FGPA Anyone?

[M68008]

Taking another look and noticed that the fx68k CPU is using clk_sys as the clock... isn't that the 84 MHz clock?

[M68008]

Taking another look and noticed that the fx68k CPU is using clk_sys as the clock... isn't that the 84 MHz clock?

Never mind, I guess the actual CPU clock must be enPhi1 and enPhi2 instead.

[mk79]

Yes, basically everything runs on the same base clock and you use enable gates to match the actual required speed.

[M68008]

I dont't see where 4 cycles are added for word-size ROM access... is that somewhere?

[mk79]

That is not part of the release version because IIRC the QL stopped booting when it was enabled.

Code: Select all

diff --git a/QL.sv b/QL.sv
index ae3be5f..3f14c1e 100644
--- a/QL.sv
+++ b/QL.sv
@@ -277,7 +277,7 @@ end
 //////////////// QL RAM timing ////////////////////
 
 wire ram_delay_dtack;
-wire rom_delay_dtack;
+wire rom_dtack;
 
 ql_timing ql_timing(
 	.*,
@@ -777,6 +777,7 @@ wire cpu_dtack =
 	qlsd_sel? qlsd_dtack:
 	rom_shadow_read || rom_shadow_write? sdram_dtack:
 	cpu_ram? sdram_dtack && !ram_delay_dtack:
+	cpu_rom? rom_dtack:
 	1'b1;
 
 // Debugging only
diff --git a/rtl/ql_timing.sv b/rtl/ql_timing.sv
index b435ea1..b0ead66 100644
--- a/rtl/ql_timing.sv
+++ b/rtl/ql_timing.sv
@@ -12,6 +12,9 @@ module ql_timing
 	input			enable,
 	input			ce_bus_p,
 	
+	input			cpu_as,
+	input			cpu_rw,
+	input			cpu_rom,
 	input			cpu_uds,
 	input			cpu_lds,
 	
@@ -19,7 +22,8 @@ module ql_timing
 	input			sdram_oe,
 	input			sdram_dtack,
 
-	output reg	ram_delay_dtack
+	output reg	ram_delay_dtack,
+	output reg	rom_dtack
 );
 
 
@@ -43,6 +47,9 @@ wire could_start =
 // ________________________------------------_____________________________  16-bit access allowed, chunk 32+
 //              I WS WS WS WS S3 S2 S1 WN WN WN WN WN WN WN WN WN D1  I
 // _______________---------------------------------------------------_____  16-bit access must wait, chunk < 32
