Expanding Magic-1 Microcode Store from 512 to 1024 Entries

Below is a detailed proof‐of‑concept explanation—complete with both conceptual microcode remapping and physical modification guidelines—for expanding the Magic‑1 microcode store (and its opcode set) from 512 entries to 1024. This explanation covers both the "program" side (that is, how the microcode encoding must be changed and how opcodes get expanded) and the "hardware" side (what minor changes are needed on the control card).

1. Background and Current Operation

In the original Magic‑1 design, each microinstruction is stored in one of several 512‑word EPROMs. The microcode control logic operates as follows:

• The opcode (an 8‑bit value read from the boot ROM or main program) is used to index microcode slots 0–255.
• For "routine" microinstructions (the next‐address field), an 8‑bit next address is available in the range 256–511.
• All individual bits in the microinstruction word are assigned to specific functions (register enables, ALU control, bus multiplexer selection, etc.). One bit—the so‑called PRIV bit—is active only in a few cases.

The author's email observes that if one could free one unused bit and reassign it as an extra "address extension" (EXT) bit, then the next address field in the microinstruction could be made 9­–bits wide rather than 8. That extra bit would allow addressing 1024 microinstructions instead of 512.

2. Proof‐of‑Concept: Expanded Microcode and Opcode Set

2.1. Microinstruction Field Remapping

Current Situation:

• The microinstruction word is 8 bits wide for the next‐address field.
• The next address is interpreted in two zones:
  • 0–255: Reserved to be indexed directly by the opcode.
  • 256–511: Used as the "branch" targets for microoperations.

Proposed Change:

• Repurpose the seldom‑used PRIV bit as an EXT bit.
• When EXT is 0, the next address is as before (i.e. in the range 256–511).
• When EXT is 1, the next address is formed by combining EXT with the existing 8‑bit next address field. In effect, appending EXT as the MSB yields a 9‑bit next address field, allowing access to addresses 512–1023.

This change not only doubles the microcode store—but it also provides a means to expand the opcode set.

2.2. Expanded Opcode Set via a Prefix Opcode

Because the original design used the low 256 microcode addresses (0–255) for opcodes, one can extend the opcode set by employing a two‑byte sequence (a "prefix opcode") as follows:

• Normal Opcode: Values 0x00–0xFE index directly into microinstruction addresses 0–255.
• Prefix Opcode:
  • A designated opcode value (for example, 0xFF) is reserved as a "prefix."
  • When the CPU fetches 0xFF, the next byte (fetched from memory) is treated as an extended opcode value.
  • This extended opcode then indexes into a new microcode region (for example, addresses 512–767).
• Microcode Branching with EXT:
  • Additionally, microinstructions whose next‑address field have EXT set can branch to addresses 768–1023.
  • This means the complete mapping in the 1024‑word space might be conceptually organized as:

Microcode Address Range	Function
0 – 255	Direct opcode table (standard instructions)
256 – 511	Microcode routines invoked by opcodes (and default branch targets)
512 – 767	Extended opcode routines (accessed via the prefix opcode 0xFF)
768 – 1023	Additional branch routines reachable via EXT‑bit setting

A "proof‑of‑concept" microcode sequence could, for instance, include a routine that tests the EXT bit to jump into the extended region and then dispatches operations from the expanded opcode set.

2.3. Example Microinstruction Remapping

Assume an original microinstruction format (simplified):

• Bit 7: PRIV (originally, now will become EXT)
• Bits 6–0: Next Address (0–127, used in a multi‑word scheme)

In the expanded scheme, suppose the microinstruction word is reinterpreted as follows:

• EXT Bit (new bit 7):
  • If 0 → next address is computed as: Next_Address = 256 + [bits 6:0]
  • If 1 → next address is computed as: Next_Address = 512 + [bits 6:0]

(Here, the exact numerical offset may be chosen to match the original mapping; the key point is that the EXT bit doubles the available address range.)

For the opcode prefix mechanism:

• An opcode of 0xFF is defined so that the following byte forms the extended opcode.
• The microcode memory is organized such that microinstructions for extended opcodes reside (for example) in addresses 512–767.

A test microcode routine might look like this (conceptually):

• Fetch Opcode:
  • If opcode ≠ 0xFF, jump to microcode address corresponding to the opcode value.
  • If opcode == 0xFF, then fetch the next byte and map this extended opcode into the extended opcode region.
