FPGA VGA Controller for 8-bit computer

[Ted/KC9LKE]

nockieboy
Glad the LVC06 is working for you.
Its after the fact but just wanted say you might have needed to adjust the value of the pull-up on the wire-OR lines, interrupt, wait, etc.
Moot point now, its working.

I have to say, following this post everyday is quite a good read.

Best
Ted

[BrianHG]

Remember, the font is a 1 bit color image.  With transparency on, you can make the 0 or the 1 value transparent by changing the transparent color from 0 to 1 which inverts the transparent color.

Then, when painting, you can choose what color, the '1' opaque color gets painted and XORED with on the screen when transparency is enabled.  Disabling the transparency means that both 0 and 1 are being painted together and the XOR paint color means all you can do is paste 2 adjacent colors in the palette instead of 2 hard selected colors when doing 2 x paste, with transparency on each time at the same coordinates and flipping which part of the font appears to be a '1' and a '0'.

Okay, so this is going to require palette modifications for whatever purpose the software needs.  I'll leave this until we've done the upgrades required to allow palette writing.

No, with 2 drawings of the same character with 2 different XOR on the source copy color which changes the transparency color, you can choose any foreground and background color combination you like.

1) Turn on blit with transparency.
2) First draw the character with copy XOR color setting of 1.  Remember, the paste color on the screen you want to show must also need to be XORed with a 1 or it will come out wrong. This will draw the background color of the text.
3) Next draw the same character again with with copy XOR color setting of 0.  The paste color you choose will be the true actual direct color, no XOR needed.  This will draw the foreground color of the text.

Done.

[nockieboy]

nockieboy
Glad the LVC06 is working for you.
Its after the fact but just wanted say you might have needed to adjust the value of the pull-up on the wire-OR lines, interrupt, wait, etc.
Moot point now, its working.

I'm starting to wonder if there isn't some stray capacitance in the circuit that's causing the rise time on the WAIT line to be so slow.  I've already dropped the pullup resistor on the line from 10K (or was it 4K7?) to 1K.  I'll have to go away and learn some more about capacitance and resistance and how both/either affect rise time.

I have to say, following this post everyday is quite a good read.

Thanks Ted, that's much appreciated.   I have frequently worried that this forum thread perhaps isn't the best place to conduct ongoing project work as BrianHG and I are doing, but I'm learning all the time from this discussion and I'm hoping that - by extension - other people are learning as well and it'll be a detailed resource for anyone wanting to do something similar in the future.

[nockieboy]

No, with 2 drawings of the same character with 2 different XOR on the source copy color which changes the transparency color, you can choose any foreground and background color combination you like.

1) Turn on blit with transparency.
2) First draw the character with copy XOR color setting of 1.  Remember, the paste color on the screen you want to show must also need to be XORed with a 1 or it will come out wrong. This will draw the background color of the text.
3) Next draw the same character again with with copy XOR color setting of 0.  The paste color you choose will be the true actual direct color, no XOR needed.  This will draw the foreground color of the text.

I've been stuck in the mental line of thinking that the character should be blitted in one go, so I haven't seen this solution myself until you pointed it out.

So instead of messing with the blitter settings, I can just leave the blitter with Paste Mask (transparency) on and blit each character twice - once for the background, once for the foreground colours?  If I want to use transparent text, I can just miss the first blit, but if I want 'opaque' text, with a coloured background, do the two-blit method you've suggested.  I'll have a closer look at implementing this over the weekend.

How's the DDR3 update coming along?  I hope it's not causing too much stress!

[BrianHG]

Getting a reliable 200MHz out of the DDR3 multiport is a headache as I need to do Quartus multi-minute compiles to check and I had to re-do a good portion of my multiport code.  It looks like it will take a few more days.  150MHz is now already easy-peasy but, 200MHz is the target to reach for a 400MHz DDR3 system.

[BrianHG]

So instead of messing with the blitter settings, I can just leave the blitter with Paste Mask (transparency) on and blit each character twice - once for the background, once for the foreground colours? 

You got it.  No need to change any other regs.  2 consecutive blits with just 2 different transparent & paste color settings.

[nockieboy]

So instead of messing with the blitter settings, I can just leave the blitter with Paste Mask (transparency) on and blit each character twice - once for the background, once for the foreground colours? 

You got it.  No need to change any other regs.  2 consecutive blits with just 2 different transparent & paste color settings.

Okay, done that and tested it - here's the result:



