CUzeBox - The new official Uzebox emulator

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by uze6666 »

Man, that would be awesome! This would make keyboard-based apps more easy to develop and share...including of course my next project :P . I'll send you a complimentary assembled Kb module then, along with with your Uzenet interface order. If you don't already have a PS/2 keyboard laying around, this Perixx one from Amazon is excellent and inexpensive. And it's also unbranded, so perfect to put a Uzebox logo :geek:. And, of course, I will gladly help with the communication protocol if you need any help.
perixxkb.JPG
perixxkb.JPG (44.22 KiB) Viewed 1955 times
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by Artcfox »

uze6666 wrote: Fri Feb 10, 2023 3:36 am Man, that would be awesome! This would make keyboard-based apps more easy to develop and share...including of course my next project :P . I'll send you a complimentary assembled Kb module then, along with with your Uzenet interface order. If you don't already have a PS/2 keyboard laying around, this Perixx one from Amazon is excellent and inexpensive. And it's also unbranded, so perfect to put a Uzebox logo :geek:. And, of course, I will gladly help with the communication protocol if you need any help.

perixxkb.JPG
Awesome, that sounds great! Thank you.

I have multiple Filco Majestouch 2 keyboards that are USB, but came with passive USB -> PS/2 adapters if you want to use their N-key rollover feature. I believe the USB keyboard protocol is limited to transmitting a maximum of 6 keys pressed at the same time, which in some games can be too limiting, but PS/2 does not have that limitation, so they added a diode for every switch and included a PS/2 adapter so the OS can recognize ANY number of simultaneous keys pressed.

Though maybe for initial dev purposes, I should probably use something significantly cheaper than my limited edition yellow Filcos, so thanks for the recommendation! :lol:

I have built a USB HID device using an ATtiny85 before, it used the awesome V-USB library, and controlled an industrial stack lamp that I hooked up to my bash prompt, so when it was executing a program it would light up the yellow bulb, and depending on the exit code of the previous command, it would either light up the green or red bulb. That's where I learned about the extremely high inrush currents of traditional 12V filament bulbs! I don't remember if my first revision used solid state relays or optoisolators, but the inrush current through a cold filament bulb latched them so hard that they desoldered themselves from the PCB, and I had to switch over to 12V LED bulbs to save the project. :idea:
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

Artcfox wrote:
I have built a USB HID device using an ATtiny85 before, it used the awesome V-USB library, and controlled an industrial stack lamp that I hooked up to my bash prompt, so when it was executing a program it would light up the yellow bulb, and depending on the exit code of the previous command, it would either light up the green or red bulb.
That's pretty cool functionality, expecially useful for industrial stuff.

On cUzeBox keyboard, how would people see this working? I think these are basic questions to establish the goal posts:
  • If a game performs the action of looking for a keyboard, should it be assumed to always start emulating a keyboard?
  • how can plugging/unplugging a keyboard be simulated? Sacrificial key(which one?), or some break sequence like Ctrl+K? Is that even needed?
  • could one just convert SDL events into the equivalent dongle outputs by table(faster High Level "Emulation") to the controller port?
  • Radical: Would there be benefit of emulating an atTiny85 since it seems a perfect little chip for other such conversions?
My thoughts would be:
yes
Ctrl+K
yes
not worth it/slower
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by uze6666 »

If a game performs the action of lookin ... keyboard?
I would have to look at how I implemented the code in Uzem but why not. I would not see why one would want to switch back to a controller from the keyboard in the same program, apart from the controller tester perhaps? I think emulating the tiny85 is a bit overkill at this point IHMO. In Uzem, SDL key events are converted to scan code via a table, so I would just do the same.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

Hadn't tried Uzem in a long while, I definitely used it at some point, butI forgot you already did that! Makes sense to use the same implementation then. Emulating another micro would probably hinder browser support pretty bad.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

So keyboard goals seem pretty much demonstrated as to what they will be, which will be a big deal to have in cUzeBox. Makes sense to basically port Alec's code over and call it a day. Keyboard is required for true use of Uzenet use IMO.

