botton@i88.isc.com (Brian D. Botton) (12/12/90)
Hello Netlanders,
I've been away since my last postings, around Nov 6th, so I decided it was
time to send them out again. I was very surprised at what had been going on
over the last 5+ weeks. I can only hope it will die quickly.
I have two machines at home, one mine, the other borrowed from work. Last
April my machine started having memory problems in low memory, i.e., the area
of memory that the diagnostic disk doesn't check because it that's where it
get loaded. The technical reference manual talks about a memory diagnostic
ROM as well as a monitor ROM. If anyone out there has either one of these,
please let me know, I'd like to make a copy of them.
Finally I've decided I need to get my machine going, I can't keep a borrowed
machine forever. So what I plan on doing is writing a low memory diagnostic
routine to place in ROM. What I plan on doing is using a terminal hooked up
to the RS-232C port for I/O, which is a lot easier to do then bit twiddle the
screen to create characters. It also takes a lot less code to implement.
What I've been thinking of doing is this, the tech manual describes the
boot process fairly detailed, so I was thinking of combining the two into one
ROM. After a reset/power on, the ROM would wait 5 seconds for any key to be
pressed. If a key is pressed, the diagnostics would be run with I/O to a
terminal, otherwise the normal boot would progress. The diagnostics would
allow exhaustive testing of the memory management unit and the bottom 256k of
RAM. The rest of the RAM and system would be checked with the normal
diagnostics disk. The purpose of the ROM diagnostics is to make sure you can
trust the diagnostics loaded from floppy, which I cannot.
I am looking for suggestions for addition to the ROM. As it sits now, the
ROM uses only ~4k out of a possible 32k. What would you like to see? Is it
worth the trouble to put a monitor program in so you can hack at the lowest
level? How about being able to tell the system to boot from a different
disk then drive 0? I'm wide open for suggestions, and possibly some help.
Of course it goes without saying that the source for the ROM will be posted,
even if I don't go any further them the memory tests. And I'll offer the
programmed ROMs for sale at a fair price. Please let me know what you think
and want/need in such a ROM.
Now for the rest of the kit news. I am in the process of putting together
another set of vidpal kits. All the parts are in stock, except the PC boards.
My vendor shipped them to me last week, but UPS seems to have lost them, so
I'll be getting a new shipment in a few days. I have two kit orders that have
been waiting for the parts to arrive and I'll ship as soon as I can, hopefully
by Saturday. What follows you may have seen before, if you haven't, then it
should answer your questions. If there are any, please feel free to e-mail
to me. BTW, if you aren't running Mgr and do program developement, you are
doing things the hard way. The little time it takes to get Mgr up and running
is well worth it. And best of all, you can still us UA, either seperately or
from within an Mgr window.
Hope to hear from you,
Brian
laidbak!botton or
laidbak!bilbo!brian
******************************************************************************
This is my standard blurb covering the kits I am selling. If you have a
question that isn't covered by this blurb, feel free to send me e-mail. I
will try to respond as quickly as possible, but my new wife and I are still
very busy, ;-).
VIDPAL KIT - $25
This kit contains a PC board, a programmed PAL, a capacitor, a socket, 66
pin sockets, ~1 inch of wire wrap wire, and complete instructions.
What this kit does is it allows you to access the video ram of you 3B1/7300
directly from any user process. The significance of this is you can now write
your own window manager with a lot less hassle. The reason I came up with this
kit was because Brad Bosch and I wanted to run Mgr on our 3B1's and we didn't
want to write a new wind.o for Mgr.
Vidpal is a little daughter board that is placed between the 68010 and the
mother board which intercepts and modifies the supervisor signal. The PAL
checks to see if you are addressing the video ram, and if you are, the
supervisor signal is forced active. This means the memory management PAL will
not cause a bus error because it thinks your are in kernel mode. The vidpal
PAL makes sure that ONLY the video ram is made accessible, otherwise you would
loose all hardware protection.
One of my design goals was there had to be NO modifications to the mother
board, and the daughter board allows this. The kit requires a modest amount
of soldering skill and for your machine to be mostly disassembled. Most
people will find that it isn't difficult to assemble and install.
SECOND HALF OF VIDPAL KIT - $15
I used to sell only part of the vidpal kit for $10. For those people who
purchased the partial kit, I have what I call the second half of the kit
available. This kit includes all the rest of the components that you had to
order on your own to complete the partial kit. THIS KIT IS ONLY FOR THOSE
OF YOU WHO ORDERED PARTIAL KITS, YOU KNOW WHO YOU ARE. If you don't have
a vidpal kit and would like one, order the full kit mentioned above.
P5.1 UPGRADE KIT - $6
I am selling copies of the Convergent P5.1 upgrade kit. This kit includes
a programmed PAL, a high quality socket, a capacitor, and instructions which
include several diagrams. You will have to provide about 10 feet of wire wrap
wire and soldering tools.
The P5.1 upgrade allows you to use hard disk drives, such as the Seagate
ST-4096, that have more than 8 heads. To get more then 1025 cylinders you will
need a WD2010x chip, which I am NOT selling. There have been several
discussions on the net about this topic, so I will refer you there.
This kit is more difficult to install then the vidpal kit, but it is not out
of the reach of most people. You will have to take your machine almost
completely apart, but it isn't hard to do. There ARE some alternatives to
this kit. ICUS Software (Lenny and GIL) sells instructions on making a board
that allows two hard disk drives to be accessed by your computer while giving
you more then 8 heads. While the P5.1 kit doesn't interfere, it is a no-op as
far as their kit is concerned. Also, John Bly Milton has a board that will let
you access 4 hard disk drives with more than 8 heads and 2 floppy disk drives.
From what I understand, you will need to do most of the P5.1 upgrade, but if
you are going to use his board, don't bother getting the P5.1 kit from me.
EXTENDED DIAGNOSTICS DISK - $1 or $2
If you are going to format a hard disk drive with more then 8 heads and/or
more then 1024 cylinders, you need to get a copy of the extended diagnostics
floppy disk. I am providing copies of this disk for a modest fee.
MGR - $0
Mgr is a great little window manager that is relatively easy to install and
works quite well. As many of you know, it is still in beta, but don't let that
stop you. It really is quite solid and is beta mainly because the device
drivers need to have their install scripts cleaned up, along with some minor
details. If you like having windows similar to what you have on a Sun, this is
what you are looking for.
There are a couple of things you should know about this package. First, it
uses the public domain pseudo ttys package that has been posted to the net, so
if you have pseudo ttys from elsewhere, ethernet board and starlan?, you will
need to do a little reconfiguring; Brad does provide the necessary guidelines.
Also, Mgr will not compile with gcc, at least not the version that Brad has,
but works just fine with the stock cc. Both of us have 3.51/3.51m systems so
we cannot test Mgr with anything earlier. As long as you have a flexnames
compiler FROM AT&T you shouldn't have any problems.
To get a copy of Mgr, use anonymous ftp to max.physics.sunysb.edu,
129.49.21.100. You need only the main file, the patch files are for people
with earlier releases.
ORDERING INFO
The kits cost the following:
vidpal $25
second half of vidpal $15
P5.1 $6
extended diagnostics disk $1 with P5.1 or vidpal kit
$2 if ordered alone
Send a mailing label and a check in US funds to my NEW ADDRESS:
Brian D. Botton
1748 Paddington Ave.
Naperville, IL. 60563-2028
--
... ___ ***
_][_n_n___i_i ________ ******* Brian D. Botton
(____________I_I______I_I_______I laidbak!botton or
/ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!briangil@limbic.ssdl.com (Gil Kloepfer Jr.) (12/13/90)
In article <1990Dec12.065224.10906@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes: >So what I plan on doing is writing a low memory diagnostic >routine to place in ROM. What I plan on doing is using a terminal hooked up >to the RS-232C port for I/O, which is a lot easier to do then bit twiddle the >screen to create characters. It also takes a lot less code to implement. I know it's more work, but I'd rather see the I/O to the console. I guess many of us have terminals or extra UNIX-pcs, but there's the other half who would bemefit from the console I/O. I think it would be worth it. >After a reset/power on, the ROM would wait 5 seconds for any key to be >pressed. If a key is pressed, the diagnostics would be run with I/O to a >terminal, otherwise the normal boot would progress. This sounds like an interesting idea. >allow exhaustive testing of the memory management unit and the bottom 256k of >RAM. The rest of the RAM and system would be checked with the normal >diagnostics disk. PLEASE! Go the rest of the way and make a diag that allows selective testing of banks of memory in the upper region also. I had a bad chip on a combo card, and it took me forever to find. As you get to this much code, you might need to put this part on a floppy though... :-( Has anyone else out there also had difficulty diagnosing RAM problems because the problem was in the combo board, and the UNIX-pc diag needs to run the complete RAM test before getting there? >worth the trouble to put a monitor program in so you can hack at the lowest >level? Sounds neat too... I wonder how many people would actually find this useful though. >How about being able to tell the system to boot from a different >disk then drive 0? I don't think that you'd be putting this in the boot ROMs, although this would also be a neat addition... Sounds good. There's quite a bit of software which needs to be developed for the ROM though. Only problems I see are making ROMable code from the compiled (COFF) output, and maybe trying to squeeze lots into 32K. -- Gil Kloepfer, Jr. gil@limbic.ssdl.com ...!ames!limbic!gil Southwest Systems Development Labs (Div of ICUS) Houston, Texas "There are beautiful people I wish would have never opened their mouths, because such ugliness oozes out." Philosophy Prof. at NYIT
botton@i88.isc.com (Brian D. Botton) (12/14/90)
In article <111@limbic.ssdl.com> gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes: >In article <1990Dec12.065224.10906@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes: >>So what I plan on doing is writing a low memory diagnostic >>routine to place in ROM. What I plan on doing is using a terminal hooked up >>to the RS-232C port for I/O, which is a lot easier to do then bit twiddle the >>screen to create characters. It also takes a lot less code to implement. > >I know it's more work, but I'd rather see the I/O to the console. I guess >many of us have terminals or extra UNIX-pcs, but there's the other half >who would bemefit from the console I/O. I think it would be worth it. I would too, however, every character has to be stored as a bit patter, which does take up a bit of space. Also, you have to implement some kind of cursor movement routine, including scrolling. None of these need to be done with a terminal if you don't mind the terminal scrolling the screen for you. I'll admit, I would love to have a monitor program where the screen has predefined and labeled fields for registers and such. I just don't see how it can be done in just 32k of ROM. Especially if you want to do a decent monitor with commands specific to the machine, such as read sector x, write sector y. The kind of things that would really get you into trouble, ;-). > >>After a reset/power on, the ROM would wait 5 seconds for any key to be >>pressed. If a key is pressed, the diagnostics would be run with I/O to a >>terminal, otherwise the normal boot would progress. > >This sounds like an interesting idea. Thanks, :-). > >>allow exhaustive testing of the memory management unit and the bottom 256k of >>RAM. The rest of the RAM and system would be checked with the normal >>diagnostics disk. > >PLEASE! Go the rest of the way and make a diag that allows selective >testing of banks of memory in the upper region also. I had a bad chip >on a combo card, and it took me forever to find. As you get to this much >code, you might need to put this part on a floppy though... :-( Has >anyone else out there also had difficulty diagnosing RAM problems because >the problem was in the combo board, and the UNIX-pc diag needs to run the >complete RAM test before getting there? Okay, okay, you're right. It wouldn't take to much effort to specify a start and end range as well as an iteration count. Consider it added. > >>worth the trouble to put a monitor program in so you can hack at the lowest >>level? > >Sounds neat too... I wonder how many people would actually find this useful >though. Yea, sound neat, but I don't know who would use it. Maybe a better answer is to put in the screen I/O and pair down what the ROM can do. Such as: 1. Test MMU 2. Test memory 3. Read floppy block x 4. Write floppy block x 5. Read HD block x 6. Write HD block x This way, if you want, you can get blocks onto and off of the HD and put them somewhere useful, i.e., the floppy, for later perusal on a system with tools like od. > >>How about being able to tell the system to boot from a different >>disk then drive 0? > >I don't think that you'd be putting this in the boot ROMs, although >this would also be a neat addition... > What I was thinking here is telling the boot ROM to load the loader off a different drive then drive 0. That loader would have to understand how to continue the boot from drive 1 when it gets run. >Sounds good. There's quite a bit of software which needs to be developed >for the ROM though. Only problems I see are making ROMable code from >the compiled (COFF) output, and maybe trying to squeeze lots into 32K. Actually, it isn't too bad. Using the following ifile: file name: ifile.0410 MEMORY { user_mem : origin = 0x0800000 , length = 0x08000 } SECTIONS { .text 0x0800000 : {} .data : {} .bss : {} } And the loader command: ld -o rom -n ifile.0410 rom.o This gets you a COFF binary that is set up to run at absolute address 0x0800000, which is where the ROM is. It also limits the size to 32k, which is the max ROM you can have. Now all you have to do is make sure your code is completely self contained, i.e., no printf's. There is one thing you have to do is strip off the COFF header. Through experimentation, I've found you need to chop off the first 168 bytes from the file rom. Then you need to program to EPROM chips, one with even bytes, the other with odd bytes. I agree, the big problem is the 32k limit. If it were not for that, we could do lots of neet things. Its too bad too, there is all kinds of wasted space in the slow ROM section of the address map, 4 Meg worth, ;-(. What a waste. Anyway, I'm still taking ideas. After a while I'll post a summary. Also, I just ordered a programmer so I won't have to go into work to progam EPROMS, this should speed up the developement cycle quite a bit. -- ... ___ *** _][_n_n___i_i ________ ******* Brian D. Botton (____________I_I______I_I_______I laidbak!botton or /ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!brian
botton@i88.isc.com (Brian D. Botton) (12/14/90)
In article <1990Dec14.060413.13515@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes: >In article <111@limbic.ssdl.com> gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes: >>Sounds good. There's quite a bit of software which needs to be developed >>for the ROM though. Only problems I see are making ROMable code from >>the compiled (COFF) output, and maybe trying to squeeze lots into 32K. > Guess what folks, I just dug out my TI memory data book and found something very interesting. The 3B1/7300's motherboard supports 14 address lines to the ROMs for a max of 2 X 16k = 32k. However, the program pin, pin 27, is not connected, and the programming voltage pin, pin 1, is tied to +5V. If you look a few pages further into the data book, you come across the 27512, which uses these 2 pins for added address lines, for a total of 2 X 64k = 128k! So, by running a couple of white wires we can have our cake and eat it too! There might be a problem with pin 1, depending on where the +5V trace is, but there are easy ways around this even if it is burried. For those of you who have done a P5.1 upgrade, this would be trivial. So, new we have the potential of 128k ROM space. That's more then enough for a video based ROM with built in monitor, diagnostics, alternate boot, etc. Let me know what you think. -- ... ___ *** _][_n_n___i_i ________ ******* Brian D. Botton (____________I_I______I_I_______I laidbak!botton or /ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!brian
ahh@glyph.UUCP (Andy Heffernan) (12/15/90)
In article <1990Dec14.060413.13515@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes: [...] > This gets you a COFF binary that is set up to run at absolute address >0x0800000, which is where the ROM is. It also limits the size to 32k, >which is the max ROM you can have. Now all you have to do is make sure >your code is completely self contained, i.e., no printf's. I think you'll have to pay special attention to un-initialized data blocks, like your stack, any global variables you might have, etc. You can't modify your pre-initialized data, naturally. You'll probably need your own startup code, too. > There is one thing you have to do is strip off the COFF header. Through >experimentation, I've found you need to chop off the first 168 bytes from >the file rom. Then you need to program to EPROM chips, one with even bytes, >the other with odd bytes. You probably know this already, but there's more to COFF than the header and your data. Your data is sitting in the middle of all kinds of goop (although the tail end might be gone if you've stripped the binary). It's pretty durn easy, though, to write a program that extracts the .text and .data section data from a COFF object. See ldfcn(4). -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "`Ha ha ha,' taunted Judy. `Your scaly exterior seems to be failing you!'"
jmm@eci386.uucp (John Macdonald) (12/18/90)
In article <1990Dec14.060413.13515@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes: |>>worth the trouble to put a monitor program in so you can hack at the lowest |>>level? |> |>Sounds neat too... I wonder how many people would actually find this useful |>though. | | Yea, sound neat, but I don't know who would use it. Maybe a better answer |is to put in the screen I/O and pair down what the ROM can do. Such as: | | 1. Test MMU | 2. Test memory | 3. Read floppy block x | 4. Write floppy block x | 5. Read HD block x | 6. Write HD block x | | This way, if you want, you can get blocks onto and off of the HD and put |them somewhere useful, i.e., the floppy, for later perusal on a system with |tools like od. How about: backup and restore, which copy a disk partition to or from a sequence of tapes or floppies. This allows making a full image backup of a system. If needed, it can be restored on a blank (but formatted) disk without having to install an OS on the disk and then trying to not trip over itself when it restores over top of itself. Restoring the root partition is trivial in this fashion. I had these functions in the PROMs I wrote for another system. PROM-based backup and restore are extremely valuable. (It was more valuable in that system, which always had a 40 Meg tape drive for making the backups - they are a lot better than floppies for this purpose.) The same code that does the floppy sequencing for backups could be used to allow loading an OS (or test program) that is too big to fit on a single floppy. (Imagine a kernel with a compiled-in, initialized 1.5 Meg ram disk. You could boot from floppy with a system that had a built-in tape driver, a sufficient file system for repair activity (fsck, etc., but not totally stripped down to the bare bones), and would still be able to mount a floppy file system. Actually, this system is not as valuable as it sounds - the PROM backup capability allows you to backup the non-working system, reinstall a working system, restore the backed-up stuff to an alternate partition to be fixed with a full running system, and then copy it back into its proper place with the PROMs). In a later message Brian mentions being able to use bigger PROMs and having a huge amount of available space. Great. How about putting fsck into the PROMs, allowing the output log to be saved on a floppy for later examination. I'd love to have the "normal" startup sequence default to something like the following: the PROM code checks for a floppy if present and there is a magic flag of some sort the PROM continues to run without loading from the floppy the PROM resets the magic flag the PROM runs fsck on a sequence of file systems given on the floppy, using arguments specified on the floppy, the output of fsck gets stored on the floppy the PROM boots the default system from disk the startup code collects the fsck log and sets the magic flag again This would allow the default startup procedure to be fairly safe while still being automatic. The log from fsck is not lost, so file that have problems can be seen. Putting fsck into the PROM is not a trivial proposition, it would require writing a set of functions that provide the system call capabilities that fsck expects. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
flinton@eagle.wesleyan.edu (12/22/90)
In article <1990Dec17.165934.1407@eci386.uucp>, jmm@eci386.uucp (John Macdonald) writes: > always had a 40 Meg tape drive for making the backups - they are I'd be very pleased to learn whether the 40 Meg AT&T tape unit being advertised in their current flier by Jade is compatible/usable with the 3b1. No specifics are given, but the price (around $250) seems right ... . E-mail to fejlinton@attmail.com might be fastest. Thanks. -- Fred
flinton@eagle.wesleyan.edu (12/22/90)
In article <1990Dec21.135502.37150@eagle.wesleyan.edu>, I wrote: > I'd be very pleased to learn whether the 40 Meg AT&T tape unit > being advertised in their current flier by Jade is compatible/usable with > the 3b1. In the same flier Jade offers an "AT&T Full Page Scanner (PC/AT/386 compatible, 200 DPI, w/ MS PagePower S/W)" -- can that link with the 3b1? Again, I'd much appreciate any usability/compatibility remarks. For replies, > E-mail to fejlinton@attmail.com might be fastest. Thanks. -- Fred
mvadh@cbnews.att.com (andrew.d.hay) (12/26/90)
In article <1990Dec21.135502.37150@eagle.wesleyan.edu>, flinton@eagle.wesleyan.edu writes: > I'd be very pleased to learn whether the 40 Meg AT&T tape unit > being advertised in their current flier by Jade is compatible/usable with > the 3b1. No specifics are given, but the price (around $250) seems right ... . nope, but if it's qic-40 (& it looks like a repackaged cms jumbo), i'll get back into high gear on a driver for it just as soon as i get jbm's disk upgrade board. -- Andrew Hay +------------------------------------------------------+ Ragged Individualist | You just have _N_O idea! It's the difference | AT&T-BL Ward Hill MA | between _S_H_O_O_T_I_N_G a bullet and _T_H_R_O_W_I_N_G it! | a.d.hay@att.com +------------------------------------------------------+