Dutchman2000

Here is the proper version of the 3D Asteroids demo and Space Race. Both were programmed by John Seghers as demo programs. Space Race was his first program, he did it to help him learn how to program the 5200. Asteroids was his answer to the 7800 version, proving that the 5200 could do rotating asteroids as well. 3D Asteroids Demo (Proper).bin Space Race.bin

From what I understand, the black boxes had the standard OS ROM, used standard controllers and functioned pretty much like a stock 5200 except for the fact that the GTIA and POKEY resided at different addresses. I'll have to look into the Votrax, I never really noticed it mentioned in there.

ZZZROM is only mentioned at the beginning of the code, to setup the system: .TITLE TEMPEST BY KEITHEN .NLIST LD ;DON'T LIST LISTING DIRECTIVES .NLIST BEX ;DON'T LIST ALL .BYTE DATA .NLIST MEB ;DON'T LET SEE CODE FROM MACROS .LIST ;LIST EVERYTHING (OVERRIDES BALANCED NLISTS) ;ZZZROM = 1 ONEROM = 1 ;DEVELOPMENT SYSTEM ALWAYS LOOKS LIKE 1 ROM VERSION

BARROOM GAME DEVELOPMENT STATUS BARROOM DATE: 8 FEB 1984 PROJECT LEADER: STEMPLER/DOWNEND START: 21 NOV 83 LAB: SICKBAY EXT: 7174/7456 NUMBER: 434XX RASTER | | SCHEDULE or | MISSED DATES | | | <OCCURANCE> | | ------------------------------------------------------------------------ PROJECT START: <21 NOV 83> 1ST ENG REVIEW: <13 JAN 84> 3 JAN 84 20 DEC 83 2ND ENG REVIEW: 1ST MKT REVIEW: <16 JAN 84> 9 JAN 84 3 JAN 84 2ND MKT REVIEW: 3RD MKT REVIEW: FOCUS GROUP: <21 JAN 84> 4TH MKT REVIEW: UL/FCC REVIEW: 29 FEB 84 FIELD TEST: 2 MAR 84 DRB/UL REVIEW: PROD REL MKT REVIEW: PROD RELEASE: JUN 84 NOTE: Above dates (except for prod release) are Phase I dates. Phase II calls for an engineering review in March, marketing review in April, field test in April and production release in June. But the occurance and/or schedule of Phase II depends on the results of Phase I. 1. Focus Group report received. Meeting should be scheduled late next week or the following week (2/20). 2. Before field test can occur, extensive gameplay changes will have to be made to the Baseball cart. A list of required changes (to simplify the game for the targeted audience) will be generated. A programmer is needed to implement these changes (can we borrow Keithen?). 3. Phase II hardware is 75% debugged. Still some problems with the DRAM refresh.

I found this also on some VAX/VMS backup tapes, the barroom sports project. Here is a 5200 rom of Barroom Baseball that differs from the existing version (has a few different bytes) and a report on the project when it began. PROJECT PROPOSAL -- BARROOM (Bar Top Sports Game) _________________________________________________ DESCRIPTION As was evident at AMOA, there is an abundance of "Bar Top" games, primarily of the gambling type (mostly card games and horse racing). There must be a sizable market for this type of product or there wouldn't be so many companies building them (maybe a bad assumption). This is a proposal for a product to compete in this market. But rather than a gambling game, we would produce a 5200 quality sports game ("RealSports" Baseball, Foot- ball, etc.). It was originally thought that we could design a hardware system which would accept off-the-shelf 5200 cartridges on which time could be bought, but it was later decided that the cartridges do not have what it takes to succeed in a coin-op environment (dead time, ability to stall, long game times). However, to minimize unnecessary engineering effort, let's field test a unit which does contain an unmodified 5200 cart (we like Baseball) to see how it does. We'll call this phase I of the project. If the field test is successful, phase II of the project will consist of getting a programmer to modify the cartridge program, customizing it to the coin-op environment. Phase I: A Moose Brain and 16 character alphanumeric display will be used in conjunction with a 5200 PC board and an unmodified RealSports Baseball cartridge to field test the concept. Some software development will be necessary to control the alpha- numeric display and read the coin mech. An "add-a-coin" feature will be implemented to address the problems of excessive game time. An anticipated problem with this field test is that we will use standard 5200 controllers, which will probably break and have to be replaced every day or two. For phase II, new controllers will have to be designed. Phase II: If phase I proves successful, a programmer will be as- signed to the project to modify the cart (or write a new baseball program from scratch). Since the basic 800 chip set will be used, the program (and subsequent programs) can be developed on an 800 and re-assembled to run on "Barroom". Messages and timing will be moved from the Moose Brain to the game program and the Moose Brain and alphanumeric display will be eliminated. Coin-op quality controls will need to be integrated into the system. Either the modified program will accept standard coin-op controls, or a coin-op quality keyboard will have to be developed to be used with a coin-op pot joystick. Barroom Baseball (11-21-83).bin

