If calls and jumps will need to be changed to kcalls and kjumps, I assume the syntax in assemblers will be like the bcall for the TiOS.  But won't that cause some major slowdowns in the programs?  I mean the rst instruction, reading the next bytes to do the calculation with, retrieving the current location of the program, calculating the new location, and then jumping there, all while preserving all the registers and flags is a lot more T-states than most z80 programmers are used to for those instructions.  Also, how are you handling conditional jumping?  You're going to have to have a way to do that somehow because there is no practical way to read the parity and sign flags any other way.

No, I will not have memory allocated in 256 byte chunks.  I can think of >9000 reasons to use small amounts of data.  Also, the routine has no noticeable delay, and if it was in something like a raycasting engine that needed the speed, users would barely notice it because it would only be slower the very first time through a loop.

How are programmers supposed to use 256-byte-aligned lookup tables then? I was really just talking about loaded programs being aligned, not all data requested. Or would the program need to request all RAM to do something like that?

I'm going to be filming Rogue in action on a real calc as proof that it is running fine I'll upload it today and then I'm off to vacation for 4 weeks.

I got textroll'd

Nice vid btw, I like to see the OS in action on the real calc ^^

calc84, I'm afraid you will have to do just that.  But I want you guys to stop and think.  Aside from getting programmer cred for saving a few T-States, will users really notice much more of a difference?  I mean, honestly, guys.

yeah it's that, and the slowdown is only on the first time it is run, so we don't have to really worry.

'tis true