Racing the Beam: The Atari Video Computer System

[carmel_andrews]

Mr Decuir, Thank you for giving millions of Atari fans something to be proud of, you are one of the greats, it's a shame there isn't a modern variant of you that people can look up to

 

Perhaps now that you've reacquianted your taste for thing's ATARI, perhaps you can team up with Curt Vendell and give your fans something they've been craving for nearly 1 and a half decades...Some new Atari hardware/console....designed by one of Atari's genius designers/engineers

 

Can you explain to us why so many people get your family name spelt wrong

[Ransom]

Mr. Decuir, thank you so much for engineering so many great things! I've been using Atari 2600, 5200, and 8-bit computer products since 1980, and still really enjoy them every day. I'd love to hear any insights you'd care to share about your time at Atari and designing these devices.

[hitchcock4]

PS. does anyone know WHY it assigned me the handle Combat Commando?

If I had any handle at all, Stella Rider would be more accurate...

Lee Krueger had beaten me at Combat on TV.

Well, apparently you are a Combat Commando until you have posted at least 10 posts. [i don't know if 10 is right but I am on post 19 and I qualify as a Space Invader.]

As you can see from my profile, I am fairly new around here. But, as the number of people of this forum will attest to, you and your team were revolutionary and great designers. As a teenager I convinced my parents to buy an Atari 800. I have some great memories of typing in programs from Compute! magazine. (And writing a few BASIC programs myself).

I recently got back into the Atari when I bought an Atari 65XE on eBay with a 1050 floppy drive. I haven't had a chance to use it much, but just turning it on when I got it was great!

-Hitchcock

Edited February 16, 2009 by hitchcock4

[JDecuir]

Welcome Joe! Care to stick around for a while and tell some stories about the early days at Atari? There's quite a few people here that are still reverse engineering the custom chips in the 8-bit Atari computers. There are new graphics modes and some amazing sounds coming from PoKey now, as well as 8-channel digi-music from GTIA. Great to see another Atari legend make it over here.

 

Stephen Anderson

 

Hello Stephen,

 

I have my engineering notebooks from that period, and third party references like De Re Atari.

I would be happy to help reconstruct the Colleen chipset: Antic, GTIA, Pokey.

I think I have partical schematics of Antic; I don't have the others.

 

Are people trying to construct a software emulator or a hardware emulator?

 

Yours,

 

Joe Decuir

[JDecuir]

Mr Decuir, Thank you for giving millions of Atari fans something to be proud of, you are one of the greats, it's a shame there isn't a modern variant of you that people can look up to

 

Perhaps now that you've reacquianted your taste for thing's ATARI, perhaps you can team up with Curt Vendell and give your fans something they've been craving for nearly 1 and a half decades...Some new Atari hardware/console....designed by one of Atari's genius designers/engineers

 

Can you explain to us why so many people get your family name spelt wrong

 

Hello Carmel,

 

Actually, I have been acquainted with Curt for a long time.

I think he is the guy I sent some schematics to.

He pulled together the design for the Flashback 2.0, which I have.

I am listed in the credits.

 

That said, I would be happy to share with the community.

I have several ideas I would have used on the 2600.

Our experiences with the 2600 led directly to features in the Colleen system (Atari 800 series) and the Lorraine system (Amiga 1000, etc). In fact, the Amiga 500 is an animation beast; it was designed to generate cartoons in real time.

If Commodore had the sense to use it as a video game console instead of a Mac competitor, it would have blown the doors off of the NES or its competitors, up to the mid-1990s.

 

If someone wants to design a new simple video game system to generate arcade style machines, let me know.

I must warn you, I do like my day job, which involves a lot of travel...

 

cheers,

 

Joe Decuir

[Bryan]

Mr. Decuir,

 

Have you seen any of the new stuff being developed for the 800/XL/XE? Stuff like this:

 

 

or demos like this:

 

Edited February 16, 2009 by Bryan

[carmel_andrews]

Mr. Decuir,

 

Have you seen any of the new stuff being developed for the 800/XL/XE? Stuff like this:

 

 

or demos like this:

 

 

 

 

 

 

 

Additionally, one hopes that the following multi system emulator that is in the works (link below) will emulate some if not all Mr. Decuir's creations/designs

 

http://www.techradar.com/news/gaming/uk-un...emulator-528487

 

what would be nice would be an all in one hardware emulator that mimics/emulate all of atari's hardware platforms (incl. coin op)...perhaps Joe Decuir could assist in the design of that system

 

Going back to Mr Decuir's last comments, I guess the reason why cbm didn't go down the videogame (with the lorraine/amiga thing) route is simply because they (cbm) didn't want what would have been a souped up Max/Ultimax system that cbm would have had to have sold at a loss just to get it on the market...and also because they could see that market was heading into the toilet so they switched gears and worked on computer based applications for that hardware

 

Just curious as to whether Mr. Decuir ever got to see the proposed atari version (worked on under the warners admin) of the lorraine/amiga chip set or didn't it get past the drawing board stage (chipset only, not the actual system)

Edited February 16, 2009 by carmel_andrews

[BSA Starfire]

I have several ideas I would have used on the 2600.

 

 

This seems very interesting, can you elaborate?

 

Also very nice to see the original designer here, thanks for the fun all these years!

 

Best regards,

Chris

[Mayhem]

Welcome Mr Decuir, very pleased to see you here and to possibly hear more about how everything came together

 

My copy of the book arrived 2-3 days ago but I've been under the weather with a cold and not feeling up to doing much bar blowing my nose and drinking plenty of fluids. I'll be perusing it when I'm better...!

[supercat]

A few questions for Mr. Decuir which I've not seen discussed elsewhere. First off, though, I should congratulate Mr. Decuir for his involvement in an absolute work of genius. But on to the questions:

 

-1- What were the constraints and optimization goals for the circuit designers? Was it to minimize the number of transistors, transistors plus resistors, or what? To what extent were interconnects considered at the circuit design level? There seems to have been some consideration given in the playfield module, but was layout an issue anywhere else?

 

-2- How did the sprite horizontal positioning circuitry evolve? In particular...

 

- Were it not for the multiple sprite copies, having a common horizontal position counter and then position comparators for each latch would seem a lot easier than the present system; such a design would not readily permit the multiple-sprite-copy feature, however. Were slip counters used because they could allow the sprite-copy function, or because they seemed like such a cool idea to borrow from the PONG design, or were they expected to work out more nicely before it was discovered that all the HMOVE circuitry would be needed anyhow?

 

- How did the multiple-sprite-copies concept enter the picture? I can't think of any arcade hardware which used a finite number of close sprite copies (some games did omit bits from comparison logic, but that would result in copies all across the screen, rather than only near the 'main' player).

 

- Did anyone at Atari ever know the virtues of hitting HMOVE just before the start of horizontal blanking (all the HMOVE pulses will work as normal, but the next horizontal blank won't be extended by 8 pixels).

 

- Was the decision to have HMxx latch D4-D7 really predicted upon 'ease of coding', or hardware layout considerations? In what anticipated scenario would it ease coding?

 

-3- Are there any design decisions where you think you 'lucked out', and made something much more useful than anticipated? Are there any which you wish you had done differently?

 

Thank you Mr. Decuir for producing such a brilliant piece of amazingly simple-yet-powerful hardware. I wish I could manage something even 1/10 as great.

[+Stephen]

Welcome Joe! Care to stick around for a while and tell some stories about the early days at Atari? There's quite a few people here that are still reverse engineering the custom chips in the 8-bit Atari computers. There are new graphics modes and some amazing sounds coming from PoKey now, as well as 8-channel digi-music from GTIA. Great to see another Atari legend make it over here.

 

Stephen Anderson

 

Hello Stephen,

 

I have my engineering notebooks from that period, and third party references like De Re Atari.

I would be happy to help reconstruct the Colleen chipset: Antic, GTIA, Pokey.

I think I have partical schematics of Antic; I don't have the others.

 

Are people trying to construct a software emulator or a hardware emulator?

 

Yours,

 

Joe Decuir

What I wouldn't gove to thumb through those notebooks! Actually, the reverse engineering has been going on due to incomplete emulation of certain features. Curt has said he will release the schematics to all the chips soon so it should soon be a non-issue.

 

There are tons of people here that would be spellbound to hear tales of the design days, technical and non-technical.

 

Thanks for replying.

 

Stephen Anderson

[+batari]

Really cool to have the TIA designer here. I know you did plenty of other things but the TIA is such an elegant piece of hardware.

 

I guess I didn't realize that you also wrote Combat. Clearly the 6507 stack mirror in zero page was an artifact of minimal address decoding, but I have to wonder if ENAMx/ENABL purposely used bit 1 to make the Z-flag/PHP missile trick in Combat possible.

 

Were there any features that you wanted to add to the TIA but couldn't?

[supercat]

Clearly the 6507 stack mirror in zero page was an artifact of minimal address decoding, but I have to wonder if ENAMx/ENABL purposely used bit 1 to make the Z-flag/PHP missile trick in Combat possible.

 

The TIA documentation I have explicitly states that as being the reason for the choice. Makes sense, though I think bit 0 or 7 would have been more helpful (to allow ROL or ROR). I'm more puzzled by the use of bit 3 for REFPx. It would seem bit 7 would have been the logical choice (store a direction there directly, or if one is in the mood to PHP, push the N flag).

 

I wonder when it became clear that most games on the 2600 would not be 'freewheeling' the sprite horizontal positions? If a game tracks the horizontal positions of sprites, one could show scores using magnified sprites rather than the score-colored playfield. As it turns out, score mode can be handy for purposes other than showing two-player scores, so it's hardly a waste of silicon, but it's hardly essential.

 

I think my biggest peeve in the TIA is probably the sharing of player/missile NUSIZx settings. Even in a game like Combat, it would have been nice to have an option for a triple plane to fire a single bullet. For that to work well, though, it might have been necessary for the code to track the plane/shot positions (since aesthetically a single shot should be fired from the center plane, not the left one). Still, it's curious that the NUSIZx feature was included at all since it considerably complicated the hardware and I know of nothing really similar in any arcade predecessors. Of course, without NUSIZx the 2600 would have died off a lot sooner, but I'm still curious what inspired it.

[+batari]

I'm more puzzled by the use of bit 3 for REFPx. It would seem bit 7 would have been the logical choice (store a direction there directly, or if one is in the mood to PHP, push the N flag).

Somewhat by accident I found that NUSIZx excludes bit 3, so NUSIZx data can also contain REFPx data. I'm not sure if that's coincidental or intentional.

I wonder when it became clear that most games on the 2600 would not be 'freewheeling' the sprite horizontal positions? If a game tracks the horizontal positions of sprites, one could show scores using magnified sprites rather than the score-colored playfield. As it turns out, score mode can be handy for purposes other than showing two-player scores, so it's hardly a waste of silicon, but it's hardly essential.

If we're talking about non-essential silicon, I'm going to vote for RESMPx - while it might save a little time and code space to move the missile on top of its player, it's not really necessary to do that. RSYNC is somewhat of an enigma to me. I recall reading somewhere that its purpose was for testing the chip, but I can't imagine how such a test would work.

[JDecuir]

Mr. Decuir,

 

Have you seen any of the new stuff being developed for the 800/XL/XE? Stuff like this:

 

 

or demos like this:

 

 

 

 

 

 

 

Additionally, one hopes that the following multi system emulator that is in the works (link below) will emulate some if not all Mr. Decuir's creations/designs

 

http://www.techradar.com/news/gaming/uk-un...emulator-528487

 

what would be nice would be an all in one hardware emulator that mimics/emulate all of atari's hardware platforms (incl. coin op)...perhaps Joe Decuir could assist in the design of that system

 

Going back to Mr Decuir's last comments, I guess the reason why cbm didn't go down the videogame (with the lorraine/amiga thing) route is simply because they (cbm) didn't want what would have been a souped up Max/Ultimax system that cbm would have had to have sold at a loss just to get it on the market...and also because they could see that market was heading into the toilet so they switched gears and worked on computer based applications for that hardware

 

Just curious as to whether Mr. Decuir ever got to see the proposed atari version (worked on under the warners admin) of the lorraine/amiga chip set or didn't it get past the drawing board stage (chipset only, not the actual system)

hello,

I saw the demos. Someone is having fun.

 

CBM kicked out the Tremiel clan in early 1984, then bought Amiga in mid-1984.

They were entranced by the MAC (which came out in January 1984) and decided to morph the Amiga into a color MAC.

They were not long on vision. Nintendo was.

The Amiga chipset was conceived to be able to render cartoon animation in real time.

Depending on how much detail you wanted, it could.

 

Before that sale (to CBM) Amiga peddled its chipset to Atari for coin-op use ONLY.

That didn't end in a product. Atari itself failed, to be dismembered and sold off.

The Tramiel clan bought the consumer part, and tried to get the Amiga chipset.

Only the lawyers benefited from that dispute.

 

BTW, you can call me Joe.

 

yours,

 

Joe Decuir

[JDecuir]

A few questions for Mr. Decuir which I've not seen discussed elsewhere. First off, though, I should congratulate Mr. Decuir for his involvement in an absolute work of genius. But on to the questions:

 

-1- What were the constraints and optimization goals for the circuit designers? Was it to minimize the number of transistors, transistors plus resistors, or what? To what extent were interconnects considered at the circuit design level? There seems to have been some consideration given in the playfield module, but was layout an issue anywhere else?

 

[joe] our marketing people told us the market would accept a $200 retail price point in 1977. Assuming a 3:1 ratio retail vs Bill of Materials, we had to keep the assembled cost in the $65 range, including chips, circuit boards, shielding, power, plastic, manufacturing, production testing, etc. I think they forgot to consider tech support and customer service...

There is not a lot of analog circuitry. The cost was dominated by the large ICs. To be manufactured for a reasonable cost in 1977, we kept the chip area on the TIA to 5mm square, using 10 um line geometries, on depletion-load NMOS. We didn't have the budget for a bit map, which would have needed at least 32k bits for 160 x 96 x 2 bits. (Stella has only 1k bits of RAM.)

I don't know what you mean by the 'playfield module'.

There aren't all that many bits in Stella:

20 bits of 'playfield'

19 bits of moving object: 2 x 8 bit sprite, 3 x 1 bit object

20 bits of horizontal motion registers (5 x 4 bits)

15 bits of collision detection latches (read only)

28 bits of palette registers: 4 x (4 bit color, 3 bit luminance)

several registars with control information

 

-2- How did the sprite horizontal positioning circuitry evolve? In particular...

 

- Were it not for the multiple sprite copies, having a common horizontal position counter and then position comparators for each latch would seem a lot easier than the present system; such a design would not readily permit the multiple-sprite-copy feature, however. Were slip counters used because they could allow the sprite-copy function, or because they seemed like such a cool idea to borrow from the PONG design, or were they expected to work out more nicely before it was discovered that all the HMOVE circuitry would be needed anyhow?

 

[joe] I thought long and hard about this.

The design used is descended from PONG, and repeated in things like TANK.

Those were built in descrete MSI logic; no processors were used.

 

For a programmable system, the obvious logical thing to do is:

- binary horizontal counter (228 color clock cycles)

- 5 x 8 bit horizontal position registers with comparators

You are correct that it doesn't facilitate easy replication.

It also is a lot larger in chip area. The counters are implemented in polynomial counters, not binary counters.

(That makes them about 1/3rd the size of binary counters.)

 

Too late to change the design, I though of replacing the 5 Hmove registers (which are also counters) with 5 Hposition registers. Basically, they would compare against the Hsync counter, and determine when to reposition the corresponding object horizontal position counter = reset it when the value in the position register matched.

The trick: to get binary positioning, the cartridge would need to contain a 160 byte lookup table to the correct 8-bit polynomial counter values.

To meet the programmers' needs, I wrote the CHRST subroutine. Given a binary horizontal position, it figures out how to issue a reset at the right time (running a 15 color clock cycle loop), and then perform the correct Hmove (+/- 7 color clocks). The programmers liked it, so we left the hardware alone.

 

- How did the multiple-sprite-copies concept enter the picture? I can't think of any arcade hardware which used a finite number of close sprite copies (some games did omit bits from comparison logic, but that would result in copies all across the screen, rather than only near the 'main' player).

 

[joe] we came up with this almost for fun. We replicated the little biplanes and jets in what would become Combat.

It was easy: just additional hard decodes off the object's horizontal counter, and then control bits to choose when to display the sprite bits. If we know that people would try to display characters with them, it might have been different...

 

- Did anyone at Atari ever know the virtues of hitting HMOVE just before the start of horizontal blanking (all the HMOVE pulses will work as normal, but the next horizontal blank won't be extended by 8 pixels).

 

[joe] When we designed it, CHRST was only being executed once per object per frame, in VBLANK.

Later, clever programmers started using it in mid-frame. We realized the error then, too late to fix...

 

- Was the decision to have HMxx latch D4-D7 really predicted upon 'ease of coding', or hardware layout considerations? In what anticipated scenario would it ease coding?

 

[Joe] for many moving objects in the Combat display (the original target game) the motion vector for the tank had a 4 bit horizontal and a 4 bit vertical component. We used the high nibble for horizontal; I don't remember why. Probably because we could mask off the top 4 bits to add to the current vertical position value (a memory byte) without having to shift anything.

 

-3- Are there any design decisions where you think you 'lucked out', and made something much more useful than anticipated? Are there any which you wish you had done differently?

 

[Joe] big questions!

 

Main luck out: putting the display in firmware (to be cheap) opened it up to the creativity of the programmers.

It wasn't luck that led to the collision detection logic; we realized that it would save a great deal of processor time.

 

Examples of 'wish we had done it differently':

- use 40 pin 6502 (cost 50 cents more, all in packaging)

- connect IRQ pin to 6532, so that we could run two threads: display, and game processing

- use 30 pin cartridge connector (cost 50 cents) to add top three address lines, R/W, clock, decode back

- hposition comparators (see above) instead of hmove register/counters

- if we could have afforded the chip area, have 40 bits of playfield instead of 20, used in one of three ways:

1) 40 bits across (cover the whole line with 4 clocks/bit)

2) 80 bits across, reflected (40 then 40)

3) 80 bits across, repeated (40 then 40)

 

