This is indicated by the "write header" bit in r39's rom.
commanderx16/x16-rom#216

At some point, I pulled out SDL_GetBasePath() as the directory root for finding files. I don't recall the reasons why, so I probably just thought it was unnecessary. However! Turns out this is important after all, if someone is in another directory and tries to invoke box16, box16 is now expecting the ROM, ini file, and other tidbits to be located in the directory that the command line is on, not the directory of the executable.

Since box16 is trying to maintain 100% compatibility with the official x16 emulator, it's important that this be addressed to restore the original locating behavior.

SDL_GL_SetSwapInterval is a V-sync option, when it fails Box16 should not shut down.

I've observed a problem in the path handling when attempting to load a program with -prg.
It seems as if it prepends ./ to the path, if it's not relative:

/home/irmen/Downloads/spinner.prg
irmen@neptune  ➤  ./box16/box16 -prg ~/Downloads/spinner.prg 
Cannot open .//home/irmen/Downloads/spinner.prg!
irmen@neptune  ➤  ./box16/box16 -prg /home/irmen/Downloads/spinner.prg 
Cannot open .//home/irmen/Downloads/spinner.prg!

It works fine if you supply a relative path.
This is on Manjaro/Arch Linux.

SDL_Image brings in a lot of DLL dependencies, and an additional package dependency on Linux. It's only being used to load a PNG file at the moment; there must be a lighter-weight alternative. Maybe even just libpng itself.

http://www.libpng.org/pub/png/libpng.html

It would be nice if the Makefile had a target debug that performed a build with the following changes:

• No optimizations
• Generates debugger symbol files
• Enables -Wall and -Werror

Cleaning up the code to actually build under this new target is not required. This is a target for making sure the code is very clean, and eventually (once it builds) making it easier for Linux contributors to debug their work.

It runs at ~98% realtime, even by its own arithmetic. This seems to be because the timing code doesn't consider the possibility that a frame plus a usleep call might result in the frame ever so slightly longer than 16,666μs, and doesn't allow subsequent frames to shave off the difference to make up for it.

We should replace it, pronto, perhaps with the BSD-3-Clause https://github.com/aaronsgiles/ymfm

Default to "enabled bindings", but there should be an option to disable the annoying keybinds like Ctrl-S and Ctrl-R which, while certainly of some use to someone, broadly interfere with other applications as well which depend on those keychords.

It only looks like it's considered for the I2C bits, not the joystick data.

In via.cpp:

case 1: // PA
case 15:
	ps2_autostep(0);
	if (!debug) {
		via_clear_pra_irqs(&via[0]);
	}
	if (via[0].registers[11] & 1) {
		// CA1 is currently not connected to anything (?)
		return 0;
	} else {
		return (~via[0].registers[3] & ps2_port[0].out) |
				     (via[0].registers[3] & ps2_port[0].in) | Joystick_data;
	}

See commanderx16/x16-emulator#414

For some reason, the Sprite preview flickers between the "correct" sprite data and seemingly garbage data.

To reproduce:

1. Start the emulator.
2. MOUSE 1 in the console.
3. Open the Sprite Settings overlay. (Windows -> VERA Debugging -> Sprite Settings)
4. Observe flickering. Some mouse movement might be required.

Command line options have been added and removed, and some have changed behavior. While I think the set of command line options and their documentation is up-to-date, it would be easier to keep track of that if the list were sorted alphabetically, as opposed to the very ad-hoc jumble they're in right now.

https://github.com/cyborgar/Petaxian

Using the preliminary v39 roms. Game works fine on official emulator.

note: game is written in prog8 so we most likely will need the generated assembly code

Setting H scale value to 0 crashes the emulator. This is easy to do inadvertently by backspacing the current value out of the input field when you intend to erase it and change it to something new.

Put the app in warp mode, and then hold the title bar (when the mouse is not moving here, the left button is down.)

Being able to mount and work with SD card images and the FAT32 filesystem is great and all, but requires additional backend work from developers to create SD card images for their projects. Certainly, I had a fun adventure getting a toolchain that worked to my own satisfaction, only to be sorely disappointed when the ROM/kernal didn't actually support the operations I wanted to experiment with anyways. But that was then, and looking forward, it would be nice to not have to build an SD card image in order to have SD card emulation.

So wish list item: Emulate the SD card as if it were created from the local filesystem.

There's gif exporting, there's wav exporting, it seems reasonable to consider welding these two ideas together somehow to export an A/V file. This is obviously more involved than the existing solutions, so this is longer-term, or something to do while we wait for updated hardware information and/or official emulator r40.

I mean, so many options are already there and can be overridden, no reason not to add the location of that file to the list... right?

