neilsf / XC-BASIC

A compiling BASIC dialect for the Commodore-64
https://xc-basic.net/
MIT License
74 stars 15 forks source link

Moving SCREEN RAM with poke #125

Closed frenchfaso closed 4 years ago

frenchfaso commented 4 years ago

Hello there, I'm trying to implement a backbuffer by poking character codes to another location (other than 1024) and then moving the video matrix with this command:

poke 53272, (peek(53272) & 15) | 64 REM (backbuffer starts at 4096)

if I use lower RAM adresses I get either rubbish characters, or a crash, how can I determine a safe location to use as a backbuffer?

I tried a couple of addresses from this C64 wiki page on screen ram: https://www.c64-wiki.com/wiki/Screen_RAM

Thanks!

PS: also, is this the best way to have the fastest screen update possible, without screen tearing?

neilsf commented 4 years ago

Hi. Take a look at this demo effect. It uses two screens, one at $2800 and another one at $2c00: https://github.com/neilsf/XC-BASIC/blob/master/examples/plazma/plazma.bas

is this the best way to have the fastest screen update possible, without screen tearing?

It depends. You can't update the whole screen under 1/50th of a second, that's for sure, even in assembly it's not doable. In Flying Saucers we're updating only an area of 40x8 chars, the rest is static. This way we don't need double buffer at all. XC=BASIC has its limitations, you have to try what's possible and what's not.

frenchfaso commented 4 years ago

Thanks, great example! I managed to do a simple double buffering test. Just using a higher memory address for the back-buffer did the trick. From the plazma example I learned to "flatten" the poke peek command sequence, poking directly a binary value should save a couple of cycles!

In Flying Saucers we're updating only an area of 40x8 chars, the rest is static.

I liked it very much, and the fact that it is coded in XCBasic makes it even more awesome!