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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[stella] Formats, Glenn Saunders | Thread | RE: [stella] Formats (64K Flat Mode, Bill Heineman |
[stella] Update to my game, Bob Colbert | Date | RE: [stella] Formats (64K Flat Mode, Bill Heineman |
Month |