Thank you Mr. Decuir for producing such a brilliant piece of amazingly simple-yet-powerful hardware. I wish I could manage something even 1/10 as great.

[Joe] a whole lot of people contributed to that success.

I suspect that you could also do that, if you were in the right place at the right time.

Good luck finding and/or creating that opportunity.

[JDecuir]

Really cool to have the TIA designer here. I know you did plenty of other things but the TIA is such an elegant piece of hardware.

 

I guess I didn't realize that you also wrote Combat. Clearly the 6507 stack mirror in zero page was an artifact of minimal address decoding, but I have to wonder if ENAMx/ENABL purposely used bit 1 to make the Z-flag/PHP missile trick in Combat possible.

 

Were there any features that you wanted to add to the TIA but couldn't?

Hello,

I believe you are correct about the use of the ENAMx/ENABL, so that it minimize computation in the Combat display kernel.

For other TIA features, see the other (longer) post I just made.

Joe

[carmel_andrews]

Just a couple of interesting questions i'd thought i'd ask you Joe (while your'e still around)

 

Firstly, Did Jay (Miner) ever intimate or tell you why the warner's management decided against Jay's plans for developing the A8 further (bearing in mind that at the time warner were starting to invest in numerous Atari R&D offshoots)

 

Also what was your opinion of Kay Kassar and the legions of people he bought in, after Bushnell left the scene (did you think ray was a good thing for Atari or a bad thing, this also applies to the legions of people be bought in)

 

lastly, to using a line from the Wayne's world film.....'We're not worthy, we're not worthy', Joe

[Defender II]

This is THE best thread I have read on Atari in ages!!!!!!!!!

 

Thanks Joe!

[Bryan]

I have my engineering notebooks from that period, and third party references like De Re Atari.

I would be happy to help reconstruct the Colleen chipset: Antic, GTIA, Pokey.

I think I have partical schematics of Antic; I don't have the others.

 

Joe,

 

Any chance you could scan this information, or at least the stuff you have on Antic? There are (poor quality) internal schematics floating around for GTIA and POKEY, but nothing for Antic. There are ongoing attempts to define all the undocumented behavior of the chipset and another member here has an interlaced display going by goosing Antic on the right cycles:

 

http://www.atariage.com/forums/index.php?showtopic=137596

 

The more documentation we can get, the more performance we can squeeze out of the chipset.

 

http://www.atariage.com/forums/index.php?showtopic=136706

 

Thanks!!

[supercat]

I don't know what you mean by the 'playfield module'.

 

Page 5 of the TIA schematic (look in the 2600 area at the top, then "Archives"), in the lower-right corner. "Playfield module" may not be a technical term, but I'm not sure what else you'd call that bit of circuitry that holds the playfield registers and shifters. My question with regards to layout had to do with the fact that the shifter interconnects go from the top of one column to the top of the adjacent column, rather than running from the top of one to the bottom of the next. Small savings in silicon (avoiding four vertical traces), but taking such opportunities when they present themselves can be important.

 

I thought long and hard about this.

The design used is descended from PONG, and repeated in things like TANK.

Those were built in descrete MSI logic; no processors were used.

 

For a programmable system, the obvious logical thing to do is:

- binary horizontal counter (228 color clock cycles)

- 5 x 8 bit horizontal position registers with comparators

You are correct that it doesn't facilitate easy replication.

It also is a lot larger in chip area. The counters are implemented in polynomial counters, not binary counters.

(That makes them about 1/3rd the size of binary counters.)

 

True, the polynomial counters are smaller than binary counters. But with a comparator-based approach one would only need one binary counter, instead of needing a two-bit sync counter and six-bit polynomial counter for each sprite. Given that the system already has a four-bit binary counter and a 4-bit comparator for each sprite to handle the HMOVE logic, I would think that adding two bits to that and adding two bits of fine position control would have been easier than adding five 6-bit polynomial counters and five 2-bit sync counters.

 

Too late to change the design, I though of replacing the 5 Hmove registers (which are also counters) with 5 Hposition registers. Basically, they would compare against the Hsync counter, and determine when to reposition the corresponding object horizontal position counter = reset it when the value in the position register matched.

The trick: to get binary positioning, the cartridge would need to contain a 160 byte lookup table to the correct 8-bit polynomial counter values.

To meet the programmers' needs, I wrote the CHRST subroutine. Given a binary horizontal position, it figures out how to issue a reset at the right time (running a 15 color clock cycle loop), and then perform the correct Hmove (+/- 7 color clocks). The programmers liked it, so we left the hardware alone.

 

Have you seen the motion routine that from what I understand was first used in BattleZone, but has been used in many homebrews since? It takes advantage of the fact that "lp: SBC #15 / BCS lp" takes five cycles (i.e. 15 pixels). It ends up having to either use a 15-byte lookup table for HMOVE values or four ASL instructions to position bits for storage in HMxx, but still works quite nicely.

 

we came up with this almost for fun. We replicated the little biplanes and jets in what would become Combat.

It was easy: just additional hard decodes off the object's horizontal counter, and then control bits to choose when to display the sprite bits. If we know that people would try to display characters with them, it might have been different...

 

I guess what I find really curious is that the slip-counter plus HMOVE approach ended up being more complicated than necessary for the main purpose, but allowed the 'just for fun' feature that turned out to be very useful. Nice bit of lucking out.

 

As for characters, when did you become aware of what Bob Whitehead was doing with Blackjack?

 

When we designed it, CHRST was only being executed once per object per frame, in VBLANK.

Later, clever programmers started using it in mid-frame. We realized the error then, too late to fix...

 

What do you mean by "the error"? The artifact produced by doing an HMOVE at the normal time?

 

for many moving objects in the Combat display (the original target game) the motion vector for the tank had a 4 bit horizontal and a 4 bit vertical component. We used the high nibble for horizontal; I don't remember why. Probably because we could mask off the top 4 bits to add to the current vertical position value (a memory byte) without having to shift anything.

 

I guess that makes sense. A slightly unfortunate decision, but not a particularly horrible one.

 

big questions!

 

Main luck out: putting the display in firmware (to be cheap) opened it up to the creativity of the programmers.

It wasn't luck that led to the collision detection logic; we realized that it would save a great deal of processor time.

 

That wasn't luck. That was genius.

 

Examples of 'wish we had done it differently':

- use 40 pin 6502 (cost 50 cents more, all in packaging)

- connect IRQ pin to 6532, so that we could run two threads: display, and game processing

- use 30 pin cartridge connector (cost 50 cents) to add top three address lines, R/W, clock, decode back

- hposition comparators (see above) instead of hmove register/counters

- if we could have afforded the chip area, have 40 bits of playfield instead of 20, used in one of three ways:

1) 40 bits across (cover the whole line with 4 clocks/bit)

