5 things u wished the 5200 had

[atariksi]

2. More ports of games from the 8-bit computer line over to the 5200. If RAM was an issue, then "dumb down" the games a tad to fit, or add in extra ram on the cart. More original titles would have helped out too. So, to break it down, MORE GAMES.

I do believe the vast majority of cartridge based atari 8-bit games worked with 16 kB (a fair chunk must have worked in 8 kB if they wanted to include the lowest common denominator -non-upgraded early 400/800 adopters).

...

You could add ROM easily to the cartridge like BBSB. However, if you use a battery and upload via some interface with Atari 8-bit computers or A5200 expansion port, they could have used SRAM as well.

[etschuetz]

2. More ports of games from the 8-bit computer line over to the 5200. If RAM was an issue, then "dumb down" the games a tad to fit, or add in extra ram on the cart. More original titles would have helped out too. So, to break it down, MORE GAMES.

I do believe the vast majority of cartridge based atari 8-bit games worked with 16 kB (a fair chunk must have worked in 8 kB if they wanted to include the lowest common denominator -non-upgraded early 400/800 adopters).

 

ditch the controller compartment for a 2600 slot.

I think it'd be most efficient to use a single slot like the 7800 with added outboard pins.

 

4. Not going with the "all-in-one" switch box/power and just going with the standard power port and switch box like the 2 port variation.

I would assume that's due to reliability and cost; otherwise having that auto switchbox is quite convenient (the later mechanism used by Nintendo etc, was superior, granted). However, the biggest pain was simply having to reach behind the TV to switch -depending on your set-up, but that might have been solved with a switchbox with a long cable on the output side to allow for more flexible placement of the box. (not sure why the mechanism Nintendo used a couple years later wasn't yet practical though -or maybe they just hadn't though of it yet)

I'm not sure when TVs/VCRs started including composite video/audio ports, but if even high-end TVs had RCA AV inputs by 1980, that would be enough to merit the 5200 including them (possibly using a similar DIN connector to the A8 computers).

 

5. I would have liked it if Atari would have taken real time on the console to perfect everything that was put in to it. If that would have happened, perhaps an extra 6 months to a year development time, it would have been the savior of the 84 crash. A system with the power of a computer, but the accessibility of a console gaming system.

