Erik Mooney wrote:
>
> Sounds like it'd be less work to convert those diagnostics to 2600
> bankswitched format, and change the output routines accordingly :)
Well there's around 250 binaries. One for each instruction except for
JAM's. They're only 1K or so each, but each one would need to be
disassembled, re-org'd and reassembled, not to mention modified to do
something sensible to the screen on the 2600. So far I haven't had much
luck even getting a disassembler to work. The C64 one I tried is written in
PERL, and when I tried it under Win95 it quit on me. I guess it wants the
UNIX version of PERL, but I don't really know. I'm not much of a PERL
programmer. But I more or less came to the conclusion it would be a lot of
work, even if all of the tools were working. That's why I thought I might
modify the emulator. I can leave the VGA in text mode, and emulate maybe as
few as one C64 ROM entry point, the one to do text output. For simplicity,
I can ignore the fact that each binary has code to load the next one if it's
running on a real C64 (or a decent C64 emulator). If one of those ROM entry
points is accessed, I could decide I'm done. (Man am I lazy!)
> It wouldn't be a flat 64k space, though - the TIA and RIOT wouldn't know
> to ignore accesses to $2000, $4000, etc - because those upper 3 address
> bits are *physically not present* inside the console. The best you could
> do is stripes of 4k each, for 32k total... or exactly what we get in the
> Tigervision 32k bankswitch method.
Oops, didn't think of that. But it would still be easier to program for.
This is one bank-switch scheme that the assembler already supports!
> Damn, I haven't had a good brainstorm in a while :)
>
> Approaching this from yet another angle... could it be done to have a
> self-contained CPU and ROM (and RAM) within the cart, using any CPU you
> want, and then some other sort of interfac to the cart slot, supplying
> nothing but graphics/sound opcodes and instructions to the 6507? Assume
> we have an arbitrarily fast CPU, that can handle timing issues involving
> WSYNC and VSYNC by itself, with its native code.
The parasite CPU would still need to watch the host CPU do something on the
bus every once and a while to keep synchronized. You could stay pretty
close by running at a clock frequency that's a multiple of the TIA
frequency, but there would still be some slippage.
> This new CPU decides its
> going t generate a striped, reflected playfield on the screen. It
> supplies the opcode for LDA immediate to the 6507 interface (to the 6507's
> data bus.) It waits one 6507 cycle, then supplies the number it wants to
> be in the 6507's accumulator to the 6507's bus; in this case, that byte
> would be $01, to reflect the playfield. (i might be wrong on
> that - don't
> have the TIA docs here ATM) It waits another 6507 cycle, then supplies
> the opcode for STA zeropage, waits another two 6507 cycles, then supplies
> the address of CTRLPF. From the 6507's point of view, it sees LDA #01,
> STA CTRLPF. While the 6507 is reading the LDA, #01, and the STA, its
> address bus lines (equal to its PC, which doesn't matter either) are being
> ignored by everything; during the write portion of the STA, the 6507
> supplies the address and data so the TIA will accept the $01 into the
> right address. (care would need to be taken to keep the 6507's PC in the
> $1000 range and out of the $0000 range, to avoid spurious reads to the TIA
> and RIOT - this could be accomplished by issuing an occasional JMP $1000
> to the 6507)
This looks pretty clever actually, force feeding instructions to the host on
the fly. But it would probably take a bit more horsepower than even I had
in mind. Unless you had some dual-ported RAM or DMA support on the
microcontroller. I was thinking one instruction per TIA clock. Chips are
cheap. Around 5 bucks a pop in quantity with RAM and one-time programmable
EPROM built in. But maybe someday... Maybe next year!
> And you'd need either some way to reverse the interface, so
> the fast CPU could read controlller and switch input from the TIA, or just
> plug the controllers into the cart, with an extra I/O chip.
Just feed it the instructions to read the switch inputs, and watch the data
go by on the bus.
John
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
