scotws wrote:
BigDumbDinosaur wrote:
See below for a little 2692 code to get you started. These defs will also work with the 26C92 but would be incomplete in some respects.
One and the same. Most of their later boxes, before they abandoned proprietary technology in the early 1990s, were built around Motorola 68K MPUs and full-height ST-506/412 hard drive mechanisms. The older hardware was built around bit-sliced MPUs, which was customary prior to the development of the 68K line. The "Point 4" name came from an achievement of the late 1970s, when they had reduced the machine cycle time to 0.4 microseconds, which in 1978-or-so, was something about which to brag.
Interesting historical fact: IRIS (Interactive Realtime Information System) was the model upon which the Lt. Kernal hard drive subsystem for the Commodore 64 and Commodore 128 computers was based. Fiscal Information Systems, who developed the Lt. Kernal during about a year after the C-64 went on sale, was a Point 4 VAR and had detailed knowledge of the inner workings of IRIS. Lloyd Sponenburgh and Roy Southwick borrowed on that knowledge to create the Lt. Kernal DOS. One of the IRIS features that was particularly difficult to emulate was something called polyfiles, which were roughly equivalent the C-ISAM file structure found in UNIX. Fiscal succeeded in implementing the keyed index part of the polyfile design and left it to the programmer to mate a key file with a CBM relative file to create a true indexed database system.
As it turned out, using a relative file was not a good solution for a variety of reasons, one being that reading or writing a record required several individual disk accesses. This was a critical concern because the ST-506/412 hard drive mechanisms of time (mid-1980s) had 30-50 millisecond seek times, very slow compared to a modern SCSI drive's typical 2-3 milliseconds. Also, ST-506/412 devices lacked any intelligence and had to be paired with a SCSI controller card, which had the dubious pleasure of translating SCSI logical block addresses (LBA) into C-H-S internal addresses that matched the drive's geometry. Hence the controller's performance added to the lag between when a disk access was requested and when it was received. When this characteristic of the hardware was combined with the need for multiple accesses per record (which always meant time-consuming seeks, since no such thing as track buffering existed back then), response seemed more like what you'd get from a floppy disk.
I ended up using a custom file structure that was based on the contiguous data file built into the LK DOS, and addressing the file as a large array, using 32 bit integer math to generate a logical block offset in the file that would relate to the notion of a record number. Since the computation of the position in the file was done on the host machine, rather than by read side-sectors on the disk (as was done with relative files), only one disk access was required to read or write a record (using a SCSI feature that permitted the reading and writing of multiple blocks per command). This got record retrieval down to little more than the seek time of the drive. The file structure also allowed locking of records to prevent conflicts on a multiplexed system.
Fiscal essentially duplicated the mass storage aspects of IRIS on the Lt. Kernal, and by the time the final version of the DOS had been released, a C-128 in FAST mode connected to a Lt. Kernal could retrieve data faster than could be accomplished with a 1750 RAM unit, certainly a lot faster than competing units of the time (e.g., CMD).
.