From: Groepaz (groepaz_at_gmx.net)
Date: 2000-01-22 14:33:07
and again... 8=)
> Why will seeks remain slow? Every seek will require at most reading one
> sector from disc.
With 'slow' seeks i was referring to the speed one could be expecting from eg
a pc hd. on a 1541 ofcoz, you can hardly do any faster ;=P
> Even the already mentioned "while(1) fseek(-1)" - example could be made
> fast if you would always buffer a whole (physical) sector on the host,
> so you would not need to read the sector from disc with every seek.
it will read the current sector into drive-memory actually....
the procedure to read byte at position N from a file would be like:
sect=fpos/254; // this is nonsence ofcoz, a table to the actual track/sector
would be involved
byte=fpos%254;
... if(sect!=last_sector) read sector 'sect' from disc to drivemem
... read byte number 'byte' from drivemem and send to host
this way no more data than necessary has to travel the serial bus ;=) (which is
the bottleneck in the cbm setup ;=)
> Another fine way would be to 'detach' the seeking and the reading:
> The seek could issue the command to the floppy to find the sector
> and return immediately; then, you only would have to wait for the
> seek being performed when you read some bytes (which could possibly be
> some time afterwards). This would also have the advantage that seeks
> w/o reading anything (like the loop above) would be really fast, because
> we would never have to wait for the floppy.
well, what you are thinking of is async-operations and YES it will be ofcoz
possible to improve the disc-driver to use it.... however, due to the nature
of the 'generalized' kernal and kernal-disc drivers its out of the question at
this time.... but something to remember for the 1541-specific driver ;=)
> Another think to think about is to read the links only when they
> are needed or when they are provided anyway. I believe it's too
> much overhead at opening to get the link list for a file occupiing
> the whole disc, when there will never be any seek on it.
well...for a 664 blox file it would require 664*2 bytes for buffering the
whole link-list.... maybe its too much you are right ... mmmhhhh, i have to
think about some mechanism that retrieves the list when needed ;=P
> Well, now I'm not sure, but I believe you should only close() _one_
> pre-defined file handle at a time and re-open it immediately.
this will also work. it will also be 'safer' than the way i mentioned above i
think
since it'll also work if stdin/out/err are NOT fd=0,1,2
> The rest seems good to me.
ok.
l8rs
gpz
--
........................................................
/^\
\ /
ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL
/ \
........................................................
.--.--.--.----..--.--.--.-----.----.
C=64 / / / / . / . . / . / . /\
/ / /__/ /__/ / / / / / / / /
PC / / / /\_/ / / / __ / / / /
/ / / / / // / / / / / / / /
PSX / / / / / // / / / / / / / /
/__/__/__/__/ //__/__/__/_____/__/__/ /
\__\__\__\__\/ \__\__\__\_____\__\__\/ Groepaz
........................................................
.. http://fly.to/hitmen-c64 ............................
..... the hitmen c64 home page .........................
.. http://www.hitmen-console.org .......................
..... hitmen psx section ...............................
.. http://start.at/hitnav64 ............................
..... biggest c64 link collection around ...............
.. http://fly.to/hitmen-groepaz ........................
..... my little personal page ..........................
........................................................
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET