some pretty awesome graphics for the Lynx!

[solidcorp]

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.

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

[108 Stars]

Wow, thanks a lot for the in-depth info!

[solidcorp]

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

 

[108 Stars]

I hope you will find the S.T.U.N. Runner-stuff eventually. If your not in bad luck and the floppies died by now.

 

But, since you mentioned that there was sourcecode for sound and technical demos and prototypes on the drive... maybe there was something of interest to the community? It´s a long shot, but if there is something worth seeing that has not been released to the public it would be cool.

After all, to this day people are searching for (and occasionally finding) prototypes of unreleased games for the Lynx, or betas with differences or tech demos. Maybe your drives hold such a treasure too?

 

Of course it would be understandabe if you can´t share infos on such things because of old NDAs or something, but I just had to ask.

[TailChao]

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.

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

It is basically the latter.

Having used HSPL while working on Zaku, the tools we have now are much less restrictive than EPYX's. If you want good music, you have to hire a good composer. The conversion to the hardware is trivial otherwise.

 

I also remember Alex Rudis noting that he was given barely any space to store music. But he would probably be more qualified to comment than I.

 

Edit (Nearly forgot)-

Mr. Williamson, Thank you very much for your work on Toki

Edited October 31, 2011 by TailChao

[sd32]

Have to say that a love the Lynx Toki, great sound, graphics and gameplay. Loved the original Bubsy too!

[solidcorp]

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.

[108 Stars]

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.

 

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´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?

 

 

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.

[sd32]

After knowing about the conditions under which you ported Toki, it makes it even more amazing. I cant stress enough how good Toki in the Lynx is, i feel its very underrated. I feel its easly the best action platformer on the Lynx, and wish you could have made a sequel to it back in the day, maybe not an official sequel, but a similar game in spirit.

Music and sfx in the Lynx is usually kinda dissapointing (there are many bright spots in the library, though) but it rocks in Toki and the graphics are excelent.

[solidcorp]

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.

 

[Cobra Kai]

On the subject of the Lynx lacking a killer app, or not having a mascot etc... While I think original titles are important, I think the Lynx could have really been better off going after arcade ports even harder than it did. Why force a mascot? They tried that with Atari Karts on Jaguar and honestly that's nothing special, a stripped down Mario Kart game. With the arcade especially in the early 1990's there would have been a limitless amount of titles to license. Heck the Atari Games division alone should have had many more possibilities and cheap or no licensing fees right?

[Emehr]

On the subject of the Lynx lacking a killer app, or not having a mascot etc... While I think original titles are important, I think the Lynx could have really been better off going after arcade ports even harder than it did.

 

