DaveDDS wrote on 2024-06-23, 17:33:

Ok, I interpreted your original as meaning you implemented unformatted in a .IMD it's perfectly reasonable to implemented it any […]
Show full quote

superfury wrote on 2024-06-22, 09:10:

Well, as UniPCemu handles that, it's actually quite simple: just create the header and define all tracks (40 or 80) without ANY sectors in them.

Ok, I interpreted your original as meaning you implemented unformatted in a .IMD
it's perfectly reasonable to implemented it anyway you want in the emulator.

Just curious though - your descriptions sounds like the number of tracks is pre-defined for an unformatted disk.
How does it handle things like 5.25"s with differing number of tracks (originally formatted in 40 track (360Kish)
drive, and later formatted in 80 track (720Kish) drive - IMD handles this by a "double step" option within IMD
itselfm as a .IMD knows only what tracks exist - not the track density? (I specifically avoided encoding anything
about "type of drive" - that can make it more difficult to retrieve the data if you don't have the drive it wamts -
eg: I can recreate working 8" disk images on a 80 track drive)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Basically when creating a disk image unformatted, you chose from a list of predetermined standard formats right now. That basically just determines the amount of tracks right now. It just writes the header and heads and tracks with FM/MFM type speed, one 'sector' on the track with type #0(invalid I think).
https://bitbucket.org/superfury/unipcemu/raw/ … icio/imdimage.c
Look at generateIMDImage for the specifics.
Stuff like read/write/format is in the module as well.
All based on physical location on the medium of couse (CHS and size(other than restrictions on having to match) is handled at the FDC itself (using physical cylinder, head and sector number (0 through track size) for accessing the image and virtual CHSN within the controller itself (using the read sector ID when passing the cylinder index hole to index hole in documented ways, although that's untimed from the CPU pov, other than DMA transfers being timed together with head seek times, otherwise as fast as a 1 port i/o right now, not having implemented drive RPM other than basic sector transfer timing based on RPM (basically RPM driving track size in sectors times 512 bytes per second (so the data transfer rate is RPM*tracksize*512(4 format I think) bps right now))).
Look at hardware/floppy.c for that(drive index hole and physical 'spin' is emulated at 0ns speeds during read/write commands (look for readsector/writesector for startup/next sector and executeReadData/executeWriteData for after each read/write sector/track data phase (which also enters result phase or restarts the command for the next sector), also performs CHS increment after and writes the sector to disk for writes)).
Actually, thinking about it, format track is sort of to write sector (but compressed data during format) what read track is to read sector in a way(ignoring sector IDs)?

superfury wrote on 2024-06-16, 23:38:

What about read/write sector result phase's sector size result?

That's according to the sector ID, as this is the last sector ID encountered.

Edit: And the FDC FORMAT command's data is the ID's for all the sectors that will be formatted. But the ID's can be whatever, since the FDC just writes them as is. This is how, say, IBM was able to write XDF floppies on a regular FDC.