Printing Petscii Faster

Posted3 months agoActive3 months ago

ibobev

44 points

11 comments

retrogamecoders.comTechstory

calmpositive

Debate

20/100

Retro ComputingOptimizationC64

Key topics

Retro Computing

Optimization

C64

The article discusses optimizing PETSCII printing on the Commodore 64, and the HN discussion revolves around the technical details and nostalgia for retro computing.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

Peak period

96-108h

Avg / period

5.5

Comment distribution11 data points

Loading chart...

Based on 11 loaded comments

Key moments

01Story posted
Oct 10, 2025 at 6:20 PM EDT
3 months ago
Step 01
02First comment
Oct 15, 2025 at 12:22 AM EDT
4d after posting
Step 02
03Peak activity
6 comments in 96-108h
Hottest window of the conversation
Step 03
04Latest activity
Oct 15, 2025 at 11:41 AM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (11 comments)

Showing 11 comments

1313ed01

3 months ago

3 replies

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.

Someone

3 months ago

1 reply

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.

michalpleban

3 months ago

1 reply

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 ;)

satiated_grue

3 months ago

I want to get invited to your parties.

classichasclass

3 months ago

You can approximate BLOAD with SYS calls. Something like SYS57812"FILENAME",8,1:POKE780,0:SYS65493 will do it.

dusted

3 months ago

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.

mkesper

3 months ago

1 reply

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.

vanderZwan

3 months ago

> it's basic knowledge

Oh you!

dobin

3 months ago

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.

Cockbrand

3 months ago

Mandatory mention of Raquel Meyers' amazing Petscii art:

https://www.raquelmeyers.com/

dusted

3 months ago

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

View full discussion on Hacker News

ID: 45544500Type: storyLast synced: 11/20/2025, 2:38:27 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN