Wired up an ADAU1761 audio codec interface circuit. It is an interface used already on an earlier FPGA board. Everything should be wired now for audio I/O. Wrote a small test routine to output a 600 Hz tone for three seconds at startup. Did not work. No tone output.

Had to slow down the system clock to 50MHz, ran into timing issues with the MMU present.

Found a bug in the RTC clock update routine. The address was not updated, it was fixed at zero. So, the first byte of the RTC clock would be the only one updated. Also found an error in the time display routine. It was passing the wrong register to the byte display routine causing a zero to be always displayed.

Experimenting with loading S37 format files. Updated and reduced the size of the loader program – 350 bytes. The serial terminal program strips both carriage returns and line feeds from a S37 file, leaving it one continuous long stream of characters. The loader needs at least line feeds in the file. The terminal program was then set to transfer the file as a binary file. The loader was reading one too many bytes from the S37 file causing the checksum to be off. Worse yet, it did not properly load the next line. Roughly every other line of the file got loaded.

Still working on the RTC. I decided to try writing the driver in C. Hence the need for a program loader.

I found a bug in the CPU. It was fetching data from the calculated address during a LEA or PEA instruction for some address modes. Usually this would just be a performance issue of running an extra bus cycle. Except that for some I/O devices an extra read can clear status when it should not be. This bug was found by inspection while looking for another software bug.

Fixed it good. There was no bug. Tried the fix and things did not work.

Trying to track down an ornery bug. It happens when an S19 file is loaded by the loader. Part of the loader code gets overwritten with zeros, causing an illegal opcode crash. I cannot see where in software the issue would be which makes me think it is a hardware issue of some sort. <= found this issue, was a software bug, the address was not copied to an address register.

Added big-endian bus access support to the graphics accelerator and the random number generator. More to follow. Whether the bus access is big-endian or little-endian is determined using one of the address bits. Little endian being active when the address bit is zero, otherwise bit-endian. Reversing the byte order for I/O access was creating a coding headache. Now it is simply determined by the I/O address used. This can be easily setup in a table of I/O addresses. There is little hardware overhead, it is mostly just wires.

Changed some of the address decodes for I/O devices to align them on 16kB boundaries. 16kB is the MMU page size. This allows devices to be mapped on an individual basis.

Also some more mods to support big-endian.

Added support for extended double precision operations. Not quite 68881. The significand is 80-bits instead of 64-bits. IIRC the 68881 does all operations in extended precision then converts the results to other precisions as needed. Currently decimal float and extended double precision cannot be present at the same time.

Got a ‘multiple drivers’ error on an overflow signal. Near as I can make out there should not be an error. So, to be able to build overflow detection is disabled for that function.

Lots of effort into getting a demo running via loading as S19 file. Fixed up the binary floating-point for the CPU. Do not know if it works at all, but the code is in place without breaking the decimal floating-point code. Trying to get decimal floating-point working from within ‘C’ code. The compiler is being tricked into using decimal floating-point by taking over the binary float-point opcodes and using them for decimal-float. The compiler should not know the difference. One gotcha is that the compiler spits out code for floating-point constants as binary floats. That means constants cannot be used directly since decimal-floating point operations are present. A small routine was written to convert strings of numerics to decimal-floating point. This should allow the use of decimal-float constants indirectly in ‘C’ code. An important difference is the constant string is evaluated at run-time, so the program may be slightly slower. Constants should be evaluated once. Sample usage below. “double” is actually a double-precision decimal-float in this case.


The conversion routine does not work in ‘C’ code yet. It is an adaptation of the routine used to get decimal floats used by the system and TinyBasic.

Upgraded the toolset version after a certain anti-virus tool toasted the current version. Could not figure out how to remove it from quarantine *without* subscribing to the anti-virus.

