Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
tbsp authored Dec 23, 2022
1 parent 456155b commit 9758fc8
Showing 1 changed file with 14 additions and 3 deletions.
17 changes: 14 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,21 @@ Varaboy is a Game Boy emulator written in uxntal for the Varvara system.
## Features

- ROM/MBC1/MBC3/MBC5 games (only basic ROM/RAM banking support, extended bank bits not handled, no RTC for MBC3)
- Variable frameskip (default: 3), adjustable with number keys 0-9
- .theme file support
- No sound support

## Controls

| Key | Function |
| --- | --- |
| Home | Start |
| Shift | Select |
| Ctrl | A |
| Alt | B |
| Arrows | Dpad |
| 0-9 | Set frame skip (default: 0) |
| Escape | Write SRAM to disk and quit |

## Stability

Note that due to the incomplete MBC implementations and SRAM not being repacked unless you quit with the escape key I **strongly discourage** playing any game seriously with this emulator at this time. Games will almost certainly break, and save files will almost certainly be lost/corrupted.
Expand Down Expand Up @@ -84,9 +95,9 @@ Note that this means we don't have access to the UXN zero page, which contains t

## Performance

This emulator performs fairly well on a modern computer. On a Ryzen 5600X running in [uxnemu](https://sr.ht/~rabbits/uxn/) most games are playable with no frameskip. Emulation speed in [uxn32](https://github.com/randrew/uxn32) is quite a bit slower, making it very hard to get inputs to register at all (perhaps due to differences in how vectors are handled). A i5-540M with a frameskip of 3 could be considered playable for some games, but action games are pushing it. Performance on the Nintendo DS UXN VM is even worse, which isn't surprising.
This emulator performs fairly well on a recent/fast CPU. On a Ryzen 5600X running in [uxnemu](https://sr.ht/~rabbits/uxn/) most games are playable with no frameskip. Emulation speed in [uxn32](https://github.com/randrew/uxn32) is quite a bit slower, making it very hard to get inputs to register at all (perhaps due to differences in how vectors are handled). A i5-540M with a frameskip of 3 could be considered playable for some games, but action games are pushing it. Performance on the Nintendo DS UXN VM is even slower, which isn't surprising.

I've sped up instruction dispatch by using jump tables, which in certain cases "wastes" as much as 126 bytes for the ~64 "ld r8,r8" instructions, but overall I believe the performance gain is worth it. I've also tried to pre-calculate as much as possible in the PPU scanline renderer to reduce redundant calculations as I'm not considering mid-scanline register writes. Background/window tiles are cached for reuse for up to 8 pixels, which provides a slight performance gain, though the presence of that code also slows things down a bit, so the net gain isn't huge. In addition, several common operations (ticks, reads, etc) have been converted to macros for speed over size, though the gains are minor. The initial release had a very inefficient OAM scan approach, which has since been resolved.
I've sped up instruction dispatch by using jump tables, which in certain cases "wastes" as much as 126 bytes for the ~64 "ld r8,r8" instructions, but overall I believe the performance gain is worth it. I've also tried to pre-calculate as much as possible in the PPU scanline renderer to reduce redundant calculations as I'm not considering mid-scanline register writes. Background/window tiles are cached for reuse for up to 8 pixels, which provides a slight performance gain, though the presence of that code also slows things down a bit, so the net gain isn't huge. In addition, several common operations (ticks, reads, etc) have been converted to macros for speed over size, though the gains are minor. The initial release had a very inefficient OAM scan approach, which has since been resolved. I've also reworked the PPU mode advancement to only check a single PPU transition dot per mode, and to only check once per instruction, which speeds things up quite a bit and doesn't affect accuracy with a simple scanline renderer.

Save files are unpacked into a file per bank on startup for faster access during SRAM banking. The individual bank files are repacked on shutdown if you quit by pressing the Escape key. Quitting by closing the VM any other way will not properly write SRAM contents back to the SAV file. Without file seeking, games which use lots of ROM banks (and bank often) could also suffer a notable performance hit which could be reduced by unpacking ROM banks in a similar manner.

Expand Down

0 comments on commit 9758fc8

Please sign in to comment.