SAGE: fix thirteen 68000 bugs that kept the UCSD p-System from booting

[ajfa]

The Sage II simulator only ever gets exercised by CP/M-68K, and readme-sage.txt still lists UCSD Pascal as "does not run yet". It turns out the p-System is blocked by thirteen separate bugs in the 68000 core rather than by anything specific to the Sage hardware.

With this patch:

• the four Sage p-System IV.13 diskettes boot to Command: E(dit, R(un, F(ile, ... and the Filer lists both drives
• the four Stride p-System IV.21 diskettes boot to their startup utility
• CP/M-68K 1.2 boots exactly as before

The commit message lists all thirteen. The three with the widest reach are probably these:

• MOVE never cleared V and C, which accounts for most of the difference on its own
• the (d8,An,Xn) modes sign extended the 8 bit displacement as if it were 16 bits, in all eleven places that build such an address, so every negative displacement reached the wrong memory
• the bit mask table had four wrong entries, so BTST, BSET, BCLR and BCHG worked on the wrong bit whenever the bit number was 15, 19, 23 or 27

How this was tested

A differential tester runs one random instruction at a time on this core and on Musashi from the same starting state, then compares the sixteen registers, the PC, the condition codes and a 64 byte window of memory. The SIMH side is driven through the simulator's own command interface, with deposit, step 1 and examine, so what gets tested is the simulator as built rather than a relinked copy of the core.

Out of 425 comparable cases in a run of 800 random instructions, 98 disagreed before these fixes and 8 after. Five of those eight are cases where the two models take a different view of addresses outside the simulated 512 KB. The other three are real and still open: the carry flag of ROR.B and ROR.L, and the flags of CHK.W.

The p-System images used for the boot tests are David Erhart's ImageDisk dumps of original Sage and Stride diskettes. They contain compressed sectors, so they need uncompressing before the simulator will mount them read/write.

🤖 Generated with Claude Code

[markpizz]

Similar comment about identifying who you are mentioned in simh/simh#1256.

Otherwise, since you're making a good jump at fixing things here in a simulator which, seems to have had a very quiet life in the 12 years it has been in the codebase, why stop before addressing the remaining 8 cases you found to be unexpected?

[ajfa]

On the remaining eight: they were in the description, but they were not one group, and widening the test changed the picture enough that the honest answer is longer than "three".

Five of the eight were never core bugs. They are cases where this core and Musashi take a different view of an access whose effective address falls outside the simulated 512 KB, so there is nothing to fix until someone decides what the Sage ought to do there, and that is a hardware question rather than a 68000 one.

The other three were real, and they are fixed in the commit I have just pushed. Going after them turned up four more in the same code, so the commit carries seven:

• ROR.B, ROR.W and ROR.L took the carry from the bit one position above the msb of the result, and got a count that is a multiple of the operand width wrong as well.
• ROL.B and ROL.W got multiples of the width wrong, and ROL.L set the carry whenever the result was nonzero, because MASK_32L is & 0xffffffff.
• CHK.W compared the whole 32 bit register against an unsigned bound instead of doing a signed 16 bit compare, so any Dn with bit 31 set trapped even with its low word in range, and a negative bound never trapped at all.
• CMPI.B/W/L set X. CMP, CMPA and CMPM in the same file already save and restore it; CMPI was left out because it shares its case with SUBI, which does set X.
• ASL.L indexed the carry as bitmask[32-cnt] where LSL.L a few lines below uses bitmask[33-cnt], and its cnt >= 32 arm still tested cnt == 16, copied from ASL.W, so the carry was never set there at all.
• BSET with a register bit number and a memory destination took the bit number from the register in bits 2..0, which is the effective address register. BTST, BCHG and BCLR all use bits 11..9.
• The four MOVEM helpers threw away read and write errors. ASSERT_OK ends in break, which is meant for the switch in sim_instr, so inside a helper's for loop it merely left the loop and the function then returned SCPE_OK. A misaligned MOVEM moved nothing, reported nothing and let the program counter walk on, while MOVE.W at the same address reports the access. ASSERT_OKRET, already defined in the file, is the right macro there.

Why the answer grew is the useful part, so it is worth saying plainly: the "eight" in the description was one seed. Over four seeds of eight hundred random instructions the disagreements go from 60 to 38, and only after these seven fixes is every one of the 38 that remain an out of range address or a 68020 memory indirect encoding rather than an instruction semantics difference. A targeted bank of twenty cases for these families, each chosen so the correct answer is unambiguous and including a SUBI.W control to confirm that SUBI still sets X, goes from eighteen disagreements to none. Two of the seven are invisible to the differential tester, because it skips any case where the two cores disagree about whether to trap; those were checked directly against the programmer's manual instead.

CP/M-68K 1.2 and the p-System IV.13 still boot, and the simulator's own register test still passes.

On identity: ajfa is a stable GitHub account rather than a throwaway, and the commits are verifiable against it. I keep my email address private as a matter of course and would rather not change that. If a name on the profile is what matters for attribution I can look at that, but I would ask that the account itself be enough for the code review.

And if that rule means these changes cannot be taken on, I understand, and there are no hard feelings. Each defect above says what was wrong and how it was measured, so the work is there for whoever wants to redo it under their own name.