RELEASE v20170123

[Warren Young]

I've just tagged the biggest release of the PiDP-8/I software yet:

• When any program that talks to the PiDP–8/I front panel starts up, it now prints out a banner modeled on the Erlang configuration line. Real-world examples:
  
  PiDP-8/I trunk:i49cd065c [pi3b] [ils] [serpcb] [gpio]
  PiDP-8/I release:v20170123 [cake] [nls] [nopcb] [rt]
  
  
• The ILS feature can now be disabled at configure time via the new --no-lamp-simulator flag. This option is automatically set when building on a single-core Raspberry Pi. (The flag is there only to allow someone building the software on a multi-core host machine to disable the ILS. There is currently no easy way to force the use of the ILS on a single-core Pi, on purpose.)
  
• Tweaked the ILS decay constants to be asymmetric, better mimicking the way real incandescent lamps work: they heat up to full brightness faster than they fade to perceptively “off.”
• The LED values used by the GPIO thread were being recalculated way too often. They're now updated only about 100 times a second, with the rate continually adjusted based on the simulator's current execution speed.
• In prior versions, the ILS was only updating at its intended rate when the PDP–8 simulator was running flat-out on a current multi-core Raspberry Pi. If you throttled the SIMH simulator to a slower execution rate, the display quality would start to degrade noticeably below about 1 MIPS.
  
