Incandescent Lamp Simulation Question with latest build

[Mike Katz]

I have Bill's latest build (trunk) running on two PiDP-8/I's one running a PI3B and one Running a PI4B.  Both are running Trixie 64 Bit.

The ILS seems to be decaying slowly on both of them compared to an actual PDP-8/E.

Video of the 2 PiDP-8/I's. PI3B on the Left, PI 4B on the right.

Video of my PDP-8/E running the same program

[Ian Schofield]

Hi,

 Could you send the code used for this test.

BW, Ian.

[William Cattey]

Hello Ian,

Nice to know you're monitoring this communication.

I think I know what's going on, actually.  I noticed in my testing that indeed the decay was slow.  But only when I ran pidp8i out of the build system, not the installed version.  Then I tripped over these lines  in the install logs:

Setting real-time priority capabilities on pidp8i-sim...
Setting real-time priority capabilities on pidp8i-sim-ils...
Setting real-time priority capabilities on pidp8i-sim-nls...
Setting real-time priority capabilities on pidp8i-test...

Looks like ILS wants real-time priority to do its work properly.

The documentation on ILS is pretty far out of sync with what's actually implemented.

What's published on the tangentsoft wiki is almost 7 years old!
https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Simulator&p

We have the timeline of the branch integrating of ILS2 with pi5 support two years ago with much heavy lifting by HB Eggenstein, and Steve Tockey.

How can we bring our published documentation up to date to explain the current algorithm, the important bits of cleverness we worked through, and the need for this real-time stuff so as to not confuse people going forward?

-Bill

[Ian Schofield]

Hi Bill,

 Thanks for your note. I am not surprised that this might be a task priority problem as the original ILS code was not synced to any RTC sources.

 It is a good idea to run a short piece of startup code to evaluate the tasks execution speed and adjust the ILS parameters with this data

 as you have in gpio-ils.c. I am surprised that this does not sort the problem out.

 This should have had the result that all the different Pi's show the same display even if the overall MIPS varies.

 However, I do note that around line 202 you comment that the fetch and execute brightness are set to 50% for each cycle.

 I am rather puzzled about this as a basic fetch/execute cycle (EG OPR) takes 1.5 us for which the ACC is updated at TP3.

 and finally locked at the end of TS4 and then a new fetch starts.

 However for an OPR instruction (Fetch state only):

 MA -> MA+1 @ TS1

500 ns 

MA->PC @ TP1

250 ns

MEM(MA) ->MB  @ TP2

250 ns

ACC->(new)ACC @ TP3

500 ns (ALU settling time to end of TS4)

The sequences for the MRIs also include a second/third fetch cycle at which point the register are again updated as above.

Anyway (so far as I can determine), the fetch is set by TP4 at the end of the previous cycle and then execute is only set on the

next cycle for MRIs (which may include a defer cycle). So, for a series of OPR instructions and a JMP, execute is never set.....

Regards, Ian.

[William Cattey]

Hello Ian,

What version of the tree are you looking at?

In trunk, the code around 200 is commented out:

 198  #if 0
   199  // This has been disabled because Fetch and Execute are now accurate wit
h
   200  // the actual major state of the simulated machine
   201  
   202          // Hard-code the Fetch and Execute brightnesses; in running
   203          // mode, they're both on half the instruction time, so we
   204          // just set them to 50% brightness.  Execute differs in STOP
   205          // mode, but that's handled in update_led_states () because
   206          // we fall back to NLS in STOP mode.
   207          br_targets[5][2] = br_targets[5][3] = MAX_BRIGHTNESS / 2;
   208              for (int row = 0; row < NLEDROWS; ++row) {
   209                  size_t *prow = pdis_paint->on[row];
   210                  for (int col = 0; col < NCOLS; ++col) {
   211                      br_targets[row][col] = prow[col] / br_quant;
   212  
   213                  }
   214              }
   215  
   216  #endif

This is why we need to update our documentation.  ;-)

-Bill

[Steve Tockey]

