Great video, I love the tech details. As a side note, the magazine "The One" also had dual-format disks on several of its issue from 1988 up to 1991. I had several of those.
@@RobSmithDev No, I don't, sorry. I am pretty sure it's the same format, though. And I binned all my cover disks some years back because I thought I could always just download them from the Internet. Duh. :)
Zero magazine did as well. From memory they were a bit fickle on the Amiga - usually they'd boot up OK, occasionally not. I seem to recall they were also by Rob Northern, but I'd have to check
I was a bit confused until the animation at 9'30"... of course the disk is spinning and passing data in a serial manner and the machine is "looking out" for the sequence it is expecting. Very good explanation.
Very cool! I never saw these disks, but my second STFM came with a bunch of crackdisks whose intros frequently mentioned Rob Northen as a sort of nemesis for pirates. Makes sense that he'd have a hand in this ingenuity.
Interesting Video, always wondered how dual format disks worked, quite impressive how it was pulled off, I bet this could never have been done if the file systems were similar in design, But thanks to them being slightly different, it enabled dual format to be supported from the 1 disk
Yeah this was probably a considerable cost saver vs mounting an SS (or trick-formatted dual compatible disk for the ST and a DS one for the Amiga. Any time the later ST Format (or other mags) had dual coverdisks was part of some kind of special issue or giveaway promotion (eg having a full game from a couple years back)
Interesting stuff, I had a number of these dual-format disks back in the day and had come to the obvious conclusion that the ST data was on the side single-sided STs could read but didn't think much beyond that.
Educated guess, DOS PCs uses FAT too so they should be able to read such a "single-sided" disk just fine. And as the PC disk controller can't read Amiga formatted disk all Amiga stuff just appears as noise to it. Just don't expect any special tools like VGA Copy to play nice with them. Sidenote, a PC can read a 1581 disk just fine and if you have a file system driver you can even manipulate files on them. Tried that under Linux and it worked just fine, there is a FUSE driver called cbmfs that lets you just mount them. Or dd them and open them in c1541 from the VICE package.
I could see it being set up similar to the ST Format SS-compatible DS disks. You just have a couple folders in the root, one "PC" and one "ST", with the respective files in. The processor architecture is different enough - and each OS smart enough to use magic numbers in the executable headers to prevent accidental execution of data / foreign programs with unpredictable effects - that it wouldn't do any harm to let users on the two platforms see each other's files if they opened the other folder. Also as you could assume that all 3.5" PC drives to be double sided (given that they didn't start shifting to the format until it had already been proven in other machines, and didn't even stick with double-density for very long), it it could share some space with the Amiga on side B as well. Allocate maybe 250KB or so to each platform, with the PC stuff even working in regular DS mode so it's got the same sectors on each side and the FAT works more logically. (As shown with ST Format et al, single-sided drives can read double-sided disks just fine and don't care about whether the FAT says they're SS or DS ... only the DS machines pay attention to that, to know how to read the two formats. It's just that with a normal format, files get striped between the sides, track by track, so the machine starts reading the data then hits a snag after the first few KB... The Rob Northen format used by STF laying data down sequentially instead, track to track on side A, then starting over on side B, with the "side B" folder effectively being a second root directory that only double siders could open. Therefore you can present the disk to the ST and PC as being double sided, but with the ST data only existing on the first two thirds or so of Side A, Amiga on the first two thirds of side B, and the PC data occupying both sides of the last third.) You'd really need a good reason to do that though, as that's not very much space overall, and it'd just make more sense to use separate disks for each platform (or, say, have a split ST-Amiga or PC-Amiga one where the Amiga got about 2/3rds of the space, and a second ST-PC disk that's literally just MSDOS format but maybe with the single-sided-compatibility trickery, and the split being according to whatever was on the other disk) That does bid a question though ... STs with TOS versions before 1.04 did something odd with their built-in formatter. Even though the TOS and MSDOS formats are sufficiently close to the original CP/M standard (that both OSes derive directly from), and the ST can always read PC-formatted floppies, the PC can't handle those formatted in an older ST (unless you use a thirdparty formatter utility). Which turned out to be quite annoying when I wanted to back up old disks from our TOS 1.0 machine to a PC based archive, and had to use an MSDOS go-between disk, and later filesystem-agnostic imaging software with an emulator... I wonder what it is that makes the PC choke on them? Something to do with the 1KB clusters? Different header ID codes with the PC expecting some extra part that the ST doesn't care about and doesn't lay down?
Well, I already knew those disk were using one side for each computer because of the head movement being twice as fast (half the data to read for each track). Thank you for explaining the boot block trick. IIRC, the game "Carrier command" is a dual format disk.
I recall there were dual-format CD-ROMs around, too. The Lost Mind Of Dr Brain came on a disc that had versions of the game for both Windows 3.1 and MacOS, which had rather different file systems for their respective CDs, and where you'd only see the relevant version of the game on each machine. Very useful for me, when the school had a bunch of macs (with one CD-ROM drive for the whole room) and I had a PC at home. Still had to have a separate saved game on a floppy for use at school, though.
That was much simpler. ISO 9660 (the standard file system) places its header at a different location on the disc (32kB from the start) than the Apple partition map (512B from the start) or Apple HFS/HFS+ header (1kB from the start). Only Mac OS will look for an HFS file system or Apple partition map. If it finds either of those, it will ignore the ISO 9660 file system entirely. Conversely, other operating systems don't know about Apple file systems or partition maps, and will only look for the ISO 9660 header. Since all of these are at different locations on the disc, there is no need for overlapping-sector trickery, and since CD-ROMs are read-only, there is no need to protect either file system from being accidentally overwritten by the other one.
@@argvminusone The unused 32kB at the beginning of the ISO 9660 file system is also exploited by Linux distros which put MBR (and possibly GPT) partition tables there in order to make ISO images that can be written directly to a drive, e.g. USB flash drive, to create a bootable live/installation medium.
@@RobSmithDev Great idea maybe could be build in to DiskFlashBack, as a side note rob northern mentioned he used a disk duplicaton machine made by Trace to write his special formats back in the day I think it cost him around £15000 in the 1990's
At 7:09 the third longword, 0x00000370 or 880 in decimal, is the pointer to the root block mentioned at 14:45. And why was the root block in the middle of the disk? It takes less time to seek 40 tracks to either end of the disk than the whole 80 tracks from one end to the other.
No idea why it’s in the middle but seems to be a consistent thing - should have spotted that but I don’t know if it’s used to find the root block. Libraries like ADFlib look for the middle point, without checking this value. Hmmmm
I've always wondered how it was done, I thought maybe it might be something like the ST data on one side and the Amiga data on the other but didn't have a clue how they did it, I certainly didn't think it was so complex 😀 It's got me wondering about the ST Format double sided disks, I seem to recall they were double sided with a "Side 2" folder on the disk for double sided disk drive owners. I guess in that case it was just maybe a pointer in the FAT12 filesystem for anything in the Side 2 folder was on the second side perhaps?
I wonder if it might just have been something as simple as you format the drive as single sided, write all the Side A content, fill it out with dummy files so there's no free clusters, then do a type of quickformat that changes the disk definition to double sided instead (maybe you format DS then quickformat to SS first of all, then change back...). Then you make your Side B folder and put all the Side B content in there, and delete the dummy files. Maybe if the DS FAT is larger than the SS one you'd have to put dummies in the place where the extra parts would have to go, then back it up and use some trickery to rewrite new copies with the Side B area blank, but that wouldn't exactly be a great hill of beans, there were enough recovery tools like KnifeST and the like which could do that kind of work. The alternative is that it somehow changes the sector order so that all the Side A ones come first and then all the Side B ones, instead of the tracks alternating side to side like with a normal format (so if you were to copy everything from that disk to another one, it'd have to run through 0 to 80 (81, 82...) twice, though stepping a little quicker than would be normal for a DS disk, with a clearly different seek pattern on the target drive, with the copy then not being properly SS compatible any more and stepping 0-80 just once at a more normal pace if you also copied *that* ...). That might be a little more work to set up initially, but it may be as simple as changing what the index numbers are on each sector, and after that you just have to make sure to pad the Side A fileset out to 360K before starting to write Side B, and deleting the dummies at the end. (Or, third... you copy the programs onto the master disk using a special program that arranges them on the respective side A / side B tracks for you, as you only need to do that once, and you can prepare the contents for each side on a separate single sided disk to be sure it's going to fit, which is probably the easiest and simplest method of all - don't need any dummy files, don't need to reformat the disk vs a standard 720K (or 800K+ extended... this example disk has 10 sectors per track for the ST after all!) double sided type, etc) Like it's probably nowhere near as complicated as it first looks. You just have to be able to do some minor bit of low-level FAT or sector ID hacking, and any extended formatter can probably do that already.
The "Side 2" feature allows compatibility with both drive types. Normally files would be written sequentially, top surface then bottom per track but these disks would have been built with some sort of custom creation program that keeps files on only one surface. Potentially you could create this manually by writing 2 files at once, offloading sufficient content to one file then the other to keep it on the side you wanted. Use dummy files as filler after a file ends to eat up the remainder of the current track, then delete later - though I doubt it would have been the method used. Another possibility is that the allocation map was just patched after formatting to mark Side 2 as all used - then write the side 1 files and unpatch the Side 2 blocks and reserve the spare Side 1 blocks. Write Side 2 then remove the patched Side 1 mapping.
@@Rybagz Could be interesting to see if you could replicate it using a combination of those two ideas - fill the disk with a whole bunch of files that are just big enough to take up a single sided track each (first one may have to be smaller to account for FAT...), with sequential names because GEM seems to write them in alphanumeric order. Delete all the even numbered ones (assuming you started from file "000"), and that should presumably have the entire of Side B marked as used, whilst leaving Side A free. Just to make sure you could then swap to a single sided drive, to see if the disk was at all readable, then to copy files onto it (it's physically incapable of writing to side B, and if it comes across a writeable sector that's on the wrong side it'll error out). Make sure you have just enough space left to lay down the empty Side B folder (I think it might have to be on A to display in the root, but its metadata content could spill onto B without any issue). Then swap back to the double sided drive to delete all the odd numbered files and write the Side B folder contents. Though of course the actual play, once you'd verified the idea was usable with the single sided drive, would be to erase everything except the Side B folder off of Side A, and keep that disk as a master that could then be repeatedly duplicated using a fast sector-exact filecopy program whenever you needed to spin up a new one. Maybe Rob Northen was sneaky, and did just that... supplied them with said master (perhaps even doing an initial step of deleting all the odd numbered files and replacing them with a single 360K file that filled the entirety of Side B), claiming it was a special format, and the only instructions were to delete the dummy file inside Side B folder after writing everything to A... and claimed it was a "special format". Or set the folder and that dummy file as Hidden and provided a little utility program that would "prepare" each side for use... Doing nothing but a few random seeks before side A was "ready", then repeating that plus unhiding the folder and deleting the dummy file to "prepare" side B ;)
They must've used special hardware to write these disks since you'd need to write flux transitions. Maybe the Amiga could pull it off though since the hardware is very flexible.
Would have been easy to write them, at low level MFM which is what drives care about it’s all within spec. The hard bit would just have been the initial setup, but the Amiga could easily pull that off with the right knowledge
Writing flux transitions is exactly what the Amiga did. As I mentioned in a comment on another video, the floppy interface was a fairly primitive bridge between the floppy drive read/write lines and the DMA engine. Writing tracks which required accurate sector positioning would have been tricky, though, since there was no hardware-level support for synchronisation with the INDEX signal.
The Amiga can detect the INDEX signal, and the PC format does allow quite a large tolerance for the positions of the sectors so the Amiga could easily write these perfectly fine, and does
@@RobSmithDev (This comes from my understanding of the information from the HRM and schematics, so hopefully it's mostly correct!) The INDEX signal is connected to the FLAG pin of one of the CIA chips, so you would have to start the disk DMA from an interrupt handler or a polling routine. That introduces some variability in the timing and may require some tweaking to get right. I know from experience that there was software like CrossDOS that was able to read and write PC floppies. I believe that the PC floppy controller did use index pulses for positioning, so it was evidently possible to get the required accuracy on the Amiga. Again, if someone else knows more, I'm more than happy to be corrected! EDIT: I just noticed that you did say that the PC controller had some tolerance regarding positioning, so there we go...
Huh, I always thought it was something to do with the rumour that the ST's single sided drives had the head on the "wrong" side, because Tramiel got a load cheap that were built wrong, or were actually double sided with one head failed... Guess not, unless the Amiga defaults to reading the boot sector from the opposite side to other systems (Mac, PC etc)? Similar to how the internal mechanisms on the early Megafile hard drives were actually higher capacity than stated, but some fault that meant only half the heads worked... Anyway, the explanation is pretty good but begs a question from me over one point: you said that the bitpatterns used for MFM sector sync can't be laid down using normal data - presumably you have a combination of flux frequencies that would never happen due to how the encoding is designed to limit consecutive runs of 0's/1's and 0101's, but are written deliberately by the controller chip to mark these positions (also what reads and recognises them - the OS never gets to see this raw data, only what processed form the controller provides, which is why you have to use things like the Greaseweazel to record flux transitions). So, how are we writing those patterns within the Amiga sector, if you can't do it with regular data? I expect the repeating pattern seen in the data analysis is just an artefact and doesn't actually mean anything, it's just the best that your software can do to interpret the "illegal" codes into something that seems valid. Maybe you can provoke the controller chip directly to write an index wherever you want it, but that seems unlikely and would need extremely exact timing. Would be better to set up a duplicator to directly alter the flux pattern, like what they probably did with Copylock and so-on? After all the disks are going to have to be copied by a professional operation rather than just with an office machine and ordinary drive anyway. Though, I wonder - maybe there's inherent timing differences in where the two machines start to lay down their data on the disk, versus the index pulses that come from the drive's rotation sensor? Or they / their controllers can be set up to have a different degree of delay. Then you can format the disk as Amiga format at first, with as short a delay as possible, so its own bootsector appears pretty much immediately the chip starts reading and gets as much space as possible to store the setup data which tells it to look at track 40 and ignore the rest of side A. Then you reformat side A as ST format (skipping track 40...), but have a really big delay before anything gets written to track 0 after the index pulse, with the erase and write heads being deenergised so they don't erase the existing content either (and of course the sectors being halved in size so you don't risk overwriting the start of the Amiga data either, despite keeping the same number of them). That then plonks the start point for ST sectors, including the controller-generated index pattern, somewhere in the middle of the second, unused Amiga sector. Possibly if the Amiga controller starts reading a little quicker after the pulse than the ST does, the ST may not even see the Amiga index at all, let alone having to process it and decide it's invalid (IDK if the controller might then just lockout for the rest of the track and wait for the next pulse to retry, after all). And you achieve this without having to do any direct-flux-transition-writing voodoo at all, just sending some adjustment data to the drive controller with a bit of assembly code. (and if that's not doable, you could have a modified ST drive specifically for writing that one track, with the index sensor moved slightly, or with a simple 555 circuit hacked in that delays the pulse by a few hundreths of a second)
Just to clarify, the Amiga for example can easily write any pattern it wants, but normal MFM encoding of data to flux transitions won't produce those special sequences. Theres nothing wrong with them, just data won't generate them. But its all still a normal MFM bit stream. You can find out more about MFM encoding this is much earlier video of mine: ruclips.net/video/OAswAoNLJhs/видео.html These disks could easily have been written from something like the Amiga and dont require any special flux timings at all.
@@RobSmithDev As in the Amiga is able to write whatever MFM patterns it likes, under software control? Interesting... wonder if that's why it had such a piracy problem :D ... maybe even the machine of choice for copying disks of entirely different formats too? I figured the "illegal" vs "legal" patterns were because of the intent behind the "modified" FM, making the encoding more efficient in terms of how much fluff was around the actual data, whilst also making it more robust and less prone to losing track of the self-clocking / not having a significant DC level / etc? Regardless, if they're not produced by any actual "real" data, then presumably they also can't be decoded back to a particular bitpattern either, so either have to be ignored completely or flagged as an error (sign of a bad sector, perhaps, or at least that the read has to be retried), except where they are index codes appearing at a point when they're being actively looked for?
@@RobSmithDev the "how data is encoded on floppies" one? I think I kinda have a grip of it in general, I'm just not familiar with the specifics for the miggy, having (perhaps obviously) been an ST child and then moved to PC. I can grok the workings of a WDC 1771 at some level and have a misty idea of how FM / MFM / RLL work if nothing else :)
yes that video, it goes much lower level into flux transitions and what the drive does, then covers how MFM encoding works (and the sync marks). The Amiga could read or write a bitstream of data (MFM or GCR encoded) - they still had to be at fixed timings, you couldn’t adjust that but the Amigas hardware didn’t do much for you (by default) beyond that. It could be setup to watch for a sequence and trigger interrupts/start DMA etc too. Writing was all done using DMA
It’s true but for some reason I haven’t looked into they don’t work for these disks - I suspect it’s because of the different sector sizes and the driver probably assumed them all to be the same
The tricky part is also that, to actually have the ST sector 0 inside the Amiga sector 1, you need to "break" the MFM encoding, because MFM cannot encode the sync words (for good reason). Moreover, as the Amiga always needs to write whole tracks, attempts on modifying track 0 will certainly break the disk for the ST. If the Amiga had actually checked the MFM encoding while removing the clock bits, it would have refused to decode sector 1. But it didn't care about the clock bits and if the checksum was right, everything was fine. It would also be interesting if the Amiga would read in enough of the track into the MFM buffer if it "accidentally" picked up the 4489 of the ST sector 0 first, so that the end of the buffer would contain a full version of Amiga sector 1 -- otherwise the sector 1 would appear broken (rereading the track would likely fix that). It would also be interesting to know whether these disks worked on all kickstart versions. I believe that later versions (kick 3.0?) would always try to decode a whole track and put up read errors if some of the sectors were corrupt or missing (remember that these disks were missing Amiga sectors 2 - 10 on track 0. About the bitmap blocks on the Amiga side: Better never corrupt the disk from the Amiga side so that the disk validator needed to run on it -- it would try to restore the bitmap blocks and likely miserably fail to mark the Atari ones as occupied.
That edge case of perfectly reading at exactly the wrong moment is interesting. I suspect if it ever happened the Amiga would just re-read and the chances of that happening twice are very unlikely. Interesting though
@@RobSmithDev Yes indeed, re-read the track and the chances you start reading somewhere else are pretty high. There is an edge case in many trackloaders (game and trackmos alike) that is not covered, but according to the documents, is not so rare at all and that would be to start reading just before the second sync word and however, this second sync word would not end up in the DMA buffer, so the buffer does not start with the $4489 word -- and given that you might not get another full copy into your buffer of this sector at the end of the track, you might not be able to decode it if your decoder looks for the sync word. So given that this is a case that is happening in the real world, picking up the ST sector sync word instead of any Amiga sector ones should be occurring a lot more often that the case I mentioned. Wasn't there a dual format Amiga / Atari music disk a couple of years back (looked it up: Chipo Django 2)? The Amiga could actually have read the ST formatted content using a custom loader and re-use the data content -- but it didn't seem like they used a dual format disk, unfortunately. That would have been the cherry on the cake.
The sync word is less of an issue. Most track loaders instruct Paula to start the dma at the first sync word, and read enough usually for one track + around 2 sectors. Well at least workbench does! Not a massive issue though. Picking up the wrong sync word, well the window between the start of the Amiga sector and the ST is very small - as a percentage of the track I’d imagine it’s so small it’s very unlikely to be hit
@@RobSmithDev I might have not been clear enough: There is a hardware bug that will cause the DMA to only start AFTER the first *detected* sync word (so if the controller reads $4489 $4489 $5555 the DMA buffer will only start with $4489 $5555). There are cases where the reading of the bitstream might exactly start inside the first sync word, so that one will be missed and only the second one triggers the DMA, and thus only $5555 will end up in the first word of the buffer. There is only about a 3-4% chance of this happening (for a 11 sector disk), but it DOES actually happen and games and demos have had issues with this. I added a fix in my trackloader for this very reason. Depending on how large the distance is between the Amiga sync words and the ST sync words are, you might hit this, but yeah, the chances are likely to be 1:500 or less.
I'd be suprised if its actually a bug, I suspect, much like your other edge case it may just have missed the first sync word and found the second one. Its a sync word, not a sync long.
Actually it was other way around. ST/Amiga Format team continued to create ST Format, and ex-ACE magazine team started the new Amiga Format journey as it was finally commercially viable to publish Amiga only magazine. ST Format always had original roots of that publication till its closure in 1996.
Do you know how ZIP and JAZ disks worked? Are they just made of a different material that's able to store magnetic information more densely like a hard drive does?
I suspect the density of the magnetic medium is much greater, plus a much smaller drive head. They used CDR ( Constant Density Recording) with run length encoding but I dont know anything about that
Zip drives are simply an improved version of regular floppy drives. A denser magnetic coating on the disk along with physically smaller heads and a more accurate voice coil based tracking mechanism, a technology which was borrowed from hard disks. Competing "super floppy" formats like Floptical and SuperDisk drives used optical tracking mechanisms to position their heads more accurately than conventional floppies while retaining compatibility with regular 3.5" disks. Jaz drives are a completely different technology and consist of a single hard disk platter inside a removable cartridge. This type of drive was already quite popular with competing products sold by Imation and Syquest.
I thought Zip had some kind of magneto-optical element to it, but only for positioning the heads rather than in any R/W capacity? There was supposedly some technical trickery like that. Unless I'm getting confused with the LS120? (After all it begs the question how you could have cross compatibility between the 25, 100, 250 and 750MB versions, or at least the 250/750s could still read 100MB Zips...)
@@tahrey I also assumed that optical tracking was used, but a teardown on Gough Lui's Blog confirms that it doesn't. The only optical mechanism is for detecting disk size via the retro reflector in the corner of the disk. According to CNET's review of the Zip 750, backwards compatibility with the original 100M disks was unreliable and read only.
Floppy disk sorcery. It would be possible to create a dual format blank with all the blocks pre-allocated as bad/used, wouldn't it? I guess it's safe to write to such a crafted empty disk but there might be some pitfalls when deleting files or doing a filesystem check, I don't know. Maybe it's possible to write two special disk format programs on each system and after you've used both on one disk you get a dual format disk that's safe to write to until it's full.
I suspect each file system wouldn't be able to write to the "other" systems sectors if they were marked as free. Normal sector writes rely on the sectors already being present from the format operation which isn't the case here.
ST-Amiga Format proper was only around for like 11 or 12 issues IIRC. Once they'd got off the ground and the 16-bits were becoming more popular it must have been a bit of a stretch to cover both platforms in a single mag (and disk), and despite their architectural similarities their general software ecosystems and use cases rapidly diverged, only really sharing games in common, which sometimes showed great differences between the two machines. Plus the special format must have been a complete nause to deal with, though Rob Northen did then give ST Format its (presumably much simpler and easier to implement) single-sided compatible double-sided format... (DS owners could access the whole thing but SS only half of the contents, with a separate disk holding just the "side B" data available on request, though it's likely most SS owners just bought an SF314 as a second drive, or as an external for the early 520STf's with an internal SS, and copied the contents of that folder to a fresh disk themselves if there was a reason to load from the original drive)
There was also a public domain program called Flip for the Atari ST that allowed something similar to ST Format disks. First versions were written in 1987. It was used for example by Finnish Atari ST user club "ST-Klubi" to provide extra content for double sided drive owners on their disk magazine. Difference was that user had to launch Flip first and use command parameter to "extract" the file from Flip-formatted side B to another disk, rather than just open SIDE_2 folder as it worked using the ST Format disks.
@@Maraka77i ST Format did use a similar program for a little while until they added the SIDE_B folder, which is actually better because that way a small program is not taking up space on the disk, twice, that could be used by another tool or game. Remember that a file uses up at least a cluster on the disk, which could be 2 sectors on some disks, no matter how tiny the file is. Eventually they just said "If you don't have a double sided drive by now you wont be able to read our disks." and went double sided 100% as it also allowed them to squeeze extra tracks on disks for a little more content.
Good ol' Rob Northen, the target of so many incendiary pirate scrolltexts.
I always found dual format disks fascinating. I understood the basic principles, but always wondered about the details. So thanks for enlighten me.
You're welcome :)
I read that the “dual format” was credited to Jez San/Argonaut, but it’s got Rob Nothen written all over it. 😂
Hopefully they paid for it...
Great video, I love the tech details. As a side note, the magazine "The One" also had dual-format disks on several of its issue from 1988 up to 1991. I had several of those.
Oooh, interesting, do you happen to know if they used the same technique?
@@RobSmithDev No, I don't, sorry. I am pretty sure it's the same format, though. And I binned all my cover disks some years back because I thought I could always just download them from the Internet. Duh. :)
lol never mind
Zero magazine did as well. From memory they were a bit fickle on the Amiga - usually they'd boot up OK, occasionally not. I seem to recall they were also by Rob Northern, but I'd have to check
@@petergaley314 Isn't that always the case with Amiga floppies though? ;)
If I close my eyes, ctrl-alt-rees sounds lke Andy Crane on Bad Influence. I'll be following his channel to find out more about Ataris.
I wondered why the voice felt familiar...
Great video and very interesting! Good to see you both teaming up!
Fascinating stuff again Rob. I had forgotten about these disks and it was a very clever system. Well explained.
Thanks for explaining. Back in the day I often bought that mag and did wonder how they did it.
I did not know that I wanted to know this much (and more!) about disk encoding schemes
I was a bit confused until the animation at 9'30"... of course the disk is spinning and passing data in a serial manner and the machine is "looking out" for the sequence it is expecting. Very good explanation.
The ‘looking out for’ is covered in this video:
How Data is Encoded and Stored on Floppy Disks
ruclips.net/video/OAswAoNLJhs/видео.html
Really good breakdown. Glad to see someone documenting these file system/disk tricks publicly!
Rob Northen also developed the compression algorithm that was used at least in Hired Guns. Now that was some game for the A500.
fascinating Rob Northen technology
Very cool! I never saw these disks, but my second STFM came with a bunch of crackdisks whose intros frequently mentioned Rob Northen as a sort of nemesis for pirates. Makes sense that he'd have a hand in this ingenuity.
Interesting Video, always wondered how dual format disks worked, quite impressive how it was pulled off, I bet this could never have been done if the file systems were similar in design, But thanks to them being slightly different, it enabled dual format to be supported from the 1 disk
A lot of work to use one disk. But disks were expensive at the time. It's funny to think that a few short years later, AOL wasn't giving away disks.
Yeah crazy! Mind you if they were that expensive it makes sense to cram two systems of content on there to gain a wider audience
Yeah this was probably a considerable cost saver vs mounting an SS (or trick-formatted dual compatible disk for the ST and a DS one for the Amiga. Any time the later ST Format (or other mags) had dual coverdisks was part of some kind of special issue or giveaway promotion (eg having a full game from a couple years back)
Interesting stuff, I had a number of these dual-format disks back in the day and had come to the obvious conclusion that the ST data was on the side single-sided STs could read but didn't think much beyond that.
Never owned a atari or a Amiga, but man thats fascinating.
I would love to see a tri-format disk for sure
....coming soon...
Educated guess, DOS PCs uses FAT too so they should be able to read such a "single-sided" disk just fine. And as the PC disk controller can't read Amiga formatted disk all Amiga stuff just appears as noise to it. Just don't expect any special tools like VGA Copy to play nice with them.
Sidenote, a PC can read a 1581 disk just fine and if you have a file system driver you can even manipulate files on them. Tried that under Linux and it worked just fine, there is a FUSE driver called cbmfs that lets you just mount them. Or dd them and open them in c1541 from the VICE package.
I owned an computer
@@ms2649 why strive for tri when you can aim for quad?
@@sacredbanana unless they can read eachother files... Its not worth it in such a small storage medium
I suspect the tri format ones just relied on the ST's ability to read standard MS-DOS disks.
From what I understand yes, but would need some tweaks to allow the pc to recognise it
PC format and an AUTO folder (which the PC wouldn't attempt to execute) would probably work OK on the ST.
I could see it being set up similar to the ST Format SS-compatible DS disks. You just have a couple folders in the root, one "PC" and one "ST", with the respective files in. The processor architecture is different enough - and each OS smart enough to use magic numbers in the executable headers to prevent accidental execution of data / foreign programs with unpredictable effects - that it wouldn't do any harm to let users on the two platforms see each other's files if they opened the other folder.
Also as you could assume that all 3.5" PC drives to be double sided (given that they didn't start shifting to the format until it had already been proven in other machines, and didn't even stick with double-density for very long), it it could share some space with the Amiga on side B as well. Allocate maybe 250KB or so to each platform, with the PC stuff even working in regular DS mode so it's got the same sectors on each side and the FAT works more logically.
(As shown with ST Format et al, single-sided drives can read double-sided disks just fine and don't care about whether the FAT says they're SS or DS ... only the DS machines pay attention to that, to know how to read the two formats. It's just that with a normal format, files get striped between the sides, track by track, so the machine starts reading the data then hits a snag after the first few KB... The Rob Northen format used by STF laying data down sequentially instead, track to track on side A, then starting over on side B, with the "side B" folder effectively being a second root directory that only double siders could open. Therefore you can present the disk to the ST and PC as being double sided, but with the ST data only existing on the first two thirds or so of Side A, Amiga on the first two thirds of side B, and the PC data occupying both sides of the last third.)
You'd really need a good reason to do that though, as that's not very much space overall, and it'd just make more sense to use separate disks for each platform (or, say, have a split ST-Amiga or PC-Amiga one where the Amiga got about 2/3rds of the space, and a second ST-PC disk that's literally just MSDOS format but maybe with the single-sided-compatibility trickery, and the split being according to whatever was on the other disk)
That does bid a question though ... STs with TOS versions before 1.04 did something odd with their built-in formatter. Even though the TOS and MSDOS formats are sufficiently close to the original CP/M standard (that both OSes derive directly from), and the ST can always read PC-formatted floppies, the PC can't handle those formatted in an older ST (unless you use a thirdparty formatter utility). Which turned out to be quite annoying when I wanted to back up old disks from our TOS 1.0 machine to a PC based archive, and had to use an MSDOS go-between disk, and later filesystem-agnostic imaging software with an emulator... I wonder what it is that makes the PC choke on them? Something to do with the 1KB clusters? Different header ID codes with the PC expecting some extra part that the ST doesn't care about and doesn't lay down?
Well, I already knew those disk were using one side for each computer because of the head movement being twice as fast (half the data to read for each track).
Thank you for explaining the boot block trick.
IIRC, the game "Carrier command" is a dual format disk.
I recall there were dual-format CD-ROMs around, too. The Lost Mind Of Dr Brain came on a disc that had versions of the game for both Windows 3.1 and MacOS, which had rather different file systems for their respective CDs, and where you'd only see the relevant version of the game on each machine. Very useful for me, when the school had a bunch of macs (with one CD-ROM drive for the whole room) and I had a PC at home. Still had to have a separate saved game on a floppy for use at school, though.
Didn’t know that, very interesting!
That was much simpler.
ISO 9660 (the standard file system) places its header at a different location on the disc (32kB from the start) than the Apple partition map (512B from the start) or Apple HFS/HFS+ header (1kB from the start).
Only Mac OS will look for an HFS file system or Apple partition map. If it finds either of those, it will ignore the ISO 9660 file system entirely. Conversely, other operating systems don't know about Apple file systems or partition maps, and will only look for the ISO 9660 header.
Since all of these are at different locations on the disc, there is no need for overlapping-sector trickery, and since CD-ROMs are read-only, there is no need to protect either file system from being accidentally overwritten by the other one.
@@argvminusone The unused 32kB at the beginning of the ISO 9660 file system is also exploited by Linux distros which put MBR (and possibly GPT) partition tables there in order to make ISO images that can be written directly to a drive, e.g. USB flash drive, to create a bootable live/installation medium.
@falcon-ng6sd Ah, I was wondering how those hybrid CD+USB bootable images worked.
Thank you Rob a little more than my brain can handle.
Yes it was a real deep dive - the part about clusters actually took me a day to get my head around :)
Great in depth explanation rob, are there any tools to create these type of disks myself ?
None that I know of. Maybe I should make one
@@RobSmithDev Great idea maybe could be build in to DiskFlashBack, as a side note rob northern mentioned he used a disk duplicaton machine made by Trace to write his special formats back in the day I think it cost him around £15000 in the 1990's
Another great video
I didn't know that such a thing existed!
At 7:09 the third longword, 0x00000370 or 880 in decimal, is the pointer to the root block mentioned at 14:45.
And why was the root block in the middle of the disk? It takes less time to seek 40 tracks to either end of the disk than the whole 80 tracks from one end to the other.
No idea why it’s in the middle but seems to be a consistent thing - should have spotted that but I don’t know if it’s used to find the root block. Libraries like ADFlib look for the middle point, without checking this value. Hmmmm
Sub earned for such deliciously anti-social retro filesystem based content!
thank you
I've always wondered how it was done, I thought maybe it might be something like the ST data on one side and the Amiga data on the other but didn't have a clue how they did it, I certainly didn't think it was so complex 😀
It's got me wondering about the ST Format double sided disks, I seem to recall they were double sided with a "Side 2" folder on the disk for double sided disk drive owners. I guess in that case it was just maybe a pointer in the FAT12 filesystem for anything in the Side 2 folder was on the second side perhaps?
A very good question. I’m not sure how it would have presented that don’t worked with both. A curiosity
I wonder if it might just have been something as simple as you format the drive as single sided, write all the Side A content, fill it out with dummy files so there's no free clusters, then do a type of quickformat that changes the disk definition to double sided instead (maybe you format DS then quickformat to SS first of all, then change back...). Then you make your Side B folder and put all the Side B content in there, and delete the dummy files.
Maybe if the DS FAT is larger than the SS one you'd have to put dummies in the place where the extra parts would have to go, then back it up and use some trickery to rewrite new copies with the Side B area blank, but that wouldn't exactly be a great hill of beans, there were enough recovery tools like KnifeST and the like which could do that kind of work.
The alternative is that it somehow changes the sector order so that all the Side A ones come first and then all the Side B ones, instead of the tracks alternating side to side like with a normal format (so if you were to copy everything from that disk to another one, it'd have to run through 0 to 80 (81, 82...) twice, though stepping a little quicker than would be normal for a DS disk, with a clearly different seek pattern on the target drive, with the copy then not being properly SS compatible any more and stepping 0-80 just once at a more normal pace if you also copied *that* ...). That might be a little more work to set up initially, but it may be as simple as changing what the index numbers are on each sector, and after that you just have to make sure to pad the Side A fileset out to 360K before starting to write Side B, and deleting the dummies at the end.
(Or, third... you copy the programs onto the master disk using a special program that arranges them on the respective side A / side B tracks for you, as you only need to do that once, and you can prepare the contents for each side on a separate single sided disk to be sure it's going to fit, which is probably the easiest and simplest method of all - don't need any dummy files, don't need to reformat the disk vs a standard 720K (or 800K+ extended... this example disk has 10 sectors per track for the ST after all!) double sided type, etc)
Like it's probably nowhere near as complicated as it first looks. You just have to be able to do some minor bit of low-level FAT or sector ID hacking, and any extended formatter can probably do that already.
The "Side 2" feature allows compatibility with both drive types. Normally files would be written sequentially, top surface then bottom per track but these disks would have been built with some sort of custom creation program that keeps files on only one surface. Potentially you could create this manually by writing 2 files at once, offloading sufficient content to one file then the other to keep it on the side you wanted. Use dummy files as filler after a file ends to eat up the remainder of the current track, then delete later - though I doubt it would have been the method used.
Another possibility is that the allocation map was just patched after formatting to mark Side 2 as all used - then write the side 1 files and unpatch the Side 2 blocks and reserve the spare Side 1 blocks. Write Side 2 then remove the patched Side 1 mapping.
@@Rybagz Could be interesting to see if you could replicate it using a combination of those two ideas - fill the disk with a whole bunch of files that are just big enough to take up a single sided track each (first one may have to be smaller to account for FAT...), with sequential names because GEM seems to write them in alphanumeric order. Delete all the even numbered ones (assuming you started from file "000"), and that should presumably have the entire of Side B marked as used, whilst leaving Side A free.
Just to make sure you could then swap to a single sided drive, to see if the disk was at all readable, then to copy files onto it (it's physically incapable of writing to side B, and if it comes across a writeable sector that's on the wrong side it'll error out). Make sure you have just enough space left to lay down the empty Side B folder (I think it might have to be on A to display in the root, but its metadata content could spill onto B without any issue). Then swap back to the double sided drive to delete all the odd numbered files and write the Side B folder contents.
Though of course the actual play, once you'd verified the idea was usable with the single sided drive, would be to erase everything except the Side B folder off of Side A, and keep that disk as a master that could then be repeatedly duplicated using a fast sector-exact filecopy program whenever you needed to spin up a new one.
Maybe Rob Northen was sneaky, and did just that... supplied them with said master (perhaps even doing an initial step of deleting all the odd numbered files and replacing them with a single 360K file that filled the entirety of Side B), claiming it was a special format, and the only instructions were to delete the dummy file inside Side B folder after writing everything to A... and claimed it was a "special format". Or set the folder and that dummy file as Hidden and provided a little utility program that would "prepare" each side for use... Doing nothing but a few random seeks before side A was "ready", then repeating that plus unhiding the folder and deleting the dummy file to "prepare" side B ;)
it's Control ALT Rob!!!! :D
😂😂
Atari ST could also read DOS formated disks from PC. Built in as standard. No tools needed...
Yes, Amiga also, 720 Kb
I think the Amiga used something named Cross DOS to read and write to the disks if you had the utility.
Fascinating. Great background music too. I have just subscribed to Kevin MacLeod's YT channel!
He has some great music!
They must've used special hardware to write these disks since you'd need to write flux transitions. Maybe the Amiga could pull it off though since the hardware is very flexible.
Would have been easy to write them, at low level MFM which is what drives care about it’s all within spec. The hard bit would just have been the initial setup, but the Amiga could easily pull that off with the right knowledge
Writing flux transitions is exactly what the Amiga did. As I mentioned in a comment on another video, the floppy interface was a fairly primitive bridge between the floppy drive read/write lines and the DMA engine.
Writing tracks which required accurate sector positioning would have been tricky, though, since there was no hardware-level support for synchronisation with the INDEX signal.
The Amiga can detect the INDEX signal, and the PC format does allow quite a large tolerance for the positions of the sectors so the Amiga could easily write these perfectly fine, and does
@@RobSmithDev (This comes from my understanding of the information from the HRM and schematics, so hopefully it's mostly correct!)
The INDEX signal is connected to the FLAG pin of one of the CIA chips, so you would have to start the disk DMA from an interrupt handler or a polling routine. That introduces some variability in the timing and may require some tweaking to get right.
I know from experience that there was software like CrossDOS that was able to read and write PC floppies. I believe that the PC floppy controller did use index pulses for positioning, so it was evidently possible to get the required accuracy on the Amiga.
Again, if someone else knows more, I'm more than happy to be corrected!
EDIT: I just noticed that you did say that the PC controller had some tolerance regarding positioning, so there we go...
Huh, I always thought it was something to do with the rumour that the ST's single sided drives had the head on the "wrong" side, because Tramiel got a load cheap that were built wrong, or were actually double sided with one head failed... Guess not, unless the Amiga defaults to reading the boot sector from the opposite side to other systems (Mac, PC etc)? Similar to how the internal mechanisms on the early Megafile hard drives were actually higher capacity than stated, but some fault that meant only half the heads worked...
Anyway, the explanation is pretty good but begs a question from me over one point: you said that the bitpatterns used for MFM sector sync can't be laid down using normal data - presumably you have a combination of flux frequencies that would never happen due to how the encoding is designed to limit consecutive runs of 0's/1's and 0101's, but are written deliberately by the controller chip to mark these positions (also what reads and recognises them - the OS never gets to see this raw data, only what processed form the controller provides, which is why you have to use things like the Greaseweazel to record flux transitions).
So, how are we writing those patterns within the Amiga sector, if you can't do it with regular data? I expect the repeating pattern seen in the data analysis is just an artefact and doesn't actually mean anything, it's just the best that your software can do to interpret the "illegal" codes into something that seems valid. Maybe you can provoke the controller chip directly to write an index wherever you want it, but that seems unlikely and would need extremely exact timing. Would be better to set up a duplicator to directly alter the flux pattern, like what they probably did with Copylock and so-on? After all the disks are going to have to be copied by a professional operation rather than just with an office machine and ordinary drive anyway.
Though, I wonder - maybe there's inherent timing differences in where the two machines start to lay down their data on the disk, versus the index pulses that come from the drive's rotation sensor? Or they / their controllers can be set up to have a different degree of delay. Then you can format the disk as Amiga format at first, with as short a delay as possible, so its own bootsector appears pretty much immediately the chip starts reading and gets as much space as possible to store the setup data which tells it to look at track 40 and ignore the rest of side A. Then you reformat side A as ST format (skipping track 40...), but have a really big delay before anything gets written to track 0 after the index pulse, with the erase and write heads being deenergised so they don't erase the existing content either (and of course the sectors being halved in size so you don't risk overwriting the start of the Amiga data either, despite keeping the same number of them).
That then plonks the start point for ST sectors, including the controller-generated index pattern, somewhere in the middle of the second, unused Amiga sector. Possibly if the Amiga controller starts reading a little quicker after the pulse than the ST does, the ST may not even see the Amiga index at all, let alone having to process it and decide it's invalid (IDK if the controller might then just lockout for the rest of the track and wait for the next pulse to retry, after all). And you achieve this without having to do any direct-flux-transition-writing voodoo at all, just sending some adjustment data to the drive controller with a bit of assembly code.
(and if that's not doable, you could have a modified ST drive specifically for writing that one track, with the index sensor moved slightly, or with a simple 555 circuit hacked in that delays the pulse by a few hundreths of a second)
Just to clarify, the Amiga for example can easily write any pattern it wants, but normal MFM encoding of data to flux transitions won't produce those special sequences. Theres nothing wrong with them, just data won't generate them. But its all still a normal MFM bit stream. You can find out more about MFM encoding this is much earlier video of mine: ruclips.net/video/OAswAoNLJhs/видео.html
These disks could easily have been written from something like the Amiga and dont require any special flux timings at all.
@@RobSmithDev As in the Amiga is able to write whatever MFM patterns it likes, under software control? Interesting... wonder if that's why it had such a piracy problem :D ... maybe even the machine of choice for copying disks of entirely different formats too?
I figured the "illegal" vs "legal" patterns were because of the intent behind the "modified" FM, making the encoding more efficient in terms of how much fluff was around the actual data, whilst also making it more robust and less prone to losing track of the self-clocking / not having a significant DC level / etc? Regardless, if they're not produced by any actual "real" data, then presumably they also can't be decoded back to a particular bitpattern either, so either have to be ignored completely or flagged as an error (sign of a bad sector, perhaps, or at least that the read has to be retried), except where they are index codes appearing at a point when they're being actively looked for?
Check out the video I pusted above, it explains how it all works
@@RobSmithDev the "how data is encoded on floppies" one? I think I kinda have a grip of it in general, I'm just not familiar with the specifics for the miggy, having (perhaps obviously) been an ST child and then moved to PC. I can grok the workings of a WDC 1771 at some level and have a misty idea of how FM / MFM / RLL work if nothing else :)
yes that video, it goes much lower level into flux transitions and what the drive does, then covers how MFM encoding works (and the sync marks).
The Amiga could read or write a bitstream of data (MFM or GCR encoded) - they still had to be at fixed timings, you couldn’t adjust that but the Amigas hardware didn’t do much for you (by default) beyond that. It could be setup to watch for a sequence and trigger interrupts/start DMA etc too. Writing was all done using DMA
I've never seen one of these disks in the flesh, can you mount the ST side on the Amiga with the Dos filesystem from the Storage disk?
For some reason, no it doesnt although I havent checked yet to see why
Always confusing that the 314 has higher storage capacity than the 354 lol
Yeah that confused me too!
There were also drivers for the Amiga to read FAT disks.
This would have meant that the disk could be read as OFS and as FAT.
It’s true but for some reason I haven’t looked into they don’t work for these disks - I suspect it’s because of the different sector sizes and the driver probably assumed them all to be the same
In theory shared data could have been stored in the ST section only but it mightn't have been worth the effort in most cases.
The tricky part is also that, to actually have the ST sector 0 inside the Amiga sector 1, you need to "break" the MFM encoding, because MFM cannot encode the sync words (for good reason). Moreover, as the Amiga always needs to write whole tracks, attempts on modifying track 0 will certainly break the disk for the ST. If the Amiga had actually checked the MFM encoding while removing the clock bits, it would have refused to decode sector 1. But it didn't care about the clock bits and if the checksum was right, everything was fine.
It would also be interesting if the Amiga would read in enough of the track into the MFM buffer if it "accidentally" picked up the 4489 of the ST sector 0 first, so that the end of the buffer would contain a full version of Amiga sector 1 -- otherwise the sector 1 would appear broken (rereading the track would likely fix that). It would also be interesting to know whether these disks worked on all kickstart versions. I believe that later versions (kick 3.0?) would always try to decode a whole track and put up read errors if some of the sectors were corrupt or missing (remember that these disks were missing Amiga sectors 2 - 10 on track 0.
About the bitmap blocks on the Amiga side: Better never corrupt the disk from the Amiga side so that the disk validator needed to run on it -- it would try to restore the bitmap blocks and likely miserably fail to mark the Atari ones as occupied.
That edge case of perfectly reading at exactly the wrong moment is interesting. I suspect if it ever happened the Amiga would just re-read and the chances of that happening twice are very unlikely. Interesting though
@@RobSmithDev Yes indeed, re-read the track and the chances you start reading somewhere else are pretty high. There is an edge case in many trackloaders (game and trackmos alike) that is not covered, but according to the documents, is not so rare at all and that would be to start reading just before the second sync word and however, this second sync word would not end up in the DMA buffer, so the buffer does not start with the $4489 word -- and given that you might not get another full copy into your buffer of this sector at the end of the track, you might not be able to decode it if your decoder looks for the sync word. So given that this is a case that is happening in the real world, picking up the ST sector sync word instead of any Amiga sector ones should be occurring a lot more often that the case I mentioned.
Wasn't there a dual format Amiga / Atari music disk a couple of years back (looked it up: Chipo Django 2)? The Amiga could actually have read the ST formatted content using a custom loader and re-use the data content -- but it didn't seem like they used a dual format disk, unfortunately. That would have been the cherry on the cake.
The sync word is less of an issue. Most track loaders instruct Paula to start the dma at the first sync word, and read enough usually for one track + around 2 sectors. Well at least workbench does! Not a massive issue though.
Picking up the wrong sync word, well the window between the start of the Amiga sector and the ST is very small - as a percentage of the track I’d imagine it’s so small it’s very unlikely to be hit
@@RobSmithDev I might have not been clear enough: There is a hardware bug that will cause the DMA to only start AFTER the first *detected* sync word (so if the controller reads $4489 $4489 $5555 the DMA buffer will only start with $4489 $5555). There are cases where the reading of the bitstream might exactly start inside the first sync word, so that one will be missed and only the second one triggers the DMA, and thus only $5555 will end up in the first word of the buffer. There is only about a 3-4% chance of this happening (for a 11 sector disk), but it DOES actually happen and games and demos have had issues with this. I added a fix in my trackloader for this very reason.
Depending on how large the distance is between the Amiga sync words and the ST sync words are, you might hit this, but yeah, the chances are likely to be 1:500 or less.
I'd be suprised if its actually a bug, I suspect, much like your other edge case it may just have missed the first sync word and found the second one. Its a sync word, not a sync long.
stampede did the same thing.. but the whole magazine was on the disk..
I used to get ST/ Amiga Format, until they dropped the ST bit (making it better 😊) and then bought Amiga Format.
Actually it was other way around. ST/Amiga Format team continued to create ST Format, and ex-ACE magazine team started the new Amiga Format journey as it was finally commercially viable to publish Amiga only magazine. ST Format always had original roots of that publication till its closure in 1996.
Do you know how ZIP and JAZ disks worked? Are they just made of a different material that's able to store magnetic information more densely like a hard drive does?
I suspect the density of the magnetic medium is much greater, plus a much smaller drive head. They used CDR ( Constant Density Recording) with run length encoding but I dont know anything about that
Zip drives are simply an improved version of regular floppy drives. A denser magnetic coating on the disk along with physically smaller heads and a more accurate voice coil based tracking mechanism, a technology which was borrowed from hard disks. Competing "super floppy" formats like Floptical and SuperDisk drives used optical tracking mechanisms to position their heads more accurately than conventional floppies while retaining compatibility with regular 3.5" disks.
Jaz drives are a completely different technology and consist of a single hard disk platter inside a removable cartridge. This type of drive was already quite popular with competing products sold by Imation and Syquest.
@@firstsurname9893 very inty! Thanks for the info
I thought Zip had some kind of magneto-optical element to it, but only for positioning the heads rather than in any R/W capacity? There was supposedly some technical trickery like that. Unless I'm getting confused with the LS120?
(After all it begs the question how you could have cross compatibility between the 25, 100, 250 and 750MB versions, or at least the 250/750s could still read 100MB Zips...)
@@tahrey I also assumed that optical tracking was used, but a teardown on Gough Lui's Blog confirms that it doesn't. The only optical mechanism is for detecting disk size via the retro reflector in the corner of the disk.
According to CNET's review of the Zip 750, backwards compatibility with the original 100M disks was unreliable and read only.
what about 2 megabyte high density disks? are they really 2048 kb? unformatted in size? thanks.......................
I honestly don’t know!
🤯
Floppy disk sorcery. It would be possible to create a dual format blank with all the blocks pre-allocated as bad/used, wouldn't it? I guess it's safe to write to such a crafted empty disk but there might be some pitfalls when deleting files or doing a filesystem check, I don't know. Maybe it's possible to write two special disk format programs on each system and after you've used both on one disk you get a dual format disk that's safe to write to until it's full.
Yes I think it would be safe, but if you ran any kind of disk repair tool it would probably damage it
I presume they did this to make the disks. You have to decide ahead of time how much you allocate to each side
I suspect each file system wouldn't be able to write to the "other" systems sectors if they were marked as free. Normal sector writes rely on the sectors already being present from the format operation which isn't the case here.
Too bad floppies didn't have partition tables. Would've made this a lot easier.
Very true
What the hack is this black magic 😂
ST Amiga Format was not that short lived. They decided to split it into two magazines, ST Format and Amiga Format later adding PC Format to the list.
This is true, but I meant short lived in the dual format
ST-Amiga Format proper was only around for like 11 or 12 issues IIRC. Once they'd got off the ground and the 16-bits were becoming more popular it must have been a bit of a stretch to cover both platforms in a single mag (and disk), and despite their architectural similarities their general software ecosystems and use cases rapidly diverged, only really sharing games in common, which sometimes showed great differences between the two machines. Plus the special format must have been a complete nause to deal with, though Rob Northen did then give ST Format its (presumably much simpler and easier to implement) single-sided compatible double-sided format... (DS owners could access the whole thing but SS only half of the contents, with a separate disk holding just the "side B" data available on request, though it's likely most SS owners just bought an SF314 as a second drive, or as an external for the early 520STf's with an internal SS, and copied the contents of that folder to a fresh disk themselves if there was a reason to load from the original drive)
There was also a public domain program called Flip for the Atari ST that allowed something similar to ST Format disks. First versions were written in 1987. It was used for example by Finnish Atari ST user club "ST-Klubi" to provide extra content for double sided drive owners on their disk magazine. Difference was that user had to launch Flip first and use command parameter to "extract" the file from Flip-formatted side B to another disk, rather than just open SIDE_2 folder as it worked using the ST Format disks.
@@Maraka77i ST Format did use a similar program for a little while until they added the SIDE_B folder, which is actually better because that way a small program is not taking up space on the disk, twice, that could be used by another tool or game. Remember that a file uses up at least a cluster on the disk, which could be 2 sectors on some disks, no matter how tiny the file is.
Eventually they just said "If you don't have a double sided drive by now you wont be able to read our disks." and went double sided 100% as it also allowed them to squeeze extra tracks on disks for a little more content.