Subject: RE: [stella] Formats (64K Flat Model??) From: "John Saeger" <john@xxxxxxxxxxx> Date: Tue, 5 May 1998 02:39:19 -0700 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [stella] Formats (64K Flat Mode, Glenn Saunders | Thread | RE: [stella] Formats (64K Flat Mode, Erik Mooney |
RE: [stella] Formats (64K Flat Mode, John Saeger | Date | Re: [stella] playfield on-the-fly u, Piero Cavina |
Month |