Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (637/668) > >>

BrianHG:
Here is a GEOFF patch for the GPU.  All the files in the .zip belong in the GPU's 'SV' folder.  The patch just makes the new 4gb DDR3 addressing change match the source files in the above Modelsim simulation.  There should be no change in functionality.

BrianHG:
 :phew: Ok, here is the new 2 page block diagram 'BrianHG_GFX_VGA_Window_System.pdf' and 'BrianHG_GFX_VGA_Window_System.txt' documentation for developers.

Details here...

nockieboy:

--- Quote from: BrianHG on January 28, 2022, 02:56:55 am ---Ok, I simulated a screen text CR/LF in the 'GPU_GEOMETRY_Testbench' and the saved test bitmaps seem to look fine.

I've attached the latest testbench as it now has the new 4GB addressable space source code.  However, I set modelsim to cap the screen memory to 16 megabytes, otherwise it will crash badly.

Enter modelsim and change to the testbench directory.
In the transcript, type:

--- Code: ---do setup.do
do test_blitter.do

--- End code ---
Wait 10 seconds for the sim to complete.

Read the 'GEO_tb_Blitter.txt' to see the commands I sent.
(CR/LF begins at line 145 which sets the blitter to match the destination output screen specs.)
(Lines 146,147,148 are optional if they have already been set accordingly.)
(Lines 150,151 perform the CR/LF.)
Read the 'GEO_tb_command_results.txt' to see what was actually being sent to the GEOFF.

Look at:
GEO_print_before_crlf_blit.bmp
GEO_print_after_crlf_blit.bmp
GEO_print_after_clear_boxfill.bmp

To see what's happening to the display after the commands are being sent.

If you like, you can change all the coordinates and screen sizes in the 'GEO_tb_Blitter.txt' to match your screen and pixel sizes as well as screen address and see what happens after typing 'do test_blitter.do' once again in the transcript.  Note that higher resolutions means a longer simulation time for the CR/LF as the sim needs to simulate all the hardware to copy all those pixels in simulated memory.

--- End quote ---

Perfect.  Got it working now.  I seem to recall you mentioning something about the order in which certain registers are set for the blitter, though I might be making that up - my memory is terrible thanks to an accident involving a mountain bike, my head and some tree roots years ago.  There didn't seem to be a lot wrong with the commands I was sending other than the order in a couple of cases, but once I'd sorted that and got single-line scrolling working, I needed to look at mass output (typing HELP, for example, produces about 3 screens worth of text in Mode 0) and it does look as though I was flooding the GPU's command FIFO as well; adding an extra FIFO status check has cleared up some random graphical issues with repeated scrolling.

BrianHG:

--- Quote from: nockieboy on January 28, 2022, 03:08:00 pm ---Perfect.  Got it working now.

--- End quote ---
:-+

--- Quote ---  I seem to recall you mentioning something about the order in which certain registers are set for the blitter, though I might be making that up - my memory is terrible thanks to an accident involving a mountain bike, my head and some tree roots years ago.  There didn't seem to be a lot wrong with the commands I was sending other than the order in a couple of cases, but once I'd sorted that and got single-line scrolling working, I needed to look at mass output (typing HELP, for example, produces about 3 screens worth of text in Mode 0)

--- End quote ---
  ??? Is mode 0 640x480, or 1920x1080?  If the latter, then my god, how big is your documentation?

--- Quote ---and it does look as though I was flooding the GPU's command FIFO as well; adding an extra FIFO status check has cleared up some random graphical issues with repeated scrolling.

--- End quote ---
Yes, in super-hires, blitting a full screen CR/LF with the current old-fashioned pixel-writer driving the DDR3 command bus, it will take around 1/60th of a second, maybe 1/30th of a second for 1080p.

2 ways around this:

A. Use a tile font text mode and still use the blitter and box fill, but blitt and fill (actually now only a line) to the screen data which will be a 16/32bit word of ascii data for every 8x16 pixels on display.

