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.

Worked a bit on another older project today, the Butterfly. The Butterfly project is a small pipelined CPU that executes most instructions in a single clock cycle. It is only 32-bit so I was re-writing it to have 128-bit registers. The idea was to use it implementing the MMU and 128-bit registers are convenient for loading descriptors. But I eventually decided not to go that route.

Made a pretty memory map for the rf68000 SoC.

Contemplating how to use multiple graphics accelerators together in the same project. I think each one needs its own dedicated memory to perform well. Considering using 340x192 graphics mode (subset of 1366x768) and RGB444 resolution. That way multiple screens (one for each graphics accelerator) can fit into the BRAM. The trick is how to merge all the results together. It is not too bad if the results do not overlap. The drawings could be sorted according to z-depth and handed to graphics accelerators processing a particular z-range. Farthest away z would be copied to a master screen buffer first, then closer results would be copied overtop - the painter’s algorithm.

Still stuck on a NULL pointer issue in the OS. But I have tracked it down further.

A JSR (a0) with a NULL pointer is one failing point. Fortunately, that instruction is not used very often. It is used only three times in the boot ROM. Unfortunately, I cannot see how it could be getting a NULL pointer, but I put in NULL pointer checks anyway. The code is loading address pointers from tables. Entries that are not used are stubbed out (they are not NULL). The one spot where it is used is in the I/O TRAP routine (TRAP #0). Since this routine gets called for every I/O operation, it is called literally thousands of times during startup. Why it would fail in one case is a mystery. The second use of JSR (a0) is similar – the TRAP #15 which tries to emulate the TRAP #15 in other systems. Once again, this routine is called successfully many times. The last use in the boot ROM is for a generic IRQ routine. This routine is not used.

The indirect subroutine call is also used by device drivers in the command processor.

From a software perspective this looks like a hardware error of some sort.

From a hardware perspective this looks like a software error of some sort.

Found a software issue in the keyboard interrupt. For some reason I decided to protect things using a blocking semaphore. The issue was that the semaphore lock logic temporarily enables interrupts in a loop. It must or the system could hang waiting for a semaphore to be released with interrupts disabled. With interrupts enabled and a level sensitive keyboard interrupt, the keyboard interrupt would activate again, recursively, and eventually overflow the stack. Also overwriting BIOS variables. I simply updated the semaphore logic to use non-blocking semaphores which run with interrupts disabled.

The system works a bit better but still responds with an ‘illegal opcode’ message over and over again, indicating it is getting to invalid code. Something is still amiss.