• Routine Execution:
  • A branch instruction with EXT bit set jumps into the address region 768–1023 for extended functions.

This approach demonstrates the proof‑of‑concept for an expanded opcode set.

3. Hardware Modifications on the Control Card

3.1. Freeing A9 (Pin 24) of Microcode EPROMs

In the physical design, each microcode EPROM has a pin (A9, pin 24) that is currently permanently tied to ground. This effectively locks the microcode addressing to 512 words. To expand the address space:

• Modification:
  • On each of the five microcode EPROMs, remove (cut or desolder) the trace or jumper tying pin 24 (A9) to ground.
  • Instead, reconnect (wire‐patch) pin 24 so that it is driven by the EXT output signal from the microcode control logic.
• Impact:
  • With A9 now connected to the EXT bit, the address lines become 9‑bit wide when EXT is high, yielding a 1024‑word microcode space.

3.2. Reassigning the PRIV Bit and Adjusting the MISC Field

• Reassignment:
  • The PRIV bit (appearing in only a few microinstructions) is reassigned to become the EXT bit for addressing.
  • Its original functionality is then moved into an unused encoding of the MISC field in those microinstructions where it is needed.
• Conflict Resolution:
  • Note that there are a couple of microinstructions in which both the PRIV bit and a non‑zero MISC field were used. In these cases, the microcode must be rewritten (or re‑encoded) so that the functionality formerly provided by the PRIV bit is now provided by an alternate encoding.
• Programming Changes:
  • The microcode assembler must be modified so that it understands the new covering rules. It must now generate microinstructions with the additional EXT bit and support the opcode prefix mechanism.
• Verification:
  • A careful review of the microcode routines will show that all next‑address fields are now interpreted as 9‑bit values (using EXT as the MSB), thus proving the concept.

3.3. Minimal Versus Major Changes

• Physical Changes Required:
  • Cutting or desoldering the ground link for A9 and repatching it to the EXT line.
  • Possibly modifying wiring on the control card (the board that houses the microcode EPROMs) to reroute the signal.
• Programming Changes Required:
  • The microcode itself must be reassembled with the new instruction format.
  • The opcode decoder on the CPU will need to recognize the prefix opcode (e.g., 0xFF) and fetch an extended opcode from subsequent bytes.

In many cases, only a minor hardware change (freeing pin A9 and tying it to EXT) plus software updates (reassigning the PRIV bit functionality and rewriting microcode to avoid conflicts) are necessary. No major overhaul of the overall processor architecture is required.

4. Summary

Proof‑of‑Concept Highlights:

• Microinstruction Expansion: By repurposing the seldom‑used PRIV bit as an EXT bit and using the newly freed A9 (pin 24) of each microcode EPROM, you double the microcode address space from 512 to 1024 entries.
• Opcode Expansion: By introducing a prefix opcode (for example, 0xFF) to indicate that the following byte is an extended opcode (with microcode routines residing in the new address region 512–767), you effectively expand the processor's instruction set without massive hardware redesigns.
• Hardware Modifications: The only physical modifications needed are to remove the ground tie on A9 for each microcode EPROM and reroute that pin to the new EXT signal. In parallel, microcode software must be updated so that the EXT bit governs microinstruction branching and so that any conflict with the MISC field is resolved.
• Integrated Approach: With these minor physical changes on the control card and corresponding microcode modifications—plus updates to the microcode assembler—you can achieve a fully expanded microcode store and extended opcode set.

This proof‑of‑concept demonstrates both logically and physically how one might extend the Magic‑1 computer's microcontrol store and opcode space with only a few targeted modifications. It shows that minimal hardware changes combined with programmable microcode updates are sufficient to double the available microcode words and add a prefix‑based extended opcode mechanism.

Extended In-Depth Explanation

Below is an extended, in‐depth explanation—with both additional microcode–format details and explicit hardware modification instructions—that illustrates how the Magic‑1 computer's microcode store and opcode set can be expanded from 512 to 1024 entries.

1. Microcode Format Changes and New Opcode Expansion

1.1. The Original Microinstruction Scheme

Originally, each microinstruction in the Magic‑1 is organized so that its "next‑address" field is eight bits wide. In practice this works as follows:

