"Active" cartridges?

[tearex]

I've had this crazy idea, of building an "active" cartridge that does not have simply a ROM inside, but instead a cicuit with a CPU of its own (a microcontroller with built-in RAM, ROM, and I/O, most likely), that generates the opcodes on-the-fly and spoon-feeds them to the main CPU.

 

I doubt that I'll do it any time soon, but what do you think, could you defeat some of the 2600's limitations that way? Like having more colors per line or so? The kernel could consist of mostly just "LDA #$xx; STA $yy" this way (as seen from the main CPU's point of view) , without any branching instructions or calculations, those would be done by the CPU in the cart. Also you could have large amounts of ROM and RAM this way without need for bankswitching; basically the cart is the computer and the console just acts as an oversized I/O device. Maybe you could even use two controllers, one that sends instructions to the main CPU and one that actually runs the game code in parallel.

 

Only once in a while would you need to send a "JMP" to avoid overflowing the main CPU's program counter into the I/O area.

 

Basically the idea is to take the concept of Pitfall II's in-cart sound chip a step further.

 

I admit this is a bit sick, but sounds like hacker's heaven.

[Thomas Jentzsch]

Hehe, sounds interesting.

 

BTW: To feed two continous registers as fast a possible (only 6 cycles) you can abuse JSR (stack points at those registers). And 3 registers with BRK (7 cycles). Still not fast enough for hires graphics, but better than nothing.

 

But why don't you just "feed" the TIA directly?

[Pitfall Harry]

An "Active" cartridge could, theoretically, allow you to make and run whopper-sized games through your Atari, but such a cartridge could neither bypass nor overcome the speed and graphical limitations imposed by the 6507 CPU and the video display hardware.

 

The 6507 microprocessor inside the VCS can only read the 8 data address lines coming out of the cartridge (i.e one byte at a time) and only at its 1.19 MHz speed, no matter how fast the CPU inside the cartridge is. The VCS's 6507 CPU interprets the bytes it reads from the cartridge output as machine instructions, some of which write values into the TIA chip's registers to modify video output. A "Smart" CPU inside a cartridge cannot outsmart the middleman, the 6507 CPU inside the Atari which reads the cartridge output. The 6507 can only spoon feed video-altering register writes to the TIA that it knows of, that the TIA supports and only at its own speed of 1/3 the speed of the TIA chip. And the TIA chip can only do what it can do, which is not very much.

 

If you added a bypass of some sort to your cartridge PCB, you'd have to modify the VCS connector and motherboard to permit bypassing the Atari's original CPU and the TIA. But if you're going to go that route,, you may as well yank the entire works and stick a shrunken Pentium-IV board into an empty VCS console shell and have the system boot into a VCS emulator.

 

Ben

[tearex]

But why don't you just "feed" the TIA directly?

 

The idea was to do something that can work in a standard unmodified 2600's cartridge slot.

 

How much current am I allowed to take from the +5V line by the way?

[tearex]

An "Active" cartridge could, theoretically, allow you to make and run whopper-sized games through your Atari, but such a cartridge could neither bypass nor overcome the speed and graphical limitations imposed by the 6507 CPU and the video display hardware.

 

I know and the point was - could you do *any* better with my idea than what you can do with a normal ROM-plus-bankswitch cart.

 

I consider anything "fair" that plugs into an unmodified 2600's cart port and does not need external connections to anything else. Otherwise bankswitched carts are also not "fair" since they contain active components too.

 

Maybe a power supply would be needed if this simply isn't possible given the maximum amount of current the cart port supplies.

 

Of course the basic limits of the 2600 stay the same - the only limits that I could overcome are those that are based on the fact that the 6507 normally has to spend time thinking about just what to tell the TIA *and* also has to take the time to actually store it.

 

So the question is, how much time do you lose in a well-written kernel for calculations, decision making, jumping around, etc. If the answer is "hardly any time at all", then of course my idea is of no value.

 

Note: I neither have a game idea to go with this nor the needed microcontroller experience, or programming devices for that matter. Consider this a mental exercise at this point.

[Eckhard Stolberg]

But why don't you just "feed" the TIA directly?

 

Wasn't Atari's Graduate Keyboard supposed to work like this? I think there is a technical document about it on Curt Vendels site. Basically you could have a small ROM with a very simple kernel, that only does the three lines of VSYNC, does some game calculations and then constantly calls WSYNC for the active part of the frame. The processor on the cart would wait for the WSYNC address to appear on the bus for synchronisation, and then start to quickly change the TIA background colour. That way you might be able to get a 160x192 bitmap mode with 128 colours.

 

To make this usefull for games you would have to contruct a graphics chip that can handle tiles and sprites to put into the video RAM automatically so that the it can be fed into the TIA. Otherwise it would take the 6507 too long to contruct the graphics in the video RAM on the cart.

 

 

Ciao, Eckhard Stolberg

[Blackbird]

A 160x192 bitmap mode sounds great, and I actually have a project in mind which could use a bitmap mode very well on the Atari... if there's anything you could do with it, you could probably couple it with Chronocolor and have the 8-color palette. If you did have an external processor, you could probably have it dip in and out of a ROM or RAM bank, and generate code for a 160-pixel sprite.

 

i.e.: You have 160 bits of code in ROM. The processor would then anaylze the code, and generate STA instructions and insert them in some code stored in a RAM bank. You switch to a RAM bank at the beginning of a scanline, having both sprites tripled up like a 48 pixel sprite. However, in the kernal, you can save time because you don't have to draw data from a location in ROM; it's already in code, which saves you a few cycles. This can give you enough time to use RESP0 and RESP1 when you need to, which will reset the sprite to the location, and continue storing data in the sprites. Theoretically, you could create a 160-pixel sprite of one color, and with Chronocolor you could display a full bitmap with it.

 

~Blackbird

[slapdash]

Something like this WAS in the works... The guy I talked to said they had a game much like Tempest running on it. I think it was supposed to be for a cable-based games download system IIRC.

[Nukey Shay]

But why don't you just "feed" the TIA directly?

 

Wasn't Atari's Graduate Keyboard supposed to work like this? I think there is a technical document about it on Curt Vendels site. Basically you could have a small ROM with a very simple kernel, that only does the three lines of VSYNC, does some game calculations and then constantly calls WSYNC for the active part of the frame. The processor on the cart would wait for the WSYNC address to appear on the bus for synchronisation, and then start to quickly change the TIA background colour. That way you might be able to get a 160x192 bitmap mode with 128 colours.

 

To make this usefull for games you would have to contruct a graphics chip that can handle tiles and sprites to put into the video RAM automatically so that the it can be fed into the TIA. Otherwise it would take the 6507 too long to contruct the graphics in the video RAM on the cart.

I was under the impression that The Graduate simply did all the work on it's own (like the Mimic AppleII adapter did for the C64). That it just passes through the cartridge port and ignores everything that it can.

[cschell]

Ok,

 

I have to say that I do not understand why people want to do stuff like this. If you put a processor that is much more powerful than the 2600 itself in a cart, and plug it into the 2600, are you really stretching the limits of the 2600? No. You're proving that modern electronics are more powerful than the 2600. Big deal. If you want that much power, why involve the 2600 in any way?

 

Let's see, the cart has it's own power supply, it's own ROM, RAM, and processor. Gee, that's basically a computer by itself. Now add a video output and the cartridge is its very own game system. That's basically all the 2600 becomes at that point, a crappy video card for your new computer.

 

If you want a game more powerful than the 2600 can handle, write it for a more modern game system. There are plenty of them out there. I could buy an old AMC Pacer, strip it down to the chassis, build a new superstructure on top of it, cool sheet metal, great engine, modern safety systems, etc. etc. Does that really count as showing what a great car the Pacer could be? And wouldn't I have been better off starting with a better car to begin with to achieve my tricked out ride?

 

Sure, bankswitching also stretches the limits of the 2600, but in a much more subtle way. And it was done at a time when the more powerful systems were running on similar hardware, just with more address lines for handling more ROM and RAM. So it was reasonable to do that.

 

IMO (notice no H, I won't kid myself here), the beauty of the 2600 was its simplicity. Once you add a modern processor to start making more modern games, you've destroyed any semblance of what makes the 2600 what it is. Why not just gut it and put a computer inside?

 

Chad

[Pitfall Harry]

Chad, I could not possibly agree with you more.

 

Ben

[Blackbird]

I agree as well, actually. I planned out what I said last night, and you wouldn't benefit anything from an external processor graphics wise. Might be helpful for sound, like Pitfall II, to have an external processor... but you're right, it's better to deal with the Atari when you're dealing with the Atari.

 

~Blackbird

[Thomas Jentzsch]

Before creating new hardware, maybe us homebrewers should first start exploring the capabilities of the Pitfall 2 chip. At least using that would be as "authentic" as e.g. using the SuperCharger RAM.

 

How complicated would it be, to produce new boards based on that chip?

[Nukey Shay]

But that would also make it more difficult to produce actual homebrew cartridges, right?

[EricBall]

Before creating new hardware, maybe us homebrewers should first start exploring the capabilities of the Pitfall 2 chip. At least using that would be as "authentic" as e.g. using the SuperCharger RAM.

 

How complicated would it be, to produce new boards based on that chip?

 

I belive the Pitfall 2 chip was made like most of the other bankswitched games: with the control logic included as part of the masked ROM. So you can't re-use a Pitfall 2 chip, since there is no way to modify the ROM parts of the chip or reuse the control logic.

 

However, there is no reason that you couldn't put the logic (documented in the patent) into a modern FPGA, and put that into a cartridge along with the code and graphics EPROMs. (See the Cuttle Cart for an example of what an FPGA can do & cost.)

 

Patent #4,644,495 is an interesting read. However, some features almost require a disassembly of Pitfall 2 to understand how to use them. But my guess is, other than the sound oscillators, the features are only applicable to some games and would be useless in most cases.

 

Supercharger games are an untapped market too.

[tearex]

Patent #4,644,495 is an interesting read.  However, some features almost require a disassembly of Pitfall 2 to understand how to use them.  But my guess is, other than the sound oscillators, the features are only applicable to some games and would be useless in most cases.

 

If you're interested, it's online at:

 

http://patft.uspto.gov/netacgi/nph-Parser?...5&RS=PN/4644495

 

It's partially pretty heavy "patentese" but it is certainly interesting.

[SmileyDude]

You know, the idea might seem dumb, but it actually has some merit -- you are still able to plug your cart into any Atari 2600 out there, and play a game that would've been impossible without any outside assistance.

 

This is another variation along the lines of Andrew's ChronoColor demo -- it's something that just would not have been possible to pull off back when the 2600 was in it's heyday, but now with the powerful PCs we have for development, emulators for debugging, and the ability to build carts with virtually unlimited amounts of storage, we can do so much more with it.

 

BTW, Andrew, I'm not trying to trivialize your effort -- there is obviously a lot of skill and thought that goes into your code. And, from what I understand of tearex's idea, someone would still need that skill to do anything worthwhile on this.

 

Personally, I would love to be able to have a cart that had a modern CPU in it (ARM based? ) that could feed the 2600... that would be pretty neat to play with. You still have to deal with limitations of the 2600, so it's not like you're going to be able to have really modern looking games, but it does give you some more power to do some neat stuff with the 2600.

 

Heck, I would settle for another 6502 that could work in tandem with the CPU -- maybe have some dedicated RAM/ROM for the cart 6502, and then some RAM that would be available for code to run on the 6507 in the 2600. At least this way, it would satisfy the purists, because everything on the cart was at least out when the 2600 was being produced

[mos6507]

Well, given that the Atari 8-bits employed the concept of having a separate processor to "feed" a TIA (ANTIC driving GTIA) then it's not that unreasonable to investigate coprocessor like technology for the 2600.

 

The DPC chip is the perfect example of this, as it almost makes the 2600 into a sort of Atari 8-bit lite.

 

It's remarkable what can be accomplished when some of the timing restrictions are removed from 2600 kernels! It's pretty much impossible to drive a full asymmetric display and all 5 sprites at single scanline precision. So some of the TIA's output goes wasted all of the time.

 

The Supercharger helps also by being able to store strips of RAM for the kernel, extending beyond the 1-D-ness of the TIA kernel.

 

 

(I'd like to see what could be done with a 6502 running at 3X. There were some experiments done by someone on Stellalist and the concensus was that it wouldn't work...)

 

 

I'm not so much into putting a powerful processor on a cart, but something akin to a combination of a Supercharger (so that all the memory is read/write) and the DPC (which does all that nice auto-indexing of ROM addresses) would enable some amazing kernels.

[EricBall]

(I'd like to see what could be done with a 6502 running at 3X.  There were some experiments done by someone on Stellalist and the concensus was that it wouldn't work...)

 

FYI, the 6502C in the 7800 runs 50% faster than the 6507 in the 2600 (1/2 colorburst, 1.78MHz vs 1/3 colorburst, 1.19MHz), but it drops back to 1.19MHz when accessing the TIA (which the 7800 uses for sound & paddles/buttons and 2600 compatibility mode).