Hi Ethan,
Thanks again for the very useful information.
I've had some success - but now have more questions than answers.
Reminder: This SuperPET 9000 has been stripped to just the 6502 board. On power-up
it init's screen (can see garbage, then clear), plays the "bee-dle-bee-dle-bee-dle"
startup noise, then hangs with the blank screen (never displays basic startup
message). Some experimentation suggests the it continues to run code at this point
(ie: is hung waiting for something), however this is by no means certain.
I hunted around funet and found the Basic4 ROM disassembly - as far as I can tell,
it exactly matches the ROMs in this PET.
Looking at the startup code ($FD16), and the schematic, I was able to identify the
diagnostic input signal (Pin 5 of user port), and when held low, it DOES startup in
the monitor (Took me a long time to figure out the commands - especially the fact
that you need TWO spaces after ':' to write to memory).
Now is where things get interesting.
The monitor always starts up, and the 'R' always works, however 'M' to display memory
causes it to crash about 80% of the time - however if it works, it is reliable, and
'M' will continue to work until the next time I restart the machine.
Even 'M xxxx' (no second address which normally never outputs anything anyway) will
fail. Depending on the value of 'xxxx', it will either crash (hang), or more often
re-enter the monitor with 'B*' indicating it thinks a breakpoint went off (not
suprising if the stack is corrupt - read on).
At first I thought this might be an indication of bad RAM (still might be), however
after playing with it for a while, I noticed that the SP in the register display is
always '01', '03' or some low value when it doesn't work - I'm guessing the monitor
tries to locate it's stack below here and it wraps) - sometimes SP shows up as FF or
FE, and then all works fine. I have no idea how this is (not) getting initialized on
power-up entry to the monitor through the diag signal (any idea)?
Once it "works", I can read and write RAM and it appears to be holding the values
(although by no means an exhaustive test).
Another thing I don't understand yet:
When powered-up with diag held low, the system goes directly into the monitor
($D472), and DOES NOT play the "bee-dle-bee-dle..." startup noise. This indicates
that this noise should be generated by entry into BASIC ($D3B6).
Looking at this code, it sets up a few location in zero pages, and then output the
startup message (no other subs are called in between) - I see nothing which would
generate the "noise" - so one would think it is being generated AFTER the startup
message, however ...
When I start the machine with DIAG high (normal), I see screenful of garbage (briefly)
and then it clears, then the "noise" plays - no message comes out, but I know the
screen is working. Referring to the working machine, it is clear that the "noise"
finishes BEFORE the text comes out, however I don't see where it could be generated.
The only function called before the message is output is $E000 to setup the I/O,
however it is called before DIAG is tested (ie: even if entering the monitor), and
the noise is not heard in this case...
By using a reset switch, I was able (after several attempts) to bring the machine
up from power off in "normal" mode, and then pull DIAG low and reset to enter the
monitor and examine the RAM - comparing the values in ZPAGE to those written by
the BASIC init code, I can confirm that the code just before the message is output
is in fact executing...
Any further ideas?
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
Received on Fri Aug 13 2004 - 12:37:33 BST