The hidden 640x400 graphics mode on the QX-16

[vprada]

After spending a lot of time reverse-engineering the QX-11 video system, I became curious about the QX-16. Both machines use the same 640×400 monitor, and their 80-column text modes look virtually identical, so I wanted to know whether the QX-16 could also display true 640×400 bitmap graphics.


The QX-16 BIOS only exposes the usual IBM-compatible 640×200 mode, but the QX-16 technical documentation describes an internal mode called VM6. VM6 uses the full 32 KB of video RAM as a 640×400, 1-bit framebuffer, divided into four interleaved 8 KB banks. Its memory organization is very similar to Hercules graphics, except each row is 80 bytes instead of 90.


By setting BIOS mode 6 for the correct display timing, then selecting VM6 through the APX-ICRT control registers, I was able to address all 400 scanlines independently. We confirmed the mapping with test patterns and a full-screen diagonal, then adapted the Sierra SCI driver previously created for the QX-11.

There is a full description of what I did in my github in case you are interesting on those dirty details.... QX-16 VMM6 640x400

The end result is a working custom QX-16 SCI driver that converts Sierra’s 320×200 framebuffer into a dithered 640×400 monochrome display. This appears to be a real native capability of the QX-16 hardware that was not normally exposed through its standard BIOS modes.

 

[Eudimorphodon]

VM6 uses the full 32 KB of video RAM as a 640×400, 1-bit framebuffer, divided into four interleaved 8 KB banks. Its memory organization is very similar to Hercules graphics, except each row is 80 bytes instead of 90.

I was scanning through your analysis on the github, and it says the 32K framebuffer memory is aliased at both B000 and B800? I may be misremembering, but isn't the 640x400 mode that's available on the AT&T 6300/Olivetti M19 (that also showed up in a partially compatible form in a number of other places, like Toshiba and Compaq LCD/Plasma portables) also four-way interlaced like this? If that's the case it would seem like it might be pretty trivial to port software that uses that mode to run in this mode on the QX-16?

