I also couldn't get a serial mouse to work (Logitech M-C43). The mouse works on another computer. I did successfully use the TinyLlama serial port for bios debugging and also from DOS with a nullmodem connection to another computer.
Tried several mouse drivers (cutemouse 19, 20, 21 and logitech drivers), tried to disable the BIOS USB mouse support, no luck.

I noticed that the MAX3243 (RS232 transceiver on Tinyllama) spec sheet has a few paragraphs about driving serial mice. It does say that the auto power down feature should be disabled for serial mouse support. I didn't try to change this, not sure if it could have something to do with the problem.

florian3 wrote on 2022-11-07, 19:38:

I also couldn't get a serial mouse to work (Logitech M-C43). The mouse works on another computer. I did successfully use the TinyLlama serial port for bios debugging and also from DOS with a nullmodem connection to another computer.
Tried several mouse drivers (cutemouse 19, 20, 21 and logitech drivers), tried to disable the BIOS USB mouse support, no luck.

I noticed that the MAX3243 (RS232 transceiver on Tinyllama) spec sheet has a few paragraphs about driving serial mice. It does say that the auto power down feature should be disabled for serial mouse support. I didn't try to change this, not sure if it could have something to do with the problem.

This might very well be the cause, yes. Good catch! I knew I had successfully tested serial mice (albeit with a raspberry pi emulating a serial mouse) sometime in the past, using the MAX3243 - so I was confident it should work. Going back to the schematics of that early 2019-prototype, I see now that I'd included a pin jumper for the FORCEON feature of the 3243:

...which would explain why it worked then, but doesn't seem to work now. I assume TI knew what they were talking about when saying the auto-powerdown should be disabled for serial mice.

If anyone wants to give it a shot, try cutting the trace between pin 23 (FORCEON) and GND, and bridging pin 23 and pin 22 (~FORCEOFF, which is tied to VCC), thereby pulling pin 23 high:

I'd be very careful, though, as not to accidentally bridge VCC and GND 😉

I lifted the pin and bridged it, still not working.

florian3 wrote on 2022-11-07, 21:59:

I lifted the pin and bridged it, still not working.

Could it be a uart configuration issue? I'm really not that familiar with serial mice, but I think they might usually be communicating at 1200 baud, right? I don't know if CuteMouse or the Logitech equivalent will try to reconfigure the computer's uart to that speed, but if not - try doing that manually? MODE COM1: ...something...?

I got the serial mouse to work by calling COMTEST.COM (comes with cutemouse) before loading the driver.
I haven't figured out yet what makes the difference there.

florian3 wrote on 2022-11-07, 23:34:

I got the serial mouse to work by calling COMTEST.COM (comes with cutemouse) before loading the driver.
I haven't figured out yet what makes the difference there.

Interesting, I can reproduce this too. Just as you say, if I run `comtest` before `ctmouse /S14` it starts working like magic.
The board also seems to work well with a "Razer Deathadder Essential (2021)" USB mouse.

florian3 wrote on 2022-11-07, 23:34:

I got the serial mouse to work by calling COMTEST.COM (comes with cutemouse) before loading the driver.
I haven't figured out yet what makes the difference there.

Looking at the assembly code for COMTEST.COM, I figure there's some kind of setup/resetting of the UART that does the trick. Not super into x86 assembly, though. I'll try to get hold of a serial mouse and see if I can't get this setup/correct configuration done in BIOS.

@eivind

I found the source code for comtest.com here -
https://github.com/TritonDataCenter/sdcboot/b … ity/comtest.asm

Eivind wrote on 2022-11-07, 20:36:

