Working on getting the graphics accelerator to work, and on getting lower resolution video modes to work.

Changed the module names so that the bus width is not part of it. Made the bus width a parameter to the modules, so any bus width may be used. Not quite finished this mod yet, there are a couple of more modules to convert. Good experience for keeping things up to date and running at the same time.

The frame buffer controller register readback was incorrect for registers at odd word locations. It was reading back zero instead of the register value. This was due to the use of a 64-bit wide bus internally, which is multiplexed onto a 32-bit bus. (The controller may be configured for operation with either a 64-bit or 32-bit slave bus). Write worked okay, it was just the readback. Since the controller is normally written and not read back this did not affect much.

Found a bug in the accelerator, there were two ack signals sent back for a single point plot. This would cause points to get missed.

Pondering how to add mass storage to the system. Maybe a serial flash pmod. The board has ample serial flash storage on it, but I would rather experiment with an external module. If something goes wrong, then the board is not kaput.

Been tangling with bus errors trying to read the DRAM. I have changed something just slightly and now the DRAM reads are not working as well. Just going though the file change history to see what changed.

The display got jittery, and I spent a while trying to figure out why. So, then I switched the video mode back down to 800x600 and all the jitter was gone. It looks like that clock buffer may have had enough of being over-clocked. It may also be other issues like meta-stability. The 800x600 clock is more closely related to the CPU and system clocks than the 1920x1080 dot clock. So, there are likely to be fewer issues with it.

Could you go to a 4 phase clock to read the dram?

I do not think it could be done at the frequency the core is operating at. It is running 200 MHz and the FPGA logic maxes out. Going to a four phase clock would mean cutting the operating frequency to at least half. I do not think there are timing issues with the DRAM (DDRAM) controller itself, but with other components interfacing to it. The DDRAM controller is interesting because it uses a 4x clock (800 MHz) and special DDR I/O logic. The DDRAM is access twice per 800 MHz clock. There is *loads* of memory bandwidth, it is just a matter of being able to use it. To get things running at the general FPGA's clock limits the DDRAM bus is widened by a factor of eight so a clock 8x slower can be used (done by special high-speed muxes in the I/O logic). On top of that components in the system use a max of 1/2 that so they are running at 1/16 the DDRAM rate.

The rendering machine in the graphics accelerator was locking up, staying in the same state. The state machine was thus re-written to use a one-hot encoding, it does not lock up now. Note the toolset often automatically converts state machines to one-hot, but since the state was being dumped in the logic analyzer it could not convert the machine automatically.

Finally decided to write a small test bench for the memory controller. Something that can be used to experiment with events. Found out that my round robin arbiter does not work correctly. So, I re-wrote it based on an arbiter found on the web from Circuit Cove.

Just barely missing timing in a couple of places. I tried it with the missed timing because it is only 100ps off.
I can a few more regs in a couple of places which may help.

Reads posts. Oh, you are already running a 4x clock for dram.
When I was playing with FPGA's, I had DRAM but could not find a free memory controller
for it so I stuck to static ram.
Nice how it tells you XXX does not meet timing, but no way to fix the problem with XXX.
It is the hold times that worries me.

Yeah, it is the vendor's core that uses the 4x clock.
I would like to see a board with a good chunk of SRAM on it, but they just do not make them. DDRRAM is too appealing, but one must find an appropriate controller.

Graphics accelerator and memory controller work a lot better now. But still not perfect. A memory dump aborted with a bus error after dumping about 8kB. There is the odd pixel that does not get cleared or set, but they are not too noticeable. Drawing lines is very fast. So is rectangles and triangles. But there still seems to be something off with the display of those shapes. There are too many horizontal line displays as if drawing the shape got truncated. Curve drawing did not work.

The screen clear routine is blazingly fast now. It appears to be instant. So, probably fast enough for some games. There is a hardware helper to set memory to a given value. That uses burst writes.

I thought I would be clever and use the DIVU instruction after random number generation to limit the co-ordinates to the screen since it provides the modulus (remainder) in the correct position already. DIVU would return the remainder in the upper 16-bits of the register, which is where it is needed. However, it does not work correctly. The routine looks like this:

Appears not to draw on-screen, or only horizontal / vertical lines, no filled rects or triangles. I have hard coded some graphics tests which can be called using the monitor's jump to code command.

Wrote a wishbone to axi4 lite bus bridge. It is mostly wires and little bit of combo logic. It may be too simple to work.