I'm not 100% sure this is relevant, but it could be. So here goes:

1) Setting Fetch and Execute lamps at 50% brightness was, I believe, only done in the pre-Cycle Accurate version of the PiDP-8/I simulator. This was because that simulator only ran at a full-instruction emulation level. The latest version, which includes Cycle Accurate, lights the Fetch, Execute, and Defer lamps proportionally (sampled) to match the actual memory cycles encountered. The easy way to tell that you are running the pre-Cycle Accurate version is to note that when OS/8 is in its user IO Wait loop (PC looks like 01217), both the Fetch and Execute lamps are lit. In the Cycle Accurate version, only the Fetch lamp will be lit per my second point.

2) All OPR instructions (Op code 7) do take only one memory cycle, Fetch. IOT instructions (Op code 6) also take only the one Fetch memory cycle (But, IIRC, can take longer than 1.5 uSec in real hardware when they involve Pause). MRI instructions AND, TAD, ISZ, and DCA (Op codes 0-3) take 2 memory cycles, Fetch and Execute, when when they are directly addressed (bit 3 == 0). They will take 3 memory cycles, Fetch, Defer, then Execute, when indirectly addressed (bit 3 == 1). While JMS and JMP (Op codes 4 and 5) are technically MRIs, they behave differently than the other MRIs in terms of memory cycles. When JMS and JMP are direct (bit 3 == 0), they use only 1 cycle, Fetch. When they are indirect (bit 3 == 1), they take 2 cycles, Fetch and Defer.

The OS/8 user IO wait loop code is something essentially as follows:

01207  6031  WAIT,   KSF         / SKIP THE NEXT INSTRUCTION WHEN ANY KEY HAS BEEN TYPED

01210  5207          JMP WAIT    / NOTHING HIT< CHECK AGAIN

The KSF at 01207  is an IOT so Fetch only. The JMP at 1210 is direct, so it's also Fetch only. Thus, in OS/8's user IO wait loop only the Fetch lamp should be lit when it's executing.

-- steve

[Ian Schofield]

Hi Steve,

 Sorry to nit pick ... I am a programmer (yeah right). You are correct about the JMP taking only 1 cycle ie fetch only. A JMS takes (at least) 2 cycles ... to write the return address at the target location.

 Hence, this instruction would have an execute cycle. And, yes, IOT cycles are longer and I would make a fuss here in that the IOT LED should be brighter than the JMP LED for a

 KSF, JMP .-1 loop. In addition, this loop should not have an execute cycle. Having said all of this, I cannot remember the front panel patterns on my 8/I. After all it is 50 years ago!

 For the IOT delay, I have included this in my local build. See attached image. Please note that the execute LED is lit ..... wrong I think!

 This is the OS/8 keyboard loop. I also can recall a video which I cannot find but here is one that is close to what we want:

Bing Videos

However, the test app contains an ISZ so there will be an EXECUTE cycle but I think this bulb is a bit dimmer?????

I think we might need to ask someone who has a real machine to help us here.

Regards, Ian.

[Steve Tockey]

Ian,

Ooops, you're right. My mistake. JMS does take 2 memory cycles when direct and 3 when indirect. I stand corrected. Thanks for reminding me.

FWIW, I'm also a programmer and not a hardware guy. Back when I did PDP-8 work for real, I ended up taking on field service for the company's -8/m and -8/a embedded sites. I had to get far enough into the hardware and the logic to diagnose and repair the darn things. Taking a Minicomputer Architecture class in my undergrad degree at UC Berkeley where we designed our own PDP-11 (taught by Dave Patterson, inventor of RISC) helped a lot, too. But that was all 40-ish years ago and I've dropped a lot of bits of that particular memory content. otherwise, it's been software all the way since.

Personally, I wouldn't fuss about the relative brightness of IOT vs. JMP. It doesn't need to be perfect, I think we're in the zone of "good enough". On the other hand, I've been kicking around doing the research on making the Data Break lamps (Word Count, Current Address, and Break) actually work for simulated RK05 disk accesses.

