The diskette that blew Trixter’s mind
Posted by Trixter on September 28, 2008
As an IBM PC historian, one aspect of my hobby is archiving gaming software. (You can take that statement to mean anything you want — whatever you think of, you’re probably right.) At the 2008 ECCC this past Saturday, a vendor wanted to offload his entire PC stock on me for $5, which I happily accepted since there was at least one title in there (Martian Memorandum) worth that much. When I got home, however, I found two additional Avantage (Accolade’s budget publishing title) titles that have not yet been released “into the wild”. This means there are no copies of these games floating around on Abandonware sites. For me, this was like finding actual gold nuggets in a collection of Pyrite.
The two games I got were Mental Blocks and Harrier7, so they join my third Avantage title Frightmare. I decided to archive all three properly, and it was when I got to Mental Blocks that I ran into something I’d never seen before: The manual for Mental Blocks claims that, for both C64 and IBM, you put the diskette in label-side up. I thought that had to be a typo, since every single mixed C64/IBM or Apple/IBM diskette I have ever seen is a “flippy” disk where one side is IBM and the other side is C64 or Apple — until I looked at the FAT12 for the disk and saw that tons of sectors in an interleaved pattern were marked as BAD — very strange usage.
The Incredibly Strange FAT of Mental Blocks That Stopped Living And Became Mixed-Up Formats
A DIR on the disk shows that only about 256K of it is usable as space, instead of 360K. My Central Point Option Board’s Track Editor (TE.EXE) confirmed that every other track on side 0 cannot be identified as MFM data. So the manual is correct, and this truly is a mixed-format, mixed-architecture, mixed-sided diskette.
This diskette has officially blown my mind.
This is the very first time I have ever seen something like this. The data for the IBM program takes up more than 160KB as evidenced by a DIR. The C64 1541 drive is a single-sided drive; IBM’s is double-sided. Based on all this, we can deduce how this diskette is structured and why:
– The IBM version of the game required more than 160KB (ie. needed more than one side of a disk), probably because it has a set of files for CGA/Herc (4/2 colors) and another for EGA/Tandy (16 colors) and either set will fit in 160K but both won’t
– The C64 version required around 80K, based on the fact that every other track is unreadable by an IBM drive
– The publisher had the requirement of using only a single disk to save on packaging and media costs
– Not wanting to limit the game to either CGA or EGA, someone at Artech (the developer) built the format of this diskette BY HAND so that DOS would not step on the C64 tracks, and somehow the C64 would also read/boot the disk
I don’t know how the C64 portion boots since track 0 sector 0 looks like a DOS boot sector, but quick research shows that C64 disks keep their index on track 18. If anyone knows how C64 disks are read and boot, I’d love to know.
I think I need to go on a mission to discover who built the disk format(s) by hand to see what he was thinking. Did he work on it for weeks, feverishly trying to figure out how to meet the publisher’s demands? Or was he so brilliant that he did it all in a day or so, not thinking too much about it other than it was just another facet of his job? Fascinating stuff!
Just goes to show that you can still get surprises in this hobby after 25 years, even after being considered one of the top 20 “subject experts” for PC oldwarez. I guess you truly can never see it all.
Oldskooler Ramblings 
Nils said
I think one word sums it up: Neat.
niggot said
niggabuts
dan said
I can understand very well your fascination, as I often find myself intrigued by various things, especially if they happened some time ago (In the glorious past ;)).
Joe said
An 80s myth busted!!!!
chopin said
that is incredibly cool
this mysterious programmer deserves an award for services to computer awesomeness
Telkom said
Much more impressive than my 1 megabyte hard drive I got as a present in the 80’s :(
Snappy said
Hec ould have wrote a composite disk image reader that reads both IBM and C64 images and write it to the disk on a disk sector level, and not through the OS File I/O level, which would be limited to what the OS dictates.
Kuroki Kaze said
Cool, really.
Dom said
“The Incredibly Strange FAT of Mental Blocks That Stopped Living And Became Mixed-Up Formats” – love the reference.
vorlath said
Yeah, C64 1541 disk had 35 tracks with track 18 reserved for directory entries. But only the Block Availability Map needs to be present on track 18, sector 0. The first two bytes of that sector states what track and sector the directory begins. Directories almost always start on track 18, sector 0, but it can be moved.
C64 never actually boots a program on disk. You have to first load in a file and then run it. Binary programs tells the C64 where in memory it wants to be loaded up. The run command is for BASIC, but usually what you just loaded was in binary. So what usually happened is that the binary code would load up where BASIC programs are stored (as when you type 10 print “HELLO”) and the first BASIC command found was actually from what you just loaded and it would immediately transfer execution to itself in binary (usually by having overwritten the stack so that when the run command returns, it will actually go back to the binary code instead).
And that’s how:
load “*”,8,1
run
worked for binary programs. Some programs also just overwrote the beginning of the memory where the stack is stored and you didn’t even need to type run.
vorlath said
Correction: Directories almost always start on track 18, sector 1, but it can be moved.
Mickut said
If you’re interested only in the sector data, it’s the same as used in C64 emulator disk images (the D64 -format). The track 18 sector 0 has the block allocation tables (BAM), that tells which sectors are in use and t18s1 starts the directory structure. Each data-sector has the first 2 bytes as Track Sector pointing to next data-sector, or 00 NBytes, for the last data-sector where NBytes is [0-254] telling how many bytes of the sector belong the data-chain. With C64 drives the tracks start at 1, the sectors start at 0 and the number of sectors per track depends on the track. As it’s been a few years since my C64 days, I can’t remember the exact details anymore, but the D64 format should be pretty well documented, if you can read the sector data somehow.
Paolo Bonzini said
I don’t know exactly how C64 disks are read, but yes, the directory is in track 18. You’d load a game by doing LOAD”*”,8 (load the first file in the directory, which would be written in assembly language but with a very small BASIC prologue leaving control to the assembly language code) and then RUN. So, no big deal to read the data.
The weird part is that C64 disks have a variable number of sectors per track, and that there are 17 to 21 *256-byte GCR sectors* in a C64 track, while there are always 9 *512-byte MFM sectors* in a DOS track. So the low-level bits of this disk were indeed interesting, and that explains why TE.EXE did not make sense of it. :-)
Anyway, it must not have been *that* hard to write the disk once it was “conceived”. All that was needed was to format the disk on the C64, write the bad sectors for even tracks to the BAM (block allocation map), reformat every other track + the second side on the PC, and write the bad sectors for odd tracks to the FAT. All of the necessary tools (or at least routines) were probably already available as part of copy protection schemes. After this was done, either OS could probably write to the disk without damaging the other architecture’s data! For me, the fact that it might have been quite easy to do, is actually increasing the awe factor…
I still wonder how they managed to prepare the disks they sold, because what I mentioned above is a genuinely manual process. But I have no clue anyway of how disks were copied from the master copies, so maybe this was no harder than distributing other copy-protected disks.
Kevin Thorpe said
I did a very similar thing to get dual format BBC Micro and Research Machines 480Z diskettes back in the day. We used to publish educational software for both and it saved a lot of media.
Dr Herbert J. teaBagger said
I will create a GUI interface using Visual Basic… See if I can track the masater file allocation catalog….
qele qele said
great! thanks
John Zenger said
I saw something similar in the Apple II world. Beagle Bros had a way to format a single disk so that it could be used in both DOS 3.3 and ProDOS. The trick was that each OS put the index on a different track (DOS 3.3 at the front, ProDOS in the middle, IIRC), so you just write the two different tracks and then use the indexes to block out the half of the disk allocated to the other OS.
h3 said
Awesome and very ingenious!
Paolo Bonzini said
@John Zenger: Interesting — though notice that there is a difference, in that in this case the *physical* bit-level patterns would not make sense to the “wrong” drive. In your case, you could use a per-sector copy to create a new disk, while for Mental Blocks you’d need to do a physical copy of everything, including the beginning-of-sector markers.
Paolo Bonzini said
@vorlath: the program would not need to do anything like overwriting the stack. The BASIC program started at location 2049 (if I remember correctly) and they would do just
10SYS2060
or something like that (2060 = address of the startup routine, often placed right after the end of the basic program). Then, the assembly language program would simply never return. The only way to quit games was to turn off and back on the machine or, almost never, to do a “warm reboot” with the RUNSTOP+RESTORE key combination (which would reset the BASIC interpreter’s state to sane values).
Gerald Ford said
Pretty fascinating. I can only assume that the two disk formats are somehow inter-weaved and use different sectors of the disk. A lot of early PC games seemed to use all kinds of stupid disk setups. I remember playing Starflight alot, and you had to make a copy of the original floppies, because when you died, the game saved your “dead” state, so you had to overwrite your copied disks with a fresh “copy” to play again. If you died using the original disks, that was it. :p
Thank god for modern standards and such. The early PC games were a wild west of strange setups. :D
Loved seeing the Disk Editor output. That is truly old school.
The Great BDB said
The disk could have been copied using a disk nibbler, a program that would do a bit copy of a disk without even looking at the file system on it. They were handy for duplicating copy protected disks because they would ignore “bad sector” errors and continue copying.
Torley said
Glad to see the Martian Memorandum reference — I never played it, but am a fan of Tex Avery’s first adventure, Mean Streets!
rick_of_racy said
I’d love to see an interview with the developers of this. What a brilliant idea. I wonder if it took longer than to produce the actual game.
It gets to my motto:
“Limitations Breed Creativity”
Kalyan said
Nice hobby, and this is very interesting find. I am also interested in finding the original programmer’s intention and the number of days / weeks it took for him to do this. If you find this info please post on your blog.
Eric said
Very cool find. Hopefully now with the attention this article is getting you will find out who is behind this.
joel8360 said
I have forgotten nearly everything I once knew about the 1541 disk format, but it looks like Amazon has some copies of “Inside Commodore DOS: The complete guide to the 1541 disk operating system” which will tell you just about anything you’d care to know.
LarrySDonald said
Beyond the initial sector 18 the C64 had an amazing amount of freedom in what to do with a disk. The 1541 was programmable to a degree I’ve never seen in a drive before or after (possibly because later drives were included as defaults), it was even possible to use it’s CPU as a secondary with equal performance as the C64 itself beyond memory limitations. As long as a PC didn’t need sec 18 (I never got that deep into specifics on PC disks) it wouldn’t be hard for a decent C64 coder to work around the rest and store whatever wherever – the vast majority of software used non-standard formats and non-standard drive software as soon as they were up and running. The “real” drive firmware/software was awful and rarely used except to get a loader going since the comm and timing to the drive was vastly overkill and a good 10x speedup could be had by handling timing and error correction differently. I’d expect marking 18 and whatever else space needed bad and then writing the data with a 1541 wouldn’t be any harder then constructing a normal loader, after marked bad a PC should be able to handle the rest of it’s writing without any issues.
Paolo Bonzini said
@LarrySDonald: you would still need some kind of standard filesystem to allow LOAD”*”,8 though.
old fart said
still amazes me after all these years the lack of “understanding” a lot of people have who claim to be programmers. heck when i was knee high to the grape juice it was common knowledge how to get your computer to do anything you wanted…all you whippersnappers with your microsoft and linux and apples…hell we had to walk 16 miles in the snow just to get to the library to hook up to the 2400 baud modem.
smelly said
2400 baud ?
Luxury.
We had to drag dead priests for 1200km just to use a borrowed 75 baud asr33 reader/punch illicitly installed in an outhouse !
Nick said
Where can I download this game?
rawsausage said
Sure, old fart. And it was uphill. Both ways. And the wolves howled.
Samuel F. B. Morse said
Hey old fart, you had 2400 baud modems? I had to invent my own telecommunications system!
drdick said
It seems there is always five bad clusters in a row, that makes 10 sectors because on 360KB disks there are 2 sectors/cluster. So it simply is one full track on one disk side (plus one sector on other side).
C= 1541 uses only one disk side at a time (disk have to be flipped to use another side).
Ithink here C64 uses one continuous area on disk and that is marked as bad sectors on PC filesystem. Maybe on C64 filesystem similar trick is used to give free tracks for MSDOS.
So nothing very special here.. :)
Justin Kerk said
Hmm, you should send it to the C64 Preservation Project (http://c64preservation.com/) guys too to make sure the C64 data also gets properly archived.
Milosz Derezynski said
It is extremely troublesome to format a disk in such a way that all even tracks are GCR and all odd MFM or so.
You’d basically need either a hybrid drive, or format/write the disks with 2 single drives, but there you’d risk overwriting written tracks (i admit this is very unlikely, I never had it happen with 2 different disk drives of the same type, eg. two 1541s, but at this occasion I just wanted to point out the chance; maybe the alternating encoding makes this a worse problem.)
So even if some of what I previously said might not be entirely true, I still stand by that creating such a disk would most likely overweigh the cost of just shipping 2 disks; I think this was rather a thing of fancy, not of economics.
Richie said
You had actual howling wolves? Luxury! We had to howl ourselves!
Wes Garland said
@paolo – BASIC storage did indeed begin at 2049 on the C64. load “programname”,8,0 (or simply ,8) instructed the C64 to load the program into the start of BASIC. This was how BASIC programs could be written on the VIC-20, PET, etc and still run on the C64. BASIC interpreter token values were also preserved from machine to machine, and even from BASIC 2 (VIC, C64) to BASIC 4 (CBM8032 and ilk).
The load “programname”,8,1 command is more interesting. It takes the first two bytes of the PRG file and uses them as the address to start loading data into. One technique to make programs auto-start (rather than typing run) simply involves overwriting the top of the stack. When the BASIC interpreter’s load subroutine finished loading the PRG file, it will RTS. The CPU then pops the top two bytes off the stack, and uses them for PC.
The C64’s memory map even makes this quite practical, as the only stuff between the top of the stack and the start of BASIC program storage is stuff like the keyboard buffer and opened file table.
8-bit micros were great. You could actually reach down to the bare metal and (reliably) make it do something totally new, cool, and un-thought-of by the inventors.
Wayne Colony said
Paolo Bonzini (#13) mentions in passing GCR relating to the C64 disks. GCR was a 10 bit scheme to encode 8 bits of data insuring that you would never have more then 3 ones or zeros in a row on the actual media.
Commodore was amazingly paranoid about error detection so they had odd schemes on writing to media. A fun example was shown by most of the tape accelerators. When a program was written to tape it was actually written twice! The acceleration came from ignoring the second copy. The Commodore disks had a large number of formatting bits on them and most of the copy protections schemes simply erased or ignored these sync marks.
The 1541 had a 6502 in it so you could reprogram it to do almost anything. You could change the number of sectors on a track or even oscillate the head at high frequencies to make (very bad) music (this would quickly destroy the drive).
I may still have some books on hacking the disk programs for a 1541 in storage. One book in particular had a range of programs to hack directly on the disk structure and the drive’s programs. It was mostly related to cracking copy protection on the odd disks.
Nate said
Hi Trixter. I’m one of the members of the C64 Preservation project. We have a custom copier (mnib) that reprograms the 1541 to dump whole tracks over a parallel port added to the drive. We’d love to grab a copy of your disk if you’d let us. Contact me or Pete Rittwage for info.
Thanks,
Nate
Wes Garland said
@Milosz – While creating the first disk would be a PITA (a very, very cool PITA, though!), replicating it might not be such a challenge. Low-level copying hardware might understand neither GCR nor MFM — there would certainly be no need to.
Now, it wasn’t available when this software was written, but I wonder — do you think the 1571 could be programmed to create or duplicate this disk? It seems like it might be possible, although you’d probably have to load special software (“firmware” nowadays!) into the drive.
Troy Heagy said
>>>The 1541 was programmable to a degree I’ve never seen in a drive before or after (possibly because later drives were included as defaults), it was even possible to use it’s CPU as a secondary with equal performance as the C64 itself beyond memory limitations.
>>>
I’ve been told (but never verified) that the Amiga drive is actually the most-flexible, being able to read any 3.5″ disc ever produced (except 2.88 megabytes).
The 1541 had its own CPU, so it had the ability to operate independently from the computer (like a printer), which was always a neat trick. It also allowed programs like GEOS to download “fast load” programs to make access nice-and-speedy, or to create new formatting methods that allowed even more data to be squeezed on each disk.
soppulf said
A software disk nibbler would be no use here … very few floppy controllers give you access to the raw data before mfm/gcr decoding. Not the Amiga cia/paula, neither the intel 82077 floppy controller. Generally, you need special hardware, especially for writing.
Troy Heagy said
>>>you’d probably have to load special software (”firmware” nowadays!) into the drive.
>>>
You got it right the first time. The 1571 had a CPU so just like any other computer, you load it with software that can handle unique disks.
Random said
@Milosz Derezynski:
Not really. This is quite easy to do, even on a pc floppy drive, if you know where to poke the 1’s and 0’s. The trick is not relying on the OS device handlers (or, overriding them with your own interrupt vector table ;)
Paul Shirley said
Its a lot simpler to create a disk like this than most of you think. When you remember there are low level calls to format individual tracks on the PC side (and presumably the C64 – never messed with its drive), or at worst the drive controller is directly programmable for individual track formatting. Format on the C64, mark whatever blocks you want then format individual tracks on a PC. Provided both drives are reasonably well aligned (always a problem with the 1541) tracks won’t right over each other.
In fact most PC controllers were programmable down to ‘nearly’ the bit level, capable of writing arbitrary track data, you just couldn’t bypass the MFM coding. Last time I did stuff like this I actually wrote everything on an Amiga which allows writing individual flux transitions and any bit format you like. Confused the duplicators a lot trying to handle my non-standard MFM coding on a mixed ST/Amiga master ;)
ehud42 said
I hacked around on a ][e in the ’80s enough to just begin to actually appreciate what was done here. The assembler for manipulating the floppy was beyond me a the time, but I clearly remember some games having speed loaders, ‘hidden sectors’ and other crazy copy protection schemes and enhancements.
Kudo’s to the clever programmer who created this.
Michel said
@17 (John):
Apple II system were using the following:
– Track 0 Sector 0 for boot (after a nibble).
– Track 0 Sector 1, 2, 3 (Block 0 and 1) for ProDOS boot supplemental
– Track 0, 1, 2 for Apple DOS system
– Block 2 for directory Key block (ProDOS)
– Track $11 (17) for Apple DOS 3.3, using sector 0 for master and free blocks, and two sectors for file pointers (bare minimals, by default, it takes the full track $11)
Although there’s no real reason to do so other than hacking interests, I think (TBD) it would theoretically be possible to create a single diskette that would be booted by ProDOS, recognized by DOS with a folder, booted by a PC and loaded on a C64, as C64 and DOS aren’t using the same track for directory, ProDOS requires 6 sectors out of 16 for booting and directory purposes, with a particular nibble for recognition and BIOS requires another sector for starting up with another different nibble.
ps_inkling said
as far as creating the original disc, not that hard. format the whole disc for a commodore. use track 18 sector 0 for bam and sector 1 for directory (just one sector). calculate number of tracks needed for commodore program storage. mark the rest of the disk sectors as used.
move the disk to a pc. using a custom program, format the individual tracks not used by the commodore for the pc (do not use the dos format, it would wipe the disk of commodore info). so, the back of the floppy and the tracks not in commodore space. mark the tracks not formatted for pc as bad in the fat sectors on track 1.
since the commodore puts more sectors on the outside of the disk (by timing, not varying the spindle speed ala macintosh) maximum storage would be to start the commodore tracks at track 2 (dos needs track 1) up to track 18, and any spillover past 18. format the pc tracks past the physical location of the last commodore track, and the back of the disc.
based on the limited screenshot, this is my guess at how it was done. probably a two step process — mass format as commodore data disk, use custom pc program to write pc format tracks, test and ship.
zBeeble said
What nobody talked about was “booting”. C=64 didn’t “boot” from a disk. They booted, period. The process took about 2 seconds… at which point you’re dumped into the BASIC interpreter with a “READY.” prompt and blinking cursor.
The 1541 disk drive was a stripped version of the earlier PET drives. The PET drives had processors because the PET was shipped before drives were ready. The PET had an IEEE bus that was vaguely similar to HPIB (or so I’m told). There were single density single and dual drive, and dual drive double density drives. IIRC the double density also featured double sided.
When the C=64 was created, it was outfitted with a serial version of the IEEE bus that the PET used (which was 8 bit parallel).
When a C=64 (or a PET) talked to it’s hard drive, it did so using a standard bus protocol — the drive was entirely independent and indeed could be rebooted (or not) when the computer was rebooted (or not).
Some other people here have talked about how the drive could be reprogrammed. All manner of accelerators existed for the drive (the serial bus was dog slow). Some of these were software-only solutions !
Anyways… typically, for a game, you entered load “*”,8,1 followed, sometimes, by run. This loaded the first program on the disk and executed it. Some have already mentioned that some programs could autorun once the load instruction was given.
It’s worth noting that neither the C=64 nor the 1541 drive would automatically boot from a disk. The full DOS for the computer (such as it was) was in ROM as it was in the drive. Formatting a disk, for instance, required you to enter:
open15,8,15,”n0:diskname”
(ie: opening a data connection to the command channel 15 and issuing the command n0:)
Otto said
@Paolo Bonzini and @vorlath: You two are almost correct…
C64 files on a disk actually had something extra most people don’t know about. The first few bits of the file contain, believe it or not, a memory address.
When you do a LOAD “*” ,8, the 8 is telling you what device to read from, in this case, the disk drive. This is the same as LOAD “*”,8,0.
That 0 is telling the load command to load the program into the start of BASIC memory (location 2049). If it was a 1 instead, then it’s telling it to load it into the location in memory specified by the file itself.
Many auto-booting C64 programs did indeed overflow the stack. The 1 was an all access pass, a program could overwrite any section of memory it wants, including the first 2K of memory, which included, among other things, the “next instruction” pointer. So some programs could indeed self-execute just from a LOAD “*”,8,1 command.
Other programs used the fake BASIC trick, by loading at location 2049 regardless of whether 1 was specified or not, and then having a pretend program to make a SYS call to the location in the BASIC memory block. This was called the “BASIC STUB” technique, and it meant that you had a lot more memory to work with and that ,8 followed by RUN would still execute your program instead of having to run it by doing SYS 49152.
<CONTENT /> v.4 » Disk Shenigans, Old School said
[…] The diskette that blew Trixter’s mind « Oldskooler Ramblings […]
AlanRII said
A 1571 could tackle the task of both creating and copying this disk. It has the hardware and routines necessary to handle both MFM and GCR encoding. Would just take a little bump of a user program loaded into the drive or used on the computer side to control the process.
As for the Amiga floppy drive, it is fairly flexible owing to the interaction between hardware and system software. It cannot, however, read HD formats using standard floppy drives, or indeed use most standard floppy drives without minor modification. It does read HD formats using a special HD drive which halves the rotation to accommodate the 250kb/s transfer speed of the floppy controller. AFAIK, it does not read above HD format (2.88 et al.); the native format is 1760k, and can handle 1.44 and Microsoft’s DMF as well.
This Blows Me Away « I like onions. said
[…] Classics, IBM It blows this guy away too. Chalk it up to computer arcanum, but someone found a lost disk that works on both C64 and IBM floppy drives using a disk formatted by hand. I can only wonder if they formatted it by hand or actually copied […]
notfred said
When I was at school in the 80s we had Commodore PETs (same disk format as C64s) and BBC Model B micros. We could buy floppy disks from our teacher and they were expensive (for a school kid), so most of us did the format trick mentioned here of splitting the disk in half and using the first half for the BBC and the second half for the PET. This was well known at the time.
squarebrackets said
I have to say this does sound
really impressive, clearly the
person who sold it to you
should have know that it was
more valuable than $5, oh well,
their loss
x
Trixter said
First off, I’m amazed at all the responses I’ve gotten. I should post about oldwarez more :-)
Now some responses:
@Nick, the game isn’t available in the wild yet, but a friend of mine (who has more free time than I do) is working on cracking it. The C64 version of Mental Blocks might already be in the wild on c64.com (or c64.org, I get them confused). I see a reference to it at http://www.gamebase64.com/game.php?id=4736&d=42 but no download.
@Justin, I’ll consider it once we have the PC version released.
@Wes: I too enjoy how older machines have known boundaries. I regressed in my PC demoscene coding back to the original PC (actually, I’m working on a PCjr demo) because the target is fixed and known.
@Nate: Email me your contact info. I could try to image the disk myself, but I don’t have the cable and have never tried (I haven’t even powered on my C64s in over a decade) so I’d feel more comfortable shipping it to you. (I want a cracked copy back! ;-D
@Wayne: Thanks for the info about how the 1541 handled data. I had no idea stuff was so redundant, although I did realize the 1541 was quite reprogrammable.
@Random: This is *not* easy to do on a PC floppy drive, at least, if you’re going to keep it connected to a PC controller. There are very few techniques that can read, exactly, the bits off of a disk and the only program I know of that can do it is Disk2FDI.
@Paul: It may be “simple” to you, but having never run across the concept before, I found it extremely clever :-)
@ps_inkling: That is exactly how I would have done it too. Just use (and specially mark) the diskettes in their respective environments.
timmy said
Nothing special. This was common practice for the Oregon Trail disks (Macintosh and IBM-clone compatibility on one side).
Eric said
SYS 64738
Jim Frost said
I’m with Paul Shirley, this doesn’t seem like it would be that hard to do. All of the systems I’ve used allowed single-track formatting, and it’s a win that DOS used track 0 for important metadata while Commodore used track 18. It would not be difficult to create a disk with half of the tracks formatted one way and half the other; there would be manual massaging of the metadata, primarily to mark the alien-formatted tracks as off-limits, but this is easy. You could even do three format with IBM, Apple, and Commodore so long as the Apple and Commodore formatting was on flip sides of the disk.
Clever, but probably not really a huge savings.
jim frost
jimf@frostbytes.com
Rob Nicholson said
I dabbled with the C64 disk drive in the 1980s and wrote my own little disk system for one of the SSI games we wrote. It was pretty common around then mainly because the ROM routines to do disk I/O were very slow and didn’t the screen turn off as well? I managed to get something like x4 (maybe x8) speed increase with the screen on by using real handshaking. The I/O port had all the bits for handshaking but the ROM routiens were not efficient at all.
The disk drive was a little computer in it’s own right. I can’t quite remember the details (*wish* I had the source) but I think the disk interface was pretty much bit level and all the decoding was done in software.
The Amiga disk interface was certainly just a bit stream that was fed into a rotating 16 bit shift register which you programmed with the 16 bit start word that marked the start of the sector. I’d always wondered how soft sectoring worked. It did meant that a disk, in theory, had twice as many bits on there as there was capacity but you could never use it.
You also controlled the stepper motor – as could the C64 – and some enterprising people almost blew their drives up by getting them to play tunes with the stepper!
Cheers, Rob.
Elrond Hubbard said
Wow, this thread reminds me of the old days on USENET, when the s/n ratio was reliably high… *sigh* Anyway, a lot of people have mentioned how slow the 1541 drive and/or its serial interface was. True, and a huge boon to makers of fast-load cartridges and the like. From what I understand (sorry, no reference), this was the result of a terrible last-minute decision made under pressure to meet the C-64’s ship date.
The ROM routines for communicating with the drive probably originated with the PET, by way of the VIC-20, which had its own floppy drive, the 1540. When the C-64 was nearly finished the engineers realized they had a problem: Memory access on the C-64 was interleaved, with the 6510 CPU getting the even cycles (let’s say) and the VIC-II video chip getting the odd cycles. This threw off the timing of the disk read/write code sufficiently to prevent it from working. To meet their ship date, rather than write more efficient routines, Commodore’s engineers deliberately slowed the disk interface down and released the crippled drives as the re-badged 1541. Similarly, the C-64 would have to use the VIC-II’s screen-blanking trick to make it stop accessing memory so that it could read and write to the tape drive efficiently; some nibblers with custom disk routines would do the same thing.
And yep, this hybrid disk is a cool trick.
Rob Nicholson said
>When a C=64 (or a PET) talked to it’s hard drive, it did so using a standard bus protocol
Ahh that explains why is was slow :-)
Rob.
Rob Nicholson said
>write more efficient routines, Commodore’s engineers deliberately slowed the disk interface down and released the crippled drives as the re-badged 1541.
Ahh now it’s coming back to me. Yes – the disk routines in the C64 *were* timed in terms of something like “Give me bit 0 please”, “wait 10ms”, “take whatever is on the port”.
That’s why the screen was disabled – so that the timing routines could be guaranteed.
It didn’t take long for people to realise that there were sufficient bits on the I/O port to allow full handshaking which could run at whatever speed the CPUs at each end could work. I think with the screen on, it was the C64 not the disk drive that was the limiting end.
Three bits used maybe? Raise REQUEST bit on C64, noticed by 1541 which puts the data DATA bit on out and raises READY bit. Noticed by C64 which reads the data bit and then drops REQUEST to indicate “I’ve got it”. Waits for 1541 to drop READY bit before carrying on.
Can’t remember whether all this was polled or interrupt driven.
Cheers, Rob.
robotii said
Wow, that is some ingenious method of being able to use the same disk. I didn’t even know the disks were compatible.
Jens Schönfeld said
It was actually common back in the days to mix formats in order to save media cost. However, I have no idea how the actual duplication process was made, as mixing MFM and GCR seems fairly difficulat in a single machine. True, there were drives that could read and write both, such as the Commodore 1571, but I have a hard time believing that media duplication was done manually.
You talk about the “option board” in your article – that’s a fairly old thing for the ISA slot AFAIK. If you only have PCI, then you might want to look at the Catweasel floppy controller, which lets you read and write lots of different formats – including PC, C64, Amiga, VersaDOS, TRS80 and many others. No special drive needed – just attach a 3,5″ and/or a 5,25″ drive from your PC-floppy collection and go for it.
Hans said
Whoever came up with the solution is a floppy disk Ninja. ;)
Cpro said
wow that is pretty awesome (on an unrelated note I did get your 8088 corruption demo running on my 286 before my 25mb ide conner hdd died, although it crashed several times before making a full run, still, man that was neat.. although my 8088 with a 386 ‘upgrade’ card wouldn’t run it at all, and I don’t have any good ways of getting info on my last st-225… I haven’t looked, but has anyone developed a mfm to cf? (I have an 8 bit isa ide controller, but it’s never worked right, so I can’t even trust it as far as I can throw it)
As for the c64, they really don’t ‘boot’ floppies (unlike the apple II or the pc), once you turn the unit on you are in basic and you have to load portions of the disk yourself (all landings on the Galactica are hands on) which are stored on a specific file on the disk Also the commodore disk drive is a whole computer all by itself, even including it’s very own 6502, so it’s possible to make it do several things that it wasn’t designed to. I’d would think your best bet to get an image of the disk resides in a 1541 drive… there are several imaging programs out there for dumping discs with the use of the 1541 and a parallel cable, but man is that disc weird!
keep the old things working, I just got someone’s heavily modified appleIIgs (with a hdd) along with 7 crates of floppies that I hope to have time to go through, catalog, and dump for all to enjoy someday
Jay Levitt said
I found (and then lost) a great USENET conversation on the Epyx Vorpal fastloader, which was probably the king of Commodore 64 fastloaders – something like 10x faster than the next fastest, IIRC. Ridiculously fast. Made my 1541 almost as useful as my Lt. Kernal hard drive fast.
I’d always assumed that it went for the third bit as well; most fast loaders borrowed the clock line to go from one bit to two.
But apparently what Vorpal did was even better: it timed its communications subroutines so perfectly that it could execute them while the disk was spinning. That is: it was able to do no-wait unbuffered I/O from the 1541 to the C64. That, plus well-spaced sectors (timed to coincide with the breaks in those subroutines) gave Vorpal its speed.
Wish I could find that thread now.
And, yes: “Inside Commodore DOS” was the bible.
Trixter said
I am honored that Jens found me to post about the catweasel, which is something he created and something I have *always* wanted to try but never got around to it. Jens, you’d be interested to know that the Option Board has some very odd limitations — for one thing, it can’t read GCR at all, and some protections (like Rob Northern’s COPS Copylock II) can defeat/confuse it — so I think a catweasel will be in my future at some point. I’m tickled you saw this post :)
For Old Hack said
You can easily copy the pre-encrpted data. HE SAID he has a CopyII Option card. Which I would guess could also duplicate the disks. Also a few disk editors on the PC would allow you to write anything to a track. It was able to copy Apple II disks, which use GCR, and even a few Apple II games. Since I never used a commie, I didn’t get any software for it. I recently found a game based upon the name of a configuration file. Turned out it was extremely rare anyway, and a version I had never heard of or seen. ( Empire 4.34ER)
Nerdsuperhero said
Proof that nerd computing skills have seriiusly declined since the ascendance of MS Windows.
This type of OS and Disk subsystem programming was old hat back in thos days of nerd superherodom!
m i n d c o d e » Blog Archive » Good old-skool h4×0r! said
[…] seen on slashdot, this story made me smile in pure, raw nostalgia: The manual for Mental Blocks claims that, for both C64 and […]
jintoreedwine said
That was a great post :) . I always love a good tale of old school computer trickery
CompaniaHill said
Ah, fond memories. At the height of 8-bit game programming, when the Apple/Atari/C64 machines were the bulk of the market and IBM’s PC (and “PCjr”) were the annoying newbies, most game coders used the default boot tracks and sectors and disk formats, not so much because they were “standard” but mainly because they already existed and it was the quickest way to get your game to market. “Copy protection” usually took the form of specific bad sectors that the game startup code would verify. I guess we figured that truly custom disk formats were only created by the best (or craziest) coders. So of course our game company [name withheld] created our own disk formats. We reverse-engineered the Apple II’s ROM disk boot assembly code (and found a bug in the IIc ROM’s equivalent, which earned us some nice praise in letters we traded with some Apple techies). The ROM would spin up the disk and read the first track, to which it would then hand over the CPU. So we wrote our own loader code, with no file system overhead or its imposed sector interleaves. My favorite feature of our Apple loader was that we tuned it to suck up an entire track in one revolution of the floppy, resulting in extremely rapid-fire seeking sounds from the drive. The first time most people heard it, they though it was formatting their game disk! The Atari/C64/PC drives had hardware APIs that wouldn’t let us drive the magnetic heads quite as directly, so our games didn’t load quite as fast from them as they did on the Apple, but we still tuned them to load as fast as their hardware would allow. I still have copies of these disks, and I’m still quite proud of that work, even now decades later. And writing code to play four-voice music, using attack/decay waveforms, over the Apple II “keyboard click” speaker. Sigh, lost arts. I may as well be bragging about my slide rule skills, or my buggy whip collection. Get off my lawn!
Simon said
Thanks for this insight into the past… This is very, very cool indeed.
Having been an avid computer user since 1983 (ZX Spectrum thankyou very much), I loved this slice of history!
Zandr Milewski said
I used to work for a company that made commercial floppy duplication equipment. We had our own electronics on the drives, and could easily write GCR and MFM on alternate tracks. But we had custom read and write channels all the way down to the heads. The only thing the stock drive electronics were doing was running the spindle and head stepper motors.
We were doing all sorts of fun stuff. Simultaneous double sided writes, don’t wait for index after step (so 2.33 revolutions to write/verify/step) 4x spindle speeds, etc.
Golan Klinger said
One small correction. Mental Blocks *can* be downloaded from the Gamebase64. Look for a link labeled “Latif”. It’s a ‘cracked’ version in d64 form and since a d64 is a container (of sorts) rather than a true image of the original disk (those are called g64s) there is little to be learned from it other than that at some point someone else encountered this curiosity.
jason said
Is this similar to how the old blizzard games would have both windows and mac on the same disk?
Jason Scott said
Jason: Similar in one fashion (readable data for two platforms on a single media), but HFS/ISO hybrids were a common situation from the start once Macintoshes started using CD-ROMs – this cross-platform compatibility was covered in CD-ROM burning programs and the like.
The methodology for doing this PC/C64 hybrid, while similarly “simple” once you know what to do, has very few examples in the wild, regardless of some statements above. Hence the amazement at discovering it.
Of course, and I must point this out, the market/needs to present the same general product to Mac/PC platforms simultaneously were/are MUCH higher than in the PC/C64/Atari era.
Cpro said
@jason: windows and mac was easy, because they both used mfm writing and (essentially) the same drives (which is why certain early macs loaded with just an extension could read pc disks as long as the density was the same or lower than the drive was rated for), and at the very least you could have it on separate partitions, but in this case, the methods of writing data are completely wrong with one another, thus a (rather difficult) hack was used. to put it into perspective, it would be sorta like a piece of magnetic tape with both betamax and vhs recordings of differing subjects written upon it that while on the same tape and track didn’t interfere with eachother because the author of the tape accounted for both systems somehow (yes it’s a bad example because I chose a linear format and one with different physical packages, but I couldn’t think of anything better)
Bill said
C=64 pwns your Vista!!
K.Mandla said
Now that is pretty cool. :)
ShawnFumo said
I loved playing Martian Memorandum as a kid. “You are nothing but a fake cop!”
Trixter said
@CompaniaHill: How the heck did you get 4 voices out of the Apple beeper? Especially since the CPU and memory were so slow?
Dave Farquhar said
I remember this game from my Commodore days. Someone in my circle of friends bought it, and the dual nature of the disk surprised us. We found someone who had both a C-64 and an IBM PC to have them try it. Sure enough, it worked on both machines. We speculated a bit about how it worked, then someone looked at it with a sector editor and came to the same conclusion you did.
As I recall, the game had very little, if any, copy protection. So I’m not surprised that the C-64 version is in circulation, but heaven only knows how closely a D64 image resembles the original disk. Lack of copy protection would also be unusual for a C-64 game, but maybe they figured all the nibblers on the market would get hopelessly confused by the FAT portions of the disk.
We thought the dual disk format was a really clever hack at the time, which is probably the only reason I remember this game. After all, it was just a Tetris clone, and there were plenty of those floating around in the 1988-1990 timeframe.
raymccullie said
That’s what’s fun about older games and software. Now days developers seem to just demand more resources to get the job done. Back in the early days you had to use what you had the best you could.
That’s why a lot of games these days seem lacking in my opinion, not enough imagination from the developers.
avantgardebkk said
This is funny. I had the same experience nearly 25 years ago on a IPM PC.
Webmaster for http://WWW.SILVER-THAILAND.COM
Jim Brain said
TO find the format of the disk, Google for “D64 format”, as the D64 image format is a sector representation of the format of a 1541 disk.
The creator no doubt made the IBM PC format first, ensuring that the even tracks were empty, moving them if needed and updating FAT to reflect that.
As noted, 18:0 is BAM (CBM FAT, so the speak), and 18:1 is the dir. While you *can* move dir to start elsewhere, some utilities wrongly assumed it always started on 18:1, so it is best to leave it there.
In all sectors, bytes 0:1 is the next track and sector (T&S). T=0 means last sector, with S=valid bytes in sector, starting from byte 2. Dir entries are 32 bytes. starting at byte2 of the sector. Byte 1:2 of the entry is the starting T&S of the file.
DOS normally tries to fill starting at tracks 17 & 19 (to minimize seek time from dir track). Also, sectors are located with an interleave of 10 (or less, if a fastloader is used). Thus, 17:0 would be first, then 17:10, etc.
To create this:
Given an MFM disk side with even tracks devoid of data, I would have written a small ML routine that ran in the 1541 and used the format_a_track routines from the format command to format each even track and create a good BAM and dir. You could probably do this from BASIC as well.
Go into a BAM editor and mark all odd sectors as used. Since each track takes 4 bytes, it would be easy to mark them as completely used.
Save file to disk. Since the BAM shows all odd sectors as full, DOS would skip over them.
Roshan Online » Blog Archive » links for 2008-09-29 said
[…] The diskette that blew Trixter’s mind « Oldskooler Ramblings (tags: Disk Diskette PC Commodore C64 Mixed Format Tracks Interleave) […]
Joe Testagrossa said
This is very cool. I haven’t thought about this in years. Brings back memories. thanks to all
snuf said
Brings back the memories. I recall after removing copy protection from one game C64 game in the 80s I wished to put a custom “cracked by” image at the start. The spare data in track 18 was actually being used by game code. To get around this I formatted out an extra track (36 if I recall correctly) and had the BAM jump up there for the file location to my loader image. The loader image itself was stored on the rest of the “extra” track.
Blinkenlichten Blog » Blog Archive » Funny and Cool: The Diskette That Blew Trixter’s Mind said
[…] https://trixter.wordpress.com/2008/09/28/the-diskette-that-blew-trixters-mind/ addthis_url = ‘http%3A%2F%2Fblinkenlichten.org%2Fblog%2F2008%2F09%2F30%2Ffunny-and-cool-disk%2F’; addthis_title = ‘Funny+and+Cool%3A+The+Diskette+That+Blew+Trixter%26%238217%3Bs+Mind’; addthis_pub = ”; […]
Porphyre said
There was a Mastertronic game called “Shogun” which also had the same property; it was readable on both IBM (8088, perhaps later) and C=64.
nexien said
Among others, the TEI and IMSAI disk controllers (which were all TTL) allowed control to the bit level on recordings. In fact, to format a floppy in a TEI, we created the entire bit layout for each track in memory and then streamed it to the disk directly. I recall writing an 8″ floppy with a different (custom) format on every track on an old IMSAI VDP-80. The customer wanted security, and this provided a practically unbreakable secure system for the client.
Nexien
Dave said
Luxury! When I were a lad we had to bang rocks together to get ones and zeroes, AND WE ENJOYED IT!
rithban said
I don’t want to go back to computing in that era, but the constraints that hardware put on us back then produced an endless stream of clever hacks.
Cool. Very cool.
Ibod Catooga said
Whoa whoa who hold it now. I just pooped my pants. You have no idea how hard, but I can show you it.
electrogeist said
@Trixter, RE 4 voices out of an Apple ][ — Even more amazing (I think) is when Compute! magazine published a sound digitization program for the Apple ][. It took forever to key in all the code, and get it right, and without an Apple of my own I had to do it at school or a library or something… It did kinda sound like crap but considering all recording/playback was done on a stock system it was impressive. No not a gs either.
I had a Tandy 1000 when I was little, back when Tandy actually put some innovation into their pc compatibles, probably one of the best 8088/8086 machines. Still worked up until dropping it in the dumpster…which I regret but couldn’t take it with me. I remember games with flippy disks, pc on one side and c64 on the other, but not both on the same side. This caught my eye and it has been fun reading all the comments here!
Poking around the site I saw some references to chicago, if you’re still in the area I have a c64 and 1541 that I’d be happy to let you borrow. In a box here somewhere…
The Age of Cleverness « さまざまの言葉… random items said
[…] The Age of Cleverness Filed under: goofy — rithban @ 7:07 am Tags: hacks Hardware constraints forced a lot of clever things to happen in the earlier days of computing. Trixter wrote about a disk hacked for both DOS and C=64 use. […]
Naughty Nimitz said
Jason, those games are actually mastered from a hybrid disc which you could easily make with a program like Toast on Mac.
You take an Windows-folder and appoint it as the ISO.part (jolliet compliant and all) , then you select the Mac-folder which becomes the HFS side of the CD.
The fun part (as a multimedia programmer) was to have all the shared data (movies, sounds, MM-director files,…) on the Mac-part but available in the Windows-part by using ‘aliases’.
Paul Shirley said
Trixter: I didn’t say it’s not clever, just easier to implement than many posters think, especially if you read the relevant manuals ;)
Hard(ish) is incompatible sector formats on a single track… unless you cheat and use an Amiga. Even harder is finding any halfway credible reason to do it!
While I never played with C64 disks I did get the tape loader running at 1541 speeds (or should that be slows), with the screen enabled, pretty easy, pretty reliable, pretty astonishing CBM messed up so badly it needed doing! I really miss machines so hackable.
Troy said
JUST TO GIVE EVERYONE AN IDEA HOW SLOW THE 1541 WAS:
Back in the day I played an Activision game called Mindshadow. It was a text-based game like “Zork” but with graphics to illustrate the scenes. Loading the game took about 5 minutes. Then you flipped the disk, and it took another 4 minutes!!! Zzzz. And once inside the game, loading a new screen of illustrations took 30 seconds (bit like web-surfing using a 56k modem). —– —–
That was one of the early 1983 or 84 games. Fortunately for us gamers, later software used fast-load routines to reduce times to about the same pace as a Nintendo Gamecube or PS2 (10-20 seconds).
John Keels said
This is fascinating. Some brilliant person figured out how to make this work. I have owned DOS PC’s and also still have a C64 (interest in vintage computing hardware). Anyway, I can easily see how this is possible since with the correct information in the FAT Table on the DOS side which is at track 0 and with the BAM (Block Allocation Map) at Track 18 telling the C64 where stuff is it is indeed feasible. Still, I cannot imagine how long it took to make the original disk in this way. I do know that the C64 Disk drives were programmable and like any disk you could have it read or write indvidual sectors if necessary. C64 operating system did not require a boot sector because the boot code was in ROM and to execute a program you would type LOAD “”,8,1 and then it would look for that file in the BAM which would then tell the disk drive where the file was and then load it into RAM in the computer. Commodore Disk drives (and their clones) were intelligent drives that did not require direct control from the computer. BASIC and some basic IO routines were contained in the ROM on the computer but then the portion of the operating system that controls the disk drive and reads and writes sectors was contained in a ROM in the disk drive. In fact, the disk drive itself had its own RAM and Microprocessor. It was even possible to load small programs into the disk drive and do different things that were not part of the original ROM code and in fact was how may disk crackers and other fastload routines for the C64 worked. It is all very interesting indeed.
John Keels said
OH, someone was talking about how slow the commodore disk drives were. Unfortunately, that was very true. However, there were very transparent and workable schemes that vastly improved the speed of the disk drives. I still have the famous Epyx fastload cartridge which makes a huge difference in how quickly programs load. As mentioned many programs later had their own (even better) fastload routines that really seemed to make things load just about as fast or faster sometimes than the C64’s contemporaries such as the Apple IIe. The Epyx cartridge is nearly always transparent and even the programs that didn’t work correctly with it (which were not too many) usually were programs that had their own fastloaders to begin with.
John Keels said
The C64 was very popular. Unfortunately, sometimes it did not receive the proper respect from the apple and IBM fanboys. It really was a pretty powerful 8 bit system. Its graphic and sound capabilities in particular pretty much walked over the Apple IIe at the time. Its downside was limited expansion (only through cartridges and user port) and the fact that the disk drives were notoriously slow (though again easily fixable).
John Keels said
Another deficiency that I WILl give credit for is that the built in version of basic for the C64 was not that great. This one thing that made Apple much easier and better for a lot of users. Apple’s basic pretty much made it easy to take advantage of the machine’s capabilities where as the commodore basic required tons of obscure peek and poke statements to even access advanced hardware features such as sprites, sound, etc.
Steve Sexton said
A little bit to add about how C-64 drives boot. Some of this recaps what others have said, for completeness.
1. Yes the directory is track 18, with BAM at 18,0 and directory nodes at 18,1 18,4 18,7, etc. The directory node binary format was actually compatible with the on-disk format of a BASIC program, so to DIR the disk you would LOAD “0:$”,8 and then LIST it. BAM was just a bitmap showing what was allocated and what wasn’t, and could at best be considered “advisory” – it was consulted when allocating new blocks for a file and ignored pretty much everywhere else. So the mixed format disk wouldn’t even have to mark the FAT blocks as in use.
2. Bytes 2,3 of the binary PRG format were the desired load address of the program (Bytes 0,1 of each sector were a link to the next sector in the file). For BASIC this was 01 08 (little endian).
3. 1541 didn’t autoboot. You had to manually enter a LOAD command. Usually this was LOAD “0:*”,8 followed by RUN if it was a BASIC program, or LOAD “0:*”,8,1 if it wasn’t. The * was the standard Ultrix-like wildcard for “any file”, the “0:” specified the first drive bay (some Commodore drive units had two drives in them) and 8 was the typical serial bus unit number for the drive (with 9-11 for the 2nd-4th drive, if you had them). The 1 (any odd number, actually) tells the Kernel to load to the address specified in the PRG; an even number (0, or leaving it off) loads it to wherever BASIC is currently pointing to (usually but not always 2049).
4. For a machine code program, one way to autoload was to make the bytes of your program at 2049-2060 map to the BASIC tokens for SYS2061. Usually this would be at the start of your program, since the screen buffer was at 1024 so you couldn’t really put code there. These you would LOAD “0:*”,8 and then RUN, just like BASIC. Unless of course someone moved the start of BASIC text on you, then it wouldn’t work. Interestingly, in the C-128, the SHIFT-RUN/STOP was changed to generate LOAD “0:*”,8 followed by RUN, vs. C-64 it was just LOAD and RUN (handy for loading from tape, but not much else).
5. Another way to autoload, was to overwrite some of the BASIC interpreters variables down in the 600’s. Among other things, BASIC kept a jump vector to its main loop down there (I forget exactly where). This was intended to be used to customize/extend BASIC itself, but it was also handy for for auto-loading: put a different address into that vector – say, something that points to your main entry point – and when the LOAD statement returns, BASIC will JMP into your code. This isn’t to say that there probably weren’t *some* programs that worked by overwriting the stack (which was at 0x0100-0x1FF), just that the patching BASIC’s jump vector was the method I saw (and used) most often.
shodhansaher said
You’re a geek! LOSER!
An a-ha moment in ancient history… « The Whiz’s Crucible said
[…] was reading about the diskette that blew Trickster’s mind and really enjoyed the blog. I have forgotten much of what U have learned in school but I was still […]
mdpb said
The good old times. These were the things a developer (now called a hacker as things were never 100% reproducible) would do to make things ship. Diskettes were incredible expensive.
I recall how a developer requested me to shave off one half filled diskette from a bundle, saves a ton of $$$.
To these days I am amazed how inefficient recent developers have become with DVDs and CDs. Thats probably also what probably killed the compression or intelligent (ie self rendering) technologies. Space in abundance.
To put a green spin on it, how “green” are cds and dvds? Why not be more hacky with those? “Download only” is really not more green concerning the CDs, customers will still burn a backup.
My suspicion is that the entire diskette image was build on a PC. Very likely using the already described anti copy protection by marking many sectors as bad. Then someone used a self-written tool (manual sounds too long) to use the bad marked sectors for the Commodore. At least thats how I would attack this specific issue.
pcanella said
really cool how that works, very good find! Me and my brother have a collection of old games on diskettes, but nothing close to this one, makes me want to dig them up again….
http://theweeklytech.com
AyeRoxor said
Awesome! Thanks for this flashback!
Warez4Life said
Obviously, there are a slew of people who already know about this. They’re hanging out in 200 baud at (212)625-1555.
Doug Renner said
Commodore DOS is stored in ROM. It does not reside on the floppy. The drive has its own 1 MHz 6502.
(Coauthor of Copy-Q, Sprint Print, Q-Term, The Communicator and others.)
Michau said
Being a C64 hacker myself, I have once written a program to read and write IBM PC 360 kB disks in the 1571 floppy drive on C64. Wasn’t that hard actually, because the 1571 had simple commands to read, write and format MFM records. So such disks could be easily duplicated in the 1571 (which could write both MFM and GCR tracks).
rasdollars said
Thanks for reminiscence and a really fun geekothrobbing :p
kay said
I’m a freshman majoring in computer science because I thought Im interested in programming etc. But then every once in a while I experience this horrid dread of being a middle aged adult with an avid interest in some outdated technology, living out her days with a feverish obsession in some antiquated format of hardware/software. This feeling is strong enough to make me want to change and be a lawyer or doctor. I don’t know why working with outdated technology scares me so much, it doesn’t sound any worse than button-collecting or knitting…. but since confiding here anonymously has given me some reprieve, thank you for your article.
game writer guy said
BEAGLE BROTHERS!
Holy shit, I haven’t seen that name in about 2 decades.
Ditto re the geekothrobbing, whatever that is!
El disquete que desconsertó a Trixter said
[…] sorpresas después de 25 años, a pesar de ser uno de los 20 expertos en Oldwarez”.Vía| Oldskooler Ramblings (blog de Trixter)Imagen| […]
Alex said
We used to do that all the time with the Apple IIe. No disk space and out of floppies? No problem. Grab the hole punch – hit it about 20% of the way down, flip it and you’ve got another disk. That was before floppy drives started writing on both sides of the disk (1982 or so).
anythingwritten said
Not any sort of PC software expert, but that sounds like an interesting problem that some guy just innovated a whole new way to beat. Too bad – at least we think it too bad – we don’t know who he is.
Maybe contact the game publisher for credits on the game? (Maybe the guy made some more stuff – or is famous – that you’ll think is neat.
Mathew Edlund said
duh.. ya!
As a historian I would have thought this would be a no brainer. Used to do it ALL the time. Take a single sided 5 1/4 floppy and a hole punch, punch the other side of the floppy (you will see a right protect gap on the right side of the floppy, make the same hole on the left) and you now have a two sided floppy. Both sides can be formatted differently.
sheesh, I was 12 when I learned that.
savavoom said
I was about 8 when I first bought one of these floppy disk, tape player game thingys! I think it was a C64 like you mention in your post. Good times!
What I really want someone to tell me though is how do you get a post to become a Hawt Post?!? I can’t find a good explanation anywhere!
I think my blog – http://www.ecohho.wordpress.com is pretty good but my posts never get the attention I think they deserve!
So come on – someone shed the light on how to get that “Hawt Post” that seems so damned elusive!
OldProgGuy said
It’s been a long time since doing it(30 yrs) so my memory is a bit cloudy but, the 1541 Drive was easily Re-programmed to read & write floppies in just about any way you liked. It did not take much effort to build a program, send it to the drive, and execute it. The only restriction was the track 18 BAM properly pointing to the auto-exe file that held the code to be loaded to the drive. With that it would not be too difficult to interleave data for 2 different systems. In the case of Faery Tale Adventure for C-64 we created our own disk format. We did not need to interleave data for another system but it would not have been too difficult to incorporate such a need, especially for a system that you don’t have to worry about reserved allocation conflicts.. When it came to duplication we were asked to provide to the duplicators the 1541 drive code we developed to create the different format and write the executable disk.
Trixter said
@Mathew Edlund: The diskette was not 1-side IBM 1-side C64, it was IBM on both sides and C64 on half of the first side. That’s what makes it interesting. If it were a simple “flippy” disk, I wouldn’t have blogged about it.
@savavoom: You need to meet a comment threshold and # of pageviews target to become a “hawt post”.
@all: I sure would like to know how an Apple could pull off 4-voice music… if anyone has any ideas or pointers, please steer me…
Ben said
I read this whole article and I’m ashamed to say, the most impressive part is that you made a reference to “The Incredibly Strange Creatures Who Stopped Living and Became Mixed-Up Zombies” (For those of you who don’t know: http://en.wikipedia.org/wiki/The_Incredibly_Strange_Creatures_Who_Stopped_Living_and_Became_Mixed-Up_Zombies )
I DIDN’T KNOW ANYONE ELSE HAD SEEN THAT MOVIE!!!
spanky said
Wow….and I thought I was a geek. Nerdpower.
Top Posts « WordPress.com said
[…] The diskette that blew Trixter’s mind As an IBM PC historian, one aspect of my hobby is archiving gaming software. (You can take that statement to mean […] […]
Alf said
Great thread, was worth all the time spend reading it. Felt like starting hacking the C=64 again! Thanks!
PabloG » Blog Archive » links for 2008-09-30 said
[…] The diskette that blew Trixter’s mind « Oldskooler Ramblings (tags: histoire informatique archives jeux software hardware) […]
A Game Programming Mystery: 2 Formats on a 1-Sided Floppy | Universe's Tech Blog said
[…] in label-side up. I thought that had to be a typo. What I discovered has officially blown my mind. read more | digg story This post has been read 1 […]
qkumba said
Trixter, getting four voices from the Apple II was a matter of toggling the speaker _very_ quickly. It took almost 100% CPU time, though, so not much else would be happening (but check out the Tetris II loader page – music, bars, and smooth-scrolling text, all at the same time). It’s not so dissimilar to the PC speaker. Digitised sound was also achieved – Sea Dragon and Ghostbusters have sampled speech.
Air level critical! :-)
Harpo said
The Author must love MST3K.
“The Incredibly Strange FAT of Mental Blocks That Stopped Living And Became Mixed-Up Formats”
is a spoof of one of the movie titles seen on mystery science theater 3000
“The Incredibly Strange Creatures Who Stopped Living and Became Mixed-Up Zombies”
although i’m the bigger nerd for pointing this out.
Trixter said
Give that man a cupie doll: https://trixter.wordpress.com/2008/09/20/ill-save-you-the-trouble/
Morcaradhras said
the gay old times, the golden age of engineering!! i’ld love to play the game =O
Buzz Az said
If only the games of the C=64 could come alive now.. I have a great collection of diskettes that’s awaiting my getting a Mac so that I can get the best emulator. Trixter, would you like two boxes of games including ACE-2 and a bunch of great titles from mid-80’s Europe? OR anyone else? I’d just like to get this treasure in the hands of someone who could do some good with it.
Markus Diersbock said
I remember in the “old days” with 51/4″ one-sided floppies, we would take a hole puncher and make a half-circle cut on one side of the disk, opposite of the write-protect notch.
Then you could flip the disk over and use both sides.
Double-sided disks at the time were expensive, so you got a double-sided disk out of a single-sided with this hack.
Erik Niklas said
A little background on the slow 1541 drive: according to Brian Bagnall’s wonderful book, “On the Edge: The Spectacular Rise and Fall of Commodore,” the 1541 drive was designed with high speed serial lines that would have made it 20-30 times faster. Unfortunately, another team “optimized” the design before production and, not understanding why those extra lines were there, removed them. By the time the original designer found out, the PCBs were already in production.
Trixter said
@Buzz: I appreciate the offer but I’m not nearly as well-versed in C64 as I am in other areas. Hopefully one of the other people who commented here, or on slashdot or digg or reddit (who also covered my post), will take you up on your offer.
@qkumba: I checked it out — it’s nice, but it’s only 2 voices, not 4 :-)
SubSprawlBlog » Nerdly Interestingness. Or Interesting Nerdliness. said
[…] I don’t know why or how, but I managed to make it to about 35 comments down before I lost interest/gave up on needing to understand any further: Check it. […]
VF said
It was a remarkably fortunate (semi-)coincidence for the creator of this hybrid disk that the physical GCR track layout corresponds exactly to the layout of the first 35 tracks of an MFM “double density” disk, though the sector layout and bit format in individual tracks is different. In fact, if this hybrid disk is properly readable on a C64 drive without using its own custom routines, I guess tracks 36-40 are all-PC?
There are a lot of these old-time hacks that we can look at in retrospect and say “well sure, that’s perfectly doable” but I can’t agree with anyone who says this was no big deal. It was a feat of engineering design to come up with the idea in the first place. (Figuring out the law of gravity was the same kind of “no big deal” – look, gravity is all around us.)
On a side note, someone up there mentioned the C64 processor and video chip taking alternate cycles to access memory – but these would be memory cycles, not CPU cycles, and back there the memory cycles were shorter – you could say (speaking in CPU cycle terms) that the CPU got every other “half-cycle” to access the memory, and there wasn’t any waiting involved. (At least from this source. The video chip would now and then need extra cycles to pick up character codes, hi-res colours or sprite bitmaps, and then it would take over both memory access half-cycles.)
Chat Marchet News Digest » A Game Programming Mystery: 2 Formats on a 1-Sided Floppy said
[…] Get the whole story… This entry was posted on Wednesday, October 1st, 2008 at 6:43 am and is filed under le Chat Marchet. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. […]
Retro dual-mode floppy disk discovered in a swap meet bin | Sugar Mob said
[…] The diskette that blew Trixter’s mind [Trixter.Wordpress.com] (Thanks, Brett!) […]
Carlos Martins said
Really cool stuff.
I remember using (years later) the Amiga and it’s insane floppy disk copiers to do weird stuff as well.
And there was a PC program (VGAcopy?) that also allowed formatting disks with weird higher capacities.
Nowadays, we talk Gigabytes like it was nothing… :)
koitsu said
Super cool. I’d like to know how Copy II Plus handles this disk! :-)
Frumpus said
is there a pulitzer for nerdiest article?
Trixter said
@VF: I completely agree — anyone can say “big deal, here’s how you do it” but it is an entirely different thing to come up with it in the first place.
@koitsu: copyiipc handles it okay, actually, but it takes a VERY long time on the GCR tracks (since it can’t make heads or tails of the data).
qkumba said
Right, two voices on the Apple, not four. It was Electric Duet not Electric Quartet.
I can’t count.
trs said
The original Mac could barely mix four voices, so there’s no way the Apple II could’ve.
http://folklore.org/StoryView.py?project=Macintosh&story=Sound_By_Monday.txt&sortOrder=Sort%20by%20Date&detail=medium
“Then he [Steve Jobs] looked at me. “You’ve had long enough to get the sound going. I want to hear great sound on Monday, or else.” Then he stormed off, leaving Burrell and me to figure out what to do…
Burrell’s new design was very clever. The Macintosh was already continuously fetching data from memory to drive the video display, interleaving memory bandwidth between the display and processor in a similar fashion to the Apple II. But every 44 microseconds, there was a “horizontal blanking interval” where no video data was needed, so Burrell used that time to fetch data for the sound. That gave us a sample rate of 22kHz, which would allow us to do frequencies up to 11kHz, which isn’t too bad.
The sound driver worked at the interrupt level, so sound generation could proceed in the background while the processor performed some other task. It arranged to receive control at the beginning of the vertical blanking interval, which occured every 16 milliseconds. It needed to generate all the sound data for the next 16 milliseconds, which worked out to 44 microseconds for every successive sample. If our calculation took 22 microseconds per sample, for example, the sound generation would be soaking up half of the available processor cycles.
It only took a few hours to write a driver with a simple sound generation loop. It could do two voices fine, but it didn’t run nearly fast enough to do four – it took too long to generate each sample, which caused audible glitches as well as making everything else run like molasses. Burrell took a look at my code, and saw that I was using some memory locations during the sound calculation.
“Memory? Are you kidding? You can’t hit main memory, you’ll never make it that way. You’ve got to do everything in the registers!”
“Registers” are special locations that are part of the processor chip itself, where the action really happens. They could be accessed four times faster than the bulk of memory, which was in separate memory chips. The problem was that there were only 16 registers. For each voice of sound, we needed a frequency, a waveform pointer, a position within the waveform, and an amplitude, plus some housekeeping data. There weren’t enough registers to do four voices.
I was able to rewrite the routine without touching main memory, but I was only able to get three voices since I ran out of registers. But that wasn’t good enough for Burrell. By now it was late on Saturday evening, and I wanted to go home, but he felt that we had to get the fourth voice done before “head hits pillow” as he liked to say, or we’ll never get the fourth voice.
Finally, I was able to leverage the fact that the registers were 32 bits long and we only were doing 16 bit calculations in some of them, to use some of the them to hold two different values. Each sample took about 22 microseconds to calculate, so we were using roughly half of the CPU to get the four voices at the maximum sample rate. The basic four voice capability was implemented, but we still needed an impressive demo to show it off. We went home to sleep at around midnight, after agreeing to come back around noon to work on the demo.
The next day, we decided to write a demo called “SoundLab” that would let the user control the pitch and waveform of the four independent voices. You could specify or edit a waveform by drawing it with the mouse, and control the frequency of each voice with a scrollbar. The results didn’t sound like music, because there was no envelope shaping, but you could make very eerie sounding noises, which we deemed impressive enough. And it was fun to be able to hook an oscilloscope up to the sound output, and then draw a waveform with the mouse and see it on the scope. “
trs said
I found a newsgroup posting by Paul Lutus, the author of Electric Duet. Even two voice playback seems to be an amazing feat for the Apple II. http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.apple2.programmer/2007-03/msg00063.html
Ivan said
I couldn’t afford a 1541, and had to hack the cassette player. I seem to remember creating a FAT/dir in the centre of the tape and reading/writing to alternate blocks on either side of the centre.
To have text and graphics on the same screen, you had to switch modes at the top, middle, and bottom of the screen by counting scan lines. Used the technique to write a program similar to the Soundlab demo.
2400 baud – such luxury! 300/75 here in S.A. up to 1986 or so, as Telkom decreed that ‘copper lines will never support high-speed data transfer’. Funny, they’re still using the same lines . .
Weekly linkdump #145 - max - блог разработчиков said
[…] истории хакерства, от oldschool до наших дней, The diskette that blew Trixter’s mind « Oldskooler Ramblings, LPC: Booting Linux in five seconds […]
Jerry Kurtz said
@Nate – I have the original disk of Mental Blocks and can send it to Pete. Heck, I may have already made an image of it?
@Jens – Your Catweasel is a cool device but is absolutely no good for anything that has even the slightest level of copy protection. In fact, the vesion I had choked on the basic CBM DOS errors, meaning it didn’t fully support the error information block in the .D64 format. Also, not just any 5.25 drive worked for C64 stuff – it took me about 10 drives until I found one that would actually work. Maybe the drivers are better now, or the support for the PC world is more complete?
@Trixter – Not too sure you should waste your time on the Catweasel – unless of course you just have a bunch of data disks that need backed up.
As for mass duplication — could it have been a two phased process? the first pass put down one format and the 2nd pass put down another? Just a guess as I know nothing about mass-producing disks.
Jerry Kurtz said
@Buzz – If you have original C64 disks that you would like to donate for preservation, see http://www.c64preservation.com...
Jerry Kurtz said
@Doug Renner
I’ve been trying to find a copier I used back in the day — Copy-Q, but the one that I keep turning up isn’t it.
It was a black screen that had a grid-like screen that as it progressed, would fill up the screen from left to right. I think the name of the company may have been spelled incorrectly, like “Copy-Q Comminucations” instead of “Copy-Q Communications”
Would like to get it if I can…
Doug Renner said
Versions 1, 2 and 3 can be downloaded from here:
https://www.c64copyprotection.com/copy-q-1984/
Versions 1 and 2 can (uselessly) be executed in an online emulator here, but also downloaded:
https://archive.org/details/softwarelibrary_c64_applications?and%5B%5D=copy-q
Looks like someone stripped out our Q R&D credit screen and put their own pirate handles in there. But that is our software, and I’m happy to see it still circulating around. For actual usage I’d recommend either versions 1 or 3. :-)
Doug Renner
links for 2008-10-03 | Nathan and his Open Ideals said
[…] The diskette that blew Trixter’s mind « Oldskooler Ramblings A nostalgic C64 mystery here: The manual for Mental Blocks claims that, for both C64 and IBM, you put the diskette in label-side up. I thought that had to be a typo, since every single mixed C64/IBM or Apple/IBM diskette I have ever seen is a “flippy” disk where one side is IBM and the other side is C64 or Apple — until I looked at the FAT12 for the disk and saw that tons of sectors in an interleaved pattern were marked as BAD — very strange usage. (tags: retrocomputing retro technology c64) Share and Enjoy: […]
Falling through a window into another world « Joe Wrigley Blog said
[…] https://trixter.wordpress.com/2008/09/28/the-diskette-that-blew-trixters-mind/ […]
early October links « …the importance of being, Andy. said
[…] The diskette that blew Trixter’s mind. Good old fashioned geekery. Not for the faint of geek. […]
falk said
Reminds me of Monty Python’s “Matching Tie and Handkerchief” album. One side had two interlaced grooves.
You got one at random, depending on how the needle happened to land.
suresh said
Amazingly cool…Excellent stuff
This guy definitely deserves an award in computer science
gpz said
“Your Catweasel is a cool device but is absolutely no good for anything that has even the slightest level of copy protection. In fact, the vesion I had choked on the basic CBM DOS errors, meaning it didn’t fully support the error information block in the .D64 format. Also, not just any 5.25 drive worked for C64 stuff – it took me about 10 drives until I found one that would actually work. Maybe the drivers are better now, or the support for the PC world is more complete?”
you should look for alternative software atleast once before making such a claim – both the “arjuna” tool for windows and the “cwtool” for linux can create G64 images just fine (and probably better than mnib can). And even the imagetool supports d64 with errorinfo since the last update :)
Rocco said
Two-voice on the //e left enough CPU to drive a game. See “Microwave”, one of my favorites at the time.
Trixter said
I just played it — while simultaneous music during gameplay was quite an achievement, it was only single-voice.
zpinzane said
Wow.
A lot to say in feedback here. What first struck me about this post was your “sleuthing skills” while attacking this problem. Although the technology itself is over my head, I’m pretty sure I can understand the base enjoyment you got out of working through this little mystery. Not to mention the thrill of finding a rare, old collectible for a song. :)
That being said, I’m sure this deluge of front page feedback you got had to be like Christmas morning for you! I’m glad you were able to get so many constructive responses, and so many readers.
Kudos to you Mon Trixter!
See you at B^3.
(^_^)
The diskette that blew Trixter’s mind « Williamo’s Blog. said
[…] 8, 2008 This is pretty obscure, and super old sk00l, but I am completely fascinated. This guy found a disk that was readable by both C64 and IBM PC – quite a rare find […]
usotsuki said
I actually created several disks of crunched Apple ][ games, and put them on disks with a nonstandard DOS for speed.
Since it didn’t have a BRUN command, but it had a RUN command (& RUN), I did the stub trick, which was easy since the cruncher assumed C64 files, and the load address was the same, and the BASIC similar. I changed the header, replaced token for SYS with the token for CALL, and boom, Bob’s your uncle.
microcontroller said
I have searched about the word “stepper motor” and you blog appeared to me.
where can I read about stepper motor in details in your blog?!
Tagz | "The diskette that blew Trixter’s mind « Oldskooler Ramblings" | Comments said
[…] [upmod] [downmod] The diskette that blew Trixter’s mind « Oldskooler Ramblings (trixter.wordpress.com) 1 points posted 7 months, 2 weeks ago by jeethu tags vintage software […]
kometbomb said
Sorry for the necropost but this was an interesting read. There were some double boot budget releases of older games that worked on the Atari ST and Amiga as well, at least in theory. I think some games written this in mind even shared some code since both machines use 68000. They most likely didn’t save any money in the end, thanks to having to send disgruntled customers a pure Atari or Amiga copy of the game because the loader wasn’t very reliable.
It’s funny how the exact same thing is still happening, people use similar tactics to overcome differences in web browsers without having to have multiple versions of the same files (namely by utilizing how browsers tend to handle erroneous CSS definitions differently, some leave the previous definition in effect and some do not).
phil said
Reminds me of a reference to another brain twister of a disk format mentioned in Jason Scott’s “The BBS Documentary”. Apparently this disk for one Apple game didn’t have tracks – it had a continuous spiral created by quarter-stepping the heads as the disk spun. You can just imagine the copy protection designers on that one saying, “Go on, nibble this! I dare ya!”
Trixter said
And yet, amazingly, it could be cracked: http://www.fadden.com/techmisc/computist.htm
Scali said
Yea, as someone mentioned, Commodore put the BAM (their equivalent of the ‘FAT”) slap-bang in the middle of the disk. In a way it’s strange, since it’s such an obvious optimization: you never have to seek more than half the number of tracks to go from the BAM/FAT to the data or vice-versa.
Amiga uses a similar approach, where the directory is stored at track 40.
So it’s a nice and creative exploit: since the two systems use different tracks to store their tables, all you need to do is to cleverly allocate the sectors so that they don’t step on eachother’s toes.
The C64 does not have a method to mark bad sectors though, so I wonder how they side-stepped that (if they did at all). As long as you only read the disk, you’ll be fine. But I wouldn’t try writing to the disk with the C64’s built-in disk routines, as it’d probably destroy the PC data.
Not sure if the game even writes to the disk at all on the C64, but if it does, they probably built in their own allocation scheme to avoid overwriting any PC data.
links | Mark Hamzy's weblog said
[…] that contains both IBM and C64 on the same side link […]
Bookmarks for July 24th | Chris's Digital Detritus said
[…] The diskette that blew Trixter’s mind « Oldskooler Ramblings – […]
Jorge Massoud said
Not wanting to limit the game to either CGA or EGA, someone at Artech (the developer) built the format of this diskette BY HAND so that DOS would not step on the C64 tracks, and somehow the C64 would also read/boot the disk……
FileFormat.Info · The Digital Rosetta Stone | brandybradham said
[…] The diskette that blew Trixter’s mind | Oldskooler Ramblings […]
door behind said
magnetic Strip
The diskette that blew Trixter