How Triple Format PC/ST/Amiga Floppy Disks Worked

[@gnu-lynx2501]

Such a nice technique! Apparently only few mastered it back in the day. Fellow viewers, please report examples of games or magazines that used it.

[@tlhIngan]

So it's just a dual format Amiga-PC disk that the ST could also happen to read, with the trick in that they altered the disk interleave to provide more inter-sector spacing.

[@RobSmithDev]

Kinda yeah. It’s simpler than the dual format one. I was a little disappointed tbh

[@stuaxo]

The more I think about this, the more combinations there are to achieve this (or not!) this would almost make a fun(?) puzzle game with various scenarios.

[@MistaMaddog247]

I wasn't surprised that a FAT12 disk with 80 tracks & 9 sectors can be read on both ST & PC, I've used DOS formatted disks to transfer files between the school's PC & my own STe. But I had to use a dedicated formatting program on the ST (which also adds a boot sector saying it was formatted with MS-DOS) instead of using the GEM desktop. Adding the "bad" sectors that can be read on an Amiga was the clever part... 😀

[@wunderarnebjarne]

The STE actually formatted DOS-compatible floppies from the desktop.

[@JimLeonard]

The animated visualization starting at 4:38 is great! How did you produce it? Was it painstakingly created in something like After Effects, or did you use something else?

[@RobSmithDev]

I copied the cluster FAT from the disk and wrote a program to render the basics of that. It drew out the grid, filled it in, and also did the directory listing at the bottom. It exported something like 3000 PNG frames which I loaded up as a video later on and overlaid a graphic with extra information on.

[@JimLeonard]

@RobSmithDev Well, if that isn't enough of a reason to subscribe to your channel, I don't know what is. Excellent work.

[@RobSmithDev]

@@JimLeonardthank you

[@Jaw0lf]

Again more amazing information and clever methods employed to make that 3 system disc work.

[@barkingboyuk]

Very interesting. My budget release of Stuntcar Racer is dual Amiga/PC format which I always thought was rather cool.

[@stuartaxon2898]

Nice! Just need some modern utilities to create these now (well need being relative of course).

[@guffaw1711]

I wonder how did you create those nice looking disk shaped sector views?

[@RobSmithDev]

The circular ones were with HxD floppy disk emulator

[@George090974]

I just love the feel of a real floppy. Such nostalgia!

[@96JustStuff]

Thats what she said

[@DaveVelociraptor]

I know at least some ST games had the clever idea of putting disk 2 onto disk 1 but handling the error of not being able to access them by just saying insert disk 2. Meaning if you had a double sided drive you wouldn't need disk 2. Later it became more common to put "double sided drive required" on game boxes because the single sided drives were only in the very first STFM and in the original STm with SF-354, and you could buy an SF-314 to go double sided.

[@dieseldragon6756]

Seeing the techniques used to place specific data on specific areas of the media so they can be read by their respective target systems (I assume the Amiga only used 40-track drives?) _without_ interfering with the data for the other systems in the process, part of me is wondering if anybody ever released tape reels that would be readable in IBM-based systems on one side, but if you turned the tape over so the _back_ of the tape was passing the read head you'd get data targeted to a UNIVAC? 🙃 Nice videos here, chap! I've done a lot of messing about with floppies at the _data_ level¹ but mapping data areas to specific _phisical_ points on the disk has always escaped me. Ask me to drop a new BPB? No problem. Ask me to drop a stream of data right on track 40? Outside of my ability, I'm afraid! 😇 (¹ - I once managed to cram about 250MiB of data onto a 1,44MiB floppy just for a laff, the result was readable on any FAT-12 capable system. I later employed a similar technique to produce ISO images about 1GiB in size each bearing 1TiB worth of test files, that each bear unique file hashes and provide a useful (And sysadmin-free) alternative to H2TestW. 💿🗜👍)

[@RobSmithDev]

The Amiga by standard was an 80 track DD drive. It was just flexible (or left to the programmer) how to package the data. Never played with tape for computers expect for a VIC20 but I was very young. Sounds like you’ve done some fun and cool stuff too! Seems a shame this kind of knowledge is slowly getting lost

[@zemaj0]

Excellent video so if you formatted the PC St or Amiga disk what's the other information still be there? For the other formats?

[@RobSmithDev]

No, formatting would rewrite/damage track 0 so you would lose everything

[@Aeduo]

If there was common data between the two "formats", it seemed that the PC and ST used a similar (same?) disk structure/filesystem so it would make sense they could just include the data for both together, and even common up some files shared between both versions of software to save space? Probably hopeless for Amiga since it seems to be just a wholly different sector/disk format though.

[@stuartaxon2898]

That would be the ultimate, somehow have some readonly files for data shared by all three and a version of a game / software for all three that uses it.

[@jjdigitalvideosolutionsllc5343]

Could you do another video in this series and cover the floppy disk format used by MacroSystem's DraCo. DraCo runs AmigaOS 3.x and uses a standard PC floppy drive. MacroSystem distributed some of their software using. custom floppy format. Somehow they also managed to manipulate the PC floppy drive to read Amiga disks too.

[@RobSmithDev]

It’s actually really easy to read Amiga disks with a PC floppy drive, just not with the original PC floppy drive controller. I don’t know much about the Draco though so I’d have to find a disk.

[@tahrey]

@@RobSmithDev I wonder even if it is actually possible to read Amiga disks on PC, so long as the controller (or BIOS?) offers sufficient low level read functions (that may be necessary for, say, copy protection). There's enough ST disks that I imaged for use in emulators way back in the late 90s / early 2000s using PCs with entirely standard motherboards, even though DOS/Windows refused to even acknowledge that there was a disk in the drive. Perhaps the same story for the Amiga, seeing as it's the same density, encoding, etc? Just laying the MFM down differently? So if you can tell it to just grab whatever valid bytes it can find, you may be in luck... just the OS will still ignore it, and you can forget about writing to it. Now, _Macintosh_ (and maybe Apple II?) floppies, that's an entirely different kettle of fish, given their multi-zone sector density and variable RPM trickery to keep the effective physical bit density relatively uniform across the whole disk (all that to get just 400K per side, too ... pity). I'm still not sure how Spectre GCR managed using them on the ST... perhaps a custom controller that varied the data rate rather than the rpm? But a PC would be completely lost...

[@RobSmithDev]

There was a trick that used to work, using two drives for reading Amiga disks. The idea being you told the bios to read a PC disk, and it did. But as it started you switched the drive to drive B and the bios would just keep reading the disk. Some controllers could be programmed to read Amiga disks too. Mac, yeah that’s more complex and variable speed ones are even more difficult if you don’t have a Mac floppy drive to read it on.

[@stuartaxon2898]

PC bios that understands Rob Smiths floppy or other stuff like the GreaseWeazle would be good. Could definitely expose some new IO controls, and maybe even add filesystem support.

[@104d_3rr0r_vince]

Back in the days, I had a friend with an STFM. He wanted some new games and I managed to get some in the early days of internet. I remember somehow extracting the images, and write them to disks via CrossDos, so I guessed that the ST had the same format as the PC. Maybe I have false memories... who really knows anymore.

[@RobSmithDev]

Yes ST and PC can be compatible with each other. They both use the same file system, but the ST *can* be more flexible than standard PCs could

[@Mrshoujo]

This is similar to Mastertronic's release of Ninja in the U.S. for the Atari 8-bit & Commodore 64 on the same side. Track 0 boots Atari 8-bit & jumps over half the disk to load the Atari sectors. Commodore disks can have the File table anywhere & lies in Track 1. The 1st half is all 1541 readable.

[@Carlos_Se]

I really liked those "Public Domain" magazines back in the day. Have they been preserved in PDF? Thanks.

[@RobSmithDev]

I’ve no idea. I literally just have this one disk. I’m sure someone out there somewhere will have them maybe. They might be on the internet archive i guess

[@NellWatson]

There are six cover disks on there, but I don't see the magazines themselves, unfortunately.

[@RobSmithDev]

@NellWatson hopefully someone has them somewhere

[@Carlos_Se]

@@RobSmithDev No, they are not there but there are the all 6 issues cover disks.

[@tahrey]

Oh, this was off an actual magazine? Explains why it's multiformat I suppose. I thought it was maybe from some very odd PD Library...

[@jongrantuk]

