Atari 2600++ Programmer's Hardware Wish List

[bigmessowires]

After experimenting with 2600 programming for a while, I have some hardware wish-list items for an "Atari 2600++". These are extra hardware features in the TIA or 6507 that I think could have been do-able with only a modest increase in hardware cost and complexity. Think of these as ideas for what Atari and MOS might have done if they'd had a slightly bigger budget. What else would you add to this list?

 

TIA

 

CDELP0/CDELP1 - Like VDEL, but for player color changes.

PF3 and PF4 registers - With five 8-bit playfield registers, you could have an asymmetric playfield all the time!

COLUM0/M1/BL - Independent colors for the missiles and ball. Or at least one extra color, applied to all three.

LINENO - A hardware line counter, resets during VSYNC, increments after every line.

XP0,XP1,XM0,XM1,XBL - A direct way to set the X position. I understand TIA implements these as LFSRs and not standard binary registers, but even if we had to use a table lookup to get the necessary LFSR value, it would be so much nicer to stuff in an X value than to suffer through RESxx and HMxx and HMOVE.

 

 

6507

 

ADD/SUB - Add or subtract without carry (add) or with carry (sub). Avoids needing to CLC/SEC everywhere.

mem.A address mode - Variant of INC/DEC/ASL/LSR/ROL/ROR that operates on memory but also leaves the new value in the accumulator. The existing instructions already have to load the value from memory anyway, and modify it, so why not stick the value in A while also writing it back to memory?

STZ, INC/DEC accumulator - these were all added in the 65C02

 

[glurk]

The 6809 processor has a thing called 'direct page' which is like zero page, but can be set from $00-$FF to allow ANY page to be the zero page.  This would be useful for slightly faster addressing of ROM data in kernels.

 

Actually, the 6809 has a TON of things that would be nice features if wishes were horses and all that...

[+splendidnut]

Anytime someone talks about improving the TIA... it always reminds me of the Atari 8-bit chipset, where players/missiles were doubled and playfield capabilities were greatly expanded.  I think that chipset would take care of about 3, maybe 4 out of the 5 things on your TIA expansion list.

 

From your list, being able to directly set the X position is the big one... but that was really due to the type of counters they used to save chip space.  The team addressed that issue with the 8-bit chipset.

 

I think the two things that would have made the greatest impact would have been:

   - increased CPU speed (1.79mhz like the rest of the Atari 8-bits).

   - more built-in RAM (like 128 bytes more -> built-in Superchip without the separate R/W areas)

 

But, those were more likely time-frame oriented... if the 2600 would have come out a year or two later, those might have been a given.

 

 

[+Gemintronic]

Maybe a board that takes a Raspberry Pi Pico for ROM, RAM and SaveKey support.

[bigmessowires]

3 hours ago, splendidnut said:

more built-in RAM

I'd never say no to more RAM! But so far, I've been surprised that RAM isn't the major limitation that I imagined it would be. The main challenge is not enough time during a scan line to do all the things I'd like to do, and especially not enough time during HBLANK to update TIA registers without creating visible glitches. Imagine if all the color and graphics register updates could be optionally delayed until the next HBLANK period... that would be sweet.

[+Pat Brady]

15 hours ago, splendidnut said:

Anytime someone talks about improving the TIA... it always reminds me of the Atari 8-bit chipset, where players/missiles were doubled and playfield capabilities were greatly expanded.  I think that chipset would take care of about 3, maybe 4 out of the 5 things on your TIA expansion list.

 

From your list, being able to directly set the X position is the big one... but that was really due to the type of counters they used to save chip space.  The team addressed that issue with the 8-bit chipset.

 

I think the two things that would have made the greatest impact would have been:

   - increased CPU speed (1.79mhz like the rest of the Atari 8-bits).

   - more built-in RAM (like 128 bytes more -> built-in Superchip without the separate R/W areas)

 

