Hi - Please see attached. I haven't had a chance to try it yet, or compare to the (working) firmware in my latest V2.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Book 8088 discovery and modification thread
- Thread starter Retroplayer
- Start date
I flashed the new (attached above) firmware to my older V2 system - it resolved the issues. No more Mode 80 commands are needed. I will try to dump the FW from my newer system and see if it matches or is different. I have a photo of the controller board, just in case. (Edit - Attached the old version of the firmware just in case.)
Last edited:
I'm excited to try the PicoMEM 1.11 on the Book8088 - I see that FreddyV already uses one for testing so I have good hopes for it. I'm going to upgrade the bios to n0p's 1.0.6 to make sure that I have good floppy support, and I'll report back when it arrives.
Yrouel
Member
Well this is interesting, I hashed (MD5) all the binaries and here's the results:
The firmware "Book8088V2_OLD.BIN" inside "Book8088V2_OLD.zip" you also provided matches my LCD_VGA_BAD.bin I attached here (inside "Book8088_LCD_Firmware.zip"): ac207032250d31b794f4a791cd9fda40
All the other firmwares don't match:
My "LCD_VGA_GOOD.bin" (inside "Book8088_LCD_Firmware.zip"): 2989a77a2b2e7b15d31dfae2dcbd0512
n0p's "BookV2_VGA_Other_P25Q40H.BIN" attached here (inside "BookV2_VGA_Other_P25Q40H.zip"): 8f9f5a341df98f06b54e248ac6ba62c4
Your "Book8088_LCD-CTRL-FW.BIN" (inside "Book8088_V2_VGA-LCD-Controller-Firmare_8April2024.zip"): bf99791c1cfbb41597ad9949989a55a8
So to recap we have at least four versions of the LCD controller firmware: the older bad one that if I'm not mistaken came from the V1 and doesn't support higher resolutions and tree newer ones that work with higher resolutions but at least in one case (n0p's) had alignment issues.
My good one and yours have seemingly little actual differences (I have no idea what that does though) while n0p's dumped version seems completely different from either
What software do you use? I have both of those modems but can't get them recognized with either Telix or Bananacom.serial wifi modems that i have used.
WiRSa v2 Wifi RS232 Serial Modem adapter with SD by RetroDisks on Tindie
Wifi RS232 Serial Modem adapter with SD file transfer features and OLED displaywww.tindie.com
RS232 Serial Wifi Modem for Vintage Computers V4 by The Old Net on Tindie
Get your vintage computer connected to BBS's and more! It can act as a Modem, PPP ISP or a SLIP Ethernet adapter!
both are based off the same code.
i think the oldnet version works slightly better but i go back and forth.
Sorry for not having the expertise to dump the ROM from my chips - but I can say to you that yes, I received a new driver board FOC in February, I've just changed it out tonight and can confirm it is working in VGA modes properly, and I'm not seeing alignment issues at the moment. Additionally I'm getting the OSD "VGA" and "Auto Detect" messages which I was not getting at all with the computer as shipped.
With the older FW it was easy to trigger the text alignment issue by entering graphics mode and then back to text/DOS prompt. The bottom 1 or 2 lines would be below the screen but I haven't reproduced it since updating the FW. I should be receiving a new board in the next week, and if the FW is different I will post it. Good luck all
I'm trying to install DOS 6.22 to a WD / SilconDrive 2GB CF card in the Book8088 using the latest 1.0.6 Jinshin BIOS without success. I'm able to boot from USB using the DOS floppy images with the system going through all of the steps as normal. In the end, the system attempts to boot from the CF but hangs at "Booting C>C". I've tried formatting in Windows 10, and letting the DOS installer handle all of the disk management, but it's the same result. I also just tried to clone the original 512MB CF to a 2GB card, but I'm unable to extend the original partition and also unable to add an extended/secondary partition. My preferred solution is to have everything on a single 2GB partition. I'm ok with a fresh install, or extending the original install, but I've been unable to find a tool that can extend a FAT16 parition - Thanks for any input
I forget quite why now but I seem to recall a lot of warnings that everything needed to be 512mb or smaller for the Book8088 (the CH375 USB stick as well as the CF card). If you use on thats larger you might need to repartition it to 512mb.
jscipione
Experienced Member
Not all CF cards will boot so you may simply have one that won’t boot for whatever reason and you need to try another CF card.
That being said you may
I got a 2gb cf card booting on my Book 8088 before it died so I know it’s possible. I loaded the cf card in virtualbox, installed MS DOS 6.22 on it and copied my files over.
However your installation method should also work so it might just be an incompatible cf card.
STrRedWolf
New Member
- Joined
- Mar 26, 2024
- Messages
- 1
What are you using for flashing the VGA board? I have the V2 with VGA and the display firmware could use it.
I will try via virtualbox and see how that goes. The drive is the same CF card model that i received with the Book8088 but the 2GB model (WD SiliconDrive). I'll keep messing with it.
I'm using the very popular XGecu Pro Model: T48. I'm not sure how it's bundled at various stores, but I bought the slightly more expensive one that included a bunch of socket adapters. The key for the VGA board is that you get the version that includes the SOIC 8-Pin Test Clip & adapter. Once you have that, you can remove the LCD bezel and get very easy access. The SW for the flash tool is pretty straight forward. The SW tool will run in a virtual machine, but I wasn't able to successfully flash the onboard FW that way - flashing EEPROMS wasn't an issue at all.
I received the Pocket386 finally. I attached some photos, but I'll try to start a new thread if someone didn't beat me to it. A couple of things - The keyboard mouse function does not allow drag and drop because you cannot use more than one key at a time. If you exit to DOS from Win95, then type 'exit' to enter Win95 again, the screen does not sync (at least on this system); rebooting will allow normal Win95 operation again. I don't think the correct video driver is installed - I will capture an image of the card and then try alternatives. System is quite a bit smaller than the Book8088, and the keyboard suffers a bit though the keys seem a little better.
Attachments
You can buy one very bare-bones and then buy individual adapters, or you can buy bundles with varying numbers on Amazon. I have a T48 and I'm very pleased with it. Very straightforward for a newbie and the software isn't bad once you get used to it.
sergey
Veteran Member
This probably needs to go to the 386/486-based Systems thread
I've been using a T56 since they came out (it came out first before the T48).. they work well and handle many more things than the TL866II+ even.
@sergey I wonder if you could provide any advice on this issue - I've just got one of FreddyV's PicoMEM boards, but the BIOS on that card cant INIT because the XTIDE takes over. Is there a way to deal with this on the Book8088? Perhaps even getting the PicoMEM to load the XTIDE BIOS? I'm using n0p's BIOS at the moment.
sergey
Veteran Member
@Betamax80 I am not closely familiar with the PicoMEM board.
Are you not seeing any PicoMEM BIOS output at all? Or you can't boot from it?
The 8088 BIOS searches the upper memory (D0000-F8000) for BIOS extensions in ascending order.
It might be possible that if you swap the addresses of XUB and PicoMEM BIOS extensions, you'll change the boot behavior, or at least the card initialization order.
Unfortunately, on pre-PnP systems, combining multiple bootable BIOS extensions doesn't always work. It really depends on the implementation of the particular BIOS extension.
For example, in most cases, bootable BIOS extensions will redirect the INT 19h (IPL - initial program loader) to themselves. So that, they can boot the system using the storage/network devices that they support.
Of course, there's only one INT 19h vector, so only one piece of code will get to handle it...
Depending on the implementation of that piece of code, it might boot from its own device right away, or offer some kind of mechanism to boot from other devices, which is done by saving the previous INT 19h vector, and calling that...
XUB, if I am not mistaken, completely replaces INT 19h with its own code, that offers boot from an HDD or a CF card, floppy drives, and serial port (if compiled/configured).
Same problem exists with INT 13h - disk services. But here, BIOSes typically will try to chain the interrupt call, that is if the particular disk number is not serviced by the given BIOS extension, it will be passed down the chain to the next (previous) INT 13h handler...
Are you not seeing any PicoMEM BIOS output at all? Or you can't boot from it?
The 8088 BIOS searches the upper memory (D0000-F8000) for BIOS extensions in ascending order.
It might be possible that if you swap the addresses of XUB and PicoMEM BIOS extensions, you'll change the boot behavior, or at least the card initialization order.
Unfortunately, on pre-PnP systems, combining multiple bootable BIOS extensions doesn't always work. It really depends on the implementation of the particular BIOS extension.
For example, in most cases, bootable BIOS extensions will redirect the INT 19h (IPL - initial program loader) to themselves. So that, they can boot the system using the storage/network devices that they support.
Of course, there's only one INT 19h vector, so only one piece of code will get to handle it...
Depending on the implementation of that piece of code, it might boot from its own device right away, or offer some kind of mechanism to boot from other devices, which is done by saving the previous INT 19h vector, and calling that...
XUB, if I am not mistaken, completely replaces INT 19h with its own code, that offers boot from an HDD or a CF card, floppy drives, and serial port (if compiled/configured).
Same problem exists with INT 13h - disk services. But here, BIOSes typically will try to chain the interrupt call, that is if the particular disk number is not serviced by the given BIOS extension, it will be passed down the chain to the next (previous) INT 13h handler...