New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single stepping vCPU #83
Comments
The more I think about this, the more complications I see pop up. Lets focus on single-stepping vCPU, that is hard enough. |
Single stepping is a specialised form of multi-threading: alternating between the program under test and the monitoring program. We must want the monitoring program to be written in vCPU, instead of being natively integrated with the video loop. Because that's the only way to make something educational out of it. Therefore the user visible vCPU state must be switched, including, to make it practical, the sysFn and sysArgs variables. It's wise that the monitor program doesn't touch the area just under the stack pointer. Many programs park some temporaries there. |
Still, SYS functions make single stepping convoluted. If they return well within their allotted time, NEXT will happily dispatch one or more vCPU instructions. There's no way to stop that, and SYS instructions are important enough not to be ignored for such functionality. v6502 is even harder because it continuously overwrites vCPUselect. Effectively every 6502 instruction is dispatched twice: first for fetch and addressing mode, second for execution. SBC even is dispatched 3 times (IR is modified into an ADC). I'll leave this issue unsolved and close it. |
It just occurred to me that it’s easy to run vCPU and v6502 in stepping mode: Just give the interpreter only a time slice for 1 instruction. With that, I can think of a way where we first fetch one instruction from ROM, put it in RAM, execute it, and then fetch the next from ROM, etc.
This way we can have these kind of libraries directly available without translating to native code, and without eating RAM space. At the expense of more speed loss.
We already have a SYS function that prefetches the required 3 bytes quickly: SYS_Read3_40
Although it splits the ROM page in two halves (it was done for Pictures where this makes sense).
A dedicated "trampoline" for this purpose also seems justified.
The text was updated successfully, but these errors were encountered: