solidcorp

Very nice.

Combat - steerable shots FTW Space Invaders - it "felt" better to me, the base seems to move so slow and be so big in the arcade. Warlords - idk, just feel that way Circus - color, gameplay Air Sea Battle and breakout have to be a tie for me I think.

Both! Racing the beam is a fantastic book. The only one that I've found that chronicles that great era, introduces the players in context, discusses how the hardware drove the market, and where the market went from there and why. Once Upon Atari is another animal all together - a fantastic, personal documentary by one of the most influential game developers of all time. The interviews, by allowing the people at Nolan Bushell's Atari, and Nolan himself to tell you their stories and perspectives allow you to get to know these people in a way that I don't think you can from anything in print. Racing the beam is the book that inspired me to write Star Castle for the 2600. The chapter a Yar is born drew my interest to Howard Scott Warshaw, which led to my getting Once Upon Atari, and reading all of the interviews about Star Castle and Yars Revenge. I was a huge fan of both games and never knew their connection. D. Scott Williamson

If you have any trouble reading the floppies, after you have exhausted all other options, you may be able to read them by carefully cleaning them with a cotton swab and rubbing alcohol. I just recovered ALL my data off previously unreadable 3.25" Amiga, PC, & ST Floppies. I wish I knew about this when I was recovering my 8 bit Atari floppies. See my photo blog with instructions here I repeat: I tried everything to repeatedly read these disks and they always had bad sectors until I cleaned them, then they read like new. (I only cleaned the ones that needed it) Do this at your own risk and I ONLY recommend it as a last effort. Here are some pictures - my photo blog linked above has more images and a complete description of what I did and plenty of warnings about what not to do. Good luck.

Thanks, I saw that but forgot it. I think they still have the support, or it is easy to add. My only unix machine is an ancient laptop running Xubuntu without a SCSI interface anyway, as a matter of fact I only have one old web server that has a SCSI card in it. I ended up backing up the drives by taking disk images of them with Roadkil's Disk Image, a tool off the Ultimate Boot CD for Windows, an excellent collection of the best free tools adapted from the original Ultimate Boot CD. Anyway, I have the raw binary disk images backed up and now I can mine that however I want at my leisure. (the byte level disk format is even documented on many sites like this one) Thanks for the tip.

The system was called "Nuon". The company VMLabs, the tech was used in a couple of DVD Players around 2001, it was very hard to develop for, only a few games were produced like Tempest 3000, Iron Soldier 3 etc.. You can find more information here http://www.nuon-dome.com/ . The latest SDK is available in the download section. It would be awesome if you could find some more Panther information, as there is very little stuff to find for this system unfortunately. The attached PANTHER folder was on my ST C: boot disk drive. Most of it is a standard 68k ST development environment. Of particular interest are the header files PAN.H and SPECIAL.H which are dated 1/10/1991 and 12/9/1990 respectively. PANTHER.zip

The Video Game Summit, usually in July in Lombard IL. isn't exclusively Atari but they have tons of Atari and other systems displayed there, maybe you could work with them as well. http://avc.atari-users.net/VGS.html

Yea, full dev docs I think - from emacs instructions to tech specs and floppies too. I just went and looked and couldn't find them. That's not to say I don't have them, it's just that at least they are not where I expected to find them. I may have just came across the floppies and thought I had the manuals. If I come across them, I'll let you know. I thought it was lame. After working on the Lynx, going back to a display list platform with just a single scan line video buffer more like a 400/800/7800 just seemed like a big mistake. For that matter, does anyone have any documentation on the later Atari quad core "Project X"? It was post PSX and I think Bill Rebock left Sony to join Atari on that one, and the Brittish tech guy, Miller I think his name was, was the head engineer.

