FPGA VGA Controller for 8-bit computer

[BrianHG]

Ok, show me something good...

[nockieboy]

Okay, nothing interesting to show yet - I haven't had much time to sit and write a demo for the new tile/layer capabilities, but I'll have something soon(-ish).

In the meantime, I've been trying to fix a problem with changing modes.  I have three modes - the default (Mode 0) 720x480 which works fine.  Mode 1 is 1280x720 and Mode 2 is 1920x1080.  Switching to either Mode 1 or Mode 2 causes graphical problems on the screen.  The video mode is updating correctly, the HW_REGs are being updated according to the current mode, but what I'm seeing on the screen doesn't correlate.  Here's an image of Mode 1 - it should be a clear screen with a yellow vertical line running down the right edge.



Instead, the area of the screen being cleared appears to be only 720x480.  The DMI uses GEOFF to clear the screen and the screen width and height are recalculated during mode changes.  I've dumped the HW_REGs values in the screenshot so you can see how the screen is being set up.  If I try to draw lines, circles, triangles etc with GEOFF, they aren't drawn outside of the 720x480 limits.  Before I pull too many hairs out, this isn't an issue with GEOFF is it?

Oh, before you point out the obvious, the line is drawn at the limits of what is visible - I've tried drawing from 1279,0 to 1279,720 and nothing shows up.  It looks like GEOFF really doesn't want to go outside 720x480.

The very bottom of the 'screen' also seems to be offset to the right slightly and at the top of the real screen, as you can see with the yellow line fragment.

[BrianHG]

What is the @SET_MAX_XY limiter set to in the GEOFF?

[nockieboy]

What is the @SET_MAX_XY limiter set to in the GEOFF?

Ah yes, thanks - that was it. 

[BrianHG]

What is the @SET_MAX_XY limiter set to in the GEOFF?

Ah yes, thanks - that was it. 

Remember, if you are using the GPU ram for CPU code or even GPU instructions as well, without any type of limiter for the geometry unit, carelessly drawing a line or rectangle somewhere will erase your code.  In under a second, you can erase you entire entire Z80 4mb.  (More like 3 seconds to erase all 512mb if you ever get around to re-doing the pixel-writer and optimize it for 128bit access.)

[nockieboy]

Remember, if you are using the GPU ram for CPU code or even GPU instructions as well, without any type of limiter for the geometry unit, carelessly drawing a line or rectangle somewhere will erase your code.  In under a second, you can erase you entire entire Z80 4mb.  (More like 3 seconds to erase all 512mb if you ever get around to re-doing the pixel-writer and optimize it for 128bit access.)

Yes of course - with a little tweaking and careful design, I could have the entire Z80's memory space in the GPU.  Does the pixel-writer need re-writing then to be more DDR3-optimised?

[BrianHG]

Remember, if you are using the GPU ram for CPU code or even GPU instructions as well, without any type of limiter for the geometry unit, carelessly drawing a line or rectangle somewhere will erase your code.  In under a second, you can erase you entire entire Z80 4mb.  (More like 3 seconds to erase all 512mb if you ever get around to re-doing the pixel-writer and optimize it for 128bit access.)

Yes of course - with a little tweaking and careful design, I could have the entire Z80's memory space in the GPU.  Does the pixel-writer need re-writing then to be more DDR3-optimised?

It's more like the pixel writer need to be changed into a generic blitter copy function, with a few mask and mix functions.  It needs to be designed smart so that it can perform multiple tasks during this copy.

I'm thinking the controls will look like this:
------------------------------------------------------------------
copy length (set the number of cycles the copy should run)

copy source data A bits width   (8,16,32,64,128)
copy beginning source address A
copy source address A inc/dec step size per copy cycle.

copy source data B bits width   (8,16,32,64,128)
copy beginning source address B
copy source address B inc/dec step size per copy cycle.

copy A-B function, only use source A or B/add AB/subtract AB/mult AB/divide AB/float or int/ XOR/and/or/ mask in and mask out levels.

copy destination Y data bits width   (8,16,32,64,128)
copy beginning destination Y address
copy destination address inc/dec step size size per copy cycle.
--------------------------------------------------------

With the above, you should have enough to do graphics, blending, sound stereo/mono stream processing as well as volume control and channel mixing at different depths as well as resampling/pitch bending including generic math-co processing, FFT, multidimensional transformations, vector array scaling and a bunch of other things the Z80 has no business of attempting at such a scale.


You would then need to modify the geometry unit's pixel address generator to prepare the list of commands to feed this new generic memory processor to write the pixels, but now you can also drive this section directly by the Z80 to perform other functions.

[BrianHG]

