Sorry I read your PM. Really converting to app safe format isn't that hard. If you are using my code than, you must copy the grey lcd copier and the sprite routines to the ram. Make sure that the are addressed to work there. it should all fit in statvars with the interrupt vector table and the interrupt itself. But I see if I can make another release with app friendly define.
That's easier said than done. Question: If I alter the functions so that calls within the function are all relative, then I would just need to call the memory address I copied the function to to use it, right?
Or woudn't it? Would I have to alter the greyLCD copier so that the interrupt pointed to the right place?
Not knowing the routines well, I don't know how successful I will be doing this.
BTW, to copy all of this code, I can just use ldir, right?
*edit* Perhaps jim, your APP friendly defines could do the following:
In gsEnable, copy the LCD routines to RAM before setting the interrupt
For gsPutSprite, copy the routines to RAM and re-define names of functions so that they point to RAM areas.
Also, if you are successfull, make sure to mention which sections of RAM will not be accessible for APPs.
It shouldnt be too hard to just relocate the grayscale interrupt routine to a saferam area and run it from there. You just need to make sure that the labels are changed with respect to the saferam area in which you are copying it to.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
Actually I have mostly decided not to release RGP on to ticalc in any form. I first started it s a proof of concept thing(like most stuff I do). I later justified turning it into a package because it seemed knowledge of how to work with the hardware, doing grey in general, and creating highly optimised code was at a premium.
But now after several PMs and the posts I've gotten over the months it seems like I got more questions on how to do the most simple things. So I've come to the conclusion making a big package of code that seems to offer a lot of pretty doesn't really help new coders, Rather it impedes on actual production since they set their goals to high. Not everyone is going to pull a tr1p there first game.( even then he had experience)
So in other words, You should try making it app friendly on your own, if you can do that then you are going to be more likely to finish that project.
Jim e wrote:But now after several PMs and the posts I've gotten over the months it seems like I got more questions on how to do the most simple things.
Actually, my issues have always been compiling/assembling issues. Mainly trying to get the .inc file to behave with Latenite, or getting SPASM to work by itself. I'm bad at making things work on the comp XD
Good point, Jim. Very good point. You could consider releasing it without providing support though, so people who know what they're doing can use it. Because I think it would be a shame not to release it.
I agree with Timendus. I think i've got a decent understanding of how your package works, perhaps not all the hardware details though. Leave out contact info? Besides, if someone wants to improve/modify it, they'll be able to do so if they're good enough