Handle reset with/without image unloading

[gyurco]

Tested the core, found out that the reset function is not working like in the docs. Hopefully fixed. Loaded several games in several modes, the Shock Megademo, seem to be OK. However it would be really good to fix the timing (timing constraints?), because it is impossible to add anything else, any change makes the core unstable. Btw, do you know, why the SPI clock is defined at 100Mhz in the .sdc file?

[sorgelig]

SPI definition comes from one of MiST core developed by Till. So, i didn't touch this. I'm not sure what exact timing has problem. SDC is not strong part of my knowledge.

[sorgelig]

There is one more thing you probably didn't notice - ULA timings. As far as i remember +2A/+3 have different memory contention timings than 128K.

[gyurco]

Yes, I know the contentions patterns are different, but I didn't look at it, because I didn't really encounter problems not implementing it (don't think too many demos are for +3). And there's even a bigger issue for me: I didn't really understand the code which handles the contentions. AFAIK BANK0,1,2,3 are completly un-contented, and BANK4,5,6,7 are contented (in hardware there are 2x2 64x4kbit RAM chips, 2 are contented, 2 are not).

About the SDC: seems it is not the most fun part of FPGA programming, but seems unavoidable. The problem with the wrong setup results sometimes tape loading errors for example (even for turbo loading), the middle row of the keyboard doesn't work, strange instabilites . The SPI and clk_sys are so greatly differs, and they're not even the multiple of each other, so data arrives at an SPI register and transferring to a register latched by clk_sys can fail so many ways. Just wondering how the Amiga and the ST can work (I'm not sure, maybe they're using lower clock frequencies?)

Btw, I think the correct definition is:

create_clock -name {SPI_SCK} -period 41.666 -waveform { 20.8 41.666 } [get_ports {SPI_SCK}]

And something is needed to define the relationship between the two clock domains, but didn't found it yet. Something like this:

set_max_delay -from [get_clocks {SPI_SCK}] -to [get_clocks {pll|altpll_component|auto_generated|pll1|clk[0]}] 2.5

[sorgelig]

You can experiment with SDC. If you can make compilation more stable then we will patch the SDC

[sorgelig]

It's not easy to explain how contention works. The main reason of contention is because of display and CPU need access to the same chips. There is some ULA timings exploration in internet. I don't remember links right now. I will try to find it later if you won't find it. I think, basically contention mechanism is the same for all ULA versions. Only different part is which part of memory has contention and which is not. So you just need to find what pages of +3 are slow and what are fast.

[sorgelig]

By the way, isn't PC/AT uses the same FDC chip as in +3? If yes, then here it is: https://github.com/MiSTer-devel/ao486_MiSTer/tree/master/rtl/soc/floppy It uses Avalon-MM interface, but i think the main FDC logic should be the same. It has full r/w support.

[gyurco]

Probably yes, it should be an intel 8272 descendant chip (AT supported HD disks, I think). Btw, not the chip itself is the hard part, but the (E)DSK format parser. I found an altera document, google it with 'altera understanding metastability in fpgas'. The bottom line is, using registers between different clocks can(must) be solved with synchronization registers. I've tried it in a couple of regs coming from mist_io, and works great. Even the size of the core was went down from 19% to 18%, and the used delay from 6 to only 1%. And great stability, better values in TimeQuest (still not fully closed, but much better).

[gyurco]

Found the contention info here: http://www.worldofspectrum.org/faq/reference/128kreference.htm

[sorgelig]

I've ported your +3 code to MiSTer version of ZX core. Tried Robocop 2 game on DSK http://www.worldofspectrum.org/infoseekid.cgi?id=0004181 I've choose +3 model and mounted the DSK. What should i do next? I've opened +3 Basic and entered there" cat "a:" Got error "Drive A: track 0, sector 1, unknown error.... " Am i doing something wrong?

[sorgelig]

after further exploration, i found that +3 games on www.worldofspectrum.org are usually distributed in EDSK format rather plain DSK, while your upd765 code has no EDSK format parser (as i did in WD1793).

[gyurco]

It has EDSK parser, just checks the first letter of the signature (E for EDSK and M for DSK). Not every game has a +3DOS compatible filesystem, but they can be booted by just choosing Loader from the +3 menu. However not all Speedlock protected EDSKs will work (need some logic in the read code handling weak sectors).

[gyurco]

And sorry for the ugliness in the RAM handlers, but as the metastability problems seems to be solved, I can improve the code now. Already got your generic dpram handler from the WD1793 used in upd765.

[sorgelig]

EDSK has very flexible structure where even each track can have different number of sectors with different size of each sector. Checking the first byte of EDSK is not enough to handle the EDSK. You can see how complex my EDSK scanner in wd1793 is.

[gyurco]

Don't worry, the variable track lengths are handled (even missing - unformatted - tracks are). Try for example Tomahawk.dsk, its copy protection relies on unformatted tracks. Robocob 2 still doesn't boot? It reboots after starting the game, because of Speedlock, but it loads.

[sorgelig]

Ok, now i see i just need to start Loader to load the +3 game from disk. It's easier than in BetaDisk mode. Both Robocop 2 and Tomohawk (although i don't know the answer for security code) are loaded. But how to display the catalog from disk?