• Opcode Indexing: When the CPU fetches an opcode (from the boot ROM or program memory), the opcode (an 8‑bit value) directly indexes microcode locations 0–255.
• Branching Within Microcode: The microcode instructions used for internal routines contain an 8‑bit address field indicating the next microinstruction to execute. In these routines, the hardware automatically adds an offset (for example, 256) so that branch targets fall in the range 256–511.
• The Role of the PRIV Bit: One bit in the microinstruction—called the PRIV bit—is almost always zero because its function (for handling privileged operations) is used in only a few cases.

Thus, with 8 bits dedicated to addressing, the complete microcode space is fixed at 512 words.

1.2. Expanding the Next Address Field

The key idea is to reclaim one bit currently used as the PRIV bit and reassign it as an "extended address" bit (EXT). In more detail:

• Reassigning PRIV → EXT:

  • The PRIV bit, used only sparingly, is redefined to serve as the high‑order bit of the branch address.
  • In practice, the next‑address field is now interpreted as 9 bits: the new EXT bit forms the most significant bit (MSB), and the existing eight-bit field forms the lower bits.

• Address Mapping:

  • When EXT = 0: The next address is, as before, calculated as: Next_Address = 256 + [7-bit field] (or in some implementations, the 8‑bit field might be used directly, with the known offset already hard‑wired in the control logic.)
  • When EXT = 1: The next address becomes: Next_Address = 512 + [8-bit field] This "doubles" the available address space to 1024 words.

• Microcode Remapping Example: Imagine a microinstruction originally encoded as:

  • Bit 7 (originally PRIV): 0
  • Bits [6:0]: 0x34 (52 decimal)

  In the classic design, its branch target is at address 256 + 52 = 308. In the new design, if a routine needs to branch into the extended space, the microcode assembler would emit the same lower field but set EXT = 1 so that the branch target becomes 512 + 0x34 = 564.

1.3. Expanding the Opcode Set via a Prefix

A second, very interesting opportunity arises. In the original design, opcodes (from 0x00 to 0xFE, for example) index directly into the lowest 256 microcode words. With the new hardware in place:

• Prefix Opcode Concept:
  • Reserve a special opcode value (commonly 0xFF) to serve as a prefix.
  • When the CPU sees the prefix opcode, it understands that the following byte constitutes an "extended opcode."
  • The extended opcode is then used to index into the newly available microcode region (for example, microcode addresses 512–767).
• How It Works:
  • This two‑byte sequence effectively expands the available instruction set without any radical change to the basic CPU design.
  • Microcode in the range 768–1023 or any other chosen segment can be dedicated to branch routines for extended opcodes.
• Resulting Mapping: For example, the overall microcode space (0–1023) can be organized as:
  • 0–255: Standard opcode routines
  • 256–511: Routine branch targets for standard opcodes
  • 512–767: Extended opcode routines (accessed via the 0xFF prefix byte)
  • 768–1023: Additional branch routines accessed by microinstructions with EXT=1

2. Hardware Modifications on the Control Card

To support the expanded next‑address field, the physical wiring must be adjusted so that the microcode EPROMs can actually address 1024 words. Here's how:

2.1. Freeing Pin A9 on Each Microcode EPROM

• Current Situation: In the original hardware, each microcode EPROM's address input A9 (commonly on pin 24) is hardwired to ground. This "locks" the overall addressing to 512 words.
• Proposed Change:
  • Desolder or Cut the Ground Connection: Carefully remove the solder bridge or cut the trace that ties A9 to ground on each of the five EPROMs used for microcode.
  • Reroute A9 to the EXT Signal: The EXT bit (which replaces the original PRIV bit) is then routed (using standard jumper wires or a patch board) to each EPROM's A9. With this wiring, when EXT is HIGH (1), the EPROM will output data corresponding to addresses 512–1023; when EXT is LOW (0), the EPROM addresses 0–511 are in effect.
• Physical Layout Considerations:
  • Work carefully on the control card. Since this modification is on a wire‑wrapped board, use a precise soldering iron and desoldering braid, or gently cut the trace with a sharp knife.
  • After freeing pin 24, add a jumper wire to take the EXT signal from the microcode control logic and tie it to A9 on all EPROMs. Ensure that the EXT signal is clean (using TTL buffering if necessary).

