65ORG16.b Core

[ElEctric_EyE]

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

[ElEctric_EyE]

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.

[ElEctric_EyE]

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.

[ElEctric_EyE]

I think this is going to work. It has passed synthesis already. This is the address decoding receiving signals from the .b core:

Code: Select all

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: Select all

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.

[ElEctric_EyE]

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.

[ElEctric_EyE]

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.

[BigEd]

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

[ElEctric_EyE]

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!