I have a quick thought about the graphics in the book 8088 and the possible use of only using a LCD controller for graphics? I know there is a new version of the book 8088 that uses a real VGA controller. I only found out recently about the new VGA version and had this thought before I knew the VGA version existed. Instead of using a real VGA controller or even the way they did CGA in the book 8088 , couldn't you just use a LCD controller directly ? From doing various google searches there is a LCD controller that is directly controllable and also supports an 8-bit bus , so it definitely could be used in the book 8088. This LCD controller supports a resolution slightly higher than 640 x 480 and definitely does support 640 x 480 with 256 colors.

My idea instead of using a real VGA controller would to use this LCD controller and write a bios extension to control it and emulate SVGA graphics ( 640 x 480 256 colors ) and various other graphics modes?

Yrouel wrote on 2023-12-21, 10:16:

Are you sure this is the issue? I checked the expansion board and there is a 79M05 connected to the ISA slot and chained from th […]
Show full quote

Gennadios wrote on 2023-12-21, 01:43:

1st post for posterity;

I bought one on black friday and have been playing around with it. The book 8088 only supplies +5v and +12v, any cards that require -5v will kill the display and you'll get a 'no signal' error when powering on.

If anyone plans to use it to play around with 80's expansion cards, Phil/Necroware's voltage blaster works, but you're losing 1/3 expansion slots. It might be worth monitoring aliexpress to see if they start selling an expansion board with more slots.

Are you sure this is the issue? I checked the expansion board and there is a 79M05 connected to the ISA slot and chained from the -12V so both negative voltages are provided.

...

It's possible the voltage blaster is just stabilizing the power rails more than providing the negative voltages that are already there

It didn't even dawn on me to plug in the expansion board, but you are correct. The cards that worked with the voltage blaster also worked with the expansion board plugged. Thanks, a second PSU is a better tradeoff than losing an ISA slot.

MichaelWeaser wrote on 2023-12-23, 02:44:

I have a quick thought about the graphics in the book 8088 and the possible use of only using a LCD controller for graphics? I know there is a new version of the book 8088 that uses a real VGA controller. I only found out recently about the new VGA version and had this thought before I knew the VGA version existed. Instead of using a real VGA controller or even the way they did CGA in the book 8088 , couldn't you just use a LCD controller directly ? From doing various google searches there is a LCD controller that is directly controllable and also supports an 8-bit bus , so it definitely could be used in the book 8088. This LCD controller supports a resolution slightly higher than 640 x 480 and definitely does support 640 x 480 with 256 colors.

My idea instead of using a real VGA controller would to use this LCD controller and write a bios extension to control it and emulate SVGA graphics ( 640 x 480 256 colors ) and various other graphics modes?

Such a solution would have to be compatible with VGA at the register level. If the LCD controller does not provide such software compatibility, it would have to be emulated at the register level. That would involve I/O port trapping, which requires at least a 386 CPU. (And even on the 386, such emulation would likely be slow.)

What might work is a VBE 1.x driver for such an LCD controller. I'm not sure about that, though, since I believe that the VESA BIOS Extensions (VBE) would still require the pixels to be mapped to the frame buffer in a certain (VGA-compatible) way.

If that wouldn't be possible either, then the only alternative would be to write drivers specifically for that LCD controller, but that would only help with getting Windows to work, or any text-mode applications that use only INT 10h BIOS calls to access the graphics card, without programming any specific graphics cards directly.

Long story short: it wouldn't be useful unless such an LCD controller offered VGA software compatibility at the hardware register level.

digger wrote on 2023-12-23, 11:43:

Such a solution would have to be compatible with VGA at the register level. If the LCD controller does not provide such software […]
Show full quote

MichaelWeaser wrote on 2023-12-23, 02:44:

I have a quick thought about the graphics in the book 8088 and the possible use of only using a LCD controller for graphics? I know there is a new version of the book 8088 that uses a real VGA controller. I only found out recently about the new VGA version and had this thought before I knew the VGA version existed. Instead of using a real VGA controller or even the way they did CGA in the book 8088 , couldn't you just use a LCD controller directly ? From doing various google searches there is a LCD controller that is directly controllable and also supports an 8-bit bus , so it definitely could be used in the book 8088. This LCD controller supports a resolution slightly higher than 640 x 480 and definitely does support 640 x 480 with 256 colors.

My idea instead of using a real VGA controller would to use this LCD controller and write a bios extension to control it and emulate SVGA graphics ( 640 x 480 256 colors ) and various other graphics modes?

