From: Greg King (gngking_at_erols.com)
Date: 2003-06-13 03:19:23
From: Ullrich von Bassewitz
Date: Wednesday, June 11, 2003, 04:23 PM
>
> On Wed, Jun 11, 2003, at 02:50:04PM -0400, Greg King wrote:
> > ... It takes only a few extra bytes to
> > restore DEVNUM. I see no valid reason to leave it out.
>
> And, I see no reason to restore it, since no one relies on it.
> ...
> My suggestion would be to ask the following question (in fact,
> this is the question, I've asked when deciding if a save/restore
> of other variables is necessary): Is there a need to save and restore
> this variable?
I rely on it. (When I write BASIC programs that use more than one drive
[and/or printer], I make those programs remember and restore DEVNUM,
so that I can depend on it being what I expect it to be.)
The IDE64 cartridge is another thing that relies on DEVNUM's value.
We can see a directory-listing simply by typing DIR or LL. When we do not
type the other parts of those statements, (
"",12
for example), they will read from whatever device is "named" by DEVNUM.
I like the convenience of being able to run a program, then afterwards,
display a directory without needing to remember to type the device-number
[but, apparently, no one else likes it :-)].
I will concede that it is not absolutely vital to restore DEVNUM -- unless
you consider convenience to be a necessity [sometimes, I do! :-)].
----------------
From: Groepaz
Date: Wednesday, June 11, 2003, 04:42 PM
>
> If you decide that you would like to restore this (and maybe more)
> variables, you can still link some own code to your programs easily and
> without much effort.
I go further than that. I changed my copy of the libraries so that they
save-and-restore some useful things that might be trashed. I mentioned it
to Uz because I thought that other people might appreciate that convenience
as much as I do [if I am wrong, my ego will survive -- just barely ;-)].
> Just for curiousity ... what kind of tool/program is that what you think
> could need such treatment? And, why wouldn't you have it loop
> infinitely, and provide an "exit" option rather than restarting it
> by "run"?
Suppose I run a program that asks me to type a file-name -- and, I forget
how to spell it (I refuse to admit how often it happens! :-P). If I am
lucky, then that program has a fancy user-interface, and I can make it show
a directory. But, what if it cannot do that? It is nice when I can stop
the program, use a "wedge" to display the directory, re-run that program,
and type the file's name.
----------------
From: Groepaz
Date: Thursday, June 12, 2003, 11:02 AM
>
> On Thursday, 12 June 2003, 16:36, MagerValp wrote:
> > >>>>> "G" == Groepaz writes:
> >
> > G> Mmmmh well, are there actually any of these "wedges" that would
> > G> even survive after running a cc65 program?
> >
> > Anything that stays in low mem. ( < $0400, like the tape buffer) and
> > under the Kernal ROM does. $c000 stuff stands a fair chance of getting
> > nuked though, but that's to be expected.
>
> Well, RAM under Kernal is used by both TGI and also the exp. mem.
> interface. And, most low mem. can't be used for user programs, either
> (tape buffer being the only practical exception, if and only if
> your cc65 is made to never use tape).
Don't forget that we easily can write and use configuration-scripts that
protect anything that we want to keep in high-RAM.
----------------------------------------------------------------------
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-06-13 04:12:41 CEST