MSX1 Memory Mapper

Página 20/20
13 | 14 | 15 | 16 | 17 | 18 | 19 |

Por zPasi

Champion (499)

Imagen del zPasi

14-03-2016, 09:11

So the problem isn't just /RW signal being "hairy", it's also coming too early. Or the data coming too late. I've always thought when writing, should set data first and then toggle the clock. Seems that they did the opposite in Yamaha Wink

Maxis, you're my hero! I made a delay line of six ports of the 74HTC245, and it seems to work! Now I'm confident I can make this work.

I'll buy those 74HC14s to make sure it really works before I solder everything in place. Or should it be 74HCT14? I remember reading HCT variants are more compatible when connecting MSX to newer chips.

Por maxis

Champion (512)

Imagen del maxis

14-03-2016, 11:29

zPasi wrote:

Maxis, you're my hero! I made a delay line of six ports of the 74HTC245, and it seems to work! Now I'm confident I can make this work.

I'll buy those 74HC14s to make sure it really works before I solder everything in place. Or should it be 74HCT14? I remember reading HCT variants are more compatible when connecting MSX to newer chips.

Ha-ha, I'm glad that it works now Wink
HCT is a bit slower than HC and also HCT thresholds are more compatible with the TTL, so right, HCT is a better fit than HC.

I agree with you that the data must be stable on the falling edge of the IORQ signal. Here Yamaha have violated the standard. Maybe they thought that 30ns of a negative slack is not a big deal for the decoding logic, which is always slower.

What I find amazing is that till now I haven't seen a cartridge, which refused to work correctly in Yamaha computer.

Por zPasi

Champion (499)

Imagen del zPasi

14-03-2016, 12:50

maxis wrote:

What I find amazing is that till now I haven't seen a cartridge, which refused to work correctly in Yamaha computer.

It's amazing, really! There are plenty of CPLD and FPGA based carts out there, and supposedly they all just work, even on Yamahas...

Now I'm running Nemesis2 (cracked) disk version. This is a much better test, because it requires a working ram mapper. So far no freezes.

And the SRAM doesn't seem to need that /RW cleaning after all. It seems when the timing problem wasn't solved, my CPLD design somehow interfered the SRAM even with mapper functions disabled. Now the setup is running happily, with /RW directly connected to the SRAM. Weird.

But my other SRAM seems incompatible. I'll test that more later.

Por zPasi

Champion (499)

Imagen del zPasi

14-03-2016, 22:19

Just for a learning purpose, I tried this:

NET "d(0)"  LOC = "P27" ;
NET "d(1)"  LOC = "P19" ;
NET "d(2)"  LOC = "P20" ;
NET "d(3)"  LOC = "P21" ;
NET "d(4)"  LOC = "P22" ;

NET "WR"  LOC = "P12";

NET "d(0)" TNM_NET = "data";
NET "d(1)" TNM_NET = "data";
NET "d(2)" TNM_NET = "data";
NET "d(3)" TNM_NET = "data";
NET "d(4)" TNM_NET = "data";

TIMEGRP "data" OFFSET = IN 20 AFTER "WR";

"WARNING:Cpld - Clock 'wr' is used in an OFFSET timespec, this clock should be explicitly declared as a global clock input (BUFG) in your design in order for the OFFSET timespec to be properly analyzed."

Great. Now I need a global clock. Back to reading PDF and / or Googling. I'm doing this for fun, you know Smile

Then I invented a beautiful hack:

...
architecture Behavioral of MapRegDumy is
	SUBTYPE REGDATA is STD_LOGIC_VECTOR (pagebits downto 0);
	TYPE reg_array IS ARRAY(0 TO 3) of REGDATA;
	signal reg:reg_array;
	SIGNAL REGD:REGDATA;
BEGIN
	mappSet: PROCESS (clk, we, aa, data)
	BEGIN
		IF clk='1' or we='1' THEN
			REGD <= (OTHERS => '1');
		ELSIF clk='0' AND we='0' THEN
			for i in 0 to pagebits loop
				if REGD(i) > data(i) then
					REGD(i) <= data(i);
				end if;
			end loop;
			CASE aa IS
				WHEN "00" => reg(0) <= REGD;
				WHEN "01" => reg(1) <= REGD;
				WHEN "10" => reg(2) <= REGD;
				WHEN OTHERS => reg(3) <= REGD;
			END CASE;
		END IF;
	END PROCESS mappSet;
...

The idea is, those false readings are usually #FF (because of pullup resistors). So, when clk (=/RW) or we is high, I'll set register REGD to all '1'. When clk and we are both low, I'll change any bits that are '0' in (input) data, but '1' in REGD. Eventually the correct value should end up in REGD.

I wasn't very surprised when this didn't work Tongue

But since the MSX mapper problem is solved, maybe should continue this for example in FPGA and CPLD topic.

Por zPasi

Champion (499)

Imagen del zPasi

17-03-2016, 21:58

I've got those 74HCT14s but I think I won't use them in this project. Because the 74HTC245 seems good enough, and by using that I just need one chip, for cleaning both /RW and /WR, and for the /RW delay line. Looks like it's a little slower than HCT14, which is better for this. Smile And, it has a couple of ports more.

Página 20/20
13 | 14 | 15 | 16 | 17 | 18 | 19 |