Question on the new ILS model

[Cristian Arezzini]

I've been quite out of touch for a long time, only scanning the list here and there, but recently I noticed the plans for a new update, which includes a new ILS model.

I have a quick question. The old ILS model had a bug (admittedly not easy to encounter): when you slow down the clock speed to very slow speeds (I seem to recall that it happens with speeds slower than 10 instructions per second), i.e. 1 instruction per second, then instead of having the LEDs on for the whole duration of the instruction (and possibly "fading" between instructions) the LEDs would "blink on" for about 1/10th of a second, and then stay off for the remainder of the duration of the instruction.
Does the new model still have this bug, or is it gone, since it's a whole different model?

Thanks,

Cristian

[Heinz-Bernd Eggenstein]

This is a very good point!

TL;DNR: yes the problem persists but I rhink we can fix it.

The long version:

We still have a problem here, and if this was a bone, it would be a multiple fracture :-)

To start with, it's not actually easy to tell SIMH to execute just one instruction per second. You can telll it to execute 330000 instructions per second with

set throttle 330k,

but both 

set throttle 1

and

set throttle 0.001k 

are rudely rejected by SIMH as a syntax error. 1000 instructions per second is the minimum via this syntax.

So what people do (also via the --throttle=human and --throttle=trace options to configure) is use the "fraction" syntax fro throttle:

set throttle 1/1000 

tells SIMH to execute 1000 times the minimum delay period (happens to be 1ms)  after every instzruction => roughly 1 instruction per second.

The first problem is that the "fraction" syntax will cause the ILS mode to be disabled and fall back to NLS-like mode. This is documented:

https://tangentsoft.com/pidp8i/doc/trunk/README-throttle.md

"If you use the ratio form here (e.g. --throttle=123/456) the configuration script disables the ILS feature because of the way SIMH handles this type of timing. The ratio form of CPU throttling tells SIMH to run some number of instructions and then sleep for some number of milliseconds. (The above 123/456 example means "run 123 instructions, then sleep for 456 ms.") This batched instruction execution scheme interferes with the high-speed LED panel update rate, so we must disable the ILS when running with such a throttle value set."  

(it's not just the configuration script thos, even you change the throttle setting to this on-the-fly with CTRL-E, the code will disable the ILS effect(

The second problem is that in general, if the instructions per second  gets below the panel refresh rate, you see the effect you mentioned. This could be seen as a bug.

So two problems here:  a) the glow effect is disabled which is not nice and b) the lights go out when they should not

The extreme case of "low instruction rate per second" is when the CPU halts altogether => 0 instructions per second. The code then has some special logic to prevent the lights from going out altogether, but it still feels compelled to disable the ILS "glow". Which is sad: e.g. you would want to have realistic ILS effects when you single step thru a program!!! This never worked with the old or new ILS code but it should.

All of this can be fixed, but because the logic that handles the sim throttling / halting /single stepping affects several places in the code it's not entirely trivial to get it all right.

But if not now, when? I'll see what I can do.

Thanks fro the reminder

Cheers

HB

[Heinz-Bernd Eggenstein]

Oh well....while fixing the "extreme throttle case", I ran into something that to me looks like a problem in the current cycle-realistic code variant. I think Steve will have to look into this:

My understanding is this:

When throttling SIMH, the result under the hood is that the current code (both cycle-realistic and legacy) will decode and execute a certain number of *instructions*, then SIMH will insert a waiting delay. The number of instructions to execute in sequence and the length of this delay are calculated and calibrated by SIMH so that the throttling target  in instructions-per-second is met, on average.

 The important thing here is that a throttling-delay is inserted only in between *instructions". That is the reason why we can still use 

set throttle 333k   

even in the cycle-realistic code to get a realistic speed for the PDP-8i which has a cycle time of 1.5µs = 667k cycles per second

So if you run the cycle-realistic code throttled at 1 instruction per second, you will see the state of the LEDs in between instructions persist on the panel  for about a second (what you expect) but you will see the state of the lamps change during cycles for one instruction as flashes (and more so with the proper ILS effect restored)

Even when using realistic throttling values, I think the fact that throttling delays are currently only inserted in between completed instructions will create a bias for those states and will let the lamps lit in those states appear artificially brighter than they should be if all cycles (not instructions) were treated equally.

I think the only way to correct this is to allow the delays for throttling (and other stuff that happens triggered by timers???)  to happen after any *cycle*,

But that would also probably mean that we will then have to set the throttle in terms of cycles, e.g.

set throttle 667k 

to get realistic PDP-8i performance.

Hmmm....thoughts?

Cheers

HB

[Heinz-Bernd Eggenstein]

Here is a video of the effect I described above.

The sim here is running at 1 instruction per second, and I finally got ILS working in that mode as well (also in single step/single instruction). But you can also see the short flashes of lights when more than one cycle is executed per instructions (e.g. watch the FETCH/ EXECUTE/DEFER lights ).

https://youtu.be/HO8LtWGK3ng?si=xx7SdLDB07pGyskK