DIY 8-bit computer, Episode 1C: ...In which characters are displayed

In this video I present a series of experiments to add support for displaying text characters to the FPGA-based display controller.
As always, code and schematics are on the Githubs: github.com/daveho/DIY8bit/tre...
This took quite a while, but I am feeling fairly confident that the display controller will be fully working in the not-to-distant future.

[@AppliedCryogenics]

My favorite retro computing font is the classic five by seven matrix, used by alphanumeric LCD displays everywhere. It ends up being a 6x8 font once the characters are padded, but it's the most economical with space without compromising any glyph shapes. It does take some liberties with lowercase descenders, though, but I like how that looks.

[@davehohacks]

That is a good one!

[@TroySchrapel]

Awesome stuff, Dave. Well done.

[@davehohacks]

Thanks, Troy! It was satisfying to make some progress.

[@robdom91]

When you need to write hundreds of lines of code into a computer so you could make some text characters for a DIY computer...
Teasing aside, the fact that you're making your own Atari level computer by yourself is insanely cool! Wish I had your insight!

[@davehohacks]

Ha! It definitely is a lot of effort for a relatively modest result. But it's strangely satisfying to have a computer system where I designed all of the hardware, and it's actually not all that complicated once you know a few basic principles.

[@0toleranz]

Hi, one suggestion I would like to give is use the dual ported ram as screen buffer and the single ported ram as bitmap data for fonts. The reason is you probably change the screen buffer much more often than the font data on an text display. Although the fpga is fast enough to perfectly sync the access to the ram in between the screen update access which only needs to read every 8 clock cycles or every 4 cycles when also reading color data from the same blockram. Internally I would organize the screenbuffer as 16 bits wide so the access to character and attribute data happens in one cycle. Ther would be an attribute register holding my current foreground and background color attribute for the current read/write position and an 16 bit address counter for sequentially accessing contiguous data in read or write mode and a mode register to set if you want to read/write, one byte per screen position (only character data) or two bytes (character and attribute) an count register to set the number of transfers (character/pairs) an up/down count bit and a base address for where to start (makes it easier to have successive block transfers withe less setup overhead).

[@davehohacks]

Thank you for the suggestion! Let's see...the UP5K has 15300 bytes of block RAM. If the attributes (foreground and background colors) can be stored in 1 byte per character, then that would certainly fit. If the attributes were 2 bytes, to allow 256 fg/bg colors, that's 11100 bytes. The color palette only needs 512 bytes. With the font data in SPRAM, everything would still fit! Assuming it's possible to initialize the contents of the SPRAM as part of the bitstream, it wouldn't even require any effort to initialize. I like tthis idea...

[@HamsterSnr]

Which FPGA are you using. Good to
See that you use synchronous methods in your Verilog description. I have seen so many designs where engineers veer off this synchronous design route to end up hating and despising FPGA design. I made such a vga display driver for a commodore V20 and C64 computers . What you should do, if there is enough block RAM in the FPGA, is to implement a 4K x 8 character ROM, then a 4K x 8 RAM for the 100 x 37 display. Then get the FPGA to do all the data shuffling rather than the Arduino. The Arduino would just handle the lower layer operations such as downloading the character RAM and messages to be displayed.

[@davehohacks]

The FPGA is the Lattice ICE40 UltraPlus 5K (UP5K). I'm using the Upduino 3 dev board, and the open-source IceStorm via the APIO front end. Having everything be completely synchronous makes the most sense to me (as a relative novice at programmable logic.) The Arduino is really just standing in for the host 8-bit microcomputer system, which the FPGA will just be the display controller for. It's not period-accurate, but I'm pretending it's a custom ASIC 🙂