Cereal port, needs to be 7. Breakfast is a important meal.
For testing could the the keyboard also have break key irq that bypasses the normal
irq handler?

Level 7 is reserved for NMI on the 68000 it is wired to a button. I have the timer on 6.
Thought about detecting CTRL-ALT-DEL in hardware and having it trigger a higher interrupt.
CTRL-C is detected in the keyboard IRQ handler and causes the current program to abort and jump to the monitor.

There are only six IRQ signal levels. I wrote some code to allow chaining multiple ISRs to an single IRQ level, but it is ugly. For now, there is just a single ISR per IRQ signal level.

Mods
Added support for the TAS instruction at the memory. In theory the RMW cycle of TAS can be performed atomically. Using TAS instead of hardware semaphores allows more semaphores to be implemented, as any address may become a semaphore. The semaphore lock and unlock functions were altered to accept an address instead of a semaphore number.

The system is busted ATM. It runs for a second or two then crashes. It has something to do with switching to a thread I think. The PC gets corrupt somehow. The thread switching is simple.
1) disable interrupt
2) save regs in thread control block
3) switch to kernel stack
4) acknowledge interrupt
5) call 'C' ISR (may change the active thread control block)
6) restore regs from thread control block

Looks like the issue with switching threads is fixed. The supervisor stack for each thread was the same, the fix was to make them separate.
Now there is an issue with getting keyboard input from the monitor.

The IOFocus variable used to determine which core has the I/O focus gets corrupted somehow. This causes the I/O focus to be lost preventing keyboard input and causing display issues.
For now, the I/O focus is reset in the monitor’s loop waiting for a keyboard character. This allows things to work, except that core #2 always has the focus.

Milestone:
Sending a message from one thread to another waiting for a message.

Mods

With message send/receive looking like it is working, the way the keyboard works was changed. It now uses message primitives. All the ISR does is post a scan-code to the keyboard mailbox. A Keyboard translate thread then translates the scan-code and sends it to the App with the input focus.

The system monitor was changed to use a mailbox to receive messages. It sits in a loop waiting for keydown messages from the keyboard translate thread.
And… it does not work. The system hangs.

Removing the keyboard translate thread allows the system to work, although without keyboard input. This thread was given a higher priority than the other threads.

Modified the memory controller to allow a port to use both streamed and non-streamed access. Access is differentiated by the transaction id which is always zero for a streamed access and non-zero for non-streamed access.

Bug Fixes
CheckMsg() was not unlocking the mailbox and message at one return point.
Issues
The system is trying to add a thread to the timeout list that is already on the timeout list causing a panic. There are only a couple of possibilities.
1) A flag is not being set indicating the thread is timing out
2) The thread is not properly removed from the timeout list

SendMsg() and PostMsg() are very similar. It is tempting to try and combine them into a single call. The difference is SendMsg() may cause thread rescheduling and PostMsg() does not. Also, SendMsg() will block until the message can be sent, whereas PostMsg() will wait only a short time, returning a busy error if the message cannot be sent succinctly.

There are two fields (srcadr and dstadr) in a message block that are not being used. They may be eliminated. The idea was to track where the message came from and where it was going. Removing the two fields would make messages 16 bytes in size.

Messages are not currently timestamped or tagged with co-ordinates. What type to use for graphics co-ordinates?
Mods
Streamlined SendMsg() and PostMsg() by removing redundant code. They were allocating a message, then freeing same message if a thread was dequeued from a mailbox. Now the message is not allocated or freed in that case.

Modified the message primitives to send and receive a pointer to a message rather than the individual message fields. Setting up the individual message fields would result in too many arguments. The message type was modified to include a timestamp and graphics cursor co-ordinates.

Mods
Added FMTK_AllocTimer() and FMTK_FreeTimer() timer functions. There is a pool of 200 timers that can be allocated at one time. Each timer has micro-second resolution. Since 200 ISRs for the timers would be too many for the 68k to support, there are seven identical ISRs to support the timers. Each ISR services 32 timers.

Added FMTK_SetAlarm() and FMTK_KillAlarm() timer functions. Set alarm’s job is to set up the timer registers for a one-shot or periodic timer and enable the timer interrupts. KillAlarm() disables the timer interrupts and counting. SetAlarm() also specifies which mailbox will receive notification of the timeout event. There can be multiple mailboxes linked for the timeout event, and each mailbox will receive the event.

I have been pre-occupied with other events in my life and have not worked on the system so much lately.

The OS is not handling time outs properly, or possibly the thread selection on a context switch is not quite right. The idle thread seems to run multiple times even after it calls WaitMsg(). WaitMsg() looks like it gets called multiple times without waiting. When a valid timeout does occur WaitMsg() is not returning the correct message values.

Found a way to reduce the core size and improve the timing a miniscule amount. about 100 ps better.

The move multiple registers instructions were using an if/else priority encoder to select registers to move based on the register list bitmap.
This is now done with a find-last-one module to detect a bit in the bitmap, and a case statement to select the register.

The system almost boots, It displays a list of devices it found, dumps a task list, and the interrupt live indicator is active. Keyboards interrupts are detected (a flashing indicator on screen), but after that the system is locked. The cursor is in the wrong location on screen and the keyboard is locked out. This looks like a software issue.

Found a mistake in the cursor set/get code. For setting the cursor registers were not saved on the stack, but at return time they were popped off. This would a) load registers with unknown values b) underflow the stack. Fixing this did not affect the system operation however. Cursor is still in the wrong location and keyboard is locked. But, it is one less bug.

