My world view was based on news from computing magazines and messages embedded in demos (i.e. bizarrely limited compared to today) but at that time I was pretty sure I was the first who “opened” the middle of the C64’s side border to create an edge-to-edge horizontally scrolling text: https://csdb.dk/release/?id=742. My friend and co-crew member of the 1001 Crew helped set up a museum exhibition display featuring side border sprites last year: https://twitter.com/JoostHonig/status/1448624117289193478. We’re still in touch and like to reminisce about the good old 8-bit times. I’ll study this article at some later time to see if I can still match their approach with mine. I really should look at my code and annotate it some day.
I guess there are not that many that truly understands the effort and commitment needed to get a seemingly trivial thing by today’s standards such as this. Well, I do at least :)
A truly awesome achievement.
Very well done, Raistlin and Sparta!
I never used a C64 (first computer used was a 386 with VGA graphics), but I've seen in descriptions/videos it has a screen border that you only can change the color of (plus the occasional effects like this one here that manage to do something with the border).
I know that systems like the C64 had limited memory and graphics capabilities, but still I'd like to ask the question about this:
What's the reason for having a large screen border? If it doesn't have enough memory to display text/graphics on the entire screen, why not instead make the text/center part bigger with larger pixels so more of the glass tube surface area of the monitor is used for something useful?
https://en.wikipedia.org/wiki/Overscan: “Overscan is a behaviour in certain television sets, in which part of the input picture is shown outside of the visible bounds of the screen. It exists because cathode-ray tube (CRT) television sets from the 1930s through to the early 2000s were highly variable in how the video image was positioned within the borders of the screen. It then became common practice to have video signals with black edges around the picture, which the television was meant to discard in this way.”
Basically, you couldn’t trust two televisions to show a picture at the same size, or even a single television to show an image at constant size if it heated up.
Computer users would object if their screen chopped of some letters at the edge of their screens, so they had to accept the reverse: wasted space around the screen’s contents.
You have borders because you want the image to be inside of the title safe area and then the layout is constrained because the chip is designed to show a 40x25 character area of characters 8 pixels wide, and outputting 8 pixels takes exactly as much time as one clockcycle of the cpu, they execute in lockstep.
And of course you can’t just zoom in a little because a character is 8x8 pixels and the video signal has a fixed number of lines on the screen so 25 characters of 8 lines tall is just a fixed part of the screen (which is 312 lines tall on PAL).
In hindsight it is a bit silly that there is no easy way to display sprites over the borders though, to do that you have to wait until the video chip is displaying the last character and then configure the screen a bit less wide/tall so it oversteps the end and never stops outputting.
It is not a matter of quantity of memory. (One screen worth of content is just 1000 bytes - 40x25 chars)
Do not forget that the physical pixels sit on real rasterbars on a cathodic ray tube machine.
If you made the centered content bigger, first of all the effect would simply be ugly - stretched;
if you expanded the content per bar (over the 40ch, 320px) but keep the same ratio, you'd have less warranties that the set would make it visible;
similarly for using more rasterbars than 200 (taking into account that compatibility with NTSC basically imposes a limit at 240): will every set display all the lines or will you cause frustrated users?
(And of course, given the shape of the screen, if you filled it up with a rectangular matrix you would surely lose displaying the content at the corners.)
As others said in a different way: there was a safe area.
The 6510 processor can accesses memory only on every other clock cycle. So half of all clock cycles can be used by the VIC to get display data out of memory, without fearing contention with the CPU.
But this means that pixels must be output at the rhythm of the processor's clock. If you wanted to make the pixels 10% wider, you'd have to slow down the clock driving the VIC, but then it wouldn't be able to interleave memory access with the processor anymore.
Not entirely sure this is the true reason since my knowledge is patchy, but it's my guess.
I don't think I could even remotely write one of the cracktros I used to.
I seem to remember it all had something to do with interrupt timing. You had to fill with NOPs in order to get the timing right.
Same here. I actually still have some of the code for a few of my intros and demos, but I look at it now and it's like just total gibberish to me. That knowledge is LONG gone from my brain... I can't even remember how to compile it anymore!
My world view was based on news from computing magazines and messages embedded in demos (i.e. bizarrely limited compared to today) but at that time I was pretty sure I was the first who “opened” the middle of the C64’s side border to create an edge-to-edge horizontally scrolling text: https://csdb.dk/release/?id=742. My friend and co-crew member of the 1001 Crew helped set up a museum exhibition display featuring side border sprites last year: https://twitter.com/JoostHonig/status/1448624117289193478. We’re still in touch and like to reminisce about the good old 8-bit times. I’ll study this article at some later time to see if I can still match their approach with mine. I really should look at my code and annotate it some day.
I remember vaguely that you’d have to catch the raster then “do something” I forget (scroll registers come to mind).
Love the effect and the in-depth write up!
I guess there are not that many that truly understands the effort and commitment needed to get a seemingly trivial thing by today’s standards such as this. Well, I do at least :)
A truly awesome achievement. Very well done, Raistlin and Sparta!
I never used a C64 (first computer used was a 386 with VGA graphics), but I've seen in descriptions/videos it has a screen border that you only can change the color of (plus the occasional effects like this one here that manage to do something with the border).
I know that systems like the C64 had limited memory and graphics capabilities, but still I'd like to ask the question about this:
What's the reason for having a large screen border? If it doesn't have enough memory to display text/graphics on the entire screen, why not instead make the text/center part bigger with larger pixels so more of the glass tube surface area of the monitor is used for something useful?
https://en.wikipedia.org/wiki/Overscan: “Overscan is a behaviour in certain television sets, in which part of the input picture is shown outside of the visible bounds of the screen. It exists because cathode-ray tube (CRT) television sets from the 1930s through to the early 2000s were highly variable in how the video image was positioned within the borders of the screen. It then became common practice to have video signals with black edges around the picture, which the television was meant to discard in this way.”
Basically, you couldn’t trust two televisions to show a picture at the same size, or even a single television to show an image at constant size if it heated up.
Computer users would object if their screen chopped of some letters at the edge of their screens, so they had to accept the reverse: wasted space around the screen’s contents.
You have borders because you want the image to be inside of the title safe area and then the layout is constrained because the chip is designed to show a 40x25 character area of characters 8 pixels wide, and outputting 8 pixels takes exactly as much time as one clockcycle of the cpu, they execute in lockstep.
And of course you can’t just zoom in a little because a character is 8x8 pixels and the video signal has a fixed number of lines on the screen so 25 characters of 8 lines tall is just a fixed part of the screen (which is 312 lines tall on PAL).
In hindsight it is a bit silly that there is no easy way to display sprites over the borders though, to do that you have to wait until the video chip is displaying the last character and then configure the screen a bit less wide/tall so it oversteps the end and never stops outputting.
It is not a matter of quantity of memory. (One screen worth of content is just 1000 bytes - 40x25 chars)
Do not forget that the physical pixels sit on real rasterbars on a cathodic ray tube machine.
If you made the centered content bigger, first of all the effect would simply be ugly - stretched;
if you expanded the content per bar (over the 40ch, 320px) but keep the same ratio, you'd have less warranties that the set would make it visible;
similarly for using more rasterbars than 200 (taking into account that compatibility with NTSC basically imposes a limit at 240): will every set display all the lines or will you cause frustrated users?
(And of course, given the shape of the screen, if you filled it up with a rectangular matrix you would surely lose displaying the content at the corners.)
As others said in a different way: there was a safe area.
I'm guessing it's because of memory access.
The 6510 processor can accesses memory only on every other clock cycle. So half of all clock cycles can be used by the VIC to get display data out of memory, without fearing contention with the CPU. But this means that pixels must be output at the rhythm of the processor's clock. If you wanted to make the pixels 10% wider, you'd have to slow down the clock driving the VIC, but then it wouldn't be able to interleave memory access with the processor anymore.
Not entirely sure this is the true reason since my knowledge is patchy, but it's my guess.
I'd encourage anyone interested to download VICE and try putting a sprite in the sideborder yourself. It's quite satisfying to see it working!
What are your favourite tools for efficient C64 coding nowadays?
When I was messing around with C64 programming, I used dasm (https://dasm-assembler.github.io/) and the VICE emulator (https://vice-emu.sourceforge.io/). But I'm sure there are better tools out there. This text file is a fantastic reference on the VIC-II video chip: http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
These are basic, but free and will get you going quickly:
CBMPrgStudio is a solid free windows app. I like cross-platform WinVICE for it's great monitor.
Once you get to be an expert, people seem to use C++ to synthesize their own 6502 routines.
Additionally: where is a good place to start for learning about C64 (demo) programming?
I recently got a cheap as chips 1541, now I just need to get ahold of my C64-C that stuck in my mother's garage about 1500 miles away!
I know my way around Amiga demo programming, but would love to have a go at C64 too.
coodebase64.org is a decent place to start.
codebase64.org of course. 8-(
I knew all those techniques once, back in the day when I was 11, with a Final Cartridge and a curious mind.
Nowadays I just operate https://c64g.com/
I don't think I could even remotely write one of the cracktros I used to. I seem to remember it all had something to do with interrupt timing. You had to fill with NOPs in order to get the timing right.
Same here. I actually still have some of the code for a few of my intros and demos, but I look at it now and it's like just total gibberish to me. That knowledge is LONG gone from my brain... I can't even remember how to compile it anymore!
Why is the loader critical? Does it load from disk while the demo is running?
Yes.
Naturally the coding wizard is named Raistlin.