Speaking of implementing Uzenet essentials, I have converted the old ESP8266 stuff from Uzem to cUzeBox. It compiles, that's it since it's not as obvious how to "add UART" but think I see it now.

Pretty sure no one ever tried the original unthreaded Uzem version, but it actually worked for the limited test and I managed to populate a chatroom with emulated guests. I was quite amused with it anyway. It was horribly slow however since it was very naive in it's command checking versus a byte being read. CUzeBox runs quite a lot faster from the get go. I converted from C++ to C, and halfway translated to cUzeBox coding style so far.

My questions there:
  • is anyone else working on this, planning to, or wish to be involved?
  • given the processor really can't be emulated, does the High Level Emulation at the AT level I'm suggesting seem reasonable? What other option is there really?
  • emulated ESP8266 will respond regardless of what baud setting are selected. This avoids a huge host of various emulation items, just use a known working value. Not that big a compromise considering it's one line of code in game?
  • UART timing is completely fake by design. The kernel's UART code throttles the throughput to semi-realistic levels, and I see no gain to not use the kernel implementation anyway. This "Emulated" UART is tje same as the Uzem version: always ready to receive a byte. If there is data from the ESP8266, it always just received a byte if asked(transfers are instant, and you cant lose bytes by waiting too long). Full emulation of that circuitry(framing bits, etc) seems very heavy and difficult. Acceptable? Not really a question, someone else could add that later if wanted, it's way beyond my knowledge or interest.
  • You would have to verify timing on real hardware, with no plan to ever perfectly support timing due to ridiculous burden(not even a commercial ESP8266 emulator exists), but it might be close in some cases due to the way the kernel handles UART. You could copy timing sequences from existing code and expect it to work first time on hardware. You can never depend on network timing anyway, but it would be inherently less latency than the real thing. Latency simulation is a thing I would consider necessary for development to be added later. Better ideas?
  • should there be a separate config file for ESP8266 or how to do that? In Uzem I started a separate file which represented the ESP8266 non-volatile memory. In reality it is not very many variables.
So the insane thing I started(Linux only, Windows seems no harder)was passing through emulated UART bytes to a real serial device on the host. The timing is extra fake then, because the OS will let you buffer a huge amount of data to the device. If you actually send that much in a row at the real thing, it just stops working as expected at some point. The OS also lets you buffer a lot of data before reading, not sure...megabytes maybe? I briefly looked at limiting this...eh...maybe possible, but at best I think you wont simulate real conditions no matter what without asm on the x86 side. No real gain IMO so I'd leave that to someone else who cares.

This crazy idea would be for a more accurate ESP8266 in the emulator, without the additional load on the CPU. You could then develop ESP8266 specifics in the emulator like firmware updaters. Basically USB TTY(Arduino?)<->real ESP8266. The problem becomes there is no way to handle the reset pin. I have some code trying to turn the serial port extra pins into GPIO, but they simply are not that universal I found so I gave up on that. An Arduino is cheaper and more useful than a dedicated console cable for that, so I'm thinking that is a solution?

TL;DR

Basically it seems possible to add the missing ESP8266 features and achieve full speed, but accuracy will need to be enforced by code not doing impossible things. By using a real ESP8266 and sticking non to kernel UART, you can develop such code in the emulator and final test on Uzebox with likely success(my guess). This keeps speed up in the emulator. I don't believe an accurate ESP8266 emulation is needed or will ever exist frankly.

