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
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.
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
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.
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.
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
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
But since the MSX mapper problem is solved, maybe should continue this for example in FPGA and CPLD topic.
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. And, it has a couple of ports more.