Clearscreen is almost working. The screen clears but to the wrong color. The startup message is displaying as a string of '?'. I think these are issues with the OR instruction.

Latest Fixes:

Register forms of ADD / SUB /AND / OR / EOR were not updating the register file.

SUBQ was not updating the overflow flag properly.

NBCD was not storing to a data register.

Z flag was not being cleared by BCD operations if the result was zero.

OR was completely messed up. It was invoking ADD by mistake. Next no data was being fetched to OR with.

There is something wrong with the implementation of BCD add and likely subtract. I guess it does not work quite the way as expected with the 68k. The add
implementation is simple, it uses lookup tables to adjust the result and carry. For now, I just commented the test out. It is not a high priority for me.

Milestone: startup message displayed on screen and in the right colors. The system monitor displays a help message. Keyboard input almost works, cursor keys are not working. Monitor commands other than the help ‘?’ are not working yet.

Some work on exception processing logic.

Added bus retry capability. The retry waits several cycles before trying the bus operation again. The waiting period comes from a LFSR, so it is pseudo random.
Added a default state handler. If the machine gets to an invalid state it will reset.

Latest Fixes:
Flags were being updated for ADDQ / SUBQ to an address register.
The ADDI instruction could hang the machine on an illegal opcode pattern.

Wondering just how compatible to the 68000 I want to make the machine. ATM the stack must be 32-bit aligned, whereas the 68k required only 16-bit align. The rf68000 uses a 32-bit data bus instead of 16-bits. Moving 32-bit data around is twice as fast as on the 68k. Been thinking about supporting virtual machine.

Congratulations on reaching the Hello World milestone!

I am making rapid progress by porting over boot code used in a previous project that used the TG68 core from opencores.org. I am amazed that things are working through a network. It is now possible to clear the screen and dump memory through the monitor program. Screen scroll does not work 100% correctly yet.

The processor test code fails during testing of the ‘OR’ instruction. It does not stop at an error as per normal when an op test fails, but instead is looping for a long time through a sequence of tests. I left the test running for about 10 minutes at the ‘OR’ stage. I do not think it should take that long to test one instruction. It loops hundreds of times and is not practical to simulate.

I would like to get a processor trace and debug facility working which would help with this sort of thing. Features not found in a standard 68000.

Now I am trying to get exceptions working. I believe the code is all in place. I could not find information on what is stacked for the cycle type word during a bus or address error exception, so I invented my own word. This kind of thing is likely to change between different versions of the processor and would be buried in the innards of system software. The word I used has the read/write status, function codes, byte lane selects line and the machine state number. The instruction register and bad address are pushed beforehand. For the status register 32-bits are pushed to keep the stack 32-bit aligned. So, I would like to add 16-bits to the SR to include the current hardware thread number and privilege level.
Any external interrupt must supply a core number to process the interrupt which is then routed through the network to the correct core.

Exception programming is one place compatibility issues arise. I intend to use the core in multi-core systems, possibly with multiple hardware threads per core. As such there is no user and supervisor mode. It is expected that exceptions may work slightly differently. Not planning on using a typical MMU. May have pages of app randomly distributed, hash table, if possible. Combining the address bus with a PRNG number to determine the page address. Would have to deal with conflicts though.

Each core has access to other cores memory through the network. It works like a DMA access. I would like to be able to invoke code on a different core than the core originating a request. One core may handle text I/O for instance so that there is a funnel for I/O requests. The text controller core may have a thread waiting for requests. I believe this is a form of remote procedure call. The trick is passing arguments to the remote procedure and triggering the remote procedure. I am thinking of using a special signal for this. The remote thread could wait until it sees the signal, then proceed. An instruction like STOP called WAIT may be required.

Added 256 hardware semaphores accessible as a global resource. For now, the boot code now locks a semaphore before trying to display and unlocks afterwards. Each core is supposed to display a line on-screen indicating it is starting up. But only one core is displaying. Claims to be core #0 which none of the cores are.

Figured out why only one core was displaying a startup message after some head scratching. It was not the case that only one core was displaying a message. They all were. Each core had its own local copy of BIOS variables. On startup all these variables are identical. So, each core wrote to the screen at the same location, overwriting the other cores output. To fix this I added a RAM to store global BIOS variables in.

Modified the core to be more compatible to the 68k. Added some 68010 support to the core. Mainly to get access to the MOVEC instruction. Movec allows access to special control registers. In this case the tick, core number, and instruction count were added as special registers. Previously they had been accessible at predetermined memory addresses.

