• Please review our updated Terms and Rules here

Book 8088 discovery and modification thread

Interesting. What is the interface to the panel? If it's a standard one, you could use a different controller to test. Can you share some pictures of the panel, its cabling, and the controller, front and back?

I have a number of generic LCD panel controllers wandering around.

- Alex
 
While I don't have a system, I believe CL-GD5428 can do all the VGA modes and quite a few SVGA modes too. Moreover, given the information gathered by the members of this forum, it uses the stock Cirrus Logic / Quadtel VGA BIOS, so that BIOS would happily support all the VGA/VESA modes. That is unless the system designer/manufacturer badly screw-uped the schematic, or say used very slow DRAMs...
I think the issue is coming from the LCD panel and the Realtek RTD2662 controller not programmed to properly render VGA modes.
 
While I don't have a system, I believe CL-GD5428 can do all the VGA modes and quite a few SVGA modes too. Moreover, given the information gathered by the members of this forum, it uses the stock Cirrus Logic / Quadtel VGA BIOS, so that BIOS would happily support all the VGA/VESA modes. That is unless the system designer/manufacturer badly screw-uped the schematic, or say used very slow DRAMs...
I think the issue is coming from the LCD panel and the Realtek RTD2662 controller not programmed to properly render VGA modes.
As I say I even have 1024kb of memory on my module - 4 times more than makes any sense! So I'm sure its the components from an ISA card placed onto the module in stock form. It seems some of us get GD5428 and some GD5429 - very little in it, slighly fewer refinements in the 5428 but I dont think enough to explain this kind of behaviour. Their quite refined compared to the 5422 / 5424 I remember those having odd VESA mode issues.
 
Book8088 uses 12 pin JST connector with 1.25mm step. Three first pins are +5v, full pinout is in design pdf, which i don't have near me right now.
I've tried connecting it to two different lcd boards (rtd2662 and some unknown chip) and an arcade GS8200 convertor (unsure if i remember that name correctly) without any success, except that arcade convertor tried to display some unsynced video. But that's for CGA, VGA might give better results.
Worth noting that CGA CLPD gives not only IRGB signals, but several more used for LCD connection
 
Last edited:
I think the issue is coming from the LCD panel and the Realtek RTD2662 controller not programmed to properly render VGA modes.