Weak hardware had nothing to do with the 83 crash though, it was overinflation of the market largely tied to mismanagement at Atari/Warner -an oversimplification though. (commodore's price war had a huge catalyzing effect too)

 

The A8 hardware was fine for the time, nothing wrong with it, though the 5200 was a bit of a muddled/rushed mess in hardware terms. (probably for a number of reasons including the management issues and interdivision relationships at atari)

 

Quite honestly, for the flaws the 5200 had, it gave it character. It was big, powerful, and had great games. It was the simple mindedness of consumers that really hampered the console then. They wanted to have the Atari 2600 but with better graphics. I also blame Atari for not pushing developers over to the 5200 and begin the death phase of the 2600.

Not sure that's quite how it was, the market was confused in part by the large number of emerging platforms (granted, the main ones established were VCS, Intellivision, CV, and 5200, but then the Arcadia and Vectrex popped up -and previous competitors had already fallen behind I think), but on top of that were home computers with ever encroaching price points.

I'm not sure what "have the 2600 with better graphics" means though, do you mean a fully compatible upgraded console, an upgrade module for the VCS, enhancement hardware on-cart, what? (the latter was done with the DPC chip used in Pitfall II, of course)

 

Now as to pushing developers to the 5200 (or resources in general), I'd agree, and pushing to both the 5200 and A8-bit makes sense (similar architecture), but "begin the death phase" of the 2600 would have been crazy to do at the time, even in hind sight, let alone in the context of 1982! Now, shifting the 2600's market position perhaps, yes, but regardless they 2600 should have continued to be suppored as long as profitable, so continue selling but with fewer new games and less advertising and pushing more to the budget market well into the late 1980s. All big successful platforms end up this way, NES, SNES, Genesis, SMS (in Europe and Brazil), PSX, and especially PS2; all last a long time past their prime. (look at the PS2, still in production 10 years after being launched)

 

You made some great points. Leaving the 2600 alive would have been a fine idea even then, but definitely market it as the "Budget System". The console that plays games. Market the 5200 as the next evolution of "Interactivity and Excitement".

 

I think that if Atari would have managed the 5200 a lot better, it would have lasted up to the release of the NES. It would have also had a large number of developers behind it up to that time. Given that, I think any new console released after the 5200 (i.e. the 7800 we dream about) would have out done what Nintendo released. Atari was in the business of producing great merchandise and pushing research and development. Of course, hindsight.

[kool kitty89]

I do believe the vast majority of cartridge based atari 8-bit games worked with 16 kB (a fair chunk must have worked in 8 kB if they wanted to include the lowest common denominator -non-upgraded early 400/800 adopters).

You could add ROM easily to the cartridge like BBSB. However, if you use a battery and upload via some interface with Atari 8-bit computers or A5200 expansion port, they could have used SRAM as well.

To be clear, I was talking about onboard RAM of 16 kB (or 8 kB in early, stock 400s and 800s), cartridges could obviously be larger, with no hard limit with bank switching. (ROM costs would be the main limiting factor)

With the battery backed sram comment, are you referring to use for game saves?

 

 

You made some great points. Leaving the 2600 alive would have been a fine idea even then, but definitely market it as the "Budget System". The console that plays games. Market the 5200 as the next evolution of "Interactivity and Excitement".

That's pretty much what happened with the 2600 Jr with the 7800 4 years later, under Atari Corp. Though, the 7800 its self was in the budget category too to some extent (much cheaper than the competition), with the Jr in the super budget category; this ignores the XEGS though.

 

I think that if Atari would have managed the 5200 a lot better, it would have lasted up to the release of the NES. It would have also had a large number of developers behind it up to that time. Given that, I think any new console released after the 5200 (i.e. the 7800 we dream about) would have out done what Nintendo released. Atari was in the business of producing great merchandise and pushing research and development. Of course, hindsight.

If the 5200 had become reasonably established, it should have lasted well into the NES years (of course being relegated to budget console with the successor released -probably by '87 or '88).

But bringing the NES in at all is total conjecture in such a hypothetical discussion, had the crash been avoided or significantly reduced in severity, Nintendo would have faced much stronger competition (granted, that also would have if Warner had kept A.Inc and Morgan had completed his reorganization).

But say that, other than the 5200 being a bit cleaner and more successful and Atari shifted more to the 5200 (and possibly computers), with the outstanding management and numerous other problems in the company, combined by the strong catalyst of Commodore's price war with TI (and general drop in home computer prices), the crash would still have happened. However, the 5200 would have been in a better position to survive the crash and the 7800 wouldn't have existed, at least as it was. GCC may still have presented a design to Warner, but it may have ended up being modified for use as a later machine.

Edited March 27, 2010 by kool kitty89

[atariksi]

I do believe the vast majority of cartridge based atari 8-bit games worked with 16 kB (a fair chunk must have worked in 8 kB if they wanted to include the lowest common denominator -non-upgraded early 400/800 adopters).

You could add ROM easily to the cartridge like BBSB. However, if you use a battery and upload via some interface with Atari 8-bit computers or A5200 expansion port, they could have used SRAM as well.

To be clear, I was talking about onboard RAM of 16 kB (or 8 kB in early, stock 400s and 800s), cartridges could obviously be larger, with no hard limit with bank switching. (ROM costs would be the main limiting factor)

With the battery backed sram comment, are you referring to use for game saves?

...

The original person was claiming in porting 8-bit computer stuff to A5200, one can add RAM, but that's not true since there's not R/W signal on Cartridge connector of A5200. But you can add battery-backed SRAM (but it would act like ROM); it would just have to be uploaded via some other machine or via the expansion port. Yeah, there are games on 8-bit computer that use up more than 16K RAM.

[kool kitty89]

You could add RAM they same way they did with the VCS... with a hack, sacrificing an address pin (in that case) to use as a read/write pin. (just as an address pin had to be used as ROM enable by default) In another discussion it was mentioned that the read/write issue was the simple problem to fix, the tough one was lack of a Phi2 line. (which the early 5200s also lacked stock, I think -later added to facilitate the VCS adapter) The A800 has both R/W and Phi2 on the cart port.

This discussion: http://www.atariage.com/forums/topic/147026-was-there-a-reason-why-atari-limited-the-memory-size-of-2600-games/page__view__findpost__p__1793339

 

It's not like the 5200 cartridge didn't have a bunch of unused/redundant pins that could have added R/W among other things. (hence why 3 new inputs were easily added) Even after the 2-port model additions, there's still 2 unconnected pins and 3 gnd lines. (not sure what pins 18 and 36 are for -listed as "interlock")

Edited March 28, 2010 by kool kitty89

[atariksi]

You could add RAM they same way they did with the VCS... with a hack, sacrificing an address pin (in that case) to use as a read/write pin. (just as an address pin had to be used as ROM enable by default) In another discussion it was mentioned that the read/write issue was the simple problem to fix, the tough one was lack of a Phi2 line. (which the early 5200s also lacked stock, I think -later added to facilitate the VCS adapter) The A800 has both R/W and Phi2 on the cart port.

This discussion: http://www.atariage.com/forums/topic/147026-was-there-a-reason-why-atari-limited-the-memory-size-of-2600-games/page__view__findpost__p__1793339

 

It's not like the 5200 cartridge didn't have a bunch of unused/redundant pins that could have added R/W among other things. (hence why 3 new inputs were easily added) Even after the 2-port model additions, there's still 2 unconnected pins and 3 gnd lines. (not sure what pins 18 and 36 are for -listed as "interlock")

 

Where's the discussion on how they use an address pin as r/w pin? Seems like an interested and complex hack. Interlock is used for hot-swapping cartridges on A5200 so that you can mount your A5200 underneath the desk with hole for putting in cartridges and never have to turn off the unit (ideally).

[kool kitty89]

Where's the discussion on how they use an address pin as r/w pin? Seems like an interested and complex hack. Interlock is used for hot-swapping cartridges on A5200 so that you can mount your A5200 underneath the desk with hole for putting in cartridges and never have to turn off the unit (ideally).

It's in the thread I posted: http://www.atariage.com/forums/topic/147026-was-there-a-reason-why-atari-limited-the-memory-size-of-2600-games/page__p__1793339#entry1793339

 

And a number of things were mentioned, not just read/write, like A12 being sacrificed as a chip select line in normal usage. (and there's actually a wasted pin on the cart: "shield ground" apparently provided with the intention of a built-in game -activated with no cart plugged in) Plus lots of stuff regarding bank switching.

 

But to point out the specific posts:

However, the connections between the chip selects and the address lines must be taken into consideration, too. It takes only one address line to distinguiish between the upper 4K and the lower 4K of an 8K address space, so if you "sacrifice" pin A12 for that purpose, you can have a 4K cartridge area, and the other 4K could be used for other things-- onboard registers, onboard RAM, or even onboard ROM.

Just a quick note to clarify the 2600 cart port usage. There are 13 adress lines, 8 data lines, a +5v power line, and 2 ground lines for a total of 24. The dual ground lines were to support the planned but unused built in ROM feature of the console. Note that there is no clock, or chip enable, or read/write line. The decision to omit these was based on a cost savings of 50 cents in the edge connector. (And it was later considered by the designers to be a huge mistake. ) These missing control lines limit cartridges to ROM only without the addtion of extra logic in the cart. And because there is no cart enable line, one of the 6507's address lines is sacrificed for that function. That's why it's a 4kB ROM space max instead of 8kB.

So, had they not reserved the pin for the second ground they could have used the full 13-bit address bus. (or added a read/write line)

How did they manage to include on-cart RAM expansion w/out a read/write line?

There were different methods used. The simplest was to use yet another address line. So for example addresses $000~0FF would be used as the write port and addresses $100~1FF would be the read port, using A8 as the read/write line. Additional logic in the cartridge would be used to time the necessary signals locally.

It's not just the R/W line but the lack of phi2 that makes adding RAM to a lot harder than just switching banks. I'm not sure what cwlikson meant by "not that hard" but it is a lot harder than bankswitching. Certainly it's not an amazingly difficult problem but it is not trivial.

 

The lack of R/W line is easily worked around by having separate address for reads and writes. But, no phi2 signal means that you have to use accurately timed circuitry to simulate phi2 to hit the small window where data is valid for writing between cycles. Worse, there are actually two windows you need to hit as some instructions write on the first cycle and some write on the second.

 

Alternatively you can latch the address bus on writes and wait for the address to change, then grab the data and use the latched address to know where to write it. This method requires much more hardware than regular bankswitching.

 

Also, neither of the above RAM methods can be gleaned from simply examining 6507 datasheets. Atari had to do experiments to figure out the timing.

 

The document here shows some of the research done. Although this was done for the 2600 computer add-on, as I understand the research ultimately resulted in the SARA chip:

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

 

That last quote is the most relevant to the RAM issue.

Edited March 29, 2010 by kool kitty89

[atariksi]

Where's the discussion on how they use an address pin as r/w pin? Seems like an interested and complex hack. Interlock is used for hot-swapping cartridges on A5200 so that you can mount your A5200 underneath the desk with hole for putting in cartridges and never have to turn off the unit (ideally).

It's in the thread I posted: http://www.atariage.com/forums/topic/147026-was-there-a-reason-why-atari-limited-the-memory-size-of-2600-games/page__p__1793339#entry1793339

 

And a number of things were mentioned, not just read/write, like A12 being sacrificed as a chip select line in normal usage. (and there's actually a wasted pin on the cart: "shield ground" apparently provided with the intention of a built-in game -activated with no cart plugged in) Plus lots of stuff regarding bank switching.

 

But to point out the specific posts:

However, the connections between the chip selects and the address lines must be taken into consideration, too. It takes only one address line to distinguiish between the upper 4K and the lower 4K of an 8K address space, so if you "sacrifice" pin A12 for that purpose, you can have a 4K cartridge area, and the other 4K could be used for other things-- onboard registers, onboard RAM, or even onboard ROM.

Just a quick note to clarify the 2600 cart port usage. There are 13 adress lines, 8 data lines, a +5v power line, and 2 ground lines for a total of 24. The dual ground lines were to support the planned but unused built in ROM feature of the console. Note that there is no clock, or chip enable, or read/write line. The decision to omit these was based on a cost savings of 50 cents in the edge connector. (And it was later considered by the designers to be a huge mistake. ) These missing control lines limit cartridges to ROM only without the addtion of extra logic in the cart. And because there is no cart enable line, one of the 6507's address lines is sacrificed for that function. That's why it's a 4kB ROM space max instead of 8kB.

So, had they not reserved the pin for the second ground they could have used the full 13-bit address bus. (or added a read/write line)

How did they manage to include on-cart RAM expansion w/out a read/write line?

There were different methods used. The simplest was to use yet another address line. So for example addresses $000~0FF would be used as the write port and addresses $100~1FF would be the read port, using A8 as the read/write line. Additional logic in the cartridge would be used to time the necessary signals locally.

It's not just the R/W line but the lack of phi2 that makes adding RAM to a lot harder than just switching banks. I'm not sure what cwlikson meant by "not that hard" but it is a lot harder than bankswitching. Certainly it's not an amazingly difficult problem but it is not trivial.

 

The lack of R/W line is easily worked around by having separate address for reads and writes. But, no phi2 signal means that you have to use accurately timed circuitry to simulate phi2 to hit the small window where data is valid for writing between cycles. Worse, there are actually two windows you need to hit as some instructions write on the first cycle and some write on the second.

 

Alternatively you can latch the address bus on writes and wait for the address to change, then grab the data and use the latched address to know where to write it. This method requires much more hardware than regular bankswitching.

 

Also, neither of the above RAM methods can be gleaned from simply examining 6507 datasheets. Atari had to do experiments to figure out the timing.

 

The document here shows some of the research done. Although this was done for the 2600 computer add-on, as I understand the research ultimately resulted in the SARA chip:

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

 

That last quote is the most relevant to the RAM issue.

 

But then code would have to reside always in space where A8=1 in RAM or be unused space in ROMs since CPU fetches would cause writes otherwise.

[Crazyace]

The address line isn't always used as a R/W - it's limited to a small address range.

 

So for a 5200 cart you could have rom/ram mapped like this:

 

4000-4fff: 4K ram bank read

5000-5fff: 4k ram bank 'write' alias

6000-7fff: 8k rom/ram bank A (read only)

8000-9fff: 8k rom/ram bank B (read only)

a000-bfff: Fixed 8k rom bank

 

and place rom / ram bank signal around bfxx, maybe like this

 

bf00-bf7f: 4k area mapped to ram ( bank 0-3e, lo/hi 4k )

bf80-bfbf: 8k area mapped to bank A area ( bank 0-3e )

bfc0-bfff: 8k area mapped to bank B area ( bank 0-3e )

 

This would support a cart up to 512K , split anyway between Ram/Rom

[Crazyace]

..that might not be correct for the 5200 startup sequence though, but the general idea is the same

[atariksi]

The address line isn't always used as a R/W - it's limited to a small address range.

 

So for a 5200 cart you could have rom/ram mapped like this:

 

4000-4fff: 4K ram bank read

5000-5fff: 4k ram bank 'write' alias

6000-7fff: 8k rom/ram bank A (read only)

8000-9fff: 8k rom/ram bank B (read only)

a000-bfff: Fixed 8k rom bank

 

and place rom / ram bank signal around bfxx, maybe like this

 

bf00-bf7f: 4k area mapped to ram ( bank 0-3e, lo/hi 4k )

bf80-bfbf: 8k area mapped to bank A area ( bank 0-3e )

bfc0-bfff: 8k area mapped to bank B area ( bank 0-3e )

 

This would support a cart up to 512K , split anyway between Ram/Rom

 

So if I have an instruction sequence at $4000: LDA #$6C; STA $5800; LSR $5800.

 

The A12 would be r/w line and would be "1" only for 1 cycle of the 4 cycles STA takes. So it looks like you need some complex/fast decoder circuit on the cart to implement your above scheme. And how would LSR work which requires a read and write?

[Lynxpro]

Since this thread originally had to do with "things" we wished the 5200 had, I'd say "a lower starting MSRP" plus standard 2600 compatibility. That is what kept my parents from buying one even though my dad and I both wanted it.

[Crazyace]

 

So if I have an instruction sequence at $4000: LDA #$6C; STA $5800; LSR $5800.

 

The A12 would be r/w line and would be "1" only for 1 cycle of the 4 cycles STA takes. So it looks like you need some complex/fast decoder circuit on the cart to implement your above scheme. And how would LSR work which requires a read and write?

 

The LSR wouldn't work as it's accessing a write only address with a read. ( Although there were some VCS bank switching schemes that might have allowed that )

The logic isn't completely trivial, but people already had these schemes working on 2600 cartridges.

 

In my opinion though, the 5200 actually has enough memory for almost any game on the 8 bit, especially if you add extra massive amounts of bank switched rom.

[atariksi]

 

So if I have an instruction sequence at $4000: LDA #$6C; STA $5800; LSR $5800.

 

The A12 would be r/w line and would be "1" only for 1 cycle of the 4 cycles STA takes. So it looks like you need some complex/fast decoder circuit on the cart to implement your above scheme. And how would LSR work which requires a read and write?

 

The LSR wouldn't work as it's accessing a write only address with a read. ( Although there were some VCS bank switching schemes that might have allowed that )

The logic isn't completely trivial, but people already had these schemes working on 2600 cartridges.

 

In my opinion though, the 5200 actually has enough memory for almost any game on the 8 bit, especially if you add extra massive amounts of bank switched rom.

 

But the full-screen interlaced graphics required 16K+ RAM especially with overscan. And then you need RAM for PM graphics stuff as well although you can use up tons of ROM space and have every combination of sprite in ROM and just toggle banks.

[kool kitty89]

Since this thread originally had to do with "things" we wished the 5200 had, I'd say "a lower starting MSRP" plus standard 2600 compatibility. That is what kept my parents from buying one even though my dad and I both wanted it.

 

Umm, with the existing design, those 2 things are very mutually exclusive. Integrated VCS compatibility would have meant tacking on the VCS hardware for little to no other use, simply adding to board space and cost.

 

Simplest cost reduction as things were, would have been to use a case as minimalistic as possible, pretty much what the 5200 Jr/5100 did, though that wouldn't help cost all that much, perhaps only 2 controller ports and a manual swtichbox from the start. (a further redesign with more consolidated board and even more compact case) Though it probably would have been more cost effective to make fewer changes to the 5200 from the A8 hardware to better parallel production, so no unique controller ports, no missing PIA and such. (had lockout been implemented, that could have facilitated subsidizing cost too)

 

The original 1980 Sylvia/3200 design concept was much more in line with a cost optimized system with integrated VCS compatibility, but that apparently was taking too long to meet the desired release date. (probably the redesigned S-TIA being the major issue) -The use of SRAM still seems odd though.

 

Short of that would probably be what I mentioned before, using portions of the A8 chipset with the VCS hardware in a manner similar to the 7800, namely: add ANTIC+GTIA and DRAM (8-16 kB) but probably omit POKEY and rely on RIOT for the joystick I/O and done a similar controller set-up as the 7800. (except now there's also the 8 GTIA inputs you could put to use)

Now, without POKEY pots would need to be software polled if used, just like the 7800, but for 1982, TIA was a lot less antiquated than it was in '84. (and you still get better sound than the VCS due to more CPU time, like on the 7800 -plus there's the GTIA keyclick sound you can do some things with) OR they could have added POKEY too, and dealt with higher cost. (and if the I/O was mapped differently for 5200 mode than 2600 mode, you could have RIOT set-up like PIA for 4 controller ports too)

 

Omitting POKEY would leave the system closest to the Sylvia design though, just adding GTIA rather than reworking TIA.

[Crazyace]

In my opinion though, the 5200 actually has enough memory for almost any game on the 8 bit, especially if you add extra massive amounts of bank switched rom.

 

But the full-screen interlaced graphics required 16K+ RAM especially with overscan. And then you need RAM for PM graphics stuff as well although you can use up tons of ROM space and have every combination of sprite in ROM and just toggle banks.

 

I guess you're right , although I wouldn't expect too much of a game using those modes - and if it was for a title/screen or picture on a graphics adventure why not run it from rom.

PM graphics really only need 1.25k though

 

I still expect that all of the videos shown earlier from 8 bit games could be reproduced using the 16k ram + large rom though.

[atariksi]

In my opinion though, the 5200 actually has enough memory for almost any game on the 8 bit, especially if you add extra massive amounts of bank switched rom.

 

But the full-screen interlaced graphics required 16K+ RAM especially with overscan. And then you need RAM for PM graphics stuff as well although you can use up tons of ROM space and have every combination of sprite in ROM and just toggle banks.

 

I guess you're right , although I wouldn't expect too much of a game using those modes - and if it was for a title/screen or picture on a graphics adventure why not run it from rom.

PM graphics really only need 1.25k though

 

I still expect that all of the videos shown earlier from 8 bit games could be reproduced using the 16k ram + large rom though.

 

I don't know about that-- what about Flight Simulator-- doesn't that use up more than 16K RAM? It doesn't run on my Atari 400/600XL. And for PM graphics, there's all those animations and shapes which need to be either copied to PM graphics memory area or PMBase pointer switched to another RAM area. Since Y-axis requires memcopy, it would be hard to keep it all in ROM.

[Crazyace]

I can't really imagine FlightSim actually requiring more than 16k of ram - the 5200 gives 32k linear rom, rather than 16k on the 8bit/XEGS, and the original game ran on my 800 with 48k ram.

[atariksi]

I can't really imagine FlightSim actually requiring more than 16k of ram - the 5200 gives 32k linear rom, rather than 16k on the 8bit/XEGS, and the original game ran on my 800 with 48k ram.

 

It all depends on many locations they need to WRITE to.

 

And for games that do full-screen double-buffered graphics, that's 16K RAM right there.

[Wrathchild]

Taking Rampage as an example, you can take a game disassemble it, identify which bits are code, read-only data, written-to data. As Atariksi says, you'll then know if this will fit in the 16K the 5200 has. However, relocating the references in the code (and even pointers in the data too) is the time consuming part, but not impossible.

Edited April 1, 2010 by Wrathchild

[Charlie_]

if there were 5 things you wished the 5200 had, what would they be?

 

1) reliable controllers (self centering would be great but i really like the 5200 controllers already despite what critics say)

2) backward 2600 compatibility

3) audio/video outputs