Instructions that are restricted to supervisor mode only are now privileged instructions and will cause a trap to the privilege violation routine if an attempt is made to execute them from user mode. One exception which is different than the 68010 is that moving to or from the user stack pointer is not a privileged instruction. It is possible to move to or from the user stack pointer in user mode using the move usp instructions.

The 68010's vector base register is also supported, but it must be aligned on a 1kB boundary. A simple concatenation of the vector number and the vector base register is done rather than using an add operation.

Gave each core its own area of screen memory in the text controller. That allows each core to have its own screen. Then I modified the GetKey() routine to detect an Alt-tab and cycle through the displayed screen area. Cycling through the screens with Alt-tab works. The monitor FILL command can be used to fill the screens with data. The small monitor program is mostly working now. It has a selection to download S19 files. So, once I get the serial port working I should not need to rebuild the system all the time to run software.

There seems to be an issue when multiple cores are using the network. Core #2 which is being used for console I/O hangs if other cores are allowed to run. So, for now I just have the other cores sit in an infinite loop at startup. Still pondering how to implement RPCs.

Forgot to include the packet ager in the network, which means that packets could circulate forever if there is a network issue. I modified the nic to simplify the slave write acknowledge. It looks like the acknowledge was being missed somehow, causing the master to hang. The write acknowledge depended on what state the machine was in. Now it is not state dependent.

RPC calls require a service routine on the remote host. What is the best way to get the service routine to run? A couple of choices come to mind. 1) run the routine on demand, triggered by an interrupt. 2) run routine on demand triggered by stuffing an RPC instruction into the instruction stream 3) run the routine periodically triggered by a time interrupt. 4) use a messaging system. The service routine must scan a call buffer for arguments and call number.

Bizarre issue tonight. The cursor was appearing on a different screen than the current output screen. It is at the right position on the wrong screen. I forgot that local memory is shared in pairs. So, the screen location that was being modified for the second core also affected the first one. Got around this by creating a get_screen_address() subroutine to return the address of the screen for a core rather than simply reading a screen address vector as was previously done.

Latest Mods
Altered some of the bus states to make them retry-able. This was mostly moving the PC increment into a trailing stage, out of the bus access ack stage. Moved the PC increment into the decode stage for instance to make IFETCH retry-able. All the bus states may be retried simply by going back to the state containing the bus operation. This makes implementing retry relatively painless.

Latest fixes
Bit instructions were always working modulo 32 instead of modulo 32 for data registers ops and modulo 8 for other ops.

Latest idea
Making the bit instructions more powerful by making use of unused bits in the bit number to test value. For instance, when a constant is used, 16-bit are fetched for the constant but only the low order five bits are used. By using the other bits in the constant it would be possible to perform bit-pair manipulations as well as bit manipulations. I think this idea is almost backwards compatible as the upper bits of the value used should normally be specified as zero. This would break programs that assume the upper bits do not need to be zero.

Latest Quandry
The core does not check for illegal address modes. It merrily processes them as it encounters them. I think it is possible to do things like addi.l #1234,#5678 and the core will add the two immediates then update the code for immediate #5678. I am not sure how big an issue this is. Most assemblers will not allow illegal encodings so unless one uses a constant to define the instruction the illegal encodings would not be available.

Latest Mods
I missed the LINK instruction when modifying for instruction retry-ability. So, it has now been updated.

Latest Additions
Added an interrupt controller to the system. I am now trying to get interrupts working. Added the MOVES 68010 instruction.

Latest Issue
Blue screen without text appearing, and the keyboard is locked. I must have inadvertently altered some code causing an instruction to fail. But which one? In the logic trace I can see the keyboard being scanned, but there is no response when I press a key.
Then I noticed there was no network traffic for the update of the screen display.
Turns out the little keyboard controller on the FPGA board was not working. I noticed the LED was not flashing. Unplugging and plugging the keyboard back in again a couple of times got it working. I spent hours looking for a software issue, and it was just a hung micro-controller.

Latest Fixes
ADDA/SUBA was only updating for the long form of the instruction. ADD/SUB to a data register was not updating flags properly. ADD/SUB was always updating the register file, even for add to memory instructions. AND/OR/EOR were always updating the register file, even for memory operations.

Latest Quandry
LEA instruction can process (An)+ and –(An) address modes. It evaluates the effective address without updating the address registers and returns the value. This is different than the 68k where it is illegal to use these address modes with LEA.

Strange but true
It is faster to perform a multiply in rf68000 than it is to perform a shift operation. I have got into a habit of using shift operations instead of multiplies so, now I must think differently.

You have a multi-cycle shift? What kind of shift network do you use?