This might very well be the cause, yes. Good catch! I knew I had successfully tested serial mice (albeit with a raspberry pi emu […]
Show full quote

florian3 wrote on 2022-11-07, 19:38:

I also couldn't get a serial mouse to work (Logitech M-C43). The mouse works on another computer. I did successfully use the TinyLlama serial port for bios debugging and also from DOS with a nullmodem connection to another computer.
Tried several mouse drivers (cutemouse 19, 20, 21 and logitech drivers), tried to disable the BIOS USB mouse support, no luck.

I noticed that the MAX3243 (RS232 transceiver on Tinyllama) spec sheet has a few paragraphs about driving serial mice. It does say that the auto power down feature should be disabled for serial mouse support. I didn't try to change this, not sure if it could have something to do with the problem.

This might very well be the cause, yes. Good catch! I knew I had successfully tested serial mice (albeit with a raspberry pi emulating a serial mouse) sometime in the past, using the MAX3243 - so I was confident it should work. Going back to the schematics of that early 2019-prototype, I see now that I'd included a pin jumper for the FORCEON feature of the 3243:
Screenshot 2022-11-07 at 21.01.54.png
...which would explain why it worked then, but doesn't seem to work now. I assume TI knew what they were talking about when saying the auto-powerdown should be disabled for serial mice.

If anyone wants to give it a shot, try cutting the trace between pin 23 (FORCEON) and GND, and bridging pin 23 and pin 22 (~FORCEOFF, which is tied to VCC), thereby pulling pin 23 high:
max3243_surgery.jpg
I'd be very careful, though, as not to accidentally bridge VCC and GND 😉

You lucky it wasnt a fix, as i already have my boards with the other "fix" ( if it is a fix that is, time will tell ) 😜

Serial mice are weird - they typically have no charge pump to generate RS232-compliant voltage levels. So they require negative, positive AND ground voltages to be present across various pre-defined serial pins that vary depending on device manufacturer. I'm not sure how cutemouse handles all the different possibilities, but back in the day you had to use the driver that was specifically written to cope with that specific mouse otherwise the voltages would end up on incorrect pins. Maybe that's what's going on here.

PS/2 to serial adapters are also very manufacturer-specific - the generic ones you find on eBay don't work on ANY of my PS/2 mice (even the ones that say they support serial).

(interestingly, most of the serial mice I've checked actually use the serial port's negative voltage as VSS, and GND as VDD. Probably because this allows for simpler low-side logic switching).

rasteri wrote on 2022-11-08, 11:40:

Serial mice are weird - they typically have no charge pump to generate RS232-compliant voltage levels. So they require negative, positive AND ground voltages to be present across various pre-defined serial pins that vary depending on device manufacturer. I'm not sure how cutemouse handles all the different possibilities, but back in the day you had to use the driver that was specifically written to cope with that specific mouse otherwise the voltages would end up on incorrect pins. Maybe that's what's going on here.

PS/2 to serial adapters are also very manufacturer-specific - the generic ones you find on eBay don't work on ANY of my PS/2 mice (even the ones that say they support serial).

(interestingly, most of the serial mice I've checked actually use the serial port's negative voltage as VSS, and GND as VDD. Probably because this allows for simpler low-side logic switching).

Huh, that's interesting - didn't know that!
I'll be getting my hands on a few serial mice tomorrow, should be able to see if I can't sneak in a little serial mouse detection/setup in the POST part of the BIOS.

Today FedEx came in early (I expected them tomorrow but they came this morning so that's great)

And it works first try 😁

Now there's a minor inconvenience, and I'm not sure if it's a hardware issue or software issue : when I first set the card and doom to irq 5 I had no sfx, but the opl3 music worked. However by setting irq 7 sfx started to work just fine.

The doom version I tried is quite old (v1.2) so it might be just a quirk with this old version of doom, I haven't tried anything else yet (I'm using the usb drive used to flash the bios).

Another thing I noticed is that there seem to be a high latency with the keyboard. Again maybe it's something wrong with my setup and everything should be fine otherwise, but as usb can be pretty demanding for low end devices, I'm not certain of this.

I'll try to make more tests for this later 😀
(I could even make my own latency test program and use a crt for minimal delay)

Deksor wrote on 2022-11-09, 10:04:

Today FedEx came in early (I expected them tomorrow but they came this morning so that's great)
And it works first try 😁

Yay! Good to hear! 😁

Deksor wrote on 2022-11-09, 10:04:

Now there's a minor inconvenience, and I'm not sure if it's a hardware issue or software issue : when I first set the card and doom to irq 5 I had no sfx, but the opl3 music worked. However by setting irq 7 sfx started to work just fine.

Yep, use IRQ 7. I think I already wrote that in the configuration example in the wiki.

Deksor wrote on 2022-11-09, 10:04:

Another thing I noticed is that there seem to be a high latency with the keyboard. Again maybe it's something wrong with my setup and everything should be fine otherwise, but as usb can be pretty demanding for low end devices, I'm not certain of this.

There's bound to be a certain amount of lag with USB keyboards since the BIOS is just polling USB events periodically and then translating them to PS/2. But I'll double check that there are no unnecessary slowdowns in the code, logging or anything else going on there. Hopefully later today/tonight, I just got a few serial mice in that I'll check out as well.

Oh by the way I used a usb drive as a boot device so that probably doesn't help (I don't have any free micro SD card at hand right now)

After I got home from my work I bought a SD card and started messing with it.

I think the keyboard latency was lower using the SD card (to be verified).

I tried to run a few benchmarks, but I noticed some strange shenaningans. 3DBench cannot be quit (I'm not sure if it was possible actually, or if it needs a special key. I tried escape and "Q" but it didn't work). Also Speedsys crashes after the first step, it never reaches the CPU benchmark. With drivers and memory expanders loaded, it will just hang, without, the computer will reboot completely.

Also I wanted to check @rasteri's result when he made his video about this and got 27FPS out of quake and doom, and I can confirm that. I also tried fastvid just in case and it didn't change anything. Topbench reports a 311 µsec delay for vidmem, the rest is of the system seems to be very fast in that system.
However I tested a few more games and benchmarks and these didn't struggle like doom and quake.
Duke nukem 3D with the FPS counter enabled reports 70-80FPS.
Chris' 3Dbench reports 70FPS
PCPlayer benchmark reports 63FPS

So I'm not 100% sur what's up with doom and quake, maybe they use some special video mode these other benchmarks don't and this is causing slowdowns. Since both these games are open source maybe another version of the engine could fix the issue ?

Edit : after launching carmageddon, the keyboard/mouse delay became very very bad. This game is quite demanding and while it runs pretty well on it, the input lag makes the game very hard to play unfortunately. Some keypreses aren't registered and the mouse jumps from place to place. I think a ps/2 connector would be a must have for future revisions

Edit 2 : quake actually runs at 38fps when the CPU is set at 500mhz, so maybe it's just doom being quirky and the rest works fine, I think the 27fps in your video was a coincidence

Edit 3 : using this https://github.com/goshhhy/486quake
I managed to get 44.7fps out of quake486.exe

Does anyone know of a similar thing for doom ? Maybe it could help having a more enjoyable doom on this computer

Deksor wrote on 2022-11-09, 20:42:

I tried to run a few benchmarks, but I noticed some strange shenaningans. 3DBench cannot be quit (I'm not sure if it was possible actually, or if it needs a special key. I tried escape and "Q" but it didn't work). Also Speedsys crashes after the first step, it never reaches the CPU benchmark. With drivers and memory expanders loaded, it will just hang, without, the computer will reboot completely.

I've noticed similar things, my guess is that some of these old benchmark programs freak out because they have no idea what kind of processor is installed and what its feature set is.

Deksor wrote on 2022-11-09, 20:42:

Edit : after launching carmageddon, the keyboard/mouse delay became very very bad. This game is quite demanding and while it runs pretty well on it, the input lag makes the game very hard to play unfortunately. Some keypreses aren't registered and the mouse jumps from place to place. I think a ps/2 connector would be a must have for future revisions

Hm, yeah either that or integrating @rasteri's HIDman solution (having the CH559 chip do the USB->PS/2 translation). What's you guys' take on this? I figure it's better to be able to use modern keyboard/mice than real PS/2 devices, but I might be in the minority about this?

Deksor wrote on 2022-11-09, 20:42:

Edit 2 : quake actually runs at 38fps when the CPU is set at 500mhz, so maybe it's just doom being quirky and the rest works fine, I think the 27fps in your video was a coincidence

I don't think there's anything magical about the 27fps number, no.

Deksor wrote on 2022-11-09, 20:42:

Edit 3 : using this https://github.com/goshhhy/486quake
I managed to get 44.7fps out of quake486.exe

Cool, I'll have to try that! Also, for Quake, it bears mentioning at what resolution these fps numbers are being seen at. The Vortex86VGA is pretty slow and has a pitiful amount of video memory, and really struggles at higher resolutions.

Deksor wrote on 2022-11-09, 20:42:

Does anyone know of a similar thing for doom ? Maybe it could help having a more enjoyable doom on this computer

Try FastDoom! But afaik, the original (and most ports of) Doom are hard capped at 35fps in any case, so you'll probably always have a hard time getting a buttery-smooth experience there! 😉
I'm sure the framerates for most games I played on 486-class systems as a kid were crap, but I can't remember that! 😁

I figure it's better to be able to use modern keyboard/mice than real PS/2 devices, but I might be in the minority about this?

It's alot easier to find USB mice/keyboards nowadays than PS/2 variants, so I agree with you there.
I'm curious to see how much of a difference rasteri's HIDMan will make though.

Eivind wrote on 2022-11-10, 06:12:

Hm, yeah either that or integrating @rasteri's HIDman solution (having the CH559 chip do the USB->PS/2 translation). What's you guys' take on this? I figure it's better to be able to use modern keyboard/mice than real PS/2 devices, but I might be in the minority about this?

This sounds good enough to me. Plus finding a good modern controller should be much easier than finding a good old controller for PC (I think most of the old one aren't very good ...). And the ability to map some keys as keyboard keypreses is a really fantastic thing to add ! Since I mentioned carmageddon, that's something that is very useful when playing this game because it only supports 4-button controllers as far as I know which is absolutely not enough for this game. I remember using joy2key on windows 98 on a pentium 2 just to add the extra buttons as keypreses, but this should be even nicer.

Eivind wrote on 2022-11-10, 06:12:

I don't think there's anything magical about the 27fps number, no.

Well there's still something wrong with doom that makes it run at 27fps.
The game is indeed capped at 35, but this is for the uncapped benchmark so this is very strange (and having 8 extra frames is still good to have 😁). I will definitely try out fastdoom !

Eivind wrote on 2022-11-10, 06:12:

Cool, I'll have to try that! Also, for Quake, it bears mentioning at what resolution these fps numbers are being seen at. The Vortex86VGA is pretty slow and has a pitiful amount of video memory, and really struggles at higher resolutions.

True, I ran every benchmarks at 320x200, like you said pushing it to higher resolutions is asking for trouble and I'm fine with the default VGA resolution.

Hey just for funsies I thought I'd flash the tinyllama bios to my SOM-128-EX to see if it would work on my 86duino one.

It now won't boot from SD card - like it can't even detect it. The boot menu appears.

Is there a difference between how the SD card on the tinyllama works vs the 86duino?

EDIT: Never mind, I see you've moved the SD card pins. D'oh!

I got hold of 4 serial mice and did some testing. Only one of them worked with the 3243 in auto-powerdown mode. After turning that feature off by doing the pin shenanigans described earlier, they all worked. Although - only after running COMTEST. I'll have to get back to that later, did some initial probing around with DEBUG, but nothing solid yet.
So yeah, my take on the auto-powerdown issue is that it's happening too fast for most mice to manage to send anything back before the 3243 kills the DTR/RTS lines powering the mouse.