This is a game I complied recently from source code found on VAX/VMS tape backups. This doesn't match the known version out there. The date on the tape was 7-18-84 but I doubt this was written that late, it's most likely an early version of the PAL version. Enjoy! Sorcerers Apprentice PAL.bin

Here are the demonstrator versions of 5200 Pac Man and Galaxian. Created in 1982 for a type of 5200 Demonstration Kiosk, we have no idea if these ever appeared anywhere, but here are properly compiled versions that came from the original source code. Galaxian Demonstrator 3-15-82.bin Pac Man Demonstrator 10-5-82.BIN

In the PAMEQU file, it tells you the different addresses: ; PAM MNEMONICS ; ANTIC = 0D400 ; .IF NDF,ZZZROM ; ... FOR 800 BLACKBOX GTIA = 0D000 POKEY = 0D200 .ENDC .IF DF,ZZZROM ; ... FOR EPROM OR ROM GTIA = 0C000 POKEY = 0E800 VOTRAX = 0E000 .ENDC

Here are 2 binaries for 5200 Tempest that were made for Atari's Black Box development system, this is what games were tested on during development. The addresses of the chips on this system were different then a stock 5200. These work on emulators but elements are missing due to the address differences. I am hoping that someone with some more expertise could modify these binaries to work on a real 5200. These were found on the Tempest development disks along with the source code dated 3-15-84. I converted them from DLD files to BIN, using the same tools used at Atari back in the day. DLD files were compiled and then downloaded to the development system for testing. demo.bin temp.bin

The 9-track tapes I have were read with an M4 Data 9-track SCSI drive I have. Tapes were converted to digital files, then extracted using specialized programs. The main way I do it now is restore the data on my tape images to the virtual VAX (SIMH) then use FTP to transfer the files to my PC.

Yes I know, I have copies of his tapes as well.......

I have the full source code to 2600 Gyruss, I'll have to check with the programmer and see if i can release it.

Yes, he has that too but I got this from a VAX/VMS backup tape of a VAX that belonged to Atari Coin-Op.....

