Yes, the idle process is increasing continously a counter. It has the lowest priority, so it only gets CPU time, when no other process is currently working.
Now you can compare the constant 50hz system counter with the counter of the idle process and calculate the free CPU time.
I am not sure if Zozo wants to ask this, but it can be used somehow to monitor the CPU clock as well, eg switching to "turbo EP" mode, SymbOS would be able to notice somehow, that CPU clock is higher, or such. The only problem with this: it won't work if there is no idle time, so idle process has never gets the control.
@LGB: Thanks for the new functions, such a hex dump makes some things easier! Yes, the kernel is still working after such a freeze. I guess the Desktop Manager process is hanging. I will add some debug code into SymbOS to find out, what is still alive and what not. Unfortunately this will take a while, as I am currently working on another things.
By the way, it would be useful the mentioned (by me) "label file" somehow, which can be feed (well will be, if I develope something like this into JSep, though segment numbers must be also provided ...) to JSep, so you can query a SymbOS data structure (or code) by symbol name ... I don't know ep128emu has this capability or not (but anyway you told, that it does not happen with ep128emu, though something like this can be useful with other software as well than SymbOS), but eg for Commodore 64 emulation I use VICE which has the ability to load a label file and use that for debugging.
Hmm, it's kinda interesting that every time you press Z80 button in JSep you get PC values belongs to the idle process and never for the desktop manager that can help where the execution is? By the way: as far as I can imagine, SymbOS should store all Z80 registers of a given process, since values must be restored when the scheduler gives back the control to that process. By knowing it, isn't it possible to eg peek()
the kernel process structure to get to know what PC has the desktop manager process?
I thought that "desktop manager hangs" means that eg it's in a infinite loop. But it can't be since then IDLE process would never been invoked, since its priority (as far as I can imagine) is lower than the desktop manager. So, just seeing that execution is almost (?) always in the idle process means that no higher priority processes are in "working" state. Am I right? So maybe desktop manager hangs in a way that it waits for a message or such, so the theory above is not right, and maybe desktop manager should be inspected that why it is waiting for a message, what it could be, and so on. Or I only want to be too smart and I am totally wrong ...............
Or maybe desktop manager hangs only because it waits for another process through a message and that is which is "frozen" for some reason?