With the new toolset version: timing errors everywhere. Where with the previous version there were only a couple of timing errors. According to the new toolset, the memory controller won’t work past 100 MHz. That could explain some of the stability issues if the timing was off. I tried it with the timing errors and it still seemed to work. Since timing errors are according to clock edges, if the timing is off, it just means the signal may not be processed until the next clock edge. In many cases this is still acceptable to operation.

Fortunately, most of the memory controller does not need to operate at the 200 MHz rate, while still getting and sending data at the max rate.

Responses back (data and valid) from the MIG controller need to be latched at the 200 MHz clock rate. Command signals going to the MIG controller also need to be at the max rate. If the command signals are not limited to 200 MHz pulses it will trigger multiple read and write operations. For example, if the read command is present for two clocks, it will read twice from the DDR RAM. It may not be an issue reading or writing the same address multiple times. But there is an issue when burst accesses are being performed.

The keyboard buffer was not being cleared on a reset. So, after resetting the system old keystrokes were still in the buffer.

Graphics accelerator stopped working again. It turned out the circuit select signal was not being activated. No commands were getting through. I re-wrote the select signal to come from the AV bridge instead of the main SoC circuit selects. Chip select is now being generated but the graphics system still does not work. It may have to do with new timing for the memory controller.

Added a PowerPC compatible CPU core as a system option. Currently it is just hooked as a device connected to the memory controller. To get it to work programs would need to be stored in the main memory. Since main memory is not well working at the moment, testing the PowerPC CPU has been put off.

The display resolution was switched to 1024x768. The clock system could not generate a required dot clock rate of exactly 65 MHz and its five times serial rate (325 MHz) but it could come close. The dot rate is about 64.4 MHz with a 322 MHz serial clock. About 1% too slow. Seems to work. Given enough cascaded clock generators or PLLs the frequency could probably be generated exactly.

The system is losing track of which core has the I/O focus. This leads to a non-responsive keyboard and a lack of cursor update on the screen. Cores not having the focus are sent a no-character available response if a character is requested.

Spent some time keying memory management routines in assembler.

Now the keyboard no longer works. I think this has to do with the same issue with the I/O focus. The I/O focus core was hard-coded to a ‘2’ then the I/O focus issues went away. This indicates that the stored value is getting corrupt somehow. The same SRAM is used to store the keyboard buffer and status. It seems to me something is amiss with this SRAM, which was previously working. So, a RAM test routine was written.

This RAM is globally accessible and used to store values common for all cores. The PAM (page allocation map) for memory management is stored in this RAM. So are the keyboard, clock and serial port buffers.

Added device discovery black-box to the graphics accelerator and the serial port. Dunno if it works, the keyboard needs to be working first. The device discovery box allows the circuit select lines to be programmable. It also identifies that a particular device is present in the system. It also handles interrupts for the device. When the system boots it can search for device discovery black-boxes to know which device drivers need to be present.

Are general purpose interrupts required?You have ample FPGA power, for a simple CPU and dual port memory for a smart device
for any i/o used.

Not really required, a second CPU could be used to do polling. But I like to support them.

Keyboard is back. The ack from the scratchpad RAM was delayed an additional two clock cycles for writes, and it seems to work now. In theory it should not matter. Error logging during the scratchpad RAM test revealed the output was always zero. Meaning either the RAM never got updated or there is an issue with the readback path. In this case the RAM was never updated. An extra register in the readback path improved the RAM timing just enough that timing was met for the build. Usually, it is off a few pico-seconds.
Got the memory controller working back up at 200MHz again. Specified all the clocks to be asynchronous to each other. It made it easier for the tool to meet timing. I have yet to fix up the cached access to the RAM.

Started working on a new interrupt controller. This one using a message signaling approach. Device interrupts are daisy-chained to the interrupt controller. The device provides an eleven-bit vector number, operating mode indicator (system or user), and an interrupt priority level. The interrupt priority level may be omitted by having separate daisy-chains for each interrupt level. The interrupt controller takes the message input and looks up the interrupt vector. For message signaled interrupts, when the CPU runs an interrupt acknowledge cycle, the interrupt vector is returned on the data bus, instead of a vector number. The task of looking up a vector is done by the interrupt controller. This does mean the 68000 core needs to be adapted to handle MSI, while at the same time supporting the original approach.

