Applecorn
Applecorn copied to clipboard
bobbimanners
Make more space in Aux LC by moving some stuff to main
Non performance-critical code can be moved to main mem.
We have 866 bytes of Aux LC left at the time of writing.
Most likely the SHR line-drawing stuff can live in main memory. It is not going to slow it down appreciably.
Moved font exploding code and coordinate conversion to main memory.
823 bytes left in aux LC. (We added support for VDU 23 also, which explains why the number didn't go up more.)
This is a decent base for adding SHR graphics in main memory.
How much space is left in mainmemory? The code goes up to about 6000, how far can it go?
The absolute limit is BFFF. ProDOS keeps some stuff up there so you can't go all the way to the top. There is quite a lot of free space in main mem. I am planning on putting all the line drawing code in main memory, but even so, we have oodles.
On 31-12-2022 07:25, Bobbi Webber-Manners wrote:
The absolute limit is BFFF. ProDOS keeps some stuff up there so you can't go all the way to the top. There is quite a lot of free space in main mem. I am planning on putting all the line drawing code in main memory, but even so, we have oodles.
I've been pondering how much of the VDU code could move over. The main non-VDU-call stuff that needs to be exposed is the flashing cursor and reading characters from the copy cursor. Most of the other stuff looks easy enough to do via a shim, read pos/vpos, read vduvar, read point colour, read character bitmap.
-- J.G.Harston - @.*** - mdfs.net/jgh
Well I guess it depends on how much new functionality we are planning to add :)
I think I have enough space to finish up SHR graphics. Just line drawing and clipping left now really. The rest is there.
And there is a fair bit of SHR code that I could easily move to main memory (the colour and palette stuff.)
173 bytes free in aux LC at present. Planning to push the SHR cursor code over to main memory which will maybe save another 100-200 bytes in aux LC.
There's the coordinate clipping stuff mentioned in the other issue. I think this would be easier to deal with after moving the code into main. I think I might need to print out some listing to work out where in the code to switch banks and pass info across. I think that the whole of VDU25 might be the easiest, just make VDU25 a stub that switches banks, and the the code in main reads across the VDU queue. And once that's done, I think there's quite a bit of code the HGR and SHR drivers can share.
That may make sense. For MODE 0 / MODE 1 I do the clipping after the coordinate transformation to physical coords, which may not fit with that plan. Also note that because the "Super High Res" mode is a GS feature only, I can use 65816 code in the SHR code, which makes doing 16 bit ops a lot nicer. Lots of trade-offs here.