Re: option ROM into a 3032 - A better test rom for PET?

On Fri, Sep 29, 2017 at 8:08 PM, Mia Magnusson <mia@plea.se> wrote:
> Den Thu, 28 Sep 2017 19:14:02 +0200 skrev Francesco Messineo
> <francesco.messineo@gmail.com>:
>> Now for the real "funny" part: pettester.bin shows no error both on
>> VRAM and on the system RAM, but using the original kernel EPROM on UD9
>> gives a garbage screen.
>
> I haven't had a look at the source code that dave_m just posted, but
> AFAIK the petester.bin can't tell if there is something wrong with the
> adress lines/decoding, only if some data bit is stuck.

yes it doesn't even find some quite common errors. I've first used
while repairing my own 3032, it helped, but it didn't find all
problems on the RAM.
If curious, look at: https://www.youtube.com/watch?v=H5_mTETwWJk

>

> I.e. you'd need a test that fills memory with 0,1,2,3,4,... and
> afterwards check if they read back correct. Preferably only fill up to
> 254 instead of 255 as that would be good enough to catch problems even
> if A0-A7 are good. (Just filling all memory with 0-255 and mirror that
> on each page would of course not show any problem with A8 and the
> higher adress lines).
>
> Maybe it's kind of hard to do this without reling on any ram at all.

well, actually I started some years ago on writing some C64 "dead test" code
that I would use in place of the kernel, it didn't rely on any RAM
until some part of it were
tested good. It would output a 9600 bps serial code using the internal
I/O port of the 6510, so that the serial output would appear on a pin
of the tape port.
Generating code with macros (until you can actually have a stack) was
something funny ;-)

> Although without any reliable ram at all you might use the stack
> pointer as a temporary storage (TAS, TSA or whatever the instructions
> are called) and with a large enough rom you could unroll some loops so
> you don't need a loop counter.

SP can only be transferred to and from X. I don't remember if I had
used it before checking the stack area.

>
> Or the tester code could start with a check if some screen ram or some
> main ram seems ok and use that as a temporary storage. (If access to
> main ram does bad things with screen ram or vice versa I think it would
> be hard to make the tester run at all).

yes, on a PET, video ram is different from the main ram, so it could
be used as general purpose
area when the main ram is dead or unknown. However, you wouldn't have
stack and zero page.

> One thing the tester could do is check if the I/O chips work and output
> it's state to the user port or use the user port data register as a
> temporary storage.

that's another very good idea, few bytes, but indeed useful.


> P.S. I'm one of the best at making up more or less good ideas and one
> of the worst at actually taking the time and energy to implement them :)

I'm on the same side :)
If I had to fix one PET per month, well, maybe I'd spend some time
making my custom ROM, but I don't think it will ever happen here (and
maybe to anyone else in the world).
Actually I could even justify getting a nice logic analyzer if I had
this volume of fixing jobs :)

Frank

       Message was sent through the cbm-hackers mailing list