The blargg tests copy their tests into RAM from $4000 to $C000. KoholintIsland only supports showing disassembly results for the cartridge, meaning it's not possible to visualize and step through the instructions for these tests in a meaningful way..

This could be used to back-propagate function argument types through to immediates.

Some examples of errors:

• out of bound cartridge locations
• duplicate scripts, macros, globals, data types, labels
• infinite loops in scripts (may need to introduce a timeout for scripts)

This command should continue execution until a layer is popped off of the callstack. If there are no layers to pop off then this command should be disabled.

This will enable larger structural organization of the disassembly.

One way to do this would be to allow a filename to be associated with a function. Doing so would cause the function's entire scope to be moved to that file. This file would in turn be imported from the appropriate bank.

The emulator pane should enable the following features:

• Initiate an emulation run at a specific address with an initial CPU state.
• Emulating one instruction at a time and visualizing CPU state results.

Some open questions:

• What happens when the CPU state is ambiguous and conditional logic is encountered?

This primarily affects macros, which almost always end up representing more than three bytes of information.

It's currently only possible to search within a single source file.

It should jump to the location within the same project.

E.g. main.else_01_0245: shouldn't interrupt the scope line for main.

When an instruction can be inferred as having multiple types, this should be surfaced in the UI as a "fixit"-style suggestion to select one of the types as the preferred type.

The script should be provided with the macro's argument values. This will enable the script to react to macro values and take action (e.g. registering a new executable region).

This appears to have broke after migrating to a xib-based menu.

This will help verify that the checksums of assembling the disassembly matches the checksum of the ROM and that no errors were introduced as a result of a bug in Windfish or the project configuration.

Doing so will require integrating the rgbds tool into the Windfish UI in some manner.

This should improve the likelihood of blargg/instr_timing/instr_timing passing, as it relies on the serial interrupt being fired.

Some options:

• Right-clicking and showing a context menu.
• Double-clicking immediately begins editing inline with a text editor.

This will clarify simpler methods.

• Able to add breakpoints
• Able to delete breakpoints
• Emulator pauses when a breakpoint is encountered (when breakpoints are on macros, only the first instruction of the macro should pause the emulator)

The only way to restart emulation right now is to close Windfish and reopen the project.

There are two primary phases to disassembly:

1. The disassembly itself.
2. The generation of attributed text for each ROM bank.

Phase #2 can only begin once phase #1 has concluded. Phase #2 is likely the easiest part to parallelize because each ROM bank's attributed text can be generated in parallel without any overlap.

Phase #1 will be harder to parallelize. This will require exploring how to allow runs to happen in parallel to one another, merging the results in the same order that runs were initiated in order to preserve consistency across multiple disassembly invocations.

Tasks

• Create an instrumentation baseline of end-to-end disassembly so that improvements can be measured.

Note how the macro lines do not show up as code lines.

This will enable the disassembler to treat any call/jp addresses within the region as mapped to the destination region. This will be particularly handy for working with the test ROMs as they frequently copy code into RAM before running it.

The reverse mapping can be useful as well: if the emulator detects it is running in a mapped region it can highlight the code at the source region instead.

We may want to initiate disassembly after a period of 5 seconds or so to avoid unnecessary runs while edits are happening. If a new run is initiated while another run is active, the active run should be terminated.

E.g. typing in 100 should be interpreted as 0x64 while 0x100 should be interpreted as 0x100.

Right now it always assumes the selected bank is $01, which isn't necessarily accurate. If the selected bank isn't explicitly known, then it should be indicated as such in the UI (likely by not showing any selected bank at all).

The project and its emulator currently continue running in the background even after the project is closed. Only full termination of the IDE causes emulation to stop.

This makes it hard to find the new region, particularly if there are a large number of regions.

This bug affects all tables with an add button.

The viewport gets reset to bank 0 at the top rather than staying fixed to the current view.

A related bug is that if the bank being debugged is not open when a breakpoint is hit, then the bank's source will be opened but the correct location won't be jumped to until at least one more emulation step occurs. There is likely some race condition happening between loading the bank's source and the ability to jump to a given line in the source.

This will allow projects to automatically retrieve symbolic information for the rom.

E.g. x86 supports a variety of 3+ byte opcodes: https://en.wikipedia.org/wiki/X86_instruction_listings

This might already be working somewhat, but it needs to be verified. Some places in the CPU implementation may assume only a single nested layer of opcode tables.

Step into can continue stepping one instruction at a time, but step over should always move to the "next" apparent line of code.

This will enable comparison of the generated disassembly with the rom's binary to ensure correctness.

And vice-versa. This will be to show that the emulation is running.

Also stop storing the bank filename mapping as this should be computable from the disassembly source.

When clicking between files, the scroll position from the previous file propagates to the selected file, which is unexpected. Scroll positions should be maintained on a per-file basis and restored when a file is selected.

They are currently drawn as white squares with the accessibility label drawn over top. Ideally we are using the same symbol icons on 10.15 that we're using on 10.11+.

This will accomplish a few things:

• Easier to store project files in GitHub for archival purposes and documentation.
• Easier to make hand-edits to the project.
• Less reliant on plist, which is not a common format outside of the Apple ecosystem.

When a label is clicked, the previous viewport should be pushed onto a navigation stack so that it can be popped back.

• Shows the LCD
• Shows relevant registers
• Shows vram

To standardize on terminology.

This can easily happen when renaming a label with a scope. A quick improvement would be to strip the scope prefix from the label name when double-clicking it to edit it.

The current implementation is a rough approximation but is not cycle accurate and has some visual quirks. Note the odd flashes in the opening sequence of Link's Awakening on the beach scene where sprites disappear around 2/3 of the way into the scanline:

This will make it easier to see which line was jumped to.