Redesigning "Mcu Monitor".

There are a few things in the current Mcu Monitor that are not convenient.
For example:
- You can't watch RAM, ROM and PGM at the same time.
- You can't watch internal Registers of the CPU (I can in 6502, but that is a hack).
- What happens with devices with no RAM ROM or PGM?

And there are other features that could be interesting:
- Add breakpoints at some PC value, RAM or ROM changes (in simulation mode, not in debugger mode).

So I'm thinking how to redesign it to solve these issues.
If you have some ideas please share here.


Related:
https://simulide.forumotion.com/t291-mcu-monitor-0-5-16

My Z80CPU Monitor looks like in the pictrure. It looks ugly and needs a little bit tunning.
There are displayed flags, registers and internal states of the CPU. The buttons at the bottom are used for execution only one T state, one machine cycle or one instruction.
I would be nice to have possibility to set breakpoints to state of registers and state of bus with possibility to set counter how many times it is skipped.

I already did some changes:

- Monitor only shows only what the device has.
- Added cpu registers.

Here is how it looks for 6502:



Other information could be added as variables (left lower part in the image above), like T State, Address Bus, Data Bus, etc (All info you show in the lower part).

The buttons at the bottom are used for execution only one T state, one machine cycle or one instruction.

I saw that in the source code and it is very interesting.
It could be used after breakpoint to step the cpu.
Also after Logic Analyzer "Pause on Condition" or just pausing simulation with pause button.

Being able to debug the cpu without the debugger is a very useful feature.
It could also be used with the debugger:
Run the debugger to certain point and then execute by small steps.

I'm thinking to add something like that in the white area at the right in the image above.

And... I think I know why your Monitor crashes (more on this and other Z80 stuff in the other discussion).

• separate windows for RAM, ROM and PGM would be great
  
• It would be great to be able to read in map / lss files  
  e.g. for reading out variables similar to registers
  

BTW: what is the "CPU" tab in the Mcu Monitor for?

It would be great to be able to read in map / lss files  Redesigning "Mcu Monitor". 1f600
e.g. for reading out variables similar to registers

Something like that is already implemented for avr-gcc.
Detected (global) variables are automatically added to a list below registers (if you compile in simulide):
https://simulide.forumotion.com/t605-debugger-and-variables

BTW: what is the "CPU" tab in the Mcu Monitor for?

To show any information about the CPU itself: internal registers, internal states or any other information.

That's great. It would be good to have this also for the case hex made by external IDEs (e.g. MPLAB X for PIC / AVR).

That's great. It would be good to have this also for the case hex made by external IDEs (e.g. MPLAB X for PIC / AVR).

The question is how to get the information.
When you compile in simulide the toolchain is known, which files are generated from which sources are known, etc.
From an hex file you know nothing.

lss or map files can have some information about variables or not.
And the formats are different for each compiler, so there is no generic way to find that info if it even exist.

The debugger gets information to map PGM addresses to source lines from list files, but this is much easier, and in any case some information must be provided in the compiler definition file in order to know what kind of list file it is.

Variables are not that easy, but if somebody knows a method to do it let me know.

From: https://simulide.forumotion.com/t390p150-simulide-1-0-0-tester-builds#4830

KerimF wrote:[1]
Saving the look of the MCU Monitor with its circuit.
For example, the RAM/SRAM table could be seen, therefore, as it was set (displayed) in the previous session.

[2]
Changing, on the MCU Monitor and in a convenient way, the displayed values DEC to HEX or HEX to DEC (instead of adding another column). This option eases, when necessary, the comparison between a hex value of a byte on the RAM table (mid panel) with one on the SRAM table (right panel).

I think monitoring the SRAM bytes (defined as single bytes only, not of an array) also by their defined names is not easy to implement, at least for the time being.