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