But, those were more likely time-frame oriented... if the 2600 would have come out a year or two later, those might have been a given.

 

I'm a bit annoyed at how much time I've wasted thinking about this particular alternative history, where instead of the 8-bit computers Atari made a 2600 plus that was compatible with 2600 games.

 

A few things could have been done without redesigning any of the big chips, and making compatibility mode relatively easy to implement:

1. The easiest thing: add more address pins and a R/W line to the cart connector (a la 7800). Allows bigger ROMs without bankswitching, and bigger banks with it.
2. Increased CPU speed, like you said. Even the modest bump to 1.79 MHz would make a big difference for the 2600 because you could do much more in the kernel.
3. Increased RAM, like you said. 128 bytes at $180 is the most obvious one, which would decouple the stack from zero page. Beyond that, put more 128-byte blocks at other mirrors, and/or put 1 or 2K at $800.
4. Add an ADC for paddles, so the kernel doesn't have to read them (admittedly this was not a widely-used feature in the 8-bit computers AFAIK).

Those 4 things (or just the first 3) would be a *huge* upgrade IMO.

 

Further into fantasy territory is a "TIA Plus" that might be implementable with a compatibility switch. My wishlist:

1. Allow full-width playfield using the other 4 bits of PF2 and mirrored addresses of PF0-1.
2. Provide 4 player sprites and 4 missiles, using mirrored addresses (which kind of explodes the collision detectors, so may need to be clever about that).
3. Improve audio (which gets the most detail here because it's what I know the most about):
   1. Increase frequency counters to 6, 7, or 8 bits.
   2. Tweak the distortion definitions to account for the higher resolution.
   3. Provide a few more distortion settings (5, 9, 10, and 13 are currently redundant), ideally at octave intervals (useful and easy to implement) of existing settings.
   4. Provide 1 or 2 more channels using the mirrored addresses.
   5. Increase dynamic range to 5, 6, 7, or 8 bits.

Redesigning the 6502/6507 is too far out for me to think about.

 

EDIT: not annoyed at anybody here, I thought about all that before yesterday.

[bigmessowires]

These are all great ideas!

 

Was a 1.79 MHz clock possible at the time? I would have assumed Atari went with the fastest CPU they could get, but I don't know what the incremental cost would have been for going faster. If they increased the speed they would have needed a faster spec'd PIA as well as faster 6507, not sure about the TIA.

 

Including the R/W signal at the cartridge connector seems like it should have been a no-brainer if Atari could have anticipated future technology trends, and would have cost them virtually nothing in manufacturing costs.

 

As I understand it, the cartridge connector already has every address signal the 6507 offers (A0 through A12), so it wouldn't be possible to add more unless you also replaced the 6507 with a 6502. The 4K limitation comes from the 2600's memory map, which defines anything with A12=1 as ROM and anything with A12=0 as either TIA or PIA. To free up more address space for ROM, the Atari would need more complex internal address decoding logic for both the TIA and PIA. And the designers were probably trying to shave costs on that. But the extra logic could have been something as simple as an extra OR gate.

 

How about this idea: The PIA has two 8-bit bidirectional I/O ports. In normal use PORTB (SWCHB) is configured as eight inputs, but only five are actually used for the console switch inputs, so there are three PORTB pins unused. These could be configured by software as outputs, and routed to the cartridge connector to be used as additional optional address signals. For only the cost of routing three extra traces on the PCB, Atari could have provided built-in 8-way bank switching by writing to SWCHB with mask X X B2 B1 X B0 X X. I checked the data sheet to confirm that writing to PIA input registers has no effect, so this would be perfectly safe. You wouldn't even need pull-up resistors for B2,B1,B0 to handle the start-up condition before they were configured as outputs, because PIA inputs already have a weak pull-up. It's perfect!

 

 

[+splendidnut]

46 minutes ago, bigmessowires said:

Was a 1.79 MHz clock possible at the time? I would have assumed Atari went with the fastest CPU they could get, but I don't know what the incremental cost would have been for going faster. If they increased the speed they would have needed a faster spec'd PIA as well as faster 6507, not sure about the TIA.

The original CPU speed was geared towards the 1Mhz mark.  In 1979, the Atari 8-bit had a 1.79mhz 6502.  If by "at the time" you mean 1976/1977 exactly, the answer might have been no, Wait a couple of years. 

 

TIA ran at the system / color clock speed of 3.58mhz, so there might not have been any issue interfacing to a 1.79mhz CPU.  There was some experimenting done with changing the CPU speed a few years back (wow, over 10 years ago) that you might want to give a read thru:  https://forums.atariage.com/topic/201304-overclocking-the-2600-with-a-wdc65c02/

That's something I've always wanted to experiment with... but my breadboard is currently full with a TTL-chip based NTSC video experiment.

 

1 hour ago, bigmessowires said:

Including the R/W signal at the cartridge connector seems like it should have been a no-brainer if Atari could have anticipated future technology trends, and would have cost them virtually nothing in manufacturing costs.

Having more cartridge pins is a wishlist item that Joe Decuir, one of the original engineers, talks about whenever he gives a presentation on his Atari/Amiga engineering work.  Apparently it would have cost only a couple of cents.  That would have given the option to provide a R/W line, clock signal, and/or extra address pins. 

 

1 hour ago, bigmessowires said:

How about this idea: The PIA . . .

Using the PIA is an interesting idea, but if you're going to be changing the cartridge connector anyways to support that, you might as well swap out the 6507 for a 6502 also.

 

If planned for when designing a program, bank-switching really isn't that big of an issue to deal with.

[+splendidnut]

18 hours ago, Pat Brady said:

Improve audio (which gets the most detail here because it's what I know the most about):

1. Increase frequency counters to 6, 7, or 8 bits.
2. Tweak the distortion definitions to account for the higher resolution.
3. Provide a few more distortion settings (5, 9, 10, and 13 are currently redundant), ideally at octave intervals (useful and easy to implement) of existing settings.
4. Provide 1 or 2 more channels using the mirrored addresses.
5. Increase dynamic range to 5, 6, 7, or 8 bits.

 

So, a POKEY chip? 

 

I think that's a great idea though because, IF the TIA had those features, then the 7800 would have had much better audio in the base system.

[+Gemintronic]

How about making this like an Aladdin Deck Enhancer or Sega 32x?

 

I mean, why not use the base 2600 instead of adding to the bom?

[Prizrak]

Part of me feels like that's what the ARM carts are doing. Like strapping a 32x type attachment to our system. I'm blown away by what modern chips can add to a 40 yr old system.

[orange808]

"Just enhance" the missiles and ball with unique images. It's okay if the additional sprites share colors with P1, P2, and PF. All I want is VDEL and a unique image register for all three of the additional "sprites" (the ball already has VDEL). Maybe the "image" register for the missiles/ball would default to 255? That would allow legacy software to function normally.

 

Unique missiles and ball images would add a lot. That VDEL for the missiles would also really help.

 

That would open a lot of possibilities:  a ton of them.

 

"Just enhance" is in quotes for a reason. I understand the incredible amount of complexity that would add. I imagine changes could also mess up a lot of new complex kernels that run at the absolute far edges of TIA's capabilities. As is, TIA is a marvelously intricate, complicated, and elegant design.

 

While "bitmap kernels" are not the primary use case, the additional bitmap kernel options with ARM would probably trigger and upset a lot of people--and bring down a sh*tstorm of nerd rage. The machine would be pure evil. 🤣

[+Pat Brady]

7 hours ago, bigmessowires said:

Was a 1.79 MHz clock possible at the time? I would have assumed Atari went with the fastest CPU they could get, but I don't know what the incremental cost would have been for going faster. If they increased the speed they would have needed a faster spec'd PIA as well as faster 6507, not sure about the TIA.

 

In my imagining, this 2600 Plus would have happened in the early 1980s, when a 6502 at 1.79 MHz should have been feasible.

 

I forgot another important and easy enhancement: a 2- or 3-button standard controller.

 

Even without any TIA enhancements, a 2600 with a faster clock, more RAM, bigger banks, and a multi-button controller would have been a significant upgrade.

 

6 hours ago, splendidnut said:

So, a POKEY chip? 

 

Similar to POKEY in capability, but different in design, based more directly on (and remaining compatible with) TIA.

 

[Mr SQL]

On 2/10/2023 at 1:45 PM, splendidnut said:

Anytime someone talks about improving the TIA... it always reminds me of the Atari 8-bit chipset, where players/missiles were doubled and playfield capabilities were greatly expanded.  I think that chipset would take care of about 3, maybe 4 out of the 5 things on your TIA expansion list.

 

Agree Atari had a great approach. My idea to expand the TIA using a soft blitter for display lists was similarly inspired by the A8 ANTIC architecture.
 

16 hours ago, Pat Brady said:

 

In my imagining, this 2600 Plus would have happened in the early 1980s, when a 6502 at 1.79 MHz should have been feasible.

 

23 hours ago, orange808 said:

"Just enhance" the missiles and ball with unique images. It's okay if the additional sprites share colors with P1, P2, and PF. All I want is VDEL and a unique image register for all three of the additional "sprites" (the ball already has VDEL). Maybe the "image" register for the missiles/ball would default to 255? That would allow legacy software to function normally.

 

Unique missiles and ball images would add a lot. That VDEL for the missiles would also really help.

 

That would open a lot of possibilities:  a ton of them.

 

"Just enhance" is in quotes for a reason. I understand the incredible amount of complexity that would add. I imagine changes could also mess up a lot of new complex kernels that run at the absolute far edges of TIA's capabilities. As is, TIA is a marvelously intricate, complicated, and elegant design.

 

While "bitmap kernels" are not the primary use case, the additional bitmap kernel options with ARM would probably trigger and upset a lot of people--and bring down a sh*tstorm of nerd rage. The machine would be pure evil. 🤣

 

Great ideas! I implemented something along these lines to tilemap the playfield and background graphics with PETSCII bitmaps for my software implementation of a Super Atari, basically an Atari emulator for the C64 to allow many of the options discussed on this thread using retro technology from 1982.

 

Check out this enhanced version of Arkanoid using PETSCII bitmaps on the boards.
 

Like soft ANTIC, the RIOT, TIA and Atari system bus are also in software allowing Atari programs to run on the Commodore 64 with extra functionality accessible including the PIA, VIC-II and SID.

 

This software Super Atari is available for download here with SuperCharger BASIC programming examples for the C64 and Atari 2600.

 

[Sohl]

On 2/10/2023 at 1:21 PM, bigmessowires said:

TIA

 

CDELP0/CDELP1 - Like VDEL, but for player color changes.

PF3 and PF4 registers - With five 8-bit playfield registers, you could have an asymmetric playfield all the time!

COLUM0/M1/BL - Independent colors for the missiles and ball. Or at least one extra color, applied to all three.

LINENO - A hardware line counter, resets during VSYNC, increments after every line.

XP0,XP1,XM0,XM1,XBL - A direct way to set the X position. I understand TIA implements these as LFSRs and not standard binary registers, but even if we had to use a table lookup to get the necessary LFSR value, it would be so much nicer to stuff in an X value than to suffer through RESxx and HMxx and HMOVE.

 

I would love to have XPx to directly set the X positions, even if we need to use the direct LFSR values to do so.  The other things you list for TIA would be nice too.  

For the 6507, a "load accumulator with one of two options, based on a condition flag" instruction would be great.  I think there is an undocumented one that sort of works, but maybe has some other side-effect or limitation.