6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 14, 2024 1:46 am

All times are UTC




Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 41  Next
Author Message
PostPosted: Mon Apr 29, 2013 4:31 pm 
Offline

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

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


Top
 Profile  
Reply with quote  
PostPosted: Sat May 04, 2013 11:06 pm 
Offline

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

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


Top
 Profile  
Reply with quote  
PostPosted: Sat May 04, 2013 11:22 pm 
Offline

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

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 06, 2013 3:55 pm 
Offline

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

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


Top
 Profile  
Reply with quote  
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 1266 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: 10977
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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 41  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 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:  
cron