[sorgelig]

Btw, FPGA in MiSTer is much larger and thus has no metastability issue.

[gyurco]

CAT would do it, if it is a real +3DOS disk. Games usually bypasses +3DOS, and reads the disks directly via IN/OUT commands, and don't have a catalog, or just have a fake one. That is one of the reason why they cannot work from external "B:" disk drives.

I think the metastability problems is not due to the FPGA size (18% used for the zxspectrum core in MIST), but that the SPI clock and the clock_sys are greatly different, and don't even has the same period (24MHz vs 112MHz). So the signals passing between them should be treated as asynchronous signals. I saw you eliminated async clocks from your designs in a lot of places, but still has between SPI and the system clock. Since the SPI clock cannot be changed, there must be sync registers between them instead of directly wiring from the clk_sys domains to the SPI_CLK domain.

I read on your MiSTer page: High speed ARM<->FPGA interconnect due to both are in the same chip. So probably the SPI clock is more close to the system clock there?

[sorgelig]

All MiST cores use same SPI and even the same SPI handling code. I think the problem is not in SPI clock. To go between different clock domains you can use synchronizer which is simply 2 sequential triggers:

always @(posedge clk_sys) begin
    old_clk1 <= spi_clk;
    old_clk2 <= old_clk1;
    if(~old_clk2 & old_clk1) -> rising SPI clock detection
    if(old_clk2 & ~old_clk1) -> falling SPI clock detection
end

So, it's not an issue.

MiSTer uses parallel 8/16bit data transfer between ARM and FPGA. But it also uses synchronizer similar to above. In MiSTer data rate can be controlled from both sides, so it's easier to catch the data at required pace.

Ok. It looks like +3 games don't use file system, but start from loader. Never had Spectrum +3 and didn't know it different so much.

By the way, turbo mode doesn't work in +3 (48K mode). It seems required other addresses to hook. Normal/Fast tape loading works.

[gyurco]

Now I just added a simple fifo for the signals coming from mist_io, e.g.:

img_mounted_sync <= img_mounted_spi; img_mounted <= img_mounted_sync;

As suggested by the Altera research paper (ok, it suggests at least a 3 step synchronizer).

Maybe it can be adapted to your synchronzier?, e.g.

old_clk1 <= spi_clk; old_clk2 <= old_clk1; if(~old_clk2 & old_clk1) begin img_mounted <= img_mounted_spi; end

Btw, most games ported to Beta also doesn't use the filesystem, but uses direct sector level IO. The files are just there so you can load the loader itself. If a +3 image has a filesystem, you can usually load it with LOAD"DISK"