Take a look at the header row and address columns - they should be filled with solid colour, but have black lines between (and above/beneath) each character.  I can only guess this is because the font literally doesn't include a blank column at the far right (or left) to space the characters? Is it not wide enough for the blit settings, or am I somehow inserting a 1-pixel gap between each blitted character?  And if I am, what's going to be the easiest way to fill that gap with background colour?

[BrianHG]

If you are using the 'space' character, it should be completely blank.
Are you sure your blit width and height is set to 8x16?

What does the geometry test-bench output when you draw 2x2 characters in the same manner?

[nockieboy]

If you are using the 'space' character, it should be completely blank.
Are you sure your blit width and height is set to 8x16?

Ahh, that was it.  For some reason (probably to do with getting confused over which registers were 0-based), I'd set the blitter width and height to 7x15, which went undetected until now.

[nockieboy]

Found some time to work on BBC BASIC in CP/M.  Have started adding drawing commands in - here's a little Mandelbrot the uCOM drew earlier.  It's all greyscale due to the current GPU palette, but is a good test to show that - even in its current state of partial development - the GPU is working. 

[BrianHG]

Found some time to work on BBC BASIC in CP/M.  Have started adding drawing commands in - here's a little Mandelbrot the uCOM drew earlier.  It's all greyscale due to the current GPU palette, but is a good test to show that - even in its current state of partial development - the GPU is working. 

Nice.....

I'm just about done on my side.  It's been hard finding spare time.  I'm on the last step before sending out a beta DDR3 v1.5.

[nockieboy]

Nice.....

That was a 480x480 render - took my 8MHz system about 4 hours.    If the aspect ratio isn't 1:1, it ends up clipping some of the image.  That and a full 720x480 render would probably take about 8 hours.  I'd forgotten just how slow these old 8-bit systems were. 

I'm just about done on my side.  It's been hard finding spare time.  I'm on the last step before sending out a beta DDR3 v1.5.

No worries.  Time isn't an issue - it's taken me two weeks to get around to sorting out BBC BASIC so I can do some more testing with the graphics.  Going to try and make a ROM-only version of it too.

[BrianHG]

  I'd forgotten just how slow these old 8-bit systems were. 

What the longest/slowest calc in the Mandelbrot?
Your gonna have room to place a 32bit integer and floating point math-co-processor in the FPGA to do long-divides within a Z80 instruction cycle.

[nockieboy]

What the longest/slowest calc in the Mandelbrot?

Erm.. all the big calculations go off in these loops:

Code: [Select]

  190 FOR I=0 TO 3
  200   FOR J=A(I) TO MAXY/SCALE
  210     FOR K=B(I) TO MAXX/SCALE
  220       CR=XRANGE+K*4/(MAXX/SCALE)
  230       CI=YRANGE+J*3/(MAXX/SCALE)
  240       ZM=0:ZR=0:ZI=0:ZR2=0:ZI2=0
  250       IT=0
  260       REPEAT
  270         Z1=ZR2-ZI2+CR
  280         Z2=2*ZR*ZI+CI
  290         ZR=Z1
  300         ZI=Z2
  310         ZR2=ZR*ZR
  320         ZI2=ZI*ZI
  330         ZM=ZR2+ZI2
  340         IT=IT+1
  350       UNTIL IT=ITERS OR ZM>=4
  360       GCOL COLOFF+(COLS-1-INT(IT/(ITERS/(COLS-1))))
  370       MOVE K,J
  380       PLOT
  390     NEXT K
  400   NEXT J
  410 NEXT I

Lines 360-380 actually deal with setting the graphics pen colour, setting the coordinates of the pixel and plotting the pixel.  SCALE is set to 1, so there's no complicated division going on in lines 200-230, but there could be if SCALE is changed.  The real meat of the calculations is kicking off in lines 260-350, where the program works out the number of times the value can be iterated before it decides it's drifting off to infinity.  ITERS is the iteration limit and is set to 32.  MAXX and MAXY are the dimensions of the image (480 and 480).

So there's some multiplication going on (about 96 times per pixel), but it's all with floating point numbers so an FPU would certainly speed things up a bit.

Your gonna have room to place a 32bit integer and floating point math-co-processor in the FPGA to do long-divides within a Z80 instruction cycle.

 

If I have time I will be expanding the PLOT command today to include various modes, so as well as plotting a pixel it will access the GPU's other drawing functions and allow the user to draw rectangles, triangles and ellipses with ease, and incorporate the MOVE command so I can shorten the loop above by a line.