Approx calculation:
For 32bit character mode = 8:(32/(8*16))= or  1:32, or 32 times faster.
(32 bit blits probably wont work as we never expected to go that far with the 8 bit GPU, but you can cheat this one with 16bit or 8 bit blits setting the screen width to 2x or 4x the character width when driving the GEOFF.)
For 16bit character mode = 8:(16/(8*16))= or  1:64, or 64 times faster. (16 bit blits should work, I hope.)

B. Make the new memory co-processing engine which can move ~750 megabytes a second, and clear/write/set around 1500 megabytes a second.  Probably at least 15x the current speed.

nockieboy:

--- Quote from: BrianHG on January 28, 2022, 07:02:19 pm ---
--- Quote ---  I seem to recall you mentioning something about the order in which certain registers are set for the blitter, though I might be making that up - my memory is terrible thanks to an accident involving a mountain bike, my head and some tree roots years ago.  There didn't seem to be a lot wrong with the commands I was sending other than the order in a couple of cases, but once I'd sorted that and got single-line scrolling working, I needed to look at mass output (typing HELP, for example, produces about 3 screens worth of text in Mode 0)

--- End quote ---
  ??? Is mode 0 640x480, or 1920x1080?  If the latter, then my god, how big is your documentation?
--- End quote ---

Mode 0 = 720x480, Mode 1 = 1280x720, Mode 2 = 1920x1080.  All modes use a window with a 20-pixel border around its edges, so take 40 pixels off those dimensions for the actual display area.

It is three pages in Mode 0.  Less than 16KB as it fits in a ROM bank. ;)


--- Quote from: BrianHG on January 28, 2022, 07:02:19 pm ---
--- Quote ---and it does look as though I was flooding the GPU's command FIFO as well; adding an extra FIFO status check has cleared up some random graphical issues with repeated scrolling.

--- End quote ---
Yes, in super-hires, blitting a full screen CR/LF with the current old-fashioned pixel-writer driving the DDR3 command bus, it will take around 1/60th of a second, maybe 1/30th of a second for 1080p.

--- End quote ---

Scrolling in 1080p is noticeably slower.


--- Quote from: BrianHG on January 28, 2022, 07:02:19 pm ---2 ways around this:

A. Use a tile font text mode and still use the blitter and box fill, but blitt and fill (actually now only a line) to the screen data which will be a 16/32bit word of ascii data for every 8x16 pixels on display.

Approx calculation:
For 32bit character mode = 8:(32/(8*16))= or  1:32, or 32 times faster.
(32 bit blits probably wont work as we never expected to go that far with the 8 bit GPU, but you can cheat this one with 16bit or 8 bit blits setting the screen width to 2x or 4x the character width when driving the GEOFF.)
For 16bit character mode = 8:(16/(8*16))= or  1:64, or 64 times faster. (16 bit blits should work, I hope.)

B. Make the new memory co-processing engine which can move ~750 megabytes a second, and clear/write/set around 1500 megabytes a second.  Probably at least 15x the current speed.
--- End quote ---

B is looking like a far more interesting route. :-+  I don't really want to go back down the tile font text mode route again as I can easily do text and graphics on the screen currently, but yes I know that text mode is fast.  I'm going to get around to writing a tile mode demo soon though, as it'll be useful for countless applications in gaming etc.

Still have a remaining bug to squash in mode-switching.  I'm still sounding this one out at the moment, but it appears to happen if the GEOFF draws a shape in a higher-resolution mode, outside the bounds of a lower resolution mode, then I switch to that lower resolution mode.  It shouldn't make any difference to anything, but it causes screen corruption on switching to a lower mode and causes the GPU and or whole system to lock up after a few characters are typed into the console.  Like I said, I'm still exploring this issue at the moment so I can't clearly define the conditions that cause it (though what I've described above it pretty much it), and it's most likely to be an issue with my code, but at the moment I can't see an obvious cause for it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version