6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Apr 29, 2024 7:08 am

All times are UTC




Post new topic Reply to topic  [ 353 posts ]  Go to page Previous  1 ... 20, 21, 22, 23, 24
Author Message
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri May 11, 2012 11:40 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Ah, you're right. I'm done with the .b core!
This is a problem some peope have: is that we don't know when to quit!

'cept I quit for now. Head post updated for the last time tonight...

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Thu Dec 13, 2012 5:24 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I've been looking over the ALU.v and cpu.v to make sure they are inline with Arlet's most recent updates to his original core on Github, and I've found 1 oversight each in my modifications of ALU.v and cpu.v. I've updated the .b core on Github.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Feb 13, 2013 7:42 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Ah. I see something!

The 16-bit zeropage and stackpage pointers that place the respective pages within the 4GB space could be made to go 'off-cpu' in order to properly affect the address decoding scheme for the FPGA stackpage and zeropage blockRAMs! So the softcore could keep up with a piece software that wishes to relocate zeropage or stackpage. I will experiment with this next. :D

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Thu Feb 14, 2013 12:56 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I think this is going to work. It has passed synthesis already. This is the address decoding receiving signals from the .b core:
Code:
module SRAMif( input cpuWE,
               input [31:0] cpuAB,
               input [15:0] ZPP,            //from CPU, zeropage pointer
               input [15:0] SPP,            //from CPU, stackpage pointer
               output reg ram1CS = 0,
               output reg ram1WE = 0,      //pre-init to '0', not selected
               output reg ram2CS = 0,
               output reg ram2WE = 0,      //pre-init to '0', not selected
               output reg rom1CS = 0
               );

// address decoding for internal blockRAMs
wire [15:0] ZPP;
wire [15:0] SPP;

always @* begin
   ram1WE <= ( !ram1CS && cpuWE );
   ram2WE <= ( !ram2CS && cpuWE );
   if ( (cpuAB >= {ZPP,16'h0000}) && cpuAB <= ({ZPP,16'h03ff}) )      //1Kx16 zeropage RAM address decode w/ZPP reg as the MSB pointer
      ram1CS <= 0;
      else ram1CS <= 1;
   if ( (cpuAB >= {SPP,16'hfc00}) && cpuAB <= ({SPP,16'hffff}) )      //1Kx16 stackpage RAM address decode w/SPP reg as the MSB pointer
      ram2CS <= 0;
      else ram2CS <= 1;
   if ( (cpuAB >= 32'hffff_f000) && (cpuAB <= 32'hffff_ffff) )      //4Kx16 'initialized RAM' ROM address decode
      rom1CS <= 0;
      else rom1CS <= 1;
end

and the modifed .b CPU output signals:
Code:
module CPU( input clk,          // CPU clock
            input rst,            // reset signal
            output reg [aw-1:0] addr, // address bus
            input [dw-1:0] din,      // data in, read bus
            output reg [dw-1:0] dout,     // data out, write bus
            output reg we,              // write enable
            output reg [dw-1:0] ZPPout,   //Zeropage pointer
            output reg [dw-1:0] SPPout,   //Stackpage pointer
            input IRQ,              // interrupt request
            input NMI,              // non-maskable interrupt request
            input RDY               // Ready signal. Pauses CPU when RDY=0  );
            );
......
......
assign ZPPout = QAWXYS[20];
assign SPPout = QAWXYS[21];


EDIT: I updated Github after a quick software test that appeared to work. Will post some waveforms after more in-depth tests.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Feb 15, 2013 1:59 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
This feature of zero page and stack page relocation probably won't be too useful to me now since I am strictly using blockRAMs inside the FPGA in the PVB project. But if these memories were outside of the FPGA and there were multiple CPUs running in parallel, this would be a useful feature. Also it didn't slow down the core any, so I'll leave the latest update to Github intact.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Mar 23, 2013 2:20 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
The zero page and stack page relocation registers have proven to be very valuable recently. As a piece of functioning hardware within the .b core, it is able to fool the software. This is something I became fully aware of when it was necessary to allocate the video memory at the bottom of the cpu memory map from $0000_0000 - $027F-$01E0. Read more about that here. It involves plotting 16-bit X & Y values and using indirect indexed mode to interpret the X value from the LSB and the Y value from the MSB.

Also, regarding this core, an error has been found when and LSR opcode was used for any of the addressing modes. This was corrected in the ALU section, later on in the samethread. Github has been updated. :D

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Mar 23, 2013 8:21 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Just to summarise, then, EEye: You have added two 16-bit registers, with some special instructions to access them, which act as the high half of the address for zero page and stack accesses. So the stack and zeropage can be relocated to any 64k section of the 4G address space.

(I'll update that description if I got it wrong!)

Nice work!

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Mar 23, 2013 1:59 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BigEd wrote:
Just to summarise, then, EEye: You have added two 16-bit registers, with some special instructions to access them, which act as the high half of the address for zero page and stack accesses. So the stack and zeropage can be relocated to any 64k section of the 4G address space.

(I'll update that description if I got it wrong!)

Nice work!

Cheers
Ed

That's correct and thanks! And it's probably worth it to save some address decoding resources and have them both use the same 64K block, as has been mentioned before, although last year!

_________________
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  [ 353 posts ]  Go to page Previous  1 ... 20, 21, 22, 23, 24

All times are UTC


Who is online

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