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.
Hybrid disks - not a novel idea after all! (Score:2, Insightful)
Re:Hybrid disks - not a novel idea after all! (Score:5, Insightful)
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*.
Re:Hybrid disks - not a novel idea after all! (Score:5, Interesting)
Re: (Score:2)
yeap.. and this is why this is "new for nerds" someone spent some time on this.
i would love to know how they went about it - seems like it would be an intresting read
Re:Hybrid disks - not a novel idea after all! (Score:5, Informative)
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.
Re:Hybrid disks - not a novel idea after all! (Score:4, Informative)
The Commodore 1541 floppy drive stored 170K
Re: (Score:3, Informative)
I think Commodore floppies only stored 110 K of data.
They stored 160 KB per side of a 5-1/4" disk. These were accessed by the 1541 and 1571 drives.
The 1581 drives stored 800 KB per 3-1/2" disk. You could even partition the disk as I recall!
*sigh* those were the days...
Re: (Score:3, Informative)
It wasn't so much that the formats were different as it was the controllers. The catweasel can write to both formats using a standard 1.2mb 5.25" PC floppy drive.
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: (Score:3, Funny)
So that person's claim to fame was using ISOBuster to save an "optimized" ISO ?
Wow.
No really, I'm impressed. I mean, it took some serious cojones to actually click that checkbox.
Re: (Score:2, Insightful)
ISOBuster 1.0 came out after Windows XP. The GP was talking about "several years before XP". Probably not an automated process back then.
Now? We have a torrent with all Windows installation CDs. It fits conveniently on two DVD9s.
Re:Hybrid disks - not a novel idea after all! (Score:4, Informative)
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. :)
Re: (Score:3, Informative)
to install W95, you needed about 60MB worth of CAB files.
No, I have Win95 on 13 floppy disks = 18.72MB.
Half Tracking (Score:2)
I think we use to do this with what was called half tracking. On my 1541 I could tell the drive to set it's alignment 1/2 a track off of normal and store data there. If everything worked write, I could double the space used. You could also do this to have a multi-format disk.
It didn't always work right and produced media that worked fine on my 1541 but not on other 1541's.
Anyway, that's my recollection. It's been how many decades ago? We use to also change the HZ of our 300 Baud modems so we could sq
They might be multi-format (Score:2)
CDs have various formats they can have written on them, and there is a Mac specific one. However, there isn't anything that neat about it since it is all part of the spec and you just tell your burner software how to handle it. I don't know all the details of all the different things you can do but mixing all sorts of different data modes on a CD is no big deal. Same kind of thing as mixed audio/data CDs.
Re: (Score:2)
Re: (Score:3, Insightful)
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.
Re:Hybrid disks - not a novel idea after all! (Score:5, 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
Re:Hybrid disks - not a novel idea after all! (Score:4, Informative)
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.
Re: (Score:2)
Your Blizzard "game disks" are CDs or DVDs, not diskettes. Most software CDs and DVDs these days use the same file system, no matter what the target operating system is.
Re: (Score:3, Informative)
See my response above -- "Mac/PC" hybrid disks actually use two different filesystems. Macintosh CDs use the HFS/HFS+ filesystem. People took advantage of this to make dual-filesystem hybrid disks. (On the other hand, having two partitions with different filesystems on one disk was old hat by the time data CDs were around.)
In my day, we had to hand format disks (Score:5, Funny)
With a tiny magnet, flipping 1's and 0's.
Re:In my day, we had to hand format disks (Score:5, Funny)
You had magnets!?!
We had rub our fingers against piece of sheepskin really fast to build up a static charge and then touch the bits to flip them!
Re:In my day, we had to hand format disks (Score:5, Funny)
You had fingers!?!
I'm not even going to tell you how we charged our sheepskins.
Re:In my day, we had to hand format disks (Score:5, Funny)
Let me guess... Hillbilly style, from behind? :D
Re:In my day, we had to hand format disks (Score:5, Funny)
And that's the reason there are so few famous female programmers.
Re: (Score:2)
Re:In my day, we had to hand format disks (Score:5, Funny)
you had ones AND zeros? We only had zeroes. We were too poor to afford all those ones. We had to just close our eyes and imagine the ones. When we finally got a few ones, we had to use them sparingly and reuse them, we only had 8 ones between all us kids, and when we wanted to format our disks, we had to format then one byte at a time, then recycle those ones. SUre, you might occasionally get lucky and get to do a few bytes at the same time, but those solid blocks of 255s used to kill us. Spoiled rotten damn rich kid,
Re:In my day, we had to hand format disks (Score:5, Funny)
Disks? Huh. You kids and your newfangled "disks". Why, in my day, we had paper tape. Except we were too poor to have a tape puncher, so we had to use a pencil! And we were too poor to own a pencil sharpener, so when the pencil broke, we had to use our teeth!
Now get off of my lawn!
Re:In my day, we had to hand format disks (Score:5, Funny)
You kids and your new fangled paper tape. In my day we had to chew the wood into a pulp to make the paper to make the cards we had to use.
Now get off my lawn.
Re:In my day, we had to hand format disks (Score:5, Funny)
You had wood? .. wait, on second thoughts I don't like where this is going ..
Re:In my day, we had to hand format disks (Score:5, Funny)
You have a lawn? Spoiled brat!
Re:In my day, we had to hand format disks (Score:5, Funny)
Re: (Score:3, Funny)
we used to dream of asterisks not to mention all punctuation those were not even invented back in the day
Re:In my day, we had to hand format disks (Score:4, Funny)
Paper tape? Eee, tha' were lucky. In my day we had to toggle the loader in on front panel switches.
The disturbing thing is that it's true, I *am* that old.
Re: (Score:2)
Ever since Microsoft patented ones and zeros [theonion.com], formatting them is much harder...
Re: (Score:2)
You were spoiled, in my day we only had 0's.
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.
Re: (Score:3, Funny)
Pfft. Real programmers just think really hard, choosing the proper universe such that electrons happen to tunnel at just the right place and time to affect the magnetizer.
Even better ones choose the universe in which the atoms of the proper hard disk spontaneously tunnel into just the right configuration from across spacetime.
Re: (Score:2)
Butterflies?
We considered that, but waiting for evolution to process butterflies wasn't an option. We went with Daleks. Time Lords were busy...
Or course, the Daleks caused more trouble than they solved. We shoulda waited for the butterflies after all. Let that be a warning to you .NET types. Don't glom onto the most insanely great thing just cause it's pretty, louder, or has a bigger gun, ok?
Prior Art! (Score:5, Interesting)
Not really that hard... (Score:5, Informative)
(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
Re:Not really that hard... (Score:4, Informative)
I thought C64 floppy drives were notoriously hard to emulate because the drive was programmable and the disc often contained a program made to read its own content?
In which case you could pretty much do what you wanted, loader-program location excepted.
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:Not really that hard... (Score:5, Informative)
Oops- forgot to add, of course if you didn't do copy-protection at the disk level (as I'm guessing the case is here, hard enough to make it dual format!), this wasn't an issue. You just interwove the data so neither side (C64/IBM) really knew about the other, or cared really. If it wasn't linked via an entry in track 18 the C64/1541 had no business "looking" at a track/block). Not sure what the deal was on the IBM side but I'd guess simular.
Ted
Re: (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 a
Re: (Score:2)
That was part of it. The 1541 drives had a 6502 and their own ROM.
Another part is that the disk was divided into concentric zones with different data rates to squeeze a bit more capacity out of the outer tracks.
Re:Not really that hard... (Score:5, Informative)
Poor choice of words, since the C64 (well, the 1541) didn't even use MFM. ;-)
These aren't just two different filesystems; we're talking about two different encoding schemes used on the same medium, on a track-by-track basis.
Not hard? Ok, fine, once you've thought of it, you can do it. Weird and a historical curiosity? You betcha!!
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: (Score:2)
It might have been interesting getting the IBM and C64 drive's idea of where a track goes to line up close enough. The floppy was just a disk of magnetic media with no intrinsic tracks on it. The drive decided where those were.
It could also have gone wrong because the two formats (and physical characteristics of the mechanisms) are designed not to interfere with adjacent tracks in the same format. They just happened to be able to work with the interleaved formats.
Like many really great ideas, it's really si
Re: (Score:3, Informative)
Nit: The 1541's directory structure lived on track 18, not the C64's.
Track 18 was chosen because it was in the middle. That was the typical way Commodore did it back in the day -- So 4040s, 2031s, 1540s and 1541s had track 18 directories, but 8050s, 8250s, and SFD-1001s had them on track 40.
No idea where the harddrive dirs were, I couldn't afford one.
Re: (Score:2, Funny)
>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.
I have SYS 64738 that part of my memory a long time ago.
Re: (Score:2)
The C64's 5.25 drives (1541, 1571) didn't use MFM - they used GCR. Only their 3.5 drives (1581) used MFM.
Re: (Score:2)
No. The 1571 could do either GCR or MFM. MFM support was added so that CP/M programs from Osbourne, Kaypro, Epson and IBM could be read on the C=128.
Re: (Score:2)
I stand corrected, but I very much doubt that this game was written for use only on a 1571 drive - the majority of Commodore owners had a 1541.
Re: (Score:2)
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:
Neo: Do you always look at it in code form?
Cipher: Well, you have to. The viewer works for the Ti-99/4a, but there's way too much information to decode the C64.
Re: (Score:2)
You forgot "Now get off my lawn!"
Re: (Score:2)
Ingenious, but really not that hard at all...
Which is precisely the part that blew my mind :-)
Re: (Score:2)
Do you mean that there is a file on the IBM side 'taking up' the space for the C64 side, and vice versa? If so, couldn't you (or someone else) hose the disk by trying to delete that file "to make more space"? Though maybe these weren't even MSDOS disks, and thus had a completely custom filesystem, like lots of software back then.
Re: (Score:2, Informative)
My inital post wasn't really specific enough in it's terminolgy. It was almost painful to bang out as I was dealing with some pretty old memories! :p
When I said "side" I should have really said something like "from the view of the (C64/IBM)". I wasn't really talking about sides of the disk, but the 'view' you take when working on one system or the other.
For the actual physical layout, it looks like one side of the floppy itself was used in it's entirity for the IBM data. The other side of the floppy had
Re: (Score:2)
At least on the IBM side, the FAT had the C64 tracks marked as full of "BAD" sectors. Without a sector editor or similar tool, there was no way to get it to even try to access those sectors.
Back in the day, both floppies and HDs commonly had sectors marked as bad. Part of the formatting process was verifying all of the sectors and marking the ones that failed as bad. More modern HDs hide the imperfections internally by remapping to spare sectors instead. The filesystem is presented the illusion of perfect m
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.
Re: (Score:2)
Re: (Score:3, Funny)
Not only that, but on a 3.5" floppy too!
Re: (Score:2)
I remember having lots of fun with directories; making infinitely deep nested structures, or playing with where . and
Most of the Pascal coding I did was writing TSR programs to do annoying things after a few minutes had passed.
Re: (Score:3, Funny)
LOL, ok that KB, not MB.
ST/Amiga Format (Score:5, Informative)
The short-lived, dual-format ST/Amiga Format [wikipedia.org] 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 [reversers.net] 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...
Re: (Score:2)
The amazing little floppy.. hehe..
Speaking of drives, do you recall the SpectreGCR and the Twister format? One of the Elders at the time (Dave Small) had written a program that re-worked the track/sector format. It skewed the sectors on the the disk so that as the read head moved from track to track it was quicker to get to the next sector number... The Spectre GCR was a hardware device that allowed the Atari ST drives to read the Macintosh disk format.
There was no difference, iirc, between an ST and MS-DO
Re: (Score:2)
One of the Elders at the time (Dave Small) had written a program that re-worked the track/sector format. It skewed the sectors on the the disk so that as the read head moved from track to track it was quicker to get to the next sector number...
I remember non-standard DOS formatters that used that trick, and others that managed to squeeze a few hundred more K out of the standard 1.44mb floppy.
Re:ST/Amiga Format (Score:4, Informative)
To be pedantic, the Amiga had a very flexible diskette drive controller. The drives themselves were essentially the same as drives used in PC clones, aside from having a diskette presence detect switch which was generally omitted in PC drives. As I recall, PC drives (even 5-1/4" ones) could be plugged into the Amiga and used, but the computer wouldn't automatically notice diskette insertions because of the missing switch. The Amiga used odd-ball 23-pin D-sub connectors for the disk drive, but they could be made out of DB-25 connectors with a Dremel tool.
The Amiga stored 880K (IIRC) on a 720K disk because it simply crammed more sectors on each track. The PC's controller would write a sector at a time, so its disk format required gaps between the sectors to allow it to write a sector without stomping on either of the adjacent sectors. The Amiga's diskette drive controller could write an entire track in one pass, so the Amiga format could dispense with both large inter-sector gaps and sector interleaving. The Amiga could also read and write PC disks (with appropriate software that bypassed the regular filesystem code), by simply programming the diskette controller to put fewer sectors on each track and place them farther apart.
Some folks liked to use nonstandard formats which crammed even more data on the diskette by using more than 80 tracks. Many diskette drives of the day were capable of stepping the head out beyond track 80, but how many tracks would vary from drive to drive. Thus, these nonstandard diskette formats weren't as portable as the normally-formatted ones, since hacker A might be able to write one or two more tracks on their diskette drive than hacker B's drive could handle.
Now, I think that the Macintosh drives of that era were physically different somehow, but I don't remember the details. I vaguely recall that there was a product that allowed the Amiga to emulate a Macintosh, and it had some sort of electronic doohickey that installed between the computer and the diskette drive to let the Amiga read/write Macintosh diskettes. Or maybe it required a completely different diskette drive... my memory is fuzzy.
This conversation does bring back memories, though! I remember having a flaky diskette drive and being too poor to either replace it or have it fixed by a pro, so I had to do a ham-fisted re-alignment by loosening the stepper motor and turning it by hand until it read some random disk semi-reliably! Hmm, I think I even did that in the snake-infested snow, uphill in both directions. :-)
Just more corruption on the 8088 ... (Score:3, Funny)
It's just another case of corruption on an 8088 ;-)
(If you know Trixter, then you know what I'm talking about ... http://www.oldskool.org/pc/8088_Corruption )
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.
Re: (Score:2)
I have a 45 single from a new wave band(MainFrame). The B-side doesn't contain a song, but a program, in 3 different versions for some UK computers. Pretty slick. There's a whole web page devoted to cassette programs stuck on Vinyl. I think even The Stranglers did it on a release.
Re: (Score:2)
Re: (Score:2)
I have a cassette of spectrum games, and the accompanying book in a plastic case, from a magazine in 1984. PC Format I believe, the box isn't to hand right now.
The magazine is still around, I keep wondering if I should post it to them.
Re: (Score:2)
I had a tape for some band that had modem noise on the b-side. It was a kermit transfer of the lyrics.
Probably the coolest thing ever! (Score:5, Informative)
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?
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: (Score:2)
I also theorized about this as a kid. It's easy when the platforms you want it to work with look at different places for their initial data, and easier if you can direct them to unusual places for subsequent data.
But if you have two systems with different processors both going to the same track and sector for their first data, it becomes an exercise in how to write machine code that both systems can execute and neither of them crash running. A matter of finding safe bytes that do nothing of consequence on
Re: (Score:2)
Incidentally, did you know that "<!-- ", in 80x86 assembly, is CMP AL,21, SUB AX,202D? Gives a new (or should I say old) meaning to ".com"...
Starglider 2 (Score:3, Informative)
This game used a custom hybrid format so the same game disk worked on both ATARI ST and AMIGA.
http://en.wikipedia.org/wiki/Starglider_2 [wikipedia.org]
Funny I did the same thing on Color Computer Disks (Score:2)
Way back when I was a 6809 freak, there was a period of time when I transited over from CoCo to PC. I used to format floppies on the PC, fill them with track-long files, figure out which ones where past track 16 or 17, rename them so they'd be invisible, and delete the others. Then I would format on the CoCo starting from track 17 and up, and mark the low "granules" (clusters of 9 sectors on the CoCo) as in use. I ended with floppies usable on both systems.
Took a few days to figure out how the FAT worked
This is nothing new (Score:4, Informative)
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.
Re: (Score:2)
That was old school hacking, before "War Games" and people trying to crack computers and security and writing viruses.
You were using your Amiga 1000 before "War Games" came out? That's pretty hardcore, man.
Re: (Score:2)
Yeah a bit of time travel was involved, but nevermind. :) It was a joke.
Commodore vs other formats (Score:2)
probably the other formats the directory starts on track 1 near the hub of the disk, where on the C64 and other DOS 2 disks the tracks started in the middle (track 18 of 35). So by doing a partial formatting you could write two formats on a disk.
Starglider! (Score:2, Interesting)
Re: (Score:2)
Umm, they're still quite common. Lots of music is put out with extra stuff (video or DRM) on data tracks at the end. Usually this uses the CD extra format which puts data at the end in a separate (but linked) session.
The CDROM + audio thing has audio starting with track 2 and is good , but not quite as good because if you put it into a CD player it'll try to play the first track as music and make bad noises.
Re: (Score:2)
The grandparent poster must not be used to store bought music media. I sure haven't used any of that obsolete stuff since I discovered mp3's in the 90's. His unfamiliarity with that old format is perfectly understandable.
Re: (Score:2)
It really wasn't that uncommon, Microsoft studios did the same thing in the late 1990s with Outwars and the original Age of Empires as well as the expansion pack. Earlier games used this technique to allow for less cpu overhead while playing music, typically the sound was just sent though the cd-in connector.
Re: (Score:2)
You used to see this a lot on computer games--one track with code, the others with background music. The game would load and then just tell the audio bits of the CD player to play the BGM tracks. This kept the CPU from having to deal with BGM, and you get CD-quality audio...
Re:Anyone remember audio+data CDs? (Score:4, Insightful)
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.
Re: (Score:2)
Quake 2 and Half Life both had excellent soundtracks to listen to independent of the game.
Re: (Score:2)
Answer: with a magnetized needle and a very steady hand.
Next question?
Re: (Score:2)
it was done with butterflies
http://xkcd.com/378/ [xkcd.com]
Atari 800/C64 disks (Score:3, Informative)
If memory serves me right, the disks you're thinking of were from Mastertronic or possibly Epyx (specifically, World Championship Karate, the only game by Epyx I had on floppy). There's a chance that it could have been one of Datasoft's games as well.
Re:Tiltowait (Score:5, Funny)
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.
Re: (Score:3, Funny)
I clicked on the story thinking he had found some kind of strange Goatse image embedded in the disk. I was very disappointed.
Thank you for that. I'll never be able to look at the spindle hole of an 8" or 5.25" disk the same way again.
Re: (Score:2, Insightful)
Seriously. If somebody did this today, it would be featured on the daily wtf.