2) 80 bits across, reflected (40 then 40)

3) 80 bits across, repeated (40 then 40)

 

Your first three items would have increased the cost of the unit, and I'm not sure there would have been much benefit. Cartridges did come along with bank switching, on-board RAM, etc. despite the lack of pins for them.

 

My wish-list items would have been:

 

- Separate NUSIZx enables for players and missiles (how much silicon would that have taken, including routing)?

 

- A 'divide-by-two' option in AUDCx (possibly using bit 0 or adding a new bit 4). If the counter could hold value for 64us, the feature could be implemented by killing one of the clock phases feeding the main counter. Probably less than eight transistors per channel if done using AUDCx.0; a little more if it used bit 4. Still, I shouldn't complain too much about the 2600's musical abilities. It's really quite good compared to almost anything else of the era.

 

- A 20-pixel mode for the playfield using double-sized pixels. Adding too many playfield registers would, I think, have been a mistake, since there's only a finite time available to update them. For most games, the existing set is more useful than a five-byte set of registers would be, unless the latter happened to include a means to update multiple registers with one write.

 

- For PAL 2600's, an read bit to report even-odd scan line (this would make it easier for games to avoid losing color if something slips by a scan line).

 

- A means to write a sprite without copying the other sprite's delay register (see note below (*))

 

