zyga64 wrote on 2026-01-16, 18:50:

I checked with the Phoenix ROM 2.27 BIOS that was originally on this motherboard (the pictures were taken with GlaBIOS 0.4.1) and the status bar is now white all the time (previously it sometimes turned brown) and the residual command characters are now white (previously it sometimes turned blue).

FYI, the developer of GlaBIOS is aware of the issue and committed a fix some time ago, but it's not yet in a release build.

ripsaw8080 wrote on 2026-01-19, 05:18:

zyga64 wrote on 2026-01-16, 18:50:

I checked with the Phoenix ROM 2.27 BIOS that was originally on this motherboard (the pictures were taken with GlaBIOS 0.4.1) and the status bar is now white all the time (previously it sometimes turned brown) and the residual command characters are now white (previously it sometimes turned blue).

FYI, the developer of GlaBIOS is aware of the issue and committed a fix some time ago, but it's not yet in a release build.

Thanks for the info, so I can build GLaBIOS with the patch myself !
I checked new build of your AGI plantronics driver and text in inventory (with Turbo XT BIOS 3.1) is no longer blinking ! Good job !

Horizontal display positioning (Ctrl+Alt+Left/Right) also works just fine !

ripsaw8080 wrote on 2026-01-16, 01:22:

The new AGI video drivers are coded by myself, and installation is easy: make sure you have a backup of the original CGA_GRAF.OVL file and then extract a replacement from either of the attached archives.

I wrote a SCi0 driver for the Olivetti PC1 160x200x16. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
I want to do one for AGI games since they are already made for 160x200 they should look great on the Olivetti PC1.

I don't have any info for writing a driver for AGI, could you maybe help?
On my github would will extensive documentation of the Olivetti PCI hidden mode. https://github.com/RetroErik/Olivetti-PC1-Hid … n-graphics-mode

Jinxter wrote on 2026-02-07, 16:09:

ripsaw8080 wrote on 2026-01-16, 01:22:

The new AGI video drivers are coded by myself, and installation is easy: make sure you have a backup of the original CGA_GRAF.OVL file and then extract a replacement from either of the attached archives.

I wrote a SCi0 driver for the Olivetti PC1 160x200x16. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
I want to do one for AGI games since they are already made for 160x200 they should look great on the Olivetti PC1.

Well, you must already be aware from SCI0 that the 40-column text drawn in graphics will be illegible, so do you view it as just an academic exercise?

Just switch to text mode whenever a text window is displayed. Just like how those old silent movies would show the lines of the actors in text on a black background spliced between the scenes. And then switch back to graphics mode when the user presses ENTER when they’re done reading.

AGI games would already freeze/pause the game whenever a text window was shown anyway. And also they would already switch to text mode whenever you checked your inventory.

It's not only about text windows. Consider a couple of examples where AGI combines graphics and text:

Also, the "LOOK <object>" command shows graphics representing the object and a text window description at the same time.

However, the main problems with "just switch to text mode" are the status bar, dropdown menus, and command input that use text drawn in graphics; and you're talking about a change in interpreter behavior, not driver behavior.

Depending on how the interpreter implements keyboard input, the video driver could intercept the keyboard interrupt for user-triggered horizontal zoom and pan functionality.
It would still be a kludge, but could be workable.

I imagine that would be easier to do for SCI0 where text is internally rendered as graphics, unlike AGI that relies on BIOS functions to render text. Are you planning to implement it?

It would be easier to do for SCI0, and it would be the most feasible thing to do for SCI0 in a genuine 160x200 pixel mode, precisely because it renders text as graphics.
For AGI, BIOS replacement routines that use a 4x8 font would make more sense. Granted, some letters are a bit tricky, but most of them work quite well.

The Amstrad and Plantronics AGI drivers actually do intercept the interpreter's BIOS call to draw text, which is necessary because BIOS doesn't know how to draw 16-color text in the non-standard modes, but BIOS still does most of the heavy lifting with my approach. The example screenshots I attached earlier are made with the Amstrad driver, which the font might give away to those familiar with it.

