Grzyb wrote on 2024-12-21, 03:26:

But no luck in making my own 5.25" 1.44 MB floppies as of yet - all those non-standard formatters failed.
I'm blaming my special four-floppy FDC - it has its own BIOS, there's no floppy drives declared in CMOS Setup, which may be enough to confuse non-standard software.
Oh well, I will try again when I aquire a more standard setup...

FDFORMAT should come with full sources, Turbo Pascal IIRC. I have them if you can't find the correct ZIP file on the net. Also BTW there are two compiled executables, the default one is in German but there is also English version. I've seen ZIP packages with only the German EXE compiled, even thoough it looked to be the exact same source pack that I have. Weird.

Point is, if you are feeling bored you could try to modify the sources to properly support your 4-floppy controller. But I'm guessing it won't be very easy, especially if it lacks documentation and actually needs its own BIOS extension installed to work. On typical PC FDCs the format program is very simple to use, just give it a parametery like F144 and it will know what to do. Of course you can also specify sectors, cylinders and head count with separate parameters if you want to play with those.

Well, I'm not sure what's exactly wrong - DiskDupe seems to directly access the FDC, and works fine with "Standard" setting:

FDFORMAT, however, fails even when trying the standard 1.2 MB format:

With 800.COM loaded, the standard format also fails.
VGA-COPY can't see A: and B: drives at all.

If you can lie to diskdup then, I'd just try duplicating a blank 1.44mb disk onto the 1.2mb drive.

(That is, lie to diskdupe / change its options to lie about destination drive type, pop a fresh, clean, formatted 1.44 in the source drive, then 'duplicate' it.)

wierd_w wrote on 2024-12-21, 12:37:

If you can lie to diskdup then, I'd just try duplicating a blank 1.44mb disk onto the 1.2mb drive.

No, can't format a disk in the fake 1.44 MB drive...

What about NFORMAT? It can blank-format diskettes in different standard and custom formats.

Grzyb wrote on 2024-12-21, 13:14:

No, can't format a disk in the fake 1.44 MB drive...

DD might have the same limitation as DOS does, try some other tool, IMD perhaps? It can format too, but only to more-or-less standard PC requirements.
See, with DOS (the newer ones, 5+, it might just work on something older like 3.3) the issue is again the media byte. DOS will not even let you bypass it with /U. But a quick way to work around it is a strong magnet, just erase enough of the sector 0 data to prevent it from being readable and set the 1.2 drive in BIOS as 1.44. And now that "cleaned" media will format fine even with DOS format program.

Can the freedos format command have said check commented out?

Oh!

or just use debug to load the sector, edit the Media Descriptor Byte, then write it back.

Debug dont give 2 shits.

analog_programmer wrote on 2024-12-21, 13:39:

What about NFORMAT? It can blank-format diskettes in different standard and custom formats.

No luck, even with the standard 1.2 MB format:

Deunan wrote on 2024-12-21, 13:41:

try some other tool, IMD perhaps?

Some progress - IMD did complete the format with 18 spt.
But IMD-formatted diskettes aren't meant to be normally usable, right?
It just does LLF, filling the sectors with E5 byte, but doesn't write proper DOS boot sector, FATs, root directory.

After the 18 spt format, I tried to write a 1440 KB image to it, but:

Really, there's something strange about this FDC...

Grzyb wrote on 2024-12-22, 06:15:

But IMD-formatted diskettes aren't meant to be normally usable, right?
It just does LLF, filling the sectors with E5 byte, but doesn't write proper DOS boot sector, FATs, root directory.

Correct. IMD should be able to write an image to a floppy it formatted though. But...

Grzyb wrote on 2024-12-22, 06:15:

Really, there's something strange about this FDC...

Actually it's also about the format. So the magnet method probably won't work either. The floppy in 5.25" drives spins faster than in 3.5" drive (360 vs 300 rpms) so you can't fit 18 sectors on it without making the gaps shorter. These are gaps between each header and sector data, and next header, as well as the very first and last gap (PC doesn't really use track headers). Too small gaps will make over-writing more difficult on some systems, the FDC won't be able to re-sync and decode data. Too big gaps (standard 1.44 tried on 1.2 floppy) simply won't fit on the track, you'll wrap around and overwrite your own format. Some FDCs might be able to detect that when seeing index pulse too soon, some will not notice but such "formatted" disk won't be usable.

