finkel@TAURUS.BITNET (02/13/89)
There has been lately a talk about IEEE drives, and their owner's dislike of turbo disk programs. Well, I have written a turbo program for 8050/8250/SFD1001. It uses all 3 processors ( 2 in the drive, 1 in the C64 ) so it can easily read a full track at a time with zero interleave. The program reads the disk using a nonstandard file format ( that coexist on the same disk with normal PRG/SEQ file ) that uses 256 data bytes per block and continous block allocation on the disk. I have a special copy program that prepares such disks. The program runs on special IEEE cards manufactured by the company on which I work. (these are actually network cards. up to 20 C64's can share the same IEEE drvice ). Speed is much faster than anything possible with any C64.. I think it's faster than the C128 burst mode. I also have a C128 version of the program. Turbo-saving is NOT supported. the only way to create such turbo files is using teh copy program which is written partly in basic and partly in assembly. If anyone is interested, please write me for more details. Udi Finkelstein finkel@taurus.BITNET
leblanc@eecg.toronto.edu (Marcel LeBlanc) (02/14/89)
In article <8902130828.AA09474@MATH.Tau.Ac.IL> <finkel%TAURUS.BITNET@CUNYVM.CUNY.EDU> writes: >There has been lately a talk about IEEE drives, and their owner's dislike >of turbo disk programs. > >Well, I have written a turbo program for 8050/8250/SFD1001. It uses all 3 >processors ( 2 in the drive, 1 in the C64 ) so it can easily read a full >track at a time with zero interleave. The program reads the disk using a >nonstandard file format ( that coexist on the same disk with normal PRG/SEQ >file ) that uses 256 data bytes per block and continous block allocation on >the disk. I have a special copy program that prepares such disks. The program >runs on special IEEE cards manufactured by the company on which I work. (these >are actually network cards. up to 20 C64's can share the same IEEE drvice ). >Speed is much faster than anything possible with any C64.. I think it's faster ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not true! >than the C128 burst mode. I also have a C128 version of the program. It should be faster than the C128 burst mode, because of the greatly reduced overhead required in decoding non-standard sectors! This isn't something unique to IEEE drives, of course. The _STANDARD_ 1541 fast loader on Super Snapshot V4 is FASTER than a 1571/C128 in burst mode (12-15x speedup), and about the same speed as a 1581/C128 in burst mode. Supplied on the utility disk, is a translator program which converts to Turbo 25 format. This is a non-standard format such as the one you described. As the name implies, it achieves 20-25x times speedup over standard 1541. This is for the C64, and is MUCH faster that C128 burst load. 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
finkel@TAURUS.BITNET (02/16/89)
>Subject: Re: turbodisk and IEEE >Summary: Non-standard formats can give much better speed WITH 1541 >Keywords: turbo, non-standard sectors >Message-ID: <89Feb14.155723est.2717@godzilla.eecg.toronto.edu> >Date: 14 Feb 89 20:45:50 GMT >References: <8902130828.AA09474@MATH.Tau.Ac.IL> >Organization: EECG, University of Toronto >Lines: 31 > >In article <8902130828.AA09474@MATH.Tau.Ac.IL> <finkel%TAURUS.BITNET@CUNYVM.CUN >>There has been lately a talk about IEEE drives, and their owner's dislike >>of turbo disk programs. >> >>Well, I have written a turbo program for 8050/8250/SFD1001. It uses all 3 >>processors ( 2 in the drive, 1 in the C64 ) so it can easily read a full >>track at a time with zero interleave. The program reads the disk using a >>nonstandard file format ( that coexist on the same disk with normal PRG/SEQ >>file ) that uses 256 data bytes per block and continous block allocation on >>the disk. I have a special copy program that prepares such disks. The program >>runs on special IEEE cards manufactured by the company on which I work. (these >>are actually network cards. up to 20 C64's can share the same IEEE drvice ). >>Speed is much faster than anything possible with any C64.. I think it's faster > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not true! >>than the C128 burst mode. I also have a C128 version of the program. > >It should be faster than the C128 burst mode, because of the greatly reduced >overhead required in decoding non-standard sectors! This isn't something >unique to IEEE drives, of course. The _STANDARD_ 1541 fast loader on Super >Snapshot V4 is FASTER than a 1571/C128 in burst mode (12-15x speedup), and >about the same speed as a 1581/C128 in burst mode. Supplied on the utility >disk, is a translator program which converts to Turbo 25 format. This is a >non-standard format such as the one you described. As the name implies, it >achieves 20-25x times speedup over standard 1541. This is for the C64, and >is MUCH faster that C128 burst load. Well, you didn't understand me. it seems that I was too conservative.. a. My Turbo is 50% faster than any THEORETHICAL 1541 speedup! my drives reads a 8250 track that contains 27 sectors in one revolution! the 1541 has only up to 20 sectors on a track. even if you will have such a full-track-reader-in-one-revolution for the 1541 ( which I doubt ), your turbo will STILL be 50% slower! b. My turbo uses STANDARD 8250 sector format! it's the DOS format that isn't compatible, not the sector format! you can read these sectors using U1:, U2:, and you can do D0=1 as much as you like. the ONLY thing you can't do on such a disk is (1) to validate it (b) to copy files using the internal copy command. I don't have a copy program for such files. What we do is to have a 'normal' copy of the files, and when we finish working on the file, we copy it to the 'fast' format. there is also anotehr limitation to the copy program. I don't think it will work with the SFD1001. it must use a double-drive unit. c. I think it will not be hard to modify my turbo to accomodate the standard DOS format, and then find teh equivelent M-W on the 8250/8050 to change the interleave ( as on the 1541 ), and record disks with interleave 1. to demonstarate the speed of it, lets say that loading a picture from within Doodle, it takes about 1 second, once you see the computer starts drawing it. ( i.e. not including the directory search time, and the time required to seek to the appropriate track ). we had a demo disk ( made before I wrote the 'file' structure ), that recorded a series of doodle pictures on the disk's tracks, and a demo code that read them right of the disk's surface at predefined tracks. the avarage time between a screen change ( the demo read 8-10 pictures right after another, then restarted at the beginning ), was about 1 second. ( remember - no directory search, and the disk is aleady spinning at full speed ). We almost don't use it any longer - actually we almost stopped selling C64/128 networks. besides, our IEEE based HD server is even faster, has a true 'fast' file structure, and can do real 'fast save'. > >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 > ------------------------------------------------------------------------------- Udi Finkelstein | Bitnet: finkel@taurus.bitnet or finkel@math.tau.ac.il Tel Aviv University | Internet: finkel%taurus.bitnet@cunyvm.cuny.edu Israel | UUCP: ...!psuvax1!taurus.bitnet!finkel -------------------------------------------------------------------------------
leblanc@eecg.toronto.edu (Marcel LeBlanc) (02/17/89)
In article <8902160843.AA11442@MATH.Tau.Ac.IL> <finkel%TAURUS.BITNET@CUNYVM.CUNY.EDU> writes: >>Subject: Re: turbodisk and IEEE >>Summary: Non-standard formats can give much better speed WITH 1541 ... >a. My Turbo is 50% faster than any THEORETHICAL 1541 speedup! my drives reads >a 8250 track that contains 27 sectors in one revolution! the 1541 has only up >to 20 sectors on a track. even if you will have such a >full-track-reader-in-one-revolution for the 1541 ( which I doubt ), your >turbo will STILL be 50% slower! >b. My turbo uses STANDARD 8250 sector format! it's the DOS format that isn't >compatible, not the sector format! you can read these sectors using U1:, U2:, You are right, of course. The maximum possible speedup on a 8050/8250 is greater than on a 1541. Also, because the 1541 has only one processor, it can't decode GCR and send it over the serial bus as quickly as it reads it. To accomplish this requires the use of non-standard sectors that have a lower information density that normal GCR. If the information density is low enough (but still useful), then the single processor can decode it and send it over the serial bus as it reads it. I think you would be able to get the equivalent of 15 standard sectors on a 1541 track. I haven't tested this new low information density format yet, but I think it should work. >to demonstarate the speed of it, lets say that loading a picture from within >Doodle, it takes about 1 second, once you see the computer starts drawing it. >( i.e. not including the directory search time, and the time required to seek >to the appropriate track ). > >we had a demo disk ( made before I wrote the 'file' structure ), that recorded >a series of doodle pictures on the disk's tracks, and a demo code that read them >right of the disk's surface at predefined tracks. the avarage time between >a screen change ( the demo read 8-10 pictures right after another, then >restarted at the beginning ), was about 1 second. I think you're being conservative again :-). Reading 40 sectors worth of information shouldn't take anywhere near 1 second with your turbodisk. If I remember correctly, the 8050 doesn't retain any directory information in it's buffers, so it has to return to the directory track before reading each new file. This constant seeking would account for the 1 second delay between screen changes. 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