[BrianHG]

Even if you divide by 1, the Z80 math code may not figure to skip the divide, just that it will take fewer cycles to compute.

'MAXY/SCALE' should be pre-caculated before the loops and stored in a fixed variable when running the routine.

As for implementing the math-co, it is simple easy as all you need to do is use 8 x 8bit write ports, IE 2x 32 bit numbers as your A&B, then feed those into an altera FP add/subtract, fp multiply and divide.  Then feed the 32bit results of each function's output to 3x 4 bit read ports.  Place number a & b into the 8 write ports, and just read the read ports of which function you want to use.

Oh, you will also want to add a 4th function, FP compare which will return 3 bits to another 8 bit port, a>b, a<b, a=b.  Everything should compute before the Z80 can even get to a read except for maybe the 'divide' where after setting the a&b, you may need to 1 nop instruction to add a delay as the divide can still take something like ~100 clocks at 100MHz and if the Z80 can exceed 1 mips going from writing the last port to reading the result, 1 extra nop would definitely clear the hurdle.

The FP module should be something you should be able to create on your own.
Just read and generate the example verilog functions from altera's math IP functions.
I can help you with the wiring to the new Z80 port scheme.

[BrianHG]

A floating point divide only takes 15 clock cycles at 100MHz.  There is no way your Z80 can keep up as a single instruction takes 3-4 clocks at 8 MHz, meaning less than 2 mips.

Also, the floating point functions are in the FP_FUNCTIONS inside the IP Basic Functions / Arithmetic.

You can also do trig/log/root functions as well as fixed int to float and float to fixed integer.

[nockieboy]

A floating point divide only takes 15 clock cycles at 100MHz.  There is no way your Z80 can keep up as a single instruction takes 3-4 clocks at 8 MHz, meaning less than 2 mips.

Also, the floating point functions are in the FP_FUNCTIONS inside the IP Basic Functions / Arithmetic.

You can also do trig/log/root functions as well as fixed int to float and float to fixed integer.

Going to have to go do some reading on FP maths I think. 

In other news, I'm noticing some artefacts cropping into the display during 'intensive' GPU activity.  I say 'intensive', it's through BBC BASIC so can't be that intense, but it's a step up from a simple 'draw a full-screen rectangle', if you get my meaning:



This image is generated by a simple little program that loops through all the palette colours, 0-255, and gets the GPU to draw a rectangle for each one 720/255 pixels wide and 480 pixels high, so the screen is filled with the palette colours.

As you can see, there's some black pixels slipping through - at first I thought this might be an issue with BBC BASIC trying to pass FP numbers to the GPU, which only takes 24-bit integers, but I'm getting artefacts if I try to display an even number of colours across an even number of pixels, so it looks like read errors in the DDR3 possibly?

The graphics routines are checking for the GPU's input FIFO being free before sending commands.

[BrianHG]

A floating point divide only takes 15 clock cycles at 100MHz.  There is no way your Z80 can keep up as a single instruction takes 3-4 clocks at 8 MHz, meaning less than 2 mips.

Also, the floating point functions are in the FP_FUNCTIONS inside the IP Basic Functions / Arithmetic.

You can also do trig/log/root functions as well as fixed int to float and float to fixed integer.

Going to have to go do some reading on FP maths I think. 

In other news, I'm noticing some artefacts cropping into the display during 'intensive' GPU activity.  I say 'intensive', it's through BBC BASIC so can't be that intense, but it's a step up from a simple 'draw a full-screen rectangle', if you get my meaning:



This image is generated by a simple little program that loops through all the palette colours, 0-255, and gets the GPU to draw a rectangle for each one 720/255 pixels wide and 480 pixels high, so the screen is filled with the palette colours.

As you can see, there's some black pixels slipping through - at first I thought this might be an issue with BBC BASIC trying to pass FP numbers to the GPU, which only takes 24-bit integers, but I'm getting artefacts if I try to display an even number of colours across an even number of pixels, so it looks like read errors in the DDR3 possibly?

The graphics routines are checking for the GPU's input FIFO being free before sending commands.

Hmmm?
The junk is in the middle of the draw.

Are you drawing vertical lines or single pixels?

It the blitter enabled?  I know you are using it for system text and if it gets enabled in the middle of plotting a pixel, you may be drawing a black pixel or rendering a corner of a font at the end of a position as your draw command may have it set to on at some odd intervals.  (This error would only show up if you are drawing single pixels, not lines.)

The color data is only 8 bit, not 24 bit.

The coordinates are only 12bit for signed x and 12 bit signed for y, not 24 bit.

Try a test running your code with integer variables.

For your basic to indeed overflow the pixel drawing, it would need to fill the screen at least 10 times a second if not something like 30fps.

Which version are you using?  We had 1 version which had regular black dots in the past.

What happens if you render the screen twice, or double draw each pixel?

[nockieboy]

Hmmm?
The junk is in the middle of the draw.

Are you drawing vertical lines or single pixels?

Rectangles, 720/255 wide and 480 high. (EDIT: Actually, variable width as I'm adjusting the width of the columns as I display increasing colours on the screens up to 255).

It the blitter enabled?  I know you are using it for system text and if it gets enabled in the middle of plotting a pixel, you may be drawing a black pixel or rendering a corner of a font at the end of a position as your draw command may have it set to on at some odd intervals.

Blitter is disabled for all draw commands in BBC BASIC, then re-enabled when the appropriate commands have been sent...    There's no chance that the blitter is being re-enabled before the GPU has completed the current the drawing command, is there?

The color data is only 8 bit, not 24 bit.

The coordinates are only 12bit for signed x and 12 bit signed for y, not 24 bit.

Yeah, I thought I'd got that wrong after I posted. 

Try a test running your code with integer variables.

For your basic to indeed overflow the pixel drawing, it would need to fill the screen at least 10 times a second if not something like 30fps.

Already did before posting previously - same issue.  I've also noticed some colour bleed between the coloured columns - not at all obvious with the greyscale but with the (godawful) colour palette I've inserted at the start, you can see it quite clearly:

[BrianHG]

Try going into file: "../BrianHG-DDR3-Controller/BrianHG_DDR3/BrianHG_DDR3_COMMANDER.sv"

Lines, 385,386 and lines 436,437 and change:

Code: [Select]

        .words           ( 3                                 ),
        .spare_words     ( 1                                 )                  // The number of spare words before being truly full.

to

Code: [Select]

        .words           ( 4                                 ),
        .spare_words     ( 2                                 )                  // The number of spare words before being truly full.

And see what happens.
If that doesn't work, also try changing line 409 from:

Code: [Select]

        .words             ( (PORT_R_CMD_STACK[x]+1)*8         ),              // Select 4 word or 8 word FIFO.
to:

Code: [Select]

        .words             ( (PORT_R_CMD_STACK[x]+1)*10         ),              // Select 4 word or 8 word FIFO.
This commander section is what is currently being replaced.
Also, the pixel writer will be updated to make better use of the DDR3 ram controller most likely solving what looks like missed pixels after a new-line.

[nockieboy]

Hmm.. neither change seems to have any effect.

Could it be the command FIFO, rather than DDR3 read/writes?

Ignore that last sentence.  If it was the FIFO the uCOM wouldn't be sending further drawing commands through to it until it's got space again.

[nockieboy]

So I've been giving some thought to setting up an SD card interface.   This is an important step as I intend to replace the existing CompactFlash card with an SD on the graphics card.  The DECA board has a built-in SD card socket, making testing easy.

At this stage I've just been looking up information on how it should all work to get an overview.  My gold-standard outcome would be for the FPGA to store and read files from a standard FAT16/32-formatted SD card and handle translation of files and directory structures between the FAT system and the system CP/M expects to see on the host uCOM.  Depending on how difficult that would be to implement (I have no idea - I'm at the stage where I don't know what I don't know), I could always just copy the existing CF card system of sector-by-sector writing and not worrying about using FAT at all, but it would be great if I could access the SD card from a modern PC too, without faffing around with old/no longer supported CPMtools etc.

I'm very early in the design stage at this time.  I have identified an existing project that appears to do what I want, perhaps with a little tweaking necessary, but should be up to the task without being too complex for me to understand.

What I'm trying to decide at the moment is the best way to connect the interface to the FPGA.  The CF card works via IO calls to the card itself - software sets a memory address to read from or write to, calculates the appropriate address on the CF card to read/write as appropriate and it's all handled via IO calls and the Z80 handling the reading and writing.  It's probably going to be a lot easier for me to copy this system and tweak it for the SD card - though it'll be slightly different in that the commands and data will go through the Z80_Bridge and SD interface in the FPGA, rather than direct to the SD card.