PART III : "The stun runner bug" To refresh your memory, here is where I began my journey... Well, um, I did the game like 20 years ago (1990-1991?). I still have the source code, sort of... The Amiga 3000's battery leaked in storage and ruined its motherboard. The hard disk *might* still work, I did just recover all my old ST files last year from 25 year old Supra and Mega drives. I also have the Amiga floppy disk backups somewhere and *might* be able to restore them *if* I can find a floppy drive and the right software. ... As far as speed is concerned, there is (or at least should be) a sweet spot, or what is now in racing games called a blue line, an optimal path through the levels. In stun runners tubes it would be on the outside, where a pendulum would swing if you were truly racing around the corners. The stars in the first levels are placed on that line to train you where you should be on the track for maximum speed. In the flat areas only the walls slow you down, and I don't think anything slows you down while boosting. The problem you *may* be having with S.T.U.N. Runner (if there is not a bug) is that the controls are touchy and you really can be harshly penalized for climbing too high up the walls. I put a lot of work into the centrifugal sweet spot aspect, if I didn't then the star placement painstakingly reproduced from the coin op wouldn't work. Well, here we are. I have since verified the function of the Lynx game and the coin op game and they are clearly different as described, and I have managed to recover the Lynx source, but the story doesn't end there. First, let's look at the offending code, here is an excerpt from the function xyphysics in srship.src, starting at line 534: ; ***** DETERMINE WHETHER TO USE TUNNEL OR FLAT PHYSICS lda shipterrain cmp #WARP beq .38 bit #FLATFLAG bne .50 lda shipangle cmp #TUNFLATR+1 bge .50 cmp #TUNFLATL-1 blt .50 .38 ; ***** TUNNEL PHYSICS ***** ; ***** CURVATURE DECELERATION ; sweetspot = shipangle-(curvature+sign(curvature))*16 ; there is no curvature deceleration on flats stz temp0 lda dx2tab+2 beq .41 bpl .49 dec dec .49 inc asl asl asl asl .41 eor #$ff sec adc shipangle ; set max speed depending on deviation from shipangle ; the net is $80-A with max check bmi .47 eor #$ff inc .47 ; give a little lee way in terms of max speed sec sbc #$80 bpl .42 lda #shipmaxvx .42 cmp #shipmaxvmax blt .43 lda #shipmaxvmax .43 sta shipmaxv .70 ; ***** CENTRIFUGAL/GRAVITY FORCE FOR TUNNEL ; CG pulls toward shipangle-(curvature)*16 stz temp0 lda dx2tab+2 beq .72 asl asl asl asl .72 eor #$ff sec adc shipangle ; A contains the deviation from the CG vector ; add -A/4 to shipvx eor #$ff inc bpl .71 dec temp0 .71 lsr temp0 ror lsr temp0 ror adc shipvx sta shipvx ; if the ship is moving slow and shipangle has the ; opposite sign of the curvature then tell the person ; how to play lda speed cmp #20 bge .7f lda dx2tab+2 beq .7f bmi .77 lda shipangle bpl .7f bra .78 .77 lda shipangle bmi .7f .78 ; try to announce "the outside wall is faster in turns" lda #OUTSIDEWALLSBIT sta msgbits lda #msgtime sta msgtimer .7f jmp .80 .50 ; ***** FLAT PHYSICS ***** ; reset shipmaxv lda #shipmaxvmax sta shipmaxv ; ***** CENTRIFUGAL FORCE FOR FLATS ; force pulls shipx in d2x direction ; shipvx = shipvx+shipv*(curve+-1)*4/256 lda #4 ldx dx2tab+2 beq .60 ; bpl .51 ; dec ; dec ; dex ;.51 ; inc ; sta MATHD ; stx MATHC ; lda shipv ; sta MATHB ; stz MATHA ; WAITMATH ; lda MATHG ; asl MATHH ; rol ; asl MATHH ; rol ; this centripital force adds 1, or -1 to shipvx ; depending on the direction of curve only ; if the ship is moving fast enough bpl .51 lda #-4 .51 ldx shipv cpx #$40 bge .52 lda #0 .52 clc adc shipvx sta shipvx .60 ; ***** FRICION ON WALLS FOR FLATS The cause of the observed behaviour is due the these 5 lines near the top. lda shipangle cmp #TUNFLATR+1 bge .50 cmp #TUNFLATL-1 blt .50 This is very peculiar in the following ways. The preceding code, clearly identifies and acts on the type of track (flat or tunnel) that the ship is ; ***** DETERMINE WHETHER TO USE TUNNEL OR FLAT PHYSICS lda shipterrain cmp #WARP beq .38 bit #FLATFLAG bne .50 but goes on to test the ship's angle in the tunnel on the following 5 lines and if in the bottom, go execute the flat track physics code lda shipangle cmp #TUNFLATR+1 bge .50 cmp #TUNFLATL-1 blt .50 Later in the FLAT PHYSICS section of the file, note that code for centrifugal force was written but commented out. ; ***** CENTRIFUGAL FORCE FOR FLATS ; force pulls shipx in d2x direction ; shipvx = shipvx+shipv*(curve+-1)*4/256 lda #4 ldx dx2tab+2 beq .60 ; bpl .51 ; dec ; dec ; dex ;.51 ; inc ; sta MATHD ; stx MATHC ; lda shipv ; sta MATHB ; stz MATHA ; WAITMATH ; lda MATHG ; asl MATHH ; rol ; asl MATHH ; rol Both of these suggest that the current function was not in the original design but were changed for some reason. OK, so now I've found the source of the issue (pardon the pun) but could still not tell you weather this was an error, or deliberate, so I pulled all the paperwork back out of storage and read every note and piece of correspondence I still have from S.T.U.N. Runner and found this. It is the official Lynx S.T.U.N. Runner Atari Games review, the pre-release beta review of the Lynx game by the main programmer of the coin op game. It all came back to me right in item 2. Item #2 I did exactly that, and to further adapt the game for the Lynx, Atari Corp management/QA requested I treat the floor of the tunnels the same as flat sections of track. Most of the time, enemies would force you off the floor anyway. The whole Lynx recovery photo album inlcuding some coin op source, the full resolution letters, and more can be found here: https://picasaweb.go...feat=directlink So, the bottom line is, yes there is a discrepancy, but it is not a bug, it's an adaptation and at one point in development, it was true to the coin op. That was fun and the very happy side effect is that I have all that source material recovered and backed up on DVD now. Thanks for pointing it out Tursi!

