I mean how far can the original console be pushed given a cartridge input, where the cartridge would take over as much as possible? I know the video output is limited to what it can do on an old TV, and sound is likewise limited, but could a cartridge basically take all of the heavy lifting and just use the Atari CPU for display only with the cartridge doing all the processing? Could we get games like Minecraft (in SD) working on it if it was taken to its limits, like the cartridge having it’s own video card and just spit out display info for the CPU to display on the TV?
OK, it has been a long time since I looked at one of those, but I thought the cartridge was just ROM, maybe with a little permanent storage to hold high scores or game saves, but didn’t have any processing power at all.
The TV wasn’t the limiting factor on the graphics or sound. Other video game systems (and home computers) came along that got a lot more out of those same old TVs.
The implicit question is “what if the cartridge weren’t just ROM and a little nonvolatile storage?”
People interface Raspberry Pi computers with retro electronics over the most unlikely interfaces. Who knows if this might be one of them?
Everything you could possibly think of has been/is being discussed at atariage.com and reddit.com/r/atari
I see. Well, it would be probably easier to just emulate the Atari 2600 on a Raspberry Pi than try to hack into the system through the memory bus, if that’s even possible.
The Atari is essentially a hobbled 6502 with a TIA chip handling video and sound. At what point does it stop being a 2600 if you go around these chips and put all the heavy lifting on whatever you have in your cartridge?
This is a key point I’ve been thinking about since I made my post. There’s a comedian who said he had George Washington’s axe. He just replaced the handle and head, but it occupies the same space!
I know that there were a few Nintendo cartridges that included extra processing in the cartridge, to enable things that wouldn’t have been possible with just the console’s own built-in capabilities. I don’t think that ever was done with Atari cartridges (the economics for it would rarely make sense), but I suspect that it could, if you were clever enough (and some of those Atari engineers were very clever indeed). If nothing else, you could put in some code to display a scanline retrieved from somewhere in the cartridge’s memory, and then use an onboard processor to change the content of that memory every scanline.
I suspect, though, that even doing this, you couldn’t get any better screen resolution than normal.
Which is, itself, a reference to (or restatement of) the “Ship of Theseus” paradox.
Pitfall II did have a music chip on the cart, which is why it sounds so much better than stock 2600 sounds.
ETA: apparently this chip also allowed for some graphical improvements. The sound it took from two-channel to four-channel. And it sounds more in tune to me than the TIA.
I did find a Twitter post by David Crane (of Activision fame) saying there are modern 2600 games with ARM CPUs at 50x the speed and memory of the 6507. He didn’t give titles though.
The Starpath Supercharger, introduced in 1982, used audio cassettes to allow the creation of larger games for the 2600.
Here’s a comparison of Frogger from a regular VCS cart and the SuperCharger: This Company Made Superior Atari 2600 Games. Here’s Why - YouTube
The idea is to have a cartridge that would totally blow out any expectations of the limits of the 2600, even if the cartridge is actually now the computer.
This is what I was thinking of, using the Atari itself as a display adapter doing nothing but displaying what the cartridge tells it to line by line. And sound also. So this begs the question what is the max resolution possible, even if the Atari is displaying a static picture.
Yes I had the Starpath adapter, I most likely still do somewhere. It was not just the graphics, but the depths of some of the games that was pretty amazing for it’s day.
According to Mr. Google, you’re going to be limited to a max of 160 x 192 pixels, and you’re limited to 128 colors. So, not great by modern standards.
On the other hand, you can basically remove the 6502 from the equation by holding the ready line and forcing the 6502 into perpetual wait states. Your “computer on a cartridge” could then shove data into that 160 x 192 pixels screen at a rate that the original 2600 engineers would have probably never dreamed possible.
If you made it play Doom, that would probably be quite impressive, even with the limited screen resolution. Minecraft should be possible, too.
You’ll also need to dredge up a working old tv or monitor capable of receiving NTSC signals.
This is only adjacent to your question since it’s about the NES, but it does show what you can do when you stuff advanced hardware into a cartridge:
You could do much fancier things (and glitch-free) with an FPGA instead.
But no. You have assumed the bus was designed for DMA, like an IBM PC’s ISA bus…
The atari 2600’s cartridge pinout is not designed as a bus, it just the 8 data bits, and a0 to a11.
The cartridge has no way to interfere with the atari 2600’s cpu and address decoder,etc, the 2600 is going to run its program and control (or interfere with, from the cartridge’s pespective) the address and data lines on the cartridge interface … Now the 2600’s cpu can of course run the rom on the cartridge … and be relegated to just being the I/O slave to some system on the cartridge… Pitfall 2’s cartridge shows the way… that cartridge has a data pointer register , which is a auto-incremented with each read from memory mapped IO register… so the 2600 just runs a tight loop,. load A, from cartridge IO, store A, to video or sound output register… So as to throw bytes the fastest way.
I still didn’t find info on how the cartridge knows the direction of the operation. There’s no DIR (direction) line !. Any address on the cartridge must be either output, or input ? So if you had a register on the cartridge that you wanted bidirection, you must write to it at one address, and read from it at another address ? The cartridge address decoder setting “DIR” for the cartridge, the cpu setting DIR for the motherboard.
I feel sure I’ve seen a video on a project that was attempting to implement the 2600 as graphics card for a much more powerful computer residing in the cartridge, and ran into exactly this directionality issue (and, if I recall correctly, solved it). Damned if I can find the thing now. I might be misremembering, but I think they figured out that whilst there was no read/write direction signal, it could be done by dead reckoning and very precise timing.
A note: although I’m pretty familiar with electronics and low-level programming, I am not at all an expert or even a novice with the Atari 2600. This is just what I’ve found with an hour or so of research.
The only way the 2600 can output to the TV is via the TIA chip, the “Television Interface Adaptor”. As noted above, this has 160x192 visible pixels, but it comes with a caveat, which is that with the HBLANK there are effectively 228 pixels of width, and since there is not even a linebuffer on the chip, those pixels have to be generated in realtime.
The TIA outputs one pixel per clock cycle and runs at 3.57 MHz, which is precisely 3x the clock rate of the CPU. And they run in complete lockstep. Therefore there are exactly 76 CPU cycles to generate the scanline.
But we want something fancier than what the TIA can generate natively–something more like full-color graphics. And so the real limit is more like 54 clock cycles, because that’s how much we have within the 160 pixel width.
At top speed, the CPU can write 8 bits every 3 clock cycles. And I don’t think there’s a way to go faster than that, no matter how clever we get with the cartridge. The TIA latches the data when the Ø2 input goes low. And that input is driven by the CPU itself and has no connection to the cartridge. I don’t think there’s any way to make it go low more than 18 times in that 160 pixel range.
Aside from that, the cartridge has some flexibility. There is no need for the CPU to ever read data: in fact, it can simply write 0xFF to address 0xFF over and over, continuously. The data and address pins will be high. But because the CPU uses pullup resistors to achieve the high state, they can be safely driven low by something else on the bus–like the cartridge. So if it gets the timing right, it can output whatever data it wants (just not more than 18 times per scanline).
What can we do with those 18 writes? Well, we can change the background color to whatever, and not even have a foreground. And the palette of 128 colors really isn’t too bad. So we get an image of 18x192 pixels in glorious 7-bit color, which is a bit of a weird aspect ratio, but you can use the excess vertical resolution to achieve some color dithering. From a distance, I think videos wouldn’t look too bad.
You can change the horizontal offset of the background color changes within a 9-pixel window, either temporally or across scanlines. That would give a blurring effect, and be a little flickery, but would smooth out transitions. I suspect that photos would be greatly improved and sorta have 54-pixel width.
And you can use the sprites. You effectively get 8 pixels from every write. It’s just binary, so you get a foreground and background color, but that’s not bad. Unfortunately, you still can only write 8 bits every 9 pixels–not enough for full-resolution text. And you have to update their positions, since there’s only two of them, and you’d have to step through them as the scanline is rasterized. They can be stretched to 2x or 4x width. I think it would be easy to handle 4x, and you’d get a real 40 pixel width from that. 2x might be just doable, since the first two sprites can be set up in advance. I’m not going to do the timing by hand. But I think it might just barely be possible to get an 80-pixel width.
You can also blend these techniques. With the 4x stretch mode, you have 7 writes to update 16 pixels (16*4/9=7.1). So, for each sprite, 3x writes to update position/pixels/color, and then one more to update the background. Though I’m not 100% sure it works out given how it needs to be interleaved. Still, you could get something close to 40 pixels width, where each 8x1 chunk can be any two colors (well, one has to be shared with an adjacent 8x1 chunk).
The TIA supports a few other things, like a 20-bit playfield… but I think the other features aren’t as useful here. Though maybe I’m not imaginative enough.
If it were possible to write to the TIA more frequently, you could do a lot more. I’m not seeing it, though.
References:
Schematic: https://www.atariage.com/2600/archives/schematics/Schematic_2600_High.html
Instruction set (with timing), and other info: https://cdn.hackaday.io/files/1646277043401568/Atari_2600_Programming_for_Newbies_Revised_Edition.pdf
Basic TIA info: Television Interface Adaptor - Wikipedia
Detailed TIA info: TIA-1A Manual
“Bus stuffing” info: Atari 2600 Hardware Acceleration | Big Mess o' Wires
I do remember someone making DOOM for the NES. Not the same thing, obviously, as the NES is much more powerful. But it worked the way you guys are describing: he put a CPU in the cartridge that could actually run the game, and just used the NES for input and output.
And the result was that they couldn’t actually make the video perfect. The NES doesn’t support raw output to screen, instead using sprites. So the programmer came up with an engine that would basically create the necessary sprites on the fly. The result has some glitchy aspects in it, though.
So that may in fact be a limit on the Atari as well.