I think it'll be easiest if the commands are fed directly to the SD interface (via the Z80_Bridge), with a data buffer in DDR3 RAM or the FPGA's block RAM; the Z80 would write a 512-byte block of data to the FPGA, then use IO commands to signal to the SD interface (via the Z80_Bridge) where the block of data is (if it's not a fixed location) and where it's to be written to.  A status register can tell the Z80 when the write is complete or if there are any errors.  A read would work the same way, with the Z80 requesting data from a sector address (or filename, if I'm using FAT16/32 I guess) and copying the data block from GPU RAM (DDR3/block RAM) when the status register gives it the all-clear.

TL;DR
So really what I'm trying to decide is whether or not to use a read/write buffer in DDR3 and if so, what's the best way to connect the SD interface to it via the BrianHG_DDR3_Controller - do I just expand the PORTS and wire the SD interface to its own DDR3 R/W ports?  The alternative is to stick with a more basic serial stream of data which the Z80 reads from the SD interface and writes to wherever it needs to write it?  The issue with the second method is that I'm not sure the Z80 will keep up with the data from an SD card unless I really slow down the clock on the data transfers, and I don't know how compatible that will be with later SD cards.   Plus it's slower.

[asmi]

SD/MicroSD cards support two communication protocols - "legacy" single-line SPI mode (technically it's optional but I'm yet to see a card which doesn't support it), and main SDIO mode (using 1 or 4 bidirectional data lines, command line and a clock). Both transfer data in a chunks of 512 bytes.

Now, handling a filesystem in hardware doesn't sound like a good idea because all filesystems were designed to have software driver handling these. The problem is that there are quite a bit of use-cases, so it might require a lot of hardware to handle all of these, to the point that it will actually be more resource-efficient to include a small specialized softcore dedicated to just that task (and appearing as a fixed hardware to outside world). This has been done in the past, when in IBM PC XT times some of specialized CPUs used in peripherals were actually more powerful than the main CPU in that system.

I also highly recommend implementing support for exFAT filesystem, because finding smaller SD cards in stock is becoming harder by the day. exFAT supports all SD card densities of today and foreseeable future.

[nockieboy]

SD/MicroSD cards support two communication protocols - "legacy" single-line SPI mode (technically it's optional but I'm yet to see a card which doesn't support it), and main SDIO mode (using 1 or 4 bidirectional data lines, command line and a clock). Both transfer data in a chunks of 512 bytes.

I'm intending to use a 4-bit SDIO connection - the project I linked in my previous post uses this connection to the SD card and the DECA development board includes a full 4-bit connection to the SD socket on the board.

Now, handling a filesystem in hardware doesn't sound like a good idea because all filesystems were designed to have software driver handling these. The problem is that there are quite a bit of use-cases, so it might require a lot of hardware to handle all of these, to the point that it will actually more resource-efficient to include a small specialized softcore dedicated to just that task (and appearing as a fixed hardware to outside world). This has been done in the past, when in IBM PC XT times some of specialized CPUs used in peripherals were actually more powerful than the main CPU in that system.

I was thinking about including a softcore (this one specifically) to handle the filesystem on the SD card, then I came across the linked project above which seems to support FAT16/32 and up to SDHC v2 cards.  I have a lot of learning to do regarding filesystems though, so your comments regarding exFAT have raised a point I hadn't thought about before now and perhaps including a softcore is more a requirement than an option.

I also highly recommend implementing support for exFAT filesystem, because finding smaller SD cards in stock is becoming harder by the day. exFAT supports all SD card densities of today and foreseeable future.

Okay, you've sold me on exFAT!

[asmi]

I was thinking about including a softcore (this one specifically)

That guy is sick with a terminal case of NIH syndrome (had some run-ins with him on other forums where he heavily promotes his stuff), so I would recommend to go with something more established, like RISC-V, as this way you can utilize gcc/binutils toolchain for writing software in C instead of using some custom stuff. You can find some really small cores for RV32I, or you can even implement your own - it's very simple because this instruction set only contains around 40 opcodes.

I came across the linked project above which seems to support FAT16/32 and up to SDHC v2 cards.

Judging by a lot of Chiness on the project's home page, you are probably going to have to dig on your own with little to no docs while integrating it into your project.
FAT16 is obsolete now and I don't think it's even used anywhere these days, so I wouldn't waste my time supporting it. But FAT32 and exFAT are definitely worth supporting, even if there is a clear trend for latter to largely replace the former. That said, since you control what kind of card is to be used, you can go either way, or even limit support to just a single one if you wish.
FAT systems are fairly simple, if you understand how linked lists work then you will feel right at home with it as it's just a bunch of linked lists.