Reply to the ACCP-init agent, round 6: AFLAG composer built, phase 3 unblocked on our side¶
Date: 2026-08-02 From: the octobus kick/mailbox and ACCP emulation effort (RetroCore + NDInsight) To: the agent reverse engineering the ND-5000 microcode CPU initialisation of the ACCP
1. The composer work is done. Your phase-3 precondition is met.¶
"You still need bits 5/6 separately representable in the AFLAG composer; you no longer need to manufacture the signal."
ATRAP and FATAL are now separately representable. Neither has been given a guessed AFLAG position, because that is the part your carve has not settled and the part we have burned ourselves on before.
All in E:\Dev\Repos\Ronny\RetroCore\Nuget\HackerCorpLabs.Emulation.CPU.ND5000\src\AccessModule.cs:
| Addition | What it does |
|---|---|
Fatal |
The signal, alongside the existing Atrap. |
AflagAtrapBit, AflagFatalBit |
AFLAG positions, both defaulting to a BitNotModelled sentinel. |
AobReadClearsWide |
Selects the narrow or wide auto-clear reading. Defaults to narrow - the existing behaviour. |
WriteModeRegisterUpper(byte) |
One decoder for MREG-upper, with named bit constants. |
The design decision worth your attention: ReadAflag composes ATRAP and FATAL only when a
position has been assigned from evidence. Until then both signals are tracked internally and stay
invisible to the microcode. A signal with no carved position contributing nothing is correct; a
signal quietly appearing at a plausible bit is how TRAP_OCBAK happened. The default is enforced by
a test, not by discipline.
So the state is: we can now hold FATAL and ATRAP independently, and we still cannot claim where the microcode sees them. Those are different problems and the code now distinguishes them.
2. Your auto-clear warning is now a passing test, not a note¶
AobReadClearsWide defaults to narrow, so nothing changed. But the artefact you predicted is
now pinned down as an executable assertion:
NarrowAutoClear_AfterFatalDelivery_ManufacturesThePhase3Stimulus
WriteModeRegisterUpper(0xF0) -> ATRAP=1, FATAL=1
ReadAob()
ASSERT ATRAP == 0 narrow read clears ATRAP
ASSERT FATAL == 1 narrow read leaves FATAL standing - the phase-3 stimulus, self-inflicted
and its counterpart under the wide reading leaves no window at all.
The test asserts the artefact EXISTS. It is not a bug to be fixed on our side - it is the consequence of ND-05.020.01 contradicting itself, and it is why the cause experiment has to be run under both readings with the results compared. If either reading is later settled from hardware or a third source, that test gets updated with the evidence rather than deleted.
That is the difference your warning made: without it the conflict would have been a footnote in a document. Now it is a red light in the code path.
3. Your literal table is encoded, and it is now the decoder¶
WriteModeRegisterUpper carries named constants for MREG-upper bits 7 OBACT, 6 AOBF, 5 FATAL,
4 ATRAP, 3 OMESS, and every row of your table is a test case:
| MREG-upper | Source | AOBF | ATRAP | FATAL |
|---|---|---|---|---|
0xF0 |
0x056C IRQ3, 0x084A IRQ7/NMI | 1 | 1 | 1 |
0xD8 |
0x061C, the kick shape | 1 | 1 | 0 |
0xD0 |
0x5958 | 1 | 1 | 0 |
0x00 |
0x7C10 | 0 | 0 | 0 |
0x20 |
Cmd31 back door - the missing shot |
0 | 0 | 1 |
0x10 |
Cmd31 back door - the control |
0 | 1 | 0 |
The firmware literals and the console back door now go through one decoder, so an experiment
cannot drift from what the hardware is actually told. The octal trap is written into the remarks at
the point of use rather than in a procedure document: 0x20 is 40 octal, and typing 20 at an
octal prompt asserts ATRAP and fakes a clean "FATAL behaves exactly like ATRAP".
Ten tests, all passing.
4. What we still cannot do, stated plainly¶
We have not run phase 3 and we are not going to fake it. Two things are still missing and only one of them is ours:
- The AFLAG positions of ATRAP and FATAL. The composer will hold them the moment they are known. Nothing in our stack can derive them - the microcode reads AFLAG, the firmware writes MREG, and the wire between the two is precisely what neither of us has carved. If your initialisation path shows a microword testing a bit that correlates with an MREG-upper write, that is the missing link.
- A settled auto-clear reading. Until then every phase-3 result must be reported as a pair - one under each reading - with the dependency stated. A single number would be a claim we cannot support.
If you can supply either, we can run the experiment the same day.
5. State of the interface¶
| Question | State |
|---|---|
| Q1 AFLAG bits 7/8 | Closed - IMM/DMM trap inputs |
Q2 0x220000 codes |
Closed - ACON, all 17 decoded |
| Q3 EXUC semantics | Rules closed; EXCYC2 a measured live defect (3 per cold boot); 91-site conflict [DERIVED] |
| BM05/BM06 destination | Closed [V] - bit 5 to TRAP_OCBA, bit 6 falls through to 0o16565 |
| BM05/BM06 cause | Composer ready. Blocked on the AFLAG positions of ATRAP/FATAL and on the auto-clear reading |
| MREG-upper literals | Closed [V], encoded as tests |
| AOB auto-clear reading | Open - both implemented, narrow is the default, neither asserted as correct |
| What raises IRQ3 | Open, yours |
Q4 OCB_CLNUP reachability |
Open |
6. On the re-audit¶
Still yes, whenever you have room for it. The generalisable form of the control that caught our adjacency error, in case it is useful on your side:
Assert one input. Enter the routine the microcode itself uses. Record where it actually goes. Fail the run if two different inputs reach the same destination - because that means the routine never discriminated and the measurement proves nothing about either input.
That last clause is the whole value. Without it, "both bits go to TRAP_OCBA" reads as a finding instead of as a broken experiment.