Took a break from the usual to make a Collatz conjecture machine which can process hundreds of numbers in parallel. It should be able to run at 250 MHz. Now trying to figure out how to display results. I have the calculation organized as a 24x24 matrix of calculators. So, I may display the done status of each calculation as a block graphic on the screen. Once all 24x24 calcs are done, the screen will clear and begin with the next set of numbers. This should repeat up until the last specified number to be tested.

The rusty old rf6847 video display generator (VDG) is being used. The done status bits are connected to the character bitmap input and an external character generator selected. I had to modify the rf6847 to accept external sync inputs. Normally it generates the sync signals. The display is not quite right yet, vertical timing is off resulting in a flickering screen. Horizontal timing seems okay.

More work on the co-processor. This time integrating graphics acceleration. Graphics acceleration includes a hardware blitter and hardware cursors. The screen is 400x300 as it needs to fit into BRAM with memory available for other things.

The co-processor can now write to the screen memory (screen clear is successful). Point plot acceleration does not work yet, it is the current item being worked on. Because the processor only handles 64-bit data and pixels are 16-bit, there is not an easy way to plot pixels. Hence the point plot accelerator. The accelerator plots a point at the current graphics position in the current color.
Graphics commands are posted by the processor to a graphics command queue. The queue allows longer running operations to be run without stalling the graphics commands coming from the processor. The command queue seems to work.

Operation of the core is somewhat tricky since it is a co-processor capable of running a program, yet at the same time it acts as a state machine to perform accelerated graphics operations. In the instruction fetch stage the graphics command queue is checked to see if it is empty. If it is not empty, then graphics processing is triggered. This acts like an interrupt. It is effectively an interrupt routine performed by hardware. (Hardware based hardware interrupt - HHI). Vertical sync and TLB misses are also detected at the ifetch stage. A trick behind the graphics acceleration is that it only performs a few states at a time before returning to the ifetch stage. This is so that not very many cycles are lost before an interrupt is serviced. Because graphics operations are sent to a command queue it should be possible to perform graphics operations in an interrupt subroutine. Any outstanding operation will complete first though.

The pixel plot function works!

I keep forgetting that the co-ordinates are 16.16 fixed point and the graphics ends up at the top left of the screen co-ordinate 0,0. Things are slowly coming together. Drawing filled rectangles almost works. It works except that every other pixel is drawn, and it alternates between lines, resulting in a checkerboard appearance. I have yet to figure out the cause of this. Filled rectangle drawing is done by the blitter, so that is almost working.

Loop counts to display things on the screen are not being honored. There is a loop to 15,000 to display random pixels on the screen, but only about 50 pixels show up. Triangles do not show up on the screen yet. The test program runs all the way through, but no triangles are displayed.

Hardware cursor logic is in place but the cursors do not show up yet.