CUzeBox - The new official Uzebox emulator

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by Jubatian »

Nice! I wonder whether it will actually work in the end, if the bottleneck is the AVR's emulation, that would be a problem.

CUzeBox supports two resolutions (which in SDL2 can be scaled to whatever you like), one is 640x560, the other is 320x280, the latter being faster to render. Normally you can switch between these with F2, in the web emulator this is often useful if your PC is too slow to run it at the higher resolution. For the 3DS, if it has this low resolution, you would also have to drop the displayed debug info, normally F3, then the resolution would be 310x228, which can be centered on its display. You should also turn off frame merging, normally F7, which also has some cost.

The console window on the lower display of the 3DS could also be sluggish, this is easier to turn off, simply by FLAG_NOCONSOLE in make_config.mk. There are also other parameters there: FLAG_DISPLAY_SMALL requests to start at 320x280 resolution, FLAG_DISPLAY_GAMEONLY turns off debug info (so 310x228), and FLAG_DISPLAY_FRAMEMERGE can be used to turn off frame merging.

Otherwise you would have to edit guicore.c to make it fit for the 3DS's display. You may also try to tweak around the debug info to arrange it better on the wide screen (such as moving memory usage display to the side).

Hopefully messing around with this part can make it run better, it depends on the system. Shoveling pixels onto the screen could be notoriously costly, on some systems more, on some others, less, so reducing the count of pixels actually displayed (and frame rate of the display which CUzeBox automatically does as needed) may help a lot.

It is odd for me that it can not report the proper speed, for some reason a proper timing base might just not come through SDL that case, if that's so, it just wouldn't be able to properly adjust its performance.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: CUzeBox - The new official Uzebox emulator

Post by ry755 »

I already edited guicore.c, enabled FLAG_DISPLAY_SMALL and FLAG_DISPLAY_GAMEONLY, and disabled FLAG_DISPLAY_FRAMEMERGE. The 12-15 fps was after those changes. Unless there's some other changes or optimizations I could do, it looks like that's the best it'll get. :(
It does get a little bit faster if I disable the console output though.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by Jubatian »

