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.