From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-20 23:48:49
Hello Ullrich, UvB> I've also thought of something like this, because this would be useful for UvB> chaining IRQs on banked systems. On the C128 for example, the IRQ routine in UvB> the ROM will bank in BASIC and KERNAL - and bank out part of the cc65 program. UvB> If the cc65 program contains an IRQ or BRK handler, at least a small stub has UvB> to go into non banked memory, otherwise the program will crash at this point, UvB> because the vector points to code that is not available in this moment. BTW: UvB> The Plus/4 routines posted by MagerValp do also have this problem. UvB> However, I'm not sure how a good solution would look. Problem is, that "at the UvB> beginning" is a soft requirement. If you have three big modules to place at UvB> the beginning, the third one may already be in a range that is banked out. well... i'd say thats the responsibility of the programmer... those "three big modules" should only contain some small bits that actually have that requirement. (ie a bunch of actual wrapper functions that call the kernal, or even better, one of it that calls kernal via jumptable or sth). i see 2 possible solutions here... the first would require each module to be split into the "non critical" and the, small, "critical" part, and each put into a section with different attributes. the other would involve one common "farcall" API, which in turn means ONE common wrapper function for each target that takes care of that sorta things. however, while the first solution looks more attractive to me (wastes less cycles when done properly), it has still the disadvantage of possible clashes when linking to much of those modules - the common farcall-thing wouldnt have that disadvantage but would obviously be much slower. however, since that fastcall thing could probably be easily forced to link into always acessable ram (ie right after crt0 or sth) its probably the way to go, right? :) as a side-effect, this might be a relativly easy way to write quite portable assembly for cbm-machines or even across all targets, since calling routines through that jumptable would also mean the jumptable can be adjusted for each target :) (as a currently popular example, those pet file i/o patches might end up there - and automagically be available for any other sort of thing that might use them :=)) >> btw is there a reason for not having a toplevel makefile for easy >> doing the usual "make all install" thing? :) if the answer is the same >> as for the (formerly ;=P) missing file i/o, i can post what i hacked >> up for myself now :=) UvB> I think, Keith has requested that years ago, together with a "bin" directory UvB> where all the binaries should go. The reason why I didn't add something like UvB> this is, that I don't like to clutter the main directory and I don't know a UvB> good way to have all these things without doing that. uhmz well eh... ;=P how do you go through the build/install cycle then after having changed stuff in the compiler or library code? i mean... manually going through the directories and typing make and copying stuff to /usr/bin etc pp just isnt really acceptable when there is a shell or make util that could easily do that kinda boring work for me ,=) anyway, there are more urgent problems than this hehe :=P just beeing curious :) you might want to direct any other ppl that ask to me though, i think i am going to make this thing complete for myself anyway :=) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- 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 : 2002-11-20 23:48:58 CET