On Fri, Aug 13, 2004 at 01:37:33PM -0400, Dave Dunfield wrote:
> Hi Ethan,
>
> Thanks again for the very useful information.
You are welcome.
> 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.
OK... thanks for the reminder about how far it gets.
> I hunted around funet and found the Basic4 ROM disassembly - as far as I can tell,
> it exactly matches the ROMs in this PET.
That makes sense. AFAIK, the base 8032 is unchanged when "converted" to a SuperPET.
All the magic is in the board that attaches to the processor socket.
> 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).
Cool... much of it is working, then.
> 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.
OK...
> 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)
Hmm... I just checked vs xpet and SP _is_ 01... that means that the stack is 'full'
on entering the monitor. I'm not surprised that some of the functions act wierd.
I don't recall how a 6502 acts when the SP wraps around, but it's probably not the
best thing in the world to be doing.
> 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).
That makes sense.
> 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 ...
Is there an ASCII 0x07 (BEL) in the message?
> 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.
OK...
> By using a reset switch, I was able (after several attempts) to bring the machine
> up from power off in "normal" mode....
>
> Any further ideas?
You've got me stumped now. I'm not the worlds greatest experts when it comes to
BASIC 4.0 machines. All of my deep, deep exploration was in the days of BASIC 2.0
on a pre-6545 (TTL video) PET. By the time I got an 8032, I didn't have to dig
into the depths that far to accomplish what I wanted to do.
Maybe you could write a program that checksums the BASIC ROMs (4K at a time)? It
wouldn't even have to call $FFD2 for output - you could just write the values into
RAM somewhere and you could end with a BRK (0x00). VICE (xpet) would be a good way
to validate your experiements. It's quite precise about how it emulates things.
You could even enter the same program into xpet and use that to verify your checksums.
At this point, you might be having RAM problems, ROM problems, or something unrelated
(address select, etc.) If your PET had sockets for the ROMs, I'd recommend replacing
them. Since you don't, that won't help.
The only thing that comes to mind is that the BASIC print routine probably still
synchronizes with the frame refresh signal on 6545-based models. The "killer poke"
is entwined with this concept, because the point of it (with the original hardware)
was to set a particular bit on a 6520 such that the BASIC PRINT subroutine always
thought it was "safe" to scribble on screen memory, speeding up PRINTing significantly
(there's a whole genre of BASIC animations that depend on the killer poke for special
effects).
The char print kernel routine at $FFD2 doesn't check this bit, just the BASIC PRINT
subroutine, _before_ it calls $FFD2. Perhaps that circuit is faulty and it's hanging
while printing the startup banner because BASIC doesn't think it's "safe" to write to
screen memory without potentially causing an access conflict with the screen update
process.
Just a guess, but I can't figure another reason why the monitor would fire up in
diagnostic mode, but the startup banner would "hang".
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 13-Aug-2004 22:10 Z
South Pole Station
PSC 468 Box 400 Temp -75.7 F (-59.9 C) Windchill -119 F (-83.90 C)
APO AP 96598 Wind 15.1 kts Grid 093 Barometer 669.8 mb (11014 ft)
Ethan.Dicks_at_amanda.spole.gov http://penguincentral.com/penguincentral.html
Received on Fri Aug 13 2004 - 17:30:39 BST