Just tried 48k turbo loading mode with Arnhem and Academy, worked. Turbo mode with 3.5 MHz (fast tape load - off) works?

[sorgelig]

I've refreshed my memory about MiST's user_io. All signals are made in SPI_CLK. That's not good yeah.. Probably it's better to rewrite user_io/mist_io to use core's system clock, so all signals to/from user_io will be bound to core's clock.

Didn't you mess fast load and turbo load? For me only fast load works.

[gyurco]

Turbo when the memory injection is in place, right? It works for me. Are you trying on MiSTer? Did you also ported the rom_en signal change for the smart_tape?

[gyurco]

Well, but the SPI data arrives physically with SPI clock rate, right? How to receive this data with clk_sys? It is not even at a multiple rate.

[sorgelig]

About turbo load: do you use the source from this repository? My MiSTer code follows this code.

for SPI: you need to use clksys to sample the SPI* signals through synchronizers and detect rise/fall of SPI_CLK. So, basically use SPI_CLK as one of generic signal, not clock.

[gyurco]

Yepp, just already added the synchronization code mentioned above (maybe I'll try to change mist_io instead as you suggested). The 48k ROM in +3 is nearly the same as in 128k, the loader code is sure to be at the same location. I have a +2A machine with a DivIDE, and its tape traps are working.

[sorgelig]

I found bug in my recent MiSTer code change, so turbo loading has been fixed.

by the way, user_io code in MiSTer is clocked by clk_sys. May be that's why it has better stability in ZX core.

[gyurco]

Ah, good! Don't you like to change MIST, too? I'm not really sure how to do it. My current solution works, but using the same clock everywhere would be much better.

[sorgelig]

Actually i've moved to MiSTer and don't plan active development on MiST. My MiST boards are shelved. So many things are planed to do on MiSTer, and i have no time to develop on MiST as well. I will see if i will find the time.

[gyurco]

A bit sad to hear you abandoned the good old MiST. And other developers are, too. There are a lot of unfinished/unstable cores, and they seems to be never fixed. Btw, I think the SamCoupe has the same problem, the latest release is unstable for me, and I read on the Atari forums that others also has stability problems.

[sorgelig]

Although, i like MiST in general, i hate its VGA output. You can also migrate to MiSTer. It has much more resources. Also, ARM has a lot of space for additional code to implement something which require CPU processing.

[sorgelig]

Check the Robocop 2 +3 version. It resets the spectrum when you choose control method (i choose keyboard). Probably this game expects some +3 specific things.

[gyurco]

About the VGA output, it works for me, HDMI of course is nicer, but then I can buy a scaler (which scales frequencies, too). And I don't really had the tools, knowledge and willingness to build the expansion cards.

I know about Robocop 2, it is because of the protection. This version of Speedlock requires special patterns on weak sectors, e.g. there should be x bytes which are not varying between reads, then y variable bytes, then x static again... It's hard to debug on the MiST. The Fuse emulator code has the workaround for such protections, it must be ported. The +3 DSK files doesn't contain the various versions of the weak sectors (which is permitted by the EDSK format). The current code only messes up some bytes in sectors with CRC errors, it is enough for some versions of Speedlock, but this Speedlock is smarter than that.

[sorgelig]

About expansion boards you may find some sales here: http://www.atari-forum.com/viewtopic.php?f=33&t=32121

Different cores provide different non-standard resolutions. For example Minimig has high-res modes like 1280x720i which not supported by any scaler. You need to find a special Amiga monitor to see such resolution. MiSTer shows it without problem on HDMI. Actually MiSTer convert any resolution and refresh rate to standard HDMI. There is no such external scaler exists.

It seems 'm lucky to choose the game for tests :) Anyway, i hope you will find a solution for such protections.

[gyurco]

You can be sure I'll consider MiSTer when MiST will be totally dead :)

After the write support, the protections will my next target. Try Rick Dangerous for a nice looking game :)