Updated the GlyphEdit program so that it can input and output .mem files needed to initialize block RAMs. I changed the character generator bitmap RAM to use a memory macro rather than have the block RAM inferred by the code. And the memory macro accepts only a .mem file. Tools were having difficulty inferring the block RAM after I increased the size.

Modified the text controller to have a smaller text memory and a larger font memory. There is now room for 8192 8x8 characters. The font can be anything from 6x6 to 64x64. I am using a 12x18 font which gives a nice 64x32 screen in 800x600 mode. There is only enough room in the text memory for two 80x50 screens. The text controller can act as a tile graphics controller.

Updated the keyboard controller slightly. Registered the input signals as well as the output signals and made some other minor mods for System Verilog.

I have been experimenting lately with interfaces in System Verilog. They offer a way to encapsulate signal buses and can accept parameters.

The text controller is chopping off two pixels on the left-hand side of every character. I have not been able to see why yet as it is a pipeline. One would think the entire line would be shifted to the right and not each individual character. When I created the font, I placed the characters at the far left of the character cell and left two empty spaces on the right-hand side. Why I did this I am not sure. So, to compensate for the missing char image, for now the character font is shifted a couple of pixels to the right.

Could you have some sort of weird clock skew with the video routing or video shift register?
Does the problem change if you change color depth.
Ben.

I thought it was a weird clock skew issue. But it turns out the bytes were swapped. It takes two bytes to display 12-bit wide characters. 1/2 of the high order byte is zero because only four bits of it are needed. So only the right half of the character was displayed. It is fixed now, and things display beautifully. It is somewhat tricky to get the bits out of the char RAM in the right order for different sizes of fonts. There could be up to eight bytes required for each scan line. 12x18 takes 36 bytes.
The color box for the character was off by one pixel too so a delay had to be added. There is only a single color-depth for the text display. RGB777 for both foreground and background colors. Takes 42-bits. Four more bits are used for the color plane. Then thirteen bits are used for the character code, so 8192 different characters can be displayed on-screen. I think 59 bits of the text cell are used. So, I have been thinking of adding other attributes, possibly flash and underline.
The controller sounds really complex, but it does not consume a lot of LUTs.

Forgot to include a register in the text controller to allow the character width to be set programmatically.

Picture of the power up screen with randomized characters and colors.

Some more editing of the text controller. The size of character glyphs must now be a multiple of eight bytes. This is to make it easier to use 64-bit wide memory and to ease the generation of glyph tables by software.

Work on rfPhoenix is progressing slowly. There were issues with the instruction cache due in part to the use of odd and even cache lines. The instruction pointer would keep incrementing in a miss scenario until it got to a hit again. Hit and miss were oscillating causing multiple cache line loads that were not needed. It works a bit better now, but is far from ideal.

I have become convinced the way to do compares is to generate a bit vector of comparison results, like the 66000.

Completely reworked compare instructions. The instruction is wide enough to be able to fuse a compare and extract operation into one instruction. Therefore, compares can provide either bit vector results or a single bit result. The single bit result is analogous to the classic ‘SETxx’ instructions. A single fused instruction takes care of all the CMP and SETxx instructions. It takes only four bits in the instruction to specify a bit extract, or no-extract, since all the results fit into 15 bits. These four bits come from four unused bits in the R2 format instruction, or by reducing the immediate constant by four bits for RI instructions.

Just about got rid of the postfix instructions, but when reviewing the assembler code to build constants decided against it.

Added support for 64-bit operations to the core.

The core runs all the way through Fibonacci now although not quite correctly. I think loads through the data cache are not working. But stores are. This is running just a single thread of execution.

Getting load data is tricky because of the use of asynchronous responses. The cpu can make several requests for data before seeing any data coming back. The plan is to not rely on the data coming back in the same order as it was requested. That means using transaction ids to identify which responses belong to which requests. It means the master must also keep track of outstanding requests and responses coming in. One issue is how does the master know when the last response has arrived? My thought is to keep a bitmap for outstanding burst requests then fill the bitmap in when responses arrive. Once all the bits in the bitmap match what is expected, then it is known all data is received.

I think the above is too complex for now. So, the number of responses may simply be counted.

Spent time today working on the bus interface unit, BIU, cleaning up some of the dead code. Came up with a way to support 46-bit physical addressing using only 32-bit page table entries. The high order bits of the page number are stored in the page table pointer for the page table containing the PTEs. That makes the high order bits common to all PTEs in the page table. It means that the pages of memory referred to by the PTEs must all reside within the same 64GB address range. The 64GB address range could be anywhere in a memory space up to 2^46 bytes in size. The page tables must all reside within the same 4GB address range.

More work on the BIU. Updated the region table and TLB to use 48-bit physical addresses.

Dealing with pipeline issues today. Instructions end up being replicated in the pipeline. If the core decides not to issue an instruction to the pipeline the output of the instruction fifo is still feeding the pipeline, so those instructions need to be flagged as invalid. It almost works. Somewhere along the way the odd instruction gets marked as invalid that should not be, causing their operation to be omitted from the instruction stream. It appears to be in the decode stage.

Some more work on the pipeline. It still does not work the way it should, but I think it is improving.

Still reeling from that dwarf fortress screenquilt. Might you spill a few forbidden secrets of glyph tables.

Okay. The following is relevant only to the glyphs used by the text controller. I have a feeling the pixel padding is on the left-hand side, not the right-hand side as shown.

Glyph tables are composed of glyphs stored consecutively. The glyphs are all the same size. A glyph is a multiple of eight bytes in size. Each glyph is composed of consecutive scanline lines beginning at the top of the glyph. Each scanline must be a multiple of a byte in size. The number of bytes in a scanline depends on the number of pixels horizontally in the glyph. If there are 12 pixels horizontally then two bytes are used for each scanline. A 12 wide by 18 high glyph then takes 2 * 18 = 36, rounded up to 40 bytes to be a multiple of eight bytes. Note that padding at the end of a glyph may not be a whole scanline.


The glyph editor supports several different formats. The most useful ones are probably the .mem format and .bin formats. A .bin file is raw byte data for the glyphs stored as outlined above. A .mem file stores the glyph data as ascii hexadecimal values. The values may be selected as either bytes as in: 12 34 56 78 or octa-bytes like: 12345678. Each glyph has its own line in the text file. So, the glyph can be found easily by looking at the file line number. The glyph information is still stored consecutively for each glyph. There is an optional eight-byte header for binary files that indicates the glyph size for the benefit of the Glyph editor. Otherwise, it is a pita to specify the glyph size all the time when editing a file. An optional header for the .mem file is eight bytes or an octa-byte hex ascii value. The Glyph editor can also input and output .coe files.


It is possible to convert between file formats by loading in one format as saving in a different format. the glyph editor was developed for the purpose of being able to load block RAM in an FPGA with character bitmaps. As such it does not (yet) support other popular file formats like .png or .bmp.

A feature not yet in the glyph editor is the ability to use multi-color mode which is supported by the text controller. For multi-color mode each dot required two bits. I hope to have a simple tile editor feature at some point.

In the text controller there is register, to point to the active glyph table in memory. Multiple tables may be loaded. But some means to paste the tables together for a .mem file is needed. I think .mem or raw binary files can just be concatenated.

The GlyphEdit screen. The screen is a bit of a mess.

What about anti-aliasing character bit maps?