Of course, some of those notions are created with the benefit of 30 years' hindsight. I'm amazed at what you pulled off.

 

Out of curiosity, have you seen any of my projects? Strat-O-Gems, Toyshop Trouble, or the Stella's Stocking menu? And have you read at all about my 4A50 cart?

 

Strat-O-Gems is a game I started back in 1994 but abandoned because I couldn't figure out the RIOT. I finished it in 2005. It manages to do 'thinking' processes that take multiple frames to complete, without causing loss of video. Things would be a little more efficient of the 2600 had interrupts, but the lack of interrupts is hardly a major problem.

 

Toyshop Trouble is my favorite of the games I've done. It shows four player sprites per line with independent color and shape; three of the objects move together horizontally, while the other has free horizontal and vertical motion. I sometimes like to imagine what you guys would have done if I'd smuggled a copy of the game back in time and showed it to you; there are a lot of TIA tricks in that thing. Incidentally, the game uses an 8K EPROM with one off-the-shelf 74xx chip, something I don't think was ever done in the day (games either used multiple chips or custom logic).

 

The Stella's Stocking menu must be seen to be believed. Four-voice music through a five octave range, with full chromatic support. The music driver uses 46 cycles/scan line, leaving 30 to draw the display.

 

The 4A50 cart includes 32K RAM and 128K flash, using my own banking scheme. What makes it unique is that writes and reads can be performed at the same addresses with no special coding tricks required. Even code execution and read-modify-write instructions work 'normally', despite the lack of a R/W line to the cartridge.

 

