Add binay file to img file for booting

[JohnElliott]

Here's a scenario where you wouldn't just dd a disk image to a drive: You've got a disk image of a 320k ( 40 cylinders, 2 heads, 8 sectors/track) FAT12 floppy and you want to write it to a 3.5" disk, using a USB drive that supports 720k media. You'd need to write 512 dummy bytes after every 8 sectors, to ensure everything ended up where the target computer was expecting to see it. 160k floppies left as an exercise for the interested reader.

 

[segaloco]

Okay that actually makes sense if the physical geometry of the output device/media differs from the nature of the input image. In the case of generating an image on the fly though this would simply suggest start with the proper geometry/format, which means we're probably saying the same thing just from different angles. For a real image of the same geometry though I would hope a simple write of the image would suffice, but I guess it depends.

 

[Svenska]

Well, the sector structure on a floppy is written into its magnetic coating using the same technology as the sector data itself. It will weaken over time and can be damaged by magnetic fields, so reformatting floppy disks - even with the same format as is already there - is highly recommended. It's also a great opportunity to detect whether a given sector can hold data at all.

So again, formatting before writing is advisable; the former requires controller cooperation.

 

[MiaM]

But also, with a controller capable of writing a full track with arbitrary data + headers you get the (re)formatting for free. One spin = format+write at once, next spin = verify.

Going off on a tangent, it feels like non-Shugart/PC style floppies maybe reads/writes both sides at the same time? Or at least reads both sides? Seems like a low hanging performance fruit to me. What I think might not work would be to write one side while reading the other, perhaps.

 

[Svenska]

But also, with a controller capable of writing a full track with arbitrary data + headers you get the (re)formatting for free.

Sure, but we were talking about PC-style and USB/UFI hardware. An Amiga or 1541 could do substantially better...

Going off on a tangent, it feels like non-Shugart/PC style floppies maybe reads/writes both sides at the same time?

You only have one set of wires for read data, write data, write enable. The selection logic in both the controller and the drive is built around that, and they both only handles a single data stream.

Accessing both sides at the same time would require you to add (or extend) the floppy controller, duplicate the signal conditioning inside the drive, and add a second data path. After that, you successfully turned your floppy mechanism into a two-track tape drive.

 

[doshea]

I guess but I would still think at least for storage devices ultimately you're looking at a linear array of bytes from the logical perspective. That logical array of bytes may be blocks with control data, may be sectors, something else, but in the end I want write(2) to put the number of bytes I say at what would in the physical structure of the device represent the logical address <xyz>, because my expectation would be to in another breath ensure a file descriptor seeked to the same address in that logical array reads back that physical data from the media.

Even with tapes I seem to recall that early attention was given to ensuring the magtape drivers in UNIX could, however inefficient, treat magtape like a random access character device. Sure maybe this means reading out a whole block/record, editing it, rewinding the tape, and recording the whole record again just to edit one byte,

I don't know a whole lot about tape, but I found this at https://en.wikipedia.org/wiki/End-of-file#tape_mark because I thought tape marks might make a counter-example:

In the ANSI X3.27-1969 magnetic tape standard, the end of file was indicated by a tape mark, which consisted of a gap of approximately 3.5 inches of tape followed by a single byte containing the character 0x13 (hex) for nine-track tapes and 017 (octal) for seven-track tapes.

https://en.wikipedia.org/wiki/Magnetic-tape_data_storage#IBM_formats says something about NRZI encoding, so I suppose that sure, you could maybe still have a linear array of bytes, as you suggested, and we could say that our interface to this tape presents one byte per 1/1024th of an inch or something, and:
- if the first byte is 0 and the second is a 1, then the actual data presented to the user should be a 0
- if the first byte is a 1 and the second is a 0, then the actual data presented to the user should be a 1
- if there is a run of 3500 or so zeros followed by the 0s and 1s that make up 0x13 then you found a tape mark

Hopefully my encoding scheme based on vague memories isn't too confusing for the purposes of this conversation.

I think that in practice, you wouldn't want to do this, because:
- you probably also need to detect the bit transitions to do clock recovery in hardware; and
- it would be slower to have twice the number of bits sent to the CPU and then translated back into the desired number of bits, particularly for older machines.

Others might have better arguments than me, because I don't really know too much about how this kind of hardware would work.

I think though that ultimately you're not really looking at a linear array of bytes, but analog signals (gross!).

 

[MiaM]

Sure, but we were talking about PC-style and USB/UFI hardware. An Amiga or 1541 could do substantially better...

USB drives could do things whichever way they want, and thus it might not be necessary to first format and then write when writing an image using some USB drives. Perhaps wort testing what happens with blank or non-PC-formatted disks for each USB drive anyone happen to have.