2.2. Resolving the Microinstruction "Conflict"

• Reassigning Functionality in the Microcode Word:
  • The original microcode used the PRIV bit not only as an address extension candidate but also for a few privileged operations.
  • For any instructions where the PRIV bit was set and a non‑zero MISC field was required simultaneously, the microcode must be rewritten such that the privileged functionality is encoded elsewhere in the MISC field.
• Programming Considerations:
  • Update the microcode assembler to treat the bit formerly known as PRIV as the EXT bit.
  • In microinstructions where the privilege level was essential, assign a "reserved" MISC encoding for that function and instruct the assembler to clear the EXT bit.
  • Validate that all branch and jump targets now use the proper 9‑bit addressing, and double‑check that no microinstruction inadvertently uses EXT when it really must operate in the lower half.

2.3. Summary of Hardware Changes

• Minimal Changes Required:
  • With just a few minutes of careful board modification (freeing A9 and adding jumper wires) the hardware is ready to accept 9‑bit microcode addresses.
  • No major logic redesign is needed on the control card aside from ensuring that the EXT signal is distributed correctly to every EPROM.
• Combination with Programming Updates:
  • The microcode images must be reassembled with the new EXT bit definitions.
  • Also, the opcode decoding logic inside the CPU's microcode control (whether in discrete LSI or hardwired decoder circuits) must recognize the prefix opcode to tap into the extended microcode range.

3. Practical Example

Consider the following (conceptual) microinstruction representations:

Original Instruction (Before Modification)

• Format (8-bit next address field): PRIV | N[7:0] For example, a microinstruction might have:
  • PRIV = 0
  • N = 0x34 (52 decimal) → Branch target: 256 + 52 = 308.

Revised Instruction (After Modification)

• New Format (EXT replaces PRIV): EXT | N[7:0]
  • If the intention is to branch to the original space, EXT is 0. → Next Address: 256 + 0x34 = 308.
  • If the designer wishes to branch to the extended space, set EXT = 1. → Next Address: 512 + 0x34 = 564.

Opcode Expansion Using a Prefix

• Standard Encoding: Any opcode value from 0x00 up to (say) 0xFE proceeds as usual.
• Prefix Opcode for Extended Opcodes:
  • When the CPU fetches the opcode 0xFF, the microcode logic is designed to fetch the next byte from program memory.
  • That byte is then treated as the extended opcode, and it indexes into a dedicated area (for example, microcode addresses 512–767).
  • Thus, a "two‑byte opcode" expands the hardware instruction set.

4. Conclusion

In summary, doubling the microcode store and expanding the opcode set is completely feasible with a few targeted modifications:

Hardware Side:

• Free Pin A9: Remove its ground tie on each microcode EPROM and tie it, via jumper, to a newly defined EXT signal.
• Signal Redistribution: Ensure that the EXT signal (formerly PRIV) is properly buffered and distributed on the control card.

Microcode Programming:

• Reassign the PRIV Bit: Modify the microcode assembler so that the bit formerly used as PRIV is now the EXT bit.
• Remap Branch Targets: With the EXT bit available, the next-address field becomes 9‑bits wide and can address microinstructions in two halves (0–511 vs. 512–1023).
• Introduce a Prefix Opcode: Reserve a special opcode (e.g. 0xFF) so that an extra byte becomes an extended opcode indexing the new microcode region.
• Resolve Encoding Conflicts: Review and rewrite any microinstruction where the old PRIV bit conflicted with other non‑zero MISC fields by relocating privileged functions into unused portions of the MISC field.

This thorough proof‑of‑concept shows that only minor modifications to the control card's wiring (and a corresponding update of the microcode) are required to double the microcode store and expand the opcode set accordingly.

Resolving the Privileged-Bit Conflict

Below is a detailed explanation of one complete, systematic approach to resolving the "privileged‐bit conflict" that occurs when a design change frees the single bit formerly used as the PRIV bit for microinstruction addressing (now called EXT) while some microinstructions also relied on that bit to indicate a privileged operation. In short, every microinstruction that originally had PRIV = 1 in combination with a nonzero MISC field must be re‐encoded so that its "privileged behavior" is signaled solely by a redefined MISC field (using one or more "reserved" codes) while the freed bit is forced to 0 (i.e. treated as EXT = 0). The following sections describe one method to accomplish this for 100% of the affected instructions.