+//
+// I = idle, WS = wait for slot, W4 = STATE 4, Sx = waste slot cycles for 16-bit access, WN = wait for next slot, D1 = allow DTACK
+
 typedef enum reg [2:0] {
 	STATE_IDLE				= 3'd0,
 	STATE_WAIT_START		= 3'd1,
@@ -138,4 +145,59 @@ begin
 	end
 end
 
+
+typedef enum reg [1:0] {
+	ROM_STATE_IDLE			= 2'd0,
+	ROM_STATE_WAIT			= 2'd1,
+	ROM_STATE_FINISHED	= 2'd2
+} rom_delay_state_t;
+
+rom_delay_state_t rom_delay_state;
+reg [1:0] 			rom_wait_cnt;
+
+
+// Emulate 8-bit bus timing for 16-bit ROM
+always @(posedge clk_sys)
+begin
+	if (reset || !enable)
+	begin
+		rom_dtack <= 1;
+	end else if (ce_bus_p)
+	begin
+		case (rom_delay_state)
+		ROM_STATE_IDLE:
+			begin
+				rom_dtack <= 0;
+				if (cpu_as && cpu_rom)
+				begin
+					if (cpu_uds && cpu_lds)
+					begin
+						// 16-bit read access to QL ROM, delay it
+						rom_wait_cnt <= 2'd3;			// The STATE2->STATE4 transition will happen when we go to ROM_WAIT_STATE. Then do additional 4 wait cycles
+						rom_delay_state <= ROM_STATE_WAIT;
+					end else begin
+						// 8-bit access, we're done here
+						rom_dtack <= 1;
+						rom_delay_state <= ROM_STATE_FINISHED;
+					end
+				end
+			end
+			
+		ROM_STATE_WAIT:
+			begin
+				rom_wait_cnt <= rom_wait_cnt - 2'd1;
+				if (rom_wait_cnt == 2'd0)
+				begin
+					rom_dtack <= 1;
+					rom_delay_state <= ROM_STATE_FINISHED;
+				end
+			end	
+		
+		ROM_STATE_FINISHED:
+			if (!cpu_as) rom_delay_state <= ROM_STATE_IDLE;
+		endcase
+	end
+end
+
 endmodule
\ No newline at end of file

[M68008]

I've replaced the timing logic with what I'm implementing for Q-emuLator and it's much more accurate for Mister, too:

However, there must be an issue in IPC/ZX8302 communication, I had to use a hack where I disable ROM wait states when running IPC-related code (range 2F7C - 2FAE in JS ROM).

The SDRAM refresh can also add extra cycles as it's not in sync with the ZX8301 refresh. Haven't looked into how often that happens.

I'll try to clean up the logic and share it.

[mk79]

I've replaced the timing logic with what I'm implementing for Q-emuLator and it's much more accurate for Mister, too:

Funny, I use Test909, too

However, there must be an issue in IPC/ZX8302 communication, I had to use a hack where I disable ROM wait states when running IPC-related code (range 2F7C - 2FAE in JS ROM).

Aaah, yes, that was it, keyboard stops working correctly. Now I remember That was the point when I stopped working on it, too frustrating Of course the core shouldn't be OS specific in the end, but it's an interesting step. Might be difficult to debug, but since I tried the Xilinx ISE debugging environment I view Intel's SignalTap with much more appreciation, it's a 1000 times better.

The SDRAM refresh can also add extra cycles as it's not in sync with the ZX8301 refresh. Haven't looked into how often that happens.

SDRAM refresh only takes 0.5 CPU cycles at QL speed, I don't think it really matters. You probably have more speed deviation in real QLs from variance in the crystal (had to improve the QL-VGA core once because one QL was outputting the pixels faster than all the others I have).

I'll try to clean up the logic and share it.

Cool, thanks.

[M68008]

Funny, I use Test909, too

It's a nice benchmark, at least on the QL. Too short for emulators, though.

Might be difficult to debug, but since I tried the Xilinx ISE debugging environment I view Intel's SignalTap with much more appreciation, it's a 1000 times better.

As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.
If SignalTap is different and free, I'll give it a try.

SDRAM refresh only takes 0.5 CPU cycles at QL speed, I don't think it really matters.

Yes, timings are pretty close, the effect seems to be very small if any.

I'll try to clean up the logic and share it.

Cool, thanks.

I've sent you a pull request with the changes. Only tested with a standard QL and QL Speed, I hope it doesn't break the other scenarios too much

I have also fixed the IPC communication issue in the ZX8302 logic, mainly by adding a latch to COMDATA.

[mk79]

As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.

Oh wow, I never even tried using ModelSim, though it's probably the professional thing to do.

If SignalTap is different and free, I'll give it a try.

It's integrated in Quartus. It lets you add a logic analyzer into the core. You can define triggers, chose signals, etc. and then just get them live via JTAG while the core is running.

I've sent you a pull request with the changes. Only tested with a standard QL and QL Speed, I hope it doesn't break the other scenarios too much

Well, just looking at it, I think you broke QL-SD on speeds greater than QL by removing most of my cpu_dtack equation But haven't found the time to actually check it out yet.

I have also fixed the IPC communication issue in the ZX8302 logic, mainly by adding a latch to COMDATA.

Great, thanks!

[twellys]

As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.
If SignalTap is different and free, I'll give it a try.

The trick, I've found, to Modelsim comes when you change something in some code way down in the hierarchy => that code and everything upstream needs to be re-compiled.

Therefore, I use a script (Python/Perl/shell/Make/etc.) to the Modelsim compilation.