From: Spiro Trikaliotis (Spiro.Trikaliotis_at_gmx.de)
Date: 2000-01-21 00:03:45
Hi Groepaz, let's make a statement to some of your statements... >however, seeking WILL also be supported by the kernal-driver, but will perform >awfully bad ofcoz (only way to seek would be to read sequentially from the >start, Well, you could keep a seek pointer with every file, so at least forward seeks would be possible w/o going through the _whole_ file. Another way would be to only read the 2 first bytes from the needed blocks from the disc, so you would need need to transfer all the unneeded bytes over the serial bus, this should speed up the seek a little. You could also keep track of all these link bytes once read (i.e., when the first seek is started), so you can make further seeks() much more faster... >there will be, however, a somewhat 'generic' driver for floppy-drives though, >that >will support real seeking via direkt disc-access. Hm, it seems you thought about something similar to my thoughts above, didn't you? >> The low level functions should handle three file descriptors without any >> further action: >> 0 stdin >> 1 stdout >> 2 stderr >ehrm... /me confused =) ... do you mean that first descriptor my open() returns >should be 3 Well, Ullrich obviously means that, yes. >and whenever my read/write routines are called with descriptors 0-2 >as parameters they should simply map the call to stdin etc ? No, I don't believe that is meant. The descriptors 0-2 are like any other descriptor. It's best to think the following way: When starting up, your routines should perform something like open 0,0,0 : rem open keyboard as stdin open 1,3,0 : rem open screen as stdout open 2,3,0 : rem open screen as stderr (well, on Unix/DOS/WIN, these are not opened by the startup code but rather by the OS.) So, the special processing of handles 0-2 is not in the i/o routines but in the initialization. >IF so, what is the >standard way to SET what IS the, eg, stdin ?! (what c-function ? or should the >OS somehow define this?) Well, under Unices, DOS & WIN, the OS is the one who can redefine them. On the other, it is also possible for a program to close a handle and re-open it, so that's the standard way to redefine them. >> With this in mind, the current behaviour of printf() makes sense: It >> writes to stdout which is mapped to the file handle with the value one. >well.... ehrm... yes it MAKES some kind of sence, if you would consider the cbm >kernal calls beeing standard C-style i/o functions. [...] >[....] but if you WANTED to do >that, it would mean that printf had to call my filesystem and pass its data >through it... making screenoutput via printf unacceptable slow. Well, couldn't you make a fast check beforehand whether the output will go to screen, if so, your routine could use a 'short way', something that the C64 kernal does in $F1CA-$F1D2? >> It should even be possible to close or reopen the first three file >> descriptors, so the best way is probably to open them using the normal >> kernal calls at program start. >now this sentence confuses me again... so CBM_KERNAL file-descriptors 0-2 ???? >(nonononono that dont make sence ;=P) Yes, exactly, these three file handles are no different from the others disregarding their initialization. >> I have some specification on the 1571 (that I found on the Internet), >> that even includes specification on the build-in MFM-controller. A >> driver to read PC-disks in 1571 and 1581 can be made. >in electronic format? gimme! :=P Me too (at least URL, please)! Spiro. ---------------------------------------------------------------------- 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