Yoghoo wrote on 2026-08-23, 09:05:

Received the ISA extension kit yesterday. Was already pre-solderend so that was a nice surprise. An ALS-100 sound card was detected but OPL3 came from the laptop speaker (as suspected). As there is no line-in you need to use a audio Y-cable to redirect both outputs to external speakers. Or setup the sound card differently but that would still need external speakers and would probably hurt game comparability.

If using an external soundcard, Im sorely tempted to wire up that unused jack socket on the internal soundcard as an input. Pretty straightforward to do;
The circuit used to sum the covox output and the OPL3 sound is a bit of a fudge really, but if you add a couple of resistor from the unused socket to the volume control, basically like R27 & R28 for the covox signals, it would work as an input for external sound sources, so you can use (& mix with the internal sound) external source and have them play from the internal speakers. It looks like the ring on the socket isnt grounded, so you might need to do that as well. In an ideal world you'd add a couple of capacitors like c36&c37 as well as the resistors, but as most things have capacative coupling on their outputs you'd prob getaway without...

I guess im thinking of this as im toying with the idea of designing an external plug in that is essentially the digital playback part of a soundblaster, so in an ideal world i'll try and keep it portable...

Edit, whilst I need the internal OPL3 to work with my idea, I guess with a 'proper' external soundcard you'd want to disable it? There is an option to turn the covox off, but not theOPL3?

Jules_nerd wrote on 2026-08-23, 15:36:

Did you check the PS2 connector itself? sounds like you checked pretty much everything else...
Check for shorts as well as continuity?

I checked the PS2 connector as well. Checked continuity and values (as good as is possible without desoldering SMDs etc). Didn't check for shorts on the mainboard, only on the PS2 connector.

Jules_nerd wrote on 2026-08-23, 15:48:

Edit, whilst I need the internal OPL3 to work with my idea, I guess with a 'proper' external soundcard you'd want to disable it? There is an option to turn the covox off, but not theOPL3?

There is no BIOS option to disable it. Also there is no option to set the resources for it unfortunately.

Yoghoo wrote on 2026-08-23, 16:10:

Jules_nerd wrote on 2026-08-23, 15:36:

Did you check the PS2 connector itself? sounds like you checked pretty much everything else...
Check for shorts as well as continuity?

I checked the PS2 connector as well. Checked continuity and values (as good as is possible without desoldering SMDs etc). Didn't check for shorts on the mainboard, only on the PS2 connector.

when you say as good as possible in circuit.. I get you, in fact i checked on my pocket, which has the same circuit. I got bang on 4k7, though I know my meter doesnt tend to use a high enough voltage for semiconductors in circuit to cause an issue (and Im not talking one of my posh bench meters, just a cheapo handheld)..
Obv YMMV with different meters...

So, I was investigating why the touchpad fails to be detected so frequently, and while making experiments realized that sometimes after you reset it, the touchpad will take about HALF A SECOND to begin the handshake.

I had noticed in my test program that it was sometimes taking a while to printf the 'M' character (the first character that should come from the mouse after you reset it), but kind of dismissed the delay as some issue with my print routines 😁
I could not figure anything else wrong with the handshake, until at some point it clicked that maybe the delay was not my fault... and then everything made sense.

Online sources say that from reset to the 'M' it should take 20ms at most.
Cutemouse and most other DOS drivers expects this to take about 2 BIOS ticks at most (~100ms).
But actually this thing sometimes takes a whopping 500ms!
I patched cutemouse to increase the wait delay to 8 ticks and now it is much more reliable.

Con is that obviously mouse resets are slow (and they happen everytime you launch something in DOS...). 🙁
Plus the 8 ticks wasted waiting for a non-existent mouse everytime we search COM1...
And of course this does nothing in other OSes...
This is definitely a bug of the 8051/STM code since I'm quite sure it's the one emulating the mouse. Yes the delay is variable but I have no idea what would be causing this huge variability in delay other than the 8051 program itself...

javispedro1 wrote on 2026-08-26, 21:38:

So, I was investigating why the touchpad fails to be detected so frequently, and while making experiments realized that sometime […]
Show full quote

So, I was investigating why the touchpad fails to be detected so frequently, and while making experiments realized that sometimes after you reset it, the touchpad will take about HALF A SECOND to begin the handshake.

