Jump to content

solidcorp

Members
  • Content Count

    459
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by solidcorp


  1. I haven't tried this lately but Linux does have support for Amiga partitions. I recovered my friend's Amiga disk about 7 years ago with Debian. It was an IDE disk so I just stuck it in my PC and copied off his files. It isn't clear to me if recent distros are still building in that support or not though I suppose you could use an old Knoppix release or similar to avoid building kernels and suchlike.

     

    These days I would ddrescue to image the entire disk then loopback mount the partitions. You may only have one good crack at reading that old disk hence imaging with a rescue copier. I would also just put the disk in a USB enclosure.

     

    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.


  2. 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.

     

    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

    • Like 3

  3. Very interesting read... keep 'em coming!

     

    Do you have any "secret documents" about the Panther console, that nobody knows about?

     

    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.

    • Like 1

  4. PART III : "The stun runner bug"

     

    To refresh your memory, here is where I began my journey...

     

    Though now that I have you, let me corner you about the one and only thing in STUN Runner that bugged me (and only a little, though I considered it cheating). You only slow down when you change polygons - meaning you can maintain top speed around corners by staying on the ground! Not true in the arcade! Respond? ;)

     

    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.

    1. 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
      	


    2. 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.

     

     

    IMG_1346.jpgIMG_1347.jpgIMG_1350.jpgIMG_1349.jpg

     

    Item #2

    IMG_1351.jpg

     

    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!

     

    :)

    • Like 9

  5. 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"...

    • Like 2

  6. 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.

     

    IMG_1071.jpg

     

    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.

    IMG_1072.jpg

     

    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.

    IMG_1076.jpg

    Lynx Toki, RoadBlasters, and S.T.U.N. Runner source materials.

     

    IMG_1078.jpg

    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.

     

    IMG_1080.jpg

    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.

     

    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.

     

    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

    IMG_3994.jpg

     

    So I opened the disk and found this

    IMG_4000.jpg

     

    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.

    IMG_4003.jpg

     

    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.

    • Like 6

  7. 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.

     

    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!


  8. @solidcorp - thanks for looking, sounds like that was an adventure in itself! :)

    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.

    • Like 3

  9. Wow... so while Atari licensed the game, the original developers did not even give you the sourcecode!?

    I am no coder, but you´ d think that the sourcecode was an important part of such a deal. No source means more work for Atari employees. More work = higher production costs.

    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.

    I´m often surprised about how Atari handled things. But well, what to expect from a company that had its devs use crippleware a few years later in development for Jaguar games?

    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.

    About Toki: I am not a huge fan of it, but that comes mostly from my experiences with the Genesis-version back in the day. When I played it on Lynx a year ago I was surprised how much better it is. So congratulations on that one too.

     

    Did you work on any other Lynx-games beside Road Blasters, S.T.U.N. Runner and Toki? Now that I "know" you (slight exaggeration) I´d like to look at your other games too.

    Do you still program yourself or are you more in a position leading others mostly? I mean, if you still programmed at work I find it even more amazing that you spend your free time doing something like Star Castle.

    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.

     

    :)


  10. 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.


  11. 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.

    • Like 1

  12. 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.


  13. Now I want to try to get the source code off that old Amiga drive. (Don't hold your breath, I'm not holding mine)

     

    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".

     

    :)


  14. Yeah White Water Madness was advertised for a ton of systems, but I didn't think it was ever started for any of them. I didn't even know that there was an ST/STE version planned until a few years ago, much less that it was the original version. Very cool.

     

    Do you have any other interesting stories about your time at Atari? I'm finding all of this to be fascinating. :)

     

    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.

    Blank_002.jpg

     

    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.

    • Like 1

  15.  

    Hehe, must have been a big difference to switch from developing Lynx-games to doing stuff for the GameBoy. I would think that you get used to the luxury of the more powerful Lynx-hardware and then working with the GB posed a serious challenge. I am no coder myself, but I do find the GB port of Battlezone quite impressive. Wouldn´t have thought that the GB could handle vector graphics so well.

     

    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.


  16. Thanks for the information. I don't believe I ever heard of Whitewater Madness and can't find. What did you think of the STE by the way?

     

    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.

    • Like 1

  17. That´s a bit off-topic, but did you at SOLID Corp. only do the SNES version of Bubsy, or also the Genesis port?

    I ama mod for TheLegacy, a a gaming-database similr to Moby, and while we do have a "Solid Software" listed as developer of the SNES version, the Genesis one is listed as being done by "Al Baker & Associates". In the game and on the box, only Accolade is mentioned.

     

    Our database is based on user contributions, so while we do usually check information there may always be errors.

     

    Also, I presume your copany was called Solid Corp. back then, not Solid Software?

     

    It´s a rare occasion that I can ask the dev himself.

     

    EDIT: Found your name as well as the Solid Software logo. :) I had to press A instead of Start in the title creen to get to a menue where I could select the credits. :)

    solidlogocnc.JPG

    Atari Age is probably not the best venue for topic but I will answer your questions. SOLID Corp. is the name of my first corporation, which I still own and operate. SOLID Software, SOLID Technologies... were all divisions of SOLID Corp. Now I just use SOLID Corp.

     

    SOLID Corp. originally contracted with Accolade to work with the Genesis team to develop the SNES Bubsy. Accolade had reverse engineered the Genesis and was making the game unlicensed. Sega sued them and the courts injuncted the development of Bubsy on the Genesis, at that point the SNES became the lead SKU at SOLID Corp. After many months, an agreement was reached between Accolade and Sega and development could resume on the Genesis product but for whatever reason the team was unavailable. Accolade contracted SOLID Corp. (me) who in turn contracted Al Baker & Associates (Al Baker is a friend of mine) to assist in the port of the finished SNES Bubsy back to the Genesis. It was just the two of us and there was a tremendous amount of pressure to make up for the months the Genesis product was dormant. It only took 13 weeks start to finish for Al and me to complete Genesis Bubsy.

     

    On topic of the Lynx, and since you were so important in Lynx development... was there a reason that Lynx games often only had very little music? Was it just memory reasons or were there other problems with Lynx sound.? I play games like Switchblade II, and it is really akward that an action game like that lacks any background music.

     

    Even today in homebrews music is the aspect most lacking on the Lynx, probably due to a lack of tools. It is being worked on though. :)

     

    I don't know. The Lynx has fantastic sound hardware - multichannel, multi-bit feedback registers, white noise, with a sound system that allowed you to make ADSR envelopes and instrument banks. There were tools to convert MIDI music to game music. All of that was used in Toki for example. I also wrote compressed digitized sound drivers and tools for the Lynx that were available to developers and a fully digitized sample music system. Digitized sound was used in RoadBlasters and the compressed digitized sound effects were used in S.T.U.N. Runner and Toki. The compression was a 4 bit delta compression. Where the 16 deltas were from a table that could contain any data. Usually powers of 2 were used, but we experimented with manual tables, the golden ratio, and the Fibonacci sequence. If I had stayed longer, the plan was to create the table to best match each sample itself. It ended up being similar in that regard to the Sony BRR sound format used by the SNES sound processor later.

     

    IDK, Maybe homebrews don't have access to the tools, or maybe they don't know musicians. Homebrew devs are typically programmers, and programmers are well known for not necessarily being the best artists and musicians (although I did all the art for S.T.U.N. Runner on the Lynx).

    • Like 1

  18. It's funny how the advanced graphics of the lynx couldn't excite people back then, while nowadays its all about them.

     

    The Lynx was just great tech*. What I mean is an Xbox360, PS3, or Wii is just a fancy computer until someone makes a Halo, Drakes Fortune, or Zelda for it. The Lynx suffered from too many coin op style games and ports and no truly GREAT games, no platform sellers. I don't think we (I want to say "they" but I was there too) understood the value of the killer app, even though titles like Super Mario Brothers (1985) and Zelda (1986) were already driving NES sales like crazy. The Lynx was also not distributed as well as the GameBoy. Nintendo got into all the retailers, and from what I remember Atari couldn't keep manufacturing up with demand. The result was that retailers made better deals with Nintendo than Atari and the vastly inferior** GameBoy "won". The marketing was also anemic.

     

    Anyway, that's my two cents on how the superior Lynx didn't come out on top.

     

    *Man those guys at Epyx were really technical geniouses, Dave Needle, RJ Michael, (both credited for the creation of the Amiga, and later 3DO) Stephen Landrum... they not only made the extraordinarily innovative platform, they wrote the best set of manuals, examples, and libraries I had seen to date. The development material blew anything Atari had done clean out of the water.

     

    ** I wrote BattleZone & Super Breakout on the GameBoy for THQ so I know exactly the features and shortcomings of both platforms. I think it's funny, that even when I wrote for the GameBoy, I was porting Atari games ;)

×
×
  • Create New...