> Lately, as I've been contemplating the future of the z26 emulator, I came to
> the conclusion that it would be nice if it could run minimalist Commodore 64
> binaries, so that we could certify the 6502 CPU emulation by running the
> Wolfgang Lorentz 6502 CPU diagnostics. I thought to do this we might need
Sounds like it'd be less work to convert those diagnostics to 2600
bankswitched format, and change the output routines accordingly :)
> to support the full 64K address space. Then I started thinking, wouldn't it
> be nice if you could write 2600 programs with the full 64K address space
> without having to worry about bank-switching? It would be easy to do in an
Careful... this thinking is what led to the nightmare of 80386
protected-mode programming and Windows GPFs - "Wouldn't it be nice if we
could write PC programs with the full 16mb address space without having to
wrory about segments?" :)
> I think the easiest way to see how this might be possible is to imagine a
> 6502 with a full complement of address lines inside the cartridge running in
> parallel with the 6507 in the system unit. Ignoring for the moment just how
> we get the CPU in the cartridge to actually be running lock-step with the
> system unit, I think it's easy to see that since high order address bits can
> be easily put in the object code, we can let the CPU in the cartridge
> generate the high order address bits for memory references to the cartridge.
> When accessing memory on the cartridge, the host CPU would essentially be
> *looking over the shoulder* of the CPU in the cartridge. For RIOT and TIA
> accesses, since all the information shows up on the bus, the CPU in the
> cartridge would be *looking over the shoulder* of the host CPU.
The way I see it, you'd bave the 13-bit address bus connected between the
6507 via the cart slot, the 6502, and the ROM. And the last three bits of
the address bus connected *only* between the 6502 and the ROM. Now,
supposed the code calls for a byte at address $503F, say via LDA $503F.
The 6507 can only send the low 13 bytes of the address; the 6502, running
the same code, supplies the other 3. The ROM returns the data in that
location via the 8-bit data bus, which would have to be connected to both
the 6502 and the 6507, via the cart slot. This looks like it just might
work, actually, as long as the two CPUs run at the same speed and react
exactly the same way to all code. And if the bus can handle two different
devices writing the same data to it at the same time, which I think can be
done.
Also assuming the two CPUs can be synced. That's the bugaboo. There's no
clock signal thru the cart slot. Nor is there a HALT signal, so the 6502
wouldn't be able to respond to WSYNCs correctly. And if ever the CPUs get
unsynced from each other (which would be the case at powerup), there's no
returning - they'd be writing different things to the address bus, and
everything promptly grinds to a halt. Hopefully after writing some
psychedelic patterns to the screen. :)
The sync problems could be overcome if the 6502 could be prevented from
*writing* to the data and lower 13 bits of the address buses, but it could
read from them. This forces sync - the two chips would always be reading
from the same address. If the chips hit a STA WSYNC, the 6502 would end p
rereading the STA WSYNC over and over again (and its writes to WSYNC go
to /dev/null, because it can't write to the bus), until the 6507 changed
the address lines to something else.
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.
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. 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) 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.
This basically makes the 6507 just a vehicle to the TIA, and gets us all
the computing power, RAM, and ROM we can buy for game calculations. Not
that I actually expect anyone to do this... the timing issues would be
incredibly difficult... but designing theoretical computer systems is much
more fun than designing the real things :)
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