I had noticed in my test program that it was sometimes taking a while to printf the 'M' character (the first character that should come from the mouse after you reset it), but kind of dismissed the delay as some issue with my print routines 😁
I could not figure anything else wrong with the handshake, until at some point it clicked that maybe the delay was not my fault... and then everything made sense.

Online sources say that from reset to the 'M' it should take 20ms at most.
Cutemouse and most other DOS drivers expects this to take about 2 BIOS ticks at most (~100ms).
But actually this thing sometimes takes a whopping 500ms!
I patched cutemouse to increase the wait delay to 8 ticks and now it is much more reliable.

Con is that obviously mouse resets are slow (and they happen everytime you launch something in DOS...). 🙁
Plus the 8 ticks wasted waiting for a non-existent mouse everytime we search COM1...
And of course this does nothing in other OSes...
This is definitely a bug of the 8051/STM code since I'm quite sure it's the one emulating the mouse. Yes the delay is variable but I have no idea what would be causing this huge variability in delay other than the 8051 program itself...

Excellent stuff!
I suppose that others have found linux (which distro/version?) to be OK must just be random luck that it has a longer delay? TBH I tend to use a PS2mouse, but on the few occasions Ive done it I didnt notice an issue with windows? I guess that must also have a longer delay?
I think we had a misunderstanding earlier, or maybe I got it wrong I cant remember, I agree that the 8051/ST micro is doing the translation, but I'm guessing there may be another driver IC on the trackpad/LCD?? so is there a possibility the issue is with that? After typing.. I suppose the 8051 code is the most likely candidate...

Whilst we cant easily re-do the code... if we had more details on the trackpad - which I guess is just an LCD with a captouch interface & a couple of separate switches... maybe it might be possible to bypass that part of the existing 8051 (hoping the code will still run with no response from the trackpad controller?) & add another micro that does these switches and the captouch translation to serial mouse protocol part? lift the COM2 pins on the exiting 8051 and connect our own micro to those pins no the m6117?

TBH again I'm not a software engineer & I use a PS2 mouse 99.9% of the time... but I'll chip in where i can, I/when I take it in bits I'll have a look for any ICs used on the touchpad, I'm guessing there is a PCB for it with anther IC on it...

I don't know how I missed the Book386.. glad they finally got an ISA-16 breakout built. My breakout board is fine but the lack of a (cheap) off-the-shelf 1mm pin pitch IDE style connector was a deal-breaker with building more than a couple.

I liked the new 8086 series laptop enough as an upgrade to give this a go. And a physical floppy drive for a few bucks is also a plus.

Ordered one up! Looks like I don't have the joy of discovering all the bugs this time... I'll have to go and read the backlog of messages and see what deviltry I'm in for this time 😀.

Excellent thread and forum. I have lurked a lot, but since I'm no engineer, not a lot to chime in.

However, I got the Book 386. I was tempted a lot by Pocket 386, but felt it was too much like a toy. Well, Book 386 is also a toy, but a toy in a pretty decent laptop form factor and with a network adapter (this was important to me, getting Pocket 386 online seemed like a hassle), so I decided to dive into late summer nostalgia and party like it was middle school again.

First of all, I'd like to mention that the one I got is with EU power adapter and Windows 95 on the included CF (it has been mentioned here earlier that they came all with USA plugs and WfW 3.11; even the included manual indicates the latter). I ordered from Tindie in mid-August, after it had been restocked (earlier batch ran out in late July). Interestingly, no EU customs formalities whatsoever, it just appeared at my address with the price paid at Tindie.

Anyway, I threw out the Win 95 and with 86Box installed MS-DOS 6.22. Copied that image to CF and installed WfW 3.11 on bare metal. So far so good, after some tinkering got USB flash drives to work (if they are 1 GB FAT16 partitions) and also the machine very much online.

However, the much discussed touchpad is driving me crazy. WfW 3.11 had no problem with it before installing network and it still doesn't when booted without one ("win /n"). However, as soon the network is on, there is no mouse. Any ideas how to solve?

Also, while being aware (from this thread among other sources) that it is a very much experimental product, I'm kind of disappointed that often it powers on without the screen on. Power off-power on usually helps. Another thing I'm wary of is the power brick connector. It seems kind of loose and I sometimes have to kind of jiggle it (or press while holding the Book) for it to start charging.