Yes, if the CPU is in OS/8's IO wait loop, only Fetch should be lit. not Execute. That's suggesting you're not running the Cycle Realistic version.

-- steve

[William Cattey]

Meanwhile, I fed the current code, and the change history of gpio_ils.c to claude and have just published an updated version of the ILS wiki page: https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Sim

However, I do not know how accurate the updated history is.  @Steve, @Ian, can you do a sanity check on the new wiki page?

It seems like we have not yet achieved consensus on documenting the real-time need for the ils code.

-Bill

[Steve Tockey]

Bill,

All I'm getting is an empty page. Is that the correct URL?

-- steve

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-8/c3dc78da-69c9-458e-8dd2-346b6443d6d6n%40googlegroups.com.

[Ian Schofield]

Hi Bill,

 Ditto....

 Steve; The RK05 interface is also an interesting problem in that I don't think that there was ever a module for the 8/I.

 Are you just going for a single cycle databreak as per the RK8E controller? I don't think we can expect the users to be forced to use one or more DF32s!!! (RF08 slightly better)

Regards, Ian.

[William Cattey]

Odd. Looks like the paste-in got truncated.  Try this one: (which I just tested.)

https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Simulator&p

[Warren Young]

On May 8, 2026, at 09:46, William Cattey <bill....@gmail.com> wrote:

https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Simulator&p

I’ve given it a quick ASCIIMath treatment. Please sanity-check.

Note the use of escaped backslashes: unescaped still gives MD code blocks, while escaping them allows them to show up when the JS runs and thus be turned into math notation. The per-repo JS tries to keep this from being overly grabby; it is safe, for instance, to use backticks in commit comments.

[Steve Tockey]

Bill,

Thanks. Overall it looks great, just some relatively minor feedback for you to consider:

*) In section The Problem: "There is a range of change rates that would blur together into a soft constant glow on a real PDP-8/I but which a human would perceive as flickery on a PiDP-8/I with the original lamp driving code. The result is that programs running on a real PDP-8/I that give a nice soft glowing effect would appear flickery when run on a PiDP-8/I." -- The two sentences are essentially saying the same thing. One sentence would probably be better.

*) In section Schofield's Incandescent Lamp Simulator: "Incidentally, the two functions above are actually the same function. The falling function can also be written b = b + (0 - b) × 0.01, showing that the only thing varying is the target value: 0 for falling, 32 for rising." -- I'm not understanding this. Shouldn't you just generalize the equation and show it as b = b + ( t - b ) x 0.01 where t is the target value of 0 for falling and 32 for rising? That would make a whole lot more sense to me.

*) In section Problems with Schofield's ILS and elsewhere: "The human PoV limit means ..." -- The acronym PoV is never defined.

*) In section Non-Linear PWM Brightness Ramp and elsewhere -- the acronym PWM is never defined. Pulse Width Modulation, I assume, but best to be explicit.

*) In section Auto-Calibration: "If the per-iteration factor is f and the cycle period is T, the rate of brightness change per unit real time is (1 − f)^(1/T)." -- Minor inconsistency that the variables f and T are italicized differently in the words than in the  formula. Should the formula in your text be written as "(1 − f)^(1/T)"?

*) In section Further Refinements (2025): "Accurate Fetch/Execute lamp behavior." -- Technically, it's more than just Fetch and Execute. It's also Defer. IIRC, the Defer lamp either never came on or it was a completely artificially synthesized value. The three instruction execution Major States are Fetch, Defer, and Execute (in that order in the maximum case). Might be best to refer to it as either the Cycle Realistic or the Cycle Accurate modification in that sub-header and say something more like "Prior to 2021 the SIMH emulation of all PDP-8s was at the whole instruction level. In any real PDP-8, instructions are executed as a series of memory cycles, Major States, that vary by the type of instruction. Specifically, the PDP-8 Major States are named, Fetch, Defer, and Execute. Lamps on a real PDP-8 front panel reflect the status of the CPU as it progresses through these Major States. As well, the Sing Step switch on a real PDP-8/I front panel puts that real -8/I into a mode where it executes one Major State at a time each time the Cont switch is pressed. In a desire to make the PiDP-8/I more realistic, the SIMH code was modified to support emulation at the Major State level rather than the whole instruction level. With the Cycle Realistic / Cycle Accurate modification, not only do the Fetch, Defer, and Execute lamps on the PiDP-8/I front panel display realistic status, the Sing Step switch can also be used together with the Cont switch to execute machine code at the Major State level exactly as on real PDP-8/I hardware." in the description.