PART II : "recovering files from the raw binary backup data" I mentioned a batch file I used to repeatedly run ADFRead until a disk was fully read (or forever). It's a little tricky because when a disk is fully read, ADFRead deletes the status file and if you run it again, it starts all over. This batch file will continuously run ADFRead as long as the associated .status file exists. Change "AdfTargetFilename" to a filename of your choice (without spaces), the .ADF and .status extensions are added for you. Here is the batch file. set ADFNAME=AdfTargetFilename :loop adfread %ADFNAME%.adf if exist %ADFNAME%.adf.status goto :loop So at this point all I had were 800K disk images, no files or folders. Each of the three backups was written with a different version of the Amiga Quarterback backup program. To my astonishment, I was unable to find a single PC tool to extract files backed up with Quarterback without emulating an Amiga, so I looked at the content of the disk images in a hex editor and fortunately was able to see human readable filenames and even source code. From the binary images of the disks I was able to reverse engineer enough of the data format to write a ruby script I used to trim the disk header off each disk image, concatenate them into one large data file, and then extract the full directory structure. If you are interested, here is the hackish mess of the code that I wrote only to recover the S.T.U.N. Runner source. #!/usr/bin/env ruby =begin 2107 or 83b entries e8ec is an offset to what looks like graphics offset e2d4 (226,212)directory ends and data starts 51 42 30 31 QB01 disk # nfiles? ?????? offset to start of data? idk 01 00 00 00 00 6D 00 00 00 CC 00 99 QB01.....m...Ì.™ [file size ] ndir typ[filename terminated with 00 00] 07 CE 5D A4 00 22 00 D3 0A A3 00 2A 00 C0 66 69 6E 61 6C 73 6F 75 6E 64 73 00 00 .Î]¤.".Ó.£.*.Àfinalsounds.. [file size ] typ[filename terminated with 00 00] 00 00 06 18 00 22 00 D3 0A A3 00 00 00 40 2E 66 61 73 74 64 69 72 00 00 .....".Ó.£[email protected] [file size ] typ[filename terminated with 00 00] 00 00 18 BA 13 00 04 64 08 7F 00 00 00 40 42 45 54 54 45 52 30 31 2E 50 57 32 00 00 ...º[email protected] [file size ] ndir typ[filename terminated with 00 00] 07 CE 6E D4 00 4F 00 4D 09 77 00 1C 00 C0 71 73 75 62 66 61 6E 00 00 00 00 01 A4 00 4F 00 4C 02 CC 00 00 00 40 2E 66 61 73 74 64 69 72 00 00 00 00 01 7A 00 4F 00 4C 01 45 00 00 00 40 62 61 73 73 2E 73 70 6C 00 00 22 qb01 0x80 directory 0x40 file 0xc0 ??? qbv2 0.4 "QBv2"1 4.4 offset 0e,0f file count 4b size 6b ukn 4b type xfilename terminated in 00 00 4078a - 42e2d testcart.src 4351f 67d86 00 00 26 A3 00 74 02 6D 04 19 00 00 00 00 26 A3 00 74 02 6D 04 19 00 00 00 ..&£.t.m.... 00 40 74 65 73 74 63 61 72 74 2E 73 72 63 00 00 @testcart.src.. size4, 00 00 26 A3 00 74 02 6D 04 19 00 00 00 00 01 08 5A 05 04 44 02 DB 00 00 00 00 26 AA 00 74 02 6D 03 86 00 00 00 00 16 EB 00 74 02 6D 02 04 00 00 00 00 26 DE 59 FB 04 44 02 CC 00 00 00 00 17 06 5A 05 07 14 02 E0 00 00 size ???(properties, loc) type 00 00 26 A3 00 74 02 6D 04 19 00 00 00 40 00 00 26 AA 00 74 02 6D 03 86 00 00 00 40 00 00 26 DE 59 FB 04 44 02 CC 00 00 00 40 1a 1b 2a QVc2 6e000 =end #~ class Folder #~ @entries #~ def initialze(name, e) #~ @entries = e #~ Dir.mkdir(name) #~ Dir.chdir(name) #~ Dir.chdir #~ end #~ end def extractfile(hSourceFile, list,index) name = list[index][0] size = list[index][1] puts "Creating file #{name} (#{size} bytes)" hDestFile = File.open(name,"wb") hDestFile << hSourceFile.read(size) hDestFile.close() index +=1 return index end def processFolder(hSourceFile, list,index) name = list[index][0] numEntries = list[index][1] puts "Creating folder #{name} (#{numEntries} entries)" if !Dir.exist?(name) Dir.mkdir(name) end Dir.chdir(name) index +=1 for i in 0...numEntries puts "\t#{name}[#{i}]" index = processlistentry(hSourceFile,list,index) end puts "Exiting folder #{name}" Dir.chdir("../") return index end def processlistentry(hSourceFile,list,index) if index < list.size puts "processlistendtry #{list[index].inspect}" if list[index][-1] == "directory" index = processFolder(hSourceFile,list,index) elsif list[index][-1] == "file" index = extractfile(hSourceFile,list,index) end end return index end if false FILESIZE = 901120 diskfilenames = [ "STUN_Runner_final_7_22_QB40_1_of_11.adf", "STUN_Runner_final_7_22_QB40_2_of_11.adf", "STUN_Runner_final_7_22_QB40_3_of_11.adf", "STUN_Runner_final_7_22_QB40_4_of_11.adf", "STUN_Runner_final_7_22_QB40_5_of_11.adf", "STUN_Runner_final_7_22_QB40_6_of_11.adf", "STUN_Runner_final_7_22_QB40_7_of_11.adf", "STUN_Runner_final_7_22_QB40_8_of_11.adf", "STUN_Runner_final_7_22_QB40_9_of_11.adf", "STUN_Runner_final_7_22_QB40_10_of_11.adf", "STUN_Runner_final_7_22_QB40_11_of_11.adf"] #concat files without headers hcatFile = File.open("STUN_Runner_all_adf_conat","wb") for i in 0...diskfilenames.size hSrcFile = File.open(diskfilenames[i],"rb") copysize = FILESIZE-14 hSrcFile.read(14) if i==0 hSrcFile.read(1) copysize-=1 end for j in 0...copysize hcatFile << hSrcFile.read(1) end hSrcFile.close end hcatFile.close exit end hFile = File.open("STUN_Runner_all_adf_conat","rb") #fileheader = hFile.read(15) #puts fileheader.unpack("CCCCCCNNnC").inspect #puts fileheader.unpack("CCCCCCCCCCCCCCCC").inspect files = 0 directories = 0 sizeindir = 0 data = Array.new for i in 0...2107 direntry = hFile.read(15) direntrydata = direntry.unpack("CCCCCCCCCCCCCCC") name = String.new # 64 (40) first two size # 192 (C0) directory 2 bfore file count while true n=hFile.read(1).unpack("C")[0] if n!=0 name << n else break end end if direntrydata[-1] == 192 entries = direntry[-4,2].unpack("n")[0] #puts "\t#{'% 6d'%i}\t #{direntrydata.inspect}\t #{name} directory entries #{entries} previoius dir size #{sizeindir}" directories+=1 sizeindir = 0 data.push [name,entries,"directory"] elsif direntrydata[-1] == 64 size = direntry[1,4].unpack("N")[0] sizeindir+=size #puts "\t\t#{'% 6d'%i}\tfile #{direntrydata.inspect}\t #{name} file size #{size} dir size #{sizeindir}" files+=1 data.push [name,size,"file"] else puts "#{'% 6d'%i}\t#{direntrydata.inspect}\t #{name} unknown" end end puts "directories #{directories} files #{files}" # throw away one more zero then start processing data hFile.read(1) targetdir = "extracted" if !Dir.exists?(targetdir) Dir.mkdir(targetdir) end Dir.chdir(targetdir) index = 0 while index < data.size index = processlistentry(hFile,data,index) end Dir.chdir("../") It worked and I now have the full source, which I wrote under the pseudonym of Brian Walters Now I can finally start thinking about that "bug"...

I really don't know if anyone is still reading this but I couldn't let this issue go... PART I : "finding the disks and recovering data" At the time of my last post, I had gone through hundreds of diskettes in several boxes looking for any source from the Lynx games. I had mixed success recovering files from PC, ST, And Amiga disks (using ADFRead) but had found no trace of the Lynx disks that I knew existed, so I went back into storage to dig for the right box. Here is my crawl space. it may not look like much, but in this picture are two full Apple ][ systems, an Epson LX-80 dot matrix printer, an ST, an Amiga3000, and development hardware, software, and documentation for Sony Playstation, Nintendo 64, Super Nintendo, Gameboy Advance, Gameboy color, Gameboy, Sega Genesis (Accolade's custom hardware), Atari TT/STe/ST, 400/800/XE, Jaguar, Panther, 7800, 2600, and of course Lynx. There is a mountain of documentation from Atari in their original binders. There are also boxes of unopened games I wrote in there too. The real treasure is the box I just unearthed in the foreground, it contains the final notes, source code, cartridges, and backups for my Lynx games, Roadblasters, Toki, and S.T.U.N. Runner. I eventually did find the box with my Roadblasters, Toki, and S.T.U.N. Runner source backups, including VHS playthroughs, audio tapes, coin op source code, and unopened copies of the games. Lynx Toki, RoadBlasters, and S.T.U.N. Runner source materials. S.T.U.N. Runner Lynx game, final source backup disks, milestone disks, audio tapes, full playthrough videotape, keys to the coin op, notes, bug reports, and coin op source code. Original boxes of Toki and S.T.U. N. Runner Lynx Cartridges. So I tried to recover the disks first using ADFRead which worked perfectly for Roadblasters. I started running into trouble on Toki and S.T.U.N. Runner. ADFRead is not perfect, it does not necessarily read everything on the first try but if it is not 100% successful, it writes a .status file with a map of good and bad sectors that it uses on successive tries to focus on unread sectors and refine the image. Some disks read and some wouldn't. I eventually wrote a batch file that would continuously retry a disk and I could watch the bad sectors drop out of the .status file, but many disks had areas that just wouldn't read. So I paid the $150 for the Kryoflux board. I thought it would help with data recovery. It did not. It probably is excellent at duplicating copy protected disks but it really is incapable of recovering weak or bad data. I'm debating whether I should keep it for my remaining disks, or sell it. idk. By the way, I bought the "premium board" for about $20 more and didn't realize it was no different from the standard board except it came with floppy drive and usb cables that I already have - but, and this is a huge but - it did NOT come with a power supply for the board to power the floppy drive with - I had to improvise a power supply. If you are thinking of buying the board, just be aware of that. Left with no other options, I decided to have a look at a problem disk and this is what I found So I opened the disk and found this I suspect the material is either the case lining attached to the disk, mold or mildew. Without any other options, I mustered the courage to do what I had done to other magnetic media like cassette, VHS, and tape backup equipment and attempt to clean the disk with isopropyl alcohol. It worked perfectly, if you would like to see detailed instruction how I cleaned the disks for recovery with lots of photos check out my photo blog of it here: https://picasaweb.google.com/spot1981/111119FloppyDiskRecovery?authuser=0&feat=directlink Ultimately I had to crack open and clean all the remaining disks but I was able to read every byte of of each of them.

Lots of ST floppies were formatted using 10 sectors per track instead of the regular 9 sectors per track. PCs don't know how to handle such disks. But if you have lots of floppies to preserve, I would recommend the KryoFlux interface. This board connects standard PC drives to an USB port and makes it possible to read nearly all kinds of floppies (Amiga, ST, C64, Atari 8-bit, etc.) including copy protected floppies. Without the Kryoflux board, you can use the HxC floppy emulator software to read ST floppies using a regular PC drive. It uses fdrawcmd.sys which enable low-level access to the floppy interface enabling reading of non standard formats. Robert Thanks Robert!!! That may come in useful later. There were some ST floppies that I really wanted to recover, but I think I found the same files in my hard drive backups from last year. Still, I've made a note of your suggestions and I'm using fdrawcmd.sys with ADFRead right now to recover my Amiga floppies... More on that in the next post!

The adventure's not over... So I went into storage and dug out all my old ST, PC, and Amiga floppies. I also dug out and installed a second floppy drive last night so that I could use the two drive trick with ADFRead (http://www.winuae.net/frames/download.html) to read the Amiga floppies on the PC. I haven't found the S.T.U.N. Runner source yet but I did come across some really interesting stuff, like 1991 Lynx and Lynx titles sales figures and development contracts. I also found all the original Lynx development environment floppies and updates, though I didn't try to read them. A lot of my old ST floppies don't work in the PC, but I'm not sure the disks are necessarily bad, they may just be low density or some different format, idk. I did find multi disk backups of my drives that hopefully have S.T.U.N. Runner on them, but the problem may be that they were backed up with Quarterback on the Amiga, so I'm not really sure how I'm going to get the source data out if I can recover those disks - maybe in the emulator? I did look at another Quarterback created backup and I did see human readable code in there, so at least it's not compressed and completely opaque. More to come... Footnote: I do this sort of personal game-dev archeology every so often, something like this comes up and I get panicky about losing this data forever, or I find a new emulator, or interface, and before you know it I'm hacking ancient SCSI drives, or recovering 3 1/2" floppies, or making a SIO2 cable to read whatever I can from my A8 5 1/4" floppies... Thanks for the motivation.

By then, Atari Games (coin op) had split from Atari Corporation (home games and computers) and we had to license titles like S.T.U.N. Runner, RoadBlasters, Vindicators, Gauntlet.... http://en.wikipedia.org/wiki/Atari_games http://en.wikipedia.org/wiki/Atari_Corporation The terms must have been favorable because we did a lot of Atari Games' games.

No, they don't. The 2600's 6507 runs at 1.19MHz. The 8-bit's 6502B/C runs at 1.78MHz. HAHAHAH, I knew both those things and I totally forgot, it's been a long time, thanks for the clarification.

I asked for it, but it wasn't Atari's fault, they got the license from TAD and they did provide a coin op. I don't know if TAD had the source code. Also, remember that before the Lynx, most coin op ports were mere shadows of the arcade experience and having the source to the arcade machine was not considered vital. The folks at Atari tried to provide good development software, but I just don't think they knew how, and they were overtasked/understaffed. We were still supposed to use emacs on the ST for Panther and later Jaguar development for example, and it was all edit, exit, compile, run, repeat style dev. After working on the Amiga, going back to that environment was really tough. For ST development I used ASSEMPRO, an integrated editor, compiler, and debugger. Thanks, those are my three Lynx games. I am a lead, but I'm also a team member... I've been programming since I was 10, I've never stopped programming, and I don't plan to... After Atari, I was lead on all the games at my first company, SOLID Corp. on SNES, Genesis, and GameBoy. At my second company, Inland Productions where we did PC, PSX, N64, PS2, and Xbox games, I wrote most of the engine code and all of the PS2 VU code. Currently at High Voltage Software, I've written and maintained engine and game code on PC, GameCube, Wii, 3DS, PSP, PS2, PS3, Xbox, Xbox360 and other stuff I can't talk about. I'm one of the few there who is not afraid to read, write, and debug, assembly language on anything, and I specialize in vector assembly (think x,y,z,w). I think it's funny that the PS3, Xbox360, and Wii all have slightly different flavors of the same CPU, the Power PC, which means that you could write some code that could be shared between them, not that you would want to. I work in Direct3D and OpenGL, but prefer lower level alternatives to GL, because it's implementation usually is really easy to get started with but you inevitably paint yourself into a performance corner later and have to rewrite the renderer. I also write shaders in HLSL & Cg. I use C an C++ every day, I do way too much Ruby scripting and as a result I'm kind of weak in C#... I'm trying to fix that. I also do recreational programming, like Star Castle on the 2600 (but there was waaaaay more to that project than programming), and writing code for the CNC machine I designed and built.

Thanks about Toki... I had the coin op in the office. We pulled all the ROMs, dumped them,and were able to piece together all the sprite graphics in goofy colors. The artists then were able to shrink and color them but that looked awful, so they hand redrew everything, but the proportions were perfect. I also installed a pause switch that would halt the coin op CPU, and if you were lucky you could even unpause it. I had no source code or other materials, all the code was made by observation alone. I ported every aspect of the game I could observe and was really sad when we had to pull the scrolling level intro maps out of the game because they didn't fit on the cartridge. That game was the pinnacle of my Lynx titles.

I think I just found the WWM source.

It was like Toobin, but not quite as creative and with more direct controls. Here are the credits extracted from the DISK A image binary, special characters and all. PROGRAMMERS .. D. SCOTT WILLIAMSON & .. ED SCHNEIDER .. .. GRAPHICS ....H BOB NAGEL .. .. MUSIC .. DAVID TUMINARO .. STAN HOOVER & ....H CHUCK STENECK OF .. MUSIC COMP INC .. .. DESIGN .. JOHN,CRAIG,ED,SCOTT,BOB ....H LARRY,STEVE, AND STEVE. .. .. John must be John Scrutch out of Sunnyvale CA Craig is Craig Ericson, producer or director of product development Larry is Larry Siegel VP of Atari Steve is Steve Ryno The other Steve is Steve Harris.

I wasn't referring to flickering, you can re-strobe the position registers to reposition players mid scan line to get one player in two places horizontally on one line... but now that I think about it maybe the A8 couldn't do that because it had no equivalent of HMOVE or a position strobe.

I think you are going to be soooooo disappointed LOL Good luck though, and if you do get it up and running, be sure to tell me and the rest of the world what you think. Seriously... I'm sure I've had worse critics. Remember, it's an STe game, I don't remember if I had to do anything special in STEAM, I probably just selected the platform, region (US), and ROMs for the machine.

I just spent the last 9 1/2 hours recovering raw data off my 20 year old Amiga 3000 hard drives... I pulled out the Amiga, I took it apart (the motherboard is shot), I removed the two SCSI drives (a whopping 50 and 100 megabytes, that's right, megabytes), I found a PC here with an old SCSI 1 card in it, I spent a good while getting the drives to spin up (when they sit that long the lubricant in the hubs gets stiff, you can feel it buzz to try to start but it doesn't and it times out, I just keep power cycling them patiently until they kick free and spin up, I never hit, tap, rap, heat, or cool a HD, those are destructive wives tales) I only have one set of SCSI terminators so I can only work on one drive at a time and they can't be hot swapped so I have to shut down and restart the PC each time First I tried to use DIXML to back it up but it only works on mounted volumes I guess I tried WinUAE Amiga emulator but I didn't have the ROM files, or Kickstart, or Workbench so I bailed on that plan. Then I was able to look at one drive with ADF View, but only Bubsy map files were on there (I had forgotten Accolade used Amiga's for Bubsy map development) Then I tried the Ultimate Boot Disk and used Road Kill's disk duplicator to take a full raw dump of the physical hard disks. Looking at the contents of the files I can see the file system and all the human readable files (YAY!!!) ... Including Lynx source for a bunch of sound and technical demos and prototypes (Double YAY!!!). But there is no trace of S.T.U.N. Runner!!!! AAAAARRRGGGGHHHH! I know that Amiga was the only machine used to make it. I even searched the disks images for "NME" which is what I know the enemies were called and looked for compressed .zoo, .arc, .lzh, .lha, and .zip files. I must have backed it up to floppies. I have them, I know where they are, but they can't be read by PC's (well, not easily), and like I said, the Amiga is a non starter. So, for now... all I can say is "I tried".

I probably could go on forever, but I will leave you with this... We got an ST video digitizer in the office and had a lot of fun with it. It wasn't terribly useful for games because it took low framerate video and low resolution black and white pictures, but it was really cool. You have to remember that VCR's were just becoming commonplace, camcorders were new, thousands of dollars, and as big as a scuba tanks. This thing was solid state, small, and portable ~ well as long as you could plug an ST into the other end of the 12 foot cord. When I restored all the files from my 20 year old ST drives last year I found a bunch of stills from the office. This is what I looked like around 1991 at my desk at Atari in Lombard with my bulletin board and equipment behind me. The entire album is here and has pictures of a lot of the people from the office, as well as earlier low and high color versions of the WhiteWater Madness title screen being edited in Neochrome and Spectrum 512. There's also some other pictures of my Atari ST desktop and drives from work. The only person in the pictures that wasn't an Atari employee is JoAnn Vasbinder, my then girlfriend and now wife of 19 years. Feel free to look at the rest of my picasa web albums. The making of my Atari 2600 Star Castle cartridge is up there as well as a lot of recent (post 2008) non videogame projects. There's nothing too personal up there so feel free to look around.

Lynx development on the Amiga was the first multitasking development environment I worked with. You could have your editor open in a window, another command window for builds, and a third debugging window open for your Howard board. The Amiga editor CED was very capable, and the debugger was quite advanced too. The GameBoy development environment also had dedicated hardware but the interface was almost exactly that of DOS Debug. Command line debugging, very difficult, er cumbersome. BattleZone on the GB is all character graphics by the way, no vectors. I wrote a 3D editor and wireframe renderer in QBASIC. I modeled all the game assets (tank, super tank, saucer, buzz bomb, cube, pyramid, and bullet), and then code would render all the rotations at each scale. For each frame It generated source code for the graphics in GameBoy format. It only stored the 8x8 characters that had pixels in them and created a map of where to draw them for the frame. The graphics could be flipped left to right too to save room in the ROM. The background was scrolling character graphics, and the tanks and obstacles were multiplexed, or as you would say now "temporially dithered" (they flashed) and they were composed of all the available sprites.

I think it shipped. IDK. The STe was not revolutionary, it had a blitter, 4096 colors, and better sound, but was the same machine with some backward compatibility issues. The new multimedia features were neat but not necessary, not enough in my opinion to drive everyone who already had ST's out to buy new STe's. I didn't have an opinion at the time, I was just excited to be working at Atari on a game.