6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 2:10 pm

All times are UTC




Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1 ... 30, 31, 32, 33, 34, 35, 36 ... 41  Next
Author Message
PostPosted: Tue May 07, 2013 12:58 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 07, 2013 2:32 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 07, 2013 2:52 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 07, 2013 4:39 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
It isn't much now... *

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed May 08, 2013 1:34 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
File comment: Caught in the midst of a 'radar sweep'
P1000998.JPG
P1000998.JPG [ 128.2 KiB | Viewed 1276 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Wed May 08, 2013 3:45 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sun May 12, 2013 12:11 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sun May 12, 2013 9:22 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon May 13, 2013 8:17 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 13, 2013 11:13 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 14, 2013 12:43 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 14, 2013 4:30 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I must step back, take a breather and rethink where my focus should be. While something is there with the barrel shifter idea, it is a tangent that goes to a far off place. I think I need to learn about inferring dual port RAMs in the FPGA for use as a FIFO so hopefully the cpu or Line Generator can write to the RAM at anytime.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue May 14, 2013 9:52 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I couldn't give up on the scrolling. I was so close this morning, now I am even closer. Still one error to sort out on the horizontal scrolling.

Video

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed May 15, 2013 12:01 am 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 411
Location: Minnesota
Quote:
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...


I'm sure you've thought of this already, but my first reaction was "okay, you'll need another pair of instructions to do push and pull stack operations". Unless the PHP and PLP instructions themselves are modified to do two 16-bit pushes each time, maybe.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 15, 2013 11:50 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
teamtempest wrote:
I'm sure you've thought of this already, but my first reaction was "okay, you'll need another pair of instructions to do push and pull stack operations". Unless the PHP and PLP instructions themselves are modified to do two 16-bit pushes each time, maybe.

I hadn't really thought of it, thanks for bringing it up though. I would think that for the value going into the 16-bit wide stack, the upper 16 bits would be truncated during a PHP. During a PLP, the upper 16-bits of the Status Register would be undisturbed.
Using the upper 16-bits [31:16] for real time I/O control functions could be advantageous since they would be left alone during a PHP/PLP. Also I could see where there would be cases where preservation might be needed. In that case, the formerly unused upper 8-bits [15:8] I use currently for I/O would be preserved.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1 ... 30, 31, 32, 33, 34, 35, 36 ... 41  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 16 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: