Slashdot Mirror
PC Historian Finds Puzzling Game Diskette Image
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.
Wonder how many patents this potentially invalidates?
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.
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.
Never ask for directions from a two-headed tourist! -Big Bird
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
It's also shockingly cool because my understanding of C64 vs. IBM formatting indicates that the read/write method is entirely different between the two, making it physically impossible for one machine to run emulation to extract info from a drive of the other.
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
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.
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.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
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.
Don't put advice in your sig.