Some performance specs:
- I have not figured out how to block/deblock 128 byte/sector of CP/M into 512 byte/sector of the CF, so each 128-byte CP/M sector takes a full 512-byte CF sector--very wasteful, something to work on in the near term.

plasmo wrote on Sun, 02 July 2017 16:52

Some performance specs:
- I have not figured out how to block/deblock 128 byte/sector of CP/M into 512 byte/sector of the CF, so each 128-byte CP/M sector takes a full 512-byte CF sector--very wasteful, something to work on in the near term.

CF and SD cards are not designed to expect a lot of rewrites of the same block except in the FAT area with a DOS style fs. From a performance and a card life point of view you may well be better off just using 128 bytes of each block rather than being clever in the BIOS code.

CP/M 3 supports other sizes including 512 byte blocks but this never made CP/M 68K as far as I know because CP/M 68K had a rather brief and very unsuccessful life, being slaughtered in the market by OS/9 68K, and turning into Atari TOS.

.

Besides, I would not worry too much about excessive writes. Compared to more modern OSes CP/M disk writes are sparse.

Rienk

The improvement is much smaller than my recollection of the RAM drives speed-up. It is hardly worth the efforts except for the saving on CF write wearing. Perhaps CF accesses are particularly efficient and perhaps CP/M does the minimum disk I/O as you've pointed out.

I could argue this both ways. If you update 128 bytes at a time randomly you could potentially have 4 times the writes to the same block. You really only win if writes are sequential (which happens a lot). If you had a deep cache of blocks in memory you could gain some advantage but copy on modify could not predict either, so really you are doing more potential writes to the same block then 128 bytes per block. I prefer the packing as I don't like leaving holes on the disk and I doubt the wearing of the card is going to be a major problem in my life time of usage.

plasmo wrote on Thu, 13 July 2017 09:13

The improvement is much smaller than my recollection of the RAM drives speed-up. It is hardly worth the efforts except for the saving on CF write wearing. Perhaps CF accesses are particularly efficient and perhaps CP/M does the minimum disk I/O as you've pointed out.

Since all accesses are being gated by the 8MHz clock of your CPU, I'd expect both your slow SDRAM and your fast CF to have a similar speed. I'm guessing that if you added up the cycles for accessing the DRAM that they'd come out pretty close to the number of cycles accessing the CF. Looks like the DRAM wins by one or two cycles.

RAM disks really made a difference when our 486/Pentiums running at 66MHz were trying to access our really slow MFM drives. Or even worse, floppy drives!

At 8MHz, everything is equally slow.

yoda wrote on Thu, 13 July 2017 15:21

I could argue this both ways. If you update 128 bytes at a time randomly you could potentially have 4 times the writes to the same block. You really only win if writes are sequential (which happens a lot). If you had a deep cache of blocks in memory you could gain some advantage but copy on modify could not predict either, so really you are doing more potential writes to the same block then 128 bytes per block. I prefer the packing as I don't like leaving holes on the disk and I doubt the wearing of the card is going to be a major problem in my life time of usage.

The CF interface protocol requires that every sector read or write move multiple of 512 bytes of data to and from the CF data register. I have not figured out how to gracefully abort the data transfer after 128 bytes. As far as I can find, there are no 'transfer abort' command I can issue. Because of that I'm transferring 512 bytes of data for each CF sector access whether I need 128 bytes or 512 bytes. Even with the simple algorithm without blocking and deblocking, I'd write 128 bytes of actual data followed by 384 zeros to satisfy the CF internal state machine. This is why the amount of write wear is the same whether a CF sector contains 128 bytes of meaningful data or 512 bytes.

Isn't that what you're essentially doing with your SPI flash? You could have just as easily read the boot sector off of the CF and copied it to 0x0 before releasing RESET.