CUzeBox implementing host serial device support(relatively easy, I'll finish either way as I had to implememt similar serial code for work) would allow more than just ESP8266 use. It should be possible for instance to redirect RoseGarden MIDI output to cUzeBox to achieve the "Dream Machine of MIDI development". Not tested at all, I'm just saying a naive implication/assumption for such a low development time cost.

The host serial should be done soon to bypass the need for finished ESP8266 emulation. I can't finish MegaBomber without such a thing. Too impatient for development on real hardware, and it takes me 100,000 compiles to complete such things anyway :lol:
User avatar
danboid
Posts: 1935
Joined: Sun Jun 14, 2020 12:14 am

Re: CUzeBox - The new official Uzebox emulator

Post by danboid »

D3thAdd3r wrote: Sun Mar 26, 2023 12:04 am It should be possible for instance to redirect RoseGarden MIDI output to cUzeBox to achieve the "Dream Machine of MIDI development".
cuzebox UART support is one part and the other is having RAM patches, then a UzeSynth-alike that supports patch editing. That'd be the main dev use of the Uzebox keyboard for me - editing and previewing patches.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

danboid wrote: Mon Mar 27, 2023 11:39 am cuzebox UART support is one part and the other is having RAM patches, then a UzeSynth-alike that supports patch editing
You're right, it's sort of a chicken/egg problem on a lot of this stuff really. I believe basically the same about this as anything: if the emulator supports it, it will get more attention.

At least if this UART/MIDI section can work in cuzebox(where most development happens I imagine), it seems more likely someone would go nuts and complete out the whole package. It would need to be easier/faster than just recompiling patches(which is very fast, but not real time) so someone would have to think out the interface to how all that works, including saving things to SD, and converting that to data files to compile into a game when complete.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

Alright after some bug fixes, CUzeBox has keyboard support that matches Uzem behavior. If anyone wants to handle GitHub so this can eventually make itnto main branch please PM me. I've never merged anything before, not sure where to start.

Ok...I went nuts. Keyboard support took some restructuring to CUzeBox input system since it has to passthrough all keys(you lose control of hotkeys like pause, fullscreen, etc.). This restructure was the hardest part, but then with that it basically made room for the SNES mouse.

Mouse is basically implemented but will take a bit more time before it's usable, and I have questions. I added F6 to cycle through mouse "scaling" which effectively means sensitivity. The emulated mouse itself always reports "low sensitivity" at the SNES protocol level as in Uzem. Pressing F6 through all the scaling will "unplug" the mouse. Pressing again plugs it back in at the lowest sensitivity and you can cycle back through as needed.

However things get more complex with keyboard passthrough, since CUzeBox wont receive the hotkeys then. What I did is add a special emulator only "Ctrl+F1", which effectively unplugs the virtual keyboard dongle(restoring P2 joypad inputs). Pressing just F1 again is captured by CUzeBox(as it's then not passed through) to "plug it back in", which will again capture all keyboard input. This allows the user to utilize emulator controls at will, and full keyboard use in a program(besides the Ctlr+F1 combo).

Though F6 alone is enough to plug/scale/unplug the mouse when the keyboard passthrough is off, it doesn't work if the keyboard dongle is active. So I added an additional "Ctrl+F6" emulator only command which operates as F6 when not in pass through mode.. This is the easiest possible way I can think of, that still allows the user any possible combination. Basically you can control the mouse with or without the keyboard active. F1 and F6, in passthrough add the Ctrl.

Here's the catch, this scheme relies on keyboard always being P2, and mouse always being P1 for code and user simplicity. Actual hardware players might like to have a gamepad in P1 and a mouse in P2. IMO placing the burden on mouse only games to support either mouse in P1 or P2 is the only reasonable answer. It will still work in the emulator then with a hard restriction of mouse to P1, while keeping things simple and not requiring nore special keys, states, or input configuration.

Does that seem reasonable?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: CUzeBox - The new official Uzebox emulator

Post by D3thAdd3r »

Alright I created a branch available here: https://github.com/weber21w/cuzebox-keyboard-mouse
It works as described above. Ctrl+F1 to break out, F1 to re-enter passthrough mode.

This time I'm going to make an honest effort at source control. Have lost too much code in the past. This will be for development on keyboard and mouse. Keyboard should work perfect right now, but the mouse is not working yet so leave it disabled. Anyway for anyone needing keyboard right now here it is. I will come back to mouse later, unless someone is in dire need of it currently. It's at least generally in the right place and consuming SDL mouse events.

Goal here is to use this as the base of the separate ESP8266 emulation branch. Should be easier to merge this way, hopefully. Just pulled it and it worked for me under KeyboardDemo, let me know!
Post Reply