1. The Problem: Conflicting Encoding of PRIV

In the original Magic‑1 microcode design, each microinstruction word (typically 56 bits wide) contains many fields. One such field is a single bit called PRIV that flags whether the instruction is "privileged" (i.e. it controls operations that must only be done in a privileged mode). At the same time, the microinstruction contains a 4‑bit MISC field that sometimes must be nonzero to select specific functions (like "trap on overflow," "do branch," etc.). Unfortunately, in a number of microinstructions the PRIV bit is set yet a nonzero MISC field is also required.

When the decision is made to repurpose the PRIV bit as the high–order (EXT) bit of the next–address field (thus doubling the microcode store from 512 to 1024 words), the privileged functionality can no longer be signaled by that bit. Therefore, any microinstruction that previously relied on PRIV must be rewritten so that its privileged behavior is solely encoded by a revised interpretation of the MISC field. (In many cases the PRIV bit appears in only a handful of instructions; however, to be completely systematic the solution must cover every one of them.)

2. Overview of the Proposed Solution

Our strategy is as follows:

• Remove the PRIV Bit:
  • In the new design the bit formerly called PRIV is now re‐designated as EXT (the address–extension bit).
  • All microinstructions that formerly had PRIV = 1 will now have EXT forced to 0 (because we no longer use that bit to flag privilege).
• Reassign Privileged Functions to the MISC Field:
  • Instead of using the PRIV bit, we will reserve one or two of the unused values from the 4‑bit MISC field to indicate the "privileged" versions of specific micro–operations.
  • For every microinstruction originally encoded with PRIV = 1, determine its "privileged function" (for instance, "wcpte A,(B)", "copy PTB,A", "reti", "tosys", "fromsys").
  • Replace the combination of PRIV and the original MISC (if any) with a new MISC value (or, if necessary, even a short two–cycle sequence) that produces the same control effect.
• Update the Microcode Assembler and Source:
  • The microcode–assembler or preprocessor (which builds files such as mcode.h, mcode.c, and the PROM hex images) must be changed so that whenever a microinstruction's source contains a command to set PRIV, the assembler instead clears the EXT bit and adds a "privileged operation code" into the MISC field.
  • This mapping must be done for every microinstruction that originally used PRIV in any nonzero MISC context.

3. Detailed Example and Mapping

Let's consider several concrete examples taken from the official microcode listing that mention "PRIV(1)":

Example 1: The "wcpte A,(B)" Instruction

• Original Encoding:
  • The microinstruction (at address 0x2e) is written with the comment "wcpte A,(B) ; PRIV(1),TO_Z(R_B),SET_ADR(CODE_SPACE,PTB_OVERRIDE),NEXT(Wcpte)".
  • Here the PRIV bit is set to 1 and the MISC field is (implicitly) zero or reserved for "wcpte" behavior.
• Rewritten Solution:
  • Since we are freeing the PRIV bit for addressing, we force EXT (formerly PRIV) to 0.
  • We then assign a new MISC value (call it M_WCPTE) that explicitly instructs the control circuits to perform the "wcpte" operation.
  • For example, if neither 0xE nor 0xF is used by any other function, you might choose: M_WCPTE = 0xE.
  • Thus, the new microinstruction for wcpte A,(B) will have:
    • EXT (the former PRIV bit) = 0
    • MISC field = 0xE and the rest of the control fields (latch, enable, etc.) remain unchanged.

Example 2: The "copy PTB,A" Instruction

• Original Encoding:
  • The microinstruction at 0xc8 reads: "copy PTB,A ; PRIV(1),TO_Z(R_A),L(R_PTB,LWORD),NEXT(Fetch)".
• Rewritten Solution:
  • Clear the EXT/PRIV bit (force EXT = 0).
  • Assign a new MISC value (say, M_COPY_PTB) to indicate the "copy PTB" privileged operation.
  • For instance, choose: M_COPY_PTB = 0xF.
  • The new machine code now shows that the privileged action is indicated solely within the MISC field.

Example 3: The "reti" Instruction

• Original Encoding:
  • At 0x8a: "reti ; PRIV(1),NEXT(Reti)".
