There is effectively a read/write queue for each channel as there are fifos at the channel request inputs. Multiple read and write requests may be in the fifo. However, reads cannot snoop writes as it is just a fifo.
Writes are usually posted in FTA bus unless specifically requesting an ack back. So as soon as a write it stored in the fifo operation may proceed.
Snoop logic across eight channels would increase the size. It requires comparators for each queued write request.

It may take 30 cycles or more to perform a read / write to DRAM, but that is at a 200MHz clock rate. At the typical bus rate of 100MHz that is only about 15 cycles. Then at the typical CPU clock rate of 50 MHz it turns into only about 7 cycles.

Spent today trying to get the memory controller working. I think it may be working for streamed reads. At least there is a graphics display of bytes dumped from memory. The display seems stable but I am not sure the colors are correct. It could be that data is not being read correctly. I can tell data is being read for the display by using the monitor’s fill bytes command to fill the display memory. Using the command shows the colors being updated on screen. So, something is happening. ATM however, the bitmap display is in black and white, it is not supposed to be.

Using the monitor’s dump bytes command on the display memory results in a bus error message and no bytes dumped. So, readback through the memory controller for non-streamed reads is not working yet.

The bus error routine was modified to drop back into the monitor after displaying an error message. Previously it just sat in an infinite loop.

Complicating things is the fact that the integrated logic analyzer cannot be included in the project. Including it results in a mysterious error message. I am not sure which signals are causing an issue. I have tried re-arranging things several times with no luck.

Modified the IO bridge(s) slightly to filter out addresses with the high order eight bits equal to $FD. Previously they filtered on the high order 12 bits for $FD0. Some additional peripherals were outside the address range.

Fixed up the non-stream, non-cache access of the memory controller. Accesses do not have to go through either a stream buffer or the cache. Both can be bypassed. Performance of such access is very slow however. It may have to wait hundreds of cycles for other accesses to complete.

Got memory reads happening, at least for non-stream and non-cache access. Reading and writing data looks scrambled though. One a hunch, I shifted the address lines to the DRAM controller to the right by a couple of bits. The DDRAM is 32-bits wide, so the two least significant bits do not need to be passed on the address bus.

It turned out that for memory reads the ack pulse was too narrow. It was the width of one memory controller clock at 200 MHz. It needed to be the width of one CPU clock at 20 MHz.

Got the DDR RAM working much better now. For a while I had trouble figuring out why the screen was being filled with white pixels. It turned out that I added a check for CTRL-C to the fill loop and that set the same register as the value register to a -1 which is the color white on the display.

Screen update is noticeably slow, given a 20 MHz CPU that is probably 3 MIPs and a lot of pixels to update for the hires screen, it may be expected.

Reading through the system cache does not work yet.

I need some 68000 games that are ROMable and easily adapted.

Milestone:

Double checkerboard memory test passed. The double checkerboard test does a checkerboard test, then inverts the checkerboard and runs the test again. No errors.

Made a burst write controller with the idea of clearing the screen at a high rate of speed. Did not work. Strikes me as strange as both burst read and burst write are almost the same and burst read works for loading the streaming fifos.
The screen clear of the hires graphics screen (800x600x16bpp) takes a good part of a second to have the CPU clear the screen using ordinary MOVE instructions. It could be done an order of magnitude faster with dedicated burst writes.

Wrote a line-draw routine to support games. Wrote some code to emulate the traps of Easy68k.

Ported an asteroids game over to the system.

Considering implementing the graphics accelerator core in the system. But I think I will just stick with 68000 code using multiple processors for the graphics.

Could you emulate the AMIGA computer chip set for faster graphics?

I probably could. I made something similar a few years ago when I studied the Amiga a bit. IIRC the Amiga chip does not do some of the more complex things like triangle shading. Making a clone of the Amiga would be challenging as it shares bus phases with the video I think. The controller I used in the past is from opencores.org, the ORSoC graphics accelerator. IIRC it does some triangle shading and texture mapping. It worked fairly well. It is a bit dated. I have been thinking of a GPU approach. The Nyuzi CPU/GPU might work.

Got the point plot using hardware pixel plot. The color, and X, Y co-ordinates are specified in a register, then the plot command also specified and the frame buffer controller will plot the point at the given X, Y location. This is faster than having the CPU compute the address and plot the point. The controller also caches the memory strip containing the pixel, so if another plot is made to the same memory strip the memory only needs to be written. Otherwise, memory must be read, updated, then written. The DDRAM controller handles everything with wide access.
Plotting a point looks like:


1920x1080 video is working. It is just about the max the FPGA can do. Got a timing warning that the max frequency a clock buf is guaranteed to operate at is 709 MHz, and the video mode needs 742.5. Since this is only about 5% higher, I thought I would try it and it seems to work.

Found an error in the frame buffer video controller. One of the address lines was not hooked up. This led to incorrect displays. Address bit 13 got missed when the memory map was changed to map 16kB pages instead of 8kB pages.