An interface to read external buttons and switches was added but does not seem to work. A WaitAnyButton() routine call was inserted at judicious places for debugging purposes, but does not wait for the button as it is supposed to.

Adding support for the 68851 PMMU to the 68k core. I would like to add support for graphics co-processing too.
PMMU is co-processor #0, Floating point is co-processor #1. Likely add the audio/graphics as co-processor #7.
The PMMU support is likely going to be tightly integrated with the CPU as is floating-point which leads to a monster state machine. The number of states required exceeded 256 now so an extra bit was added to the state register.

It has been a busy coding day. All the MMU instructions with the exception of the PTEST instruction are coded. There is still more to be coded for the hardware, the RPT cache for instance. The will be an option for a 16-bit App / Process ID is allowed for instead of the 3-bit task identifier for easier process switching.

Some of the instructions may not work 100% identically to the original. I did not have register breakdowns available so I guessed the register formats. It should work, it just may not be consistent with the mc68851. One can always re-arrange the struct types to match.

The PSAVE / PRESTORE instructions may not operate identically to the original. It does save and restore the register state, but the format of the state in the save area was unknown. The instructions support only two options: short format and long format. Long format saves and restores everything. Short format does not save / restore the breakpoint registers.

The PMMU address mux is in place and does not impact the core when the PMMU is disabled. The system is able to boot with the PMMU disabled.

A trick is keeping things working while the PMMU is under construction.

I found a manual on-line with a decent breakdown of PMMU registers (the manual is quite detailed), so I am improving compatibility now. I plan on making extensions to support 64-bit addressing.

Things are busted back to the blue screen level ATM after modifications to the system and PMMU. I managed to diagnose the issue as a bad state machine transition. The state machine is supposed to go from the STORE state to the ACK state. Instead there is a runt state it hits in between. The runt state updates the register file which wrecks havoc on the running program. It might mean a significant re-write of some sort. There does not appear to be an easy fix. Perhaps the SM will work better at a lower clock frequency.

The OutputChar() routine was modified to use a TAS instruction in a spinlock. The idea was to have it wait for a previous OutputChar() to complete done by a different process. This modification uncovered a bug.

Decoding of the TAS/TST and illegal opcode was a bit mixed up. This caused a TAS instruction to be not decoded properly, leaving the CPU stuck in the decode stage. While in the decode stage the PC increments which made this more challenging to debug. It took a bit of digging to figure out which instruction was causing an issue.

Found one issue that turned out to be minor. The text video setup routine was calling the Delay3s function which was modifying several registers without saving and restoring them. Since the text video routine is called as a TRAP it needed the registers preserved. In this case it did not matter as the registers trashed turned out to be assigned new values after the call anyway.
I was wondering why my changes did not seem to affect the results in the FPGA, then I realized I was uploading the wrong bitstream to the FPGA.

Made better use of 32kB local memories in the processing nodes. Each CPU had its own 32kB memory area mostly for local vars. This had separate logic in the node to manage the memory. It has now been incorporated into the 256kB shared memory which has been extended by 64kB to 320kB of memory. In the new 64kB region address bit #15 is flipped for the second CPU. This makes the memory pseudo local. CPU #1 sees CPU #2’s memory in the range $48000 to $50000. The same is true for CPU #2, it sees CPU #1s memory in the range $48000 to $50000. Each effectively has its own memory at $40000 to $47FFF and sees the others memory in the remainder of the range.

Memory in the range $1000 to $3FFFF is considered ROM and has writes disabled.

Some heavy-duty work on the PMMU state machine and bus fetches. Made complex by the use of two sizes of descriptors and the capability to use any size at any table level. It is going to be even more complex with 64-bit support.

Bounced back up to the boot screen full of info, and interrupts running level. The system monitor program does not run yet. The OS kernel PostMsg() / WaitMsg() may be working. WaitMsg() is called in loop and does not hang so that is a good sign. PostMsg() happens from the keyboard ISR when a key is pressed. I put in diagnostic display messages at the entry point of these functions.

Added support for the 68020 breakpoint acknowledge cycle. Breakpoints are a part of and supported by the 68851.

Added support for the additional 68020 address modes. I may make the core 68020 compatible at some point. Having the address modes available helps. This feature is untested.

Changes to integrate the PMMU with the CPU caused issues with the execution of interrupts. There was a loop in the ifetch stage if an interrupt occurred which caused the machine to hang.

A bad case value caused the CPU to repeatedly store to incrementing addresses without stopping, which caused a hang. This was for the MOVEM instruction.

Contemplating how to add 64-bit support. It may be controlled by PMMU code pages. Might add a bit to the MMU page table entries that says 'this page is 64-bit code'. Same idea as having mode controlled by settings in an x86 segment register.

Added some more support for 68020 instructions (added the bit-field instructions) and CAS/CAS2.

Added support for 32-bit branch displacements. The core already supported 16-bit displacements so coding for 32-bit was straightforward. The core also has a non-standard option to support 24-bit displacements using the LSB of the displacement byte to indicate 24-bits.

Having fun coding the CALLM / RTM instructions. I think these instructions are only on the 68020 and not more recent CPUs. I may just stub them out. IDK how useful they are. I may just try for 68030 compatibility if it is easier to achieve.

For the 64-bit version, byte and word instructions would remain the same, long instructions would be 64-bit though instead of 32-bit. Rather than try and define a whole new set of instructions, the existing opcodes would be reused. Could have a bit in the SR to select 64-bit mode.

ATM I am trying to get the system monitor working with Femtiki running. It does not want to seem to process characters. Messages are not making it all the way to the monitor.