Here's another memo: Since everyone else seems to be on the subject I might as well add my two bits worth. First, regarding testing and review of 2600, 5200, 800,... software. In the past I was given carts to review, and in some cases they ignored my comments. In particular, for the 800 Centipede I saw a bootleg copy and send my comments back only get see the shit hit the fan because I managed to see the cart which should not have been possible. Months later I was officially given a newer version to test. I noted some problems and asked that the game play match the Coin-Op version in several aspects. I was told that it was too late because they couldn't make the changes in time for the release. More recently I attended a meeting to decide which Millipede cart for the 2600 should be released. The release date was less than a week away and I was told that the programmer had just gotten one version working within the last couple of weeks (and only possible thru 7 day work weeks and considerable lack of sleep). I should also point out that I sent the complete documentation of Millipede to the team leader responsible for the VCS cart months prior to this meeting. I also called and left my name and number with the comment that I was available for any assistance. I received no response until a week or two prior to the above mentioned meeting. This leds me to believe that the game was not ready for help until the time of the meeting (thus verifying the hearsay that the game had just been developed in the last two weeks). Now for the good news! ATARI did select the VCS version of Millipede over the version done by GCC. I was told that GCC was instructed NOT to do this cart but they went ahead and did it anyway. I guess they felt that if they got it done first ATARI marketing would use theirs. Judging from the meeting I attended, I would guess that they were right. In any case I have worked with the VCS programmer since and hopefully the cart has improved. I do NOT mean to say that I necessarily helped but that the cart just needed time. I should point out that the cart was not released due to a bug! Now why didn't we think of this before? That sounds like a good strategy to follow. The only reason I was given why the cart was to be released within a week of the meeting was to have ONE week worth of sales for the first quarter. WHAT A SHITTY, GOD DAMNED, FUCKING CSDKFHAS FHLAVFHJ EXCUSE!!!! What ever happened to quality which the name ATARI is supposed to represent? Where was VCS management?? I would hope that someone would stand up and say "THE GAME IS NOT READY. WE WILL RELEASE IT WHEN IT IS DONE!!" Who are they trying to make look good? Why impress Warner with 1 weeks worth of production, when you can impress the consumer 2 weeks later? It seems short-sighted to make themselves look good at the expense of ATARI's reputation. Well enough of that, I want to get back on the subject of good news. Months ago I also reviewed a Millipede for the 800 (or 5200 I don't remember). I sent my comments back and just last week received a letter back for Richard Frick thanking me and giving me a list of changes they have implemented. When I talked to him he recalled when the comments came back and how the programmer grumbled about doing any more changes. However after the changes were made the programmer has become very excited about the new program. Now ISN'T that a heart warming story. It sure made my week. I hope we see more cooperation like that in the future. Second, as Franz hinted I never received a copy of Centipede to review from ATARISOFT nor was I even told about any Centipede carts. Ignoring the fact that is rather insulting, it is not in the best interests of ATARI. We should demand quality from any product ATARI puts its name on. Considering there is expertise here in Coin-Op to test and evaluate this product, they should be very interested in hearing from us. Since there were no designer credits, I guess it was hard for them to dtermine who to come to but they could have found out. Since there seems to be new policies regarding credits for our games and since there seems to be a lack of trust between certain individuals and management, couldn't we have some WRITTEN information of these policies. In particular, can someone reassure us that the current bonus program is still in effect and will remain so until xxxxx. Can the current policy on credits be written down and include if possible the current policy on credits with respect to 2600, 5200, 800, and ATARISOFT conversions. For everyones information I was not told that my name would appear on the 2600 Millipede documentation. I had to ask Steve Calfee. In fact it seems logical that the names of all members of the Coin-Op team responsible for developing the game should appear. Can someone write down whether the ASTARISOFT software will bring royalties to Coin-OP? Now for my pet pieve, can we get a little better accounting on the bonus program? I was given verbal assurance by John Farrand that this was possible but maybe he doesn't understand how hard or time consumming this is. In the past ATARI didn't want to do this because this would release information that the competition is not supposed to know. In fact if you want to know the VCS sales of a cart, just call your friends at Activision or Imagic or Starpath for the info. I was also told that the other divisions just paid monies to Coin-Op but did not supply the number of units sold or other info. With the new organization I would hope that this information would be available. The kind of information I would like to see with our bonus checks is 1) Coin-Op units sold (at full price) 2) those sold at a loss (thus no royalties for them) 3) Coin-Op kits sold (as above) 4) same for 2600, 800, 5200 and ATARISOFT. P.S. They (Marketing) released the 2600 Millipede on Monday before they could test the cart for the required 40 hrs. There was a screen roll failure after 35 hrs. So by the book they should not have passed the cart for release.

Found this interesting memo on a tape backup: Comments about 2600 Millipede cart dated 1/23/84, by Todd Walker, Eric Ginner, and Franz Lanzinger 1-31-84 Bar at bottom is probably there to show the edge of the screen. Is this really necessary? Bees are to wide, and they fall much faster than in the coin-op. DT should say DDT. They are transparent when they ought to be solid (you can see mushrooms behind the DDT sometimes). shooter ought to be different color than mushrooms 1200 score looks strange, yet 1000 looks good. Heads of millipede segments don't stay at bottom two full times across. DDT bomb explosion too tall, and not wide enough Inchworm slow down player too, not just the creatures No collision detect between millipede segments and other motion objects. This is a serious problem, causing segments to overlay one another sometimes. You'll shoot what looks like one segment, and there is another behind it to kill you (unfair!). The screen scrolls wildly sometimes on higher levels, completely screwing up the players orientation. We have this on tape. Doesn't tell you when the next bonus is at bottom of the screen. No collision detect between player and mushrooms. Segments come down way too fast after hitting poisoned mushrooms. After hitting inchworm, sidefeed sends out two segments at a time. No 2 player option. Sidefeed too fast (much more difficult than in coin-op, especially at higher levels, where it seems impossible to deal with, even at the start of a game). Bees leave an evenly spaced trail of mushrooms. Ought to be random. Beetle is counted as part of bonus wave (shouldn't be). Sequence of bonus waves may be off (too many bee waves). DDT explosion stopped short once, don't know why. Bonus waves don't increase in duration at higher scores (this is the "best part about millipede" according to FXL) Shots that hit millipede keep going to the top of the screen. We have this on tape too. The trick flower trick doesn't work (probably because there is no collision detect between player and mushrooms). The trick works like this: You sit directly underneath a flower, and when the screen scrolls down the flower gets erased. This lets you get rid of a particularly pesky flower in the coin-op version. If this was helpful in any way, give a copy of this to Steve Calfee.