microprocessor on a 2600 cartridge?

[Seymour]

I have had this idea for a microprocessor based 2600 game cartridge in my head for a long time. Way back when I did some simple hacks to Combat for the 2600, just enough to know that every machine cycle counts. So here's the idea: Make a cartridge with a fast onboard processor and memory, etc. that creates the ROM image for the game system on the fly. The actual game programming could be handled by the onboard processor and the "generated code" could be mostly immediate loads and then stores to hardware registers. So the 650x processor on the 2600 only has to deal with the hardware.

 

Not having actually programmed a game on the 2600 I don't really know what kinds of thing you could do with this that you couldn't do otherwise. Of course such a game cartridge would in theory be able to emulate any other game. I would appreciate any comments.

[GroovyBee]

I have had this idea for a microprocessor based 2600 game cartridge in my head for a long time. Way back when I did some simple hacks to Combat for the 2600, just enough to know that every machine cycle counts. So here's the idea: Make a cartridge with a fast onboard processor and memory, etc. that creates the ROM image for the game system on the fly. The actual game programming could be handled by the onboard processor and the "generated code" could be mostly immediate loads and then stores to hardware registers. So the 650x processor on the 2600 only has to deal with the hardware.

 

Not having actually programmed a game on the 2600 I don't really know what kinds of thing you could do with this that you couldn't do otherwise. Of course such a game cartridge would in theory be able to emulate any other game. I would appreciate any comments.

If its supplying ROM code/data on the fly you have to service the 6502 every 840ns or so. Even with an embedded ARM running at 75MHz you only get 63 full clock cycles in that time. In those cycles you have to read the 6502 bus, decode its address and then act upon it. You'll also have to resync to the 6502 bus periodically due to the ARM/6502 clock frequency missmatch too. In my opinion its possible, but it'll have to be done in assembler and a microcontroller/FPGA combination I suspect.

 

Search on the forums for the Chimera project. However, that was more of a coprocessor to the 6502.

[roland p]

Maybe the new cart designs with microcontroller/fpga will be able to do this. But this kind of coding is probably very hard to debug.

[supercat]

So here's the idea: Make a cartridge with a fast onboard processor and memory, etc. that creates the ROM image for the game system on the fly. The actual game programming could be handled by the onboard processor and the "generated code" could be mostly immediate loads and then stores to hardware registers. So the 650x processor on the 2600 only has to deal with the hardware.

 

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.

[BigO]

It's something I've thought about, too, but not much beyond the wouldn't-it-be-cool surface level. Good luck with your efforts.

 

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.

Should be interesting to see how you implement it. I'll be watching for it.

Edited April 5, 2009 by BigO

[potatohead]

A Propeller can do this kind of thing very well.

 

What it brings to the table that most other MCUs don't, is it being a deterministic multi-processor. There are 8 CPU's, all sharing the same I/O pins in real time, sharing 32K of common memory in round-robin fashion, and executing programs from their 2K of CPU memory simultaneously. There are NO interrupts on the CPU. They are not necessary, because of the multi-processing.

 

Each CPU does 20MIPS, with a system clock of 80Mhz. They run without disturbing one another, unless the user program requires that to happen. (one CPU waiting on the state of another)

 

Take a look at this project, for an idea of how that can work.

 

http://www.parallax.com/tabid/708/Default.aspx

 

If desired, the chip has onboard graphics capability, for a real-time debug, interaction, if you want! Could have a coupla three CPU's doing your "present as ROM" task, another one driving a video display, and another taking serial data, or keyboard.

 

I don't have the skill yet to attempt this. Others have and are doing things along these lines with good results.

 

External circuit requirements are very low. EEPROM, xtal, and a few discrete are all that is needed.

[+batari]

I have had this idea for a microprocessor based 2600 game cartridge in my head for a long time. Way back when I did some simple hacks to Combat for the 2600, just enough to know that every machine cycle counts. So here's the idea: Make a cartridge with a fast onboard processor and memory, etc. that creates the ROM image for the game system on the fly. The actual game programming could be handled by the onboard processor and the "generated code" could be mostly immediate loads and then stores to hardware registers. So the 650x processor on the 2600 only has to deal with the hardware.

 

Not having actually programmed a game on the 2600 I don't really know what kinds of thing you could do with this that you couldn't do otherwise. Of course such a game cartridge would in theory be able to emulate any other game. I would appreciate any comments.