Your tiny font idea sounds reasonable, at least in concept, but seems like a good bit of work.

Edit: I mocked up what the tiny font would look like using an 8x8 font based on a 4x8 font doubled in width. The dropdown menus point out an AGI feature: divider lines that use custom characters. Might be able to just draw half the character, heh, or maybe identify when they're used and then provide an alternate. Anyway, I would be more inclined to pursue this challenge if there is an emulation of the hardware to test with.

ripsaw8080 wrote on 2026-02-09, 03:09:

Anyway, I would be more inclined to pursue this challenge if there is an emulation of the hardware to test with.

At first glance, the Olivetti PC1's 160x200 16-color mode looks very similar to the low-resolution Tandy / PCJr. mode, except for the frame buffer address, which is b0000h (PC1) vs. b8000h.
That means that DOSBox can be used for prototyping, and that the same driver - if appropriately written - can be used for all three systems.

(The frame buffer format is also the same for composite CGA, i.e. composite CGA might be a good starting point if low-res. Tandy code is not already available.)

Benedikt wrote on 2026-02-13, 15:21:

At first glance, the Olivetti PC1's 160x200 16-color mode looks very similar to the low-resolution Tandy / PCJr. mode, except for the frame buffer address, which is b0000h (PC1) vs. b8000h.
(The frame buffer format is also the same for composite CGA, i.e. composite CGA might be a good starting point if low-res. Tandy code is not already available.)

If your are right, here is what you need to know to enable the hodden mode, and change colors in the palette - or just keep the default CGA colors.

## ⭐ THE ONLY REQUIRED STEP:
mov al, 0x4A ; Magic value to unlock 16-color mode
out 0x3D8, al ; Write to Mode Control Register

The V6355D has an integrated **3-bit DAC per channel**, providing a **512-color palette** (8 × 8 × 8 = 512 possible colors).

### DAC Specifications:
- **3 bits per channel** (Red, Green, Blue)
- **8 intensity levels** per channel (0-7)
- **512 total colors** available (8³)
- **16 simultaneous colors** on screen (selected from the 512)
- **32 bytes** of palette data (16 colors × 2 bytes each)

### Palette Data Format (2 bytes per color):
```
Byte 1: [-----RRR] Red intensity (bits 0-2, values 0-7)
Byte 2: [0GGG0BBB] Green (bits 4-6) + Blue (bits 0-2)
```

### Palette Write Sequence:
```asm
cli ; Disable interrupts during palette write
mov al, 0x40
out 0x3DD, al ; Enable palette write mode (starts at color 0)
jmp short $+2 ; I/O delay required!

; Write 32 bytes (16 colors × 2 bytes each)
mov cx, 32
mov si, palette_data
.loop:
lodsb
out 0x3DE, al
jmp short $+2 ; I/O delay required between writes!
loop .loop

mov al, 0x80
out 0x3DD, al ; Disable palette write mode
sti
```

💡 **Speed tip:** For raster effects with 600+ OUTs per frame, use short port addresses (0xDD, 0xDE instead of 0x3DD, 0x3DE) to save ~4 cycles per OUT. See **Section 3a** for details.

Benedikt wrote on 2026-02-13, 15:21:

That means that DOSBox can be used for prototyping, and that the same driver - if appropriately written - can be used for all three systems.

Please explain how I could use dosbox to check my asm code using the hidden mode?

Jinxter wrote on 2026-02-13, 16:55:

Benedikt wrote on 2026-02-13, 15:21:

That means that DOSBox can be used for prototyping, and that the same driver - if appropriately written - can be used for all three systems.

Please explain how I could use dosbox to check my asm code using the hidden mode?

After changing the DOSBox configuration to Tandy (machine=tandy in the config file), you set video mode 8 (160x200 16-color) via BIOS and write pixel data to the frame buffer at b8000h.
That allows you to verify that the pixel output code works as expected. When you are done, you just swap the mode initialization code and frame buffer address.