(Again, this is a rusty memory, but I think the common thread for most of the machines that had this mode is they'd include a BIOS extension that would let you enable it by setting mode 40h through the int10h video mode set call? If the memory mapping is really the same you might be able to make some drivers work just by coming up with a TSR that hooks this call?)

 

[vprada]

Im not sure about the olivetti or AT&T.. As I mentioned in the github, the vram mapping is really close to what Hercules uses. If yhe Olivetti uses the same vram interlaced mapping, then you are right...creating a BIOS extension that sets this VM6 mode via a int 10 call would make the QX-16 ( and Qx-11) compatible with software written for this video mode.

What I know for sure is that EPSON created this mode to take advantage of the monochrome high resolution monitor that comes with the QX-1x series (QX-10, QX-11 and QX-16 all can use the same HR green monitor)

 

[vprada]

I forgot to mention this, documentation also list a 160x100 16 colors graphics mode. I believe there is a custom sierra video driver for olivetti that render at 160x100x 16 colors resolution, would you may not be that far off in your memories....

 

[Eudimorphodon]

What I know for sure is that EPSON created this mode to take advantage of the monochrome high resolution monitor that comes with the QX-1x series (QX-10, QX-11 and QX-16 all can use the same HR green monitor)

The AT&T/Olivetti also came with a high-resolution mono monitor (25Khz horizontal refresh?). Anyway, yeah, I looked it up and mode 40h on those machine is a four-way interlace with lines chunked at B8000, BA000, BC000, and BE000, so if the QX-16 VRAM is aliased at those locations it seems like it should be a pretty low-hanging fruit to patch it up so the QX-16 can use software supporting this mode. (There's quite a lot, including GEM and Windows drivers.)

 

[Martin Hepperle]

The same 4-times interlaced memory layout was also used in the HP Vectra (80286) Multimode video adapter (640 x 400 pixels, monochrome).
At the time I patched Borland's drivers for the AT&T6300 to be usable on the Vectra. They also had drivers for Windows 1.x and 2.x with HP branding.
The nice thing of the 640 x 400 resolution was an almost square pixel ratio, compared to the EGA and Hercules cards (not to speak of the ugly 640 x 200 resolution; VGA came later).

Martin

 

[DeltaDon]

I'm not able to follow all of this as I'm far from being a software/hardware guru, but I'm interested in what you all come up with. So my thanks goes out to those that can figure this out.

 

[Zare]

Im not sure about the olivetti or AT&T.. As I mentioned in the github, the vram mapping is really close to what Hercules uses.

Well I'm pretty much sure this is Olivetti 640x400 1bpp format; four sets of rows beginning at B8000, BA000, BC000, BE000, 80 bytes per line, 8 px/byte.

With Hercules having different geometry, it is easier for you to try using "Olivetti M24 / AT&T 6300" graphics as base.

You can see it close to Hercules, but that is a trait of 6845 CRTC everywhere in these "solutions", it implies row-interleave format. In that context, it is not actually similar to Herc due to geomerty, seems to be exact match for Oli graphics.

In my opinion - if you want "hi res" application support, disassemble and patch the BIOS with mode 40h handler.
Since it's just a normal few-instruction stanza for CRTC and other regs, it could be trivial as perhaps no relocations/repointings would be needed.
Perhaps a free-account LLM session is able to do it - I found it not bad for trivial assembly stuff such as regular PC BIOS or VGA BIOS routines and services.

 

[vprada]

I should be able to implement the int 10 function 40 easily and see how it goes.

The 640x400 on the QX-11 and QX-16 use those 4 segments B8000,ba000,bc000,be000 but for what I read the M19 puts all the odd rows in two consecutive segments and all the even rows in the other 2 segments.. so there is a difference there....

on the EPSON implementation rows alternate .. row 1 segments one,row 2 segment 2 ..row 3 segment 3, row 4 segment 4, row 5 segment 1 and so forth...

 

[Zare]

row 1 segments one,row 2 segment 2 ..row 3 segment 3, row 4 segment 4, row 5 segment 1 and so forth...

On M24 graphics

row 1 B8000 (eg. "segment 1")
row 2 BA000 segment 2
row 3 BC000 segment 3
row 4 BE000 segment 4
row 5 B8000 + 80 bytes segment 1

Which should read as a same thing?

M19 puts all the odd rows in two consecutive segments and all the even rows in the other 2 segments.. so there is a difference there....

M19 supports this but the mode is called after M24 so it's better to use it to avoid confusion.

The even/odd rows on M24 are not consecutive, they are just doubled even-odd CGA, even-odd-even-odd.
The segments are interleaved just like on CGA.

So, if this is the case for QX graphics, it should match.

As a sidenote, I think that it would be harder to accomplish what I presume is the layout you describe. Even-odd(-even-odd) layout is a consequence of using 6845.
Personally I haven't look into detail all the variants of PC graphics using a Motorola CRTC but each one I know has the row interleave, even if it has 128 or more KB of RAM.
The extra RAM will be organized to work with existing row interleave. Typically, it is extra depth bitplanes organized in the same fashion, so the CRTC remains the same but video generator deals with more planes/bits for image generation.

 

[vprada]

On M24 graphics

row 1 B8000 (eg. "segment 1")
row 2 BA000 segment 2
row 3 BC000 segment 3
row 4 BE000 segment 4
row 5 B8000 + 80 bytes segment 1

Which should read as a same thing?



M19 supports this but the mode is called after M24 so it's better to use it to avoid confusion.

The even/odd rows on M24 are not consecutive, they are just doubled even-odd CGA, even-odd-even-odd.
The segments are interleaved just like on CGA.

So, if this is the case for QX graphics, it should match.

As a sidenote, I think that it would be harder to accomplish what I presume is the layout you describe. Even-odd(-even-odd) layout is a consequence of using 6845.
Personally I haven't look into detail all the variants of PC graphics using a Motorola CRTC but each one I know has the row interleave, even if it has 128 or more KB of RAM.
The extra RAM will be organized to work with existing row interleave. Typically, it is extra depth bitplanes organized in the same fashion, so the CRTC remains the same but video generator deals with more planes/bits for image generation.

can you point me in the direction os an application that uses these M24 high resolution mode? I can surely test it and verify what's the behavior on my Epson machines...

 

[Plasma]

can you point me in the direction os an application that uses these M24 high resolution mode? I can surely test it and verify what's the behavior on my Epson machines...

Windows 3.1 includes an "Olivetti/AT&T" display driver for 640x400 monochrome. It also works with compatible Toshiba laptops such as the T1200XE.

 

[Zare]

http://www.symphoniae.com/elw/sierrautil.zip , att320.drv, att320.doc in there is SCI0 driver which you can copy to SQ3 directory and run install to pick it up.
If you want to see some sources, https://www.seasip.info/Gem/drivers3.html you can find source code for the GEM driver in asm, and https://github.com/jhhoward/MicroWeb/blob/master/src/VidModes.cpp is a new mtcp web browser for dos that supports this mode, so you can start digging from the enums/consts set for "M24" in that file.

But the programming is rather easy and clear. Enter mode 40h and fill up RAM bytes per the layout.

All the necessary details can be found here https://www.seasip.info/VintagePC/cga.html , down in the "M24" section, last sentence describes the RAM layout.
Dare I say anyone implementing such thing today like microweb browser will end up using John Elliot's website as reference.

 

[vprada]

Windows 3.1 includes an "Olivetti/AT&T" display driver for 640x400 monochrome. It also works with compatible Toshiba laptops such as the T1200XE.

QX-11 & QX-16 are both 8088 machines..I may need more than a video driver to run win 3.1 on them...

 

[Zare]

3.1.026 beta version runs in real mode, you can get it on Winworld, M24 driver is built in.

 

[vprada]

3.1.026 beta version runs in real mode, you can get it on Winworld, M24 driver is built in.

Understood ... forgot to add ... 8088 ... no hard drive ... just two 360k floppy drives

 

[Eudimorphodon]

QX-11 & QX-16 are both 8088 machines..I may need more than a video driver to run win 3.1 on them...

They'll run Windows 3.0 (badly), and I suspect the M24 driver also exists in Windows 2.x, if not even in 1.x.

If Windows is too fat of a target GEM has a driver for it, and so do programs like PC Paintbrush. Because it showed up in quite a few business machines it's one of the best supported "SuperCGA" video cards there is... but FWIW, almost all that support is "business software", I doubt there were many games for it.

As a sidenote, I think that it would be harder to accomplish what I presume is the layout you describe. Even-odd(-even-odd) layout is a consequence of using 6845.

Here's an overly wordy explanation of why line interlace is a thing on these machines.

Here's the theory of operation manual for the m24; the important parts for this conversation are on page 5-14, and for context you also need to know what's going on with the original CGA; here's a redone schematic for it, important part is on page 2. Also, when I refer to the M24's address lines I'm *only* talking about the "PC modes", the proprietary 512x256 mode it supports *only* when a Z8000 card is plugged in behaves differently when it comes to address line handling.

The m24 and CGA essentially do the same thing: in graphics mode, regardless of whether it's a 200 or 400 line mode, the CRTC only directly counts through 4K's worth of memory addresses. The CRTC is a character oriented device and doesn't really "understand" graphics modes directly very well, which is why graphics modes are almost always interlaced on 6845-based video systems. So far as the 6845 is concerned both CGA graphics modes (320x200x4 and 640x200x2) are actually 40 column by 100 line text modes. (There is a table on page 5-7 of the M24 that confirms this, look at the values of registers 1 and 6 in the "graphics modes" column.) The hardware fetches 2 bytes per "character" horizontally (that's why it's fixed at 40 characters horizontally), which is why that 4K of *addresses* produced by a 40x100 grid results in 8Kbytes of actual memory usage. (I guess another way you could think about it is it's 4K 16 bit words?) But both of these graphics mode require 16K of RAM, and worse, the M24 mode needs 32K... but the CRTC programming doesn't change for it! So how does this work? In graphics mode the character row addresses, normally fed to a character generator, are used as the high bits of the memory address.

On CGA with its 200 actual active scan lines the 6845 is set up to scan 2 lines for each of the 100 vertical "characters" the graphics mode uses. This means that the same 80 bytes of "main" memory addresses are presented to RAM for two rows consecutively on the bottom 8Kbytes' worth of address lines, while RA0 line is translated to select which page of 8K out of is displayed for even/odd scanlines. The CRTC neither knows nor cares about this, just like it doesn't care about whether the 16 bits that get fetched on each address clock get translated into 16 mono pixels or 8 four-color ones, that's all the job of the support hardware and controlled by registers separate from the 6845.

The M24, on the other hand, is *really* tricksy. Because it has that 400 line monitor instead of 200 lines it sets the character height in graphics mode to always be 4 lines high. When emulating CGA graphics instead of using RA0 as the "top" address line for 16K it ignores it and uses RA1 instead. This means that each line of a CGA mode gets scanned out twice; IE, lines 0 and 1 point to the first 8K, 2 and 3 to the second. However, when you enable the 400 line mode *both* RA0 and RA1 become the MSBs of a 32K address. (Look at page 5-9 of the manual for the MUX circuitry that selects this.) The end result is four way interlacing with each group of lines in consecutive 8K blocks, as confirmed by the manual on page 5-24. Anyway...

There is a full description of what I did in my github in case you are interesting on those dirty details.... QX-16 VMM6 640x400

I just wanted to note one little thing; I was comparing the CRTC settings in the M24 manual to what you found on your Epson, and just needed to point out something amusing. You found that the graphics mode settings on the Epson set R9 to 03h, which is what you expect, IE, 4 lines tall. The table in the M24 manual says that R9 is set to 01h. The obvious question there is "whaaaat?", because the manual makes it clear that the CRTC actually needs to count to four just like the Epson does. The explanation is the circuitry on page 5-18, the "Scrambler" circuit. This circuit in the M24 actively intercepts attempts to program the CRTC and hacks the values to be what's necessary for the different hardware. Apparently the table just lists out the CGA values for everything because the scrambler's PROM has the REAL values in it, which I would guess look a lot like the Epson's.

 

[Zare]

Understood ... forgot to add ... 8088 ... no hard drive ... just two 360k floppy drives

I built Borland BGI demo program to use the AT&T graphics driver, attached, it's about 100kb of files.

The explanation is the circuitry on page 5-18, the "Scrambler" circuit. This circuit in the M24 actively intercepts attempts to program the CRTC and hacks the values to be what's necessary for the different hardware. Apparently the table just lists out the CGA values for everything because the scrambler's PROM has the REAL values in it, which I would guess look a lot like the Epson's.

Without looking deeper into the schematics, the way I remember, it buffers through the CRTC address register write operation to the 6845 correctly and keeps the value part buffered to be used as index for the PROM on the next data register write operation. Send any value to 3D5 and correct value is sent out from scrambler to CRTC.

 

[Zare]

They'll run Windows 3.0 (badly), and I suspect the M24 driver also exists in Windows 2.x, if not even in 1.x.

Well on 4.77 MHz 32k of pixels is really a chore, but it is usable for testing.

On a side, Windows 3.1 beta for me works slightly better, faster, more responsive than Windows 3.0. At one time I pretty much ran through somebody's huge-ass list of real mode Windows applications and found out many of them don't work with CGA due to few display lines but happily work with M24 graphics.

 

[Eudimorphodon]

Well on 4.77 MHz 32k of pixels is really a chore, but it is usable for testing.

On a side, Windows 3.1 beta for me works slightly better, faster, more responsive than Windows 3.0. At one time I pretty much ran through somebody's huge-ass list of real mode Windows applications and found out many of them don't work with CGA due to few display lines but happily work with M24 graphics.

If the machine doesn't have any mass storage device Windows 3.1 isn't going to work. Something like PC Paintbrush 3.x will work okay off a 360k floppy.