If its supplying ROM code/data on the fly you have to service the 6502 every 840ns or so. Even with an embedded ARM running at 75MHz you only get 63 full clock cycles in that time. In those cycles you have to read the 6502 bus, decode its address and then act upon it. You'll also have to resync to the 6502 bus periodically due to the ARM/6502 clock frequency missmatch too. In my opinion its possible, but it'll have to be done in assembler and a microcontroller/FPGA combination I suspect.

 

Search on the forums for the Chimera project. However, that was more of a coprocessor to the 6502.

I believe it's possible without an FPGA. In fact, the Harmony is already feeding code to the 2600 on the fly without any extra hardware support. It's not generating kernels (yet) but I don't see why it couldn't create a kernel on the fly with a display list approach, for example. Supercat's proposal also has a provision for feeding dynamic code, IIRC.

 

Here's a scan of the latest prototype. That 16-pin SOIC chip is a resistor pack, in case anyone wondered.

[Wickeycolumbus]

Batari, that thing is beautiful Is that unpopulated 8 pin DIP socket for an EEPROM (for game saves?)?

[potatohead]

Nice!!

 

I'm wanting one of those things.

[+batari]

Batari, that thing is beautiful Is that unpopulated 8 pin DIP socket for an EEPROM (for game saves?)?

It looks better with the flux cleaned off

 

Anyway, the EEPROM could be used for that purpose. It could be used for other purposes as well.

[nathanallan]

Nice!!

 

I'm wanting one of those things.

I'm definitely wanting one, too!

[Seymour]

That's great that someone is already doing something with this idea. Maybe others could write games specifically for this hardware.

 

Although I won't actually be able to take on a hardware project like this for some time, if I were going to do so the first thing I might do is try to emulate it. The first thought that comes to mind is to create a hook into an existing emulator and then feed it code on the fly.

 

So, if one wanted to do this what would be a good emulator to use?

[roland p]

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.

 

What approach did you have in mind?

 

I though about it a bit too. Just brainstorming. One thing a came up with is something that produces NOP, LDA and STA on the atari 2600 side. So if you decide in the microcontroller that you want to fill a certain atari 2600 register, it would generate one LDA and one STA instruction. And if you want to sync with the beam, it would generate a STA WSYNC instruction. And if you are busy doing other stuff, if would generate NOP's. You probably have to take care of the 2600's programcounter too so it doesn't overflow. Maybe it should generate JMP's instead of NOP's so the programcounter gets constantly resetted.

[+batari]

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.

 

What approach did you have in mind?

 

I though about it a bit too. Just brainstorming. One thing a came up with is something that produces NOP, LDA and STA on the atari 2600 side. So if you decide in the microcontroller that you want to fill a certain atari 2600 register, it would generate one LDA and one STA instruction. And if you want to sync with the beam, it would generate a STA WSYNC instruction. And if you are busy doing other stuff, if would generate NOP's. You probably have to take care of the 2600's programcounter too so it doesn't overflow. Maybe it should generate JMP's instead of NOP's so the programcounter gets constantly resetted.

That's about the same approach I was thinking of. It would allow for some fancy displays, but the display would likely need to be fed with a display list. Maintaining the display list would then require some heavy lifting that the 6507 probably couldn't manage, so coprocessing would be needed for that as well. It might even benefit from a semi-fixed kernel since certain things need to happen at certain times anyway. Doing immediate loads and ZP stores allows for quite a few writes during a scanline.

 

I wrote up a more detailed spec and even a kernel skeleton but I can't seem to find it. If I do, I will post more details.

 

The idea would have the disadvantage of larger code and data space, and a semi-fixed kernel, although powerful, would likely not be as versatile as Supercat's approach.

[sack-c0s]

my approach would be to have an FPGA with a core running on it (6502/ARM/whatever floats your boat). if you chose 6502 you wouldn't necessarily be limited to the original system speed and could be a multiple but you'd have the advantage of using a familiar instruction set. I'd also have a couple of K RAM and a small area of ROM.

 

The ROM would contain a kernel for the VCS which would iterate through a chunk of the cartridge RAM (maybe 2 chunks for double buffering), drawing the playfield from it, updating the colours, etc. and would end by storing the joystick positions in a couple of bytes of cartridge RAM, write to a latch to signal the frame is complete and time the display as usual.

 

The program on the FPGA would run the game logic, build the screen buffer and then update the screen pointer when the frame completed latch is set.

 

