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.

A good test might be the game of life.

Yeah, that would be a good test. I need to get the hardware working a little bit better first.

Little by little things improve.

Not sure what I did, but the checkboard pattern for filled rectangles is fixed. I think it had to do with the data input latching. The input data latch buffer was not wide enough, a holdover from the 32-bit data version of the core.
In theory the blitter destination channel may now be used to zero out memory (any constant may be set).

Figured out a couple of reasons why loops were not being honored. The first one was loading the loop count register using too large of a number to fit in the immediate field of the instruction. There was a ‘loadi %r5,$25000’ the 25000 is treated as a negative number because the immediate field is only 15 bits. Another reason loop counts were off was in the state machine for the decrement-and-jump instruction. The register was updated twice, once in the branch state, and a second time in a writeback state. This caused the register to be decremented by two.

Found one issue with the triangle draw code. The divider load signal was stuck active causing the divider not to work.

Eight of the thirty-two hardware cursors now appear on the screen. IDK why the other 24 do not appear. They could be transparently colored (colors being chosen randomly). Greatly reduced the number of clock cycles consumed fetching cursor data. Done by assuming that cursor data is available within two clock cycles, so the normal data latching state is not used. Also, the fetch machine was revised so that it only fetches data for cursors that are displayed. With 32 cursors displayed it takes about 70 CPU clocks during the horizontal sync period. This works out to about 28 video clocks.

Text blitted characters show up on the screen, but the location seems somewhat random. The issue with location has me a bit mystified as the character box looks correct, the correct width and height. The width and height are included in the address calculation so it is at least partially working. Also, the character display is not correct. It would be nice to be able to dump messages to the screen.

Fixing timing issues in the core. The graphics processing state was being skipped over (a task was not called) for some reason. So, I re-wrote the logic a little bit to try and ensure the task is always called. There is better handshaking of the task invocation.

Point plot is busted. It is always plotting to the top left corner of the screen, obviously a co-ordinates issue. I do not think there is an issue with the logic, but rather physical issues. One issue turned out to be software.
Wrote tasks to take care of memory reads and writes. This ensures they are done in a consistent manner. It also reduces the number of LOC. Memory writes seem to not always work. So, I increased the delay before an ack is generated on a write to give the write more time.

The character textblit command code was defined as zero for convenience in displaying characters. It turns out that at startup the command fifo was reading a zero at the output, causing a textblit operation to occur to the upper left corner of the screen. So, a blank character appeared at this location after reset. So, the command code for character blit was changed. Command zero is now a NOP operation.

Not having much luck getting things to work well. There seemed to be an issue with instructions in the BRAM. So, thinking it may be a bad BRAM cell I made the instruction memory triple-mode redundant. It did not make a difference.

There is a jump to the reset address occurring when an attempt is made to perform a graphics draw operation. I can see this in the integrated logic analyzer. But, the jump is not in the program. I checked the .mem file used to load the FPGA’s BRAM and it is correct. No jump. So, where / how this jump is being inserted is somewhat mystical. I tried numerous approaches to remedy this, but no luck yet. It is almost as if it is being hacked.

Branches were made instruction pointer relative now. The IP can address up to a megabyte of memory, but the address field of the instruction is only 15 bits. To range further a value must be loaded into a register and a register indirect jump performed.

64-bit constant support was added to the OR, XOR instructions. Support for 32-bit constants was also added. Two values were used to indicate 32-bit and 64-bit constants in place of additional instructions. If the immediate field of the instruction is 15’h4001 then a 32-bit constant follows. If the immediate field of the instruction is 15’h4000 then a 64-bit constant follows. Immediates can now be aligned to 32-bit address boundaries (previously they must have been aligned to 64-bit addresses).

I chose to switch over to working on the rf68000.