Page 23 of 23

Re: CUzeBox - The new official Uzebox emulator

Posted: Sat Oct 13, 2018 2:59 am
by uze6666
Thanks for the explanations. Pretty nifty and useful, specially those timing blue bars. Got used to them very fast and could not live without them now. 8-) Fixing timing with the avr simulator was such a chore in retrospect!

Re: CUzeBox - The new official Uzebox emulator

Posted: Sat Dec 29, 2018 7:54 pm
by nicksen782
Hey Jubation!

The new Uzebox Online Player has (working) support for both on-screen gamepads. I send the key event and for game pad two I also send the right alt key. This works for the on-screen controls. I also know that I can hold the right alt key and any keyboard input I give would go to player 2.

However, this doesn't work for some keys. Specifically for alt+space, and alt+s. These must be reserved key combos for the browser. I tried to override this behavior but I could not.

Could you add an additional modifier key for player two? I don't think it matters which key you use just so long as the browser isn't using it. What about the Alt-Gr key? That's the key between the alt and the ctrl on the right side of the keyboard (US keyboards at least.)

Also, here are the cuzebox.js modifications that I made and compiler flags that I set for the online version. Do you have any opinion on these?
I do a string replace in cuzebox.js to remove "cuzebox.html.mem" and I replace it with a base64 data url. Reading through the Emscripten code I found that it accepts either a filename to download or a base64 data url. So, now the emu_core.js is those files combined. I think Emscripten has an official method to combine but I'm doing this for now.

When compiling a new CUzeBox I do a git clone and then I modify Make_config.mk and Make_defines with sed via a bash script. These are the modifications.

Code: Select all

echo
echo '************************************************************************************'
echo Using 'sed' to edit the config files for CUzeBox.

quote=\'
dquote=\"
lbracket=\[
rbracket=\]
TEMPSPOT1=""
TEMPSPOT2=""

# Edit the CUzeBox config file.
# Make_config.mk
sed -i 's|Makefile - configuration.*|Makefile - configuration - Modified for the Uzebox Online Player # CHANGED|' Make_config.mk
sed -i 's|TSYS.*|TSYS=emscripten|'                                     Make_config.mk
sed -i 's|FLAG_NOCONSOLE=0|FLAG_NOCONSOLE=1 #CHANGED |'                Make_config.mk
sed -i 's|FLAG_NOGAMEFILE=0|FLAG_NOGAMEFILE=1 #CHANGED |'              Make_config.mk
sed -i 's|FLAG_DISPLAY_GAMEONLY=0|FLAG_DISPLAY_GAMEONLY=1 #CHANGED |'  Make_config.mk
sed -i 's|FLAG_SELFCONT=1|FLAG_SELFCONT=0 #CHANGED |'                  Make_config.mk

# Make_defines.mk
sed -i 's|CFLAGS+= -DTARGET_EMSCRIPTEN |\n#CHANGED\nCFLAGS+= -DTARGET_EMSCRIPTEN -s ENVIRONMENT=web -s WASM=0 -O3 -s MODULARIZE=1 --closure 0 -s FORCE_FILESYSTEM=1 -s LEGACY_VM_SUPPORT=1 TEMPSPOT1 TEMPSPOT2 |' Make_defines.mk
sed -i "s|TEMPSPOT1|-s "$quote"EXPORT_NAME="$dquote"UOP"$dquote""$quote" |"                                                                                    Make_defines.mk
sed -i "s|TEMPSPOT2|-s "$quote"EXTRA_EXPORTED_RUNTIME_METHODS=["$dquote"FS"$dquote"]"$quote" |"                                                                Make_defines.mk
echo '************************************************************************************'
I'm using the asm.js compile and not the wasm at this point. I do intend to test wasm though since it ends up smaller and could be faster. For this I would need two compile CUzeBox twice. Once for each version. Then, I would do a feature detect for wasm support and provide that otherwise provide the asm.js.

Re: CUzeBox - The new official Uzebox emulator

Posted: Sat Dec 29, 2018 8:35 pm
by Jubatian
Nice solution for automating keeping up with the repo! Changes seem to be fine for me, really, stuff in Make_config should work just as documented, and for the arcane hackery you do with Make_defines is something I can not add much to. You know what compile options get the thing running proper in the online game changer!

I made a change: now both ALT keys would redirect controls to Player 2 (you mentioned that maybe I should add AltGr, but at least by my keyboard layout so far it accepted AltGr only for redirecting to P2).

Re: CUzeBox - The new official Uzebox emulator

Posted: Mon Dec 31, 2018 4:29 pm
by nicksen782
If you go to http://keycode.info/ you can see how the browser interprets keys.

The key that I've been referring to as AltGr is seen as ContextMenu here.

Code: Select all

event.key == ContextMenu
event.location == 0
event.which (deprecated) == 93
event.code == ContextMenu
(I do not know the SDL key. I thought it was the SDLK_LMETA or SDLK_RMETA but neither worked. )

event.key == Alt
event.location == 1
event.which (deprecated) == 18
event.code == AltLeft
SDLK_LALT

event.key == Alt
event.location == 2
event.which (deprecated) == 18
event.code == AltRight
SDLK_RALT

