Nice to see someone writing a driver for these old OSes. I really can't help you much, but if you get no luck here maybe try vcfed.org. As the focus is older stuff.

That sounds really fascinating! 😎

Windows 3.0 had an AT&T driver included, too, I think. Maybe it can be patched.
Found a video: https://www.youtube.com/watch?v=yCmU5AXdxmc

As you said, 640x400 pels is good enough for Windows.
The VGA driver in Windows 2.03 uses it, too.
Other versions of the 2.x line may use other, weird resolutions (for applications expecting EGA view port)..

I've also made a little test program for 640x400, btw.
It uses QB45 and its SCREEN modes.
Olivetti/Logabax/AT&T/Toshiba 640x400 hi-res graphics mode

mR_Slug wrote on 2022-06-29, 21:32:

I really can't help you much, but if you get no luck here maybe try vcfed.org. As the focus is older stuff.

Yes, I while Googling for some info, I noticed relevant posts over on vcfed.org, but I don't have an account over here, and I had one here already. Also I've seen the Plantronics driver for the Sierra games discussed here, so I guessed I'd give it a go. But good hint, thanks.

Jo22 wrote on 2022-06-29, 21:36:

Windows 3.0 had an AT&T driver included, too, I think. Maybe it can be patched.

Yes, in fact this driver is also bundled to Windows 3.1 (at least to the version I have here), and it misidentifies the PC bridge's CGA controller as an "Olivetti M24", because it has 32K RAM, then all you get while trying to boot is a black screen. Probably because the required BIOS support is missing(?). Anyway, one has to inject the older Win 3.0 CGA driver to get anything working. 😀 (And fun fact, I can even see this detection code trying for 32K RAM in the CGA driver bundled to the W3.1 DDK! So it's quite clear that is what's happening.)

I've also made a little test program for 640x400, btw.
It uses QB45 and its SCREEN modes.
Olivetti/Logabax/AT&T/Toshiba 640x400 hi-res graphics mode

Yes, thanks, I've actually found this post earlier while searching for info about 640x400 mono. 😀

You can probably just write a TSR that hooks int 10h and handles ax=40h/48h to set the mode. Then use the included Windows 3.1 Olivetti/AT&T driver.

Plasma wrote on 2022-06-30, 09:23:

You can probably just write a TSR that hooks int 10h and handles ax=40h/48h to set the mode. Then use the included Windows 3.1 Olivetti/AT&T driver.

Yes, that was my initial idea, but it seems the Windows driver - at least in 386 mode - tracks register states and writes, so it can restore various modes that might have been set in DOS full screen sessions and so on, plus reprograms the card on its own (I couldn't find any BIOS calls, really, at least not for a mode switch). So tracking for AT&T 6300 registers has to be removed, and support for 0x3dd has to be added, etc, at least for full support. At least when looking at the driver source in the Win3.1 DDK, it didn't looked _that_ trivial like faking a BIOS call and calling it a day. But I might be wrong, neither my Win16-fu, nor my 16bit x86 asm-fu is that strong, hence I asked for input from others.

I might still do the TSR for other software though, that supports this mode from DOS (like QBasic).

Don't know if this may help, I've found some information on how the AT&T 6300 mode 40h is set. Direct quote from other post (WD90C11 and AT&T Model 6300 video mode):

I've found something very interesting for this topic. The ROM listing for the AT&T 6300 Plus is available online (http://bitsavers.org/pdf/att/6300/ATT_Persona … ue_1_-_1986.pdf), so it's possible to understand how the mode 40h and 48h are set.

Just go to the page 202.

I'll try to create a test utility and see if this really works on more video cards.

Jo22 wrote on 2022-06-29, 21:36:

I've also made a little test program for 640x400, btw.
It uses QB45 and its SCREEN modes.
Olivetti/Logabax/AT&T/Toshiba 640x400 hi-res graphics mode

Just a quick update here, based on Plasma's idea, and though I'm 100% sure it won't get me Windows working, I started working on a TSR, that would patch the BIOS to switch into "my" 640x400 mode when mode 40h/48h is requested. It already works with my test app, it also works with Turbo Pascal 7's ATT.BGI. But both QBASIC and QuickBASIC 4.5 errors out at line SCREEN 4, saying the mode is not available. I wonder if it detects the AT&T controller somehow on the register level (and I have no chance of supporting that, due to the lack of required register mappings on the hardware level), or I just need to add more BIOS calls to have the support working (for example get mode? what if it verifies after switching into the mode if it was actually successful?).

BTW, the BIOS TSR project quickly seems to snowballed into something much larger, than I anticipated. Apart from the "just set the extra bit bit and be done with it", one needs to have support for various other calls, like clearing the screen, probably the aforementioned get mode, but also text rendering support in 640x400... both with 8x8 and 8x16 characters, actually... And more. I'm not even aiming for full support, or I'll end up re-implementing half the CGA video BIOS... Which is not that complicated, but not what I had in mind as my next project. 😀 Also it's my first DOS TSR I've ever written, also only my 2nd or 3rd pure asm code for DOS ever (and everything before was 386+), so everything is new and a learning curve... Oh well. 😀

ViTi95 wrote on 2022-06-30, 21:15:

Don't know if this may help, I've found some information on how the AT&T 6300 mode 40h is set.

Thanks for this, it's always good to have more references & background info, but this is not that helpful for this specific problem, as I lack the AT&T 6300 compatible hardware (register mappings are missing from the PC to the Amiga inside the hardware, so I can't just check and handle the required registers in my video emulation code - that runs on the Amiga -, even if an AT&T compatible BIOS or other software pokes them). So I just need to add a BIOS mode somehow which then uses a different method in the background to switch to a 640x400 mode with the same video ram layout.

