Printing Petscii Faster(retrogamecoders.com)
retrogamecoders.com
Printing Petscii Faster
https://retrogamecoders.com/printing-petscii-faster/
11 comments
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.
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.
You just need to specify a secondary address of "1" when loading the file, so that it loads into the memory area specified in the header instead of the default location.
This was rarely used with the tape though, but rather with autoloader programs on the disk - there would be a specially crafted program that loaded itself info the system stack or variable area and overwrote some vectors, so that it would be automatically run without the need to type RUN:
LOAD "*", 8, 1 : REM 8 is the disk drive and 1 is the secondary address
I consider this mostly a party trick, but it was cool when we were kids ;)
This was rarely used with the tape though, but rather with autoloader programs on the disk - there would be a specially crafted program that loaded itself info the system stack or variable area and overwrote some vectors, so that it would be automatically run without the need to type RUN:
LOAD "*", 8, 1 : REM 8 is the disk drive and 1 is the secondary address
I consider this mostly a party trick, but it was cool when we were kids ;)
I want to get invited to your parties.
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
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 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.
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.
Mandatory mention of Raquel Meyers' amazing Petscii art:
https://www.raquelmeyers.com/
https://www.raquelmeyers.com/
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!
Oh you!
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.