PC Historian Finds Puzzling Game Diskette Image 232
This past weekend, Trixter — a self-proclaimed IBM PC historian — picked up some old software for his archive. What he didn't count on was a couple of additional Avantage titles that had never been released into the wild. If this weren't enough of a find, one of these titles provided Trixter with an interesting puzzle: the diskette for Mental Blocks is apparently hand-formatted to work on both C64 and IBM (on a single side, not the "flippy disks" of old). Quite an interesting little piece of history.
Prior Art! (Score:5, Interesting)
There were a few hybrid formats around in the 80s (Score:5, Interesting)
This does look like a very early example, but the technique is not as novel and amazing as the article makes out.
For example, in the UK around 1989 there was a magazine for Atari ST and Amiga users called "ST/Amiga Format" that used a hybrid format on 3.5" coverdisks. The ST used a PC-like 720MB format, whereas the Amiga had its own filesystem that fitted 880MB on the same disk. The hybrid disks weren't flippable, they were read double-sided on both systems and just marked the part of the disk used for the other filesystem as bad.
Floppy Records! (Score:5, Interesting)
For some reason it reminds me of the floppy records that came inside magazines, when I was a kid. We would transfer the audio from the record to a cassette, then load the cassette into the computer.
Nobody even whispered, because we were convinced the least bit of sound would get mixed in and corrupted the whole thing. Same goes for acoustic-couple modems, except it really worked that way sometimes. Too much background noise and you'd lose carrier.
Ahhh.. the good old days.
Not the first "double format" image (Score:4, Interesting)
This one is relatively easy to do, since DOS uses track 0 to find the directory, and the C64 keeps the directory on a middle track. Even better, the whole second side of the disk could be formatted for PC sectors. But you do have to put the disk through two duplicators, one for the PC sectors, and another for the C64 sectors. (Nowadays this could be done with a Catweasel or similar disk controller that deals with times between transitions.)
This is pretty impressive, but it only needs one format per track. There have been cases where the same track was in multiple formats. The TRS-80 Model I booted from a single-density T0S0, while the Model III booted from a double-density T0S0. There were autoboot games which formatted sectors on track 0 in both single and double density.
As I heard it, the first part of the trick is that the Model I switched density by having both types of disk controller chips. (I don't know details of how the III did it) The second part of the trick is that you start one of the FDC chips formatting a track, then interrupt it partway through. Then you start the other FDC formatting the rest of the track. Presto, you have a track with sectors in both densities! You don't need any other data on track zero, as the boot sectors were customized to boot from the rest of the disk in single density, which both a M3 and an standard single-density M1 could read.
Re:Not really that hard... (Score:5, Interesting)
That was the case for heavy-duty copy protection schemes. The idea was that you'd have a small area of the drive with a loader program in the "normal" format and track 18-0 as readable as well so you could do the directory, the rest in your own non-standard format the couldn't be read at all. You'd then do all sorts of wacky code tricks to obscute the loader program itself, but once it loaded, it could deal with the non-standard data blocks/tracks on the disk.
Ted
Re:Hybrid disks - not a novel idea after all! (Score:5, Interesting)
Re:Not really that hard... (Score:5, Interesting)
Actually, I butchered a few terms in my post most likely. My brain nearly froze trying to remember the different terminologies (block/sector etc) from back in the day! I haven't done low level disk stuff on any platform since the late 80's. I think I got the meaning across OK hopefully.
Also- I think the encoding was more likely at a lower level then even what you'd consider "track basis". I don't really know the IBM side so I don't know if the interleave would have been same, etc. Again I can visualize what I mean here, but I can't remember the terms anymore for what the "lead in", "gap" etc in the low level bit encoding was called. I think I've blocked out all the programming knowledge I used to have regarding getting the 1541 to do it's voodoo (*shudder*, assembly from hell!).
Ted
Re:Hybrid disks - not a novel idea after all! (Score:5, Interesting)
The "Macintosh-format" CDs don't use ISO, they actually use HFS/HFS+. The dual-format disks actually contain an ISO and an HFS partition, but they're engineered so that they share data. You can have ISO-only files, HFS-only files, and shared files; the shared files are only stored once. The ISO partition is used to store data for windows; the HFS partition is used to store data for Mac OS.
The interesting thing about those disks isn't that they're formatted to have two different filesystems on them -- by the time the dual-format CDs were around, putting two partitions on a disk was no big shocker. The interesting part was that they were designed to have two partitions own the same data.
Compare with the disk mentioned in the article. It sounds like the data for the IBM and C64 are entirely separate. The interesting feature is making what is essentially a two-partition disk out of a disk that's designed to be single-partition.
Re:Hybrid disks - not a novel idea after all! (Score:5, Interesting)
You think that's neat... This was back several years before XP came out, but I once found a 700 MB image for a CD that had installations for like 15 different versions of Windows, from 95 to 98 to NT4, all on the same disc. Including all the Pro and Server and other versions and everything else.
Basically somebody had sat down and ran a big comparison on all these to find the shared files, then engineered a disc to have all these different partitions own that shared data, allowing for installation of any of them. Then they went a step further and wrote a boot sector to let you boot any of those partitions via a simple text choice at boot time. The result was a single disc that could install any version of Windows that was available at the time.
Had that disc for years, came in extremely handy.
Re:Hybrid disks - not a novel idea after all! (Score:1, Interesting)
I can't see how a single disk could support BOTH encoding techniques on a single side.
Re:Not really that hard... (Score:2, Interesting)
Assuming FAT12, you just mark it as used in the allocation table but don't make any directory entry point to it. As long as nobody runs filesystem-checking software on it (along the lines of scandisk, but scandisk itself didn't exist back then, so it'd be a third-party utility), there shouldn't be a problem. And a game disk is probably meant to be read-only, in which case nobody has any business running filesystem checks on it.
This is assuming that the two formats don't both need certain specific sectors. In the case of FAT12, I *think* certain things have to go at the beginning of the disk (low-numbered sectors), but it's been a good while since I did any significant low-level filesystem fiddling, so I could be remembering that kind of detail incorrectly.
Starglider! (Score:2, Interesting)
Re:In my day, we had to hand format disks (Score:5, Interesting)
That takes me back...
I had a cartridge for my C64 that let me do low-level stuff with disks. With it, you could browse around and read the raw sectors, change stuff, lots of fun. It wasn't long until I discovered that most C64 disks followed a certain pattern with regard to which sectors followed which (very rarely were they sequential; I think it was next-track-over+six-blocks-down). The first two bytes (iirc) pointed to the next sector. [This didn't work for copy-protected games that didn't use the standard format. If those disks went bad, you were SOL]
Interestingly, I found that when sectors went bad, they often went bad in exactly the same way: all the bytes for that sector would be shifted back one, and the first and last bytes were the same on every bad sector. I can't remember what they were now (first byte was "M", last was "Z"? Damn 20-years-ago memories...), but you could spot a bad sector by looking at it.
Effectively, only the information about the following sector would have been lost, but you couldn't just put it back in because everything had shifted over by one. And if you manually shifted everything back by one (by retyping it all in, starting from the end), and re-saved, you'd usually fuck up the sector even more, and lose data.
My solution was to browse around on the disk until you found an empty sector. Copy all the data from the old sector on to a piece of paper, go to the new sector, type it all back in, point it at what the next sector should be (following the standard pattern), save it all to make sure it's not a bad sector, go back to what the previous sector should be, and point it away from the bad sector to the new replacement sector.
[The _real_ solution would have been to write a program to do this for you, but I didn't have any manuals and couldn't figure out which PEEKs and POKEs would give me the same functionality as the cartridge]
Sometimes a bunch of sectors were bad, so you'd have to do this many, many times. I remember when I moved out after high school and found my notebooks filled with pages and pages of hex numbers; the raw data for all the sectors I moved around on disks, by hand.
Good times.