ry755 wrote: Sun Sep 16, 2018 8:42 amI already edited guicore.c, enabled FLAG_DISPLAY_SMALL and FLAG_DISPLAY_GAMEONLY, and disabled FLAG_DISPLAY_FRAMEMERGE. The 12-15 fps was after those changes. Unless there's some other changes or optimizations I could do, it looks like that's the best it'll get. :(
It does get a little bit faster if I disable the console output though.
As a last resort at easy solutions, you may change the opcode emulator in cu_avr.c, at line 1000. Normally it includes cu_avr_n.h, which I found to be faster in native compiles for the x86. You may switch this to cu_avr_e.h which was intended for Emscripten (where that's faster), and see what you can get out of it.

A disassembly listing might also be interesting, to find how the compiler works it out for this target (alternatively you may fiddle around with compiler setting, if appropriate, to make sure it optimizes for that particular CPU the 3DS has, it could be significant).
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: CUzeBox - The new official Uzebox emulator

Post by ry755 »

Jubatian wrote: Sun Sep 16, 2018 9:01 am As a last resort at easy solutions, you may change the opcode emulator in cu_avr.c, at line 1000. Normally it includes cu_avr_n.h, which I found to be faster in native compiles for the x86. You may switch this to cu_avr_e.h which was intended for Emscripten (where that's faster), and see what you can get out of it.
Changing it to cu_avr_e.h didn't seem to make a difference, it still runs at about 40% speed.
Jubatian wrote: Sun Sep 16, 2018 9:01 am A disassembly listing might also be interesting, to find how the compiler works it out for this target (alternatively you may fiddle around with compiler setting, if appropriate, to make sure it optimizes for that particular CPU the 3DS has, it could be significant).
The optimization is set at -O2, changing it to -O3 made the performance worse.

I'll mess around with it some more tomorrow

Edit: Do you think disabling the spi ram emulation could improve performance?
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by Jubatian »

ry755 wrote: Sun Sep 16, 2018 10:21 amEdit: Do you think disabling the spi ram emulation could improve performance?
No, when a game doesn't use it, there are only a few not-taken conditional branches to it on rarely executed code paths compared to general AVR emulation.

The most costly part of the emulator are the AVR emulation and shoveling pixels onto the display (yes, literally that, not rendering, or any graphics task, just copying the prepared buffer onto the display). So if you can rule out the latter, the only way to make it run noticeably better is getting AVR emulation compiling to more optimal code. I don't think there is any way to optimize that any further at C level.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: CUzeBox - The new official Uzebox emulator

Post by L4rry »

Hey. Hope this is the right thread for this. I'm busy debugging what I believe to be a memory collision bug, where either my stack is colliding with my globals or I'm inadvertently accessing some other sensitive memory location reserved for the kernal. The symptoms I'm seeing are suddenly dissapearing sprites and garbage written on the screen in random places. While doing this I'm realizing that I have no idea how the memory is organized between stack, globals, ram tiles and other reserved memory like UART rx and tx buffers and whatever else is reserved for the kernal.

Below is a screen grab of the memory access debug strip from the emulator. I'm running Tank Fu (mode 3) and this is mid gameplay with 10 RAM tiles, 10 sprites, 64 byte UART Rx and 64 byte UART Tx buffers (This isn't representative of the memory collision bug. I just use it for illustration. The bug I'm investigating occurs when using 10 Sprites 20 RAM tiles and reading content from the UART Rx buffer into a global memory location mid game play)
Screen Shot 2018-10-09 at 9.48.42 AM.png
Screen Shot 2018-10-09 at 9.48.42 AM.png (63.77 KiB) Viewed 12601 times
I have a few questions around this. So I'm fairly certain the solid green and yellow blocks represent access to RAM tiles and the left block are IO addresses. But what represents my stack access? Is that the sparse bit to the right of the RAM tiles or are those my globals? Also, what is the yellow half block to the right? It seems fairly stable and is always yellow. So constant read and write but doesn't really grow much. Also, there is plenty of blue space never in use, especially the second and third blocks from the right. How can I access these or do they perhaps represent allocated global memory that isn't accessed at all?

I guess in summary I'm looking to understand the memory debug strip in the emulator as well as general memory layout of the AVR controller and how I can interpret it to better utilize my RAM.

EDIT: Turns out my bug wasn't a memory collision, but simply a coding error on my part. Nevertheless, I'm still curious to hear what you guys do to debug memory usage and stack collisions as I'm sure it will come in handy for me (and perhaps others) at some stage :)
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by nicksen782 »

"me too"

I know that the larger bar on the right is a ram indicator. For example if you are moving a sprite and you overlap the grid you'll find that the bar fills up more with yellow. I'm not sure what the colors mean either though.

The bar on the left I've always just assumed was flash usage which has not mattered much to me since I already know the value after compile. It could be I/O. I do not know.

The Uzem emulator also had something like this.

I've long appreciated the debugging insight the graph provides. If anybody is asking for a feature addition I would like to see a 16-bit representation (at least in decimal) of the two 8-bit whisper ports.

Does a full write-up of the diagnostic section exist? Sounds like a great idea if not.
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 »

+1 on how to decipher the mystic blue bar :)
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - The new official Uzebox emulator

Post by Jubatian »

So what's going on in the RAM then...

On CUzeBox's screen, the leftmost block is the SFR area (addresses 0x0000 - 0x00FF), mostly it can be useful for debugging low-level stuff, whether the appropriate hardware register is read or written. Normally for developing games this block carries no much information.

Then the 4K of RAM comes, 16 blocks for addresses 0x0100 - 0x10FF. To understand what is going on in there beyond recognizing probably the Video RAM and the RAM tile area, some knowledge of how normally the memory allocation of the linker is laid out is required.

The stack is at the top of the RAM on the far right. So normally you will see that being almost always yellow, how far to the left it creeps indicates your stack usage. Then the linker allocates variables from bottom to up.

Typically the Video RAM and the RAM tiles (in Mode 3) are before the most of the kernel variables including audio, so normally you will see lots of noise above what you can identify as your RAM tiles. Then the game's own variables follow, which may or may not produce patterns you could identify (if you have some larger arrays, you may recognize the usage of those). A collision with the stack would normally happen in the rightmost block, if you see the rightmost yellow region reaching the noisy area produced by reading & writing game variables.

That's it. Really it all depends on the game, however if you don't do anything unconventional, creating an ordinary Mode 3 game, this should apply.
uze6666 wrote: Wed Oct 10, 2018 6:53 pm+1 on how to decipher the mystic blue bar :)
That's for indicating sync correctness, both rising and falling edge positions. If it is blue then it is all good. Older games will show some red, there are a few which could even fail to sync proper on my TV. It is useful for video mode design, or creating a new kernel or bootloader.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: CUzeBox - The new official Uzebox emulator

Post by CunningFellow »

Run T2K to see a very striking example of what you can see in the ram debug window

During the title screen, high score table and credit there is almost nothing happening.

The AVR/IO section always has a splattering of red, yellow and green.
The stack grows and shrinks in time with the music.
The general variables part is being read and written to all over the place and has a lot of colours.

HOWEVER the RamTile and VRAM section is static green. It flashes briefly red and then yellow at each transition but then stays green as the foreground on the screen does not change. The Object Store is totally empty.

When you start playing the game or the attract mode starts - you can see the Object Store section of the RAM fill up as more aliens appear on the screen.

You can also see that VRAM and RamTiles are being written all the time when the action is happening.

The other thing that you can see is that the RAMTiles in T2K are not arranged normally. They take up a full 2048 bytes of RAM which is 8x 256 byte blocks. Each block is one row of RamTile data for all 128 RAMTiles. So as RamTile usage grows - each of the 8 blocks grows a little bit
Attachments
DEBUG_RAM.png
DEBUG_RAM.png (4.51 KiB) Viewed 12548 times
Post Reply