I suspect your FDC has some differences in how the commands for the format are sent, maybe even it has two operation modes in which it emulates PC formats and interface but doesn't allow such tricks, and the native one that is so different it requires extra BIOS ROM to proprely support the chip. You should try tro create a custom 3.5" format (those around 1.6-1.7 MiB) on a standard controller and see if your FDC can work with such floppies. Because if loading the required TSR does not work then the only thing that will work is probably that 1.44 format on 1.2 media, due to how similar it is to native 1.44.

Deunan wrote on 2024-12-22, 10:42:

The floppy in 5.25" drives spins faster than in 3.5" drive (360 vs 300 rpms) so you can't fit 18 sectors on it without making the gaps shorter. These are gaps between each header and sector data, and next header, as well as the very first and last gap (PC doesn't really use track headers). Too small gaps will make over-writing more difficult on some systems, the FDC won't be able to re-sync and decode data. Too big gaps (standard 1.44 tried on 1.2 floppy) simply won't fit on the track, you'll wrap around and overwrite your own format. Some FDCs might be able to detect that when seeing index pulse too soon, some will not notice but such "formatted" disk won't be usable.

VGA-Copy cares about the gaps.

Disruptor wrote on 2024-12-22, 13:02:

VGA-Copy cares about the gaps.

All the software that allows tricky format does I think, but the issue here seems to be hardware related (4-floppy controller installed).

Grzyb wrote on 2024-12-22, 06:00:

No luck, even with the standard 1.2 MB format:

This is very strange behavior. Is this picture after 1.2 MB standard format tryout on a 5.25" diskette?

I'm using NFORMAT to format 3.5" diskettes after "bad sector curing" with neodymium magnet and I've never seen any problems with standard format for 1.44 MB diskettes. I have to dig out a 5.25" floppy disk drive to test some 1.2 MB diskettes.

I may repeat something already said in this thread, so just ignore this post in this case.

You can fit 18 sectors of 512 bytes on a "1.2MB" medium (often, they were labelled 1.6M unformatted), yielding 1.44 at 80 sectors per track. To get to this result, you need to tell the floppy control to use an extremely small gap between the sectors. Remember: There is 20% less "space" on that medium, because it turns at 360rpm instead of 300rpm, but the floppy controller takes the same time for each bit. That's why you can fit 18 sectors easily on a "1.44MB" medium (or "2.0MB unformatted"), but they just fit a 1.2MB medium. Any tool that claims to do 1.44MB on 5.25" HD knows how to format with an extremely small gap. The gap is so small that when reading or writing one sector, the subsequent sector header passes the head before the floppy controller is able to read the sector ID, so after processing one sector, the controller will miss the next sector. If two physically adjacent sectors would need to be read one after the other, it takes a whole revolution of the medium until the second sector is detected by the floppy controller. To combat that effect, 1.44-on-1.2 is formatted using "interleave 2": The first sector on the medium is sector 1, the second one is sector 10, the third one is sector two and so on. This enables the track to be read in two revolutions of the medium.

When using unconventional formats, you may need to fight with two different pieces of software. One of them is DOS. While old versions of DOS may assume a fixed geometry based on the media type byte, all "recent" versions of DOS use the explicit geometry specification in the boot sector, so DOS need not be fought, even for 1.72MB-on-1.44MB. The other piece of software you may need to fight with is the BIOS. This is what FDREAD and VGAREAD (basically the same idea) tackles: The BIOS has a floppy parameter table (which was supposed to be fixed for "the drive type used on this system", introduced with the first revision of the PC BIOS), which specifies the number of sectors per track. This number of sectors per track is sent to the floppy controller on every read and write command. If you let an AT BIOS do its thing, it will automatically install a parameter table that fits the current medium in the current drive. The AT BIOS will peek at the CMOS for that. If you set it to 1.2MB, it can (IIRC will) install a parameter table explicitly stating 15 sectors/track, making 1.44-in-1.2 unreadable. If you lie to the BIOS by setting the drive type to 1.44MB, you should be able to read 1.44-in-1.2 and standard 1.2MB media, but you will lose the ability to read 360KB media.