event.key == \
event.location == 0
event.which (deprecated) == 220
event.code == Backslash
SDLK_BACKSLASH
I see by the code changes that you allow now for both Alts to affect the player 2 game pad. But the problem still remains since ALT is used in many browser key combos.

I was hoping to use the context menu key and a blocker such as this:

Code: Select all

// Prevent the context menu from appearing on the emulator canvas. This will allow for it to be used as a combo key.
emu.vars.dom.view.emuCanvas.addEventListener("contextmenu", function(evt){evt.preventDefault(); return false;});
I'm not interested in trying to hide the context menu. I'm more interested in claiming it as a key that I can use however I want. It is right next to the Alt key anyway.

I experimented with adding keys to CUzeBox. I could not figure out the context menu but I was able to configure the backslash key to work. I have no problem with that key. It is only 3 line changes.

Re: CUzeBox - The new official Uzebox emulator

Posted: Sat Nov 23, 2019 12:42 am
by rv6502
I got a patch that doesn't seem to break the Uzebox games and works with my somewhat-degenerate signal generator...

I can submit a proper patch request on github but here it is in short:

Code: Select all

~/builds/cuzebox-master.patched$ diff ../cuzebox-master/cu_avr.c cu_avr.c
596a597
>  auint tdiff;
647,648c648,651
<      if       ( (t1 >=  944U) &&
<                 (t1 <= 1012U) && /* Sync to first normal pulse (978 cycles apart from last rise) */
---
>      
>      tdiff = t1-t0;
> 
>      if       ( (tdiff > t0) && /* Sync to first normal pulse (978 cycles apart from last rise) */
651,652c654
<      }else if ( (t1 >= 1718U) &&
<                 (t1 <= 1786U) ){ /* Sync to first VSync pulse (1752 cycles apart from last rise) */
---
>      }else if ( (tdiff < t0) ){ /* Sync to first VSync pulse (1752 cycles apart from last rise) */
It follows more closely how video hardware detects syncs with a charging capacitor threshold.
The actual duty ratio at which a CRT considers it a vertical sync depends on the V-HOLD potentiometer.

maybe it should be (tdiff <= t0) but nobody should ever output anything anywhere close to a 50% duty-ratio sync signal :lol:

Re: CUzeBox - The new official Uzebox emulator

Posted: Sat Nov 23, 2019 1:08 pm
by Jubatian
rv6502 wrote:
Sat Nov 23, 2019 12:42 am
I got a patch that doesn't seem to break the Uzebox games and works with my somewhat-degenerate signal generator...
Sorry, but this isn't quite functional. It breaks the emulator's capability to correctly follow VSync, so you no longer see whether that part of the video signal is correct. The side bars should remain all blue all the way on Megatris. It might be true that it may follow more accurately what an analogue CRT might be doing for the purpose of syncing to the next frame, but it is important that the emulator gives feedback on whether the sync signal was correct to spec. The video mode should definitely be fixed since some TVs are rather finicky about the sync in one or another way. There are types of deviations to what the emulator is set to be expecting which of course would work fine (such as a consistently slightly narrower sync pulse), but you would only be able to create such correct sync if you also modded both the kernel (providing VSync timing) and the mixer (providing Sync edges). So if you are doing only Video Mode, the sync basically is only correct to the spec. if it is all blue in the emulator on the sides (since the kernel and the mixer produces its own timing outside of the display area which your timing has to match).

Re: CUzeBox - The new official Uzebox emulator

Posted: Fri Apr 03, 2020 4:33 am
by ry755
Would it be possible to add a simple real-time SPIRAM viewer to this? You could press one of the currently unused function keys (F1 or F6) and it would open a small window to the side, like a mini built-in hex editor.

Or if that's too complicated to implement, even just being able to dump the SPIRAM contents to a file would be useful for debugging imo

Re: CUzeBox - The new official Uzebox emulator

Posted: Fri Apr 03, 2020 5:30 pm
by Jubatian
ry755 wrote:
Fri Apr 03, 2020 4:33 am
Would it be possible to add a simple real-time SPIRAM viewer to this? You could press one of the currently unused function keys (F1 or F6) and it would open a small window to the side, like a mini built-in hex editor.

Or if that's too complicated to implement, even just being able to dump the SPIRAM contents to a file would be useful for debugging imo
Guess you are hacking something right about now for which you would like to have something alike. I can give you a bit of help on that:

The interface you need is cu_spir_get_state() from this header: https://github.com/Jubatian/cuzebox/blo ... /cu_spir.h , see the comments describing each, the structure is there on the top of this header, including the 128K SPI RAM data.

The quickest is to patch it into https://github.com/Jubatian/cuzebox/blob/master/main.c , see the main_loop() function, the end of this function is the event processor, where you see the various keys captured. You can add a quick & dirty solution there to grab the SPI RAM data from the SPI RAM module on a keypress of your choice and dump it into a file.

Otherwise nowadays I am trying to create a new emulator based on this one, but with such concepts which would allow it to run just about any ATmega game console, maybe eventually I will also come up with a new UI with greater debugging capabilities. As it is now with SDL1, creating a new window is not even possible (the source supports SDL2 though). Really it should have been done since a while already to also progress with my own ATmega console design, but I am just too exhausted by my job, couldn't manage to get anything substantial done since a while unfortunately.