<I agree that the ramdisk improved performance. It was just the <implementations that made the system so fragile once ramdisk was in place. I have a kaypro with a 2048k ramdisk, it screams and would beat any kaypro hard disk. I also have a 512k Mdrive on s100 and it's plenty big enough and fast. Fragile, neither. <The virtual disk features with which I had contact were pretty memory <hungry, in that they required a fair sized buffer in order to allow speedy <caching of data from the drive from which it was being loaded. They There were some ugly implmentations. The first one I did was in late '80 and was pretty tight. No banking and it left 56k(to the base of the BDOS) for transient programs. <or that it provide a buffer in lower memory so that the higher memory coul <be switched in and out. This became quite taxing in terms of hardware <resources and memory bandwidth. I never ran out of either. <You're certainly right about the observations you made of the effect of <various floppy disk handling factors, e.g. sector skew, on performance. <Since you're probably referring to SSSD floppies, which were not only the <smallest but also the slowest, I can see why you might favor such a scheme By late 82 I was running a 4 z80/6MHz multiprocessor system using CP/M2.2 as the core OS with a task manager added. I've done most all of it at one time or another. I took advantage that statistically the data bus was actually unused between 40-60% of the time! Z80 T1 and T2 states offer very litle in the way of actual transfer activity other than preperation. <The software overhead was burdensome only because it had to reserve quite <bit of memory in order to block and deblock on a track-by track basis. <That's why we didn't use ramdisk. One could manage disk I/O almost <transparently when the disk was spinning at 3600 instead of 360 rpm. Well to deblock you only needed a chunk the size of disk sector and typically that was 256 or 512 bytes, trivial space. The code to do it is under 512bytes. Giving up 1k for a huge increase in performance is worth it. Usually I would bump that host buffer up to at least the same size as the allocation block size, as that meant you could cache a whole allocation block. That usualy being either 2k or 4k. For that I would bank in a small amount of ram in lowmem just for that and generally that was based on the common size chips (2k or 8k x8 rams). later I would do a full MMU for even more space for track buffers. the code to do basic deblock will do any size with ease. The latentcy even at 3600 rpm is low but that assumes DMA direct to ram. most controllers had a small (usually 1-2 sectors) sized buffer and would read to buffer and transfer from there.. added delays. Also those controllers could be driven harder than the usual supplied drivers did for far greater peformance. The bios often used the least efficient means to move the selected 128 bytes to the target address. Considering how often that was done it's a big hit. The average systems did not utilize the possible performance of the z80 even at 4mhz. When 6 and 8mhz parts started to show up they were often idling in loops waiting for something to happen. Spooling printer and keyboard/modem interrupts were often not done. So the user often never saw type ahead or any semblence of concurrency. All of which were possible. If there is a point, CP/M prevented nothing performance wise and usually anything it did offer was not used (it can signal when to flush the cache). Think like forground/background were easily done and there were a few print spoolers that really worked. Allison