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.