I thought about that in the 80's when I had z80 computer, but the computer died
due to a power supply failure, before I could find a drive.
The main reason I am emulating tape, is that is I don't need a file directory like disk
but have a simple stream of text data ended by a EOF. A tape mark indicates a file
name, and the next file block #.

I am trying a version with, fictional dual 8" floppies. 80 track, GCR 6 sectors of 768 9 bit bytes.
This works out to 360Kb per disc, with a 480 byte fat table.
PS.
I just realized that memory is in words, not bytes so I need to have 32kb blocks with 4k dram
and 12+ slots on the mother board, ~ 1975. This lets me have 64Kb memory program and 24K
+rom for the OS and buffers,

Is that the same number of sectors per track? Or does it vary based on distance from the centre? IIRC Commodore disk drives varied, increasing the sectors per track further out. But that was '80s. Does mean the read amplifiers need to be more flexible.


Is this for something similar to an S100 type bus? 12 slots seems like a decent sized computer. Mini? computer.

My block device reads 512 8 bit bytes, or 256 16 bit words. I use 9 bits of the 16 bit word for one byte of data, thus 1 sector is 256 9 bit bytes. Using 256 9 bit sectors,I play to see what fits on 8 bit media. I use block numbers rather than head/track/sectors so IO is abstract rather real devices.

For a small computer, you had DECTAPE,8 " floppies or a IBM 2315 disk cartridge. The only file system I can use is FAT
style file system for the simple reason I have a Algorithm for it, and I can write it assembler so I can boot strap the system.
This I need to play with numbers in how to fit it all.

Since I am emulating a retro design, I want to keep the technology in the 70's ballpark, thus 12+slots and
20 amp power supply.

I would like to use CP/M but I don't know how the internal stuff works.

Roughed in the code the code for a FAT file system. Arggg code bloat make that, a FIT file system.
I now use 4K? of ROM and 24 Kb of ram, mostly the fat table and block buffers..
Reading about the early Algol compilers and every thing used Mag Tape,
and the machines ran off drums, I may develop another language rather than small-c, that takes up too much space.

After reading a bunch of PDP-8 programs, I decided to add a increment/decrement instruction
and remove the indirect instructions and rearrange microcode decoding. Jump always jumps
regardless of the sense bit. I am writing a very tiny subset of C, as a two pass compiler,Pass one
will do simple string processing and pass 2 the real compiler. I hope to be-able to generate ROM able
code so I can write a file system. Doing it in assembly is taking too long to revise,

Is your CPU similar enough to the PDP8 to make porting programs easy?
I am thinking about small file systems too. But written in 68k assembler, or possibly C. 'C' code takes two or three times as much space though.

My cpu is more modern,I have a SUBTRACT instruction.
I have byte addressable memory, but all the PDP's other than the 11 are word addressable machines, thus I can't even emulate
one.
The problem is still the chicken and the egg one, every thing needs a full blown C compiler, to write A C compiler and or a OS.
Ben.
As side note I got the first pass of my compiler working,the easy part, ask for files to compile and generate a output file.

Cleaned up the IRQ service and fixed halt. Replaced LEA with SWP a (x). This gives me a atomic instruction for later use.

Somehow a bug with subroutine calls crept in. Rolled back the extended op codes to NOP's and simple IRQ,
Cannot resume after halt.Slowly updating the bios for file IO.