Jump to content

JDecuir

Members
  • Posts

    10
  • Joined

  • Last visited

Recent Profile Visitors

3,903 profile views

JDecuir's Achievements

Space Invader

Space Invader (2/9)

1

Reputation

  1. 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
  2. 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.
  3. 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
  4. Hi, The value was developed by the coin-op designers. They in turn listened to their customers. The value is 2^13 TV frames (60 Hz). In the original arcade machines, it was a hardware timer, not microprocessor firmware. If the value is too short, it will annoy the end-customers (and miss their quarters). If the value is too long, the operators (who want more quarters), the next people in line (who want to play) or the girlfriends (who are bored and want attention) will complain. We just recycled their experience in the home systems. We didn't realize (in the first generation) that we needed levels. As Nolan told us: "the best games are easy to learn and difficult to master". Joe Decuir
  5. Hi, As I responded to the last guy, I am happy to have pleased you guys. One of my great lifetime experiences: Black Friday, 1977, Sears store in Mountain View, California, about a mile from my apartment. (I was working on the sequel, the Atari 400/800 system at the time.) They had a system set up with Combat, nailed down for a live display. A cloud of kids surrounded it, waiting their turns. Each figured it out by watching the others play. They would fight when their parents tried to drag them off. I loved it... cheers, Joe Decuir
  6. Hello Wondering, I am delighted that you had fun. I have been married twice. Both women have thrown up their hands complaining that I was 'turning our sons into couch potatoes'. I had fun myself while working on these things. I would go to work thinking "it is a good thing my managers don't know how much I like this job, or they would charge me to show up to work." I hope you also got outside to play in the sunshine... yours, Joe Decuir
  7. 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
  8. 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
  9. The question has two parts: - why have a time limit? - why this number? Having a time limit at all applies to some games but not others. E.g. Video Olympics will end on score = 21. Some games end when the player uses up too many resources, or achieves some goal. Some games (like Combat) could go on indefinitely, or until a certain amount of damage was taken. This is a port of common Arcade (coin-op) logic. These machines generated 60 frames/second. 8192 (2^13) frames is just over 136 seconds, or 2:16. Some arcade game probably used a binary 13 bit counter, and the practice followed. (The early arcade games were made with hardwired logic, not microprocessors.) 2:16 is long enough to have fun without being exhausting. Sometimes there would be others waiting their turn to play. Plus, the Arcade operator would want more quarters... In the case of a home machine, it doesn't overtax a parent's patience. 'Mom, wait until I finish this game.' Yours, Joe Decuir Atari 1975-1979 Amiga 1982-1984
  10. Hello, I was alerted to this book a couple week's back by Lee Krueger, the leader of the North West Classic Games Enthusiasts. (I live in the Seattle Area.) I read the whole thing. I am very impressed. I write as the surviving Stella chip designer. (That bicycle still works. It is hanging in my garage.) It is too bad I did not know of the book in advance. I would have been happy to contribute. Examples: - how we made design decisions - how we did design tradeoffs between code and chip logic - design decisions we wish we had made differently - how Stella (the 2600) influenced the Colleen (Atari 400/800/5200) and Lorraine (Amiga) platforms. They did a decent job of assigning credit where it is due. (e.g. they included Steve Mayer and Ron Milner.) I see another reader already caught an erratum: Larry _Wagner_ wrote Video Chess, not Larry _Kaplan_. They did allude to an essential theme: that the flexibility of the architecture (putting most of the display in the hands of the programmers) allowed the product to be much more successful than originally envisioned. As Bill Joy (co-founder of Sun Microsystems, fellow Berkeley grad student) later put it "You should design your business on the assumption that not all of the smart people in the industry work for you." We did it because it was cheaper, not because we were far sighted. However, it is then important to capture that theme; future system architects need to use that design principle. I particularly enjoyed the section in the back about architectures for digital media. (I have been using the OSI model on communications architectures for 3 decades.) I should go look for other publications from MIT on that subject. Thanks to the authors, and all who contributed! Joe Decuir Atari 1975-1979 Amiga 1982-1984 "Success has a thousand fathers. Failure is an orphan." Jay Miner, February 1976 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.
×
×
  • Create New...