Yes, it is multi-cycle shifts. Just one bit per cycle. There is a giant case statement that takes care of all the combinations of shifts. An issue is the amount of shift logic that would be required as different widths of shifts are required, and then there is the generation of carry and 'x' bits. The 68000 has a wide variety of shift operations. There is minimal logic to a bit at a time shifting; it is simple and has a high fmax. I have considered using funnel shifters, but it is complicated. It would also likely lower the fmax and shift operations are not really used that often. Although a rotate by eight is used to swap byte order. I wish there were an instruction to swap the byte order around.

Latest Issue
If a bus error occurs the whole machine gets hung. This was happening when the primary core was trying to service an interrupt. Another core in the machine was trying to access a bad address to which there was no response, so the bus cycle was hung up indefinitely. This blocked all the other cores from working. The solution was simple, a bus timeout circuit was added to generate a bus error if the cycle was taking too long, and feed the error back to the core attempting access. All the bus error routine does ATM is hang the core in a tight loop waiting for a reset. The 68000 cannot really recover from a bus error. So, the offending task would be shut down by the OS.

Spent some time today outlining the rf65000 processor. The 68000 has some features that I like but it is a bit dated. It was designed at a time when a few megabytes of memory was a lot, and the number of pins on a chip was very limited. The issue today is that memory is really slow compared to registers. So, a machine with more registers would work better. Also compilers have advanced quite a bit.

Latest Milestone
Display of interrupt flag on screen. Interrupts are happening and incrementing a screen location.

Latest Issue
Interrupt outputs were being set to true by the network interface circuit if there was an interrupt, but they were never set back to false. This led to a continuous stream of interrupts.

Latest Fixes
1) The interrupt acknowledge cycle was incrementing the PC by two. Not sure how or why that got in the code, but it caused interrupt returns two bytes past where they should be resulting in incorrect execution of code.

2) The test suite fails in the CMPA instruction, but CMP works. The flags are not being updated correctly. This is strange since CMPA and CMP both use the same flag update code. This had to do with the address register improperly being sign extended.

3) Source and destination operands were swapped for CMPM causing it to fail.

4) Do not know how I did it, but I missed implementing the ADDX and SUBX instructions.

5) JMP and JSR were jumping to the memory location specified by the operand instead of the effective address specified. This led to a crash in the monitor program when an attempt was made to jump to code.

6) The MULS instruction does not update flags correctly. Again, this is strange since the only flags updated are zf and nf (cf and vf are zeroed out) and the same code is used as for MULU which works.

7) For ASL the overflow flag was not set properly. For all shifts the carry flag was not zeroed on a shift count of zero.

Fixed a crash in the test suite by moving a vector. I had used vector #64 as a trap for a bad branch displacement. Vectors 64 and up were reserved for user use. Well, the test suite uses that part of the vector table to store test data causing a crash when a bad branch was hit. Rather than modify the test suite, I moved the vector one lower.

Added a 4kB local ram for each core. There are a number of BIOS variables that need to be unique to each core. For instance, the text cursor position and screen location.

Latest Fixes
The MULS instruction was interpreting a whole long word as a signed value instead of a word signed value. The fix was easy, using the $signed() operator on the word values.
The CMPM instruction was not following the correct sequence of states causing it to fail to load the destination operand for the compare. CMPM still has issues.

Working on getting the BCD arithmetic right. The subtract was out to lunch.

The keyboard is interrupt driven now. Core #2 handles the keyboard interrupt. Alt-tabbing between screens reveals that only the primary core is working properly. Cores #8 and #9 clear the screen and display the startup message, but then do not accept keystrokes so I cannot tell if the monitor is working for them or not. The other cores #3 to #7 do not even clear the screen properly and appear hung. Passing keystrokes between the cores is interesting. It is done by having a common keyboard input buffer that is shared between all cores. (Switching which core has focus clears the buffer). Core #2 services the interrupt which then places the scan-code in the buffer. It should then be available to all cores, but apparently it does not work yet.

To handle BCD instructions the BCD number is converted to binary, the operation performed, then converted back to BCD. This approach allows any number of complex operations to be done. For the rf65000 there is going to be a decimal mode rather than BCD instructions. BCD still does not work. I’ve tried about four or five different things regarding the BCD instructions but cannot seem to get them to work.

ADDX, SUBX do not work yet either. It is a mystery to me since these are almost the same as ADD and SUB which work.

Added some more software. Coded breakpoint management into the monitor. The idea is to be able to set breakpoints in code and dump registers to try and figure out why the instructions are not working. Breakpoints are created by modifying code so that a “trap #3” is placed at the breakpoint address. The original instruction is recorded in a table. I chose trap #3 thinking of INT3 in the x86. I could only find sketchy information on the usage of traps in the 68000. One would think there would be a trap reserved for debug.