Bit 7 should always be 0, according to http://archive.6502.org/datasheets/mos_6522_preliminary_nov_1977.pdf

Minimal test case:

    stz $9F20
    stz $9F21
    lda #$18
    sta $9F22
    stp                         ;press F10 here while execution is stopped in the debugger
    lda $9F23
    rts

*** buffer overflow detected ***: terminated
Aborted (core dumped)

For some reason it doesn't crash without the intervening STP instruction that invokes the emulator debugger.

Test case PRG: https://mooinglemur.com/x16/CRASHDEMO.PRG

Scaling is applied to the 640px wide buffer, so we should only see 640*scale pixels.

vs actual hardware

prg:
https://discord.com/channels/547559626024157184/549247967945687071/1025460796836290584

As in the title, tooltips on the Options overlay don't specify when command-line options can override them, or what the command-line analogues are. This should be fixed. Perhaps put the command-line options on a new line below the current tooltip descriptions?

Imgui has a feature that can be enabled to make windows dockable to the edges of the display. It would be nice to enable this feature so folks can drag windows around and dock them where they wish. As part of this, it would be nice to split some of the ASM debugging functionality into separate windows. It may also be desirable, then, to change the default organization of windows, perhaps to emulate a certain large and popular IDE by a major software company. Or some other IDE that's popular among the community.

I tested the latest development commit of box16 with the latest development commit of the ROM and found I was getting "File Not Found" errors when trying to load programs in the emulator. To clarify, I'm not using any sort of -sdcard argument, so this is an issue with loading from the current directory. I bisected the issue to commanderx16/x16-rom@dd66237 (or its parent commit, but I don't think it's that one). I'm guessing that the shifting of functions from moving things to the new bank messed up the function hooking. This isn't an issue with using the latest release ROM, but it's something to keep in mind for the next release.

It would be nice if folks could launch Box16 in such a way that they could "attach" to it with an external IDE like Atom or VS Code, or even Visual Studio (or maybe GDB?) and be able to set breakpoints, step through their code, inspect machine state, etc., etc., just as one might when debugging some native executable with debugging information.

This is currently very open-ended in its definition and scope. Personally, I don't have a lot of insight into the technical side of this (yet).

One of the things I'd like to take advantage of, with there being OpenGL acceleration now, is fragment shaders to apply a display device filter, specifically a CRT filter that can be enabled when outputting in NTSC mode. It would be nice if this were more than just "add scanlines": Color mixing and phosphor glow effects would be good, generally trying to mimic the full texture and feel of a CRT.

See also:
https://www.vice.com/en/article/qj83yp/final-fantasy-remasters-reignite-controversies-over-pixel-art
https://twitter.com/CRTpixels

This would be a nice-to-have feature for rendering PSG and eventually YM2151 channel data. For the effect I'm thinking about, consider the following Youtube videos:
https://www.youtube.com/watch?v=iLWF1vEbOuc
https://www.youtube.com/watch?v=OfcYpfxipvU

It may be worth experimenting with how to present this data as well, such as finding a way to align it cleanly the way the above videos do. Perhaps centered on the midpoint between the maximum signal value and the minimum signal value?

When writing to IFR, it should clear any bits that are set in the write. (bar bit 7, which should be preserved)

This disables VIA interrupts, and then should clear the bits.

10 poke $9f0e, $7f
20 a=peek($9f0d)
30 print a
40 poke $9f0d, a
50 print peek($9f0d)

expected:

Emulator:

x16emu now hooks ACPTR and MACPTR, among others, instead of SAVE and LOAD.

The point of the new hypercalls on x16emu is to better emulate filesystem access times on the emulator. It might be worth keeping SAVE and LOAD, depending on a hypercall emulation setting, but the point in any event is to maintain compatibility with x16emu.

Just needs to be a literal list of bytes starting from $100 + SP and displaying through $1FF.

At some future point, adding a proper "callstack" that could show labeled addresses and record which pushes came from jsr or interrupts vs. other pushes would be grand, as well.

When I encountered this error #60 Box16 wrote a 0 byte dump.bin file.

Turns out that the symbol files created by cc65 are just using VICE Monitor commands. So why not add support for more of the commands when loading these files?

See also: https://vice-emu.sourceforge.io/vice_12.html

It may be useful for folks writing debuggable software if the brk instruction can pause execution and open debugging windows, similar to the behavior of stp. This should be guarded by an option setting, though, and default to false, to maintain backwards compatibility with x16emu. Toggling the setting should be exposed through UI and a command-line option.

It would be useful to be able to pass MIDI inputs to the sound chips, to help with authoring music for the X16. RtMidi appears to be cross-platform and light on dependencies, so it may be a good fit for use here.