Doing a long memory dump with 1920 video mode active causes bus errors. I think maybe because of conflicts with the video access. According to my calculations there should still be plenty of time to access memory. Data for the display is fetched using two bursts of 60x16 pixels for a scan-line. This should take < 100 clock cycles per burst or 13 CPU clocks. There are about 300 CPU clocks on the scan line. The frame buffer is using only about 5% of the memory bandwidth if my calculations are correct. So there should be lots for manipulating other objects like textures.

I have been trying to get asteroids working. No luck. Does a video page flip then crashes.

Worked on getting the system to operate through device drivers. Separated out some of the boot code into device driver files. The device driver control block structure is fairly large, currently 132 bytes. And contains mostly pointers to data and indexes. Got screwed up on big endian. The I/O devices expect things to be in little endian, so pointers and colors etc. have to be written to registers as little endian values.

Updated the graphics accelerator for a 256-bit wide bus and incorporated it into the SoC. The graphics accelerator is going to be used as a rendering engine. I have got as far as being able to access the graphics accelerator registers without bus errors, but no output is being generated yet. The system is not very stable and frequently crashes.

It is possible to write to the bitmap display using the fill command in the monitor. It seems to work. But until some lines are output for verification, it is possible that there are display issues.

At the same time, the keyboard is no longer working. The keyboard periodically stops working if left on for several hours. I am not sure if it is the keyboard or the PIC micro-controller on the FPGA board. But if the board is power cycled, or the keyboard unplugged and plugged in again, it starts working.

Testing the graphics accelerator, it seems to be non-functional. But a test routine of the display of 10,000 random rectangles does not crash, and it does not hang. It also takes a couple of seconds to run. I am getting the impression that the accelerator may be working, just not writing the correct memory address for it to be displayed. So, on the assumption there is an issue with the memory address, I set the graphics screen size to encompass the entirety of memory. That way if the random rectangle is bound to hit the display somewhere.

There appears to be an addressing issue with the frame buffer. The test diagonal line draw does not work as expected. <- this may be fixed, pending the latest system build.

Bin working on the frame buffer and graphics accelerator among other things, and I am wondering if to support 16 bpp color? Seems to me it has fallen out of favor. If it is no longer a commonly supported color depth, then maybe it should not be in the design.

The controllers being worked on are going to support four color depths and it is a choice between 12 bpp and 16 bpp. At one point, all the pixel sizes from 1 to 10 bits per color component were supported but that was wasting hardware.

I have seen recent video resolutions of 8, 12, 24, and 32 bit color, but no 16 bpp color. It strikes me as strange. Why is 12 better than 16?

The display repeats. The right half of the screen is the same as the left half. I have not been able to figure out why yet. It takes two bursts of data to fill the screen. It could be that the address for the second burst is the same as the address for the first. Or, it could be that the first burst is repeated by the memory controller. Since there is a clock domain crossing in the memory controller, there may be timing issues for the incoming request. The memory controller clock is double the frequency of the frame buffer. There is an asynchronous fifo used to cross the clock domain, so there should not be issues.

To try and detect if it is an address issue or a controller timing issue, the number of bursts required to fill the screen is going to be increased by reducing the size of the burst. If it is an address issue then the screen will repeat multiple times. Hmm, that will not detect the issue.

Finally decided to increase the size of the burst so that the entire scan line is fetched in one long burst. This avoids the issue of bad address generation. The burst works out to about 128 clocks at 200 MHz, or 64 clocks at 100 MHz, or about 13 CPU clocks. Increasing the burst size was not simple. The burst length field did not have enough bits in it. So the size of that field was increased. This increases the size of the bus transaction by two bits for all bus transactions. (Changed the length field from six to eight bits).
Increasing the burst length fixed most of the display issues. There is no longer a left-side right-side repeat. However, the display after about line 1024 is not correct. Instead of continuing the display of a diagonal to the bottom of the screen, the diagonal veers to the right making the appearance something like a hockey stick.

Forgot I added target area co-ordinates to the graphics accelerator a while ago. It has been a while since I used it last. Without the target area set, all points end up being clipped from display resulting in no output.

Still no output from the graphics accelerator. I found one issue with the addressing. It was shifted five bits making addresses 32x smaller than they should be.

Graphics accelerator still not working. I checked the accelerator’s register values by dumping them with the monitors dump command. It looks like the registers do not always get updated when written. Writing the registers is done in a convoluted fashion; it does not take place directly. Instead, a queue is written with the values of registers to update and the controller updates the registers from the queue. This is necessary to queue the drawing operations. It could literally be thousands of clock cycles before the register update occurs. So, one cannot just simply write the register and read it back to see if the write worked. To get around missed updates, the controller driver writes most registers five times, to increase the likely hood that the register gets updated. For many operations this is okay to do. For example, repeatedly setting a point position does not affect the resulting display. It is just a performance issue. Some operations cannot be repeated. For instance, the triggering of a draw operation. In that case it is hoped the draw operation succeeds. If rendering a dynamic display that gets refreshed, it may not matter if a single draw operation gets missed. It would likely be unnoticeable.