Overall, wouldn't move mission critical stuff onto that platform yet. 😀 But it has its charm.

Jules_nerd wrote on 2026-08-27, 10:57:

Excellent stuff!
I suppose that others have found linux (which distro/version?) to be OK must just be random luck that it has a longer delay? TBH I tend to use a PS2mouse, but on the few occasions Ive done it I didnt notice an issue with windows? I guess that must also have a longer delay?

Windows 3.x waits for 2 ticks, then resets again, and then waits for 8 ticks, so yes, it has a longer delay*. That said, even with these, I have seen Windows fail to detect the mouse, likely because the second reset may be done before the first has finished, and therefore delaying the reply from the 2nd reset... . On 9x I have a similar issue, or sometimes device manager will show the (!) sign on the device , or sometimes it will complain about no mouse installed (... and sometimes will do so even when the touchpad appears to work 😜 ). But overall I'd say for Windows it works about 70% of the time, while for DOS/Cutemouse it worked only about 30% of the time before the patch.
It's only NT , Linux, OS/2 who don't seem to have this issue, and my wild guess is because they may have better hotplug support . i.e. if you plug the mouse while running , are they supposed to detect it w/o rebooting ? When the mouse "hello" message arrives late, it just looks as if you hotplugged it. Linux (gpm or X) for sure doesn't care, dunno about the rest.

*EDIT: Actually, the normal MOUSE.DRV waits for 4 ticks, so it's slightly better than CTMOUSE there but still short, which explains the result. I can patch that one to also wait for 8 ticks and it improves the success ratio significantly.
In addition, it seems LMOUSE.DRV (the Logitech one) uses a different strategy (not yet known to me) which works a lot better, dunno why, albeit it doesn't have PS/2 support so I prefer MOUSE.DRV .

Jules_nerd wrote on 2026-08-27, 10:57:

I think we had a misunderstanding earlier, or maybe I got it wrong I cant remember, I agree that the 8051/ST micro is doing the translation, but I'm guessing there may be another driver IC on the trackpad/LCD?? so is there a possibility the issue is with that? After typing.. I suppose the 8051 code is the most likely candidate...

From the schematic I saw TFT and CTP lines coming to the 8051, and when I google that, I get hits of generic "3.5 TFT with capacitive touch panel" kits and the like, which I think makes sense. So there may be an IC there, but it is just part of the generic touch kit, and my guess is that this sends just the touch coordinates to the 8051, which then uses it to simulate the serial mouse and that goes into the COM2 UART (via the clearly marked COM2 TX/RX pins). I did not find how the COM2 RTS/CTS goes into the 8051 but it's likely there too.

The only other alternative would be some touch screen with an actual serial mouse interface (i.e. like a touchpad from a real laptop), and that doesn't seem the case, first because then the 8051 would needlessly be in the middle (why not connect such real touchpad directly to the M5113?) , and second because I've been trying to send stuff via COM2 and this doesn't act like any (real) serial touchpad that Linux knows.

Actually it just doesn't seem to do nothing with data sent to it. It just gives the 'M3' signature back when you reset it. Which identifies it as a MS 3 button, even though it doesn't have a 3rd button 😀 (also explains why Cutemouse calls it "logitech").

Jules_nerd wrote on 2026-08-27, 10:57:

Whilst we cant easily re-do the code... if we had more details on the trackpad - which I guess is just an LCD with a captouch interface & a couple of separate switches... maybe it might be possible to bypass that part of the existing 8051 (hoping the code will still run with no response from the trackpad controller?) & add another micro that does these switches and the captouch translation to serial mouse protocol part? lift the COM2 pins on the exiting 8051 and connect our own micro to those pins no the m6117?

Yes, albeit you need to figure out how to also read the other RS232 signals like CTS/RTS to detect when the host is trying to reset you.

EDIT: actually I realize I missed the RTS2# in the schematic, which clearly is bringing the COM2 RTS from the M5113 in to the 8051. So that explains it 😀 That's all the signals you need to emulate a serial mouse.

Good thing that he wired the COM2 TX line, even if it seems useless now, is in the future a custom serial mouse emulator could switch to a "serial touchpad" mode for the OSes that support it . And gain support for two finger scroll or sth 😀