Such a solution would have to be compatible with VGA at the register level. If the LCD controller does not provide such software compatibility, it would have to be emulated at the register level. That would involve I/O port trapping, which requires at least a 386 CPU. (And even on the 386, such emulation would likely be slow.)

What might work is a VBE 1.x driver for such an LCD controller. I'm not sure about that, though, since I believe that the VESA BIOS Extensions (VBE) would still require the pixels to be mapped to the frame buffer in a certain (VGA-compatible) way.

If that wouldn't be possible either, then the only alternative would be to write drivers specifically for that LCD controller, but that would only help with getting Windows to work, or any text-mode applications that use only INT 10h BIOS calls to access the graphics card, without programming any specific graphics cards directly.

Long story short: it wouldn't be useful unless such an LCD controller offered VGA software compatibility at the hardware register level.

This is the LCD Controller that I was talking about :

SSD1963 controller :

Overview PDF : https://ww1.microchip.com/downloads/en/Device … DS50002915A.pdf

Actual Datasheet PDF : https://www.seacomp.com/sites/default/files/r … ech-SSD1963.pdf

There are various other LCD controllers that isn't this one that can be controlled by a 8-bit bus.

I know this LCD controller probably isn't compatible with a VGA controller like you said above, but there are probably other ways you could get it to work with extra support ICs ? Like for example what about some IC interface between the computer and this LCD controller? Like using a microcontroller , FPGPA , CPLD etc. , to emulate what is necessary to make VGA work , than that would be controlling the LCD controller?

Yeah, with some intelligent circuitry in between the the ISA bus and the non-VGA LCD controller, I guess it could work. It could then also handle things like scaling non-native resolutions and such. But it would also add more complexity and make it more expensive.

Hi there. I don't mean to annoy you guys, but if you're mainly into vintage gaming and Windows 3.0, then MCGA may do.

It can do 320x200 256c (mode 13) and 640x480 mono (mode 11h).

Design wise, it's much more simple than a full fledged VGA implementation (linear 64 KB range, no bankswitching needed etc).
The original implementation in an IBM Model 30 8086 was being built by using discrete parts.

It's being described here (I'm not affiliated) :
https://www.swiat-owocow.pl/lang/en/1285.html

Simulation games like SimCity have to revert to CGA hi-res, maybe, if they don't support 640x480 mono.

Edit: Supporting AT&T/Olivetti CGA mode 640x400 mono would perhaps also increase application support a little bit.

Edit: It's just an idea. VGA would be preferable, if possible, of course.

I wrote a small program to work around the issues with the Book 8088 not centering the display properly. It's a TSR that wraps the BIOS video interrupt and briefly sets pixels in the top left and bottom right of the screen to help the LCD display calibrate correctly.

I've only tested on my V2 with VGA but am interested to hear if it helps for the V1 / CGA units too
https://github.com/jhhoward/Vidsync

