From: Groepaz (groepaz_at_gmx.net)
Date: 2000-01-21 22:12:03
HOLLA! you better correct my errors fast... i am coding this nite ;=P hehehehe
> In other OSes than 'BASIC on CBM' standard input and output and error, are used, because you can redirect them all to a file or a printer etc.
>
> Since 'BASIC on CBM' OS doesn't support redirection; stdin, stdout and stderr makes no sence.
wrong... CMD is the command.. it was explained already... if it would NOT be
supported, why should there be my problems with printf? 8=)
>
> No, no, I don't want to leave out stdin, stdout and stderr. I want to enable 'BASIC on CBM' OS to support redirection.
>
> Maybe tree pointers in memory could point to strings for stdin, stdout, stderr.
[snip]
that'll be a poor way to do it actually... kernal HAS most of the functionality
needed, its
just a little weird to use ;=)
> 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.
ofcoz... this improvement is so obvious that i ofcoz thought about it 8=)
> 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?
yes... actually my 'kernal-disc' driver will read through the sector chain
when you open() a file and buffer the link-list somewhere. this way real
'random' access a'la relative files (even performing better IMHO) is quite
easy to implement. Ofcoz seeks will still be slow...(well, if the r/w head
must NOT move tracks, it should be fairly acceptable) but compared to the
brute force method above it'll be lightening fast =P
however, once these two 'generic' kernal drivers work ok, i will challenge
myself on a really 1541 specific one with fastload, 2bit transfer... buffering
stuff on the DRIVE rather than the c64... could even do fancy shit like reading
sectors in advance and buffering in drive mem ;=P
[snip]
... so about the redirection stuff, i'll sum up what i have understood (i think
i got it, but please correct me if i am wrong even in some nasty detail ;=P)
i understand rooting printf through the filesystem makes sence... it will
require (maybe) some modification on your printf call though (it shouldnt go
directly to $ffd2 but to some other routine that i will provide)
what i will do is:
called in fs_init():
open FILENO_STDIN/filehandle 0, keyboard device driver
open FILENO_STDOUT/filehandle 1, screen device driver
open FILENO_STDERR/filehandle 2, screen device driver
... subsequent calls to open() will return handles 3,4,5,... for easier
internal handling (this should be perfectly standard compliant, is it?!)
... a "device driver" (rather a dummy and some quick-checks ;=P) for keyboard
and screen will be added and hooked to read/write.
... a printf replacement will map stdin etc to their defined filehandles (at
this point, how *exactly * do printf/fprintf/write corrospond?! is printf just
some #define printf fprintf(stdout ... thing or really a direct call to $ffd2?
(i have to admit... erhm... i could check myself ;=P) ... just wanna make sure i
could savely replace your printf() without effecting any other stuff (oh, and
are you using some other related kernal calls somewhere in your libs? these
could cause some quite weird and hard to find bugs if so ;P)
... at run time, the user could redefine stdin/sdtout/stderr by the following
procedure:
close(FILENO_STDIN);
close(FILENO_STDOUT);
close(FILENO_STDERR);
// the ORDER of these is important!!!
fd=open("a:/myinfile"); // returns fd=0
fd=open("b:/myoutfile"); // returns fd=1
fd=open("c:/myerrfile"); // returns fd=2
called in fs_shutdown():
close FILENO_STDIN/filehandle 0, keyboard device driver
close FILENO_STDOUT/filehandle 1, screen device driver
close FILENO_STDERR/filehandle 2, screen device driver
[snip]
> It is usually called "exec", but this is a rather complex call and probably
> not suitable for 6502 machines.
yeah true... supposed to be able to return to the caller etc right? obviously
not really suitable with <64k ram 8=)
> Andre Fachat has a very good description on his home page. Unfortunately,
> his homepage location changed lately and I don't have the new URL handy.
mmmh, too bad =(
> The compiler and linker are quite fast on todays hardware. But you are
> right: code that is relocatable at runtime would be nice. But it is not
> there currently.
well thing isnt that i fear compile time (should take less than a second
here compiling everything ;=P) but once more than one or two drivers exist,
it'll make quite a lot of sence not to have them all in memory and beeing
able to load them at runtime. actually i have thought about it a bit already
and a simple solution could be:
to load a device driver, just malloc() the needed memory for the driver, then
load the driver there using built in kernal driver. somewhere in the file
(preferably at the start) could be a jumptable to the driver service routines,
or a table with offsets. then just init the driver and adjust some calls in the
filesystem. the driver itself probably wouldnt need any relocation (i think?!)
due to it being very low-levelish not needing any direct memory access/jumps or
subroutine calls. (i may be wrong with the later though).
although this could turn out as a satisfying solution, it has one major draw-
back that i dont really like, and that is that drivers would HAVE to be loaded
at the start of your program, before you malloc() any other memory - or your
heap will get corrupted. also it wont be possible to remove/add drivers at
runtime, which would be a neat feature indeed.
> It depends an what you want exactly. You may use
>
> static const char* Msg[] = {
> "Bla",
> "Fasel",
> "Foo",
> };
>
> or you may use
>
> static const char Msg[6][] = {
> "Bla",
> "Fasel",
> "Foo",
> };
yes! all i wanted is THIS ;=P mmmh... was that added just recently? i tried that
sometime when i started writing my cmd-line interpreter but i couldnt get
it to compile 8=) have to check asap with the recent version hehe ;=)
...
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