*) In section Tuning the ILS: "PIDP8I_ILS_TWEAK=rising,*falling*" -- The word rising is italicized and nothing else is.

*) In section Acknowledgements: "Steve Tockey rewrote the GPIO display side of the ILS: the non-linear brightness ramp, the auto-calibration mechanism, and the supporting infrastructure in gpio-common.c" -- No, actually I didn't. I can't remember who did that. All I did was the Cycle Realistic / Cycle Accurate code. I didn't do anything on the driving the PiDP-8/I lamps side of the house. Also, you bold names in this sentence, but not Oscar and Ian in the sentence immediately above. I would suggest their names be bolded also.

*) In Footnote 1: "(Realize that the "rows" I'm talking about here are logical rows in this electrical matrix. They only have a loose mapping to the rows and columns of the LEDs and switches as they're arranged on the PCB.)" -- It could be worth adding that you can see where those logical rows and columns appear on the front panel when you use the pidp8i-test utility, assuming it still runs these days.

Thanks,

-- steve

[Steve Tockey]

Ian,

You're right about the real -8/I and RK05s. The -8/I was a point-to-point wired backplane like the "Classic" PDP-8, -8/S, and -8/L while the RK05 was only offered with an Omnibus interface card. At least it should have been theoretically possible to wire an -8/I backplane into an Omnibus, but the issue of different memory cycle times could still mess things up. Would 1.2 uSec core memory on an Omnibus work with the -8/I's 1.5 uSec cycle time CPU? OTOH, peripherals should probably have worked as they should be independent of the CPU's memory cycle time. I wonder if anyone ever connected an -8/I to an Omnibus for real. The place I worked at using -8s had all of their hardware maintained by a former DEC employee who--according to him--installed the very first PDP-8 at a customer site. He modified a Classic PDP-8 to be able to use 128K. A lot of things were possible if one had the desire and the know-how.

All that said, while the PiDP-8/I has the front panel of an -8/I the simulator actually behaves far more like an -8/e/m/f than an -8/i. 

IIRC, some installations of TSS-8 ran with a PDP-8/I and RF08 disks so that crowd could be interested in data break blinkenlights.

-- steve

[Steve Tockey]

 Come to think of it, TC01 / TU55 also used data break so that kind of mod could be useful there, too.

-- steve

[William Cattey]

Hi Steve,

I've updated the ILS wiki page to correct the issues you raised.  I did a teeny bit of wordsmithing on your suggested revision to the "Further Refinements" section.

I also corrected the "Acknowledgments" section to credit you with the Cycle Accurate code, and HB Eggenstein for the improvements to ILS itself.

Hi Warren,

I reviewed the reformatting of the equations. They look right to me.  Thanks!

Everyone else,

If anybody else has amendments to propose, I'm listening.

-Bill

[Steve Tockey]

Bill,

Looks great, thanks. I really appreciate all the hard work that you, Warren, and all the others have put into this latest release. It is much improved since the last release.

And, quick FYI, I got a good start on getting the Data Break (Word Count, Current Address, Break) front panel lamps active. I'm hoping that won't take too long to complete.

-- steve

[Rick Murphy]

For the record, there was an adapter from the 8/i's posibus to omnibus : the DW8/E. Requires a data break interface cart for peripherals like the RK8E.

    -Rick

To view this discussion visit https://groups.google.com/d/msgid/pidp-8/e5060544-d03a-46fb-bdb0-c1610cbb5397n%40googlegroups.com.

--

Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA