From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-01-21 12:02:57
> (are there corrosponding 'standard' functions for loading and/or
> running another executeable?)
It is usually called "exec", but this is a rather complex call and probably
not suitable for 6502 machines.
> ehrm... /me confused =) ... do you mean that first descriptor my open() returns
> should be 3 and whenever my read/write routines are called with descriptors 0-2
> as parameters they should simply map the call to stdin etc ? IF so, what is the
> standard way to SET what IS the, eg, stdin ?! (what c-function ? or should the
> OS somehow define this?)
Spiro answered that correctly. There are three file handles that are
expected to be already open when the program starts. The values of these
file handles are #defined by the preprocessor macros FILENO_STDIN,
FILENO_STDOUT and FILENO_STDERR. However, older software (and most unix
stuff) assumes that the values are 0, 1 and 2 respectively. So for
portability sake it is a good idea to make the handles have these values.
> for practical use it would make much more sence if you'd use a
> "screen-only" kernal call for printf() - if someone wanted to specifically
> write to a file, he would use fprintf() anyway ;=P (and your fprintf calls
> write doesnt it?) - it would obviously have the backdraw that printf() could no
> more me mapped to a file (by defining a file as stdout) 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.
Calling printf is the same as calling fprintf with stdout as first
parameter. stdout is defined as the file stream with FILENO_STDOUT as
handle. So routing calls to printf to the file driver is not only a good
idea, it is also needed for standard compliance.
One may decide to close stdout and reopen it as a file. When doing this, all
data that is printed using printf() goes to the file. This is what happens
if you use '>' under Unix.
> > So yes, o65 would be a good candidate for what you are planning to do.
>
> cool... is there some good specs on this around somewhere? =P
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.
> i would *LOVE* to support LOADABLE device drivers so one wouldnt need to
> recompile
> everything for every little change of conditions... but i honestly dont
> know how i could do this using cc65.... any ideas?
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.
> oh, one thing... how could i have an initialized list of strings? define it
> in .byte as asm ? mmmpf.... C w/o initialized structs somewhat lacks
> functionality ;(
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",
};
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
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