https://github.com/thestk/rtmidi

-nosound is causing Box16 to always show the usage help and then exit, because it thinks there's a -sound option specified from somewhere. Initially I think this is coming from a saved option to the ini file.

Manjaro linux, gcc 12.1.0:

(note: similar errors occur when compiling the official emulator)

    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 64 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 80 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 96 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 112 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 128 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 144 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 160 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 176 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 192 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~
In function ‘void expand_4bpp_data(uint8_t*, const uint8_t*, int)’,
    inlined from ‘void render_sprite_line(uint16_t)’ at ../src/vera/vera_video.cpp:410:20,
    inlined from ‘void render_line(uint16_t)’ at ../src/vera/vera_video.cpp:747:21:
../src/vera/vera_video.cpp:371:22: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
  371 |                 *dst = (*src) & 0xf;
      |                 ~~~~~^~~~~~~~~~~~~~
../src/vera/vera_video.cpp: In function ‘void render_line(uint16_t)’:
../src/vera/vera_video.cpp:407:32: note: at offset 208 into destination object ‘unpacked_sprite_line’ of size 64
  407 |                 uint8_t        unpacked_sprite_line[64];
      |                                ^~~~~~~~~~~~~~~~~~~~

From @ZeroByteOrg:

Talking to MooingLemur last night, I had an idea that might make for a good enhancement (if my understanding of official R39 behavior now works)...
It's my understanding that HostFS now takes on the same speed (more or less) as SDimage due to the fact that the hook is now on ACPTR / MACPTR and not LOAD / SAVE

If that's the case, then it might be nice to add a commandline option to bootstrap-load additional files than just -prg

pglewis is doing that dancing baby demo, and was saying how each time he runs the program to test a change, it takes a while to load all the graphics and sound. So I thought a bootstrap load for arbitrary files to arbitrary locations in memory at startup might be a nice feature to speed up this sort of thing....
like -load file,addr -load file,addr -vload file,addr

Note that Box16 is still hooking LOAD and SAVE, it should probably hook ACPTR and MACPTR the way x16emu does now.

The emulator freezes without showing a window or printing an error message when loading my symbol files.
Here's an example that triggers the issue:

al 8a6 .prog8_slabs
al 817 ._prog8_entrypoint
al 834 .cx16
al 862 .cx16:init_system_phase2
al 834 .cx16:init_system
al 871 .cx16:restore_irq
al 88a .cx16:restore_irq:_orig_irqvec
al 834 .c64
al 88c .prog8_lib
al 890 .prog8_lib:retval_interm_w
al 88d .prog8_lib:retval_interm_b
al 88c .prog8_lib:retval_interm_ub
al 892 .prog8_lib:orig_stackpointer
al 893 .prog8_lib:prog8_init_vars
al 88e .prog8_lib:retval_interm_uw
al 8a6 .prog8_program_end
al 825 .main
al 825 .main:_label
al 825 .main:start
al 832 .main:start:_prog8_breakpoint_1
al 833 .main:start:_label_local
; vice monitor breakpoint list now follows
; 1 breakpoints have been defined
del
break $832

This is an example of a combined symbol and breakpoints "mon list" file that Prog8 generates.
I think the freeze issue is triggered by the extra commands at the end.

The "mon list" file is basically a list of commands that the Vice monitor executes before launch. Command line option ref
As such it can contain any command the vice monitor accepts also when typed in interactively, there are quite a few!
But I only use it for 2 things: to define labels and to define breakpoints. So prog8 outputs symbol/monlist files containing:

• al short for add-label
• del short for delete that (without arguments) deletes all currently defined breakpoints just to make sure only the defined breakpoints in the program remain active
• break short for breakpoint
• ; line comment

Copied from Discord:

JimmyDansbo — Today at 3:05 PM
When starting box16 with the -rom option it assumes that the path provided is from the box16 executables directory instead of the current directory

Sepia — Today at 3:54 PM
Well, it had been the other way at one point, assuming the path provided was relative to where the command line was located, but the original emulator assumes the path is the box16 executables directory, so that was a compatibility-breaking change and I put it back.
So you can bug it on Github, but unfortunately it's not going to be fixed unless I decide to intentionally break compatibility with the official emulator.

ZeroByte — Today at 4:07 PM
what happens if you specify an absolute path on the cmdline?
e.g. -rom ./myrom.bin
or -rom /home/user/somedir/myrom.bin
ok - decided to just test it... @JimmyDansbo - absolute paths beginning with / will use any location.
at least it does in Linux