4) more 4 player games

5) smaller console (i like the original and think its great, but having a smaller console would be nice)

 

Smurfs Rescue in Gargamels Castle

Dragon Fire

An arcade port of Space Invaders

Yars Revenge

Bowling

 

I love the 5200 hardware just the way it is. Perfect.

So all my choices are software.

[atariksi]

if there were 5 things you wished the 5200 had, what would they be?

 

1) reliable controllers (self centering would be great but i really like the 5200 controllers already despite what critics say)

2) backward 2600 compatibility

3) audio/video outputs

4) more 4 player games

5) smaller console (i like the original and think its great, but having a smaller console would be nice)

 

Smurfs Rescue in Gargamels Castle

Dragon Fire

An arcade port of Space Invaders

Yars Revenge

Bowling

 

I love the 5200 hardware just the way it is. Perfect.

So all my choices are software.

 

The A2600 version of Smurfs rescue isn't so bad. There are many version of Space Invaders out there but the Atari Invaders is pretty good (on A8) and the original A8 version that came on cassette (the 4K version is also pretty good).

[tyranthraxus]

Wico Controllers as the pack in controllers

Smaller Size

Donkey Kong

Cloak & Dagger

Elevator Action

[ZylonBane]

I love the 5200 hardware just the way it is. Perfect.

You consider those godawful anti-ergonomic non-centering chicklet-buttoned malfunction-prone joysticks to be "perfect"?

 

Keep chugging that kool-aid, dude.

[Charlie_]

I love the 5200 hardware just the way it is. Perfect.

You consider those godawful anti-ergonomic non-centering chicklet-buttoned malfunction-prone joysticks to be "perfect"?

 

Keep chugging that kool-aid, dude.

 

I love them.

 

LOL I do really like the controllers, although I admit the maintenance sucks.