leblanc@eecg.toronto.edu (Marcel LeBlanc) (02/15/89)
In article <7124@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >in article <89Feb10.182100est.2732@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) says: >> 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. That's interesting. But I covered this topic in another posting, so I won't go into it again. >> 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). Another great idea (using a RAM to replace the kernal ROM)! If only it didn't require the jumper it would have a much better chance of widespread commercial success. >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). > >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:. Actually, I am moving development onto the Amiga! DASM is one of the most likely assembler choices, but I have found a few others. I won't be using RAM: though, probably VD0: or RAD: or just an FFS hard drive partition. >> 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.... Me too! :-) 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