The camera can be found under:
www.swissdigitization.ch/public/c64camera/
or at the very end for downloading as a large local website.
Behind the idea of a C64-MultiColorCamera is the “interesting” organization of the display/memory of the C64 (and also other 8Bit computers see Apple/Atari XE etc). These video memory concepts were more or less a hardware compression method to save expensive RAM. The multicolor (graphic) screen was 160×200 pixels. The video screen and thus the memory was not simply continuous, but was additionally “furrowed” or structured. The screen consisted of 4(x)*8(y) blocks with their own color logic. Only 4 colors were allowed – but the background color was the same for all of them! So there were actually only 3 designable colors in one block! The 4 colors can be selected from the 16 predefined colors. A block contained only 4 possible colors from 0-4, which required 2^2 per pixel or in other words a 1/4 byte. This makes a more colorful image possible than just 4 colors on the screen. The disadvantage is that it is difficult to create an image that works visually. It requires massive adjustments to this constantly changing (Sudoku) logic (manual rendering). This often results in small blocks with more uniform colors and therefore areas.
More about this:
https://research.swissdigitization.ch/?p=1495
Resolution, colors, color space, memory consumption
Here you can see how much the “block compression” affects a total memory of 64KB on the C64:
C64-MulticolorMode- (MultiColorMode)
160×200 Pixel in Blocks > 40×25 Blocks.
1 Block: 4*8 Pixel Graphic data + 3 Color datas > Codings only 0-3 > (4*1/4b)*8 Bytes + (3*1/2 Bytes) = 8+1.5
Total: 40*25*9.5 = 9.5 kb + 1b
16 MultiColor – Not existing ! (Comparison)
160*200 Pixel
1 Pixel: 16 Colors = 2^4 = 1/2 Bytes
Total: 160*200*1/2 = 16 kb + 1b
How well this compression works is sometimes impressive, at least with camera images. The loss is actually very small. However, the effort involved in designing these restrictions for games is also enormous.
Im MultiColorMode (Graphics).
The wrong colors (Too many colors in a block):
A version with all 16 colors in all 160×200 pixels.
It also shows how creative the PixelArtists of then and now are, tickling images like the following out of the C64 (Roman Werner with his 2024 Game „Timo’s Castle‚):
Social
You can even ask yourself socially what this reflects, perhaps you can even “see” the individualism that emerged in the 80s, in which of course a lot of local logics prevailed. The same can be seen – with some imagination – in the perspectives in the games, where different perspectives are also mixed by hand in a game. The system is not yet normalized, the 3D engines of first-person shooters, for example, do not yet exist, nor is it possible to choose every perspective (compare https://www.gamelab.ch/?p=10109). You could perhaps say that the C64 reflected a society that was in the process of individualizing itself and was always starting to think in smaller blocks and slowly ‚bought‘ or fought for larger blocks economically. The cameras of the 80s were virtually block-based.
Camera – the always updated world – automatic digitization
These constructed images (hand digitization) were already artistic in themselves and the games always played in a very unique world (if they were based on analogue space at all). But what would the world look like with automatic digitization – as we know it today? A view through this C64 world, so to speak.
A small answer is the C64 MultiColorMode Camera
The first idea to deal with the C64 came about a year ago. There is also a short blog entry about it here.
Other approaches
It turned out that someone had of course already done this on the iPhone (AppStore but no longer online) or generalized here: famicam.
What all these projects have in common – as far as I can see – is that they usually simply take the color palette and selection and then implement them. In most cases, the resolution is also not correct. So they are nothing more than adjustable filters. Everything as far as I could try them out.
But this is exactly what ultimately rewrites history, because the Sudoko display of the C64 could not be used as a direct digitalization if you wanted to get everything out of it.
Development
The initial idea was to develop the whole thing as a mobile phone app. But this is expensive – SWIFT is too much of a university idea. And somehow just not fun to do.
That’s why the idea was to do it with Processing, which today can also be easily “exported” to a phone. But then came the 2000 question: ok, why not just do it as a web project. Then everyone can use it. And in the future too. It won’t be trapped in an app silo and will run on any computer without any problems.
And yes, of course, it works quite well today with the integration of cameras. As a framework p5js.org was used.
p5js
In p5js there are also a number of simple options for screen capturing. There are usually problems with the access request to the webcam etc.
A WebApp
Because the screen of the C64 should be emulated as “authentically” as possible. The following steps were taken:
1. capturing the camera
2. creating a 160×200 pixel image with C64 colors
For this purpose, the color distance was calculated in the classic way, the background color was determined (most common color) and it is looked at what is closest to a C64 color. A special weighting was used to determine the most diverse colors.
// col is the current pixel color, while col64 is one of the 16 C64 colors. Fact is the specific factor of the weighting of this color.
// Colors and factors
- division into blocks and determination of the “most important” 3 colors (in addition to the background color).
This means counting the colors and then sorting them. - if the block had a maximum of 4 colors (including background color), everything was OK. If it had more than 4 colors, a further adjustment of the “false colors” to the selected 4 colors.
Display
The display of the screen was made with small circles. As a kind of simulation of the punch card aesthetics of CRT screens. This could of course be improved.
In addition to the normal image, there is also the option of highlighting the blocks and displaying the wrong colors.
Die Farben, die nicht in einen Block passen sind hier maximal Rot dargestellt.
Findings
The world can be experienced in a new way with the camera. The technical realization of the C64 and 1982, so to speak, and also in comparison to the video format.
The C64 world is very flat. With 16 predefined colors (and 4*8 pixel blocks with 4 colors [one of which is the background color for all]), this is to be expected – despite the Sudoku effect.
Of course, you should also be able to see what the whole thing would have looked like in just 4 colors. This would certainly require a mode that does not yet exist.
Interestingly, the false colors play less of a role in the camera than in games. The images appear quite flat from the outset and it is only at the edges or on specific objects that the colors become problematic. Of course, this also shows that hand-made images are much more ’symbolic‘ and detailed than our view of the analog world through a camera.
Ultimately, a game also tries to depict an analog scene – such as a living room (e.g. Maniac Mansion) in 160×200 pixels. This means that many more objects are visible and need to be displayed.
In principle, the WebApp can help to bring people closer to the specifics of 80s displays. And perhaps we will see “real” retro games on modern computers in the future.
ToDos
An optimization using a color C64 color pool is still missing.This development has been started, but there is a bug that is simply not visible.
Create a more sophisticated version with the colors. Try to find an ‚designer‘-algorithm. All colors are used in the picture – even if they are not ‚correct‘.
Try to create a petscii-version on top of this.
Release
The CameraWebApp is released on the occasion of the DemoSceneEvent moutainbytes.ch.Here, a community seems to understand what it’s all about, at least to some extent. See also the AppStore apps. Furthermore, an attempt will be made to make the app better known in the entire gamestudies sector.
Project-Sources
Will be uploaded after the project has been published.