Migrating OS from floppy to USB flash and USB hard drives

[Yoda]

And you didn't use OS caching and always wrote in small 1-byte chunks to the drive, I presume?

Does constant trollin' brings you to an extasy?

That would need 94 or 95 tracks, unless you were using a slow motor and packing more sectors into each track.

There was an old DOS resident utility - PU1700. It reduced interleave gap between sectors to pack 21 sector per track and used 82 tracks. The total capacity was 21*2*82*512/1024 = 1722 kiB/disk.

[DavidCooper]

Having thought about it for another minute, the music played by the floppy drives was probably based on moving the head in single track jumps at different frequencies and nothing to do with changing the motor speed (which may not even be possible, but certainly wouldn't be loud enough to show up).

More importantly though, if any of you have got old equipment that makes characteristic noises, whether that be beeps, clicks, grinding, chuntering or whatever, it would be worth making audio recordings while that equipment still works before the chance to do it is lost forever.

[Solar]

IIRC, I once format an 1.7MiB 3.5" floppy.

Amiga-formatted HD floppies had a capacity of 1,76 MByte. That didn't take special disks, just the special Amiga floppy drives and inbuilt floppy controller (which was significantly different from PC controllers in that it reads complete tracks at a time, making inter-sector gaps unnecessary). Later non-standard file formats allowed pushing that limit close to 2 MByte.

[Yoda]

And you didn't use OS caching and always wrote in small 1-byte chunks to the drive, I presume?

Does constant trollin' brings you to an extasy?

No, that was a genuine question. If you want to act all idiotic, feel free.

For those, who thinks that "I act all idiotic" and wasn't smart enough itself to understand what did I wrote.
1. I leaved OS default value for my flash drive to "optimize for quick removal" so Windows doesn't cache a lot.
2. Only idiotic programmer will make a lot of code that writes 1-byte chunks. Windows wrote by not an idiotic programmers.
3. So normal work with flash (and not jerking 1 byte all the time) will not be a problem.
4. And please STOP insulting!

Having thought about it for another minute, the music played by the floppy drives was probably based on moving the head in single track jumps at different frequencies and nothing to do with changing the motor speed

You may see that a self-made controller is attached to the floppy cable. It may generate very different frequencies for moving heads. Motor speed for FDD is 300 RPM and is beyond of control. Theoretically it is possible to rise data frequency but it is out of possibilities of common FDD controllers.

More importantly though, if any of you have got old equipment that makes characteristic noises, whether that be beeps, clicks, grinding, chuntering or whatever, it would be worth making audio recordings while that equipment still works before the chance to do it is lost forever.

I like the sound of very early HDDs - ST506/ST412.

[DavidCooper]

You probably don't know the way David works with his system.

I don't do anything differently from anyone else in terms of modifying code and saving the changes - things get rearranged a bit here and there while the code is held in memory, and every now and then the file needs to be saved to guard against it being lost. The only difference is that I'm editing machine code in the memory locations where it actually runs (and occasionally while it's running), whereas other programmers edit it somewhere else in memory and in a different form (which needs to be translated into machine code and then loaded into the right place to run it), but that makes no difference to the way it's saved. Exactly the same issue affects how text files are saved from my text editor - typically I make a certain amount of changes to a document and then decide it's a good time to save it in case something goes wrong, but what I'll do now is save it to a RAM-disk instead (or optionally to free space at the end of the hard drive) and I'll only save it to a flash drive or SD card at the end of a work session. The issue's entirely about writing to flash memory via the BIOS where the amount of rewrites to the same block of sectors to save the file could go as high as 16 (and that's assuming a maximum block size of half a megabyte, but if the maximum block size goes up to a megabyte, that would instantly result in 32 rewrites of the same block being necessary in order to write to the whole block in well aligned BIOS-write-sized chunks). The number of rewrites can obviously be reduced by checking which blocks of 64 sectors have changed and only writing those, and in many cases it will be better to write more than 64 sectors (though that only works if the last sector in the next lot of 64 doesn't need to be written, and it won't work on a BIOS that can't handle the normal maximum of 127 sectors at a time), so I'm going to have to write a lot of new code to do all the saving in the least damaging way, and it'll also take a lot of work just to make a RAM-disk the initial destination for every save, but it should all be worth it.

[DavidCooper]

Just a little update now that I've got things working reliably. A strange enhancement of capability of the BIOS has occurred and I don't know what caused it, but now the machine can boot up from USB floppy drive through any USB port and not just one. More importantly, I can now plug flash drives into all the USB ports and work with them all through the BIOS where previously they were ignored. This has all happened since I booted up from an SD card, so somehow that must have changed some setting and improved the machine. I don't know if there's any limit to how many USB drives the BIOS can now handle - I'll have to get a USB hub and try it with even more, but it's already increased my options considerably.

I've managed to get enough code into the MBR to provide an adequate amount of multi-boot options, so I probably won't now bother to use any additional sectors to enhance it further. My MBR code lists the bootable partitions along with 8 bytes (03 to 0A) from each VBR to help indicate which operating system they're likely to contain. Pressing a number key 1/2/3/4 then triggers it to boot the appropriate partition, though if there is only one bootable partition it will boot it directly without waiting for key input unless the partition contains my own OS. If the partition containing my own OS is selected, a further key press of Return or Space is required to enter it - if the Return key is pressed, the first version of my OS in that partition is booted, but if the Space key is pressed, the MBR code scans every 1.5MB on from there for the most recent version of my OS and boots that instead (the partition contains an array of 1.5MB subpartitions designed to behave like floppy disks). If the most recent version has a bug in it that causes it to fail to boot properly, I can reboot using the first version in the partition and repair the most recent version from there. All other subpartitions can be booted from within my OS, so it isn't vital to make them directly bootable from the MBR.

Once I've written everything up properly I'll release the new version, but at the moment I've been diverted into getting it to read BMP files out of the FAT32 partition so that some of the fun stuff it can do with photos can be made available at the same time. Now that I have an efficient way to make photos available to my OS I should be able to get on with the computer vision part of my project (which is hopefully going to be a lot more fun than the linguistics side of things where progress continues to be a grind - it won't do anything rewarding until it's complete, and I'm having to take more and more time off due to ill health).