Totally agree. Warbirds and the arcade ports such as Xybots, STUN Runner, etc. (that you couldn't get on anything else) drew me to the Lynx. I couldn't care less about a mascot. I was happy as long as there were original titles being made. 'Original' being defined as games that I couldn't play on any of the other consoles at the time. (When Ninja Gaiden III was announced I was a bit befuddled. Like "who asked for that?" befuddled. I'm sure it was a fine port but I didn't want to spend my money on NES ports.) Mascots are focus group fodder. The Lynx had a strong enough base library that the thought of a mascot never occurred to me as a gamer. To me, Lynx games are defined by their vibrant colors, distinct sounds, fantastic character and sprite animations, and unique library. It was the perfect portable for arcade ports and it could have used a lot more.

 

Unfortunately, the Lynx died a premature death. I have always wondered what kind of fantastic games we would have gotten had the Jaguar never been a glint in the eye at Atari. Maybe Guardians: Storm Over Doria would have been finished. I remember drooling over the prospect of playing that one.

[solidcorp]

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.

[108 Stars]

Also, those games were enough for YOU guys, because you were obviously attracted by the Lynx. But games like mascot games, or action platformers like Ninja Gaiden 3 was what the masses were into. I think to make the system a real success, Atari needed to get the mass market, not just few dedicated fans like the Neo Geo. Lacking that kind of stuff is what had a large role in the Lynx ultimately failing compared to GB and even GG in the long run.

 

And even in the arcade, as Steve wrote, Atari had long been split into two companies. Add to that that to my knowledge by the late eighties Atari Games was not eben the major player in the arcade, but companies like Sega, Capcom and Konami had taken center stage there. So the many of the most popular newer arcade games couldn´ t even be ported or would have to be ported in-house even if the companies were willing to license a port. There´ s limits to how much Atari could have done themselves.

[CRV]

Maybe Guardians: Storm Over Doria would have been finished. I remember drooling over the prospect of playing that one.

 

The big reason that was canned was because it would have cost to much to manufacture (512K + battery).

[108 Stars]

Maybe Guardians: Storm Over Doria would have been finished. I remember drooling over the prospect of playing that one.

 

The big reason that was canned was because it would have cost to much to manufacture (512K + battery).

 

Which in turn shows that software on the Lynx had low sales expectations. We are talking about only half a Megabit here; really not that huge an amount of memory. Not a very little for the time either, but definitively not spectacular. Later GB and GG games reached 8 Megabits.

And a battery is not a thing that costs a fortune either.

 

There must just have been very low sales expectations for Lynx games to make a 512 kbyte battery-equipped game seem not viable business.

 

I´m just saying that because people say that the Lynx was good as it was with its games, and that the arcade games were all it needed... having so little diversity in the Lynx game library probably played a major role in the system only selling so little software that a game that would have had no competition on the system was deemed unviable due to memory cost reasons.

 

Reminds me of what was written in a 1992 issue of the UK Lynx fanzine, where the mag got excited about 5 new titles to be released, and the possibility that more will come IF those 5 sell well. Mind you, even of those 5 only 2 or 3 were actually released before the Lynx was abandoned by Atari.

 

Had more games of different genres been released earlier the people might not have turned their attention elsewhere, and the Lynx might have stayed a major player longer.

[Tursi]

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

 

@108 Stars - it's not just the cost of the cartridge that's a problem, though, the cost of the /first/ such cartridge is much higher, since they didn't have any lines set up to do large carts with batteries

[solidcorp]

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

[108 Stars]

but I did come across some really interesting stuff, like 1991 Lynx and Lynx titles sales figures and development contracts.

 

Again, if you are willing to share any of these documents or the information contained within, this would be greatly appreciated. There have been some fascinating documents discovered already, like the merger agreement between Atari and JTS, a sheet of Jaguar game development costs with handwritten notes, or production notes on Jaguar games.

 

This stuff is always interesting, especially since there is not much valid Lynx sales data available afaik.

 

@108 Stars - it's not just the cost of the cartridge that's a problem, though, the cost of the /first/ such cartridge is much higher, since they didn't have any lines set up to do large carts with batteries

 

Right, you do have a point there, I did not think of that. So it is more expensive than the price for components might suggest.

Yet still it probably was not a good sign for the Lynx´ standing that Atari did choose to cancel this and other 512 kb & battery games like EotB.

 

BTW, Tursi... you mentioned you had a license for Lynx games yourself but never got to do any, and I know you are an active member here and involved in lots of techie stuff... but what systems did you actually develop for? I know of Cool Herders, but did you develop commercial games back in the day? Just out of cusiosity.

Edited November 3, 2011 by 108 Stars

[+rdemming]

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

[solidcorp]

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!

[Tursi]

BTW, Tursi... you mentioned you had a license for Lynx games yourself but never got to do any, and I know you are an active member here and involved in lots of techie stuff... but what systems did you actually develop for? I know of Cool Herders, but did you develop commercial games back in the day? Just out of cusiosity.

 

I never actually got to, no. Largely because I was a dumb kid who didn't know how to present himself.

 

I had the Lynx license and documentation, but no devkit largely because we (myself and a couple of involved friends, including Gord of ActsOfGord if you read that ) never raised the money. Later, we got a Jaguar license (largely by circumstance), and focused more serious efforts there. I say 'more serious efforts', but I'm rather embarrassed looking back. I can't imagine what Atari thought of us, though for a short time it looked like we were going to break through.

 

After that, nothing till I got involved in Playstation homebrew. I did get paid for a (very probably) unauthorized adult version of Tetris, but hunting around the net for it, I am not sure that it was ever actually released. Then the Dreamcast, where GOAT picked up Cool Herders for us and got it out to people. I played very briefly with the GBA, and then Jaguar caught my interest again and I've played around with it a lot to learn the hardware, but there are no real titles from me even now, most of my Jag coding time went into the Skunkboard.

 

HarmlessLion is currently an authorized developer for the NDS, and if I can get the last few issues solved, a new Cool Herders should hit DSiWare. But real life is complicated and I've given up predicting when. Then I need to decide whether it's worth upgrading to the 3DS or just moving on.

[solidcorp]

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.

 

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

 

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.

[solidcorp]

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
.....".Ó.£...@.fastdir..
[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
...º...d.....@BETTER01.PW2...
[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"...

[Isgoed]

Very interesting read... keep 'em coming!

 

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