3 ms·

Yeah, but the CP/M had floppy disks and a more managable address space :) give it a shot, it could work! Aside: at one point I was thinking about trying to por

Yeah, but the CP/M had floppy disks and a more managable address space :) give it a shot, it could work! Aside: at one point I was thinking about trying to port CP/M to these calcs...

kragen 7y ago
Floppy disks are terrible. In NOR you can clear a single bit, and how long does that take? The least you can write to a floppy is a whole sector, normally 512 bytes, and the seek time is close to a million microseconds, although the actual sector write time is... well, maybe less than a hundred thousand microseconds. And they make a racket when you do it, too. And write endurance? Floppy disks have write endurance of about 1000 cycles. Their only benefit is that you can take one out and put a different one in. But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. Anyway, there were assemblers that you could fit on a single-sided, single-density, soft-sectored 5¼" disk along with your source code, object file, and "operating system", all in 90K. But things became a lot more practical if you could move up to a dual-drive, double-density system, so you could access two 180K disks at a time. If there was some way to run a reasonable subset of CP/M programs on them, even if it required some hacking of the programs, that would be a significant benefit. I need to think about the problem more.
- zozbot234 7y ago
  > But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. You can just require the user to `umount` the disk before physically taking it out. And if a disk does get taken out before the read/write even starts, the OS can detect this and show a message `You MUST reinsert media $LABEL into drive: Abort/Retry/Ignore?`
  - kragen 7y ago
    I did use an operating system that required you to dismount floppies before taking them out (HDOS) but no popular OS or monitor program had such a requirement. HDOS was targeted at hobbyists and may have had some design features strongly selected against by the market.

Yeah, but the CP/M had floppy disks and a more managable address space :) give it a shot, it could work! Aside: at one point I was thinking about trying to port CP/M to these calcs...

kragen 7y ago

Floppy disks are terrible. In NOR you can clear a single bit, and how long does that take? The least you can write to a floppy is a whole sector, normally 512 bytes, and the seek time is close to a million microseconds, although the actual sector write time is... well, maybe less than a hundred thousand microseconds. And they make a racket when you do it, too. And write endurance? Floppy disks have write endurance of about 1000 cycles. Their only benefit is that you can take one out and put a different one in. But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. Anyway, there were assemblers that you could fit on a single-sided, single-density, soft-sectored 5¼" disk along with your source code, object file, and "operating system", all in 90K. But things became a lot more practical if you could move up to a dual-drive, double-density system, so you could access two 180K disks at a time. If there was some way to run a reasonable subset of CP/M programs on them, even if it required some hacking of the programs, that would be a significant benefit. I need to think about the problem more.

zozbot234 7y ago
> But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. You can just require the user to `umount` the disk before physically taking it out. And if a disk does get taken out before the read/write even starts, the OS can detect this and show a message `You MUST reinsert media $LABEL into drive: Abort/Retry/Ignore?`
- kragen 7y ago
  I did use an operating system that required you to dismount floppies before taking them out (HDOS) but no popular OS or monitor program had such a requirement. HDOS was targeted at hobbyists and may have had some design features strongly selected against by the market.