this would be the mother of all cheats - but this way I reckon you could have a first person shooter running natively (well, as natively as starfox runs on the SNES) on the VCS.

Edited April 7, 2009 by sack-c0s

[+batari]

my approach would be to have an FPGA with a core running on it (6502/ARM/whatever floats your boat). if you chose 6502 you wouldn't necessarily be limited to the original system speed and could be a multiple but you'd have the advantage of using a familiar instruction set. I'd also have a couple of K RAM and a small area of ROM.

 

The ROM would contain a kernel for the VCS which would iterate through a chunk of the cartridge RAM (maybe 2 chunks for double buffering), drawing the playfield from it, updating the colours, etc. and would end by storing the joystick positions in a couple of bytes of cartridge RAM, write to a latch to signal the frame is complete and time the display as usual.

 

The program on the FPGA would run the game logic, build the screen buffer and then update the screen pointer when the frame completed latch is set.

 

this would be the mother of all cheats - but this way I reckon you could have a first person shooter running natively (well, as natively as starfox runs on the SNES) on the VCS.

A 1PP shooter is still a little out of the realm of practicality (without flicker, a tiny window and/or monochrome graphics) no matter what hardware you throw at the 2600 because no matter how you slice it, the TIA still produces all of the graphics.

[Robert M]

Incomplete double post deleted.

Edited April 7, 2009 by Robert M

[Robert M]

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.

 

What approach did you have in mind?

 

I though about it a bit too. Just brainstorming. One thing a came up with is something that produces NOP, LDA and STA on the atari 2600 side. So if you decide in the microcontroller that you want to fill a certain atari 2600 register, it would generate one LDA and one STA instruction. And if you want to sync with the beam, it would generate a STA WSYNC instruction. And if you are busy doing other stuff, if would generate NOP's. You probably have to take care of the 2600's programcounter too so it doesn't overflow. Maybe it should generate JMP's instead of NOP's so the programcounter gets constantly resetted.

That's about the same approach I was thinking of. It would allow for some fancy displays, but the display would likely need to be fed with a display list. Maintaining the display list would then require some heavy lifting that the 6507 probably couldn't manage, so coprocessing would be needed for that as well. It might even benefit from a semi-fixed kernel since certain things need to happen at certain times anyway. Doing immediate loads and ZP stores allows for quite a few writes during a scanline.

 

I wrote up a more detailed spec and even a kernel skeleton but I can't seem to find it. If I do, I will post more details.

 

The idea would have the disadvantage of larger code and data space, and a semi-fixed kernel, although powerful, would likely not be as versatile as Supercat's approach.

 

I am not a HW dude so I may be mistaken on this approach, but I thought that because the 6507 in the VCS uses CMOS it is possible to use a Wired-AND approach. Such that if you have the processor always drive the data lines all high ($FF), then the cartridge hardware can pull the data lines low to make any data value.

 

The code from the point of view of the processor would be something like:

 

	  LDA #$FF
scanlineloop 
  STA WSYNC			 ; cycle 0
  STA.b <address1>   ; cycle 3
  STA.b <address2>   ; cycle 6
  STA.b <address3>   ; cycle 9
	 .
	 .
	 .
  STA.b <address23>  ; cycle 69
  JMP scanlineloop

 

So the cartrige provide the STA address, and then performs a Wired-AND on the data bus during the write to change $FF to the desired value.

[supercat]

I am not a HW dude so I may be mistaken on this approach, but I thought that because the 6507 in the VCS uses CMOS it is possible to use a Wired-AND approach. Such that if you have the processor always drive the data lines all high ($FF), then the cartridge hardware can pull the data lines low to make any data value.

 

The 6502 and TIA are NMOS, not CMOS; NMOS does behave somewhat as you describe (many CMOS do not), but I would be extremely loath to design around the fact that a CMOS "low" will win over an NMOS "high". The 6502 will not generally be destroyed by an occasional conflict on the data bus, but that does not mean that thousands of bus conflicts per second wouldn't take a toll. Although the pull-up transistors on the 6507 are not nearly as strong as a modern CMOS pull-down, the device does use active pull-up transistors which are not intended to be overdriven.

 

BTW, a 6507 can be damaged by trying to drive an address pin high with a CMOS output. My 2600jr needs a new processor because of that.

[+batari]

I am not a HW dude so I may be mistaken on this approach, but I thought that because the 6507 in the VCS uses CMOS it is possible to use a Wired-AND approach. Such that if you have the processor always drive the data lines all high ($FF), then the cartridge hardware can pull the data lines low to make any data value.

 

