• No static memory will be used. I thought long and hard on this, and decided that the benefits of being able to emulate multiple systems (for instance, when a link cable is used) far outweigh the performance benefits that would result from using global variables. It would be a non-trivial task to convert the CPU engine from using static memory to using the heap for use as an object, and the teensy boost in performance with static memory just isn't worth that. Even in the case of local variables in functions, reading memory from a stack-relative address isn't terribly slower than just referencing a global variable directly. I mean, come on: Virtual Boy runs at all of 20 MHz. Super-optimal performance is non-critical, but flexibility of use with the code has some significant worth.

• The emulation core itself will be the central module, called Core. To get the CPU up and running, at least the CPU, ROM and RAM modules need to be implemented and plugged into the Core. The Core will support Read and Write operations for the CPU, which translates addresses to their corresponding modules (ROM, RAM, input, video, etc.). Preferably, memory ranges can be redirected to their corresponding modules directly, without sending the requested address through a series of if statements to figure out where it should go.

• Virtual Boy ROM images, to my knowledge, do not specify the capacity of the in-cart RAM chip. The maximum usable size of the chip on the system bus is 16 MB, and I'd rather not allocate that up-front for the purpose of just in case. Instead, I can start with a smaller value like 1 MB or even 512 KB and, in the event a RAM access is requested in a higher range, the block can simply be reallocated. This can only happen a handful of times at most during a single session, so it won't be a performance hit.

• As outlined in my previous post, a list of 256 function pointers will be used to immediately direct CPU execution/disassembly to the corresponding handler using the second byte of the next instruction. Additionally, a second table will be used to fetch and decode instructions before the CPU executes them, rather than have the fetch/decode/execute all done by the instruction handler. It's a six-to-half-dozen scenario, but performing the fetch/decode in centralized code will at the least decrease the compiled size of the executable. This is possible because the formats of all instructions are known based on the value of the same byte that's used to determine which instruction to execute.

• Since the exact cycles for some instructions aren't known in all cases, uh... I'm just going to use a fixed value, probably the average of the minimum and maximum execution time for most instructions. Timing on Virtual Boy is driven by interrupts anyway, and the CPU is actually halted to wait for VBlank. It won't be totally accurate as an emulator, but it will still be pretty close.

• For bit string instructions, the program counter might not be incremented. Yeah, you read that correctly. Since those instructions can potentially take a long time to complete--by design--and also need to be abortable by interrupts, I figure the best way to handle them is to process one word at a time, taking 3 cycles for each one, and only incrementing PC when the entire process completes (then adding something like 30-40 cycles at the end). You know, the way they behave on the real system. As far as the Core is concerned, it's just executing as normal, and due to the specifications of the bit string instructions using r26-r30 as working variables for just that exact reason, it makes a lot of good sense and doesn't require any special support for the bit string instructions.

• As repeatedly mentioned earlier in the thread, memory breakpoints is a big issue. The types of breakpoints I want to support are Read, Write and Execute, meaning the Core will need to be able to intercept addresses and check them against a list of active breakpoints... in the most efficient way possible. There are too many addresses to just keep a big list of flags for each one, and processing of addresses that don't have breakpoints on them should happen in as little time as possible. Buuut, since Core will actually be implementing Read, Write and Execute functions for the purpose of normal processing, it's just a matter of hijacking what's already there.

• I want breakpoints to support complex conditions (at the very least being able to check the contents of registers and memory), and in some form or another an action to take--be it the Single Step routine (see below) baked into the debugger or a custom action given by the user. Maybe not Lua exactly, but something.

• Single Step (aka Step In), Step Over and Step Out functions are also on the list. Single Step is a cakewalk: just execute one instruction at a time during a break (perhaps most easily implemented with execute breakpoints on every following instruction). But Step Over and Step Out, uh... Yeah, this might sound weird, but the V810 family doesn't have a stack. As such, there is no instruction for returning from functions that I can trap to detect stepping out. What I'll probably have to do is keep track of the n most recent return addresses set by the JAL instruction. For Step Out, just put an execute breakpoint on the most recent. For Step Over, put a breakpoint on the instruction after the JAL in question. Exactly how many levels to support is tricky, though, because there's nothing about the system that says all functions have to return.

• The debugger should sport a disassembler so the user knows what the crap the program is trying to do. The debugger should also allow on-the-fly modifications of all registers during a break for the purpose of debugging specific scenarios without actually requiring them to occur normally. Status flags should take the form of check boxes, since trying to pack a 32-bit integer value when all you want to do is set the Z flag isn't my idea of productive.

• Like I brought up in the first post, I'd like some way to keep track of function calls as they occur in the program. The calls are easy: that's what JAL is for. But detecting returns is a bit more involved during execution, and virtually impossible just looking at the instructions in a disassembly. I imagine most returns take the form of JMP r31, but I suppose any JMP would qualify, since conditional branches are used within functions. I'll have to think on it. Either way, all starting addresses for functions when JAL is used will be added to a list for further review.