Furthermore, while DOS (mostly?) does not care about the drive type in the BIOS for regular operation, the DOS format utility does. Setting the drive type to 1.44MB for a 1.2MB drive will make DOS format do entirely wrong things, as it assumes the track is 20% "longer" than it actually is. So while lying in the setup may enable reading and writing 1.44-on-1.2, it makes formatting more difficult.

Or just use Herne data systems maxidisk.

https://www.herne.com/mdisk1.htm

Formatted and used 1.4mb 5.25’s all day everyday moving data back and forth from school, always worked, didn’t need anything loaded to read the disk, simple utility to format

rmay635703 wrote on 2024-12-22, 18:51:

Or just use Herne data systems maxidisk.

https://www.herne.com/mdisk1.htm

Which one you've used - MAXIForm (DOS), FreeForm (DOS) or MAXI Disk (win)? And they're all shareware, but with such an old abandoned site it seems like there will be no current option for obtaining a full registered/paid product.

Deunan wrote on 2024-12-22, 14:30:

Disruptor wrote on 2024-12-22, 13:02:

VGA-Copy cares about the gaps.

All the software that allows tricky format does I think, but the issue here seems to be hardware related (4-floppy controller installed).

VGA-Copy even manages the gaps in a way that tracks can be read faster.
It is likely that the 18 sectors of an 1.44 MB disk have less gaps inbetween but a higher gap between last and first sector.
And the starting position of the following head/track are optimized in that way that there will be less time until the first sector approaches.

To read a whole 1.44 MB disk there may be differences in the region of 10 seconds!

And VGA-Copy 6.25 even is freeware.

Disruptor wrote on 2024-12-23, 08:11:

And the starting position of the following head/track are optimized in that way that there will be less time until the first sector approaches.

Format skew. It's calculated based on the fact that a step on a modern floppy drive takes 3ms, so sector 1 should appear after that time. Of course that will only work if you need sector 1 of the next track and not something else. On a slow CPU the time might be longer to account for any data processing by the OS, so an XT machine would more than likely need different (bigger) skew than AT or even 386+.
Frankly there are other possible optimizations like sector interleave (again only for really slow machines) and perhaps skew between heads 0 and 1, of one sector. That last part is questionable, depends on the format and the size of last gap really.

However once your CPU is fast enough, let's say 486DX2 or better, and the OS can handle DMA properly (Win9x or Linux), the floppy controller is so slow that no matter the format there will be enough processing power to always catch the sector you are looking for on the first rotation. All these trick are pretty much DOS only.

Deunan wrote on 2024-12-26, 11:43:

Format skew. It's calculated based on the fact that a step on a modern floppy drive takes 3ms, so sector 1 should appear after t […]
Show full quote

Disruptor wrote on 2024-12-23, 08:11:

And the starting position of the following head/track are optimized in that way that there will be less time until the first sector approaches.

Format skew. It's calculated based on the fact that a step on a modern floppy drive takes 3ms, so sector 1 should appear after that time. Of course that will only work if you need sector 1 of the next track and not something else. On a slow CPU the time might be longer to account for any data processing by the OS, so an XT machine would more than likely need different (bigger) skew than AT or even 386+.
Frankly there are other possible optimizations like sector interleave (again only for really slow machines) and perhaps skew between heads 0 and 1, of one sector. That last part is questionable, depends on the format and the size of last gap really.

However once your CPU is fast enough, let's say 486DX2 or better, and the OS can handle DMA properly (Win9x or Linux), the floppy controller is so slow that no matter the format there will be enough processing power to always catch the sector you are looking for on the first rotation. All these trick are pretty much DOS only.

No, disks formatted this way also read faster on 9x and NT.
On a standard floppy, not a LS-120.

Or is there a way to read a whole track at once with DMA?

It's been quite some time since I did any low-level FDC work, and I mostly deal with older controllers. But 765B can transfer multiple sectors with one command as long as those are on the same track. Note, track not cylinder. So heads 0/1 are different tracks.