• With the prior fix, we now ship 5.script (i.e. the handler for starting the simulator with IF=5, or restarting it with IF=5 + SING_STEP) set to a throttle value of 30 kIPS, which allows the human to see each AC/MQ modification. The built-in delay loops are still there, else we’d have to drop this to well under 1 kIPS.
• The SING_INST switch now immediately puts the processor into single instruction mode, not requiring a separate press of the STOP key, as in prior versions. This is the correct behavior according to the 1967–1968 edition of DEC’s Small Computer Handbook for the PDP–8/I.
• Greatly simplified the way single-instruction mode, processor stoppage, and the CONT key work. The prior implementation was error-prone and difficult to understand. This fixes a particularly bad interaction between the way HLT instructions and CONT key presses were handled, causing the processor to not resume correctly from HLT state.
• Consolidated and cleaned up the bulk of the PiDP–8/I switch handling code so that it is not so intimately tied into the guts of the PDP–8 CPU emulator. This will greatly increase the chance that future updates to the upstream SIMH PDP-8 CPU code will apply cleanly to our version.
• Fixed a bug in examples/bit-rotate.pal which caused it to skip the actual bit rotation step. We were trying to microcode two instructions into one that the PDP–8 won’t accept together, and we didn’t catch it until now because the HLT bug masked it, and the palbart assembler we ship isn’t smart enough to notice the bug.
• Fully generalized the mechanism for generating obj/*.lst, bin/*.pt, and boot/*.script from examples/*.pal. You can now drop any PAL assembly language program into the examples directory and type make to build these various output forms automatically using the shipped version of palbart. This effectively turns this PiDP–8/I software distribution into a PDP–8 assembly language development environment: rapidly build, test, and debug your PAL programs on your PC before you deploy them to real hardware. Or, write PAL programs to debug the hardware or simulator, as we did with examples/bit-rotate.pal.
• Fixed a sorting bug in the tool that generates boot/*.script from obj/*.lst, resulting in dep instructions that weren’t sorted by core address. This didn’t cause any real problem, but it made tracing the execution of a PAL assembly program difficult if you were trying to refer to the boot/*.script file to check that the PiDP–8/I’s front panel is showing the correct register values.
• Updated SIMH to the latest upstream version and shipping a subset of the SIMH docs as unversioned files from tangentsoft.com.
• The configure script now aborts the build if it sees that you’re trying to build the software as root, since that means it generates the init script and the pidp8i script expecting to run the installed software as root, not as your normal user. The most common way this happens is that you have a configured source tree, then change one of the *.in files and say sudo make install, thinking to build and install the change in one step. This fixes that.
• Several improvements to the build system.

As always, you may download it here.

[Tony]

@warren : do you actually ever sleep? :)

[Warren Young]

Intermittently. ;)

[Brian R]

Thanks Warren, updated smoothly via fossil.

There is noticeably more activity on the panel when idling than previously.

Is this deliberate, or just a side-effect of the code changes?

[Warren Young]

On Tuesday, January 24, 2017 at 6:15:02 AM UTC-7, Brian R wrote:

Is this deliberate, or just a side-effect of the code changes?

It is almost certainly a side effect of either the timing changes or the new ILS decaying constants.

I can't know for certain that you have not found some bug, but I do know that there have been enough changes in this area to explain such differences.

If you want to prove a bug to me, you're going to have to do more than "it looks different now." Yes, I know it looks different. :)

[Brandon Himoff]

Thanks for the update. "It looks different" to me too. At idle (on a Pi 3) it alternates between the normal 50% blend of the two instructions in the tight idle loop, and just one of the instructions. The rate of change varies between a second and five seconds. It looks like a time version of a Moire pattern where the LED sample rate is an integer ratio to the clock rate. I hope this is helpful.

[Hans PUFAL]

I have made a video -  see it here : https://www.youtube.com/watch?v=jN56VsvaDRE&feature=youtu.be

Others can verify that their systems produce similar results.

   Hans B PUFAL
 Paleoinformaticien
Angouleme, FRANCE

[Warren Young]

Once again, I know it looks different. What those of you who are concerned about this have to do is show that this is a problem. "Different" is not diagnostically useful when we know for a fact that it's supposed to be different. Is it different good or different bad? If bad, what should be shown instead, and why?

[Brandon Himoff]

It is not sure, but certainly a real PDP8 when in a tight loop should just show steady full intensity LED on where both of the two instructions are 1, where one is 1 and one 0 it should display 50% and where both are 0 it should be dark. Any flickering or change would be an artifact of the sampling rate (or a bug of another nature of course). I looked in the code for the sample rate but did not immediately see it. It may be critical to have a fairly prime ratio (certainly a number not divisible by 2 or 3) of instructions per sampled instruction.

[Brian R]

On Tuesday, January 24, 2017 at 4:30:45 AM UTC, Warren Young wrote:

 

• Fully generalized the mechanism for generating obj/*.lst, bin/*.pt, and boot/*.script from examples/*.pal. You can now drop any PAL assembly language program into the examples directory and type make to build these various output forms automatically using the shipped version of palbart. 

I'm not getting this to work. The example I'm using (cylon.pal) has previously been verified as a valid .pal file with no errors.

Sample output below, with various input options.

pi@raspberrypi:~/src/pidp8i/trunk/examples $ make

make: *** No targets specified and no makefile found.  Stop.

pi@raspberrypi:~/src/pidp8i/trunk/examples $ make cylon

make: *** No rule to make target 'cylon'.  Stop.

pi@raspberrypi:~/src/pidp8i/trunk/examples $ make cylon.pal

make: Nothing to be done for 'cylon.pal'.

pi@raspberrypi:~/src/pidp8i/trunk/examples $ 

I'm guessing the command syntax requires more than just 'make'

Sorry for being a noob :-) 

[Warren Young]

On Wednesday, January 25, 2017 at 2:29:44 AM UTC-7, Brian R wrote:

On Tuesday, January 24, 2017 at 4:30:45 AM UTC, Warren Young wrote:

• Fully generalized the mechanism for generating obj/*.lst, bin/*.pt, and boot/*.script from examples/*.pal. You can now drop any PAL assembly language program into the examples directory and type make to build these various output forms automatically using the shipped version of palbart. 

I'm not getting this to work. The example I'm using (cylon.pal) has previously been verified as a valid .pal file with no errors.

Sample output below, with various input options.

pi@raspberrypi:~/src/pidp8i/trunk/examples $ make

It was intended to work only from the top level of the project; I was directing you to use the same "make" you use to build everything else. make(1) only works in directories that contain a file called Makefile or similar. This makes sense to me because your next step is something like "bin/pidp8i-sim boot/cylon.script", so why would you want to be in the examples directory to start with?

I'm going to assume you have a good answer to that, so I have added Makefiles to the examples, src, and src/PDP8 subdirectories. If nothing else, it will help out someone who is temporarily cd'd into one of these directories to work on something and forgets to cd back up before typing "make".

These intermediate Makefiles simply redirect top-level targets to the top-level build system: they purposely do not replicate any part of that build system. In particular, this is not the thin edge of a wedge leading to a recursive build system, because Recursive Make Considered Harmful.

[Warren Young]

On Tuesday, January 24, 2017 at 3:53:34 PM UTC-7, Brandon Himoff wrote:

It is not sure, but certainly a real PDP8 when in a tight loop

That's been my major blocking point: I wasn't convinced that it *was* in a tight loop. How did we know that it wasn't occasionally going off on an interrupt and showing the PC and such of whatever happened during a brief interrupt handler? Maybe the new front panel display was more correct now.

Then just today, I was reading the SIMH PDP-8 manual (yes, I do sometimes RTFM) and it just kind of casually mentioned that while OS/8 is waiting for a key, interrupts are turned off! That kicked the legs out from under my rebuttal, so I started looking into the differences between the two versions.

It turns out that I more or less explained it in my replies to alank2, who was the first to notice that this new display didn't match the old. The culprit turned out to be the new mechanism for limiting the LED status updates to 100 Hz, justified by the fact that a human can't notice updates any faster than this. This ignored an important fact, which is that the GPIO thread also has an update rate, and both loops are asynchronous relative to each other (i.e. we have no locking between them) and both have a high amount of jitter in their timing. So, what you got was an incredibly messy beat frequency between the two loops.

Some suggested fixing this by making the update rates either totally synchronous or using relatively prime update rates, but neither was really workable. Synchronization would have slowed everything down, and we already know it's not required. Messing around with relative primes doesn't help because of the high jitter: The CPU instruction rate varies by about +/-10%, and the GPIO loop is at the mercy of the OS's timer accuracy, which isn't great for a user-space app.

This idea that the ledstatus[] update rate needed to be approximately the human PoV limit is simply wrong. Instead, we need to be updating these values on every CPU instruction, like the old NLS code did — but not the ILS code — so that the sampling rate of the GPIO thread can take a fair stochastic sample of the instruction state.

Bottom line, I've checked in a fix for this, so anyone who wants to try this before I get around to cutting another release can update from Fossil and give it a try.

This also fixes another problem, which is that the code that sets the Execute indicator was doing it too close to the code that sets the Fetch indicator, so that you didn't get a nice 50/50 split in the tight OS/8 keyboard read loop. Instead, it spent most of its time in Fetch state, which isn't what you want.

Thanks to all of you who tried to clue me into this problem, despite my resistance.

[Warren Young]

On Wednesday, January 25, 2017 at 7:23:52 PM UTC-7, Warren Young wrote:

I've checked in a fix for this, so anyone who wants to try this before I get around to cutting another release can update from Fossil and give it a try.

I'm not entirely happy with this solution, by the way. Updating the ledstatus[] values takes quite a lot of calculation, even if it is mostly bitwise arithmetic which CPUs do really fast. It still shows up in testing: a SHOW CLOCKS command used to show something like 6-8 MIPS in the Execution Rate line before I started all this CPU/LED cleanup work, and now it's down to about 1-2 MIPS on my Pi 3.

While I fundamentally have no problem burning some of the execution rate difference between the PiDP-8/I and a real PDP-8/I, that's a higher cost than I'd like to pay for these improvements. I'm going to have to see about ways to buy back some of the old performance.

Better, I'd like to review patches that others have submitted which make it run faster without making the code harder to read again. :)

[alank2]

I've got the project put away at the moment, but tomorrow I will be getting a pi 3 finally so that will give me more to test with.

It is certainly not trivial what you are trying to accomplish here Warren!

To consider the original PDP-8 lamp display, is it true that each lamp was driven directly from the register it was indicating?  Even so, do the lamps used take a period of time to turn on/turn off that means they are incapable of keeping with the register speed even if you had a high speed camera to be able to see that fast.  I think I read that they later switched to LED's instead of bulbs.

If the LED's on the PiDP-8 were directly accessible, then in the main code we could just turn them on and off and it would be quite a bit simpler.  Sadly, there were no where near as many IO pins for that as would have been needed and multiplexing must be used.  Since that isn't an option, you have the thread running the emulation and you have a thread running the multiplexed display.  The question becomes how to map A to B to get the authentic look you want.

One way I can think of would be to in the emulation thread:  Once a cycle or sub cycle is done and it updates the LED's, you basically have what the lights should have been for that instant in time, until the next one.  Once all the LED's have been updated on or off, then use the enabled ones to bump a counter for each LED and keep a counter for the total number of updates.  When the display thread begins a display refresh at 100 Hz or so, it grabs all of these values and resets them allowing the main thread to build them new again.  Now, if the display thread can properly recreate the display from these counts, that would be great.  If for example 6000 emulation cycles occurred and one LED was on for 983 of them, we want 983/6000 brightness.  The question is could the display thread be capable of controlling it to this level or not.  Worse than that, the overhead on both sides to do this would almost certainly effect the MIPS in big way.  This would mean that the lights would always be chasing the actual running by 1/100th of a second, but that probably isn't a big deal considering human eyes can't see that fast anyway...

[Warren Young]

On Wednesday, January 25, 2017 at 8:16:43 PM UTC-7, alank2 wrote:

If for example 6000 emulation cycles occurred and one LED was on for 983 of them, we want 983/6000 brightness.

It sounds like you're trying to reinvent the math I've already done here:

  https://tangentsoft.com/pidp8i/tktview?name=f1bd669e8d

One subtlety I've already tackled that you haven't is that the area under the curve described by the decay function has to equal 1, else the summation of past brightness values to get the new brightness value gives either a gain or loss. Thus you see me breaking out the calculus, something I don't get to do that often.

Hoo-ah! 

[Roger Smith]

If what you need is to turn on an output for x/y of the time (x<=y) then here is a dirty little function which will do it for you :-

int ctrl(int duty) { return( (ctr+=duty)<0 ? 0 : (ctr-=slots,1) ); }

where ctr is a global, duty is x, slots is a constant y, and 0 means off while 1 means on for current time slot
this will give duty slots on for every slots time slots, as evenly distributed as possible.
This may not be what you are looking for, but I mention it  anyway.

[alank2]

Warren,

After looking at the code, there is one issue that is keeping it from being all that it can be - ledstatus is sampled inside the gpio-ils.c at its frequency.  I noticed the intervl is now 5 and with 2 sleep_us commands that is 10us plus the rest of the code execution time which means that ledstatus is probably being sampled at 100k/rows (8?) while the cpu emulation thread is running asynchronously at its own faster rate.  If the emulation thread is running at 1M then you are grabbing one of those 80+, who knows which one, and depending on how similar or dissimilar the two frequencies are, you can get into patterns that show up visually as an artifact.  The brtval needs to be moved to the emulation thread side so that nothing is missed.  Then, on the display side, it can see that out of 80 updates, a LED was on for 13 of them.  That is something consistent that you can work with on the display side and then apply any algorithm you want to it to give it delayed on/decayed off, etc.

One thing that is costly to control is variable brightness.  You have your normal multiplex speed (say 100 Hz) and you have to refresh all rows (8) so that means 100*8 or 800 Hz is the row update rate.  That is for on and off.  If you want multilevel brightness you have to multiple that by some number of levels that aren't as easy to discern.  If you really want it better you can gamma adjust those level, but that means even more granularity is required.  Lets just say you pick 16 levels.  That means a row update rate of 12.8kHz or 78.125us between rows, but for that you get 16 levels of brigthtness per 100 Hz frame.  That wouldn't use up too may resources and look very much like a LED PDP-8.  To add lamp flash decay, you can alter those brightnesses depending on the previous brightness although the 10ms transition between brightness levels might be too slow and more tweaks done to get it to look the way you want.

I may have some stuff to play around with this later next week to see what I can get it to do.

I got a pi 3 this morning, and wow, that is night and day difference faster!!!

[Brandon Himoff]

Warren, thanks for the update. I will try to run it tomorrow when I get back to the Pi. I had an idea that may have occurred to you already. It looks like there are two parts of the LED calculation now. Part One: The per instruction calculation. Part Two: The slower per lamp update calculation. Can you make it more efficient by incrementing a count in the Part One calculation for each LED state where the LED is on, and using that count to drive the Part Two calculation. Perhaps the calculation would be faster especially in Part One. If you are already doing it this way I apologize as I don't have access to your code right now.

[Warren Young]

On Thursday, January 26, 2017 at 6:12:54 PM UTC-7, Brandon Himoff wrote:

Can you make it more efficient by incrementing a count in the Part One calculation for each LED state ...

That would change the public interface of the GPIO modules again, and just after I got the ILS version back in line with the NLS version. There are three other users of that interface inside the project, not just one, and at least one outside it: Deeper Thought 2.

Yet, there may be merit to that approach, not because it makes things more efficient, but because it means we're not relying on clever oversampling and such to get the brightness values right: we can just divide each LED's count by the number of instructions executed since the last LED update.

This would probably solve something you see in the current implementation, where despite the recent improvement, the rightmost 3 bits of the PC register aren't showing a steady 50% brightness despite the fact that the code drives them at a simple 50% duty cycle.

[alank2]

I found some example code on using a mutex as well that allow good synchronizing between the threads.  I plan on replacing led_status with a led_values[columns][rows] that can hold a 32 bit integer each for a count.  When the set leds function is called, as it will change the led_values array, it will entirely be wrapped in a mutex.  Then in the display thread, at the beginning of each 100 Hz frame, it will use a mutex to copy the led_values array locally and then clear it.  The threads shouldn't fight too much as the copy/clear only happens once every 10ms.  So it will have to wait for the set leds function to exit so the data is in a consistent state ready to copy/clear, or the set leds function will have to wait on it if it is copying/clearing it.  This will give a perfect count of LED brightness for each LED and once copied locally, it can do anything it wants to massage/filter the data for display.  The only downside is that you are always seeing data 10ms late, but that isn't too bad considering human vision speed.

I really wish I had time to play with this project this week, but it will have to wait until mid to late next week.  I may try to have enough intensity levels to gamma correct it if I get it working well.

[Warren Young]

On Thursday, January 26, 2017 at 3:15:08 PM UTC-7, alank2 wrote:

The brtval needs to be moved to the emulation thread side so that nothing is missed.

No.  I just got done moving it *out* of the CPU core, on purpose. For one, it gives the NLS and ILS cases the same public module interface. For another, we can't continue calculating brightness in the CPU core when we move the front panel code out into a separate program, talking to the simulator over the SIMH front panel API.

Brandon's idea will solve the issue you've brought up.

[Warren Young]

On Thursday, January 26, 2017 at 7:48:35 PM UTC-7, alank2 wrote:

I found some example code on using a mutex as well that allow good synchronizing between the threads.

The thing keeping me from using mutexes is not a lack of example code. Mutexes add locking overhead, and I have yet to convince myself we need to pay that cost. I'm trying to make the thing faster again, not slower still.

I plan on replacing led_status with a led_values[columns][rows] that can hold a 32 bit integer each for a count.  When the set leds function is called, as it will change the led_values array, it will entirely be wrapped in a mutex.

You don't need the mutex. You can use two arrays and a pointer instead.

On init, the pointer points to array 1, and both arrays are clear.  The CPU core modifies whichever array is being pointed at at the moment. When the GPIO thread decides to paint the display, it flips which array the pointer points at and uses the other one. When the GPIO thread is done, it memsets array 2 to all 0s for the next iteration.

You avoid the mutex because the writer thread (the CPU core) never writes to the array the reader thread (GPIO) reads from, and the pointer update is atomic.

The threads shouldn't fight too much as the copy/clear only happens once every 10ms.

Instead of two threads, each running independently on its own CPU core, now you have two threads that, every 10ms, force a pair of userspace-to-kernel transitions to coordinate ownership of a small array of integers whose exact value is not critical.

This is not an improvement.

Let's go with the lock-free data structure.

[alank2]

>No.  I just got done moving it *out* of the CPU

>For one, it gives the NLS and ILS cases the same public module interface.

I agree with you that calculating the brightness does not need to be done in the core (or anywhere near the speed of the core thread), but taking a single snapshot of the core (1 out of every XXXX instructions) is always going to give poor results.  Too much data is being missed to be able to accurately recreate the display.  I don't see a way around this.  At minimum, a count of how many times it was on during a period vs how many counts in the period is necessary because of the much slower display thread.  I am a little hopeful that using integer only incrementing in the cpu thread for these LED values might allow have decent performance on older pi's as well if the display thread is kept to something reasonable.  We'll see.  If that is successful, doing ILS on it might not be such a huge penalty if the calculations are done every 10ms instead since a lamp glows/fades at rates that aren't too fast.

[alank2]

The array pointer thing is a good idea - does the ARM support RMW in a single instruction so that you can't get into a situation of read (old), increment it, pointer changes, write (new) with potentially a much larger value than it should be.  You still aren't getting a consistent display because the set leds could be in the middle of an update, but I suppose that might be unimportant.  Do you really think a mutex once every 10ms is going to be a big performance penalty?

[Warren Young]

On Thursday, January 26, 2017 at 8:23:55 PM UTC-7, alank2 wrote:

I don't see a way around this.  At minimum, a count of how many times it was on during a period vs how many counts in the period is necessary because of the much slower display thread.

That is the way around the problem: you export the "on" counts and the count of instructions executed since the last display update, and the GPIO thread uses that to calculate the brightness for each LED.

It's also a matter of encapsulation: the CPU core should not know about LED brightness. It should just report new register values to the front panel, and let it decide what to do with that info.

...decent performance on older pi's 

Could be right. It'll have to be tried.

Are you really fired up to do this, because I was already set to do it myself.

I don't see any point in competing implementations, but I think I know the code better than you do.

Your call. I won't turn down good patches. (But I get to define "good". :) ) 

[Warren Young]

On Thursday, January 26, 2017 at 8:34:54 PM UTC-7, alank2 wrote:

does the ARM support RMW in a single instruction

I don't see why you'd try to use such a thing, since all it does is avoid the need for the double-buffered LED count array. We're talking about 192 integers vs 96 integers. I think we can spare the space.

Anyway, what you'd really want is some sort of copy-and-zero operation that worked on whole arrays, so you could copy the global int array into a stack array to work on. It was while thinking about that that I thought up the pointer-to-array alternative, which is fast and atomic in pure Standard C. Why get more clever?

By the way, the inteface also needs a count of instructions executed since the last display update. So, instead of pointer-to-array, it's pointer-to-struct:

    struct display {

        size_t inst_count;

        size_t led_on_count[96];

    };

    struct display display_buf[2];

    struct display* pdis = display_buf[0];

Do you really think a mutex once every 10ms is going to be a big performance penalty?

Why pay any penalty, when none is needed? 

[alank2]

I'm happy to do it, but it will have to wait until next Wednesday.  I don't mind you defining good, If it works well and you are happy with it great; else no worries.

[alank2]

It only needs one count, not one for each LED.  Each time the set led's function is called, the total count gets bumped.  Could be the final element of an array sized COLS*ROWS+1 or its own variable.

My concern with read-modify-write is that with both threads running, it would read a large value in order to increment it, and while modifying it the other thread would change the pointer, and it would write the large value to the fresh empty array.  If somewhat remember reading that ARM had a way to deal with this in one instruction so it wasn't an issue.

[alank2]

If cpu core speed is an issue, another idea is to create a ringbuffer of the cpu registers and state needed to recreate the display the way that set led's does.  The cpu thread could feed these states into the buffer with its own pointer and the display thread could read/process them using its own.  This further abstracts the cpu core simh thread from the display as the display thread would be doing all the the display stuff.  Lots to try.

[Warren Young]

On Friday, January 27, 2017 at 4:17:01 AM UTC-7, alank2 wrote:

I'm happy to do it, but it will have to wait until next Wednesday.

I'll probably beat you to it, then. If not tonight, then over the weekend.

If you're looking for a project, there are plenty of filed tickets. :)

[Warren Young]

On Friday, January 27, 2017 at 4:22:27 AM UTC-7, alank2 wrote:

It only needs one count, not one for each LED.

I don't see your logic. Each LED must have a separate brightness, because each LED has a different history.

There is a separate "one counter only" case: the count of PDP-8 instructions executed since the last display update, held in pdis->inst_count in my design above.

It may be possible to do without this variable, since it should always have the same value as the counter for the Execute LED.

That brings up an interesting subtlety: we'll have to divide the LED brightness values for Fetch and Execute in half, because we know they can be "on" for half of the instruction time at most. All the other LED values are updated at some basically constant delay from the instruction clock edge, so they can reach 100% brightness.

I'm not sure which class Pause is in: half-instruction or full-instruction?

Each time the set led's function is called, the total count gets bumped.

Are you suggesting that we break set_pidp8i_leds() up so that each LED gets a separate update function? I see no reason for that.

We should indeed break up set_pidp8i_leds(), but not that far. Without studying it, my initial feeling is that it should be broken up into per-register functions. (e.g. set_pidp8i_mq().) I'm sure part of the current slowdown is that we're updating all of the ledstate[] values multiple times in the PDP-8 simulator CPU instruction decoding loop, when each call can update only part of the panel, the rest not having changed since the prior call.

Some of the LEDs over on the right side of the display may get their own function, if we see that they're always updated separately. set_pidp8i_run() seems plausible, for example.

I may break up the current linear "all LEDs in a 96-integer array" representation so the C data structure more closely resembles the panel. The tricky bit is deciding whether to represent it as it physically appears to the end user so the code is easy to read or to rearrange the data structure to match the mapping of GPIO pins to LEDs, so the code to translate between the representations runs fast.

Could be the final element of an array sized COLS*ROWS+1 or its own variable.

I don't see how that differs from the design presented above. COLS = 12, ROWS = 8, so we have led_on_count[96] + 1 for inst_count.

My concern with read-modify-write is that with both threads running, it would read a large value in order to increment it, and while modifying it the other thread would change the pointer, and it would write the large value to the fresh empty array.  If somewhat remember reading that ARM had a way to deal with this in one instruction so it wasn't an issue.

I'd never seen ARM assembly until today, and boy, what I shock I got. That link shows what `++num` compiles to, and it is not one instruction as I'd been assuming. I thought every processor since the PDP-11 had single-instruction increment instructions, if only for its native word size. Not ARM! Apparently this is how we get a processor clocked at around 1 GHz that executes code 10x slower than an Intel processor clocked at 2-3 GHz.

There is a solution to this problem. The DMB instructions you see in the assembly output are data memory barriers which force data access synchronization across cores. By varying the final parameter to __atomic_add_fetch(), you can control where the DMB instructions appear: both before and after the postincrement, as you see now, after only (__ATOMIC_CONSUME), or never (__ATOMIC_RELAXED). We might be able to get away with after-only, but I'll have to think more about this.

Along the way, I discovered that Intel also has this problem, even though it does have a way to express an integer postincrement in a single instruction. When you use __atomic_add_fetch() on Intel, it adds the LOCK restriction to the instruction, apparently so the microcoded behavior of the instruction completes before another thread can access that memory location. (Simple postincrement version.)

So, thank you for prompting me to investigate this, alank2. Non-atomic microcoded postincrement...who knew? (Answer: alank2, apparently.)

[Warren Young]

On Friday, January 27, 2017 at 5:50:36 AM UTC-7, alank2 wrote:

create a ringbuffer of the cpu registers and state needed to recreate the display the way that set led's does.  The cpu thread could feed these states into the buffer with its own pointer and the display thread could read/process them using its own.

I don't see how you can use a ring buffer, since the whole idea here is that we don't want to miss out on any past states. Each LED's brightness should reflect all of the changes to it since the last display update, else we get back into the same boat we're in now. That means you'd need to store the whole instruction history of the processor between each display update, which can span thousands of PDP-8 instructions.

Memory is cheap, but I think you'd end up trading CPU arithmetic cycles for memory manipulation cycles, to no net benefit.

[Len]

"I'd never seen ARM assembly until today, and boy, what I shock I got. That link shows what `++num` compiles to, and it is not one instruction as I'd been assuming. I thought every processor since the PDP-11 had single-instruction increment instructions, if only for its native word size. Not ARM! Apparently this is how we get a processor clocked at around 1 GHz that executes code 10x slower than an Intel processor clocked at 2-3 GHz."

Your example isn't necessarily a real-world situation, though. You're looking at a single standalone statement compiled "unoptimized". In a real function - and with the various optimizers turned on - it's possible that variable is already living in a register by the time that statement is executed (thereby getting rid of the leading particular ldr), and may never be copied back to RAM - thereby getting rid of the str. So the statement may actually compile to one instruction.

Debugging optimized ARM code can be "interesting", if you have to chase around thru the assembly code - it doesn't necessarily look like what you'd expect from the C code the compiler started with.

As far as not copying the updated value back to RAM: I ran into a bug on an ARM-based project several months ago because a file-scope variable used concurrently by 2 functions (one called by an interrupt handler) wasn't declared as "volatile" - when you built the code with any optimization, the second function - which ran a loop - never knew that the first function was updating the value, because the variable lived in a processor register during the execution of each function, and the updated value was never stuffed back into memory in either case. It wasn't necessary.

On Monday, January 23, 2017 at 11:30:45 PM UTC-5, Warren Young wrote:

I've just tagged the biggest release of the PiDP-8/I software yet:

• When any program that talks to the PiDP–8/I front panel starts up, it now prints out a banner modeled on the Erlang configuration line. Real-world examples:
  
  PiDP-8/I trunk:i49cd065c [pi3b] [ils] [serpcb] [gpio]
  PiDP-8/I release:v20170123 [cake] [nls] [nopcb] [rt]
  
  
• The ILS feature can now be disabled at configure time via the new --no-lamp-simulator flag. This option is automatically set when building on a single-core Raspberry Pi. (The flag is there only to allow someone building the software on a multi-core host machine to disable the ILS. There is currently no easy way to force the use of the ILS on a single-core Pi, on purpose.)
  
• Tweaked the ILS decay constants to be asymmetric, better mimicking the way real incandescent lamps work: they heat up to full brightness faster than they fade to perceptively “off.”
• The LED values used by the GPIO thread were being recalculated way too often. They're now updated only about 100 times a second, with the rate continually adjusted based on the simulator's current execution speed.
• In prior versions, the ILS was only updating at its intended rate when the PDP–8 simulator was running flat-out on a current multi-core Raspberry Pi. If you throttled the SIMH simulator to a slower execution rate, the display quality would start to degrade noticeably below about 1 MIPS.
  
• With the prior fix, we now ship 5.script (i.e. the handler for starting the simulator with IF=5, or restarting it with IF=5 + SING_STEP) set to a throttle value of 30 kIPS, which allows the human to see each AC/MQ modification. The built-in delay loops are still there, else we’d have to drop this to well under 1 kIPS.
• The SING_INST switch now immediately puts the processor into single instruction mode, not requiring a separate press of the STOP key, as in prior versions. This is the correct behavior according to the 1967–1968 edition of DEC’s Small Computer Handbook for the PDP–8/I.
• Greatly simplified the way single-instruction mode, processor stoppage, and the CONT key work. The prior implementation was error-prone and difficult to understand. This fixes a particularly bad interaction between the way HLT instructions and CONT key presses were handled, causing the processor to not resume correctly from HLT state.
• Consolidated and cleaned up the bulk of the PiDP–8/I switch handling code so that it is not so intimately tied into the guts of the PDP–8 CPU emulator. This will greatly increase the chance that future updates to the upstream SIMH PDP-8 CPU code will apply cleanly to our version.
• Fixed a bug in examples/bit-rotate.pal which caused it to skip the actual bit rotation step. We were trying to microcode two instructions into one that the PDP–8 won’t accept together, and we didn’t catch it until now because the HLT bug masked it, and the palbart assembler we ship isn’t smart enough to notice the bug.
• Fully generalized the mechanism for generating obj/*.lst, bin/*.pt, and boot/*.script from examples/*.pal. You can now drop any PAL assembly language program into the examples directory and type make to build these various output forms automatically using the shipped version of palbart. This effectively turns this PiDP–8/I software distribution into a PDP–8 assembly language development environment: rapidly build, test, and debug your PAL programs on your PC before you deploy them to real hardware. Or, write PAL programs to debug the hardware or simulator, as we did with examples/bit-rotate.pal.
• Fixed a sorting bug in the tool that generates boot/*.script from obj/*.lst, resulting in dep instructions that weren’t sorted by core address. This didn’t cause any real problem, but it made tracing the execution of a PAL assembly program difficult if you were trying to refer to the boot/*.script file to check that the PiDP–8/I’s front panel is showing the correct register values.
• Updated SIMH to the latest upstream version and shipping a subset of the SIMH docs as unversioned files from tangentsoft.com.
• The configure script now aborts the build if it sees that you’re trying to build the software as root, since that means it generates the init script and the pidp8i script expecting to run the installed software as root, not as your normal user. The most common way this happens is that you have a configured source tree, then change one of the *.in files and say sudo make install, thinking to build and install the change in one step. This fixes that.
• Several improvements to the build system.

As always, you may download it here.

[Warren Young]

On Friday, January 27, 2017 at 2:55:25 PM UTC-7, Len wrote:

"I'd never seen ARM assembly until today, and boy, what I shock I got.

Your example isn't necessarily a real-world situation, though.

Here's a more realistic one: https://godbolt.org/g/0Qt0Ap

It shows a global data structure, which gets around your argument that it could be registerized, and it's built using the default build optimizations of the PiDP-8/I software project. Also, it shows both alternatives side-by-side, so you can compare the assembly code.

I ran into a bug on an ARM-based project several months ago...

It sounds like you would be a valuable technical reviewer, then. I hope you will look over my changes when they become available.

Do you have any thoughts on which memory model suits the design better? Do I really need the full sequential consistency model, or can I get by with one of the less restrictive ones, since the code will be structured in a simple producer-and-consumer pattern?

[Marty]

Hi All;

Warren, I have put This Release on the SD and I have tried to boot it..

It Mostly boots but it doesn't look or act right (to me)..

After all of the screen lines for it to be built, I do an enter and I get the base directory..

/bin, etc,..

It does not ask for a Login nor for a Password, which makes me think that there is a problem..

This is on another PiDP8 that I got from Oscar which is for a Late Christmas Present, What I would like to do is to be able to run Pidp8i-test, to "test" all of the switches, I have had Deep Thought 2 on another SD, so it acts like all of the Led's are OK..

I have tried many of Your Sudo commands and mostly it tells me there is a problem or I need to set up the Login and Password..

Or when I do a .configure it says that the Log file is Read only.. Etc..

Or do I need to go to an Older SD file to make it work..

This is with a Raspberry pi A+ unit.. 

THANK YOU Marty

[Warren Young]

On Friday, January 27, 2017 at 5:09:20 PM UTC-7, Marty wrote:

After all of the screen lines for it to be built, I do an enter and I get the base directory..

/bin, etc,..

I have no idea what you mean by that. Maybe you could send a screenshot or something?

Troubleshooting by remote control is about as difficult as artistic painting by remote control. Help me help you.

It does not ask for a Login nor for a Password

That can't be one of my OS images, then. I have never produced a Raspbian OS image that will boot to a shell command prompt, on purpose.

 

What I would like to do is to be able to run Pidp8i-test

Perhaps I am just being pedantic, but just in case, it is important that you enter commands in the proper case. Linux is case-sensitive. There is no command called "Pidp8i-test". There is one called "pidp8i-test".

Anything you've done on the Pi side in attempting to get this going where you've been careless about transcribing commands exactly could be a relevant failure point.

 

I have tried many of Your Sudo commands and mostly it tells me there is a problem or I need to set up the Login and Password..

The front page of my PiDP-8/I site gives the default user name and password for the OS images I have produced. It also informs you that it will insist on a password change on first login, So:

1. Have you logged in as user pidp8i with the given password successfully?

2. Did you change the password?

3. Are you using that password for pidp8i logins now, or are you continuing to use the one on my site?

Or when I do a .configure it says that the Log file is Read only.. Etc..

You don't have to re-configure and rebuild the software if you're using one of my pre-built OS images unless you've also done the "fossil update" step, and that won't change the contents of the SD card unless you've added some kind of network adapter and it's connected to the Internet.

I've just re-imaged an SD card here with the current single-core OS image, did a "fossil update && ./configure && make" and got no complaints about read-only log files.

Therefore, either you're not using one of my OS images, or one of your prior sudo commands has made files formerly writeable by you as owned by root, so now you can't write to them.

If this SD card doesn't contain anything precious to you, I suggest that you overwrite it with the current image again, following the Raspberry Pi Foundation's installation instructions carefully, then take careful notes about the steps you've taken so that you can copy them here if it doesn't work out again.

You may be interested to know that I expect to make new OS images when I release the next version of the software. I was going to do it for the current version, but then all this stuff about display imperfections hit, and I decided I didn't want to bake that into an OS image.

Or do I need to go to an Older SD file to make it work.. This is with a Raspberry pi A+ unit.. 

You want the OS image marked "Single-core version" on my site.

I do not have a Pi A+ here to test with, but I also have no reason to believe my images won't work on an A+. Maybe someone else who has actually tried it could chime in, whether successful or not.

The prior version of the OS images are still available online. Here's the direct link to the prior single-core OS image:

   https://tangentsoft.com/dl/pidp8i-2016.12.18-nls-jessie-lite.img.zip

I'm not recommending that you step back to it, but it's there if you want to try it.

[Marty]

Hi Warren;

Thank You for Your Reply..

"" I have no idea what you mean by that. Maybe you could send a screenshot or something? ""

I cannot do screen shots..

What I meant was the shell command prompt, I just could not remember what it was called..

I know about Capitals and small letters with Linux, but when I type here I may insert something with Caps for Emphasis..

I used -- pidp8i-2017.01.16-nls-jessie-lite ..

"" 

The front page of my PiDP-8/I site gives the default user name and password for the OS images I have produced. It also informs you that it will insist on a password change on first login, So:

1. Have you logged in as user pidp8i with the given password successfully? ""

First, Since it doesn't ask me to log in, nor for a password..

So, ""  It also informs you that it will insist on a password change on first login, ""

How, do I do this, when It doesn't do a login ??

"" You want the OS image marked "Single-core version" on my site. ""

That is what I tried to use..

I will Reboot the Pidp8 and let You know, what it shows..

THANK YOU Marty

[Warren Young]

On Friday, January 27, 2017 at 7:44:11 PM UTC-7, Marty wrote:

I used -- pidp8i-2017.01.16-nls-jessie-lite ..

I decided to re-image my SD card again, this time after zeroing it with the SD Association's formatting tool, and this time I'm seeing the problem! Previously, I'd been re-imaging the NLS version over the top of the ILS version, so something about the way the ILS card is written makes the NLS version work.

I would not recommend trying to get your NLS image working by downloading the ILS version, and double-imaging it the way I've been doing it. Instead, just step back to the early-January release, or wait for the upcoming one. If you can wait, that's the better path.

Those reading this who have networking on their single-core Pis have another option, which is to use the older OS image and then do a Fossil update and rebuild. (This is what alank2 did recently, which I am only now understanding the reason for.)

To try and prevent this from happening again, I've got a Pi B+ and a second 2 GB SD card on the way. Then I'll have one setup for single-core images, and another one for multi-core images.

[Marty]

Hi Warren;

THANK YOU so very much, for finding and verifying that I wasn't making it up, and for all of the Trouble that I have put You through..

I will find the Previous Release and try that, Thank You..

And Thank You for Your Patience and persistence with me.. 

Also, where or How do I find the previous Releases on Your site to download ??

When I go to a Notice of a Previous release here, and go to that link and it goes to the Latest Release and not an older one..

Last, but not least, I found Your Pictures of Your Machine and it Look Really Nice, You did a great Job on the Switch and Connectors !!

THANK YOU Marty

[alank2]

>I don't see your logic. Each LED must have a separate brightness, because each LED has a different history.

If the set led's function is called at the end of each instruction and it is responsible for taking the processor state and setting the led status based on it, then aren't all led's in the same boat at this instant?  They are on or off all together, right?  In this case you just need a single counter for the number of calls to set led's.

[Warren Young]

On Saturday, January 28, 2017 at 11:22:20 AM UTC-7, alank2 wrote:

>I don't see your logic. Each LED must have a separate brightness, because each LED has a different history.

If the set led's function is called at the end of each instruction and it is responsible for taking the processor state and setting the led status based on it, then aren't all led's in the same boat at this instant?  They are on or off all together, right?  In this case you just need a single counter for the number of calls to set led's.

Sure, but that doesn't mean I don't need a separate brightness counter for each LED. And as I pointed out above, I don't even need to keep the 'total instructions executed" value separately, because that will always be equal to the bump count for the Execute LED, since that's blinked once per instruction.

So, I can do what you want, but I don't see what it gets me. 

[Len]

I don't tend to think in terms of CS theory generally so maybe I'm over-simplifying here, but as long as the consumer (display) side can keep up with what's being produced, I'd just start out with double buffering the data if at all possible - I'm not sure you'll even need a mutex, just make sure the display side knows which data buffer it's allowed to access.

If the display side is just reading a single block of data being created on the SIMH side, how critical is it if some of the data (I'm not sure what a realistic value for "some" is) is off by an instruction cycle or so? Or - if data is being buffered - a buffer is processed twice by the display side if it misses the SIMH side updating the buffer index?

(edit: I hope the above makes at least some sense - I'm dealing w/a kidney stone right now (a real one, not just software that acts like one), but I wanted to try to keep up here)

[Warren Young]

On Sunday, January 29, 2017 at 10:58:20 AM UTC-7, Len wrote:

On Friday, January 27, 2017 at 6:44:17 PM UTC-5, Warren Young wrote:

Do you have any thoughts on which memory model suits the design better? Do I really need the full sequential consistency model, or can I get by with one of the less restrictive ones, since the code will be structured in a simple producer-and-consumer pattern?

I don't tend to think in terms of CS theory generally so maybe I'm over-simplifying here, but as long as the consumer (display) side can keep up with what's being produced, I'd just start out with double buffering the data if at all possible

That's pretty much where I ended up earlier this a.m. I convinced myself that because it's strictly producer-consumer and that the consumer is in control of the timing of the pointer swap changing which of the two display buffers is being written to, that only the pointer swap needed to be atomic.

There is one other subtlety, which is that the producer has to make a copy of the pointer into the display buffer when it starts updating it, so that if the consumer swaps it, it finishes updating the display it started updating, and doesn't spread its updates over both buffers.

Bottom line: it works well! I have yet to see a glitch that I could ascribe to playing fast-and-loose with the data sharing policies.

how critical is it if some of the data (I'm not sure what a realistic value for "some" is) is off by an instruction cycle or so?

The worst case is that you're running a heavily-throttled simulator that only does a few (or even 1!) updates per second, so that if there is a synchronization problem, you get a blip in the data because some of the LEDs have an unfairly greater share of "brightness" than the others. (Or vice versa, LEDs that should be brighter than they are are momentarily dim.)

I have yet to see such a thing.

I'm dealing w/a kidney stone right now

Well, then I retract my implicit request that you review the code. Unless you want to. :) 

[Marty]

Hi All;

Warren,

Have You had time to fix the problem for the Single Pi Version, so I can use it ??

If Not Do You have some kind of Idea of when You will be able to get to it, eg. like a week or two two weeks etc..

That way I can figure out what I need to do, to Test my PiDP8.. 

[Warren Young]

On Tuesday, January 31, 2017 at 7:42:02 AM UTC-7, Marty wrote:

Have You had time to fix the problem for the Single Pi Version, so I can use it ??

Time is exactly the problem. It takes 2-3 hours to spin a new set of OS images, which is 2-3 hours I could spend clearing away the issues blocking the next release.

My intention all along was to finish the next release and make OS images for it, rather than go back and re-spin OS images for an old version of the software. That could happen as early as later today, but that's only if my testing doesn't turn up any new problems that need to be solved:

1. Compare the current ILS and NLS implementations to the prior stable releases. Are all the changes improvements or neutral? If not, decide whether they have to be fixed before release.
2. Try THROTTLE values below 30k. Is there a point where the behavior breaks down, particularly in the ILS code? If so, maybe fall back to NLS mode at low throttle values.

If someone wants to do these while I'm away at $dayjob, that could shorten the time to next release.

There is also one high- or immediate-priority bug left to fix, that being the threshold I set for allowing a release.

That way I can figure out what I need to do, to Test my PiDP8.. 

Why do you need to wait for the next release to do that test? The current single-core binary OS release link points at the prior release, v20161218, by which point pidp8i-test had been integrated into my software distribution for about 2 weeks. There haven't been any behavioral changes at the end user level to pidp8i-test since then.

I thought you were running this version now, and were only waiting on me to upgrade to something more recent for its own sake, not because you needed me to release the next version before you could proceed.

[Brandon Himoff]

I tried test 2 in ILS at throttle 30k and got blank registers, but 50%ish intensity on Fetch and Execute. 300k throttle same behavior. Nothrottle returns it to normal.

[Brandon Himoff]

Actually I am not sure nothrottle turns it back to normal when I tried it a second time.

[Brandon Himoff]

On the second session the throttle was set to 30k in the initialization script. This worked well and continued to work well down at 1k (AFAIK since I have never used a real PDP8). It also worked when it was returned to no throttle.

On the third session there were some issues. With no throttle set in the script and using CNTL-E to escape to SIMH the throttle was set to 30k. In this case the registers remained blank. They stayed blank when the throttle was changed to 1k and returned to proper functioning when set to no throttle, and worked properly for trottle 30k after that. It would help to have someone also also test for this anomaly.

It would be ideal at some point i f the time constants were faster on boot so the lamps were on a bit earlier. It would also be quite helpful of the screen froze with the correct register display when SIMH is escaped with CNTL-E.

Thanks for all these improvements!

Brandon

[Marty]

Hi All;

"" Why do you need to wait for the next release to do that test? The current single-core binary OS release link points at the prior release, v20161218, by which point pidp8i-test had been integrated into my software distribution for about 2 weeks. ""

I Don't know Where nor How to get V20161218, to put on my SD Card..

When I go to the Posted Release all I get is the current one from 20170123..

THANK YOU Marty

[Warren Young]

Before I get to the specifics inline below, I just wanted to thank you for testing and reporting on your results.

Programmers shouldn't be expected to be the sole (or even primary) tester for their own work product. We're too close to the code: we know what it's supposed to do and how, so we don't do weird things to it, because why would we? We need people with different perspectives and no warm feelings toward the code that was just written. People who will be mean to the software. Make it cry.

Thank you for being cruel to my software. :)

(I once heard a story of a dedicated software testing group inside a company where the testers all grew Van Dykes — they were all men — and would twirl them evilly when they reported their test results to the developers.)

On Tuesday, January 31, 2017 at 5:00:04 PM UTC-7, Brandon Himoff wrote:

On the third session there were some issues.  With no throttle set in the script and using CNTL-E to escape to SIMH the throttle was set to 30k.  In this case the registers remained blank.

When you make such a large downward shift in the instruction rate, the software ends up needing to clock through its delay values at the slower rate. Cut instruction rate by 100x, and it now takes 100x to get through the delay values in the worst case. (Half that if you were halfway through the current delay at shift time, etc..) This can take a LOOONG time to get through. As currently written, the code needs to go through another few iterations to figure out the new instruction rate.

Unfortunately, it isn't easy to just ask the simulator its current throttle rate. It's available, but it isn't always accurate, which adds further problems.

 

It would help to have someone also also test for this anomaly.

I don't see any need for that. I just somehow need to be able to get the code to realize quicker when this has happened and reset its prior state.

Fixing the throttle shift mid-stream may not be a thing I want to hold the release for, since it sounds like there's a straightforward workaround: stop the simulator, set a new value in the boot script, and restart. But, we'll see how hairy the problem looks when I get in there.

 

It would be ideal at some point i f the time constants were faster on boot so the lamps were on a bit earlier.

That's fixable, but I won't be holding the release to do it. If someone else wants to try and slide that feature in before release, patches are always thoughtfully considered, if not always accepted. :)

 

It would also be quite helpful of the screen froze with the correct register display when SIMH is escaped with CNTL-E.

Now that I will try to fix before release.

[Warren Young]

On Tuesday, January 31, 2017 at 6:18:38 PM UTC-7, Marty wrote:

I Don't know Where nor How to get V20161218, to put on my SD Card..

Click the "Single-core version" link on the front page of my site.

[Marty]

Hi All;

Thank You, Warren !! I got it and it works, I got Login and Password..

My only Complaint is that it wants lengthy Password, when I changes it from Your Password to my password, which I tried to have it be pidp8i, it complained it was too short and rejected it..

If it was me I would have a CR for a Password, I mean it's only a Pidp8..

And I know who EdsonDeCastro is and You having Him as Your Password for a pidp8, that is Classic..

I have a very good Friend who has and collects both Software and Hardware for Data General machines, and has two pdp8's, one an 8i and the other is an 8a..  

Who know's You might even know Him..

Did You Ever work for either DEC or Data General ??

THANK YOU Marty

[Warren Young]

On Tuesday, January 31, 2017 at 8:03:58 PM UTC-7, Marty wrote:

it complained it was too short and rejected it..

I haven't tightened the Raspbian password policies down from their defaults. This is what the Raspberry Pi Foundation endorses, not me.

I'm sure they're adjustable, but I think I'll trust that they know what they're doing here.

If it was me I would have a CR for a Password, I mean it's only a Pidp8..

It's not "only" a PiDP-8/I. It's a full-powered computer, capable of anything computers could do 10 years ago, which was a lot. You're asking me to help you set it up naked on your network, maybe even with a wifi radio, so it's even easier to get into undetected?

Sorry, but no. You are free to disable all of the security protections on my images, or you can find someone else to provide unsecured OS images. I will not be providing such things.

You might want to read up on island hopping.

Did You Ever work for either DEC or Data General ??

I could barely spell PDP a few months ago. 

[Warren Young]

On Tuesday, January 31, 2017 at 8:30:44 PM UTC-7, Warren Young wrote:

You're asking me to help you set it up naked on your network, maybe even with a wifi radio, so it's even easier to get into undetected?

I'm now recalling that you're the one with the Pi A+, so there is no network?

If so, my answer remains the same, because I'm not going to make specialty OS images with no security for non-networked PiDP-8/Is. It's enough work putting out two OS images. I'm not adding a third.

This is highly flexible open source software. Changing the password policies, disabling the login, and more is all possible, if you're wiling to learn how. It's all a Google search away.

[Warren Young]

On Tuesday, January 31, 2017 at 5:00:04 PM UTC-7, Brandon Himoff wrote:

It would also be quite helpful of the screen froze with the correct register display when SIMH is escaped with CNTL-E.

That's done now.

I've also fixed the problems with the display blanking on STOP and SING_INST.

I did not get time to test changing throttle values mid-sim. As I said earlier, if this still happens and it isn't easy to fix, I think I'll just file it as a low-priority bug and push the release out.

I also didn't get around to testing with my new Pi B+, if only to see if I can get away with allowing ILS to build on single-core CPUs again.

We're down to about 6.7 MIPS on a Pi 3, and the last hour of investigation didn't turn up any easy culprits.  That's still fast enough not to block the release. In fact, it's faster than v20170123.

[Marty]

Hi All;

Thank You for Your Reply, No I was not asking You to make another Distro, I was just complaining about having any Password..

You are Doing a Great Job, and keeping up with everything else..

"" This is highly flexible open source software. Changing the password policies, disabling the login, and more is all possible, if you're wiling to learn how. It's all a Google search away. ""

I am still trying to Understand PDP8 code, not to say anything about something as complicated Linux programming.. But, yes, as You say it's all there..

THANK YOU Marty 

[Brandon Himoff]

I tested a bit and it seems better. It is showing the register when escaped at the SIMH prompt. When you "cont" to resume the registers goes black for an extraordinarily long time at throttle 30k, but this is not a showstopper. Presumably this is the same delay as at startup. There could be a future fix that presets the running LED state with the LED state during the halt. This should match the real hardware.

[Brian R]

Sorry to say that I seem to have found a bug.

I updated via fossil, all went smoothly, but now I'm unable to enter any code via the panel switches.

'Load Add',"Dep' & 'Exam' do nothing. (Yes, I did press 'Stop' first.)

I thought It might be a hardware problem, although running the pidp8i-test showed that the Pi, the LEDs and all the switches were responding correctly.

Next, I swapped the SD card in the Pi (Pi 3) with another running release 2017/01/16, and all was working properly. I could enter code OK.

So, I then did a new install of Jessie on a new card, ran update and upgrade, then installed this release from the fossil repo.

Again, the software installed perfectly, but again, I can't use the panel switches to enter code.

Everything else seems to be working OK 

[Marty]

Hi All;

I have been able to Run the pidp8i-test program and it Passes completely..

Which means that I now know that all my Switches are OK along with all of my Led's..

Which is what I was trying to do..

Thank You Warren for updating the link to the correct Version, I am Happy now..

THANK YOU Marty 

[Brian R]

EDIT. I have just reverted to an earlier release (pidp8i-6888919960.tar.gz) and now I can enter code from the panel again. 

However, I'm now unable to directly launch OS/8 by typing 'pidp8i'. 

I'm confused (it doesn't take a lot!)

[Warren Young]

On Wednesday, February 1, 2017 at 5:23:29 AM UTC-7, Marty wrote:

"" This is highly flexible open source software. Changing the password policies, disabling the login, and more is all possible, if you're wiling to learn how. It's all a Google search away. ""

I am still trying to Understand PDP8 code, not to say anything about something as complicated Linux programming..

This would fall under system administration, not programming. The password policies are controlled by the PAM system, for example. 

[Warren Young]

On Wednesday, February 1, 2017 at 6:30:02 AM UTC-7, Brandon Himoff wrote:

When you "cont" to resume the registers goes black for an extraordinarily long time at throttle 30k

This is with the latest code on the led-counters branch? Are you trying something like 5.script, which has this throttle value set from the start?

I've just tried it here on my Pi 3, and the display resumes immediately from "c". There isn't even a brownout.

 

Presumably this is the same delay as at startup.

If you mean the 2 seconds of blankness, then no. That's a one-time delay, outside of any "running" loops.

If you mean the "brownout" delays while the simulator timer comes into regulation, that also makes no sense, since the throttle value isn't changing, so pre-Ctrl-E timing values still hold after "c". (Unless you aren't telling me something.)

 

There could be a future fix that presets the running LED state with the LED state during the halt.

I believe it already does that.

If you're still having trouble, give me a step-by-step test case. You might also want to include the "PiDP-8/I" line you get when the simulator starts. It should look something like this:

    PiDP-8/I led-counters:id[431f01b0] [pi3b] [ils] [serpcb] [gpio] [rt]

EDIT: If you aren't starting the simulator via "bin/pidp8i-sim", but instead via the init script and attaching via "pidp8i", it should be at the top of the screen session, before you get into OS/8 or whatever if you have more than 25 or so lines on the terminal. If it's scrolled off, you can say Ctrl-A Esc and run the cursor up into the scrollback area.

[Warren Young]

On Wednesday, February 1, 2017 at 7:22:42 AM UTC-7, Brian R wrote:

Sorry to say that I seem to have found a bug.

I updated via fossil, all went smoothly, but now I'm unable to enter any code via the panel switches.

I see it, too, but only on the trunk. It works fine on the led-counters branch.

While I could investigate to find and fix the problem, since led-counters is going to be merged into trunk soon, I'm not seeing a particularly good reason to spend the time.

Thank you for testing.

[Warren Young]

 So what does happen when you say that?

I just built and installed that version here, and it does start with the systemctl command, and the pidp8i command does attach to the simulator's screen(1) session.

Your IF switches aren't set to anything when you (re)start the simulator, are they?

[Brian R]

On Wednesday, February 1, 2017 at 7:14:57 PM UTC, Warren Young wrote:

On Wednesday, February 1, 2017 at 11:41:10 AM UTC-7, Brian R wrote:

On Wednesday, February 1, 2017 at 2:22:42 PM UTC, Brian R wrote:

EDIT. I have just reverted to an earlier release (pidp8i-6888919960.tar.gz) and now I can enter code from the panel again. 

However, I'm now unable to directly launch OS/8 by typing 'pidp8i'. 

 So what does happen when you say that?

I'm being asked for the password for user 'pidp8i',     AFAIK, no such user has been setup, (and no passwords are accepted anyway). 

I just built and installed that version here, and it does start with the systemctl command, and the pidp8i command does attach to the simulator's screen(1) session.

 

OK, well I've moved on from that now, so I can't try again, but no worries, I've still got the (working) earlier release, and I'm will ing to wait for the merged release.

Your IF switches aren't set to anything when you (re)start the simulator, are they?

No, I made sure that all switches were in the default off position.

BTW, thanks for the help, and all the effort that you've put into this project.

[Brandon Himoff]

Starting with:

PiDP-8/I led-counters:id[e2113929] [pi3b] [ils] [stdpcb] [gpio] [rt]
PDP-8 simulator V4.0-0 Beta git commit id: 370cb0ed

The LEDs look great at throttle 30k when started in the script. The issue arises only when the throttle is set at the SIMH prompt. When you go from no throttle to throttle 30k the register LEDs are blank and stay blank for at least 15 minutes perhaps forever (Fetch and Execute are about 50% bright), regardless of the throttle in the script. This is very reproducible for me here.

Brandon

[Warren Young]

On Wednesday, February 1, 2017 at 6:16:18 PM UTC-7, Brandon Himoff wrote:

The LEDs look great at throttle 30k when started in the script.  The issue arises only when the throttle is set at the SIMH prompt.

Oh, I thought you understood: I didn't even try to fix this last night. I ran out of time doing other things. Therefore, it is no surprise that the symptom remains.

If I get it fixed tonight, it will be announced. 

[Warren Young]

On Wednesday, February 1, 2017 at 10:05:42 PM UTC-7, Warren Young wrote:

On Wednesday, February 1, 2017 at 6:16:18 PM UTC-7, Brandon Himoff wrote:

The LEDs look great at throttle 30k when started in the script.  The issue arises only when the throttle is set at the SIMH prompt.

If I get it fixed tonight, it will be announced. 

I won't declare victory yet, but I've just checked in a change on the led-counter branch that should solve this problem. It seems to solve it in my brief testing here. 

[Brandon Himoff]

Warren,

Actually I knew you hadn't gotten there yet, but I thought my original bug report was slightly flawed and incomplete. It looks like it is all fixed now. I hope you are getting enough sleep! I'll see if I can find anything else, but nothing broke yet.

Thanks,

Brandon

[Warren Young]

On Thursday, February 2, 2017 at 5:27:50 AM UTC-7, Brandon Himoff wrote:

It looks like it is all fixed now.

Glad to hear it.

 

I hope you are getting enough sleep!

As I said earlier, "Intermittently." :)

 

I'll see if I can find anything else, but nothing broke yet.

 I might as well announce this here: the next release is imminent. All known high- and immediate-priority bugs are fixed, all immediate-priority features are implemented, and all necessary tests have been done at least once, by me.

Consequently, I've integrated the led-counters branch into trunk. I'm going to give y'all 12-24 hours to bang on it, and if no showstoppers turn up, it'll be released. 

Preliminary ChangeLog

[Brian R]

OK Warren, I can now enter code on the SR. Thanks ;-)

I've found one thing, running pidp8i-test gives no display at all, but does respond to SR changes.

After the first 'turn on all LEDs', it junps straight into SR testing.

pi@raspberrypi:~ $ sudo systemctl stop pidp8i

pi@raspberrypi:~ $ pidp8i-test

PiDP-8/I pkg:vUNKNOWN [pi3b] [ils] [stdpcb] [gpio] [rt]turn on ALL LEDs

Reading the switches.  Toggle any pattern desired.  CTRL-C to quit.

0100 0000 0000 

0000 0000 0000 

0100 0000 0000 

0000 0000 0000 

0040 0000 0000 

0000 0000 0000 

^Cpi@raspberrypi:~ $ ^C

pi@raspberrypi:~ $ 

[Warren Young]

On Thursday, February 2, 2017 at 7:38:04 AM UTC-7, Brian R wrote:

I've found one thing, running pidp8i-test gives no display at all, but does respond to SR changes.

Oooh!  I forgot that I had to ifdef its code out while redesigning the NLS mechanism.

I've reworked the program to work with the NLS GPIO module again. I did a bit of a style update on it while in there.

Let me know if the new version does what you want now.

This resets the release counter again, so maybe tonight, maybe tomorrow, if there are no more showstoppers.

[Brian R]

Thanks Warren. Everything seems to be working as it should now.

I see that in the pidp8i-test, the column and row LED test is much faster. An improvement I think.

Some might think that the pidp8i-test is of minor importance, but a new kit builder probably needs that function to verify that all is well with their hardware.

Righto then, a quick game of 'Adventure' or 'Wumpus' and the some coding practice for me now.

Have a good day :-)

[Warren Young]

On Friday, February 3, 2017 at 5:17:19 AM UTC-7, Brian R wrote:

I see that in the pidp8i-test, the column and row LED test is much faster. An improvement I think.

Arguable, I'm sure. The new speed is what I want, but if you're trying to debug things, maybe not what you want.

The window for comments is open. :)

You'll also notice a different treatment of whitespace in the console output, and the progress dots while waiting.

I've thought of a different way for it to interface with the NLS module which would simplify the test.c implementation to be more like the way it was before, so it's definitely getting another code pass before release.

[Bob]

On Friday, February 3, 2017 at 7:32:18 AM UTC-5, Warren Young wrote:

Arguable, I'm sure. The new speed is what I want, but if you're trying to debug things, maybe not what you want.

The window for comments is open. :)

  I think the most likely use of the test routine is just to check for bad solder joints on the LED's / switches after the kit is finished.  Tracking down row/column issues is probably more of an edge case?  And for that case I'm not sure the automatic stepping is all that useful.

So how about this for a U/I:

  - Turn on all LED's then stop and wait for a key press.  That allows plenty of time to look for a bad LED or fiddle with it

  - Then step forward through the current row / column test manually as the space bar is repeatedly pressed, or step backward if backspace is pressed

  - Skip to to the front panel switch test if the 'enter' key is pressed at anytime

 Right now I've got to wait for the LED test to finish even if I just want to check the switches.  And to troubleshoot a row/column problem I'd have to wait for the test signal to to cycle by all the rows/columns that are working, rather that being able to freeze it at the one that is acting up.

   This behavior could be selected with a command line switch, with the current mode the default. (Or vice-versa.)

  

   Thanks!

  Bob

[Warren Young]

On Friday, February 3, 2017 at 7:45:56 AM UTC-7, Bob wrote:

On Friday, February 3, 2017 at 7:32:18 AM UTC-5, Warren Young wrote:

Arguable, I'm sure. The new speed is what I want, but if you're trying to debug things, maybe not what you want.

The window for comments is open. :)

I'm not sure the automatic stepping is all that useful.

I think you're right. My motivation in shortening the delays is to get through the test in what -- to me -- is a more reasonable amount of time, but my own counterargument is that longer may be better. Your solution addresses both use cases.

So how about this for a U/I:

If I snug my thinking toque down real tight, I might be able to figure out how to accept right and left arrow keys.

This behavior could be selected with a command line switch

There's a fairly elaborate plan for giving pidp8i-test command options. We can certainly toss a few more carrots into the stew.

[Bob]

ouOn Friday, February 3, 2017 at 10:01:46 AM UTC-5, Warren Young wrote:

There's a fairly elaborate plan for giving pidp8i-test command options. We can certainly toss a few more carrots into the stew.

   Cool!  I'd been thinking about a feature request that could be better addressed there (actually, it's sort of *already* addressed there).

   I've made a little hack to your pidp8i-init routine to start Deeper Thought 2 if the I/F switches are set to 7 (rather than run 7.script).  That let's me start up DT without a terminal, but of course it makes the operation a little less flexible since I've lost 7.script, and it can get over-written by code updates, so it's a messy fix.

  I was thinking of asking for a 'user defined' button to be included in the start up switch test, like perhaps "Start", and pass that as a value to the pidp8i-init routine.  If the user defined key is pressed on startup then pipd8i-init would test for the existence of a defined script file (e.g. /usr/local/src/rc.9) and execute it if there.  

  My "start the blinky lights" case would be taken care of by the proposed in-built demo mode, but a scheme like the above might be useful users running other stuff on their Pi, so it may still be worth thinking about.

  A more flexible approach might be to pass the value of the whole switch matrix to the user script if the Start key was down at boot.  The user's script could then (optionally) do any number of things based on that value, or just ignore it if they only wanted a single action.

  (Arrow keys: +1!)

 

[Warren Young]

On Friday, February 3, 2017 at 10:15:39 AM UTC-7, Bob wrote:

  (Arrow keys: +1!)

You wanted arrow keys, you got arrow keys. See the trunk version. 

[Bob]

Thank you!