Also: the FN+3 hotkey simply disables sending the 'M3' signature when the host toggles the RTS line (reset). The 8051 will still happily send mouse movement, but it will not send the signature, so most mouse drivers will fail to detect anything.

Jadavärat wrote on 2026-08-27, 20:22:

However, the much discussed touchpad is driving me crazy. WfW 3.11 had no problem with it before installing network and it still doesn't when booted without one ("win /n"). However, as soon the network is on, there is no mouse. Any ideas how to solve?

Before taking conclusions , as I'm discussing above for me this looks like a completely random issue. Sometimes, if you are unlucky enough, it will fail 5 times in a row.... so I suggest you really try it a significant number of times (by this I mean, restarting Windows). I have definitely managed to make it fail without network and I have definitely managed to make it work with network, with more or less the same probability.

Jadavärat wrote on 2026-08-27, 20:22:

I'm kind of disappointed that often it powers on without the screen on.

This has not happened to me , albeit I remember it happened once or twice in the pocket386.

If there's a touchpad mouse issue wait until it should've occured in Linux then check the dmesg output. Quite a few issues will quietly correct but get logged.

Linux drivers tend to be robust against poor hardware implementations if they're for very widely adopted hardware. And there've been downright bizarre touchpad implementations over the years (looking at you, i2c).

Jadavärat wrote on 2026-08-27, 20:22:

Also, while being aware (from this thread among other sources) that it is a very much experimental product, I'm kind of disappointed that often it powers on without the screen on. Power off-power on usually helps. Another thing I'm wary of is the power brick connector. It seems kind of loose and I sometimes have to kind of jiggle it (or press while holding the Book) for it to start charging.

Overall, wouldn't move mission critical stuff onto that platform yet. 😀 But it has its charm.

In general, despite all the messages on here, Id say the Book is much less experimental than the pocket, I think they have fixed many of the issues, its much more solid...
really the only issues I think weve seen are:
edit!!s OK I keep reading back and finding more faults or niggles!! however they have been pretty minor to me and its a pretty usable product.

1. Trackpad issue, though for those of us that use a PS2 mouse, not a problem
2.The keyboard seems to use some non standard codes, Im not sure this has really caused an actual problem for anyone?EDIT javispedro1 pointed out that international keyboard layouts are unusable... though Ive not tried out the keyboard response issues that others reported with the pocket.
edit! 3. The power on reset is much better than the pocket, but its not 100%, occasionally Ive seen the time jump back or forwards 10-15 mins on a power cycle, others have seen a BIOS reset to default, but it happens much less than on the pocket & no annoying POST beeps when it does!
edit 2!! 4. The fan is noisy, Im not sure we can really call this a fault, certainly I don't like it.. but it does the job its supposed to do.... I suspect that the NTC in mine has a lower value pull up resistor (2k7??) than on the schematics & I havent done the maths to check,, but from what javispedro1 said about the NTC voltage readings & fan speeds on his I suspect the pullup resistor on his is 10k in the schematic. Regardless both of ours get up to full speed when running....

5. Some seem to find the CF slot awkward, though Ive had no problem - I just hook a fingernail under the lip on the lower edge of the CF card and they pull straight out?
6. Com1 'echo' or any DOS command sending text to the serial port seems to make it hang... Ive not used it for anything yet, but it seems to pass all tests using hardware test software (like Checkit) and a loopback plug - so the hardware seems OK, it looks like some issue with the BIOS routines??? I presume that most test software writes directly to the serial port address but DOS uses BIOS routines???
7. not really a fault, with hindsight, I misunderstood the published text on it, you need to set the LPT1address to the default normally used for LPT2 to ensure that the COVOX works with software that checks for a real LPT2 port.

I think thats it isnt it?

Yoghoo has had a problem with the PS2 connector on his, but that seems to be a one off hardware fault on his particular book.
I echo javispedro1 on the screen issue you mention, Ive not seen that on the book (I did notice on the pocket that when the +5V drops a bit, like when you plug n the power connector, the voltage is high enough to keep the pocket running, but the screen, or at least its backlight, cuts out briefly)
Also no need to press or move the power connector on mine, it works perfectly, unfortunately it sounds like you have a hardware fault specific to your unit, I think Id talk to the supplier and see what they can offer?

