Can Productivity 2000 shift 8 button presses through an array?

A rolling 8-entry button history on a Productivity 2000 (P2000) CPU is one Shift Rotate Array (SRA) instruction on an 8-element integer array, not a FIFO. Each press loads a numeric code into the inflow position, the oldest entry falls out the other end, and the win condition is an element-by-element compare against a preset array. The wrong turns below cost the most time on this job, so they come first.

Skip the FIFO instruction for a rolling window

The P2000 FIFO instruction is a queue with separate push, pop, and peek operations, and a rolling window needs all three coordinated on every press once the queue is full. Push adds at the tail. Pop removes from the head. Peek reads without removing. To keep the last 8 entries you would test for full, pop the oldest, push the new value, then peek at each position to compare against the combination. That is why the instruction reads as overly complex for this job.

The requirement is a fixed-length sliding window: entering "ABABCDCB" and then pressing button 4 must yield "BABCDCBD". An array shift does the drop-oldest and insert-newest in one instruction and leaves every position readable by index, which the compare needs.

Keep the copy-and-move rungs only as a temporary restore

Discrete copy and math rungs that move data register to register work on P2000 and are backward compatible with Click, but they cost rungs. The existing programs carry roughly 40 rungs of copy and math that one SRA rung and one Array Statistics (STA) rung replace.

• Temporary restore: if the room is running tonight, leave the working copy/move logic in place and build the array version in a saved copy of the project.
• Permanent repair: move to arrays on P2000. Use copy/move rungs only for the Click version, where arrays do not exist.

Do not shift characters in a string array

SRA does not support string arrays, so storing "A" through "D" as strings and shifting them fails or is rejected. Store numeric codes in the array and convert to characters only for display.

1. Assign each button an integer code (button 1 = 1, button 2 = 2, and so on).
2. Shift and compare the integers.
3. Present them as A, B, C, D on the player-facing side.

The number-to-string conversion is the CPC instruction, and the numeric source must itself be an array element. Plan for that when you lay out the tags.

Treat the register as a one-dimensional array of 8 integers

An array is a block of same-datatype storage addressed by index, and no special logic sits behind it. On P2000 an array has one or two dimensions, read like spreadsheet columns and rows.

Every single item is a one-element array, so nothing changes conceptually when you widen it to 8. The array-aware instructions that matter here:

Resize the tag SRA creates before you trust any result

An SRA that throws error messages on a tag the software created for you is the signature of a 1x1 array tag. The software does not arbitrarily create arrays. When you accept the instruction as finished, it prompts you to create a tag for every name in a field that does not resolve to an existing tag, and the default is a single element.

1. Open the tag database and find the array tag, for example ARRAY_Button_Panel_Combo_Entered.
2. Set the array size to 8 elements in one dimension.
3. Set the datatype to an integer type wide enough for your largest button code.
4. Apply the same size and datatype to the preset array (ARRAY_Button_Panel_Preset_Combo) and to any outflow tag, such as DATA_Button_Panel_Outflow, so the fields stay type-compatible with the instruction.
5. Re-open the SRA and confirm every field resolves without an error.

Shift one position per button press

Drive the SRA from a single rising-edge trigger so each press moves the window exactly once, and load the inflow value before the shift executes in the same scan. The shift on every scan is the most common failure of a first attempt: without an edge, the button code fills all 8 positions within 8 scans.

1. Give each button its own rung that loads the inflow tag with that button's numeric code on the press edge.
2. Fire the SRA once per press from a common "any button pressed" edge placed after the load rungs. This also handles two buttons landing in the same scan without a double shift.
3. Set the shift direction so the oldest entry ends up in element 1 and the newest enters at element 8. Confirm the direction option in the SRA dialog by watching the array in the data view on the first press.
4. Route the outflow (the value pushed out of element 1) to DATA_Button_Panel_Outflow if you need it. The win logic does not need it.

A count-based alternative fills by index and then shifts. Use it only when the game needs to know how many presses occurred.

The requirement has no reset based on presses, so the always-shift design fits and needs no counter. The count-based design would break the stated 100-presses case at press 17 unless you add a reset.

Compare the two arrays with eight equal contacts

The compare stops being hard once you stop looking for a whole-array compare and test each position. Put eight equal-to contacts in series on one rung, one per element pair, and drive the win coil from the rung.

|-[ Entered(1) = Preset(1) ]-[ Entered(2) = Preset(2) ]- ... -[ Entered(8) = Preset(8) ]-( WIN )-|

Series contacts give an AND across all eight positions, so a single mismatch drops the rung. This form is also portable: on Click the same eight compares read eight data registers instead of array elements.

• Compare the entered array only against the preset array, never against a literal string.
• Copy Array moves the current combination into the preset array during the reprogram step. That part already works; the compare consumes its result unchanged.
• Put the win compare after the SRA in scan order so it evaluates the just-shifted array on the same scan.

Go past 10 buttons by keeping integers in the array

The 10-button ceiling comes from the character approach, not from the array. A character-per-button scheme holds one symbol per position, so a code of 10 or more needs two digits and no longer fits one position. The integer array has no such limit.

1. Store button codes 1 to N as integers in the shift array. Integer compares are exact for any N your datatype can hold.
2. Do the compare on the integers, as in the previous section.
3. For the player display, convert with CPC from an array element to a string, or map each code to a lookup character on the display side.

The integer array carries the two-digit values as single elements, which lets you go past the ten buttons of the character version.

Emulate the array on Click with plain copies

Click has no arrays, so the shift becomes a chain of copy instructions on consecutive data registers. Write the rungs so each source register is read before it is overwritten.

Rung A (press edge): Copy R2 -> R1
Rung B (press edge): Copy R3 -> R2
...
Rung G (press edge): Copy R8 -> R7
Rung H (press edge): Copy Inflow -> R8

Scan order runs top to bottom, so shifting from the oldest end first preserves every value. Reverse the order and every register ends up holding the newest value. Use a single one-shot for all eight rungs, load Inflow first, and finish with the eight-contact compare against eight preset registers. This is the same approach the old 40-rung programs already use, so it stays compatible with the Click version.

Bench-test the window before it goes back in the room

Test with the array open in the data view, not just the win output. Codes: A = 1, B = 2, C = 3, D = 4.

If the array shows the wrong length or the SRA faults on the first press, go back to the tag database and recheck the array size and datatype, then the shift direction.

FAQ