Newsgroups: comp.sys.cbm Path: utzoo!utgpu!jarvis.csri.toronto.edu!godzilla.eecg.toronto.edu!leblanc From: leblanc@eecg.toronto.edu (Marcel LeBlanc) Subject: SEQ file access speedup (was: Simultaneous disk & RS-232 access) Message-ID: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu> Summary: Not really worth the trouble Keywords: custom serial I/O, IEEE-488 drives, RAMDOS Organization: EECG, University of Toronto References: <738@csd4.milw.wisc.edu> <7023@killer.DALLAS.TX.US> <765@csd4.milw.wisc.edu> <89Feb3.212709est.2386@godzilla.eecg.toronto.edu> <779@csd4.milw.wisc.edu> <89Feb7.220647est.2663@godzilla.eecg.toronto.edu> <826@csd4.milw.wisc.edu> Date: Fri, 10 Feb 89 15:05:51 EST In article <826@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >]drives. When I decided (2 yrs ago) that 1571 drives didn't give me enough >]storage, I considered getting an IEEE drive, but then I learned about the >]new 1581 drives that had been announced. I managed to get two from >]Commodore, and I'm glad I did. It loads much faster than IEEE drives (my >]assembler LOADs include files, taking maximum advantage of load speed), and >]has good storage capacity (800K vs 1M/floppy for 8250). > >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. 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! 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). 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). 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... Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn