Concept & Design of 3.3V Parallel 16-bit VGA Boards

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

Arlet wrote:
... All you need is a register that contains the start address of the frame in memory... or do hardware scrolling.
Oh, very nice!
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

Post by ElEctric_EyE »

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 cpu now has 4 outputs directly tied to the Processor Status Register bits [11:8]. Each bit output has 2 opcodes to set and clear the control bit. It is a 2-cycle operation. 2 of these bits will be immediately taken up for the most upper address bits on the video RAM for page flippling. So 2 are left for other control purposes.
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

Post by ElEctric_EyE »

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
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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:

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
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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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.
It appears to work. I simply did a

Code: Select all

BCF0C $FFFE              ;CF = LineGen Ready. 1 = ready
which is a branch opcode that translates Branch if Control Flag '0' is Clear, so it is branching to itself, waiting. In this case LineGen outputs a LGREADY signal that is '0' when plotting. IMO this is better than tapping the RDY signal, which gives the poor cpu a heart attack. With the flag, the cpu can go about it's business and retest the flag when needed.

Wish 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

Post by ElEctric_EyE »

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. :lol:
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

Post by ElEctric_EyE »

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

Post by ElEctric_EyE »

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.
Attachments
Caught in the midst of a 'radar sweep'
Caught in the midst of a 'radar sweep'
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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...
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

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.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by BigEd »

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
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Post by ElEctric_EyE »

BigEd wrote:
What you're doing here, in bringing out internal registers to the outside, is giving the CPU some I/O instructions...
Just to clarify, I'm bringing out some accumulators for their 16-bit data output only and I am also using unused I/O bits in the expanded 16-bit status register. Bit testing opcodes have been added for the inputs/ So there are two separate things going on here. Both of these methods avoid memory mapping. A typical I/O Port would use an LDA/STA. By using Accumulator outputs, I only need an LDA. It's fast and it's convenient from a software & also a Verilog point of view IMO, resources seem to be shared. My memory map is pretty typical though: I have video, zero-page, stack, 4 locations to store line coordinates and ROM.


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

Post by ElEctric_EyE »

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

Code: Select all

PLOT:   
         begin
            RAMWE <= 1;
            X <= x0 >> 3;
            Y <= y0 >> 3;
         end
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.
Post Reply