• Rewritten Solution:
  • Again, force EXT = 0.
  • Define and assign a new MISC code for the "reti" operation. For example, if an unused value exists (perhaps you can select an unused code such as M_RETI = 0x1, if that value is not already in use, or reserve 0xE/0xF for other instructions if needed).
  • The new encoding will then have no PRIV flag and instead its MISC field indicates "reti" to the micro–control logic.

Example 4: "tosys" and "fromsys"

• Original Encodings:
  • At 0xe9: "tosys ; PRIV(1),COMPARE_0(R_C),MISC(M_SET_FLAGS),NEXT(ToSys)"
  • At 0xea: "fromsys ; PRIV(1),COMPARE_0(R_C),MISC(M_SET_FLAGS),NEXT(FromSys)"
• Rewritten Solution:
  • In both cases, clear the EXT bit.
  • Define new MISC codes—say M_TOSYS and M_FROMSYS—that perform the same actions as the original tosys and fromsys operations (which previously combined the effect of a PRIV bit with MISC = M_SET_FLAGS).
  • For example, if M_SET_FLAGS originally was defined as 6, then M_TOSYS might be defined as 6 with a "privileged" variant (e.g., add an offset or select a specific reserved value not previously used).
  • Then the microinstruction is rewritten so that its micro–control signals (latches, compare, and next–address) remain the same while the MISC field now fully encodes the privileged opcode.

4. A Complete Systematic Rewrite Procedure

The following procedure should be applied to all microinstructions that have PRIV = 1 in the original source:

• Scan the Entire Microcode Source: Identify every microinstruction where the assembled or written source has the PRIV bit set.

• For Each Privileged Microinstruction:

  • Step 1: Remove or ignore the setting of the PRIV bit. In the new image, the bit formerly assigned as PRIV (now EXT) is always forced to 0.
  • Step 2: Determine the intended privileged function that was being signaled. (For many instructions the comment indicates this, e.g. "wcpte", "copy PTB,A", "reti", "tosys", "fromsys".)
  • Step 3: Check the value of the MISC field in the instruction. If it is zero, then the privileged behavior was implied solely by the presence of the PRIV bit. In that case, select one of the "reserved" values in the MISC namespace (for instance, 0xE or 0xF which are not used for non‐privileged functions) to represent that function.
  • Step 4: If the MISC field is already nonzero (i.e. its value provided an additional function), then decide on a re‐encoding rule. For example, you may choose to "OR" a specific constant (say 0x8) into the MISC field so that the resulting value is unique and reserved for the privileged version of that operation.
  • Step 5: Rewrite the microinstruction's encoding so that:
    • The EXT (formerly PRIV) bit is 0.
    • The MISC field is replaced by the new value as determined above.
    • All other fields (latch controls, enable signals, immediate values, ALU operations, etc.) remain unchanged.

• Update the Microcode Assembler/Preprocessor:

  • Hard‑code these remapping rules into the assembler so that instead of outputting a microinstruction with PRIV = 1, it now outputs a microinstruction with EXT = 0 and with the updated MISC code.
  • For consistency, add definitions such as:

#define M_WCPTE      0xE
#define M_COPY_PTB   0xF
#define M_RETI       0xX  // (Assign an unused value)
#define M_TOSYS      0xY
#define M_FROMSYS    0xZ

(Choose X, Y, Z from among the unused MISC field values.)

• Simulate and Verify:
  • Use the simulator to check that for every microinstruction with a formerly set PRIV bit the control signals generated by the new encoding match the desired function.
  • In particular, verify that the branch destination (the "next" field) now uses a true 9‑bit address (with EXT as its MSB) and that every microinstruction that requires privileged operation is still executed with full functionality.

5. Summary

In summary, to resolve the conflict we must:

• Remove any use of the old PRIV bit (which is reassigned as the EXT bit for addressing)
• Rewrite every microinstruction that originally had PRIV = 1 so that its privileged function is now signaled solely through the MISC field (using one or more new reserved MISC codes)
• Modify the microcode assembler to carry out these rewrites automatically, ensuring that no instruction ever has both EXT (formerly PRIV) set and a nonzero MISC field that conflicts with its intended privileged operation.

This procedure, applied across the entire microcode image, guarantees that all privileged instructions (100% of those that require it) are correctly re–encoded for the expanded microcode store while preserving their intended functionality.