I agree that the ramdisk improved performance. It was just the
implementations that made the system so fragile once ramdisk was in place.
The usefulness of the ramdisk was limited by its size, and, since I had hard
disks back then anyway, the speed of which was nearly infinite as compared
with the floppies, it didn't improve things very much.
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
typically used a mini-bank switching arrangement on the order of what EMS
used in PC's at one time, which required your system be compatible with it
or that it provide a buffer in lower memory so that the higher memory could
be switched in and out. This became quite taxing in terms of hardware
resources and memory bandwidth.
Ramdisk didn't become interesting until I could copy a whole diskette to it.
Since that was much more easily accomplished with hard disk, I didn't devote
too much time to it.
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.
I seldom used SSSD except for interchange of data. Buffering a whole track
in memory while reading the next meant a fair amount of memory since the
same buffer was used hard disks and floppies. A hard disk track had between
32 256-byte sectors, and 10 1K sectors. With the Lark drive (SMD) it was a
bit more, but I don't remember the details. The sectors were odd-sized.
The software overhead was burdensome only because it had to reserve quite a
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.
Dick
-----Original Message-----
From: Allison J Parent <allisonp_at_world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Monday, March 29, 1999 5:33 PM
Subject: Re: followup: Rinky dink hamfest
><I would mention that I had 128K in each of my Systems Group systems and
><never used it under CP/M. MP/M had a mechanism for cashing in on extra
><memory, but it was awkward at best under CP/M 2.2.
><
><Needless to say, the use of a RAMdisk would speed things up, but unless
><there was an extensive amount of software for managing it, and that took u
><too much TPA, even a RAMdisk didn't help much.
>
>Way off. Caching disks for CP/M-any (especally 2.2) is a huge performance
>boost. CPM suffers from waiting on the disk and often the difference
>between a slow system and a fast one is how the disks were handled. Having
>run ram disks, caches, caching controllers I have studied where the
>bottlenecks are and the most common is the CPU spinning in PIO or worse
>waiting for the sector to come around to do PIO.
>
>the software over head for caching is small. once you go over 128 byte
>sector size yo need a host buffer to deblock it... you can read a whole
>track in and deblock that. Free cache.
>
>Allison
>
Received on Mon Mar 29 1999 - 20:10:02 BST