The next step after the above new memory co-processing engine, we will need to make a sequencer, IE something akin to a simple MCU with only something like 20 assembly instructions which reads commands from DDR3 and feeds controls to the memory co-processor engine as well as the geometry unit's command inputs separate of the Z80's control.  Software for this little MCU will run everything including the SD card, audio, com ports.  Basically it will be a super-stupid PIC32 like micro-controller running code off of the DDR3 giving you your complex interface picture/sound/IO function without needing the Z80 to do anything.

(LOL, running at 100MHz, it may be fast enough to emulate a Z80 as well...)

[nockieboy]

The next step after the above new memory co-processing engine, we will need to make a sequencer, IE something akin to a simple MCU with only something like 20 assembly instructions which reads commands from DDR3 and feeds controls to the memory co-processor engine as well as the geometry unit's command inputs separate of the Z80's control.  Software for this little MCU will run everything including the SD card, audio, com ports.  Basically it will be a super-stupid PIC32 like micro-controller running code off of the DDR3 giving you your complex interface picture/sound/IO function without needing the Z80 to do anything.

(LOL, running at 100MHz, it may be fast enough to emulate a Z80 as well...)

Holy moly. 



Sound, SD card, com ports? And here I am thinking that the graphics part of this project was 150% of what I thought it could achieve... 

I've been thinking about messing with a softcore processor for some time.  Building one would be mind-blowing.

[nockieboy]

What is the @SET_MAX_XY limiter set to in the GEOFF?

Ah yes, thanks - that was it. 

I spoke too soon.  Now I've been able to test a little further, I've found that setting the MAX_XY limiter has sorted out the X-axis limitations in Modes 1 & 2, but the blitter's Y-axis is still not taking up the full height of the screen:



As you can see above, switching to Mode 1 sets the screen to 1280x720 and GEOFF is used to clear the screen, which now accounts for the full 1280 pixels across, but not the the full height.  From looking at the GPU's video RAM using the RS232 debugger, it appears that GEOFF stops clearing the screen when it reaches 0x85000, an oddly round number.  This equates to about 1008 pixels across by 421 pixels down the screen.

Drawing a circle at the bottom edge shows something going on, but I'm not sure how to interpret what I'm seeing.



This is highly likely to be an issue with my code rather than the HDL, but I've checked and double-checked the code setting MAX_XY when the blitter is set up.  Could there be anything else causing this?

Also, unrelated question, but what is the best way to turn off the scalers?  You've mentioned setting up- and down-scaling to 4,096 and setting the scalers with command 0903, but it's also possible to just send command 0900 to turn the scalers off... Are these equivalent or are there catches to the second method?

EDIT:  And yes Star Wars fans, I realise that the second screenshot just needs the addition of Luke Skywalker gazing off into the distant binary sunset.

[nockieboy]

Another thought - is there any uniqueness with the byte- or bit-order that data is passed to the MAX_XY limiter?

Here's Mode 2 (1920x1080p) with a single circle drawn at 1500,200 with diameter 400,400:



Again, 0x85000 is the hard-limit for GEOFF to clear the RAM, with random data from that point onwards.  MAX_XY is set to the window dimensions - so MAX_X will be 1880, MAX_Y will be 1040 as there's a 20-pixel border around layer 0 in all modes.

Is there a setting I'm missing somewhere that is stopping GEOFF writing to RAM beyond 0x85000?  What's going wrong with the circle being draw on opposite edges of the screen?

[BrianHG]

What is the @SET_MAX_XY limiter set to in the GEOFF?

Ah yes, thanks - that was it. 

I spoke too soon.  Now I've been able to test a little further, I've found that setting the MAX_XY limiter has sorted out the X-axis limitations in Modes 1 & 2, but the blitter's Y-axis is still not taking up the full height of the screen:



As you can see above, switching to Mode 1 sets the screen to 1280x720 and GEOFF is used to clear the screen, which now accounts for the full 1280 pixels across, but not the the full height.  From looking at the GPU's video RAM using the RS232 debugger, it appears that GEOFF stops clearing the screen when it reaches 0x85000, an oddly round number.  This equates to about 1008 pixels across by 421 pixels down the screen.

Drawing a circle at the bottom edge shows something going on, but I'm not sure how to interpret what I'm seeing.



This is highly likely to be an issue with my code rather than the HDL, but I've checked and double-checked the code setting MAX_XY when the blitter is set up.  Could there be anything else causing this?

Also, unrelated question, but what is the best way to turn off the scalers?  You've mentioned setting up- and down-scaling to 4,096 and setting the scalers with command 0903, but it's also possible to just send command 0900 to turn the scalers off... Are these equivalent or are there catches to the second method?

EDIT:  And yes Star Wars fans, I realise that the second screenshot just needs the addition of Luke Skywalker gazing off into the distant binary sunset.

Ok, 1280x720x8bpp = 921600 bytes.  Your current pixel_address_generator.sv and 'geo_pixel_writer.sv' have only 20 address bits meaning that they can only address 2^20=1048576 bytes.  So, if your screen base address begins at 126976 bytes, you can just make it to drawing 1 full screen.  If your screen base address is higher than 126976, then anything you draw would wrap around to the bottom address 0 and up.

Looks like these need patching.  Might as well push them up to 32bit while we are at it.

The 'geometry_xy_plotter.sv' has 12bit X&Y coordinate outputs.  Since we are using signed coordinates, this means you should max out at 2048x2048.

Try a 4bpp, 16 color video mode to see if you can use the full screen.  This should give you the full height with nothing else changed.  I know my window system has no problem with huge resolutions as it can handle the 4096x4096x32bpp mode used in my ellipse generator demo.

I'll look at your old geo address & pixel writer code tonight.

As for the scaler @900 & 903, remind me what you are talking about?
I assume it's this:

Code: [Select]

[at]BLIT SCALE <usX> <usY> <dsX> <dsY>     > Sets blitter scale, us=upsample   float X/Y zooms up the SRCE image copy input   1.000000 to 4095.00000. (12 bit granularity)
                                                                 ds=downsample float X/Y shrinks  the DEST image paste output 1.000000 to 0.000245.   (12 bit granularity)
You need to set all 4 to 1.0000000 to have no scaling of the blitter image.
At reset power-up, all 4 settings are already at 1.000000.

[nockieboy]

Ok, 1280x720x8bpp = 921600 bytes.  Your current pixel_address_generator.sv and 'geo_pixel_writer.sv' have only 20 address bits meaning that they can only address 2^20=1048576 bytes.  So, if your screen base address begins at 126976 bytes, you can just make it to drawing 1 full screen.  If your screen base address is higher than 126976, then anything you draw would wrap around to the bottom address 0 and up.

Looks like these need patching.  Might as well push them up to 32bit while we are at it.

The 'geometry_xy_plotter.sv' has 12bit X&Y coordinate outputs.  Since we are using signed coordinates, this means you should max out at 2048x2048.

Try a 4bpp, 16 color video mode to see if you can use the full screen.  This should give you the full height with nothing else changed.  I know my window system has no problem with huge resolutions as it can handle the 4096x4096x32bpp mode used in my ellipse generator demo.

I'll look at your old geo address & pixel writer code tonight.

As for the scaler @900 & 903, remind me what you are talking about?
I assume it's this:

Code: [Select]

[at]BLIT SCALE <usX> <usY> <dsX> <dsY>     > Sets blitter scale, us=upsample   float X/Y zooms up the SRCE image copy input   1.000000 to 4095.00000. (12 bit granularity)
                                                                 ds=downsample float X/Y shrinks  the DEST image paste output 1.000000 to 0.000245.   (12 bit granularity)
You need to set all 4 to 1.0000000 to have no scaling of the blitter image.
At reset power-up, all 4 settings are already at 1.000000.

Well, removing the start memory offset (0x5000), GEOFF is crapping out at 0x80000, or 512KB - that would equate to a 19-bit address range, so it looks like you're onto something there.

I've just tried adding another mode for 1280x720x4, but it's doing the same thing - doesn't seem to have made much difference, but yet again it could be something I've missed in my rush to test the extra mode:

[nockieboy]

As for the scaler @900 & 903, remind me what you are talking about?
I assume it's this:

Code: [Select]

[at]BLIT SCALE <usX> <usY> <dsX> <dsY>     > Sets blitter scale, us=upsample   float X/Y zooms up the SRCE image copy input   1.000000 to 4095.00000. (12 bit granularity)
                                                                 ds=downsample float X/Y shrinks  the DEST image paste output 1.000000 to 0.000245.   (12 bit granularity)
You need to set all 4 to 1.0000000 to have no scaling of the blitter image.
At reset power-up, all 4 settings are already at 1.000000.

Yes, that's it.  I assume then that the reason just using 900 is working is because the 4 settings start out at 1.0 and don't get changed.  I'll stick with the first method then (setting all to 4,096 and command 903).

[BrianHG]

Ok, here we go.

I had to change 2 things:

1) The specified geometry 24 bit base address is now multiplied by 256 bytes.  IE, left shifted by 8 when pointing to the base address of a DDR3 memory address.  This is both for the source and destination bitmaps.  So, placing a 1 in the 24bit address means a location of 256 in the DDR3 memory and 256 in my window generator's base address.  This means you can now address 4gb, or all of the 512mb on the DECA's DDR3 ram chip except each bitmap must begin on a 256 byte boundary.

2) I changed one of the old 2 word command FIFOs to a new one used in my DDR3 controller as it performed better.  However, I could not do a full test as I do not have a Z80 system.  I hope the geometry unit still functions.

