The Frob was an Atari VCS #GameDev system card for the #Apple2.
It had an interactive debugger called FMON which I am trying to debug. And an apple2 side called AMON, these run in tandem.
The Frob was unique because it had a pair of bi-directional registers for status and sending one byte of data. This can be used by the VCS and the Apple2 to send information to each other.
Chapter 2 of the Frob manual describes the operation of these registers.
These bi-directional registers were exposed as two addresses (e.g. $C0A0, $C0A1 for slot 2) on the apple2, and as three addresses ($FFF0, $FFF1, and $FFF2) on the VCS.
The status register only comprises the two uppermost bits. Bit 7 is Write OK, Bit 6 is Read OK. They are set once their complementary operation is performed.
So basically, I am seeing a situation where both sides are waiting for an OK, in a dead-lock, because the VCS isn't completing its read.
I've added bits of debug statements to the Apple2 side to see when FMON transactions are happening, and am trying to work through where the deadlock happens.
THIS DEADLOCK DOES NOT HAPPEN WITH THE CONTROL CODE THAT YOU CAN EMBED E.G. USING THE FROB EXPLORER. MY PLAYER TOOL USES THIS CODE TOO, AND IT WORKS WITHOUT FAIL.
Rebecca Heineman had offered some advice on a debugging procedure which involved embedding FMON. This approach does not work, however, because FMON is intended to be isolated in the VCS address space at a known address. It's intended to just sit and spin with nothing else bothering it, right at the end of the address space. This is in stark contrast to EXPLORER, which embeds a routine to interpret commands in-line with the game code.
FMON is a bit unique in that it uses some clever tricks.
AMON injects a bit of code into VCS RAM which loops and sleeps, then jumping to the IRQ (BRK) vector, which is used to support breakpoints.
Meanwhile FMON preserves and restores state when Go is entered and exited.
Another peculiarity, is that reading/writing to ROM addresses cause a corresponding operation to shadow area in the Apple2 at $8000, which is then transferred to the FROB memory area via PMOVE. This means that I can use FMON to alter ROM code just fine, but when I attempt a RAM or register read or write, it hangs while sending parameters.
Sigh. :)