Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!texbell!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.sys.cbm
Subject: Re: SEQ file access speedup (was: Simultaneous disk & RS-232 access)
Message-ID: <7124@killer.DALLAS.TX.US>
Date: 12 Feb 89 21:07:46 GMT
References: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 111

in article <89Feb10.182100est.2732@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) says:
>>Which is still only a marginal speedup, considering that file based
>>operations are not enhanced by such devices.  (Since that's the major
>>type of operation I need around here, that's what I look at.)  BLITZ!
>>isn't speeded up at all by FastLoad... hehehe
> Let's keep things in perspective here.  Although it's possible to speed up
> sequential file access with 'transparent' speedup software, you will never
> get as much of a speed increase as is possible on LOADs.  This has less to
> do with the transfer protocol, than with the LOW PERFORMANCE limitations of
> the C64 kernal.  To remain compatible with existing software, speedup
> software must intercept OPEN, CLOSE, CHKIN, CHKOUT, CHRIN, GETIN, & CHROUT.
> You can't expect that much speed if you call a subroutine for every byte of
> a transfer.  

     Take a look at the C-128's Kernal, and, specifically, the
burst-mode load routines (esp. the subroutine at $f4C5). It gets that
speedup despite jsr'ing STASH for each byte to store the data into the
proper bank of RAM.
     For an early version of some hardware later discarded due to
various problems, I didn't have burst-loads implemented yet, but had
standard fast serial working. I called LOAD. It had some speedup,
about equivalent to what you get from an old Epyx fastload cartridge,
but wasn't a real speed demon. Later I re-wrote LOAD to use
burst-load. Loading a large file (I forget the size, somewhere around
100 blocks) dropped from 18 seconds to 5 seconds between the two. The
main difference was the protocol.
     It seems obvious to me that the main reason fast serial isn't as
fast as burst mode is the character-by-character handshaking taking
place, not subroutine overhead. So, if you had a software product that
read 256 bytes worth of SEQ file data into a buffer, it would probably
speed up SEQ file access considerably -- although not as fast as
LOAD'ing, since there IS overhead involved in reading from a buffer
(e.g. see the 1750 REU example below).

> For example, consider LOAD vs. sequential read on IEEE-488 drives, or C128
> burst vs. fast serial. 

Curious, I just wrote a simple benchmark for the C-128. All it does is GETIN
from a file until it gets to the end. It took 17 seconds to read a 98
block file, or about the same as it took to LOAD the exact same file
off of one of my SFD-1001 IEEE drive (using the Skyles IEEE Flash,
admittedly not the fastest IEEE interface). This is about
1.3kbytes/second -- not slow at all, considering that the 1541 is
straining to do 400 cps. The IEEE interface doesn't do anything
special for LOAD'ing -- it just JSR's ACPTR repeatedly and stashes it,
just like the ordinary LOAD routine (in fact, it IS the ordinary LOAD
routine -- totally unmodified).
     Then I tried the same thing using RAMDOS and the 1750. 6 seconds
burstloading off of 1571. 7 seconds reading using RAMDOS (loading
using RAMDOS is just about instantaneous, using the DMA chip).

> Before Eric Green decides to flame me :-), I should point out that I haven't
> forgotten that block transfers can be hidden from applications
> software.

Who me? Flame? ;-). Hiding block transfers would be especially useful
for the 1750, because for byte-at-a-time transfers it's reading single
bytes instead of doing a DMA transfer of 256 bytes & going from there.
Unfortunately, there's not 256 bytes free anywhere to use for such a
buffer :-(.

> For devices like the 1541/71/81, it's quite reasonable to expect speedup
> software to transfer pieces of a file in blocks, then read from this buffer
> when a call is made to CHRIN or GETIN (same for CHROUT on write).  This
> would have been great in the early days of the C64 & 1541 (my GUESS, 3-3.5x
> speedup)!  But today, too much software bypasses CHRIN/CHROUT to use
> ACPTR/CIOUT directly.  

It could be done. But you'd have to do one of two things: Illegally
copy CBM's ROM & modify it, or have RAM and "patch" it. The latter
would be expensive, at least at current prices (32Kx8 static RAM is at
around $14 right now). After you have a patched ROM image, it's fairly
easy to do hardware tricks to swap it into place of the ordinary ROM
(but it DOES require at least one jumper into the inside of the
computer). 

In any event, there is STILL a lot of software that uses
CHRIN/GETIN... if I had the fastloader expertise to do it, I'd give it
a try just to see how much of a speedup it was.

> So what was the point of this posting?  Just that, if the software you use
> has to do sequential file reads or writes, you are limited in how much it
> can be speeded up without re-writing it.  

True. I suspect that the REU timing is about the maximum speed you can
get using byte-at-a-time. That time truly reflects JSR overhead. 

> least twice as fast as IEEE can load.  A complete assembly, which requires
> 2 passes through 600K of tokenized source, takes about 12 mins.  Using seq
> reads on a C64 would probably take about 1.5 hours, or 50 mins using IEEE
> drives (I haven't timed these, so they are just guesses).

600K?! (wow... boggle-mode activated!). Using HCD128 and the 1750 REU,
using SEQ files, it'd take about 20 minutes (if you could fit it on
the REU!). Now, on the Amiga, using DASM (a real speed-demon).... I'd
be surprised if it took longer than 2 minutes out of RAM:.

In any event... nobody's denying that LOADing will generally be faster
than READing. Just that SEQ file reading can be speeded up much more
than you imply.

> What we really need is a new OS for the C64...

Amen! But who's going to bother, when they can just go out and buy a
"real" computer? Today was the first time I'd touched my 128 in over a
week.... 

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //  ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849     |
| \X/              >> In Hell you need 4Mb to Multitask <<                  |