From: carlos (carlosofcascade_at_gmx.net)
Date: 2003-10-17 21:01:50
Hello Ulrich again,
should i use conio instead of stdio? does that make a difference?
If yes, it would be really fine. How can avoid using c file io together
with cbm file io, if
i need cbm load/save routines?
I didn't want to complain, sorry if this is how you understood that.
Greetz
Carlos
>
> On Fri, Oct 17, 2003 at 07:53:24PM +0200, carlos wrote:
> > I see your arguments, but there should be any possibility to find out
which
> > drive has been accessed the last time or something like this, because i
> > don't want to have a program running only on drive 8.
> > The natural thing is, that you use the drive, from where the program has
> > been loaded.
>
> That's ok, but you cannot rely on a compiled program that uses file I/O
not
> touching the kernal variable used for the drive number. Someone suggested
to
> initialize _curunit with the drive number from where the program was
loaded.
> Until this is available, you can use this module to do something similar:
>
> --------------------------------------------------------------------------
--
> .constructor saveunit, 32
> .export _savedunit
> .code
> saveunit:
> lda $ba
> sta _savedunit
> rts
> .bss
> _savedunit: .res 1
> --------------------------------------------------------------------------
--
>
> It is used like this:
>
> --------------------------------------------------------------------------
--
> #include <stdio.h>
>
> extern unsigned char savedunit;
>
> int main (void)
> {
> printf ("Saved unit: %d\n", savedunit);
> return 0;
> }
> --------------------------------------------------------------------------
--
>
> > The second thing is, that there are kernal variables $9a/$9b for stdin
> > stdout. This is where the drive
> > output/input device number goes when doing a cmd ... from the c64 basic
> > prompt.
> > So i don't understand why to mess up $ba, which is at the moment the
only
> > possibility to get drive from where the program has been loaded.
>
> The library is "messing" with $ba because it is opening files. And when
doing
> so, it uses the kernal OPEN entry point, which in turn will overwrite the
$ba
> variable. Please note that it is not the library that is overwriting $ba,
it
> is the ROM kernal of the C64!
>
> $9a/9b don't change anything, because stdin and stdout are files and are
> therefore using standard C file handles. Even if $9a/$9b would be used
(which
> is difficult, because the file code is the same for all CBMs and $9a/$9b
are
> C64 specific), stdin/stdout and stderr would still have to be opened. If
you
> don't want the library to open any files, then don't use file I/O - it's
> really simple.
>
> > If there would be another way instead of using kernal variables
directly, i
> > would appreciate.
>
> You do have two choices:
>
> 1. If you want to use kernal file variables without the library messing
with
> them, don't use file I/O in your program. PLEASE NOTE: This includes
> printf/fprintf/puts/putc/...
>
> 2. If you find that you need to use C file I/O, you can still use kernal
> variables, but stop complaining about the library using them, too.
After
> all, it's your program that is causing the library to do so. Instead,
you
> will need to understand what the library does and find a way to
cooperate
> with the library code. One way to do that is shown above. You may run
> into difficulties with this approach if the library implementation
> changes. But no one can prevent this.
>
> Above choices are not only limited to cc65, they are - in a similar way -
> inherent in all APIs, where a higher level API uses a lower level one. As
a
> programmer, you should only use one API. If you don't do that, you will
have
> to live with restrictions at best. If you are using C file I/O together
with
> POSIX file I/O under Linux or Windows, you will get unexpected results.
>
> 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.
>
>
----------------------------------------------------------------------
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 : 2003-10-17 21:07:24 CEST