So, apparently it is possible to use the 16 color mode for games.
In this video two guys are working on a game that use that mode.
https://youtu.be/surHot72dqc?si=gIYWB2XzVLdwcLW2

They find out how to use this mode because it is documented on the manuals of the Zenith SuperSport that use the same Yamaha V6355D video chip.

I recapped my PC1
Here is a recap video by Edy Cipolat Bares: <https://youtu.be/oUXaQp2Gwq4

My PC1 was very clean inside, so when opening it i thought that maybe someone had recapped it already, but looking at the soldering there was no sign that this was done. So i continued with the recapping. Only thing i noticed was that there where 6 (not 5) 22 µF – 16 V, and that the C4 was 22 µF – 25 V on my MB. Except for this there was nothing else to do, since it was clean and nice inside.

I have now created a github repo for my Turbo.asm.

https://github.com/RetroErik/Turbo-for-Olivetti-Prodest-PC1

A DOS utility program written in x86 assembly that controls the Turbo mode (CPU speed switching) on the Olivetti Prodest PC1 retro computer.

Features
Toggle between Normal (4.77 MHz) and Turbo (8 MHz) modes
Simple command-line interface
Updates both hardware ports and BIOS flags for proper mode switching
Supports multiple argument formats (e.g., /T, TURBO, /N, NORMAL)

I have created a program that changes the CGA palette to any of the 512 colors - on the PC1.

Features
Loads custom 4-color palettes for CGA and Textmode
3 built-in presets for quick palette switching
Supports human-readable text file format with comments - You can choose any color from the 512 palette!
Works with all CGA palette modes (palette 0/1, low/high intensity)
Displays loaded colors with colored blocks
Fallback to standard CGA palette if file missing or started with /r

Please share experiences. What colors did you choose on your games.

I've created a utility that displays BMP images on the Olivetti Prodest PC1's hidden 160x200x16 graphics mode. The program supports 4-bit uncompressed BMP files and automatically downscales 320x200 images to fit the 160-pixel width. It includes C64-style loading effects (border color cycling, cyan/red flashing during the pilot phase, and a white flash on completion).

Features:

Supports both 160x200 and 320x200 resolution images
Automatic downscaling of 320x200 images
Custom palette support from BMP files - can use any palette, even c64, Amstrad CPC, ZX Spectrum and more.
Authentic C64-style loading effects
PERITEL.COM compatible (preserves horizontal position settings)
Clean exit with proper palette restoration

Just pushed the limits of the Olivetti PC1's graphics mode! By rapidly switching the color palette multiple times during each scanline (DURING HBLANK, while HSYNC HIGH), I trick the display into showing hundreds of colors across the screen—even though the hardware can only display 16 colors at once.
The result is a smooth gradient that would be impossible with the standard 16-color limitation. This is the same trick professional demoscene artists used on 1980s hardware!
This is the exact same technique behind classic raster bars and demoscene productions!

Impressive Jinxter, good work, ages ago I managed the very same trick, is possible to change 4 color per rasterline (alternating 2 CGA palette) and 320x200 with "virtually" 512 colors

simone2016 wrote on 2026-02-04, 22:22:

Impressive Jinxter, good work, ages ago I managed the very same trick, is possible to change 4 color per rasterline (alternating 2 CGA palette) and 320x200 with "virtually" 512 colors

Nice done. I did not think if this.
I will continue to investigate the PIT option. The same method used in 8088MPH and Area5150.

I just uploaded my Sierra SCI0 driver to github. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
It works, but the conversion from 320 to 160 makes text hard to read.
Also no mouse support.

Jinxter wrote on 2026-02-06, 12:10:

I just uploaded my Sierra SCI0 driver to github. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
It works, but the conversion from 320 to 160 makes text hard to read.
Also no mouse support.

Cool work, nonetheless.

Doesn't 160x200 happen to be exactly the resolution of earlier Sierra AGI games, though? (That's probably also why those SCI games look so "AGI-like" in your screenshots. 😁)

It would be cool to get AGI games working at their intended 160x200 graphics resolution in 16 colors on the Prodest, even though text would still be an issue. But you could briefly switch modes and show the text in text mode and switch back once the user presses ENTER, since AGI games would always pause whenever a text window was shown anyway. Of course the AGI interpreter didn't have separate video driver files like the SCI interpreter did, so patching such games would be a lot harder. Perhaps start with the sources of a third-party AGI interpreter like Sarien or NAGI, or the AGI module in ScummVM that I believe is derived from Sarien?

digger wrote on 2026-02-06, 17:01:

Cool work, nonetheless.

