search

sorgelig / ZX_Spectrum-128K_MIST

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

Enhance upd765 #14

Closed gyurco closed 7 years ago

gyurco commented 7 years ago

Tested with tens of disk images and only 2 games are not working: Dragon Ninja re-release (but the original works), and Predator 2 resets after starting the game, but maybe that's not FDC related.

sorgelig commented 7 years ago

+3 mode getting better and better. I'm glad ZX core is developing not only by me.

In the meantime i've added TZX tape format support. But only in MiSTer, since it's done on ARM side.

sorgelig commented 7 years ago

By the way, some ports are not implemented in +3. Like attribute port. May be some other ports need to be checked in +3 mode, i think.

gyurco commented 7 years ago

TZX parsing in very good to have, too bad it cannot really be implemented in the FPGA.

You mean no attribute bytes are returned by the +3 in port 0xff? That was a famous incompatibility of the +3, and some "solved" it by soldering a resistor between the CPU and the gate array data bus. I only aware of the 1ffd (implemented, except the disk motor and the printer port strobe bit are not doing anything), the 2ffd (FDC main status register - just read) and 3ffd (FDC data register - read/write).

Next thing I want to do is to re-gain stability on MiST. I have an sdc, and some minor changes, and seems to work, but with 112MHz, it will never pass TimeQuest (seems to work however), but at 56MHz it is beautifully closed. I also wonder, what is the real speed of the CPU at 56MHz with the RAM wait states.

Btw, I couldn't work on it, if you did not start to develop it first!

sorgelig commented 7 years ago

You can try SignalTap to watch the data access. If i remember correct, i've achieved around 90% of 56MHz.

sorgelig commented 7 years ago

TZX can be implemented in FPGA with soft CPU, but it will require some BRAM. Actually TZX2WAV converter is not that big and doesn't require 3rd party libraries, so it's pretty self-contained. Not sure if enough BRAM is left on MiST.

gyurco commented 7 years ago

Ahh, another tool to learn :) I think I'll just measure with some BASIC or Z80 assembly code. There are about 100kbits of free RAM, it is not enough I guess.

gyurco commented 7 years ago

Here's a benchmark program I wrote: https://github.com/gyurco/ZX_Spectrum-128K_MIST/blob/cpubench/bench/benchmark.tap Can you run it on MiSTer? I wonder what does it show at 56MHz.

sorgelig commented 7 years ago

I will try your app tomorrow. Originally i've dropped 512K and 1024K memory modes in ZX core in order to use BRAM only, so 56MHz were running at its full speed. But now i've reverted it back to SDRAM for easier porting your changes from MiST. So, now ZX core on MiSTer has the same performance as on MiST. But i will test your app on BRAM-only version as well.

gyurco commented 7 years ago

On MiST, 28MHz shows about 12MHz, 56MHz = 14MHz. Since the SDRAM access is 8 cycles, it is understandable.

sorgelig commented 7 years ago

I think your test is incorrect. 14MHz has no wait states and it's much slower than 28MHz with wait states. You can disable fast load mode and load some long game in normal mode and then switch speed on the fly - you will see that 28MHz is much faster than 14MHz. An 56MHz is even more faster. If your test shows 28MHz = 12MHz then your test does it wrong.

Actually Z80 doesn't access the memory on every clock. So, 56MHz doesn't mean it needs data at every tick of 56MHz. If i remember correct, the fastest RAM access rate for Z80 is every 4th clock cycle (or even 8th - i forgot - need to read the docs). So, even on 28MHz on Z80 it's almost enough time to provide the RAM data without wait - just sometimes can't - so wait states added, but as i've said it's around 98% of 28MHz.

gyurco commented 7 years ago

14 MHz is even slower :) Maybe it misses interrupts at 56MHz, I can try to increase the measurement time. Just strange that it shows exactly 14MHz.

gyurco commented 7 years ago

Or probably because the fastest instruction is 4 cycles (e.g. NOP), so delaying with lots of NOPs introduces a 8 cycle delay in every 4 cycles. Slower instructions involves less total delay.

sorgelig commented 7 years ago

Up to 14MHz there are no wait states, so your test should show 4 times more speed on 14MHz than standard 3.5MHz if test is correct.

gyurco commented 7 years ago

I don't really understand why it is only good 'till 7MHz, maybe I'll invest some more time into it. Here's the source, if you want to see: https://github.com/gyurco/ZX_Spectrum-128K_MIST/blob/cpubench/bench/bench.asm

I have a patch which makes the core stable on MiST (at least I didn't notice any problems for 2 days), I send a pull request.