The bootup is not finding any devices when scanning for device discovery black-boxes. There are currently two devices with black-boxes, the graphics accelerator and the uart.

Bootup now finds the two devices, but does not report the device names correctly. There was a circuit select decode that needed to be added. There is connectivity now to the black boxes. Adding a box to the uart broke serial communications.

Things are busted at the moment, not even clearing the screen at startup. It does cycle through the 3 seconds delay loop lighting the LEDs so it must be close to working. I have been going back through changes to try and identify what changed that caused it not to work.

The previous bug had me baffled. I traced the startup of the CPU and it is incrementing through memory until it reaches an invalid address at which point it is hung. I have no idea why it is incrementing through memory. After a reset it starts at address $410DA and increments by two bytes at a time. It looks like it may be an instruction fetch. It is not starting at the reset address however. A zero is fetched if it is an instruction, which would be an immediate OR to d0. It occurred to me that I changed the MMU slightly. It was adjusted so that the read/write pulse to the MMU’s registers is only one cycle long.

Figured this one out. The CPU was loading the stack pointer value into the PC on reset. So it began fetching instructions from an empty stack (0) which just caused the PC to increment until it hit the end of the memory at which point it hung.

Found several bugs that make me wonder how the system worked with them. For instance, a PLL locked signal was not set to any value. When this happens synthesis typically decides to assign it some value, in this case TRUE. So, the system immediately thought that the PLL was locked, meaning no reset was being generated. (Reset is generated when the PLL is not locked).

Another bug was the CPU was not waiting long enough for the bus ack signal to go inactive. This caused the CPU state to advance too quickly. When there were two consecutive states performing a bus access, the second bus access would see the ack from the first state and assume the access was complete (if the ack pulse was too wide). This caused the incorrect value to be loaded or stored to memory. The system worked because most of the time there were not consecutive accesses performed. For instance, data was aligned according to its size. So, 32-bit data took only one bus access. Where it showed up occurred when an instruction fetch needed a 32-bit displacement or immediate value and the instruction was aligned such that the value crossed a boundary.

Almost back in business. The screen clears. Then the text controller is found as a device 1024 times. The monitor program shows up and keyboard input is possible. The serial port still does not work. Graphics screen is messed up now.

The text controller is found just once now. An address decode issue was resolved.

Updated the graphics rasterizer module to a one-hot state machine.

There are issues with triangle drawing. Not all points are being drawn giving the display a moire effect. It is artistically appealing, but incorrect. Drawing does a much better job of lines and rectangles. All points seem to be drawn for lines and rectangles.

Added a process id register and register stack to the CPU. The process id is automatically stacked to an internal stack on a TRAP and unstacked on an RTE. The idea is to support using a PID (process id). The MMU needs the PID to set the root pointer for address translations. Still thinking about this mod.

In the I/O bridge, the data was being cleared too soon when an ACK arrived. It should have been cleared when a NACK occurred. This issue would lead to reads of zero for the data for devices that were slow to read the data. Fixing this issue improved the operation of the serial port. Serial port is almost working now. It interrupts on received data, and manages to catch the first character.

Serial port is working again, at least for receive. It is possible to transfer S19 type files. A small demo written in ‘C’ is not working. There is a pointer amiss and it hits an address of zero. But at least it is loadable into the system, without having to rebuild the system.

Put some work into the OS and file system. The standard C library compiles. Now it is just a matter to writing a handful of support routines for the C library.

I was not able to figure out how to get the linker to build libraries. I tried several different linkage options which did not work as desired. Instead, to get a library file of routines, all the source code for the library was concatenated together then compiled as a single giant ‘C’ file. The assembler was run against the output of the compiler, which was a single file. The result is a single .o file containing all the routines in the library. A somewhat round-about way of doing things. Sample instructions in the makefile: