> Most you'd get out of me is a green screen if it passed, and maybe that in
> between channels look if it failed! Speaking of which, have you ever played
> with turning the Atari on and off without a cart in the slot? Amazing how
> often the display syncs. It's like air has vsyncs and vblanks in all the
> right places. ;-)
Huh? When you do that, you end up with basically random values in all the
TIA registers, which probably won't change (the CPU will hit a loop or a
JAM pretty quickly.) If the VSYNC register
contains zero, then the TV will do its own syncing, for a stable picture
which will consist of whatever values ended up in the playfield, players,
etc. If VSYNC is on, the TV won't sync right and the picture will
probably roll.
> Hmmm.... Maybe. But how do you know when the 6507 *sees* the new
> instruction that you put on the bus? You'd need a pretty good idea so you
> could delay the right time between parts of the instruction. And how do you
> know when it's safe to change the instruction? If the host samples the data
> bus just when the instruction is changing it *might* see garbage and it
> *might* get lost.
You monitor the 6507 address lines, I guess... after you put the
instruction up, you wait till the lines change once (it incremented its
PC and is reading the instruction byte), then just as the lines change
again, the 6507 begins looking for the data byte, which you then supply.
Why couldn't the designers just have put the clock signal on the cart
slot? Or A/V lines? :)
> Oh, through some I/O ports on the symbiont. The symbiont could watch or
> drive the 6507 data lines at will, and it could watch the address lines too
> if it wanted. But you'd need a pretty fast symbiont to get the timing
> accurate enough for this to actually work. I really think you'd need
> dual-ported RAM to get anything like this to work with reasonably
> inexpensive technology. Have the symbiont fill the RAM with a frame's worth
> of instructions at a time. Then cycle by cycle synchronization between the
> CPUs becomes less important and you have more CPU cycles for doing the game
> calculations.
A frame of instructions at a time? That's quite a lot, and would involve
bankswitching on the RAM. It also deprives the helper CPU of the ability
to read the collision or paddle registers line by line.
> So in this scheme, the host would read the switches and store the results
> somewhere in RAM for the symbiont to see maybe once per frame...
Well, yeah, fine on the switches, if you can get by without collision
registers or paddles.
This *would* allow the helper CPU to generate sound any way it wanted, and
send it to the TIA at 15 khz or even faster... anyone for a 2600 .WAV
player? :)
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