Ok, since i assembled my Book V1 back (connected the LCD screen) for testing VidSync, I've decided to dig into textmode centering issue a bit more.
Everything below is for Book V1 CGA only.
I thought, might reprograming 6845 CRTC help at least to some extent?
This page https://stanislavs.org/helppc/6845.html has all basic info for that, including init tables for video modes.
I've tried changing registers 02 and 03.
03 seemed to have no effect, but playing with 02 gave a result: if set to 59h instead of 5Ah and video centering fails, it makes screen shift to the right in text mode 😀. Somewhat usable, but not the real solution. So i extended my PALTSR to change register 02 of 6845 to 5Ah/59h if called from 80x25 text mode.
Odd enough, if centering failed (it's shifted to either left of right), changing register moves screen eating one column from one side (LCD reinits with that new value). BUT, if centering done right, changing that register has no effect at all!
Next, i tried setting screen border via port 3D9h right after setting CGA text mode 80x25 and got some new weird effects. LCD controller alters colors - white becomes kind of opposite to border color, other colors changed as well. On external screen everything is fine, so it's some quirk on either LCD or CGA CLPD LCD part. Might be good for some Book V1 specific virus 😁
I also noticed that changing register 0 to any value different from 71h caused LCD to lose signal and figured at some point that returning back from that state positioned screen just right. It's surely pure hit-and-miss, but it worked more reliable than "mode 80" aaand it has some success rate (>30%) with Rogue, which has 0 success rate centering with 8088 chip.
So, keeping LCD with lost signal a bit and returning back definitely helps my text mode centering issues.
PALTSR3 attached to this post and source is here: https://github.com/jinshin/Book8088/blob/main/PALTSR3.ASM
Press Ctrl+~ (key under Escape) to reset screen in 80x25 text mode.
Knows bugs: you'll need to press CTRL after screen centering as CTRL gets "stuck" after long interrupt processing.

I received a new LCD controller as well and I was able to dump the firmware from both boards and I can confirm that a simple firmware transplant seems sufficient to fix the original board.
Unfortunately it was necessary to desolder both EEPROMs otherwise the TL866 complained about overcurrent when just clipped to the chip while on the board.

The boards are identical except for a slight difference in the main controller chips, the original is RTD2660 C3F62G1 while the new one is RTD2660 D8C23G3, I don't think it's particularly relevant.

The EEPROM is a P25Q40SH (4Mbit SPI) in both boards and it's not directly listed at least in the old MiniPro software, I selected more or less randomly the BG25Q40A and disabled the ID check and everything worked

Yrouel wrote on 2024-01-12, 11:25:

I received a new LCD controller as well and I was able to dump the firmware from both boards and I can confirm that a simple fir […]
Show full quote

I received a new LCD controller as well and I was able to dump the firmware from both boards and I can confirm that a simple firmware transplant seems sufficient to fix the original board.
Unfortunately it was necessary to desolder both EEPROMs otherwise the TL866 complained about overcurrent when just clipped to the chip while on the board.

The boards are identical except for a slight difference in the main controller chips, the original is RTD2660 C3F62G1 while the new one is RTD2660 D8C23G3, I don't think it's particularly relevant.

The EEPROM is a P25Q40SH (4Mbit SPI) in both boards and it's not directly listed at least in the old MiniPro software, I selected more or less randomly the BG25Q40A and disabled the ID check and everything worked

Thanks for the dumps. I've successfully reflashed mine with the newer version. No need to unsolder the chip, but still some soldering needed, see the attached pics. Good thing is that no programmer is needed, done via VGA DDC lines on a linux PC, using this code: https://github.com/static-void/rtd266x_programmer

ipdown wrote on 2024-01-21, 13:43:

Thanks for the dumps. I've successfully reflashed mine with the newer version. No need to unsolder the chip, but still some soldering needed, see the attached pics. Good thing is that no programmer is needed, done via VGA DDC lines on a linux PC, using this code: https://github.com/static-void/rtd266x_programmer

That's fantastic, I figured something like this was possible since it's one of the main ways how you're supposed to interact with the controller. In my case it was definitely quicker to desolder the EEPROMs and use the TL866CS.
To clarify you soldered only those 4 wires on the LCD board correct?

For the changes to the code I suggest doing a pull request on that repo mentioning specifically the Puya P25Q40SH EEPROM and the Book8088 so it's also easily searchable

As an addendum these drivers work on Windows 3.0 following the instructions in the README inside the WIN30 folder to install them:
https://winworldpc.com/product/avga3-gd542x-display/1

I seemingly had to use clmode to set high refresh rate because it was initially not working at 640x480 256 color but then it worked on its own even after a hard power cycle so *shrug*

Hey folks. I just ordered a Book 8088 V2 VGA and after going through the thread, I'm left with:

• The BIOS needs to be updated, but that requires a EEPROM programmer. The latest is nop's v1.0.5.
• You should image the CF drive first.
• The version of Win 3.0 is slightly messed up.

Other than that, is the serial port driven by a 16550A compatible chip or southbridge? It sounds like it is which would be better than the older serial chips the XT and AT series had in the past.

STrRedWolf wrote on 2024-02-03, 19:59:

Hey folks. I just ordered a Book 8088 V2 VGA and after going through the thread, I'm left with: […]
Show full quote

Hey folks. I just ordered a Book 8088 V2 VGA and after going through the thread, I'm left with:

• The BIOS needs to be updated, but that requires a EEPROM programmer. The latest is nop's v1.0.5.
• You should image the CF drive first.
• The version of Win 3.0 is slightly messed up.

Other than that, is the serial port driven by a 16550A compatible chip or southbridge? It sounds like it is which would be better than the older serial chips the XT and AT series had in the past.

Hi.
My ports board on V2 has 16C550CQ chip.
As for BIOS - here's features list: https://github.com/jinshin/8088_bios/wiki
CF - i broke partitioning once, so you might want to save the very first sector. Formatting/transferring system goes fine usually
If you ordered Book with VGA - you might want to request new LCD board, as "CGA" firmware doesn't support full VGA modes range (especially mode 12h)

n0p wrote on 2024-02-04, 19:06:

Hi. My ports board on V2 has 16C550CQ chip. As for BIOS - here's features list: https://github.com/jinshin/8088_bios/wiki CF - i […]
Show full quote

Hi.
My ports board on V2 has 16C550CQ chip.
As for BIOS - here's features list: https://github.com/jinshin/8088_bios/wiki
CF - i broke partitioning once, so you might want to save the very first sector. Formatting/transferring system goes fine usually
If you ordered Book with VGA - you might want to request new LCD board, as "CGA" firmware doesn't support full VGA modes range (especially mode 12h)

I'm getting the V2 with VGA in. So far, it's in the USA now and waiting for a shipping partner (Pitney Bowes) to give it to the post office for actual delivery.

The only other thing is... damn, they put in exactly 640 KB on the mobo? I so now want to find a combo 128KB expansion and maybe PCMCIA slot cartridge to fill that ISA slot. I'll take an EMS card if need be... EDIT: Ah, there's the PicoMEM board that's close to what I'm looking for and more.

n0p wrote on 2024-02-04, 19:06:

Other than that, is the serial port driven by a 16550A compatible chip or southbridge? It sounds like it is which would be better than the older serial chips the XT and AT series had in the past.

Hi.
My ports board on V2 has 16C550CQ chip.
As for BIOS - here's features list: https://github.com/jinshin/8088_bios/wiki
CF - i broke partitioning once, so you might want to save the very first sector. Formatting/transferring system goes fine usually
If you ordered Book with VGA - you might want to request new LCD board, as "CGA" firmware doesn't support full VGA modes range (especially mode 12h)
[/quote]

I assume the LCD board may have it's own firmware in EEPROM? Is the correct EEPROM linked above? Anyone know how to find out if I got the good firmware?

And yes, I got my Book8088 in. I'm looking at programmers now.

STrRedWolf wrote on 2024-02-12, 23:27:

I assume the LCD board may have it's own firmware in EEPROM? Is the correct EEPROM linked above? Anyone know how to find out if I got the good firmware?

I wouldn't refer to those as good or bad, as both has their quirks.
Simplest way to determine which fw you have is to set mode 12h and see if it works.
If yes - you got "VGA" fw, if not - "CGA"
Program i wrote for this is here:
https://github.com/jinshin/Book8088/blob/main/MODE12H.COM

n0p wrote on 2024-02-13, 09:54:

I wouldn't refer to those as good or bad, as both has their quirks. Simplest way to determine which fw you have is to set mode 1 […]
Show full quote

STrRedWolf wrote on 2024-02-12, 23:27:

I assume the LCD board may have it's own firmware in EEPROM? Is the correct EEPROM linked above? Anyone know how to find out if I got the good firmware?

I wouldn't refer to those as good or bad, as both has their quirks.
Simplest way to determine which fw you have is to set mode 12h and see if it works.
If yes - you got "VGA" fw, if not - "CGA"
Program i wrote for this is here:
https://github.com/jinshin/Book8088/blob/main/MODE12H.COM

The screen blanks. I assume this is the bad firmware?

STrRedWolf wrote on 2024-02-12, 23:27:

I assume the LCD board may have it's own firmware in EEPROM? Is the correct EEPROM linked above? Anyone know how to find out if I got the good firmware?

And yes, I got my Book8088 in. I'm looking at programmers now.

The firmware dump I linked above is the new VGA one extracted from a replacement LCD controller board which is needed if you want higher resolutions and actually use VGA modes (I also linked a working Windows 3.0 driver in another comment)

I'm happy to announce that my postponed Book8088 V1.5 (one and a half) project is now complete 😀
My Book8088 V1 now has both fully functional external screen and keyboard connectors. And of course DMA refresh mod.
I received and soldered back keyboard microcontroller (received even two, so if anyone wants the firmware and has a working method to do it - i might try), as testing showed - Pico inputs should be pulled up to work with it (github sources updated).
Also increased a bit length of keyboard "cycle" to work better in Loderunner and Shamus, that tend to suffer from "stuck" key - not getting release properly.
This time i supplied 3.3V to microcontroller from Pico itself and everything worked fine.
USB-C hole is not that good as i had to move Waveshare Zero a bit from planned position.

Shamus on Book8088 using external keyboard.
https://www.youtube.com/shorts/guVZ3c7xhVE

Got the equipment all in today and I flashed the updated v1.05 BIOS onto a new chip. So far, looking good. Now to go check into flashing the firmware on the LCD controller, and cleaning out the drive a bit.

Meanwhile, I do have four more flash chips I can burn and send folks from the Baltimore/DC area. Just gotta find my small breadboards...