-
Full-screen (320x200) rectangle fills, random colours each time, no input checks whatsoever - the loop is just the rectangle command, repeated infinitely.
-
That RND takes too long, just do the super fast test I mentioned 2 posts up.
You still haven't maxed out the GPU.
-
There's no RND in that code. Here's the main loop:Code: [Select]
MAINLOOP:
CALL drawFRect
JP MAINLOOP
drawFRect:
CALL full_params
LD HL,0AFFH ; draw filled rectangle X[0],Y[0] to X[1],Y[1]
LD L,A
CALL send_gpu
RET
full_params:
LD HL,8000H ; set X[0] to 0
CALL send_gpu
LD HL,0C000H ; set Y[0] to 0
CALL send_gpu
LD HL,9140H ; set X[1] to 320
CALL send_gpu
LD HL,0D0C8H ; set Y[1] to 200
CALL send_gpu
recol: ; Cycle colours
INC B
LD A,B
CP 16
RET C ; RETurn if < 16
LD A,2
LD B,A ; Otherwise, set colour to 2
RET
I could tighten it up by not setting the X/Y parameters every loop... -
Who cares about the 2 black colors, let them draw.
I need to see this thing swing...
Okay, I'll remove the check for the two black colours. Could I get away with setting up X[0]/Y[0] and X[1]/Y[1] once at the start, then just running draw command in the loop without setting those registers again? That'd speed the loop up a lot.I'm trying to keep everything in 8 bit and only do adds or inc.
I think I could do better with a PIC16C54 microcontroller from the mid 1990s.
We might need to store graphic programs on the GPU to do any real work.
However, with the current rate of development, this would take forever.
Do you have any 20MHz Z80s?
No, 8 MHz is the fastest I have (well, 10 MHz chip running at 8 MHz) - it would cause me real headaches trying to change existing hardware in the system to run at faster speeds. The alternative, I guess, is to run the lot in the FPGA itself if you're after real performance.
-
Optimised the loop some more:
Not seeing a lot of difference?
Here's the code:Code: [Select]CALL full_params ; Set rectangle coordinates
LD HL,0AFFH ; draw filled rectangle X[0],Y[0] to X[1],Y[1]
MAINLOOP:
LD L,A
INC A
AND 0FH ; restrict A to 0-15
CALL send_gpu
JP MAINLOOP
drawFRect:
CALL full_params
LD HL,0AFFH ; draw filled rectangle X[0],Y[0] to X[1],Y[1]
LD L,A
CALL send_gpu
RET
full_params:
LD HL,8000H ; set X[0] to 0
CALL send_gpu
LD HL,0C000H ; set Y[0] to 0
CALL send_gpu
LD HL,9140H ; set X[1] to 320
CALL send_gpu
LD HL,0D0C8H ; set Y[1] to 200
CALL send_gpu
RET
send_gpu:
PUSH AF
LD A,L
OUT (CMD_LO),A
LD A,H
OUT (CMD_HI),A
POP AF
RET -
Maybe you are hitting the input FIFO's limit and not knowing. Do you occasionally check the status flag?
However, seeing colors broken part way down the screen should means that you are filling the entire screen with a new color faster than the video is coming out. I see 20 bars, meaning 20 fills in 1/60th of a second. Or, 1200 full screen fills per second. That's (320*200*20*60) = 76.8 million pixels written per second. Really close to the predicted figure.
Writing 4 adjacent pixels in a fill takes (2+1+1+1+1) 125Mhz clocks for 6 clocks. 125Mhz / 6 clocks * 4 pixels = 83 million rendered pixels per second.
Without any cache, you would only fill 41 million pixels a second. The cache acceleration is even more than doubled with a copy-blit function as you need to do a pixel read, then a write which has that initial read as well making a 4 pixel copy go from taking 20 clocks down to 8 clocks. IE, copy 25 million pixels a second no cache VS 62 million pixels a second with caching.
In 1 bit color, writing 16 adjacent pixels = (2+16) 125Mhz clocks for 18 clocks. 125Mhz / 18 clocks * 16 pixels = 111 million rendered pixels per second.
Ok,
As for the line demo, doing it with my simple addition would be a hell of a lot more impressive, or any other type of addition to make spiral-graph type patterns I used to generate on my Atari800, except, on steroids...
It's ok, don't stress yourself, you wont really get any further.
I'll touch up the copy color transformation feature and your can make sure all the rest of the features like the collision detectors and soft reset works.
Next, we will look at filled triangles.
Also, you can try a 640x400 hi-res 2 color B&W mode. The lines should look very sweet.
-
Code: [Select]
CALL full_params ; Set rectangle coordinates
LD HL,0AFFH ; draw filled rectangle X[0],Y[0] to X[1],Y[1]
MAINLOOP:
LD L,A
INC A
AND 0FH ; restrict A to 0-15
CALL send_gpu
JP MAINLOOP
drawFRect:
CALL full_params
LD HL,0AFFH ; draw filled rectangle X[0],Y[0] to X[1],Y[1]
LD L,A
CALL send_gpu
RET
full_params:
LD HL,8000H ; set X[0] to 0
CALL send_gpu
LD HL,0C000H ; set Y[0] to 0
CALL send_gpu
LD HL,9140H ; set X[1] to 320
CALL send_gpu
LD HL,0D0C8H ; set Y[1] to 200
CALL send_gpu
RET
send_gpu:
PUSH AF
LD A,L
OUT (CMD_LO),A
LD A,H
OUT (CMD_HI),A
POP AF
RET
Arrrg, it's 0 to 319 and 0 to 199. This is a coordinate system on graph paper.
Since we hit the 76.8 million pixels written per second, your Z80 is probably overfilling the geometry's input fifo sending out over 1200 box-fills a second.
The line would be more difficult to flood the input fifo as they have so few pixels, even though pure vertical lines would render pixels at around half speed due to all the cache-miss. The box fills will mostly generate cache-hits rapidly accelerating the fill.
If you went to 2 or 1 bit color, the cache hits doubles or quadruples. In 1 bit color, the box fills should achieve a pixel write speed close to 111million pixels a second.
-
I'll touch up the copy color transformation feature and your can make sure all the rest of the features like the collision detectors and soft reset works.
Next, we will look at filled triangles.
Also, you can try a 640x400 hi-res 2 color B&W mode. The lines should look very sweet.
Okay, working on B&W hi-res mode test right now as I've got half an hour to spare. Not sure what I can get done this weekend, going to be busy, but hoping to get the tests done you've mentioned above. -
Uh.
What am I doing wrong with the MAGGIE setup here? I'm trying to draw a grid in 640x480x2. I'm getting the grid drawn in memory, but with the current MAGGIE settings I can't see anything. 
MAGGIE HW register settings:Code: [Select]08 00 00 00 12 00 00 50 7F 02 DF 01 00 00 00 00
If I change the first byte to 9, I can see the grid on the screen, but obviously distorted as it's the wrong bpp setting (I think? Bits 2-0 all low should be 1 bit per pixel in the BP2Rast_cmd byte, right?)
Here's my GPU settings:Code: [Select]; set GPU base_addr for graphics
LD HL,0F001H ; set Y[3] to 01
CALL send_gpu
LD HL,0B200H ; set X[3] to 200
CALL send_gpu
LD HL,7F00H ; send cmd 124 to set destination base address
CALL send_gpu
; set raster width (H) and bit depth (L)
LD HL,0F000H ; reset Y[3] to 0
CALL send_gpu
LD HL,0B27FH ; set X[3] to 639
CALL send_gpu
LD HL,7100H ; set dest width to Y[3]X[3] and bpp to 0 for 2 colours
CALL send_gpu
; set X & Y limits
LD HL,827FH ; set X[0] to 639
CALL send_gpu
LD HL,0C1DFH ; set Y[0] to 479
CALL send_gpu
LD HL,5F00H ; set max X & Y to X[0],Y[0]
JP send_gpu -
A) 08 00 0F 00 12 00 00 50 02 7F 01 8F 00 00 00 00
Your boot up values were already correct except for the character in blue which changed the text column address repeat mode to regular graphics.
Don't forget you need to set the background(pen0) and foreground(pen1) colors with the 'green' colored settings. Otherwise everything will be black and transparent.
Remember the color settings?
This is how you assign the position of both colors into the chosen palette color.
Or, on a 4 color screen, it assigns the missing upper 6 bits for that maggie layer.
How do you think we are able to assign dedicated palettes to each layer's colors when they have less than 256 colors?
You have a github account for this project. Let's see you current manual for using the MAGGIE. I'm sure the color palette assignment bits were in my documentation.
In other words: Where is the MAGGIE manual?
MAGGIE has been finished for over 6 months.
-
The manual is in docs/Microcom GPU Manual.docx.
There's been a fair bit of editing with the learning I've done over the last few days, I've yet to update that. -
The manual is in docs/Microcom GPU Manual.docx.
I'm just teasing.
There's been a fair bit of editing with the learning I've done over the last few days, I've yet to update that.
But now, you have a geometry processor and enough ram for 640x480 if you change the font to 8x8 and we move the HW registers outside the first 512 bytes to the end of memory.
Big update on the GPU core coming.
I got rid of the 4word 0latency fifo and changed it for my own 2word FWFT fifo.
It saved 10% on the logic cell count and it's easier to hit the crucial 125MHz FMAX.
I've also added 2 XOR color transformations on the CopyPixel and PastePixel commands.
Now all that's left the the geometry plotter's ellipse, filled triangle & a rectangle copy from graphic ram A to B, size (X,Y).
Then your done.
-
Here is a test GPU project. I've changes all the 3/4 word fifos into a new 2 word fifo. Verify everything works.
We've gone from 90% utilization to 79%. With a few compiler setting changes, we can possibly get this same project down to 72%.
-
Been busy with other stuff for the last 24 hours - tomorrow probably the same as well - but I grabbed an hour or so to have a look at your latest update just now and I can't really test it properly.
Well, it seems to work fine as far as I can tell, but when I ran my graphics test program which draws a grid on the screen (each cell 10x10 pixels) with a single red cursor (drawn with a single filled rectangle), the image was corrupted - the vertical lines were no longer regularly spaced (or every third vertical line is missing and they aren't aligned with the start and end of the screen), and the red 'cursor' that should fill a cell spills into adjacent cells.
I've tried two previous versions of the GPU project as well as your new version and the results are the same.
I added some random lines to the mix and the attached image is what I get. Now I'm not really sure what's going on - I'm just hoping that it's a simple error I've made in my test code, but I can't see anything.
Before you start tearing the HDL apart, I just thought I'd post the pics in case it's an obvious issue that you can identify straight away. Otherwise, I'll have to put together another test program to see if the same thing happens again or if it's some stupid bug I've introduced to the original test program somehow. The lines and the red rectangle are making me wonder if it's not my test code, though. There's no way I'm aware of that a mistake in my code (MAGGIE settings or geo_unit setup) could produce broken lines or rectangles like that.
... but text mode is working absolutely fine - I'm not detecting any errors or artefacts in the symbols or text mode in general, even after running the test program above - so that points the finger back at the MAGGIE/geo_unit settings again...
I'm really short on time at the moment, otherwise I'd dig into this a lot more before posting, but it's late here and I have to hit the sack. This is worrying me though, as it's done the same thing on three different versions of the project.
The only other thing I'm worried about is if something has broken in the FPGA, but I've no real reason to think that.
Second image is 640x480 mode - same grid with random lines. I haven't been able to get the grid to display properly in 640x480, despite your recent posts with revised MAGGIE settings, so the distorted grid is 'normal', but the broken lines are showing up in this mode too.
The Z80 seems to be able to read and write the GPU RAM just fine - I can load in new character sets from CP/M so block reads/writes to GPU RAM are working fine.
Any ideas?
-
Maybe in the latest update, I overwrote the wrong 'data_mux_geo.sv'.
Yup, just checked, overwrote the 'data_mux_geo.sv' with an older one in the last update.
I'm making a new clean 'GPU' project now.
Until I upload it, you may swap out the 'data_mux_geo.sv' with the gpu_xxx_endianfix.zip upload which has the correct .sv version inside.
-
Ok, I completely cleaned and rebuilt your 'GPU_EP4CE10'.
This means rename or backup-delete whatever folder you have now and begin this new one alone.
Two thing you need to do.
A) You have 2 IO pins in your design which still have no IO pin assignment. It's been like this awhile.
B) You need to change your PS2 keyboard decoder for a synchronous one. The one you have which crosses 3 clock domains is messing up the timing report and the compiler's efforts to rank how to optimize it's location in the FPGA fabric. You other choice is to learn how to setup and define cross domain clock correlation timing restrictions.
As the design is 83% full and we have some spaghetti logic, achieving the FMAX is becoming difficult as we are close to the edge. Without providing assignments to the compiler to give it clues on where to layout the logic, or having the full subscription version of Quartus & progressively fitting the design withe the much more powerful logic-lock functions, we are left with adding pipeline buffers and trying the let the compiler work out how to deal with the design optimization on it's own. Also, for now, defining where to locate logic on the fpga would all become useless if you change fpga size or go to another vendor.
I've made some additional changes, so let me know if this latest version works fine & let me know if you can switch to a better all synchronous PS2 keyboard interface.
(You can see you had a lot of useless residue in the older uploads as this .zip is ~1/2 size for the complete project.)
-
Ok, I completely cleaned and rebuilt your 'GPU_EP4CE10'.
This means rename or backup-delete whatever folder you have now and begin this new one alone.
Awesome, thank you - all working fine now.Two thing you need to do.
A) You have 2 IO pins in your design which still have no IO pin assignment. It's been like this awhile.
Done this now - have assigned the tx/rx LED outputs for the rs232_debugger module in the pin planner. Seem to still be getting the 'some pins have incomplete assignments' message, though? How do I view the I/O Assignments Warnings report? I can't seem to find out how to view it online..B) You need to change your PS2 keyboard decoder for a synchronous one. The one you have which crosses 3 clock domains is messing up the timing report and the compiler's efforts to rank how to optimize it's location in the FPGA fabric. You other choice is to learn how to setup and define cross domain clock correlation timing restrictions.
I'll work on this this week.
I've made some additional changes, so let me know if this latest version works fine & let me know if you can switch to a better all synchronous PS2 keyboard interface.
It's all good. Will try to find another PS2 interface module, or start converting the existing one to SystemVerilog and synchronous logic. 
-
Before I start investing precious time working this new file into the project and getting it to work with the Z80 interface, do you think the attached PS2 module would be an improvement?
-
Ok, here is an enhanced cleaned up version which has a ton of wiggle room on the FMAX for the geometry unit at the limiting factors right now isn't even the geometry processor, but the Z80 bridge and vid_osd_generator. Download the new attached Quartus project. Make sure you older one is renamed so there is no chance some Quartus compile settings wont migrate between versions.
Though we are at 84% device utilization now, it is better than the 90% we were at last week.
My replacement of the 4 word 0 latency fifo for the new 2 word FWFT fifo really made it possible and I don't think the geometry unit has suffered. However, you need to test everything once again to make sure. A speed test of the filled full screen boxes will tell you. If you still get 20 vertical colored bars, then we are still at full pixel writing speed.
I also finished the pixel writer copy&paste color transformation feature to alter the color between source image and destination image. Simulation illustration coming.
(My new 2 word FWFT elastic FIFO designed purely to increase FMAX in large processing designs located here: 2 Word FWFT FIFO )
(New slacks now attached in image. Worst geometry now has 0.625ns clack and the system worst is 0.405ns slack instead of last week's version where the worst slack was 0.081ns and took 4.5 minutes to compile.)
-
Ok, here is an enhanced cleaned up version which has a ton of wiggle room on the FMAX for the geometry unit at the limiting factors right now isn't even the geometry processor, but the Z80 bridge and vid_osd_generator. Download the new attached Quartus project. Make sure you older one is renamed so there is no chance some Quartus compile settings wont migrate between versions.
Though we are at 84% device utilization now, it is better than the 90% we were at last week.
Wow, thanks - performance seems to have jumped as far as I can tell. Just wondering if the compilation setting was right, though? I'm sure I saw it prioritising area at the expense of timing?My replacement of the 4 word 0 latency fifo for the new 2 word FWFT fifo really made it possible and I don't think the geometry unit has suffered. However, you need to test everything once again to make sure. A speed test of the filled full screen boxes will tell you. If you still get 20 vertical colored bars, then we are still at full pixel writing speed.
Here's what I'm getting now - although I don't think the video (or my phone, more specifically) is up to the task any more...
The bars are not as clear as they were previously - they're thinner - so it looks like the system is working faster. The palette was slightly corrupted from a previous test, so some of the bars may be very similar colours, but I'm counting about 25?I also finished the pixel writer copy&paste color transformation feature to alter the color between source image and destination image. Simulation illustration coming.
(My new 2 word FWFT elastic FIFO designed purely to increase FMAX in large processing designs located here: 2 Word FWFT FIFO )
(New slacks now attached in image. Worst geometry now has 0.625ns clack and the system worst is 0.405ns slack instead of last week's version where the worst slack was 0.081ns and took 4.5 minutes to compile.)
Okay, I need to focus on testing the collision timers and these new copy/paste commands. Might get a little time tomorrow, hopefully. -
It looks all messed up. It looks slower in your video compared to the earlier stable ones, or at least stability-wise. Did you change your code? This may be a bug on my end. Try 1 or 2 earlier versions of the GPU. Or, has you cell phone video capture slowed down?
You didn't need to video the bars, just count them. Originally, your Z80 is clearly out-pacing the first 512 word geometry FIFO input, but you wont be able to see overshoot errors. I see around 20 bars in your still image. The question was not if it was going faster, but was it going slower.
What I needed to see was properly drawn lines. An also, my recommendation for a simple line algorithm in assemble which just incremented in 8 bit the x0,y0 and x1,y1 coordinates by those odd numbers, plus add 1 to color for every line, only checking the keyboard after every 256 lines drawn. All 8 bit single inc and odd opps to try and tax the line algorithm.
This would also prove a massively more impressive video as no Z80 could ever render so many screen size lines ever so fast before. The screen fills only showed a final few percent of the filled rectangles. However it is now clear, once we have the copy-blit function in geo unit, you will then be able to render your font, or multiple fonts on the bitmap screen with even proportional spacing as well as smoothly scroll the screen pixel-by-pixel in any direction without relying on the MAGGIE as a special layer function.
-
Wow, thanks - performance seems to have jumped as far as I can tell. Just wondering if the compilation setting was right, though? I'm sure I saw it prioritising area at the expense of timing?
There is something utterly messed up with that setting in Quartus Prime. Anything I use has little effect on the performance. However, in older Quartus -Non Prime- versions, there older Synthesis Optimization Technique, Speed, Balanced, Area, actually worked for your design. So, I added this line in the assignment editor:
set_global_assignment -name CYCLONEII_OPTIMIZATION_TECHNIQUE SPEED
Low and behold, with some of my other code changes, it worked. And yet, Quartus Prime doesn't even support 'CYCLONEII', yet, that setting is in the 'Advanced Settings (Synthesis)' in the compiler settings as plain old 'optimization technique.' Now, if you want to contact Intel and find out why, be my guest. I'm sure you can join their forum and post the question with your project stats. Maybe there is a more modern and better way to achieve the same capability, but I do not know what it is.
By the way, changing this setting in the compiler yields:
Area - 78% full, 125Mhz
Balanced - 81% full, 127MHz
Speed - 84% full, 131MHz.
Yet that stupid Optimization Mode window with the 6 settings does diddly-squat.
(Edit, is some cases that Optimization Mode does work, however, it seems to only be adjusting the 'Fitter' controls, not the 'Synthesis' compiling work like the CycloneII Synthesis Optimization Technique.)
-
Before I start investing precious time working this new file into the project and getting it to work with the Z80 interface, do you think the attached PS2 module would be an improvement?
Since I do not have a board to test this module, I cannot say anything about it's function. However, it does seem to be a synchronous design and it also seems it can transmit something on the PS2 bus as well since it uses tristate ports for the PS2 IO. I think you can control the keyboard LEDs with it.
Give it a try, but there is 1 line in it which Quartus is ignoring. Take a look at line 652. You'll notice it is green/commented out. You'll need to delete the last character on line 651 to make that line active code, or, just add an additional space at the end of line 651.
-
It looks all messed up. It looks slower in your video compared to the earlier stable ones, or at least stability-wise. Did you change your code? This may be a bug on my end. Try 1 or 2 earlier versions of the GPU. Or, has you cell phone video capture slowed down?
Lighting was different, so the exposure setting on the camera lens may have been different.You didn't need to video the bars, just count them. Originally, your Z80 is clearly out-pacing the first 512 word geometry FIFO input, but you wont be able to see overshoot errors. I see around 20 bars in your still image. The question was not if it was going faster, but was it going slower.
What I needed to see was properly drawn lines. An also, my recommendation for a simple line algorithm in assemble which just incremented in 8 bit the x0,y0 and x1,y1 coordinates by those odd numbers, plus add 1 to color for every line, only checking the keyboard after every 256 lines drawn. All 8 bit single inc and odd opps to try and tax the line algorithm.
I'll have a go at this later this afternoon hopefully, but I'm not convinced I understand exactly what you're asking for. It seems you want arbitrary-length lines that have 3,7 added to X[0],Y[0] and 5,9 added to X[1],Y[1] and their colour incremented every loop? Is that right? Not full-screen horizontal lines (I guess because they'd generate far more cache hits)?
-
Since I do not have a board to test this module, I cannot say anything about it's function. However, it does seem to be a synchronous design and it also seems it can transmit something on the PS2 bus as well since it uses tristate ports for the PS2 IO. I think you can control the keyboard LEDs with it.
Yes, I think that's the idea - it can control the status LEDs on the keyboard.Give it a try, but there is 1 line in it which Quartus is ignoring. Take a look at line 652. You'll notice it is green/commented out. You'll need to delete the last character on line 651 to make that line active code, or, just add an additional space at the end of line 651.
That's the unescaped backslash character in the comment on line 651 causing that. Interestingly, the code appears fine in my Quartus Prime editor window. When I viewed the code in Notepad++ yesterday it had displayed the next line as 'commented out', the single backslash was confusing the text renderer, but Quartus appears to be coping with it.