Instructions were being marked done or out even though they were no longer valid. This caused an issue when a new instruction was queued as it was marked done immediately.

The serial port is breathing now. A continuous stream of ‘A’s was sent to the port and received as ‘B’s by the terminal program at the wrong baud rate. At least there is a connection established and values can now be sent through the port. The bad baud rate turned out to be a port initialization routine that did not get called, because of the previously mentioned ‘marked done’ issue. The subroutine call was being marked as done before it executed.

The ’A’ stream is worked now at the proper baud rate. Now to try something more complex: putting a string to the serial port.

Finally got around to adding support for unaligned loads, unaligned stores were already supported. Support amounts to running a second bus cycle and appropriately shifting the incoming data. Alignment is in terms of the cache line width or 64 bytes, so most loads and store do not require a second memory cycle. Unaligned memory access is an option as it requires more logic.

Putting a string to the serial port just does not want to work. The putstring() routine is executed but no characters are coming through the port. It is strange because putting a constant stream of characters worked, meaning the port is working. I stepped all the way through to putting the first character in the ACIA in simulation and it worked fine.

Got some more of the boot ROM coded while waiting for system builds. The boot ROM now includes xmodem file transfer routines, and keyboard routines as well.

There is some sort of bug in the CPU. If I can figure out when it occurs it may be possible to work around it. I tracked a bug to the cursor position increment routine at a spot where it pushes then pops two registers. I made a short routine performing the same operations and it worked fine. So, I have not been able to isolate the bug yet.

Found a bug in the CPU where the out and done states were being set at the same time. I believe this should not be possible. After a thorough search for the culprit it could not be found. So, I tied the state variables to a functional unit, ensuring that only the owning functional unit is allowed to modify the states. That seems to have cleared the issue up. It is only a little more logic.

The BBS and BBC instructions were not fully implemented leading the CPU to hang when one was encountered. The register form of the instruction was implemented, but not the more useful immediate form.

Added partial support for the decrement and branch instruction. I am not sure this instruction will be supported and it is not documented yet.

The core now manages to output the first five characters of the startup message to the serial port after which it hangs. Because it is in the middle of a stable loop, I am guessing that it missed an ack pulse from memory. So, bus timeout logic was added to the core which will cause up to four retries of the bus operation after which an exception will be triggered. The bus timeout was set to 256 clocks as it may take hundreds of clocks to access the dram.

The bus timeout logic turned out not to work.

Registered the branch miss signals to improve the timing. The effect is to delay the branch miss action by a clock cycle. With good branch prediction this does not impact the performance. An issue that becomes apparent is back-to-back branch misses. The branch miss signal becomes active for more than one cycle and only the first branch miss should be processed.

Limited panics in the ifetch stage to simulation to reduce the amount of logic. It is not terribly useful to panic in real hardware as about all that can be done is reset the machine. It is much more useful during simulation to see where there are hardware mistakes.

Added an option for queuing a single instruction rather than two at a time. It is less logic. The option does not work yet.

Added an option to force ordered execution of flow controlling instructions. This may help eliminate false branches, but increases core size.

In leaf routines micro-code dedicated registers were used as a temporary place to store values rather than storing on the stack, saving memory operations. The micro-code for pushing and popping registers uses the dedicated registers, so register usage is no different.

Changed the memory issue logic. Previously all stores were forced to be in-order. Now all IO operations are forced to be in-order. Non-IO stores may occur out of order now and IO loads must be in order. Previously loads could have been out-of-order which does not work for many IO devices.

Tried numerous tricks but still stuck at about five characters of the startup message being output to the serial port. So, going to work on the display function to see if bugs can be identified.

The shift immediate instruction opcodes were not properly defined causing them not to work correctly. This showed up as the LEDs not lighting up as expected. After fixing the shift instructions LEDs still do not light up as expected.

Screen clear is clearing the screen to black with red characters now, which is not the correct colors. It is a bit strange because the screen address and size is stored along with the text attribute and those values are coming through correctly. Things can be made to work better by hard-coding values rather than reading them from memory variables.

Pretty sure issues arising because loads and stores are not always working correctly. So, I wrote a small checkerboard ram test routine. The ram test passed. Not convinced things were working, I wrote a slightly larger routine which writes random values to random addresses then reads them back. That test failed. So, there is an issue with memory loads and stores.

Tweaked the data cache controller and the TLB.

Decoding the target register for shift operations was missed causing all shift results to be discarded. The second operand for the shift instructions was encoded as zero causing shift results to be zero.

Backed out the registering of the branchmiss, it was causing issues with register validation. Rather than add more logic to resolve the issue it is simpler to go with an unregistered branch miss.