Could you record at a smaller screen size, so when we view it we don't need an HD monitor to avoid it looking blurred please.

[@RobSmithDev]

Too much information for smaller screens unfortunately.

[@deavo74]

0:00 Anyone else reply “Hello”… No? Just me… Okay as you were…

[@RobSmithDev]

😂

[@davidlloyd1526]

You sort of missed explaining why track 0 has 11 sectors... I assume it's two Amiga sectors, and 9 FAT sectors?

[@RobSmithDev]

Yes thats right

[@tahrey]

Huh! After the first minute or so I thought I was going to get to comment "Called it!", but I guess not... Really nice analysis, especially checking what side each set of files were on. How much does that data add up to overall, by the way? Or at least what's the total FAT split vs OFS? Extra info or thoughts: * The weird ordering of the sectors is probably some kind of fast-load interleave thing. Pretty common offering for anything but the most bog standard formatting utility, at least on the ST (not sure about the Amiga - allegedly that reads an entire track into memory and then decodes it using the CPU, which should make loading extremely fast, but I've never known it to be anything other than glacial...). Gives the controller a chance to read more than one sector per rotation (as it needs a little reset time after reading each one), potentially doubling or tripling your read speed, up from the bare 2.5KB/s or so you'd otherwise have to suffer. I think high-density MSDOS disks may even do that by default, as back when it was at all relevant I did clock them at around 15KB/s... so twice what a DD would manage when reading 3 sectors per rotation and having a fast head step (having sector 1 near the END of the track also helps by not having to wait for a full rotation after the step), and certainly a hell of a lot better than, say, the yawn inducing load time of a mere 32KB Degas Elite picture from a non-interleave disk. Probably extra necessary when things are packed together so tightly, though given how little data each platform is afforded out of the total it feels a bit like putting a turbo on a car you only ever drive five miles back and forth. * 11 sectors per track is really pushing it, especially if you're doing it on the inner tracks. I've tried it a couple times before to make an extra high capacity disk (in combination with using extra tracks), but it was never particularly reliable. Seems kinda crazy that they'd do that, particularly as track 0 is so important, but then I suppose you can only define a single sector number for the entire disk with DOS / FAT format floppies so you're kinda stuck. Either have to do that, or suffer having lower capacity overall by only stating 8 official sectors instead of 9. Though it kinda seems like they maybe coulda just not written the "9th" (and perhaps "8th" also) sector at all there and marked those clusters as bad in the FAT? Perhaps there's some other technical reason where the controller or OS would reject the disk if it didn't have all its sectors on that one track or whatever...? * I don't think the sector count is why PCs couldn't read that dual format disk. There's plenty of extended formats for DOS and Windows PCs that work just fine (including Microsoft's own installation floppies, which hold 1.68MB instead of 1.44), and they pretty much universally seem to rely on squeezing in extra sectors rather than seeking additional tracks, which PC drives seem to be particularly bad at vs those used in the ST and Amiga (it's a bit of a problem for imaging pirate disks, even). I think the Microsoft one uses 21 instead of the usual 18, or the equivalent of a DD with 10.5 sectors (or I guess 21 x 256 byte, if that wouldn't be an issue due to the extra sync overheads?). So, it must be something else. First thought was that it could be that DOS isn't really made to understand single sided 3.5" disks (I certainly never found a way to make the built in formatter produce a 360K rather than 720K one, much less a single sided HD), but it can handle both single and double sided 5.25"s so that seems a bit of a reach. Most likely I figure the dual format one must have used an older version of the ST-specific FAT format, perhaps more CP/M-like than MS-DOS. As I commented on that video, STs before TOS 1.04 (which was, what, 1987, 88?) couldn't natively format disks that would be readable in PCs, even though they're perfectly happy READING DOS disks, and if I ever learned why that was I've long since forgotten it. Probably some very minor detail of the BPB or the sector sync? And as the tri-format disk will have been basically made as a dual-format PC/Amiga disk (without even any trickery to distribute files between the sides), that means it'll automatically be readable by ST and PC... It may be that it was made a bit later than the dual format one (do you have a date for it?), so the ST formatting would be identical to MS-DOS anyway, but really it doesn't matter a huge amount. And likely it was all prepared and laid down by an Amiga like you proposed before, unless it was done on a dedicated duplication machine with advanced features. * Another thought that just arrived from the above: note that the tri-format disk still says 2 sectors per cluster, despite being 512 byte, rather than 256. ISTR that ST disks (at least the ones formatted on our TOS 1.0 machine...) used 1 sector = 1 cluster, thus 512 byte clusters, storing files a little more efficiently and potentially having the ability to store a little over 1400 individual files, whereas PC ones have 1024 byte clusters as each one is two sectors - possibly the same X/Y position gets twinned across both sides, as they're most likely to show mirrored bad sectors in the case of any damage? Don't know why you'd do that as a universal thing, but certainly it would be necessary in order to make 2.88MB extended density disks work with FAT12, otherwise you'd be limited to just 2.0MB (...unless they use 1024-byte sectors? ... I feel a wikipedia rabbit hole coming on) Which may then tie back to the whole incompatibility between ST and PC, if the OS is assuming that as the default, but the disk is set up otherwise. The PC would be fine working on that basis, so long as you're not bothered about storing scads of tiny files and don't mind losing a little capacity by padding everything out to the nearest KB, as all of its 3.5" disks would be double sided anyway (perhaps it may also hinge on whether you've set a drive as a 40-track, thus 360K DD 5.25", vs 80-track and therefore either 1.2MB HD or a 3.5"?). But that wouldn't work for the ST given that it was designed for single sided and had double sided capability added on almost as an afterthought... and with 720K already seeming like a lot of space, there'd be no thought of providing for some theoretical future disk with 4x the capacity. Really it needs some real low level analysis of what the BPBs, syncs, etc look like for both machines, and quite _why_ PCs can't read older ST disks. But right here right now I'm kind of tempted to fire up an emulator with both TOS 1.0 and 1.04, and, if it can actually run a format on a disk image, if single and double sided disks look different to each other in these ways both within and between the different versions. Even without using any kind of deep analysis that reveals the cluster sizes or the like, it would be enough to compare the initial free space vs how much is left after copying a 1-byte file to the root (or maybe just creating a folder?) and seeing how much it went down by. Plus doing the same on PC for 720k and 1.4MB disks just to be sure... (I don't have a functional 5.25" that I can use... or at least, I have one that came preinstalled in a hand-me-down machine, but I dunno if DD or HD, and I don't have any disks for it, had to replace it with a 3.5" to get any data in or out). (and of course that may also explain why the ST part of it ISN'T single-sided compatible, not even via the Side B Folder trick, because the clusters are innately tied together across sides ... perhaps another thing to check on is whether any of the ST Format or other coverdisks that use that convention are PC-readable without the kind of compatibility overlay you have installed? I don't know if I ever tried... just imaged them directly then used the image file instead...)

[@RobSmithDev]

I did wonder about fast loading, but the data that would be in those sectors doesnt really make much sense for that. It could be, as per your second comment to allow them to be read more quickly though, or at all, as without the usual sector gaps it may have needed two passes to find them all. 11 sectors per track was standard on the Amiga, and worked perfectly fine, but for PCs not so common. If you browse back to one of my earlier videos, there was a format on the Amiga that used 12. Now that really was pushing it to the edge. Yes I suspect the Tri-format disks were a later creation and therefore simpler to make based on previous knowledge. Re the cluster question of one byte/two per cluster. They dont get twinned in the way you describe. For example, cluster 1, 2, 3 and 4 would be on one side, 5 would be split over both, 6, 7, 8, 9 woudl be on the upper, and then this would repeat (assuming cluster 1 started on the first sector of the lower side, and that depends how the disk was configured) The calculation for the location of the sectors within a cluster is part of the FAT spec so if this is a single sided or double sided disk doesnt matter, both should be able to read it and both file systems will support single sided disks so I dont think that was the reason for the incompatability. Theres also another sync mark that PC disks need, which I dont recall seeing on the dual format disk. It might have been there, I dont recall. Someone described the early TOS disks as having a bug which made them incompatible with PC, but as I'm not an Atari expert I couldnt say. I'd imagine it wasn't a massive difference though.

[@IunahYT]

No comments lol Guess I'll be first

[@RobSmithDev]

:) someone has to be