kit posting, what I'm working on

[Brian D. Botton]

In article <111 at limbic.ssdl.com> gil at limbic.ssdl.com (Gil Kloepfer Jr.) writes:
>In article <1990Dec12.065224.10906 at i88.isc.com> botton at 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