Xref: utzoo unix-pc.general:6850 comp.sys.att:11179
Path: utzoo!utgpu!watserv1!watmath!uunet!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!limbic!gil
From: gil@limbic.ssdl.com (Gil Kloepfer Jr.)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: kit posting, what I'm working on
Summary: Some additions to memory diags
Message-ID: <111@limbic.ssdl.com>
Date: 13 Dec 90 13:52:04 GMT
References: <1990Dec12.065224.10906@i88.isc.com>
Organization: Southwest Systems Development Labs, Houston, TX
Lines: 49

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