JimmyDansbo — Today at 4:12 PM
Sure, absolute paths will always work, but normal behavior for a program is to use current working directory as a reference instead of using the directory where the binary is located.
In my home directory, I have x16-rom directory and box16 directory. If start box16 from my home directory with the following command: box16/build/box16/box16 -rom x16-rom/build/x16/rom.bin it will not work

ZeroByte — Today at 4:14 PM
hmm - gonna try the official emu in a similar vein

JimmyDansbo — Today at 4:14 PM
official emu works as every other linux program 😉

ZeroByte — Today at 4:18 PM
hahaha - I just found a bug in the official emu
x16emu -rom .
it boots the emu with null ROM instead of giving "cannot open rom.bin" error msg.
it tries to open the directory itself as if it were the ROM file
okay, so the official emu's behavior is as follows:
if -rom is specified, search relative to the PWD at execution time
else look in exe directory

JimmyDansbo — Today at 4:20 PM
hehe
Yeah, that would be the normal way of doing it for any binary on linux

DesertFish — Today at 4:27 PM
if -rom is specified, search relative to the PWD at execution time
else look in exe directory
I think it now always looks in exe dir regardless of parameter
(I requested the change to look in exe dir for the rom.bin as default)

ZeroByte — Today at 4:46 PM
I've tried a bazillion permutations on the official emu. If -rom is not specified, then it looks in the exe directory, and only there. If -rom is specified on the cmd line, then that is opened relative to the PWD.

JimmyDansbo — Today at 4:47 PM
Yes, but box16 does not try to open rom relative to current working directory

ZeroByte — Today at 4:49 PM
Sepia stated that he didn't want to break compatibility so I thought I'd give it a thorough putting through its paces just to make sure.

DesertFish — Today at 4:50 PM
My use case is the situation where -rom is not specified

ZeroByte — Today at 4:53 PM
And for a final check - I ran box16 from somewhere different than either the specified ROM or the specified PRG arguments, using only relative paths to reach each one. box16 clearly builds rom path relative to the exe in all cases, and prg path relative to PWD
Sepia - just so you don't miss this in the TL;DR thread above- the official emu uses PWD-relative path for the -rom argument if provided, else EXE directory if not specified.

Sepia — Today at 5:01 PM
I see. Okies, that's totally a valid bug then. I'll see if I can fix it properly this time. 😛

Example prg.

No dump file as it wrote a zero byte file.

Example.zip

This is probably an enhancement, rather than a bug.

The palette shows the colour in 32bit RGBA, rather than 12bit X16 colours. Showing colour number would be handy as well.

See also: (Discord)

I'm walking through the debugger. It's something related to OpenGL. glGetSynciv is always coming back GL_UNSIGNALED and glClientWaitSync is always coming back GL_TIMEOUT_EXPIRED. Both of those conditions skip the rendering step. Looks like maybe a driver thing.
Yup, when I remove both USE_GL_GET_SYNC and USE_GL_CLIENT_WAIT_SYNC it works.

The fix I would like to see:

• Add a bool to the options struct in options.h to toggle vsync. Default to false.
• Add an appropriate command-line flag to enable the bool in options.cpp and store its setting in the ini file.
• Use the new bool to choose whether to attempt to execute the vsync code in display_process().

Like it says on the tin, it would be nice if Box16 could remember which ImGui windows were left open, and then re-open them automatically when launched. ImGui itself already remembers where windows were positioned.

Ubuntu (20.04) and Linux Mint have linker troubles for some reason. I'm not sure why, and I don't know what to do to troubleshoot this further at this point.

It would be nice to have an option to capture writes to audio and export them to a VGM file. Export should be able to be enabled, but timing should only start with the first subsequent write to audio devices (e.g. trim any "dead air" that occurs before music is being played).

Bonus points if MIDI is implemented and this can export writes resulting from MIDI input in addition to vanilla writes to the audio devices. Something to consider when implementing, or perhaps means issue #2 should be implemented before this.

This seems like a fairly bog-standard feature and idea, since there are other things where keybinds may be useful, add a generic interface for mapping key bindings to specific features, actions, and toggles.

This could, and maybe even should, include the debugging keys on the ASM Monitor window.

The YM2151 routines do not clock the timers, and the IRQ line is not connected to the system yet. Per Kevin (TexElec), the IRQ line is indeed connected, so it would be beneficial to activate these timers in the emulation. Furthermore, the chip also has a purely internal feature CSM which causes a keyDn event on all 8 channels whenever TimerA overflows, which does not function properly unless the timers are clocked.

When attempting to step during a WAI, the debugger only steps one cycle, instead of stepping until the WAI instruction ends.
Discovered while fixing commanderx16/x16-emulator#392 and porting over as ec0ce83.