I also having a side project optimizing draw calls to french Minitel terminal.
Instead of letting the generator create their own draw calls, just let them print in a buffer/array.
Drawing the array means finding out what changed, and then create optimized draw sequences: Like using delete-till-end-of-line, vertical cursor moves, or repeat-character-x. Very noticable on 1200/4800 baud.
If anyone wants to do this in DOS, one thing I learned from the 1991 BLUE Book is that BLOAD can be used to load a binary file straight to graphics card memory.
https://github.com/robhagemans/hoard-of-gwbasic
There was a site hosting the author's freeware utilities (now only on the web archive?), and one is a graphics editor made for that purpose ("EBS: Screen editor for BLOAD pages"):
From a quick search BLOAD is available in Commodore BASIC as well. Would be interesting to hear how it compares to the optimized loop that PRINTs the image, if the same trick works on a C64?
* No... BLOAD was added in some later version, e.g. for C128, not any of the versions running on C64 https://www.c64-wiki.com/wiki/BASIC_7.0#Commodore_BASIC_Comm... ... But I guess the speed of reading a few kB from a C64 disk drive compared to a 1991 PC hard disk may make it a pretty bad idea anyway if speed is important. On the other hand it would make the program itself smaller and faster to load, so difficult to guess if the total time to render the screen would have increased or not.
Files on cassette have a header that contains the starting address to load to (https://eden.mose.org.uk/download/Commodore%20Tape%20Format....), so while you cannot specify at load time where to load data, files that load into specific screen ranges can be created. I don’t remember how this was done, but chances are it involved manually calling a few undocumented ROM routines.
I did this, I wrote a VGA slideshow for my "NUxT" 8088, and at its 9 mhz, it manages to switch from one full screen color image to another with about 3 fps.
I did some optimization to get there, like turning the image upside down so that the first byte of the image data corrosponds to the first byte of vga memory.
I was using some period correct-ish borland c, and had to deal with concepts such as "far" versus "near" pointers and page alignment which I never had to do on PC before, it was fun.
I did a slideshow for presenting some details about my home built C64 (MaxFake64), I drew all the "slides" in petscii and saved them as binary data at the end of an assembly program, which then copies each slide into the right place in VIC memory, I think it draws the entire screen in less than one frame period.
For (that one person) who find that interesting, the slideshow can be run in the emulator at archive.org, press F1 for next slide and F3 for previous slide.
https://archive.org/details/hvad_20221229
I mean, it's basic knowledge that in BASIC printing a whole line is faster than poking characters in a loop.
You can also simulate curses positioning by using strings of control characters https://www.c64-wiki.com/wiki/control_character
No need to have a real C64 to evaluate most things, there are quite accurate emulators, too.
I also having a side project optimizing draw calls to french Minitel terminal. Instead of letting the generator create their own draw calls, just let them print in a buffer/array.
Drawing the array means finding out what changed, and then create optimized draw sequences: Like using delete-till-end-of-line, vertical cursor moves, or repeat-character-x. Very noticable on 1200/4800 baud.
If anyone wants to do this in DOS, one thing I learned from the 1991 BLUE Book is that BLOAD can be used to load a binary file straight to graphics card memory. https://github.com/robhagemans/hoard-of-gwbasic
There was a site hosting the author's freeware utilities (now only on the web archive?), and one is a graphics editor made for that purpose ("EBS: Screen editor for BLOAD pages"):
https://web.archive.org/web/20060410121551/http://scottserve...
From a quick search BLOAD is available in Commodore BASIC as well. Would be interesting to hear how it compares to the optimized loop that PRINTs the image, if the same trick works on a C64?
* No... BLOAD was added in some later version, e.g. for C128, not any of the versions running on C64 https://www.c64-wiki.com/wiki/BASIC_7.0#Commodore_BASIC_Comm... ... But I guess the speed of reading a few kB from a C64 disk drive compared to a 1991 PC hard disk may make it a pretty bad idea anyway if speed is important. On the other hand it would make the program itself smaller and faster to load, so difficult to guess if the total time to render the screen would have increased or not.
Files on cassette have a header that contains the starting address to load to (https://eden.mose.org.uk/download/Commodore%20Tape%20Format....), so while you cannot specify at load time where to load data, files that load into specific screen ranges can be created. I don’t remember how this was done, but chances are it involved manually calling a few undocumented ROM routines.
I did this, I wrote a VGA slideshow for my "NUxT" 8088, and at its 9 mhz, it manages to switch from one full screen color image to another with about 3 fps. I did some optimization to get there, like turning the image upside down so that the first byte of the image data corrosponds to the first byte of vga memory. I was using some period correct-ish borland c, and had to deal with concepts such as "far" versus "near" pointers and page alignment which I never had to do on PC before, it was fun.
You can approximate BLOAD with SYS calls. Something like SYS57812"FILENAME",8,1:POKE780,0:SYS65493 will do it.
I did a slideshow for presenting some details about my home built C64 (MaxFake64), I drew all the "slides" in petscii and saved them as binary data at the end of an assembly program, which then copies each slide into the right place in VIC memory, I think it draws the entire screen in less than one frame period.
For (that one person) who find that interesting, the slideshow can be run in the emulator at archive.org, press F1 for next slide and F3 for previous slide. https://archive.org/details/hvad_20221229
I mean, it's basic knowledge that in BASIC printing a whole line is faster than poking characters in a loop. You can also simulate curses positioning by using strings of control characters https://www.c64-wiki.com/wiki/control_character No need to have a real C64 to evaluate most things, there are quite accurate emulators, too.
> it's basic knowledge
Oh you!