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.
With a tiny magnet, flipping 1's and 0's.
Wonder how many patents this potentially invalidates?
(wow...my first slashdot post in like 5+ years...something I actually can know stuff about! LOL)
I wanted to email Trixter this but couldn't find a contact email.
It's been now about 25 years but I still have parts of the C64 ROM's memorized. There was a time that I knew pretty much what every byte in the 64k(*) of memory was for cold without needing a reference manual. Having said that:
This wouldn't have been all that hard to do by somebody who had intimiate knowledge of *both* IBM and C64 formats I'd imagine. First, I doubt it was done 'by hand' as in a manual sector by sector copy. A program would have been written, using a slave-master 2 drive config, to stream from the source drive to the dest. drive using a list ot sectors/tracks and/or using a simple formula to calc where the tracks should go. You simply would pick areas on the C64 side that you would want reserved for the IBM side and vica versa. Knowing both IBM and C64 MFM structures would allow you to pick "safe" areas for both formats.
Oh, and the directory structure of the C64 did indeed live on track 18. All the other data blocks where chained out as a linked list from the entry in this track.
All that would have been really needed is:
#1) Format the disk for IBM and use whatever areas you need via a streamed block by block copy from Src to Dst.
#2) Noting which tracks are "safe" to use on the C64, simply write a program to format track by track and write the C64 data, streaming again.
Ingenious, but really not that hard at all...
(*) Well, more like ~80k with the shadow RAM near the top of the 64k range...
Ted
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.
The short-lived, dual-format ST/Amiga Format magazine from the late 1980s also had an appropriately dual-format cover-disk - somehow combining the apparently wildly-incompatible ST and Amiga floppy disk formats.
I've no idea how it was done (although the fact that many STs had single-sided floppy drives may have had something to do with it) - and while it could have been extremely useful to publish games in such a manner at the time, I don't know that was ever done either.
I get the impression that there was a lot of deep magic involved in these enhanced disk formats, copy protection systems and so on. I'm sure the name Rob Northen appeared on the front of a later ST Format cover disk - as the supplier of the fancy files-limited-to-particular-sides-of-disk format used to not deprive single-sided drive owners the contents of the entire double-sided disk...
Tedious Bloggy Stuff - hooray?
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
This is a cool hack. From what it looks like, this is possible because DOS put the boot sector and the root directory in the beginning of the disk, whereas the C64 made the sane choice of putting it in the middle (think about it, this minimizes seek times). Now the directory (or, more precisely, the File Allocation Table (=FAT)) contains information on so-called bad blocks, i.e. blocks that the OS shouldn't write to because they were known to be bad. If you label the blocks that you put the C64 data into as bad blocks, then DOS is not going to overwrite the C64 data. Now you do the same in the C64 FS and bang -- double OS format created. And it's read/write!
I wonder if someone managed to format a disk such that one was also able to share the data space between the different OSs?
Do those disks really use multiple formats, or do they just have Mac and PC binaries available on the same standard ISO file system?
The cool thing here is the media format itself is a hybrid. C64 disks in general are incompatible with DOS disks. But some clever hacker out there figured out a way to build a file system that's valid for both machines. A better analogy would be formatting a disk so that it's ext3 and NTFS *at the same time*.
Give me Classic Slashdot or give me death!
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.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.
LOL, ok that KB, not MB.
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.
That was the first game that I pirated... after I bought it.
The copy protection was so messed up that the only way I could get a copy of the game that was reliable was a cracked copy. But I didn't want a pirated diskette, so I had the cracked copy written over the original gold-labelled floppy.
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.
This is a somewhat common attack vector for Windows. A malware author creates a data/audio CD and then distributes it as an audio CD. If the victim puts it in their CD player, it plays fine*. If they put it into their Linux machine, and then play it like an audio CD it plays fine. But when they put it into their Windows machine, Windows (by default) recognizes the CD as data, and then loads the autorun program, which is a trojan horse.
Sony's rootkit a few years ago did exactly this.
* Some people here are saying that a CD player will attempt to play the data track as audio, and it will be random noise. I have never experienced this from data/audio CDs.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
When I had my Amiga 1000 we had software that could do an Amiga, Macintosh, and MS-DOS format on the same floppy disk. You took like 100K to 200K parts of the disk and made a mini-format for each standard.
There used to be software that made mini-standards and it was affordable for game companies to use the same floppy disk with two or more versions of their game on two different partitions of a floppy disk.
For example one was a MFM format for the PC and the other was a GCR format for the C64.
That was old school hacking, before "War Games" and people trying to crack computers and security and writing viruses. It is more of a computer hobbyist style of tweaking a computer that we computer geeks liked to use back in those days when being a "hacker" meant you wrote useful code that nobody else could to do impossible things like one floppy disk that supports two different formats at the same time. Back in the old days when programmers used machine code and assembly language and BASIC interpreters with peek and poke statements. Long before the GUI revolution and long before script-kiddies called themselves the new hackers, and are really crackers and not hackers at all.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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.
The trick is that, if you limit each OS to half of the disk, you can do this. Each OS only uses its half and doesn't try to read or understand the other's.
IBM-standard floppies put the master directory information on the first tracks on the disk. Commodore floppies put this information on track 18 of 35, halfway in. (Fun note: you could actually run out of directory space if you put a bunch of small files on the disk and filled up track 18. There were utilities that would extend the directory links to track 19 in this case.)
So tracks 1-17 were the IBM part, and 18-35 were the C-64 part. No shared data. I think Commodore floppies only stored 110 K of data.
to install W95, you needed about 60MB worth of CAB files. The rest of the stuff on the disc could safely be ignored. W98 and 98SE were 95MB. ME was 130. NT4 was 55MB. W2K was 120 or so.
I had (and still have) a CD that I made, which included W95 OSR2, W95 OSR2 French, W98SE, W98SE French, and NT4 English/French install discs, all on a single 650MB disc. And I'll go one better: because of options that were available in the install ini files, they were all headless installs, and didn't need me to choose any options or enter a product key. :)
If you believe everything you read, you'd better not read. - Japanese proverb
The Commodore 1541 floppy drive stored 170K
Yes YOU cant see how it can be done, nor can most of us. ... quite a lot more technically difficult than simply using half the tracks for one OS, and the other half for the other.
Thats why its interesting, because it would require hand crafting two entirely different format types on the same physical medium
Please read TFA before attempting to sound insightful.
{Sigh}
Okay, folks, here's how you do it...
1) Format using 1541. This will put 174K of data on the bottom side of a DSDD floppy. /T:17 /N:9). This allows BOTH sides of the disk to be formatted up to track 17, giving you about 180K to play with. Given the lousy graphics on PCs at the time, this is all you really need. This WILL NOT overwrite any 1541 formatting, since the BAM sits at track 18, and the FAT sits at track 0.
2) Manually edit the Block Allocation Map (BAM) to map out ALL tracks/sectors between 0 and 17, leaving track 18 (the BAM) and 19-35 for the 64 program and data (I figure about 82K will be free).
3) Write 64 stuff to disk.
4) Pop disk into PC drive, and either use a custom utility, or just use the FORMAT command specifying that only tracks out to 17 be formatted (FORMAT A:
5) write PC stuff to disk.
6) PROFIT!
Another person above wondered if the 1541 had an auto-remap of bad sectors... NOPE. A bad disk/sector would trigger the "headbanger" routine, and the format would fail. In fact, the reason the 1541 was so slow at formatting (about 2 minutes for 174K) was that it would write the track, then read it back to verify, update the BAM, then go back to do the next track. Fastload cartridges bypassed the verify and BAM routines, and could do the same thing in under 30 seconds.
Seriously, am I the only one here who read "Inside 1541 DOS" by Immers and Neufeld?
banzai "Bam-Bam" kai
to install W95, you needed about 60MB worth of CAB files.
No, I have Win95 on 13 floppy disks = 18.72MB.
4) Pop disk into PC drive, and either use a custom utility, or just use the FORMAT command specifying that only tracks out to 17 be formatted (FORMAT A: /T:17 /N:9). This allows BOTH sides of the disk to be formatted up to track 17, giving you about 180K to play with.
Right, except that, if you actually read the post, you'd know that what I found was that every even track != 0 was C64 and every odd track *and* the entire second side was IBM.
I mean, come on, I posted a FAT dump as a screenshot. So no, it wasn't truly that easy (even though our definition of "easy" is a lot different than most people's). It required a little more planning, and manual patching of *both* filesystems.