Boards and JTAG

As far as hardware goes, assembly is pretty much complete! All that is left is actually getting the FPGA core onto the thing, which has proven to be a little more difficult than I had intended. I have tried a few methods of programming the FPGA through JTAG, which didn't work, but I think i can get this one to function. There are a few pages online that discuss using a Bus Pirate as an XSVF player; I tried using it for plain SVF playback with openOCD, but that didn't seem to do anything. It looks like the Bus Pirate is only capable of playing back XSVF files, probably because of its limited onboard memory. Regardless, that's the method I'll try next time I work on the board.

On a more positive note, openOCD did correctly recognize and identify my FPGA over JTAG. So at the very least, the design is sane enough to not blow up its components.

The FPGA Core

Despite the hardware not really existing in a functional state, the FPGA core is actually pretty far along in development. I have been using Verilator to compile the core and simulate it locally. I have a verilator test-bench using a VGA monitor simulator that i found somewhere online that i have modified to interface with my verilog sources. If the simulator is to be believed, my core's VGA signal generation is at least functional:

And maybe a bit more than functional, as well. So far i have 2 distinct graphics modes implemented:

• 320x240 Bitmap Graphics mode (seen above)
• 80x30 Text mode

The verilator test bench also simulates the VRAM that the core grabs the graphics data from, and can pre-load data into the VRAM on startup.

The text mode has a few configuration bits that it uses to alter aspects of the display. So far it can either do 256-color text mode, or VGA compatible 16-color foreground+background text mode:

More config bits include the ability to double the height of a character and double the width of a character:

Of course, you can twiddle any of these bits in any combination you like:

Here, you can see a vertical line at the start of a lot of the color cells; As far as i can tell, this isn't an issue with my VGA timings, Its just an artifact of how I'm generating these register values. I'm feeding the X and Y registers back into the config register, which creates a double registered input, thus the 1 cycle delay. (In theory, anyways)

This happens to show how I'm actually fetching things from memory. In the text mode, I'm fetching the attribute byte in the first cycle on the X axis, and the character value in the second, and all that gets repeated nonstop. This leaves 0 cycles left for anyone else to access the framebuffer and is something that's going to need to be optimized. I'm thinking about fetching the character value and attribute byte once per cell on the first scanline of each character, and saving them in a buffer. That way i can leave 98% of the cycles open for the CPU to fiddle with the framebuffer (or even more more if the X any Y are expanded!).

Another part that needs work is the bus that the host CPU uses to write and read to the FPGA's internal registers; It needs work because it doesn't exist. Currently, to select between text and graphics modes, I'm just flipping two bits on a multiplexer. So the framework is there, i just need to move a bunch of things into registers, and then implement that CPU bus.

lots of stuff still left to do, on both fronts. Cant stop thinking of all my favorite video chips and the special tweaks i want to implement here. Maybe I'll add a scroll register next?