I need to add a few hi-speed I/O flags to the .d core that will work in conjunction with the new, soon to be made, state machine.
Concept & Design of 3.3V Parallel 16-bit VGA Boards
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Arlet wrote:
... All you need is a register that contains the start address of the frame in memory... or do hardware scrolling.
I need to add a few hi-speed I/O flags to the .d core that will work in conjunction with the new, soon to be made, state machine.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
ElEctric_EyE wrote:
I need to add a few hi-speed I/O flags to the .d core that will work in conjunction with the new, soon to be made, state machine.
The .d core also has 4 inputs tied to the Processor Status Register bits [15:12]. As inputs, they can be tested by 2 branch opcodes. Branch on clear, or branch on set per bit... Arlet gave a very helpful suggestion on page 2 of the .d core thread which allowed me to head in the right direction and complete this addition very quickly. The .d core Verilog has been updated, as well as the new opcodes on the new .d core branch on Github.
These additions have not slowed down the cpu speed from 100MHz, in the project, although more runs of smartexplorer were needed.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
So before I transition to a state machine, and understanding now how the signals should be sent to the SyncRAM I must know what I am doing wrong with my simple attempt at a Verilog interface. I cannot abandon it until I know what is wrong with it.
I am close. A report soon
I am close. A report soon
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
I see why it won't work now. It has to do with my attempt at using one output bus that was connected to the cpuDIN and no separate input bus, as I was only trying to write I didn't think I needed it and it was ok when just the cpu was writing.... I will move on the make the state machine now, now that I know what will work.
Speaking of state machines, I have an idea to make one that does all the plotting without the cpu. I got real excited when the LineGen module was able to run @180MHz. Yesterday I put in an order for 2 4ns 2Mx18 SyncRAMs, but they won't be delivered for 8 weeks. These have different pinouts, so I would have to redesign the boards, but this is way in the future.
Speaking of state machines, I have an idea to make one that does all the plotting without the cpu. I got real excited when the LineGen module was able to run @180MHz. Yesterday I put in an order for 2 4ns 2Mx18 SyncRAMs, but they won't be delivered for 8 weeks. These have different pinouts, so I would have to redesign the boards, but this is way in the future.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Yay it works! I confess I did not start on the state machine, it just seems too simple of a thing for a state machine. So far I have just writing to the RAM down 100% now. I did skew the clock going to the SyncRAM to make up for the FPGA delay. Maybe it's cheating, but it works! I lowered the speed of the cpu to 50MHz so I wouldn't be slowed down by running smartexplorer all the time.
It successfully clears the screen blue in software (can probably do this in hardware now), cpu sends coordinates to LineGen and is delayed a set amount, LineGen draws a red line, then the cpu draws a yellow circle.
Here is the simple interface code:
I think the next logical step is to add a 'Done' bit to the LineGen module and send it to one of the cpu flags.
It successfully clears the screen blue in software (can probably do this in hardware now), cpu sends coordinates to LineGen and is delayed a set amount, LineGen draws a red line, then the cpu draws a yellow circle.
Here is the simple interface code:
Code: Select all
module SRAMif( input clk,
input vramCS, //cpu is reading/writing to videoRAM
input cpuWE,
input RAMWE, //LineGen is drawing
inout [15:0] SRD,
input [15:0] BACCout, //pixel color from cpu
input [9:0] X, //LSB of LineGen address
input [8:0] Y, //MSB
input [20:0] Vaddr, //pixel clock address from HVSync Generator
input [31:0] cpuAB,
output reg [20:0] SRaddr,
//output reg [15:0] SRDO, //to cpu
output reg SRWEn
);
reg SRWEn2;
reg [15:0] SRDO;
always @(posedge clk) begin
SRWEn2 <= SRWEn;
SRaddr <= RAMWE ? {2'b00, Y, X} : vramCS ? cpuABopt : Vaddr;
SRWEn <= !(RAMWE || (vramCS && cpuWE));
if (SRWEn)
SRDO <= BACCout;
end
reg [20:0] cpuABopt;
always @* begin //optimize the videoRAM address for plotting (X,Y) in the (LSB,MSB) for indirect indexed
cpuABopt [20:19] <= 2'b00; //bank bits
cpuABopt [18:10] <= cpuAB [24:16]; //Y[8:0]
cpuABopt [9:0] <= cpuAB [9:0]; //X[9:0]
end
assign SRD = SRWEn2 ? 16'hZZZZ : SRDO; //I/O MUX'd latch to SyncRAM databus. High 'Z' during a read
endmodule-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
ElEctric_EyE wrote:
...I think the next logical step is to add a 'Done' bit to the LineGen module and send it to one of the cpu flags.
Code: Select all
BCF0C $FFFE ;CF = LineGen Ready. 1 = readyWish I had the cycle counter to prove it, but I don't notice the pixel color problem and lack of circle pixels. I had noticed this effect when I did an experiment to test the priority when the cpu was trying to plot at the same time LineGen was outputting.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Presently seeing timing scores in the 10,000+ range using smartExplorer in order to get the cpu and SyncRAM running @100MHz. I'm optimistic. I've seen the tools optimize initial scores like this to a timing score of zero after 23 runs. If not I have a backup plan, which shouldn't disturb things too much, as far as frame buffer and video/cpu timing.
EDIT: After run #19, timing score of 3860. Now it's branching off, up to run29.
EDIT: Unfortunately, it doesn't look like it's going to happen. I have the limit of runs set to 48 run in smartExplorer and it's up to 46. Since run29, nothing has beat the 3860 score... Which means it's time for plan B. Plan B is to run the cpu and graphics at 70MHz with a resolution of 1024x768. This means there can still be a 2x frame buffer in the 133MHz 2Mx18 SyncRAM. I would've had 4x frame buffer in the 640x480.
EDIT: After run #19, timing score of 3860. Now it's branching off, up to run29.
EDIT: Unfortunately, it doesn't look like it's going to happen. I have the limit of runs set to 48 run in smartExplorer and it's up to 46. Since run29, nothing has beat the 3860 score... Which means it's time for plan B. Plan B is to run the cpu and graphics at 70MHz with a resolution of 1024x768. This means there can still be a 2x frame buffer in the 133MHz 2Mx18 SyncRAM. I would've had 4x frame buffer in the 640x480.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
It isn't much now... *
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Everything transitioned over (except the software as you can see below) to 1024x768 no problem. Everything running @70MHz now. Next I'll hook up 1 of the .d core's control bits to control page flipping.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
The software has been updated and everything works in 1024x768 as it did in 640x480.
Added the Control Bit 0 for page flipping. Was easy, just 2 extra opcodes were used in the assembly. A CCB0 opcode to set page 0. Clear the screen, plot a circle and perform the line drawing 'radar sweep'. Finally a SCB0 to perform the page flip. I did not take heed of vsync though, to avoid the tearing effect that is sure to be expected, I will add vsync to Control Flag 1 and test for it before doing the page flip.
Now this is getting exciting! So easy from a programmers POV now, but I especially love the hardware aspect of where this project is headed.
With the page flipping I look forward to getting rid of the "snow effect". Not only that, page flipping should make moving objects appear smooth, unlike if I were to have 1 video page and attempt to a software PLOT, CLEAR, PLOT, CLEAR, etc. I remember having issues scrolling a character in the C-64 video, and I had found the solution but that was years ago, and now it shouldn't even matter.
Added the Control Bit 0 for page flipping. Was easy, just 2 extra opcodes were used in the assembly. A CCB0 opcode to set page 0. Clear the screen, plot a circle and perform the line drawing 'radar sweep'. Finally a SCB0 to perform the page flip. I did not take heed of vsync though, to avoid the tearing effect that is sure to be expected, I will add vsync to Control Flag 1 and test for it before doing the page flip.
Now this is getting exciting! So easy from a programmers POV now, but I especially love the hardware aspect of where this project is headed.
With the page flipping I look forward to getting rid of the "snow effect". Not only that, page flipping should make moving objects appear smooth, unlike if I were to have 1 video page and attempt to a software PLOT, CLEAR, PLOT, CLEAR, etc. I remember having issues scrolling a character in the C-64 video, and I had found the solution but that was years ago, and now it shouldn't even matter.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Not trying to to rush the project at this point, this project is at a crux...
I've successfully changed the Verilog in the .d core and the software to use the Q accumulator to hold the pixel value, since the A thru D accumulators were meant for applications requiring barrel shifting. Previously I've used the B Accumulator for the pixel value.
Currently, I'm trying to expand the Processor Status Register to 32 bits for more I/O status checking and output, without a hit to the resources used in the FPGA.
The SO flag is an interesting pin on the many different versions of the 6502 IC...
I've successfully changed the Verilog in the .d core and the software to use the Q accumulator to hold the pixel value, since the A thru D accumulators were meant for applications requiring barrel shifting. Previously I've used the B Accumulator for the pixel value.
Currently, I'm trying to expand the Processor Status Register to 32 bits for more I/O status checking and output, without a hit to the resources used in the FPGA.
The SO flag is an interesting pin on the many different versions of the 6502 IC...
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
I expanded the Processor Status Register to 32 bits and filled the upper 16 bits with hardwired zeroes for now. Until I start using them, I can't observe the resource usage yet...
But today I made some headway into vertical scrolling. I pulled the O Accumulator data lines out of the cpu and wired them up to the HVSync module for a Y offset. With the resolution of 1024x768, there are 256 lines left in memory with my 2Mx16 RAM, in the Y direction.
Now that a few hardware tools are in place, it will be up to the software to take advantage. I will do some experiments in scrolling, plotting and page flipping in the next few days.
But today I made some headway into vertical scrolling. I pulled the O Accumulator data lines out of the cpu and wired them up to the HVSync module for a Y offset. With the resolution of 1024x768, there are 256 lines left in memory with my 2Mx16 RAM, in the Y direction.
Now that a few hardware tools are in place, it will be up to the software to take advantage. I will do some experiments in scrolling, plotting and page flipping in the next few days.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
What you're doing here, in bringing out internal registers to the outside, is giving the CPU some I/O instructions. It's one of the things which I feel is awkward, when it comes time to hook up 64K RAM to a 6502, that the memory-mapped I/O gets in the way. Also, with separate I/O instructions, it should be an easier road to making I/O operations privileged.
Cheers
Ed
Cheers
Ed
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
BigEd wrote:
What you're doing here, in bringing out internal registers to the outside, is giving the CPU some I/O instructions...
EDIT: BTW, I realized I don't need page flipping when hardware scrolling, so scrolling up, down, left and right should be possible. I'll have to experiment with this next.
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
I'm not going to pursue scrolling at this time. I discovered something more interesting while trying to align address bits. The barrel shifter.
Using a variable barrel shifter together with the Line Generator should be interesting. First it made me realize how to approach to topic of subpixel precision, but subpixel precision is not my goal. I already did a neat experiment where the radar sweep was written into RAM at 1/3 the size by doing
Right now LineGen is working with 10-bit X and Y registers for 1024x1024. I was thinking why not use the full 32 bits so LineGen would be drawing in a virtual (4,294,967,296x4,294,967,296) then shift it down (>>22) to fit (1024x1024). There would actually be a little bit of error? because the integer division results in (1030x1030). I think the real error would be in multiplying the incoming 10-bit X and Y coordinates to fit the 32-bit registers. It will be an interesting experiment. I'm thinking, since I'm using a 16-bit cpu it would make sense to take advantage of this precision and draw in a virtual (65,536x65,536).
EDIT: Ah, I forgot there is a negative flag in the verilog, so I can't use 32 bits, but I'll try 31 bit X and Y registers.
Using a variable barrel shifter together with the Line Generator should be interesting. First it made me realize how to approach to topic of subpixel precision, but subpixel precision is not my goal. I already did a neat experiment where the radar sweep was written into RAM at 1/3 the size by doing
Code: Select all
PLOT:
begin
RAMWE <= 1;
X <= x0 >> 3;
Y <= y0 >> 3;
endEDIT: Ah, I forgot there is a negative flag in the verilog, so I can't use 32 bits, but I'll try 31 bit X and Y registers.