So basically one can then reuse all rendering code for the AT&T for this mode (as it already works with my TSR + Turbo Pascal 7 ATT.BGI), but the mode setting code must be totally different, sadly. (Which is also why the Windows/GEM/etc drivers need to be modified.)

Chain-Q wrote on 2022-07-02, 15:17:

Jo22 wrote on 2022-06-29, 21:36:

I've also made a little test program for 640x400, btw.
It uses QB45 and its SCREEN modes.
Olivetti/Logabax/AT&T/Toshiba 640x400 hi-res graphics mode

Just a quick update here, based on Plasma's idea, and though I'm 100% sure it won't get me Windows working, I started working on a TSR, that would patch the BIOS to switch into "my" 640x400 mode when mode 40h/48h is requested. It already works with my test app, it also works with Turbo Pascal 7's ATT.BGI. But both QBASIC and QuickBASIC 4.5 errors out at line SCREEN 4, saying the mode is not available. I wonder if it detects the AT&T controller somehow on the register level (and I have no chance of supporting that, due to the lack of required register mappings on the hardware level), or I just need to add more BIOS calls to have the support working (for example get mode? what if it verifies after switching into the mode if it was actually successful?).

BTW, the BIOS TSR project quickly seems to snowballed into something much larger, than I anticipated. Apart from the "just set the extra bit bit and be done with it", one needs to have support for various other calls, like clearing the screen, probably the aforementioned get mode, but also text rendering support in 640x400... both with 8x8 and 8x16 characters, actually... And more. I'm not even aiming for full support, or I'll end up re-implementing half the CGA video BIOS... Which is not that complicated, but not what I had in mind as my next project. 😀 Also it's my first DOS TSR I've ever written, also only my 2nd or 3rd pure asm code for DOS ever (and everything before was 386+), so everything is new and a learning curve... Oh well. 😀

QB does a check for strings in the BIOS to detect Olivetti. If you want to patch it, you can search for 4F 4C 75 58 and replace with 4F 4C EB 52.

Plasma: Thanks. Obviously Microsoft had to do it the least elegant way. Yuck. 🙁 Too bad.

It's funny because there's a MSKB issue about this exact problem. And Microsoft's response was just "welp we only tested with Olivetti/AT&T" instead of actually fixing it.

Chain-Q wrote on 2022-06-29, 20:03:

Recently, I learned about the Plantronics ColorPlus as a CGA extension, then read somewhere that Commodore PC clones supported it, but since there was so little amount of software back in the days, this was never advertised. I already noticed earlier that all PC Bridges have 32K of CGA memory, but after learning about the ColorPlus, I checked the bridge specification again, and sure enough, the otherwise very strict register mapping of these cards maps also I/O port 0x3dd to the Amiga side, which is the only extra register needed to support the ColorPlus modes on top of CGA. So I went ahead, and added support for both 320x200 16 color, and 640x200 4 color modes for the upcoming v1.6 version of Viaduct.

Thanks, very interesting. Just looking for an opportunity to add the capabilities of the Plantronics Colorplus (320 × 200 × 16) graphics adapter to QuickBasic.