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.

Modified the keyboard interrupt to save and restore registers in a piecemeal fashion as opposed to all at once at the beginning and end of the routine. This was to reduce the dynamic instruction count (save clock cycles) and reduce stack space used in cases where the interrupt was not a keyboard interrupt. Code is slightly larger, but this is not 1980 size limitations.

Stripped out the scan-code checking in the ISR for CTRL-C and ALT-tab. Then put it back in later. These are also processed by the KeybdTranslate() routine which is called by the App to translate keyboard scan codes. I thought it could be moved out of the ISR, but then realized that if the app crashed or just decided not to test for keystrokes, there would be no ALT-tab or CTRL-C functionality.

Also removed the LED updates, this was redundant as there is a screen indicator as well.

Made some progress on the looping ‘illegal opcode’ issue.

Found a hardware issue with the SoC NIC (network interface circuit). It was sending all memory requests across the network, including local ones. There would be no ACK cycle on the network for a local request, which turned out to be generally okay, except that when there was a long sequence of local accesses without any global accesses, a bus error would be signaled on the network since it thought there was a global timeout. So, a bus error was intermittently signaled to the CPU depending on what was going on. It was found after a MOVEM instruction which took some cycles to complete.

The bus error routine just spits out ‘bus error’ and drops back into the monitor, aborting the current operation.

The next hardware issue was the state stack would underflow. A bus error was just jumping directly to the TRAP code, basically a no-no since it is called as a routine from elsewhere. The underflow popped a zero off the stack which is an illegal state. Illegal states were jumping to the RESET. The RESET state had bug in it in that if it were reached other than by external reset, it would execute a different trap, possibly the previous trap executed.

Found another software issue. Mailbox handles (all the FMTK handles) are short integers (16-bit). But in the boot rom code a long word was being loaded for the handle. Because the CPU is big-endian the low order 16-bit would not be correct. The handle would never match what it was supposed to, so no messages would get delivered.

The boot rom commands still do not work yet, it hangs at the ‘$’ prompt now. At least the illegal opcode error is gone.

A great day for catching bugs.

Slowly moving the core closer to 68020+ operation. Modified the core to add an additional stack pointer. The core now has three stack pointers and three modes like the 68020 and above. User/App, supervisor and interrupt modes. The ISRs were modified to make use of the interrupt stack pointer.

Also added a global interrupt enable flag. It works like this: on power on reset, all interrupts, including NMI, are disabled until the first update of the status register. This prevents a spurious interrupt from interrupting the startup sequence.

Changed the way interrupts are masked off when an interrupt occurs. There was a ‘MOVE.W #$2700,SR’ at the start of every interrupt routine to disable interrupts. So, the processor now just automatically masks all interrupts when entering an ISR. This is slightly different than the 68000 which automatically sets the interrupt mask level to the same level as the interrupt. If it is desired to allow interrupts to occur during the ISR it is now necessary to modify the SR accordingly. NMIs will still override the ISR.

Expanding the number of interrupts supported by the CPU is under consideration. It would work by using currently unused bits in the SR. Two bits from the CCR plus a bit in the SR would add three more bits, allowing a 64-level interrupt system. Another bit stolen from the CCR part of the SR would also indicate 64-bit mode is active.

With the additional stack pointer and the mode flag (mf in the SR), the system is busted down to not clearing the screen even. It does set a LED on power-up.

Found another hardware bug. When the SR was modified programmatically (AND, OR, EOR, MOVE), the stack pointer selection was not changing to reflect the selected stack in the new SR value.

Well, I managed to get things working again up to the screen clearing, and the devices initializing, but after that it hangs. I do not have a lot of confidence about how things are working, as the fix was to simply shuffle some code around without making other changes. AFAIK it should not make a difference, but it does. I wonder if there is a timing bug in the SoC network or something similar. This could take some digging to track down.