The 6502 and TIA are NMOS, not CMOS; NMOS does behave somewhat as you describe (many CMOS do not), but I would be extremely loath to design around the fact that a CMOS "low" will win over an NMOS "high". The 6502 will not generally be destroyed by an occasional conflict on the data bus, but that does not mean that thousands of bus conflicts per second wouldn't take a toll. Although the pull-up transistors on the 6507 are not nearly as strong as a modern CMOS pull-down, the device does use active pull-up transistors which are not intended to be overdriven.

 

BTW, a 6507 can be damaged by trying to drive an address pin high with a CMOS output. My 2600jr needs a new processor because of that.

The 650x can sink 16 times more per pin than it can source - 1.6 ma vs. 100 µA each. Clearly overdriving a low would be bad, but overdriving a high might not be so bad.

 

The data sheet for the 650x indicates that the 100 µA driving current is delivered at 2.4V, with Vcc of 4.75v. This indicates that the pullup transistors are weak - impedance would be on the order of 20kΩ. I wonder if it could indeed be done without damage?

[Keatah]

You should be able to render quake or doom-3 easily with this approach. I'm joining this thread late and need to think this through. But basically you'd build up a "frame" in the "frame-buffer" in the cart, the tia could simply read it and dump it to the screen. Or you could put code into that "frame-buffer" and the tia would execute that code and build the picture line-by-line. The 6507 would have little to nothing to do with game logic or anything else.

 

Just like having super-powrful co-processor in the cart. There is no reason why you couldn't run windows xp or any modern o/s on the 2600 this way. You'd need to work in low resolution relative to the os though.

 

Make sense ?? I mean they did this with pitfall II's sound, didn't they?

[Artlover]

There is no reason why you couldn't run windows xp or any modern o/s on the 2600 this way.

Windows on the 2600? You're just begging to be smacked, aren't you?

[Curt Vendel]

I have to see what notes and technical docs I have on a project within Atari called "Bubbles" which was a graphics and memory enhancement for the Atari VCS... in the end the only part of it that ever got used was the SARA chip. The original basis of Bubbles was from a custom chip that PVI was developing for Atari for the "Graduate" computer add-on. The chip was called "Frodochip" and was an impressive little processor, it enhanced the memory and graphics handling of the VCS and also added a new expanded Bus onto the external side of the computer keyboard that allowed for larger and more enhanced cartridges and peripherals such as ram expanders, modem, printer and a wafer drive (stringy floppy)

 

I will see what I can dig up...

 

 

 

Curt

 

 

my approach would be to have an FPGA with a core running on it (6502/ARM/whatever floats your boat). if you chose 6502 you wouldn't necessarily be limited to the original system speed and could be a multiple but you'd have the advantage of using a familiar instruction set. I'd also have a couple of K RAM and a small area of ROM.

 

The ROM would contain a kernel for the VCS which would iterate through a chunk of the cartridge RAM (maybe 2 chunks for double buffering), drawing the playfield from it, updating the colours, etc. and would end by storing the joystick positions in a couple of bytes of cartridge RAM, write to a latch to signal the frame is complete and time the display as usual.

 

The program on the FPGA would run the game logic, build the screen buffer and then update the screen pointer when the frame completed latch is set.

 

this would be the mother of all cheats - but this way I reckon you could have a first person shooter running natively (well, as natively as starfox runs on the SNES) on the VCS.

A 1PP shooter is still a little out of the realm of practicality (without flicker, a tiny window and/or monochrome graphics) no matter what hardware you throw at the 2600 because no matter how you slice it, the TIA still produces all of the graphics.

[Curt Vendel]

OKay, here is a little light reading on the Graduate computer keyboard add-on:

 

http://www.atarimuseum.com/archives/pdf/vi...esign_notes.pdf

 

This give a LOT of very useful information on how to enhance capabilities onto the VCS cartridge bus.

 

 

 

Curt

[+batari]

OKay, here is a little light reading on the Graduate computer keyboard add-on:

 

http://www.atarimuseum.com/archives/pdf/vi...esign_notes.pdf

 

This give a LOT of very useful information on how to enhance capabilities onto the VCS cartridge bus.

 

 

 

Curt

Thanks for posting! The 6502 data sheets are sorely lacking in timing waveforms, and this has answered many questions.