The depth of the fifo was increased to help compensate for the extra updates.

I have used the controller in the past and it did not seem to have issues with register updates. So, some more investigation is needed. Repeatedly updating the registers is just temporary. In the past, the controller would run for four to five hours then hang.

I have re-written the register update code a couple of times using slightly different mechanisms and the result is still the same.

> To get around missed updates, the controller driver writes most registers five times, to increase the likely hood that the register gets updated.

Yikes that doesn't sound good. Even though you're having a struggle to get the bugs out, and I do sympathise, it does feel to me that adding machinery which is there to hide bugs could be counterproductive.

Yeah, it is not a very good idea, but sometimes it allows progress on other fronts. I took out the duplicate writes as things are working a bit better now.

Figured out another issue with the graphics accelerator. This time in code. The accelerator expects points to be specified in a 16.16 fixed point format. The test code was assuming the co-ordinates would have no decimals to them and hence were 65536 times too small. They all ended up as zero. The issue tracked down the hard way, by tracing back why the update address was always zero.

Shades of an early personal computer. The video display is supported with a periodic burst scan taking about 150 clocks. The CPU and the video can alternate with the CPU getting most of the bus bandwidth. The CPU has a “bad” spot for accessing memory similar to the bad scan-lines in a C64. This is shortly after the horizontal sync.

The next thing to work on is the sprite controller. The sprite controller has 4kB buffers for each sprite. The entire buffer could be loaded with one burst 128 in length.

The accelerator sort of works. The test routine displays graphics in the upper half of the screen, and divided into right and left halves. It looks for anything like an addressing mistake, except that the very same component is used in the frame buffer which is working now. The display is supposed to cover the entire screen. I do not know if maybe it is the random number generator. So, I am going to try drawing some fixed rectangles on the screen.

Think I figured out what the latest display issue was. The color depth register was being reset to a different value causing the number of bytes per pixel to change. This ultimately resulted in pixels appearing at the wrong location on-screen. This was a software issue. Manually setting the color depth register properly fixed the display.
There is another issue now however, there are too many horizontal lines displayed instead of rectangle and triangle output.

Added strip writing capability to the accelerator. For rectangles, if it detects it can write a whole strip of pixels with one operation it does. This can speed things up an order of magnitude. Useful for clearing the screen. Since the accelerator has access to all memory it could also be used to clear a section of memory by drawing the appropriate rectangle there.

Graphics accelerator works a bit better all the time. However, now not all points are being written. About 95% of the pixels get written. I think this is the memory controller not being able to service the write requests fast enough. There is a stall signal being sent back to the graphics accelerator to stall writes when the memory controller’s queue is full.

If the screen is cleared using the monitor’s fill command, the entire screen is blanked successfully. If a black rectangle is drawn to clear the screen, some of the pixels on the screen are not set to black. There are write updates being missed. I am pretty sure it is not in the mechanics of the accelerator. It is difficult to see how a pixel would be skipped while keeping the total number of pixels in the rectangle correct.

What is perplexing is that the same type of bus bridge is used for the graphics accelerator and normal writes to memory. Why it would work for normal writes and not accelerator writes is to be determined.

It is looking like the hires 1920x1080 mode has too many pixels on it for game processing. Graphics are noticeably slow. Will likely change the mode to 480x270 for games. It is 16x less memory meaning the screen clear can be 16x faster. I note the text controller can be setup for 320x240 graphics and has much faster RAM. But the color selection is limited to text cells.

The memory controller was reading from the input fifo multiple times when it should have been processing just a single fifo entry. This did not cause an issue when the fifo contained only a single entry due to a low rate of access. However, it caused requests to be missed when multiple fifo entries were present. Fixing this bug fixed up about 99% of the missing pixels on the display.

I setup a secret address in the memory bridge which when written causes the value to be broadcast across all long words in memory strip. This allows eight long words to be written at the same time to memory. This is useful for clearing the screen. It is eight times as fast as writing one long-word at a time. And it is still too slow at high resolutions.

Everything these days is 8/12/24/32 bits color depth. For the video controller being worked on it does not care about being byte aligned in memory. It just calculates the address of a cache line (256-bits). It then generates a bit index to be able to extract or insert a pixel. Because it operates generically it could support just about any color depth. I am thinking of having it support color in terms of the number of bits per color component. Four components (red, green, blue, and padding). Each component would be able to specify zero to ten bits.

Well, converted the frame buffer and graphics accelerator to use color components instead of a color depth. Each component can be from 0 to 10 bits. The total cannot exceed 32-bits (including padding).

Got the CPU's running at 100 MHz by providing a slow clock (20 MHz) for the float-decimal arithmetic. They should be able to run upwards of 150 MHz in the -2 part. (The CPU core was running at just over 80 MHz in a -1 part).