Hello, friend. How I can save screen background and move objects without erase (like game) in TRS-80 ? In BASIC I can with PEEK and POKE or only Assembly ?
Unfortunately I think BASIC PEEK/POKE will be too slow (unless maybe you just use a very small portion of the screen, like maybe 10×10 only). My code was in C language that was compiled to Z80 assembly.
The approach I used is not quite “double buffered” (like more modern systems will use that with H/W support for it)… In my approach I keep a copy of the map in memory (so that’s use 1K RAM). Then I have two “scratch pad” sections of memory: a bit mask to mark which cells have been modified, then another sections of RAM reserved to store which locations (x,y) were modified (and the target symbol to modify them to). The length of that RAM just depends on how large of icons/cells you want to support (I chose vector of 34). But for performance reasons with these limited 1mhz processors, the real “trick” was avoiding any / (divide) and % (multiply) call by using pre-computed tables (like when deciding which cell_state bit corresponds to which x/y screen coordinate).
Sorry it’s not a real easy explanation. I think the same concept could be done in BASIC (using DIM and DATA statements to reserve RAM for tables), and the same bit-logic could be used — but it’ll be interpreted and just won’t be able to run fast enough at 1mhz to be a smooth movement.
Destiny Hunter
Testing! Hello!
LikeLike
Hello, friend. How I can save screen background and move objects without erase (like game) in TRS-80 ? In BASIC I can with PEEK and POKE or only Assembly ?
LikeLike
If possible, consult my PDF document here. It is not specific to TRS-80, but gives general outline of the strategy I used for moving objects on the text screen: https://github.com/voidstar78/DestinyHunter/blob/main/doc/strategy%20for%20flicker-free%20heterogeneous%20multi-cell%20icon%20animationV3.pdf
Unfortunately I think BASIC PEEK/POKE will be too slow (unless maybe you just use a very small portion of the screen, like maybe 10×10 only). My code was in C language that was compiled to Z80 assembly.
The approach I used is not quite “double buffered” (like more modern systems will use that with H/W support for it)… In my approach I keep a copy of the map in memory (so that’s use 1K RAM). Then I have two “scratch pad” sections of memory: a bit mask to mark which cells have been modified, then another sections of RAM reserved to store which locations (x,y) were modified (and the target symbol to modify them to). The length of that RAM just depends on how large of icons/cells you want to support (I chose vector of 34). But for performance reasons with these limited 1mhz processors, the real “trick” was avoiding any / (divide) and % (multiply) call by using pre-computed tables (like when deciding which cell_state bit corresponds to which x/y screen coordinate).
Sorry it’s not a real easy explanation. I think the same concept could be done in BASIC (using DIM and DATA statements to reserve RAM for tables), and the same bit-logic could be used — but it’ll be interpreted and just won’t be able to run fast enough at 1mhz to be a smooth movement.
LikeLike