Jules_nerd wrote on 2026-08-28, 10:35:

1. Trackpad issue, though for those of us that use a PS2 mouse, not a problem
2.The keyboard seems to use some non standard codes, Im not sure this has really caused an actual problem for anyone? though Ive not tried out the keyboard response issues that others reported with the pocket.
edit! 3. The power on reset is much better than the pocket, but its not 100%, occasionally Ive seen the time jump back or forwards 10-15 mins on a power cycle, others have seen a BIOS reset to default, but it happens much less than on the pocket & no annoying POST beeps when it does!

My input on those issues:

1. I fortunately don't have any trackpad issues anymore. In the beginning I had them but since using a Microsoft mouse driver I don't have them as far as I know. Don't use the mouse that often to be honest so maybe it can popup sometimes without noticing.
3. I never had it jump back or forwards. I have regularly that it just resets the time/date completely. Bit annoying.

My biggest issue (as I mentioned earlier) is the PS/2 mouse not working. But that's probably an issue which is only on my laptop.

Inhibit wrote on 2026-08-28, 01:58:

If there's a touchpad mouse issue wait until it should've occured in Linux then check the dmesg output. Quite a few issues will quietly correct but get logged.

Linux drivers tend to be robust against poor hardware implementations if they're for very widely adopted hardware. And there've been downright bizarre touchpad implementations over the years (looking at you, i2c).

For Linuxes of this era, remember that most likely you are handling the mouse in userspace, not in the kernel 😀 E.g. inside XFree86, or gpm (the mouse driver for console).

I have been done my debugging in DOS using cutemouse's protocol.com , which apparently was designed precisely to diagnose serial mouse issues. I had added some printouts everywhere but they were not needed -- it's quite clear that the problem is the 8051 taking too long to send the mouse's hello message after the host tries to reset the mouse (toggling the RTS line).
Obviously I have no clue why this delay is so long and variable in the first place... maybe the 8051 is just polling the RTS2# line too slowly... but in any case this is an issue that we can't fix w/o hardware mod or 8051 fix.

Note that in Linux, if you use X or gpm, it simply doesn't care about what the mouse sends after reset, since you are hardcoding the model of your mouse in the config file . SO it will happily start accepting data from the mouse even if the hello message never arrives, and therefore the delay from the mouse doesn't impact Linux at all.

That also means that FN+3 (the TP ON/OFF) does absolutely nothing in Linux (touchpad always works anyway), because the only thing that does is prevent the mouse from sending the hello message, which as discussed Linux doesn't care about (but DOS drivers care).

Basically:

• If you are using a mouse driver that doesn't work when you disable the TP via FN+3, this means your mouse driver _needs_ the hello message from the mouse in order to work, and therefore it is subject to this issue (because the hello message may take a long time to arrive due to the 8051 bug). The % of times it will work/fail depends on how much time the mouse driver waits for the hello message after reset. Waiting 500ms means it works about 90% of the time, waiting 100ms only means about 30% chance only.
• If your mouse driver still works even after you disable TP via FN+3, this means your mouse driver doesn't care about the hello message, so it's not subject to this issue no matter what (i.e. 100% success ratio).

javispedro1 wrote on 2026-08-28, 11:16:

For Linuxes of this era, remember that most likely you are handling the mouse in userspace, not in the kernel :) E.g. inside XFr […]
Show full quote

Inhibit wrote on 2026-08-28, 01:58:

If there's a touchpad mouse issue wait until it should've occured in Linux then check the dmesg output. Quite a few issues will quietly correct but get logged.

Linux drivers tend to be robust against poor hardware implementations if they're for very widely adopted hardware. And there've been downright bizarre touchpad implementations over the years (looking at you, i2c).

For Linuxes of this era, remember that most likely you are handling the mouse in userspace, not in the kernel 😀 E.g. inside XFree86, or gpm (the mouse driver for console).

I have been done my debugging in DOS using cutemouse's protocol.com , which apparently was designed precisely to diagnose serial mouse issues. I had added some printouts everywhere but they were not needed -- it's quite clear that the problem is the 8051 taking too long to send the mouse's hello message after the host tries to reset the mouse (toggling the RTS line).
Obviously I have no clue why this delay is so long and variable in the first place... maybe the 8051 is just polling the RTS2# line too slowly... but in any case this is an issue that we can't fix w/o hardware mod or 8051 fix.

Note that in Linux, if you use X or gpm, it simply doesn't care about what the mouse sends after reset, since you are hardcoding the model of your mouse in the config file . SO it will happily start accepting data from the mouse even if the hello message never arrives, and therefore the delay from the mouse doesn't impact Linux at all.

That also means that FN+3 (the TP ON/OFF) does absolutely nothing in Linux (touchpad always works anyway), because the only that it does is prevent the mouse from sending the hello message, which as discussed Linux doesn't care about (but DOS drivers care).

Basically:

• If you are using a mouse driver that doesn't work when you disable the TP via FN+3, this means your mouse driver _needs_ the hello message from the mouse in order to work, and therefore it is subject to this issue (because the hello message may take a long time to arrive due to the 8051 bug). The % of times it will work/fail depends on how much time the mouse driver waits for the hello message after reset. Waiting 500ms means it works about 90% of the time, waiting 100ms only means about 30% chance only.
• If your mouse driver still works even after you disable TP via FN+3, this means your mouse driver doesn't care about the hello message, so it's not subject to this issue no matter what (i.e. 100% success ratio).

Does this mean a possible workaround for DOS is to code a mouse driver that ignores the initial handshake?

Yoghoo wrote on 2026-08-28, 11:09:

3. I never had it jump back or forwards. I have regularly that it just resets the time/date completely. Bit annoying.

My biggest issue (as I mentioned earlier) is the PS/2 mouse not working. But that's probably an issue which is only on my laptop.

Well I suppose as the reset circuit seems to be 'on the edge' of working correctly its no surprise that some of us see different effects; potentially even things like slightly different PSU cap values( they are 20% tolerance) could result in different behavior...
Just to be clear, Ive never seen any issues on mine with the PS2 mouse, that seems to work flawlessly...

Jules_nerd wrote on 2026-08-28, 11:20:

Does this mean a possible workaround for DOS is to code a mouse driver that ignores the initial handshake?

Yes definitely, or find one that already worked like this. For such driver you'd have to manually tell it to listen in COM2, because it won't be able to detect that there's no mouse in COM1.
The other alternative is to have a bigger delay -- I had some success patching cutemouse, but the windows driver is more complicated and I'm not sure the patch is really working (difficult to say since success ratio was already higher to begin with due to the longer delay it used).

Google AI tells me you can force the windows driver not to detect the mouse type, but forcce it to use a serial mouse, im just about to try this:

Windows relies on MOUSE.INI to remember which port has been successfully probed. You can force it to assume a device is already present
edit it [mouse]
MouseType=Serial2

in system.ini :
in the [386Enh] part
mouse=*vmd
& in the [boot] part
mouse.drv=mouse.drv

or apparently you can do it in the windows setup, force it to serial mouse?

Of course, for those of us that swap between using PS2 or trackpad, this is a rather unwieldy solution!!! 😁

This is the patched cutemouse btw . The offending line is just

1;----- detect if Microsoft or Logitech mouse present
2
3		mov	bx,0100h		; bl=mouse type, bh=no `M'
4	countloop_ 4,cl				; scan 4 first bytes
5	 countloop_ 2+1,ch			; length of silence in ticks

The last countloop, I have changed from 2+1 (110-165ms approx.) to 9+1 (495-550ms approx). A tick is the usual BIOS tick 55ms.

I am attaching the patched ctmouse 2.0 a4 (i.e. not the 2.1 branch), but any branch can be similarly patched like this, about the same code is present in all of them.

If you try comtest you'd notice that compared to the original comtest, patched one is much slower, but it does detect the "Logitech 3-button" mouse in COM2: all the time (at least for me).
Similarly ctmouse is slower to startup because it'll wait 500ms for COM1, but then it always finds the TP in COM2.

and for dos would
ctmouse /S2 /M

do the job?

Jules_nerd wrote on 2026-08-28, 12:19:

and for dos would
ctmouse /S2 /M

do the job?

Sadly no because the mouse systems protocol (/M) is not the same, i.e. you'd need a way to "force" the MS protocol.
I can test that while it passes "detection" the mouse movement is unusable erratic with this.

Without the /M, it still tries detection.