Just nakedly speculating here, but I kind of wonder if they specifically hacked a stock firmware for that controller in order to improve support for the 400(*) line@70hz modes and inadvertently broke the 480@60hz modes in the process. A thing you'll notice with even a lot of commercial VGA LCD screens is they generally *don't* spend much energy on making those modes work well. (As an example, I have a VGA card in a Tandy 1000, which of course means it's spending most of its time in text or sub-VGA graphics modes, and even with supposedly good-quality commercial VGA LCD monitors I have to manually hit the "auto-calibrate" menu option when switching modes to resize the output or get rid of, or at least reduce, some vertical linearity problems. And I've seen this with little regard to the age of the monitor I'm using.) I wouldn't even rule out that the stock firmware they started with didn't like the 70hz modes *at all*; there's an expectation that "modern" video cards (post 2005 or so) are expected to honor EDID mode information and adapt if the monitor informs the card it doesn't support traditional "fallback" modes.

Anyway, yeah, I would fully expect that if you wired up a better monitor it'd work fine, I'd be *extremely* surprised if this is a problem with the VGA chipset.

(* The EGA "350" line mode is a special case of the 400 line mode on real VGA monitors, that just triggers the monitor to change the vertical overscan... which is why I was really surprised to hear this machine *does* scale it up, as opposed to leaving some letterboxing compared to the double-scanned 200 line modes. Weird they'd grok that but not make the 480 line modes work.)
 
Interessante. Qual è l'interfaccia con il pannello? Se è standard, potresti utilizzare un controller diverso per testare. Puoi condividere alcune immagini del pannello, del cablaggio e del controller, fronte e retro?

Ho in giro un certo numero di controller generici per pannelli LCD.

-Alessio

I took this photo from the internet. I have the same PCB, and on the left side of the Realtek chip, there is an 8-pin integrated circuit that could possibly be a serial EEPROM with the firmware. I might also be able to dump its contents.
 
As I say I even have 1024kb of memory on my module - 4 times more than makes any sense! So I'm sure its the components from an ISA card placed onto the module in stock form. It seems some of us get GD5428 and some GD5429 - very little in it, slighly fewer refinements in the 5428 but I dont think enough to explain this kind of behaviour. Their quite refined compared to the 5422 / 5424 I remember those having odd VESA mode issues.
It's possible that the chip doesn't function with less RAM than this? I believe that the chips are salvaged by disassembling old graphics cards because they have signs and scratches, indicating they are clearly used chips. Therefore, the RAM likely comes from the same board from which they are disassembled.
 
Book8088 uses 12 pin JST connector with 1.25mm step. Three first pins are +5v, full pinout is in design pdf, which i don't have near me right now.
I've tried connecting it to two different lcd boards (rtd2662 and some unknown chip) and an arcade GS8200 convertor (unsure if i remember that name correctly) without any success, except that arcade convertor tried to display some unsynced video. But that's for CGA, VGA might give better results.
Worth noting that CGA CLPD gives not only IRGB signals, but several more used for LCD connection
If you want, I can send you an EXE file that intermittently generates two frames, one entirely green at 640x350 and the other entirely red at 640x480, if you want to test with these LCD controllers. Question: Could the firmware of the controllers be interchangeable?
 
While I don't have a system, I believe CL-GD5428 can do all the VGA modes and quite a few SVGA modes too. Moreover, given the information gathered by the members of this forum, it uses the stock Cirrus Logic / Quadtel VGA BIOS, so that BIOS would happily support all the VGA/VESA modes. That is unless the system designer/manufacturer badly screw-uped the schematic, or say used very slow DRAMs...
I think the issue is coming from the LCD panel and the Realtek RTD2662 controller not programmed to properly render VGA modes.
I'm getting a suspicion... what if this crafty Chinese guy programmed the LCD controller to darken the video BIOS post screen?
 
If you want, I can send you an EXE file that intermittently generates two frames, one entirely green at 640x350 and the other entirely red at 640x480, if you want to test with these LCD controllers.
No need, my V1 has CGA only, and connecting external display with RGB2HDMI solved most screen problems for me.
--
Looks like i've found some awg36 wire locally, hope those will fit the traces for keyboard connection.
 
Last edited:
So. Pico Zero 2 W finally arrived. Here's video of 8088mph running on Book8088 on ext display via RGB2HDMI in full composite mode (180 degree set in palette settings). Of cause dma hack by GloriousCow enabled.

 
I'm getting a suspicion... what if this crafty Chinese guy programmed the LCD controller to darken the video BIOS post screen?
It wouldn't surprise me that this could have been an intention - however, as I understand it the CGA output is handled by the system BIOS and I know that VGA was not initially planned, it seemed to even by considered slightly after the initial batch of the V2 were manufactured (i.e. with serial and parallel ports)...

On that note, I'm starting to wonder if those very ports are tying up system resources that would otherwise allow ISA cards to function, I'm very much thinking of my misadventure with the PicoGUS here.
 
It wouldn't surprise me that this could have been an intention - however, as I understand it the CGA output is handled by the system BIOS and I know that VGA was not initially planned, it seemed to even by considered slightly after the initial batch of the V2 were manufactured (i.e. with serial and parallel ports)...

On that note, I'm starting to wonder if those very ports are tying up system resources that would otherwise allow ISA cards to function, I'm very much thinking of my misadventure with the PicoGUS here.

PicoGUS uses port 1D0h to "talk" to it's utility. There's a chance that this port is considered as reserved by XT-IO chip. But that's just an assumption
 
the CGA output is handled by the system BIOS
If you have a VGA controller, all INT 10h (video services) routines are handled by VGA BIOS extension. Built-in support for CGA/MDA in the System BIOS is not used in this case.
On that note, I'm starting to wonder if those very ports are tying up system resources that would otherwise allow ISA cards to function, I'm very much thinking of my misadventure with the PicoGUS here.
PicoGUS uses port 1D0h to "talk" to it's utility. There's a chance that this port is considered as reserved by XT-IO chip. But that's just an assumption
Although, everything is possible, and we don't really know what is in that XT-IO chip, I don't think it uses port 1D0h. I don't see a good reason for that... There is a slight chance that the CPLD code has an error/omission and it incorrectly decodes addresses. Here is the I/O decoding according to the comment in the schematic (I added I/O address ranges in hexadecimal):

00000xxxxx DMA - 00h-1Fh
00001xxxxx PICCS# - 20h-3Fh
00010xxxxx PITCS# - 40h-5Fh
110000xxxx CFCS0# - 300h-30Fh
110001xxxx CFCS1# - 310h-31Fh
000110xxx0 IO60CS# - 60h,62h,64h,66h,68h,6Ah,6Ch,6Eh
100110xx0x USB - 260h,261h,264h,265h,268h,269h,26Ch,26Dh
111000100x ADLIB - 388h,389h

There might be other reasons for it not working: timing, signal integrity (sending ISA signals over a ribbon cable is not the best thing ever), lack of buffers or too much load on the ISA bus
 
  • Like
Reactions: n0p
Non mi sorprenderebbe che questa potesse essere un'intenzione - tuttavia, a quanto ho capito, l'output CGA è gestito dal BIOS di sistema e so che VGA non era inizialmente previsto, sembrava addirittura essere preso in considerazione leggermente dopo il batch iniziale dei V2 sono stati prodotti (cioè con porte seriali e parallele)...

A questo proposito, sto iniziando a chiedermi se proprio quelle porte stiano impegnando risorse di sistema che altrimenti consentirebbero il funzionamento delle schede ISA, sto pensando molto alla mia disavventura con il PicoGUS qui.

from what I've seen from simple utility tests the serial and parallel use standard addresses for lpt1 and com1
 
There might be other reasons for it not working: timing, signal integrity (sending ISA signals over a ribbon cable is not the best thing ever), lack of buffers or too much load on the ISA bus

I think I brought this up in an earlier thread, but in addition to not having buffers it's my recollection that the signals on the expansion bus are being driven by CMOS drivers, not LS, so I'd consider the SLA for the expansion bus compatibility on that computer to be "if it breaks you get to keep both pieces".
 
I'm happy to report that the SDLPT works really nicely - the driver seems efficient.
I got my version from "curtis electronics" in the UK. Is uses the NC100SD driver.
I can't make sdlpt work with any of my 8088 laptops, included book 8088
It works with xt tower no problem and with 486+ laptop. Any option you added to sddrv.sys?
 
Some info out of the v2 manual, including the pinout of the video card socket...
Has anyone managed to get a copy of the v2 schematics? I contacted my seller and he sent me what he claimed to be the v2 documentation. It was the v1 documentation.
 
Back
Top