Yet another issue with shift instructions. This time they were not included in the source valid functions, leading operands to be incorrectly assumed valid.
Blinky LEDs are now working correctly with the latest fix to the shift instructions.

I decided to remove the cache-ability field from load and store instructions. Cache-ability is now controlled strictly through the MMU memory page and region. It turns out that the hardware just ignored the cache-ability attributes coming from the instruction anyway. Removing the bits from the instruction format gives two more bits for a displacement or other use.

Changed the base clock of the ACIA to match the CPUs clock. Previously it was set to 100 MHz as a reference for the baud rate generator. But this resulted in CPU bus cycles being perceived as multiple accesses by the ACIA. Added a baud divisor table for the cpu clock rate.
Tried running the serial port at 57600 baud and a stream of ‘A’s was received as ‘P’s. The baud rate may have been 1% off and the USB serial connection seems a bit finiky. Reducing the baud rate to 9600 worked.
Got a routine to load a buffer from the serial port and dump it to the screen to work. It has been setup now to load a buffer at 0xfffde000 and jump to it. This should be able to be used to bootstrap the system. Hopefully the system will not need to be rebuilt for software changes.

Can the bootstrap software calls be set up as real network , but the dummy parameters passed set things up for the ACIA?

I am not quite sure what is being asked. Are you referring to a network software stack? There is no networking software developed yet. There is only a handful of serial IO routines which are in the boot ROM. The ACIA is initialized by the SerialInit() routine which is called shortly after boot-up, before SerialGetBuf(). The parameters for the ACIA are hard-coded in SerialInit(). The ACIA is a beefed up 6551 compatible.


It is a long-way yet before an OS can be run. The processor itself or the support system seems not to function 100% yet. No plans to try and debug an OS on a buggy processor. Working on getting a simple monitor program to work first.
Still working on the serial bootstrap. The buffer gets loaded but the jump to the loaded address is not working. I have the ramtest routine being loaded as a test program and it never starts. I have fudged things in the SerialGetBuf() routine to dump bytes to the screen as it is loading the buffer and the loaded routine’s address has been hard coded.
Been watching TV during system builds so I have been somewhat distracted.

Found a way to reduce the core size by about 3k LUTs. Removed a set of results forwarding, and made use of register file bypass instead.

The MOV instruction was not included in the source valid logic causing it to act as if source registers were valid automatically. This led to moves of incorrect values.

Changed the sequence number decrementers to ordinary subtractors from saturating subtractors to reduce logic requirements. Sequence numbers start out at 0x3f and decrement whenever a new instruction is queued. Since there are only eight queue entries they should always be greater than zero and not need saturating decrementers.

Removed several adders in the ifetch() module to change the “fetchbuf” state. The value of fetchbuf is already known so there was no need to include it in the adds.

I believe something is still amiss to do with branches. The code to convert a byte to ascii text does not work correctly. Sometimes the result is “?F” instead of 8F. I think the “?” comes from adding 7 to the intermediate result, “8”, when it should not be. This indicates the “ble” in the code below is not working. It looks like the ble itself may work, but the next instruction is being executed and it should not be.

Working out this bug is slow going as it takes almost an hour to build the system. Trying to recreate it in simulation is a challenge.

Got the gselect branch predictor working. There are now two supported branch predictors. The branch predictor is chosen at build time by a config constant.

Added a PERFORMANCE config parameter to choose between performance and core size. There are a few places where this trade-off can be made. Choosing performance increases the core size but also increases performance.

On the notion there is something amiss with branches, the branch miss logic was setup to always indicate a miss. This lowers performance but should still allow the core to work. Setting the miss to true for all branches forces a flush of the instruction buffer.

Found a bug in the dcache controller which caused the core to hang. An ack was not being sent back to the main module when it needed to be.

Decided to take a break from the processor to work on a model railway.

All change - hope it's just as satisfying!

I think it will be. I cannot spend all my time developing a CPU core. I had a model railroad a few years ago, but I sold it when I moved. I have gotten slightly more ambitious now.

Slightly OT.

Still using the FPGA to hopefully control some parts of the layout like remote switches. I may go with an FPGA with an ARM processor built-in. Otherwise, I may use the 68k core which seems to work.
Remote track switching is going to be done by RC servos which require properly timing pulses. I think an FPGA would be ideal for generating the timing pulses. A set of on/off switches would be input to the FPGA, one for each track switch. Each on/off switch would be connected to timing logic in the FPGA which would then drive the servos.

It is just a step away from driving servos for robotics. The train set is a sort of a robot.