re the 1541: The sad thing is that although the actual disk interface hardware and the CPU can write a full track of arbitrary data, each track contains more data (even when ignoring headers and whatnot) than the drive has RAM, so you either need a RAM expansion or a parallel connection to a data source (C64, XUM1541 or whatnot) to write a full track of arbitrary data. Or add more RAM. The German magazine 64'er had a DIY description for adding way more ram to a 1541, IIRC their expansion could add up to 40k in 8k banks, and you could populate SRAM or EPROMs and also select that two 8k banks would either be in the empty memory space or switchable to replace the stock ROMs. It's almost like they encouraged people to use pirate copies of disk speedup add-ons

You only have one set of wires for read data, write data, write enable. The selection logic in both the controller and the drive is built around that, and they both only handles a single data stream.

Accessing both sides at the same time would require you to add (or extend) the floppy controller, duplicate the signal conditioning inside the drive, and add a second data path. After that, you successfully turned your floppy mechanism into a two-track tape drive.

That's why I wrote "non-shugart/PC style" drives, i.e. drives that don't use the regular usually 34 pin interface. Either back in the days if some company bought drive mechanisms without the matching electronics, or nowadays it might not be any significant price difference between having two sets of read/write electronics vs just a MUX for the two heads in a USB drive. Faster USB drives (and faster drives in for example some digital cameras) probably just used a higher RPM though, but still.

 

[Svenska]

Perhaps wort testing what happens with blank or non-PC-formatted disks for each USB drive anyone happen to have.

Given the current state of most media, I consider the verification done as part of formatting worth doing anyway.

That's why I wrote "non-shugart/PC style" drives, i.e. drives that don't use the regular usually 34 pin interface.

Sure, but if you're going to replace everything (interface, controller and drive electronics) to get a dual-track floppy drive, you should have designed a tape drive instead. Gets you more tracks for the same amount of work.

Your idea is theoretically possible. As is taking a motorcycle, adding two wheels to improve stability, a roof for weather protection, and a few other gimmicks - but definitely not choosing a car.

 

[MiaM]

Given the current state of most media, I consider the verification done as part of formatting worth doing anyway.

That verification is technically optional although I think that in almost all cases verification is done when formatting disks on a PC. Either way, you can do the verification after doing a combined verification+data write.

Sure, but if you're going to replace everything (interface, controller and drive electronics) to get a dual-track floppy drive, you should have designed a tape drive instead. Gets you more tracks for the same amount of work.

Your idea is theoretically possible. As is taking a motorcycle, adding two wheels to improve stability, a roof for weather protection, and a few other gimmicks - but definitely not choosing a car.

Or remove the front half of a VW beetle and add the front wheel and whatnot from a motorcycle and call it a trike

But, at least at some point in time there were plenty of companies that would had been able to do all electronics for disk drives, but absolutely not the mechanics, and one of those could had done a both-sides-at-the-same-time drive using existing mechanisms.

 

[Svenska]

But, at least at some point in time there were plenty of companies that would had been able to do all electronics for disk drives, but absolutely not the mechanics, and one of those could had done a both-sides-at-the-same-time drive using existing mechanisms.

Yet none bothered to access both sides simultaneously, which is enough I need to know about the idea.

 

[krebizfan]

Yet none bothered to access both sides simultaneously, which is enough I need to know about the idea.

The X10 wrote to both sides at the same time. Even has a Wikipedia page. https://en.wikipedia.org/wiki/X10_accelerated_floppy_drive Unless one was copying a lot of disks, there doesn't seem to be much benefit.

 

[MiaM]

Yet none bothered to access both sides simultaneously, which is enough I need to know about the idea.

Do we actually know that no USB floppy, or for that sake other "non-PC floppies" didn't do this?

Thinking about it, in particular digital cameras that used floppies could had been made to write both sides at the same time, but only read one side at a time, as it's much easier to write than read (no need to sync up to existing timing and whatnot when writing) and also a camera likely spends more time writing than reading disks.

 

[krebizfan]

Do we actually know that no USB floppy, or for that sake other "non-PC floppies" didn't do this?

Thinking about it, in particular digital cameras that used floppies could had been made to write both sides at the same time, but only read one side at a time, as it's much easier to write than read (no need to sync up to existing timing and whatnot when writing) and also a camera likely spends more time writing than reading disks.

Interleaving a data stream to write on both heads at the same time would also require reading from both heads to get the data back. Rather tricky and unlike any typical floppy file system.

Copying a disk makes it easy to use both heads; write out each track as the matching head reads it. Most other tasks would only require using a single head at a time. The 2X and 4X USB floppy drives already handle the speed issue successfully, even if only a single head was used at a time.

 

[MiaM]

You could verify one side at a time. And sure, it wouldn't work if you had to write individual sectors, only if you would write full tracks. But for a disk that isn't very fragmented, which would be the case for a disk containing a few jpg's, you'd most likely end up being able to write full tracks for most of the file, speeding up write times.