Editor locking up during simulation

[Technical]

And, for completeness - and others looking for the solution to the actual original topic - the original issue was actually a coding error where

Symbol  desired_pot = B.5

should be

Symbol  desired_pot = 13

because on X2 parts, if using a symbol within a readadc command, you must use the ADC channel number. For the 28X2 if you type 'readadc b.5' directly the compiler will recognise the mistake and auto-correct the pin name to the channel number (to 'readadc 13)' at compilation, however if you use 'readadc my_symbol' the compiler cannot auto-correct this - hence you must use the correct channel value within the symbol to start with.

So in this case the simulation is trying to simulate 'readadc 5' (because within a symbol B.5 has the value 5) and channel 5 does not exist on the 28X2. On a real chip this wouldn't work either.

 

[Buzby]

This is exactly the sort of condition that caused me to request "Run with no GUI until condition met". The intention was to allow the simulator to run at full speed until a breakpoint or watch condition was met, then reinstate the GUI. My expectation was that there would be a button to set this mode, not some half-@rsed attempt to do it automatically. ( See https://picaxeforum.co.uk/threads/programming-editor-wishlist.20188/#post-192088 )

Also, I don't understand why the capability of the OS should affect the behaviour of the simulator, other than making it run slower. The OS shouldn't need to be involved for simulation if the GUI is switched off.

If the simulator is hogging all the resources, then that's a sign of poor programming. It's been a long time since I last programmed, but even then I knew how to release time for the OS to do other things while my loops were running as fast as possible. ( It was VB6, and the release function was 'DoEvents'. Surely modern software has something similar ?. )

The age of my computer is contemporary with the introduction of PE6, Intel i5 @ 2.67GHz with 8Gb RAM. The OS is a bit more modern Win10 Pro 64.

What system would Rev-Ed recommend that will run the simulator at full speed without locking up the comuter ?

 

[kfjl]

The OS has nothing to do with your "problem". Computing power is what counts.
The fastest a program can go is when it hogs all the resources. You're asking for a program that goes as fast as it can without hogging all the resources.
You need DEEP BLUE.

Much ado about nothing.

 

[Buzby]

Yes, run as fast as possible, but still release time for the OS to do its non-PE business.

I'm certain that this can be done.

To simulate a PICAXE will use a tiny fraction of a modern CPU's time. All the simulation has to do is shuffle bytes in a virtual PICAXE, yield some time to the OS, and check for the user input that will switch out of 'fast' mode.

If we allow the PICAXE simulator a bit more time, then it can handle breakpoints and a watch entry, which is still only going to use a tiny fraction of the CPU resources.

Once the stop condition is met, or the user request is detected, the simulator can then switch back to the 'normal' slow simulation mode.

My suspicion is that the current simulator is tightly bound to the OS, so there is no way to fully seperate the simulation from the GUI. This, combined with the totaly useless obfustication in PE6, means that no amount of CPU power is ever going give fast simulation.

Can anyone prove me wrong, and show me a system that can run the simulator at full speed without locking up the computer ?

 

[bpowell]

At very low simspeeds, the program is simulating just fine; however, the PE application doesn't accept user input.

I've never had the computer "lock up" and didn't see references to the computer (or OS) locking up ... just the editor.