(*) Handy sprite addressing:

Given that the TIA has a fair number of free addresses, it might have been handy to make address 11xxxx write to sprite registers thusly:

 

11xxx1 -- Write to player 0 write register

11xx1x -- Copy player 0 write register to display register

11x1xx -- Write to player 1 write register

111xxx -- Copy player 1 write register to display register

 

I can't see that anyone would have seen any use for such a thing when the 2600 was designed, but it would have allowed a 'write' register to be latched without copying the other sprite's 'delay' register, thus allowing four bytes' worth of data to be latched in sprite registers before the start of sprite display. It would also have made it easier to show identical data on both sprites, and to clear both sprites when switching between screen zones. It might have required a little routing, but otherwise would not have required any extra silicon.

[supercat]

One more point of curiosity: how fast was the logic in the TIA? Would it have been practical to derive a two-phase non-overlapping clock at 3.579MHz using the chroma circuit, as opposed to generating two-phase non-overlapping clocks at 3.579/4? Or was NMOS not fast enough to allow such an approach?

[ovalbugmann]

QUOTE

Examples of 'wish we had done it differently':

- use 40 pin 6502 (cost 50 cents more, all in packaging)

- connect IRQ pin to 6532, so that we could run two threads: display, and game processing

- use 30 pin cartridge connector (cost 50 cents) to add top three address lines, R/W, clock, decode back

