RE: [stella] Formats (64K Flat Model??)

Subject: RE: [stella] Formats (64K Flat Model??)
From: "John Saeger" <john@xxxxxxxxxxx>
Date: Mon, 4 May 1998 10:45:53 -0700
> If your goal is to push the 2600 to the limit and you plan on a cartridge
> than I would suggest you go with a banked ROM + RAM configuration of some
> type.  We've been having some discussions along those lines and it seems
> as if anyone comes to a decision on a cartridge format that there will be
> a means to mass produce these, and also since one of the authors of a 2600
> emulator is present, even if a new cartridge format is proposed (like some
> exotic 32K SRAM or something)) there is a good chance that he could
> integrate it so that you could use an emu for debugging it.
>
> 4K is enough for a minimalist game, as so many games demonstrated, but it
> takes more memory to do busier kernels with more gfx (i.e. Solaris, 16K).
>
> The best overal existing format, IMHO, is the Supercharger.  For those who
> already own one, $0 hardware cost and modular code via multiload opens up
> lots of depth, plus more RAM to work with than even a 16K superchip cart.
> It's just hard to sell commercial software as .BINs vs. carts.


Atari 2600 64K Flat Model -- What's wrong with this picture???
--------------------------------------------------------------

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
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
emulator, but I thought it would be to little purpose since it could never
be implemented in a cartridge.  But then it occurred to me that maybe I was
wrong.  Maybe it is possible...  So I'm putting this out to the group to see
if anybody can see why it won't work.  And who knows?  Maybe someone would
want to try to build it.

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.

Now having a separate 6502 is probably not the best way to actually
implement this scheme.  Probably a fast microcontroller programmed to
emulate the 6502 well enough to generate the high order address bits.  Since
it could be running much faster than the host CPU it could maintain
synchronization with the host CPU digitally, by watching the timing of
memory references that come from the host.  And the nice part is that fast
microcontrollers aren't really that much more expensive than a PAL which is
usually used to do the bank-switching.

So what am I missing?  Where is the obvious flaw?  What's wrong with this
picture?

John


--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html

Current Thread