Let me know if this works.

[nockieboy]

Ok, here we go.

I had to change 2 things:

1) The specified geometry 24 bit base address is now multiplied by 256 bytes.  IE, left shifted by 8 when pointing to the base address of a DDR3 memory address.  This is both for the source and destination bitmaps.  So, placing a 1 in the 24bit address means a location of 256 in the DDR3 memory and 256 in my window generator's base address.  This means you can now address 4gb, or all of the 512mb on the DECA's DDR3 ram chip except each bitmap must begin on a 256 byte boundary.

2) I changed one of the old 2 word command FIFOs to a new one used in my DDR3 controller as it performed better.  However, I could not do a full test as I do not have a Z80 system.  I hope the geometry unit still functions.

Let me know if this works.

Something's up with GEOFF.  CLS isn't working properly - it's just creating vertical lines every even pixel, by the look of it.  The image below shows the DMI's usual welcome screen, which has been cleared with a GEOFF CLS and a memory dump has been performed of the HW_REGs, then I've used GEOFF to draw a filled yellow circle.  There's garbage across the top that doesn't seem to be affected by GEOFF and the blitter isn't placing text right at the top of the window and you can see the remnants of the welcome text from before the CLS, which hasn't been cleared by GEOFF properly.



As you can see, the blitter is set up correctly with the start address >>8 and it's blitting text just fine. I've bit-shifted the screen memory start address >>8, but there's garbage at the top of the window.

Am I missing some obvious setting that I need to >>8 with the issue at the top of the screen, or is that related to the GEOFF issue?

[BrianHG]

Ok, it looks like I had to clear the LSB of the address going out of the pixel address generator.  Try this update.

If this doesn't fix it, then I'll try going back to the old 2 word FIFO.

[BrianHG]

Why did you shift the address in my VGA window system?
You are supposed to shift the intended address you are sending to the GEOFF.
I think you are addressing really impossibly high memory address this way.

[nockieboy]

Why did you shift the address in my VGA window system?
You are supposed to shift the intended address you are sending to the GEOFF.
I think you are addressing really impossibly high memory address this way.

I'm a little confused.  I thought I had to shift ALL addresses?  I should only be shifting the ones going to the blitter and GEOFF?

[nockieboy]

And yes, that update worked - I still have that crap at the top of the screen, but this is likely an addressing issue I guess.

[BrianHG]

It's the geoff which has the 24bit limit, but we need 32 bit addressing.

Does my VGA system not already have 32bits for the screen address?

This is the reason I multiplied the geoff base address by 256.  So you may access all the DDR3 ram.

My VGA system already has 32bit addressing.  So I did not need to multiply the value by anything.

Also, the display address you choose needs to be divided by 256 before being sent to the geoff since the geoff only has a 24bit register.  So, any base address which will not evenly divide into 256 will be messed up.  Unless you want to give me a new assignments to allow 32bits in that geoff and how you will be setting them as it is currently hard wired for 24bit.

[nockieboy]

Okay, modes are working properly now and I can draw to the very bottom-right edge of the screen, whatever the mode, so GEOFF is able to access the extra memory required.

I just have a bug to sort with text scrolling now - obviously missed setting an address that needs to be >>8 somewhere.

[nockieboy]

Obviously I'm setting addresses for the blitter when scrolling the screen up one tile height that require more accuracy than an 8-bit limit will allow.  I'll need to go down to at least 4-bits to get scrolling to work, even less than that for smaller tile work on a game screen, for example.  Is this an issue or is the blitter working to a 24/32-bit address resolution?

EDIT:
Actually that can't be the issue, as text is getting blitted to the screen fine with 8/16-pixel increments, so setting the blitter to copy the bottom section of the screen (minus one font row) up 16 pixels shouldn't be affected by the recent changes to address mechanism?

[BrianHG]

What are you talking about?
The scrolling should be the same source base address as the display output base base address of the screen display.
It's just the selection of starting X&Y coordinates which are different for the blit & the paste coordinates which are different.

If you were using a screen base pointer to scroll the screen, then once again, you have went about doing something so completely backwards, I just do not know what to say.

[nockieboy]

The blitter doesn't take pixel locations, it only takes memory addresses?

I've got a command for Blitter Copy Source Pointer and Blitter Copy Destination Pointer amongst others - neither take pixel locations, they're both memory pointers?  In fact, I only have memory pointers as a way of referencing the screen with the GPU at all???

EDIT:  Just to clarify, the draw commands use pixel locations - but I'm not aware of any blitter commands that do.

EDIT2: Oh hang on...  I've just been reviewing the GPU manual.  I guess I could set the blitter's copy width & (height - tile height) using 74, turn the blitter on then draw a single pixel at 0,0 to copy the screen and paste it there...