- hposition comparators (see above) instead of hmove register/counters

- if we could have afforded the chip area, have 40 bits of playfield instead of 20, used in one of three ways:

1) 40 bits across (cover the whole line with 4 clocks/bit)

2) 80 bits across, reflected (40 then 40)

3) 80 bits across, repeated (40 then 40)

 

 

Your first three items would have increased the cost of the unit, and I'm not sure there would have been much benefit. Cartridges did come along with bank switching, on-board RAM, etc. despite the lack of pins for them.

 

This is what I was most interested in hearing from Joe(thanks Joe!) - what would he do development wise differently now that he has the benefit of 20/20 hindsight vision.

 

Supercat: I think the use of the MOS6502 would have been better than the VCS's MOS6507 processor, as Joe basically has said. The availability of the 16? registers in the 6502, vs. the 13 registers in the special made 6507 that the VCS uses, surely would have been a nice benefit to software programmers then and now.

 

I'm not a programmer so if possible Joe, Nukey, mos6507(AA member) or anybody that programs the machine today tell me if I'm wrong here.

[supercat]

Supercat: I think the use of the MOS6502 would have been better than the VCS's MOS6507 processor, as Joe basically has said. The availability of the 16? registers in the 6502, vs. the 13 registers in the special made 6507 that the VCS uses, surely would have been a nice benefit to software programmers then and now.

 

