Path: utzoo!utgpu!news-server.csri.toronto.edu!eecg.toronto.edu!leblanc Newsgroups: comp.sys.cbm From: leblanc@eecg.toronto.edu (Marcel LeBlanc) Subject: Re: Fastloads vs. JiffyDOS Message-ID: <1991Jan2.144725.17549@jarvis.csri.toronto.edu> References: <1990Dec31.204111.24685@evax.arl.utexas.edu> <1991Jan1.063247.18070@DMI.USherb.CA> <1991Jan1.165812.10735@jarvis.csri.toronto.edu> <1991Jan2.030900.8433@evax.arl.utexas.edu> Date: 2 Jan 91 19:47:25 GMT Lines: 65 cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >In article <1991Jan1.165812.10735@jarvis.csri.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >>I am guessing that Mr. Fuzzy Fox has an original C128. The early versions of >>this computer seem to have problems with the power supplied to the Expansion >>port.... >Yes, this is indeed the problem I'm having. In fact, I occasionally >even have trouble simply with the cartridge itself, but the fault lies >in my computer. Say, do you have any ideas on how I can alleviate this >situation? Besides buying a 128D? I wish I did! Seriously, there was a related expansion port power supply problem on the earliest (pre-production?) C128's, and the fix for this apparently also fixes power supply problems in early production models. As you've probably guessed from the fuzziness of my previous sentence, we haven't been able to get information about this fix! However, this is only anecdotal, and Commodore has denied the existence of such a fix, so it probably never existed. >>I understand what he's trying to say, but it isn't true technically. ANY >>loader can be disabled. Most load methods in the past have used one of the >>3 following general methods: >> a) simple call to $FFD5 (LOAD vector) >> b) direct calls to ACPTR for custom format, slow load >> c) completely custom loader >> >>I haven't seen any new games that use approach (b) in a LOOONG time. Case >>(b) is the only LOADing case that a ROM replacement can handle that a >>cartridge can't. No add-on device of any kind will speed up case (c), >>including both JDOS and SS V5! >Well, you are mostly correct there. Surprise surprise, the JiffyDOS >protocol replaces all drive communications with high-speed data >transfer, but as you point out, it will not be as fast as a direct LOAD >routine. However, even a direct ACPTR "load" routine under JDOS will >load at about 3-5 times faster than normal, about on par with the old >Epyx FastLoad. Agreed; this is also on par with IEEE interfaced drives. >... When performing a standard $FFD5 LOAD, 10-15 times >speedups usually occur. The exact load speedup depends on the sector >interleave that the file was saved with. This is where SS can beat >JDOS: SS's 1541 fast-loader loads at the same 15x speed, regardless of >sector interleave. Pretty amazing. Agreed again, but the figure of '10-15 times' speedup with JDOS is only with an optimal interleave. If you try to LOAD a large program that has been saved at the standard 1541 interleave of 10 sectors, you'll get about the same speed up as Epyx FastLoad gives you, which is about 5-5.5 times. If you don't believe this, use the file copier on SS V5 to copy a large file (say, 200 blocks) to a new disk at a 10 sector interleave (the 1541 standard). Then LOAD it with JDOS on and off. This group had a fairly extensive discussion about speed up vs. interleave about 1.5 years ago. Just for kicks, LOAD the same file with your SS V5. >begin 644 .signature >G5&AI >end Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc