rasteri wrote on 2022-11-10, 23:29:

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?

Yep, the 86Duino has the SD card pins routed to GPIO group 6 (pins B11-B18), whereas they're on group 8 (A57-A64) on the llama.

Edit: you should be able to boot from a USB stick and flash the original BIOS though?

Eivind wrote on 2022-11-10, 23:35:

Edit: you should be able to boot from a USB stick and flash the original BIOS though?

Yeah I just stole the EEPROM from my old broken SOM-128-EX 😖

Planning for the next revision of the board and looking at various serial-to-modem/ppp wifi solutions (this looks very promising), I'm wondering whether to include a second RS232 port or just making room for an esp8266 module internally.
Pros of another RS232 port: more flexibility, you can connect whatever you want + takes up slightly less board space. Cons: if used with a wifi-modem, a dongle hanging out of the unit (which I don't really like 😀) + requires external power via usb.
Pros of integrating a module: Cleaner, less external clutter and cables, no need to do the TTL->RS232->TTL line level translation. Cons: will have to expand the board size a bit more.

Opinions?

Eivind wrote on 2022-11-11, 10:34:

Planning for the next revision of the board and looking at various serial-to-modem/ppp wifi solutions (this looks very promising), I'm wondering whether to include a second RS232 port or just making room for an esp8266 module internally.

If the goal is network access, wouldn't an ethernet port be more flexible? Unless there's something specific that the serial-to-wifi solution gives you that ethernet won't (and even then you still have a serial port to add one if you like).

I reckon you only need one serial port, especially when you get USB/PS/2 mice working

rasteri wrote on 2022-11-11, 12:47:

Eivind wrote on 2022-11-11, 10:34:

Planning for the next revision of the board and looking at various serial-to-modem/ppp wifi solutions (this looks very promising), I'm wondering whether to include a second RS232 port or just making room for an esp8266 module internally.

If the goal is network access, wouldn't an ethernet port be more flexible? Unless there's something specific that the serial-to-wifi solution gives you that ethernet won't (and even then you still have a serial port to add one if you like).

I reckon you only need one serial port, especially when you get USB/PS/2 mice working

Ethernet is nice, sure, but I figured the serial-to-wifi solution was even better; less cables, more flexibility with placement of the system, modem support for games that don't have a clue what IP is...
I guess technically there's nothing stopping me from having both, but the more ports, the bigger the PCB has to be! 😜

Something I thought about too, to upgrade older boards : what about making a 2nd pcb (only for the older boards, newer revs would include everything as is) with the same connectors as the 86duino so it can be sandwiched between the 86duino and the main PCB to add more functionalities ? I doubt everything a new rev would bring could be brought this way due to the available space, but at least rasteri's HIDman and maybe wifi ?

More tests !

So I wanted to see what the video card was capable of (or rather incapable of), so I was recommended by Scali Bohemiq to test a demo named "Kukoo2" because it makes intensive uses of the raster bars

You can grab it here https://www.pouet.net/prod.php?which=1444

Source code and build tools are available here :
https://github.com/type-one/t1-1994-kukoo2

The reason why I mention the source code is because I initially couldn't even run the demo, the "Pretro" was starting fine, but then it didn't advance any further, I suspect it's doing *something* with the keyboard as I think it expects a keypress, and that I can't do ctrl + alt + delete for a soft reboot (even while the animation is playing so the computer didn't crash).
So I went into the source code and disabled that "pretro" (line 602 if you're looking to reproduce it).

So I launched my new exe and the music played fine, but my LCD didn't like the signal anymore. So I decided to hookup a CRT and was greeted with this :

So I guess that video card really doesn't like this demo 🤣 ... Well at least now we know this demo just cannot be used on this card. I wonder if other things might be impacted by this ...
Also I think the keyboard situation is really problematic, because it means some other programs won't respond to the keyboard at all.
I even tried to do again ctrl + alt + delete while the 2nd part of the demo was playing (so the one with the garbled video) and it didn't work either so the computer didn't hang at all, it's just not responding to the USB keyboard.

Serial mouse update:
I experimented with stripping out pieces of the source code of and recompiling COMTEST.COM to figure out what made it work, and found out it was setting up and enabling the FIFO buffer of the UART, and then turning it off again. I have no clue why that worked, but there we are.
I added that same functionality to the serial setup code in the BIOS. CuteMouse should work with serial mice now, without running COMTEST.
Updated BIOS here.

Deksor wrote on 2022-11-12, 12:47:

So I guess that video card really doesn't like this demo 🤣 ... Well at least now we know this demo just cannot be used on this card. I wonder if other things might be impacted by this ...

Well, the GitHub page of that demo says

You will maybe need a CRT to handle the expanded video mode (384x564 60 hz)

so it doesn't really surprise me that the Vortex86VGA card can't handle this (I assume you ran the demo on a proper computer as well, to eliminate this being an issue with either monitors?).

Deksor wrote on 2022-11-12, 12:47:

Also I think the keyboard situation is really problematic, because it means some other programs won't respond to the keyboard at all.
I even tried to do again ctrl + alt + delete while the 2nd part of the demo was playing (so the one with the garbled video) and it didn't work either so the computer didn't hang at all, it's just not responding to the USB keyboard.

Yeah, looks like the USB-to-PS/2 emulation in SeaBIOS is kinda shitty. Having gotten to the bottom (sort of) of the USB mouse and serial mouse issues, I'll take a look at the USB keyboard stuff next.

Great !
I'm pretty confident the CRT would work with another video card, it's a simple one with no digital controls of whatever. I haven't really it on another machine, but I did test it in dosbox, and although it was glitchy (which I kinda expected), it didn't look anywhere as bad as this.

To me it looks like the video mode "worked", but the tricks used there didn't and ended up making some garbage, because the monitor looked like it synced to something, but that something was garbage.

Since then, I've tried this one :
https://www.pouet.net/prod.php?which=2074
- Crashes when drivers are loaded
- Reboots when the system has no drivers loaded
(maybe freedos related glitches and not tinyllama ?)

And this one :
https://www.pouet.net/prod.php?which=1158
Works fine except for some minor visual glitches where some moving things can have a strange jitter effect and at the very end, instead of going back to the C:\ prompt, it crashes and halts the system.

Deksor wrote on 2022-11-12, 13:58:

Great !
I'm pretty confident the CRT would work with another video card, it's a simple one with no digital controls of whatever. I haven't really it on another machine, but I did test it in dosbox, and although it was glitchy (which I kinda expected), it didn't look anywhere as bad as this.

To me it looks like the video mode "worked", but the tricks used there didn't and ended up making some garbage, because the monitor looked like it synced to something, but that something was garbage.

I don't have much experience with demos, but if I understand correctly they often use more or less undocumented hacks/tricks to squeeze the last drop of performance out of a system, making them pretty fuzzy about the specific hardware they run on? Again, I'm not surprised the TinyLlama isn't the best fit for these with its quirky CPU and simple graphics card... 😉

I've uploaded a new BIOS build where I've disabled the INT 15h, 4F keyboard "hook" and turned off as many debug print statements as possible - hopefully that'll help somewhat with keyboard lag. Please test and see what you think? I think it made a difference in the DOS prompt at least, haven't done any proper tests in games yet.

Eivind wrote on 2022-11-13, 19:10:

I don't have much experience with demos, but if I understand correctly they often use more or less undocumented hacks/tricks to squeeze the last drop of performance out of a system, making them pretty fuzzy about the specific hardware they run on? Again, I'm not surprised the TinyLlama isn't the best fit for these with its quirky CPU and simple graphics card... 😉

Yes, that's pretty much it. I'm not surprised either, but it's a great "benchmark" to see how well things are implemented by hardware 😀

I will test the new bios right now and report asap 👍

Eivind wrote on 2022-11-13, 19:15:

I've uploaded a new BIOS build where I've disabled the INT 15h, 4F keyboard "hook" and turned off as many debug print statements as possible - hopefully that'll help somewhat with keyboard lag. Please test and see what you think? I think it made a difference in the DOS prompt at least, haven't done any proper tests in games yet.

Well it seems to work rather well, I'm not sure it's 100% perfect (a proper test program would be best), however it has a very annoying side effect : keyb doesn't do anything anymore, so localised layouts are broken.

It may not be too bad for you, but for me it means I can't use my AZERTY keyboard properly anymore

Deksor wrote on 2022-11-13, 20:04:

well, I'm not sure it's 100% perfect (a proper test program would be best), however it has a very annoying side effect : keyb doesn't do anything anymore, so localised layouts are broken.

It may not be too bad for you, but for me it means I can't use my AZERTY keyboard properly anymore

Haha, oh no! 😁 I hadn't considered that, I'm always using ANSI layout even with my Norwegian keyboards, can't stand anything else!
But yeah, I guess it makes sense that keyb.com would use that INT15h,4F hook to change letters on the fly... Do you want to do a compilation yourself, reinstating that setting and see if the removal of the hook was what helped the most, or all the debug prints? Tell me if it's too much of a hassle, I can do it as well.

Besides the extra cycles checking for this hook takes, we're sort of limited by the rate at which the BIOS polls for USB events I'm afraid. It hooks into the system timer which fires every 55ms, which is only 18.2 times/sec.
Not sure if it would be possible to make the USB polling happen on another cadence or if that would negatively affect the rest of the system.

I don't have the time for today anymore, but I can try that tomorrow if you want.
Another solution, which would require more work, could be to save the locale in the BIOS maybe ? So keyb wouldn't be needed at all

18.2 times/sec sounds suspiciously close to the default PIT timing. I don't think you can change that clock without having a negative impact on the system, however maybe you can change this function works. This will need some more research though

Deksor wrote on 2022-11-13, 20:30:

I don't have the time for today anymore, but I can try that tomorrow if you want.

I'll give it a shot.

Deksor wrote on 2022-11-13, 20:30:

Another solution, which would require more work, could be to save the locale in the BIOS maybe ? So keyb wouldn't be needed at all

Yeeeah, if it comes to that. But I'm not sure how this is really handled under the hood at all, might be something of a last resort. 😜

Deksor wrote on 2022-11-13, 20:30:

18.2 times/sec sounds suspiciously close to the default PIT timing. I don't think you can change that clock without having a negative impact on the system, however maybe you can change this function works. This will need some more research though

Indeed it is the default PIT timer, and that shouldn't be messed with. My point was, it might be feasible to poll for USB events from another timer loop instead.

@Deksor I've added the keyboard hook back, thankfully it didn't seem to make much of a difference. The input still seems smoother than it was before I yanked out all the debug prints.
Link to the BIOS.

Great !
As I said I'll try it back tomorrow 😀

I did try messing with the PIT after all. Well, not the clock, but the count-down value being programmed into it.
It now fires 8 times as often (at about 145 Hz), and my initial tests are positive. Both the USB keyboard and mouse seem more responsive (though, it must be said, the serial mouse still feels way smoother).
Haven't seen any side-effects, other than the Quake timedemo dropping 0.1 fps.
The updated BIOS is out, if anyone wants to give it a shot.