I've not used screen paging on the 128K before, and wonder if I've been missing a trick. How does it work in practice? Does it make it more tricky in terms of structuring the code? Do you lose the use of addresses from $C000 for other purposes? or is there no downside other than making the code 128k only?
Show us what you're working on, (preferably with screenshots).
I've tried coding a scrolling demo with it. And the 50Hurts 50fps scrolling uses it too. It saves you a whole frame or more per game loop if you're using a back-screen and trying to avoid flicker.zxade wrote: ↑Wed Sep 11, 2019 9:01 amI've not used screen paging on the 128K before, and wonder if I've been missing a trick. How does it work in practice? Does it make it more tricky in terms of structuring the code? Do you lose the use of addresses from $C000 for other purposes? or is there no downside other than making the code 128k only?
The big drawback is you have to page the screen you're drawing on into the top of RAM (or write to the regular screen at $8000 and the back screen at $C000). This means you have slow RAM at the top of memory, so it's not good for storing graphics data or anything you need to access fast. Which means your game code and all the data it needs for the current stage pretty much has to fit in the middle 16K from $A000 to $BFFF.
Which means even if you're not swapping chunks of code around, you're going to need a dynamic data-management system so you can copy stuff like sprite data into the middle 16K - and that actually limits how much you can have going on in any one level, compared to a 48K game. You could at least stick any music and sound and data used during the interrupt/top-border functions in the slow RAM from $5B00 to $7FFF.
It's still sort-of 48K compatible, as on a 48K you could have your back screen at $C000 and just spend more time copying it down to $8000 instead of paging it. But you'll need a full-on strategy of managing or limiting other data to keep your game 48K compatible, and it'll run slower.
As I see it, the only reason for making a 48K game is to see what you can do with the limited system, in which case I'm not interested in 128K enhancements. On the other hand, if you are going to add 128K features, you might as well just forget about 48K compatibility and make a 128K game. Someone asking 'why isn't there any 128K music' is about as relevant to me as someone asking 'why didn't you write it for an iPhone'.
The only other trick you could use is to copy data from a fast RAM bank into a screen RAM bank by using an OUT to swap the banks over between reads/writes. But this is only efficient really if you're caching the copied bytes in lots of registers, e.g. a PUSH/POP copy, and then only really if you're copying a chunk of screen between the same addresses in both banks.