sorgelig / ZX_Spectrum-128K_MIST

ZX Spectrum 128K for MIST Board
GNU General Public License v2.0
31 stars 18 forks source link

Write support in u765 #13

Closed gyurco closed 7 years ago

gyurco commented 7 years ago

Got some motivation, and spent half of the night finishing this...

But it would really require the fix for the spi_clk->clk_sys metastabilty issue. I can send my version of that, too.

sorgelig commented 7 years ago

Ok. I've modified mist_io. Now data gotten from SPI is in clk_sys domain. I don't know if it was really source of metastability or not.

I hope it will give you more motivations to add support for protected +3 games :)

gyurco commented 7 years ago

Thank you thank you! Yes, it solved the instabilities. Nitpick1: can you please add ioctl_index, too? Just converting this last register, the interconnect usage drops from 19% to 17%, and TimeQuest's figures are much better, no unnecessary delays are inserted. Nitpick2: can you please port it to your other cores, especially SamCoupe? :)

Now I must crack SpeedLock...

sorgelig commented 7 years ago

I think you can add ioctlindex the same way as other ioctl* signals. For example like ioct_addr if you really need it. Since you actively use TimeQuest (i don't use) - you will find the right way to handle ioctl_index.

gyurco commented 7 years ago

Ok, I'll add it to my next patches - hopefully with SpeedLock :) !

gyurco commented 7 years ago

Just had an idea: what about using dual-clock for the dual-port RAMs in upd765 and wd1893? The FGPA supports dual-clock dual-port RAM. Then the asynchronous problems for the sd_xxx registers are solved (well, the address generation still crosses the two clocks, but it can be handled, I think). I'll do a test later, but you can say if it is a really silly idea :)

sorgelig commented 7 years ago

1) SPI_CLK can have different frequencies depend on several factors. 2) SPI_CLK is not always generating, but only when byte sent/received. Doesn't new mist_io work?

gyurco commented 7 years ago

Well...not always. Added nearly all code for copy protections, and instabilities started again. But I suspect maybe the T80 core also cannot cope with the 112MHz, most of the the errors are not seems to be related to the SD card access/downloading, e.g. loaded a game, works well, pressed F8, and everything blew up. In TimeQuest, there are also timing errors with the T80 on 112MHz, but all is well at 56MHz. So frustrating...

sorgelig commented 7 years ago

That's what i was talking about. When core occupies large part of FPGA (ZX occupies 55%) some instabilities may arise. Try to switch to higher fitter effort, or you can play with seed number.

gyurco commented 7 years ago

Yepp, seems sometimes it cannot find a short enough path between too registers where lots of combinational logic between them. I'll try a "standard fit". If it doesn't work...the I don't know. Maybe reducing the clock frequency...I won't miss 56MHz turbo mode, but probably you will :) And also last time we talked about it, there was a problem with the HQ2x with Timex modes at reduced frequencies.

sorgelig commented 7 years ago

There is always harder way: SDC. But you need to be familiar with every bit of every module to describe signal relations in SDC.

gyurco commented 7 years ago

Maybe I'll try something for the failing paths in T80, but it's not that fun like writing Verilog.

sorgelig commented 7 years ago

Can you commit your code for protections, so i can try it on MiSTer?

gyurco commented 7 years ago

Yes, when I get home, I will.