Triangle drawing was fixed by placing limits for lines where the inverse slope was infinite.
A five deep state stack was added so that graphics primitives could “call” hardware routines rather than using a mix of in-lining everything and spaghetti state management.

Some experimentation with anti-aliasing has taken place. The result was interesting. It’s apparent that the color of the pixels needs to be combined with the underlying color in the drawing area. What the Wikipedia article doesn’t mention is that something similar to alpha blending is required to mix the colors. Without blending the colors the perimeter of the triangles appears black. Reading the underlying color for the two pixels being set takes about six clock cycles. The total being about eight clocks for every pixel plotted. This is 4x slower than Bresenham’s line draw. Fortunately the anti-aliasing only needs to be applied around the perimeter of the shape.

The anti-aliasing at the moment actually de-proves the appearance. The problem is that the anti-aliasing lines don’t match up exactly with the lines drawn to fill the triangle. This results in more jaggies which are noticeable.

That sounds interestingly expandable.


I hadn't thought about the underlying colours, most examples cheat by using a solid black or white background.
I don't think being 4x slower than Bresenham’s is a real problem. If the alternate was to use software anti-aliasing, it would be far slower.


A different output for each algorithm, ouch.
It might be possible to use a Wu derived algorithm that works in a similar fassion to the Bresenham based filled triangle algorithm.

Whenever I encounter an intractable problem I try and work on something else for a while. So now it's flood filling.

Added flood filling to the core, it uses a recursive flood fill for simplicity. The flood fill stack is 4096 entries, so if there are more than 4094 pixels in a row to be filled without returning the stack will overflow and the operation will be aborted. It could happen since the bitmap may be up to 65536x65536. Practically it shouldn’t happen because there is only 1MB of graphics memory. The target bitmap is <= 800x600.

As a test the entire screen is to be flood filled. But when run, only two pixels in the middle of the screen are set. This has me baffled. I wasn’t expecting it to fail in that manner. I figured it would scan at least to the end of the scan-line. The only thing I can think of right now is that it’s reading the wrong pixel from the screen and it thinks it’s finished because it’s reading a pixel that’s set already.
I put an additional delay in from the time the pixel coordinate is calculated to the generation of memory address and that helped a bit. Now there are about sixteen scanlines of fill happening instead of just two pixels. This should not have made a difference but it did, as there were no timing errors reported.

Another problem with the system is that the cursor loses it’s shape. I observed that cursoring around on the screen changes the cursor shape. It looks like the cursor image address register is updated whenever the cursors vertical position changes. There’s got to be a bad logic bit somewhere. I tried to fix this with software by re-writing the cursor image address register after a change in position but it didn’t work.
Anyways I’ve re-written the flood fill because it just might be failing at a 4096 stack overflow due to a programming problem. The system is building at this very moment.

Sounds like a good move. Often a solution to one problem can suddenly pop into mind while working on a totally different problem.

Might be time for another video debug hack.
If you disable writes and run the fill in a loop, you'll be able to flag the result of your 'read test for set pixel' function and feed it directly into the video out section of the design to see what's going on.
If you also set a flag based on then the 'disabled' writes would have been occurring, use a different colour and see if it lines up with the detected edge pixels.


A fix might be as simple as only updating the cursor position during the vertical blanking interval.

The last couple of days have been spent working on yet another audio/video controller core (AVIC128). This time using ddr ram for the frame and audio buffers. According to my calculations the interface to the ram should be just fast enough to support a 800x600x16bpp display along with sprites and audio. The controller uses a 128 bit wide bus to interface to the memory. Much of the code for AVIC128 has just been copied from the previous core. The biggest difference being in the ram bus interfacing.
It was desired to use the block ram to support a multi-core operation rather than as a video frame buffer for the system.
Sprite have changed slightly because 128 bit are read at once. So that bits aren't wasted sprites are now 16 color, and 32 pixels wide rather than 4 color. They can only be linked to one other sprite rather than doubly linked.

The main processor for the system has been switched to FT64 from TG68. A sequential version of the FT64 processing core was written. FT64 makes use of a 128 bit wide data bus. FT64 is a superscalar processor but it's too big to fit in the FPGA, hence a non-superscalar sequential version that executes the same instruction set was born. The FT64 instruction set may be "good enough" for me to use as a base for future projects. I've been bouncing around with the instruction sets learning all the in's and out's.

I'm kinda stuck in the water on this project right now as synthesis quits with 'Abnormal Program Termination' and I haven't been able to figure out yet what synthesis doesn't like. I was trying to add blitter logic when this error struck. I have posted a dump file with message on Xilinx forum.

After some experimentation it looks like 800x600 mode may not support more than three sprites. I switched the system to 400x300 mode, and that seems to allow 17 sprites. Accessing memory isn't nearly as fast as block ram access. This may put limits on what can be done. The command queue seems not to work.

Numerous software issues with the FT64 assembler were ironed out. Apparently I only half-ported it from another project so a number of opcodes were wrong.

Just in case you haven't found this.

AR# 55854
Vivado - What can I do to resolve a Vivado crash, exception, or abnormal program termination?
https://www.xilinx.com/support/answers/55854.html


Modern RAM strikes again
Does the dev board have enough IO to externally connect some fast SRAM?

Got past the abnormal program termination by modifying enough code that synthesis worked on it differently. Also many warnings spit out by synthesis were fixed.


Unfortunately the dev board doesn't have any sram. There are some I/O's (34 differential pairs) on an FMC connector but I think maybe not enough unless they could be used as single ended I/Os. It would need quite a bit of sram for a decent video frame buffer anyways. 1366x768x3 bytes per pixel) * 2 pages = 6MB. 8MB or more would probably be better considering that sprite and texture data would also be stored there. It would also probably need to be 32 or more bits wide.

Using ddr ram for the display is probably the way to go for high capacity memory. But it's too bad the interfacing isn't simpler / lower latency.

Text blitting is just about working. Some random characters were displayed onscreen, except they came out flipped horizontally.

While each line of a differential pair will (should) be length matched, some dev-boards don't care so much about keeping the length of the different pairs matched to each other, this could cause issues in the case of high speed parallel bus as used to connect RAM. FMC connector, hmmm, not the friendliest thing to interface to for a hobby project, and a bit pricey.

MiSTer uses standard SDRAM on an addon board to avoid latency problems with the DDR3 on the Terasic DE10-nano.
https://github.com/MiSTer-devel/Main_MiSTer/wiki

I spotted a couple GS8662Q36E-250I chips (72Mb SigmaQuad-II Burst of 2 SRAM) on a piece of scrap board I picked up on eBay, I love the spec, but they're a bit on the expensive side and only exist as BGA.
They would make very nice display RAM though
http://pdf1.alldatasheet.com/datasheet- ... asheet.pdf



The NOT in this snippet from my VHDL code is responsible for un-flipping X.