Doesn't 160x200 happen to be exactly the resolution of earlier Sierra AGI games, though? (That's probably also why those SCI games look so "AGI-like" in your screenshots. 😁)

It would be cool to get AGI games working at their intended 160x200 graphics resolution in 16 colors on the Prodest, even though text would still be an issue. But you could briefly switch modes and show the text in text mode and switch back once the user presses ENTER, since AGI games would always pause whenever a text window was shown anyway. Of course the AGI interpreter didn't have separate video driver files like the SCI interpreter did, so patching such games would be a lot harder. Perhaps start with the sources of a third-party AGI interpreter like Sarien or NAGI, or the AGI module in ScummVM that I believe is derived from Sarien?

AGI does not a driver system like news Sierra game engines (as you said). I would have to disassemble the AGI interpreter. But it would with perfect with the 160x200 in 16 colors resolution. In AGI text would not be an issue, since it was designed for that resolution. I have shared full documentation of the V6355D videochip on github, so I hope someone steps up and creates a AGI driver.

Regarding the poor text readability when going from 320 to 160, there are options out there to fix this. But since this must happened in the same operation that copies a rectangle from RAM to VRAM, you cannot do much before it really hurts performance. I will probably circle back to this driver later. But for know i want to explore using all 512 colors on one screen. So far, I have managed to change color per line give us 200 colors on one screen. Now I am working on different methods of changing color per scanline.

Great Scott!
wonderfull, good word indeed

Jinxter wrote on 2026-02-06, 12:10:

I just uploaded my Sierra SCI0 driver to github. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
It works, but the conversion from 320 to 160 makes text hard to read.
Also no mouse support.

THE HERO TECHNIQUE
I think i have invented a new technique to get more colors in CGA mode on the PC1.
CGA 320x200x4 mode with per-scanline V6355D palette reprogramming.
As we can see it has it's limitations. But it better then only 3 (+ black) colors.

THE TECHNIQUE:
THE HERO TECHNIQUE (optimized with 0x44 start + OUTSB + skip-unchanged):
CGA mode 4: 2 bits per pixel, values 0-3.
Always uses palette 0 (no palette flip). Mapping:
Pixel 0 = entry 0 = black (background/border), fixed
--> Pixel 1 = entry 2 = per-scanline "hero" color (changes every line)
Pixel 2 = entry 4 = global color A (most common, fixed)
Pixel 3 = entry 6 = global color B (2nd most common, fixed)

During each HBLANK (~80 cycles), only palette entry 2 is updated.
Starting at register 0x44 skips entries 0-1 entirely (proven on V6355D hardware). OUTSB replaces LODSB+OUT for faster streaming.

The two global colors (entries 4 and 6) are programmed once before the display loop begins and remain constant throughout.

Big breakthrough. With some help from Simone i managed to use real CGA palette flips per scanline. Basically this means i can change all three colors individually per scanline, which technically give us all the 512 colors in the PC1 palette.

I have made a new version of my BMP viewer.
Its called PC1-BMP3.com and it opens 320x200x16 bmp files and display them in CGA 320x200x4 mode. But with the CGA palette flip we get more colors.

Good work jinxter, almost 320x200 x 16 colors fidelity
A new game using at maximum this feature would be fantastic... imagine an horizontal scrolling game with sky & terrain with 10/12 shades of color and a game with 30/40 colors in CGA
and with 320x200 pixels...

I have an idea...
what happen if we switch resolution on the fly (mid scanline)? from 320x200 to 160x200? we can have some line with less resolution but more colors...

simone2016 wrote on 2026-02-15, 15:47:

I have an idea...
what happen if we switch resolution on the fly (mid scanline)? from 320x200 to 160x200? we can have some line with less resolution but more colors...

Thanks.
If i am not mistaken 8088MPH switched resolution mid screen. Maybe not during scanline, but between scanlines. They used a timer in the CGA chip. We dont have that on the PC1. I tried using the PIT but it created a lot of noise on the screen. But i still think its possible.

Today I found a method to send to different interlaced pages to video, obtaining a wonderful 640x400 mode!
Se the attached images (sorry the quality but there is some ghost due to poor cable). In the upper and lower screen you can see the default 8x8 character, in the middle there are the same chars but in 8x16 resolution (VGA like!)
No flickering because is the normal way TV set output interlaced mode @30Hz (Obtainable only with SCART cable to a TV)

So we have to install another 16kb of video memory to work full screen (image linked is the maximum to display in double resolution without hardware mod)
We can swap the two 4416 DRAM to 4464 to obtain a total of 64k video memory and set some register...

And so we can double effective vertical resolution to 640x400 B/N (crisp!), also 320x400x 4c (weird) and 160x400x 16c (maybe too much!)