A 6502 is a chip in a 40-pin package; I think 37 of the pins are actually used. A 6507 is the same chip in a 28-pin package; nine of the connection points on the chip are left unused. There were actually a number of 28-pin parts available, using different combinations of signals on three of the pins.

 

Using a 6502 instead of a 6507 would have only provided two extra features: -1- It would have expanded the available address space from 8K to 64K. Unless a larger edge connector were used for the cartridge port, however, the extra space wouldn't have really been good for much; -2- It would have allowed the RIOT to interrupt the 6502 when the timer expired. This would have made it easier for games that have a long 'think' to maintain some sort of video display while thinking, but for the most part the 2600 does just fine without such a feature.

 

Given that the machine originally used 2K cartridges, I think the 8K address space is entirely reasonable. It might have been nice to use another 74xx gate so the TIA and RIOT wouldn't be selected at addresses $0800-$0FFF (thus allowing carts up to 6K) but I don't know that even that would have been worth the cost.

 

The design of the 2600 manages to provide 'just enough' in many ways. The 128-byte RAM is cramped, but for many games it is quite workable. The TIA is pretty minimalist, but it too provides enough features to make things work. The color circuitry is simpler than that on some other consoles (which use translation logic to turn e.g. 4-bit colors into different combinations of luma and chroma), and yet works much better. The audio isn't great, but it provides serviceable music. Wonderful machine.

[ovalbugmann]

Great information, Supercat! thanks.

 

Would the use of the 40-pin Mos6502 have increased the number of registers available to programmers?-how many does it have?

 

How many registers does the Mos6507 have, for comparison?

 

I know I've read somewhere here, probably Nukey, that if the VCS had just one more register(for a certain function?) that it would have increased it's abilities in at least one significant way.

 

I'm just curious, and unfortunately don't know enough about the VCS to even know if I'm making sense.