Switched the color depth to 32-bits RGB8888 as that is the color depth of the ‘plants’ simulation. Trying to get the simulation to work with no luck. It crashes right at the start.
The 32-bit color depth worked though. I have the video controllers specifying the color depth in terms of bits per color component. The pixel size in bits is then determined as the sum of the sizes of the components. If the pixel size is not an even multiple of a byte, then the graphics accelerator runs read-modify-write cycles to updated display memory. So, pixels can be any size. I got tired to trying to figure out whether to support 12 or 16bpp or other color depths, so just made it programmable.

Something is amiss with the displayed colors. They are coming out without a red component. Blue-green only. I could swear it was working yesterday. Also increasing the color depth to 32-bits did not work correctly. The display turned into vertical bands. About eight pixels on, and 24-pixels off. Strangely, unlike 16-bpp the colors were correct. Something has changed since yesterday.

I have been experimenting with graphics the hard way, by looking up routine addresses and using the jump command in the monitor. I finally decided to modify TinyBasic to add graphics commands. POINT, LINE, RECT, TRIANGLE, CURVE, COLOR, and COLOR DEPTH. It should be a little easier to experiment in TinyBasic. Now the trick is to get TinyBasic working again. Issuing the ‘BA’ command from the monitor caused a crash. TinyBasic has not been tested since before changes to the device drivers. I already found one bug, the wrong input and output devices were specified. The device numbers changed since TinyBasic was last updated. Fortunately, Tiny Basic does not have a lot of direct calls to devices.

Added a few more characters to the 8x8 text font. Some key characters like the comma, period, and a couple of others were missing. I did not bother filling out the font as I planned to use larger fonts.

I thought TinyBasic was working again until I went to write a small program. It did not store the line. Direct mode seems to be working. I know approximately where the code is failing, but am not sure why yet. It does go to direct mode. If I enter in a line number that is too large however, it does not spit out the error message when it should.

The compare at like 102 does not work properly. Either the instruction is toast or the value in d1 is not correct. I think it could also be the test at line 100 that is failing, causing direct mode to be entered all the time.

The only timing error was about 500 ps in the decimal float logic. Which should be okay as there are clock domain crossing regs in the path, and the CPU core waits multiple cycles for results from the decimal-float unit. I tried some float expressions and they worked.

Figured out the TinyBasic issue above. It was a bug in the CPU core. The value in d1 was always zero. I must have fat-fingered a signal name which happened to be a load signal for the float-to-int converter. That caused the FMOVE to fail with the result always zero. TinyBasic is working again. The system is so unstable though that it rarely operates more than a few minutes before crashing.

The ability to choose the display buffer (DISPBUF) and draw buffer (DRAWBUF) were added to TinyBasic.

Spent some time trying to get the spi master core working. I made some minor modifications to it. Added a reset signal for the SD card. A small test routine that writes then reads back a block does not work. The setup and write, read all execute without error. But there is no signal activity on the spi bus. Pretty sure the controller is connected correctly as the version number register dumps correctly.

Got the serial port going. It is now possible to transfer TinyBasic programs to and from the PC.

I noticed that drawing shapes from TinyBasic works a lot better than the test routine accessed from the monitor. It may be because TinyBasic is slower to execute the draw commands. On that hunch a 1 ms delay was added between each draw of the test routines, and voila, drawing worked much better – the horizontal lines were gone. I think that indicates issues with the buffering of draw commands. There is a stall signal fed back from the command queue, but it must not work properly. <- Fixed this issue, the stall signal was not connected. Fixing this made the system more stable.


Found an issue in the spi master controller. If a software reset is done, the controller would remain in the reset state.

A simple MMU was added. The system would not work with the MMU present. Thinking that the address translation would take too long for one clock cycle, the translation and corresponding signals were registered causing a one cycle latency. Did not work. So, the latency was removed as a trial operation, and then the system worked with the MMU present. It has me baffled. A one cycle pipeline delay should not have affected things. Apparently, the logic is so fast that the one cycle delay was not needed. The system is running with the MMU, but without the addresses being translated yet.

The MMU started out as an attempt to model the 68851 but ended up something different. The MMU has 2048 root pointers, one for each of an eleven-bit process id. The MMU can be enabled on a per process basis. It uses a 16kB page size and is two level, translating a 32-bit address. The first level, the page directory has only 64-entries in it. So, the root pointers point to a 256-byte directory (64 entries * 4 bytes per entry). This translates six bits of the address space. Twelve more address bits are translated using a page table containing 4096 entries in a 16kB page. A total of 18 address bits are translated. The low order 14 bits are untranslated. Translated addresses are stored in an address translation cache (ATC). ATC entries contain the process-id to keep entries unique to a process. The cache has 64 fully associative entries (like the 68851). Access to the MMU is not done via co-processor instructions. Instead, it is present as an I/O device.

The MMU automatically walks the page table and updates the ATC on a translation miss. Page faults are not supported yet as the CPU has no way to recover from one. So, the translation tables should be setup such that there are no faults. Or in other words an unmapped address will cause an exception that will likely drop into the monitor.

The graphics demo runs for about ½ hour then looks like it crashes. But it can be stopped with CTRL-C meaning that it is not a hard crash. Instead, it is still running the demo, but there is no output. I am guessing that the system loses track of where it is supposed to display the graphics and ends up updating memory somewhere else in the system.

The spi master still is not working.

Added hardware flood-fill to the graphics accelerator. Somewhat tricky as the flood fill algorithm needs to read pixels before deciding which ones to set. It is also somewhat limited as there is a hardware pixel position stack involved and it only contains a few thousand entries. Large oddly shaped objects may not be filled correctly. The floodfill remains to be tested, but was ported from another video controller I wrote a few years ago.

Added two i2c master cores, one to control the audio codec, the other for a real-time clock. I hope to debug the real-time clock before tackling the audio codec. I did not write the i2c master core. Instead, I am using one available on opencores.org.

Added the PSG32 programmable sound generator, written years ago, but updated recently. It was easy to tell the core was fairly old. It was limited to four channels and using a small BRAM to store wave signals. It was upgraded to eight channels and the use of main memory to store wave samples. The core is neat in that it has both wave table and ADSR generation capabilities. Needs the audio codec interface to get things going.

Added a lot today but have not got around to testing it.

Finally got the RTC to respond. It almost works. Reads the registers then hangs. The RTC read routine dumps the register values to memory. After a reset, it can be seen that the default values of the RTC registers are stored in memory. Did a couple of side-steps along the way. Had the RTC connector plugged in upside down to begin with. Fortunately, the power was not connected in this configuration. This resulted in no data read from the RTC, but the read routine did not hang. The next snag was having the port signals located on the wrong port pins. They needed to be connected to a lower set of pins instead of the upper set. The third snag was having the register dump located in memory offset by 20h. The bytes were placed 20h bytes further up in memory than expected, and the first few dumps done did not reveal the register values as enough memory had not been dumped. I have some confidence now that the i2c master controller works. I put some CTRL-C checks in the RTC routines now to be able to break out of waiting loops. I suspect the loop termination is not quite right causing an infinite wait loop. Writing to the RTC does not seem to work. The time registers are not being set. Not sure if there is a lock-out of some sort active. More reading up on the RTC clock is in order.

Cannot get the spi master controller to work. Not sure if it is the controller or some other factor like a bad SD card. It is always returning an error on command zero (CMD0). In the logic analyzer it can be seen that the FF’s are being sent as part of the initialization sequence, so I am pretty sure the controller’s sequencer is operating. I tried some modifications to ensure the startup frequency is the slow SPI clock.

https://elm-chan.org/docs/mmc/mmc_e.html
spi stuff

Thanks, strangely I found almost identical information on another webpage. I have been reading up on SPI the past couple of days. There is loads of info out there some of it good some of it not so good. The signals being generated look good to me in simulation and it almost works now.

Got the SPI to respond further. It is now getting past the CMD0 but falters on a CMD1. The SPI master was defaulting the data out to a zero. This was switched to a default of one. In theory it probably should not make a difference, but the card seems to like it defaulted to one better.

Have not gotten the RTC to work any better. I am beginning to believe that maybe the chip is a bit fried. It was sitting in a box for several years. Register values are appearing in what is supposed to be the SRAM part of the chip. Perhaps the address auto-increment is not working.

Added a simple co-processor with access to the audio and video circuits. It is integrated into the audio/video bridge connecting the graphics accelerator, frame buffer, text controller, sprite controller, and sound generator to the rest of the system. It is the same concept as the Amiga Copper. Gave it its own small BRAM for program storage. Access to the main memory is a bit chaotic and unpredictable and likely would not be a suitable place for program storage. The copper instructions are 128-bit. Expanded to account for larger position values. The horizontal and vertical positions can be specified up to 16-bits.