Hi Michael,
as you know I've seen some earlier releases of the code and want to start a little discussion about
some aspects of the architectural concept of the project.
I could imagine, to write some kind of a Monitor (like Monitor64 from one the first Input 64 tapes but running outside the emulated machine) for the emulator, that allows to inspect processor registers, memory contents and so on and that also allows to switch the emulator into single step mode. The question is, how this can be integrated in the rest of the code. What do think about a set of interfaces defining something that could be called an "abstract monitor", so that - probably at runtime - an implementation of such a thing could be plugged in?
Perhaps later on some other interfaces for plugging in implementations of a sound device, a joystick or other peripherals could be defined.
Greetings,
Stefan
P.S. I'm not sure, if this posting is public viewable. It's my first posting to SF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stefan,
most of what you want should be there. The monitor part should be implementable by the d.m.simulator.Debugger Interface. This is currently a very simple interface to plug some component onto the CPU that receives notification for each execution step. I tried to stay as general as possible to allow for later support of different cpu types (Z80 ;^) -- maybe a better solution is possible. Have a look into the d.m.s.m.Debugger6502 implementation -- it never worked and currently serves as place to keep some code -- but this is the class that needs to be really activated.
The other part -- inspecting/modifying chip's registers is also possible today. Each and every chip implements the d.m.Chip interface. That defines the simple accessor methods needed to read and write a chip' registers. So to get the current background color take the VIC instance and read the dedicated register (sorry I do not have the real register number at hand here -- but note that this is *not* 53280 but 53280 minus VIC base address.
What definitely needs to be done is to make the chip object instances of a running emulation available. Currently all of these are private members of the d.m.s.mos.c64.Commodore64 class, which lumps together more or less the complete UI, which is not good (simply said).
I could imagine, that this GUI restructuring had to be the first step towards the translucent 64 that you imagine, simply because some kind of menu or toolbar is needed to link in the entry point into that debug/trace system.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Michael,
as you know I've seen some earlier releases of the code and want to start a little discussion about
some aspects of the architectural concept of the project.
I could imagine, to write some kind of a Monitor (like Monitor64 from one the first Input 64 tapes but running outside the emulated machine) for the emulator, that allows to inspect processor registers, memory contents and so on and that also allows to switch the emulator into single step mode. The question is, how this can be integrated in the rest of the code. What do think about a set of interfaces defining something that could be called an "abstract monitor", so that - probably at runtime - an implementation of such a thing could be plugged in?
Perhaps later on some other interfaces for plugging in implementations of a sound device, a joystick or other peripherals could be defined.
Greetings,
Stefan
P.S. I'm not sure, if this posting is public viewable. It's my first posting to SF.
Hi Stefan,
most of what you want should be there. The monitor part should be implementable by the d.m.simulator.Debugger Interface. This is currently a very simple interface to plug some component onto the CPU that receives notification for each execution step. I tried to stay as general as possible to allow for later support of different cpu types (Z80 ;^) -- maybe a better solution is possible. Have a look into the d.m.s.m.Debugger6502 implementation -- it never worked and currently serves as place to keep some code -- but this is the class that needs to be really activated.
The other part -- inspecting/modifying chip's registers is also possible today. Each and every chip implements the d.m.Chip interface. That defines the simple accessor methods needed to read and write a chip' registers. So to get the current background color take the VIC instance and read the dedicated register (sorry I do not have the real register number at hand here -- but note that this is *not* 53280 but 53280 minus VIC base address.
What definitely needs to be done is to make the chip object instances of a running emulation available. Currently all of these are private members of the d.m.s.mos.c64.Commodore64 class, which lumps together more or less the complete UI, which is not good (simply said).
I could imagine, that this GUI restructuring had to be the first step towards the translucent 64 that you imagine, simply because some kind of menu or toolbar is needed to link in the entry point into that debug/trace system.