This is my test program. I set the screen address to $fc00 and fill the screen with a new character every frame. I skipped the macros and register definitions to keep down the size. I follow the naming conventions in Mapping the C64.
When I saw this trick here, I decided to use it in an editor I have been working on. The original code did something like this--
sta $ff01 ;just RAM 0 visible lda (line),y ;get a byte of text to display sta $ff02 ;back to kernal and i/o visible cmp #END ;have we reached the end of the line? beq ;somewhere sta $d601 ;to the VDC screen somehow iny bpl back ;for more
I realized how much more efficient it would be not to have to switch banks at all. By moving the stack through memory I could leave the kernal and i/o visible--
pla cmp #END beq sta $d601 iny bpl back
The PLA always pulls from RAM even though I/O or ROM might be visible. Sure, there is a little overhead before and after processing the line, but it worked out surprisingly well.
The difficult thing with the stack is that it becomes dangerous to get interrupts triggered and you can't easily use subroutines so that has to be avoided. The zero page can probably be used in the same way and may be easier to use if the interrupt code is free from zero page accesses.
Well, I agree--interrupts enabled with the stack located somewhere sensitive would be disastrous (don't touch that restore key). And as you say, it might be worth trying to move zero-page. A shorter, faster addressing mode is always a big plus, but then one would have to switch ROM and I/O in an out to get access to RAM underneath. It's certainly something worth keeping in mind for when an opportunity presents itself. Now that I have gained some programming confidence, I'm more willing to try these things and exploit the C128 wherever possible.
Oops, I'm wrong. LDA $00,x does indeed access RAM underneath ROM and I/O. But, the relocated zero-page still has ports at $00 and $01 getting in the way. For me, this makes swapping zero-page not as tidy as swapping the stack.
@wagner, I think you are on a good/optimal path... but yes the $00 and $01 registers can 'ruin' an otherwise 'perfect' algorithm.
I *promise* I will publish a real-life example with TEMPEST 128, but here is some theory that may (or may not) motivate you...
Think about how much faster the CPU can write zero page, or the stack page. Next imagine using that power. Maybe you can't read/write *all* 256 of the zero/stack page, but if each access saves you 25% of time, and you multiply that savings by *almost* 256 (like 248) then you can *literally* save many hundreds of CPU cycles... if done correctly.
Sure there will be loss from the $00/$01 'exclusion' code, but the gain from the remaining 254 bytes should OVER-Compensate for that... if you do it right.
I hope that helps to motivate people for now!! If not, stay tuned for *deep* program code
[Edit]I was referring to GENERAL zero-page / stack-page redirection. After contemplation, I now realize this thread is *explicitly* about page 255 manipulation. I apologize because my GENERAL post has only a statistically small chance of relevance (1/256).
Personally, I hate the way the $ff00 registers foul up an otherwise perfect VIC-II bitmap ($e000~$ff40).[/Edit]
Last Edit: Nov 11, 2017 10:12:58 GMT by hydrophilic: GENERAL page redirection