Still stuck trying to process characters in the monitor program using PostMsg() and WaitMsg() OS calls. According to screen displays, PostMsg() gets called every time a key is pressed on the keyboard, great! And WaitMsg() (or rather CheckMsg() ATM) is being called in loop. Yet, the keystroke message does not make it to the system monitor. Instead, things crash at address $00000ABA with an invalid opcode. The CPU gets there from jumping to the zero address due to a NULL pointer, then it starts incrementing from the zero address until it hits an instruction it cannot process, which is at $00000ABA. So, I know roughly what is happening, and have yet to determine the cause. Not sure how a NULL pointer makes it into the program counter. A NULL pointer as a data address makes more sense.

Decided to start work on Qupls5 for a bit.

Qupls5 is going to have fewer registers (16) and one memory operand per instruction (like the 68000). Qupls5 will have 96-bit wide registers to support triple precision floats and capabilities pointers. Integer ops only work on the lower 64-bits though. Addresses are 48-bit. Instructions are only 32-bit with additional instruction words for constants and the like. The work is mostly specs ATM.

Went all gung-ho a couple of nights ago coding the 68851 emulation. Got a lot of it coded. About 700 LOC. It is quite a sophisticated beast as MMUs go. Some of the status results for the PTEST instruction need to be coded yet.

Went to add transparent translation registers to the MMU then recalled that the 68030 MMU had them. So, a ‘030 compatible transparent translation registers were added. I think this will make the MMU compatible with the MMU in the 68030.

Decided to scrap the work I did on Qupls5. Worked on enhancements for a 64-bit mode 68000 instead.

Started working on Qupls6. Back to 32-regs and 32-bit instructions. Planning on having 128-bit registers. But processing will be on 64-bits at a time. Kinda like the way the Z80 or 68k process data. The registers will be arranged as low-half, high-half in the register file. Halves stacked vertically in the register file. This is because the BRAM is better used deep rather than wide. The 128-bit registers are to operate with larger FP values and capabilities.

An instruction like ADD.H Rd,Rs1,Rs2 (add hexi-byte values) will need to run through the ALU twice, once for each of the lower and upper half of a register.