Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: SEQ file access speedup
Message-ID: <913@csd4.milw.wisc.edu>
Date: 13 Feb 89 16:26:53 GMT
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: Interstellar Telephone, Telegraph, and Telepath, Inc.
Lines: 102

]>IF you're on a 128, or IF you're on a 64 with some sort of fastloader.
]>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
]
]I can appreciate that file operations are very important to you, and a
]relatively small number of others (maybe 10's of thousands?).  But you
]aren't exactly a typical C64 user, and neither am I.  For the millions that
]use their C64 to play the latest games, all they are concerned about is how
]fast they can start up the game, or how quickly the next level can be loaded
]in.  Speeding up file operations is a more difficult issue.

I agree that FastLoad has it's place....  but it is about as useful to
me as a doorstop is or as a 1670 is.  :-)  My 1541 is too slow to be
useful in any real way.

]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.  You CAN expect much more speed if you call a subroutine to
]transfer large blocks of memory (LOAD & SAVE).  All of this assumes at least
]minimal optimization in the LOAD and SAVE routines.  If these are just
]implemented as loops that repeatedly call the single byte transfer routines,
]then the performance won't be any better.
]
]For example, consider LOAD vs. sequential read on IEEE-488 drives, or C128
]burst vs. fast serial.  The C128 gives you great burst serial speed (LOAD &
]SAVE), but using fast serial instead of slow serial doesn't give you that
]much of a speed increase (maybe 2x).  Since software overhead is the
]dominant factor here, I'll guess that seq read on IEEE drives also gives
]about a 2x speedup.  If somebody has concrete numbers, please post!

I HAD concrete numbers, but rn barfed and then csd4 went down on
Sunday.  I don't have the exact figures with me, but here are
approximations:  A c64 with 1541 took about 1:30 to read 30,000 bytes.
A c64 with BusCard II and 8050 took more like 0:30.  The BusCard II,
by the way, is considered a "slower" interface.  I will try to make
some more tests at home tonight with the 1750 and the fast MSD IEEE
interface.

I used the following routine to do the reading and a stopwatch to time:

ready.
b*
   pc  sr ac xr yr sp
.;ee4e b0 50 00 00 f6
.
., 033c a2 02       ldx #$02
., 033e 20 c6 ff    jsr $ffc6
., 0341 a9 00       lda #$00
., 0343 8d 00 04    sta $0400
., 0346 8d 01 04    sta $0401
., 0349 20 e4 ff    jsr $ffe4
., 034c ee 00 04    inc $0400
., 034f d0 03       bne $0354
., 0351 ee 01 04    inc $0401
., 0354 20 b7 ff    jsr $ffb7
., 0357 c9 00       cmp #$00
., 0359 f0 ee       beq $0349
., 035b 4c cc ff    jmp $ffcc

]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.
]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's also a great idea for the C128 if you can spare
]enough memory to burst load the whole file (or use an REU).

Bad programming form to use calls that one cannot intercept with the
vector table.  :-)

]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.  The main reason I use Buddy 128
](an assembler) is that it LOADs include files (which defaults to burst
]serial), giving me great speed on a 1581.  The SAME speedup factor (10-12x)
]is possible on the C64 using software only (with 1541/71/81)!  This is at
]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).

That's why I refuse to assemble/compile on or work with 1541's.  The
IEEE drives are "about" five times faster.

]If somebody can suggest a faster method of speeding up seq file accesses,
]please let us know!  What we really need is a new OS for the C64...

How about UNIX on an Amiga 2500?  hehehe
--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)