AGI in 16colors on EuroPC (Plantronics) ...very cool project!

It DOES look very nice in these captures. I agree that it's very cool.

It's always good to see new things come out of old hardware.

I cant contribute anything meaningful to the discussion though. The only hardware similar to this i've ever owned was tandy graphics in a PCjr, and I no longer own one, so I cant offer testing. The US had very different machines frim Europe, and sadly many softwares are very US Centric. I'm very happy for the euro-retro hardware to have a day to shine.

I am just very pleased by this discussion and work.

I'll get out of the way and back to lurking.

I tried hacking an original JR_GRAF.OVL to use mode 8 (160x200x16) to get a better understanding of what is involved. I only did the block drawing, not the box or text drawing, and in the attached screengrab you can see the quadruple-wide characters of the command prompt. As a small bonus, the inner loop of the block drawing subroutine shaves a few CPU clock cycles off the original.

Unfortunately, the size of JR_GRAF.OVL is limited to 480 bytes because the AGI interpreters don't adapt to the size of a driver. When I first bumped into the driver size limit I figured the driver could load more of itself during initialization, but the interpreter uses the expected driver size for its memory management, so the problem is complicated without hacking the interpreter. I avoided the problem with the Amstrad and Plantronics drivers by keeping the size of CGA_GRAF.OVL under 672 bytes, which was not easy. I will look for a workaround but may have to settle for something less than elegant, such as using the CGA driver file for a universal PCjr/Tandy driver based on mode 8 and a support TSR for the 4x8 font, which could then (probably) be adapted to the Olivetti system.

Benedikt wrote on 2026-02-13, 15:21:

At first glance, the Olivetti PC1's 160x200 16-color mode looks very similar to the low-resolution Tandy / PCJr. mode, except for the frame buffer address, which is b0000h (PC1) vs. b8000h.

At second glance, I noticed this paragraph in Jinxter's documentation:

The PC1 has 16 KB of video RAM, mirrored four times in the memory map: […]
Show full quote

The PC1 has 16 KB of video RAM, mirrored four times in the memory map:

B0000–B3FFF (16 KB)
B4000–B7FFF (mirror)
B8000–BBFFF (mirror)
BC000–BFFFF (mirror)

I.e. software originally written for Tandy (or PCJr.) can keep using b8000h and all BIOS functionality for mode initialization and palette configuration can be provided via TSR.
Consequently, if there is no (unskippable) hardware detection and no direct port access, no modifications are needed.

Thx guys.

ripsaw8080 wrote on 2026-02-07, 17:37:

Jinxter wrote on 2026-02-07, 16:09:

ripsaw8080 wrote on 2026-01-16, 01:22:

The new AGI video drivers are coded by myself, and installation is easy: make sure you have a backup of the original CGA_GRAF.OVL file and then extract a replacement from either of the attached archives.

I wrote a SCi0 driver for the Olivetti PC1 160x200x16. https://github.com/RetroErik/Sierra-SCI0-Driv … or-Olivetti-PC1
I want to do one for AGI games since they are already made for 160x200 they should look great on the Olivetti PC1.

Well, you must already be aware from SCI0 that the 40-column text drawn in graphics will be illegible, so do you view it as just an academic exercise?

Well not just for academic reasons. I have managed to use a CGA palette flip method to view images in 320x200 in "lots" of colors.
Here are som images that i have tested on.
What makes this possible with so many colors is that we can choose 3 of the 512 colors on the PC1 for each scanline.

Update: I tried CGA palette flipping using the PC1's 512-color palette, but per-scanline streaming requires a 16ms VSYNC sync per update_rect call — and SCI calls it dozens of times per frame, making screen draws take minutes. But the technique that works for static images is too slow for games — each screen update needs to wait for the monitor's refresh, and games update the screen dozens of times per frame.