ZX Spectrum doesn't work or incompatible.

[sorgelig]

Released core binaries for ZX Spectrum are not working with neither 20151118 nor 20150910 firmware. I have garbled screen on start. Mist menu rolling vertically very fast and a even cannot catch the view to see what is displayed there.
Only release spectrum_140812_r306.rbf is partly working. I mean, i can see some unsynced video. It seems ignores scandoubler_disable=1 from ini and my scaler doesn't work with RGBHV video (cannot sync video).
I didn't test compatibility with older firmwares because need Amiga AGA core.
Can you update Spectrum core for latest firmware?

[harbaum]

I just verified that spectrum_150319_r894.rbf still works with the latest firmware. It does.

Please first try on a regular VGA screen without any mist.ini. Once that's working you can try to disable the scan doubler and use a SCART cable.

The ability to disable the scan doubler was introduced with version spectrum_150312_r822.rbf

[sorgelig]

I've tried without mist.ini on my projector (which is the only my device understanding such sync). And result is the same.
If i put DivMMC ROM to SD card, then i see boot screen of DivMMC and then when it should clear the screen it doesn't finish and leave in hand state with some vertical lines left on screen. Without DivMMC ROM i just see garbled screen from the start.

There is one thing i've noticed. With TV RGBS mode (scandoubler_disable=1) even with DivMMC it's hard to start with DivMMC boot screen displayed. Most times i see garbled screen instead of DivMMC. And even if DivMMC boot screen displayed, it distorted with flickering lines and pixels.
So it looks like SDRAM refresh problem.
Without mist.ini, DivMMC screen is always good looking and only after that i get hang.

Can it be SDRAM memory timing/refresh problem? May be timings used in ZX core is at the edge of specification, so some SDRAM chips can work well, while others are not?
Can you look at this part and may be tweak it?

[sorgelig]

I don't know how to re-open this issue (i don't see any button for this) but it looks like really SDRAM timing problem.
I've checked out sdram.v from older commit (6b27e2f Spectrum core) and recompiled. Now with DivMMC ROM sometimes it can successfully initialize spectrum and i can type BASIC commands. I underline SOMETIMES. So, may be once per 5 times i can boot spectrum. Other times it hangs either before DivMMC boot screen or after. So, it's better than last compiled binary, but far from usable stage on my MIST board.

If it could be any CPU programming language i could experiment and find the problem. But FPGA is like martian language for me. Thus i'm asking for help. I can provide any info you want.

P.S.: My MIST board is standard (not hand-made), ordered from Lotharek this month.

[harbaum]

Will have a look at it ...

[harbaum]

It's definitely possible that something is closer to the fpga limits than it should be and thus causes problems an certain boards. As I said, I'll have a look ...

[sorgelig]

Probably SDRAM refresh period is too long. I doubt it's something about FPGA limits because C64 works well which is close to ZX by screen and memory organization and speed. Also Amiga AGA works well which is much more powerful.
Can you look at SDRAM refresh cycle? I'm trying to study Verilog and VHDL. Older version of ZX used Verilog which i could more understand, but newer version uses VHDL which is harder for me.

Let me know if you have something to test. I can compile by myself. Just push commit will be enough.

[sorgelig]

Sorry for annoying. Just my thought:
ZX had 64kbit RAM chips (if i remember correct) with only 8 RAS lines, but MIST uses 32MByte RAM chip with 13 RAS lines. Thus if ZX FPGA tries to use the same clock for RAM refresh, then it will take much longer time than required for SDRAM refresh (in autorefresh mode) period.

[sorgelig]

After checking out sdram.v from 6b27e2f commit and some additional tweaks i've got SDRAM working. I didn't test very hard, but loaded couple games and they were fine.
Now, after fixing (i hope) SDRAM problem, i've found another problem - hang on reset. Before these two problems were hard to separate and they are looked as one.
ZX core hangs on hard reset (button on board or power on) at 50/50 probability. But reset from OSD never hangs. If it didn't hang on reset, then it works fine.
So, it looks like race condition upon core start.

Also, i can start core only with DivMMC (spectrum.rom) on SD card. Withouth this ROM, core never starts. Is it supposed to run core without spectrum.rom as well?

[harbaum]

Yes, tge core is supposed to work without the divmmc rom.

I am currently taking a closer look at the sdram. It can be quite difficult to port those cores that make extensive use of the high speed sram on the de1/de2 boards. That's why the sdram runs at 112mhz in the spectrum core. I am trying to reduce that to 56mhz which will greatly relax the whole ram timing. But feel free to commit your quick fix so others can also benefit.

[sorgelig]

I see ZX core occupies only small part of our FPGA. So, may be possible to implement RAM inside FPGA as an array of bytes? I just started to study Verilog and VHDL and not familiar with all features.
Is it possible to fit 128kb RAM inside FPGA?

As for SDRAM: it's supposed to run on >100mhz clock. It's not a problem. There is race condition somewhere. Starting the core is the main problem. It's unstable at the power-on. Once it loaded OK, i can issue reset through OSD and ZX-reset button without a problem.

I didn't provide fix i mentioned above because i'm not sure if it really help. Still, core startup is unstable and i cannot start clean Spectrum without DivMMC. It seems additional DivMMC ROM greatly change startup timings and eliminates (sometimes) hang upon power-on.

If i will make real fix then be sure i will publish it. I hope you can find the source of problem because you should have more experience here :)

[harbaum]

Hi,

no, the FPGA only has roughly 80kb of ram and some of this is needed for the
CPU, the scandoubler and things like that. We need to use external ram and it
can be used as the other cores show.

I'll also have a further look at this.

Regards,
Till

On Tuesday, December 01, 2015 11:48:30 AM sorgelig wrote:

I see ZX core occupies only small part of our FPGA. So, may be possible to
implement RAM inside FPGA as an array of bytes? I just started to study
Verilog and VHDL and not familiar with all features. Is it possible to fit
128kb RAM inside FPGA?

As for SDRAM: it's supposed to run on >100mhz clock. It's not a problem.
There is race condition somewhere. Starting the core is the main problem.
It's unstable at the power-on. Once it loaded OK, i can issue reset through
OSD and ZX-reset button without a problem.

I didn't provide fix i mentioned above because i'm not sure if it really
help. Still, core startup is unstable and i cannot start clean Spectrum
without DivMMC. It seems additional DivMMC ROM greatly change startup
timings and eliminates (sometimes) hang upon power-on.

If i will make real fix then be sure i will publish it. I hope you can find
the source of problem because you should have more experience here :)

---

Reply to this email directly or view it on GitHub:
#2 (comment)

Dr. Till Harbaum till@harbaum.org

[sorgelig]

Can you recall which exactly commit used to build spectrum_140812_r306.rbf binary?
This version always start without problem. No single hang, no matter how many times i've pressed reset.
Unfortunately none of published commits give the same result :(
If i would have exactly the same source code then i could find the source of problem.

[sorgelig]

I've located r306 (and r309) commit in Google SVN, but it doesn't produce the same binary. I've tried Quartus 9.1, 10.1, 13.1 - nothing similar to binary spectrum_140812_r306.rbf.
My binaries from r306 are about 304kb-309kb, while your compiled binary is 321kb. Source code of r306/r309 is not complete and cannot be compiled without importing some additional files added later. So, can you tell me secret of r306 binary? :)

[ghost]

It's unlikely to produce the same binary. It's likely timings are specified too tightly. This is why I always use always blocks that run off clocks

Sent from my iPhone

On 1 Dec 2015, at 22:56, sorgelig notifications@github.com wrote:

I've located r306 (and r309) commit in Google SVN, but it doesn't produce the same binary. I've tried Quartus 9.1, 10.1, 13.1 - nothing similar to binary spectrum_140812_r306.rbf.
My binaries from r306 are about 304kb-309kb, while your compiled binary is 321kb. Source code of r306/r309 is not complete and cannot be compiled without importing some additional files added later. So, can you tell me secret of r309 binary? :)

—
Reply to this email directly or view it on GitHub.

[ghost]

Would probably be best to try and identify which components in the model are running tight (Till knows this already of course - but I say this for the benefit of anyone who doesn't). Might be a clock domain issue or something needing latched etc.

Sent from my iPhone

On 1 Dec 2015, at 22:56, sorgelig notifications@github.com wrote:

I've located r306 (and r309) commit in Google SVN, but it doesn't produce the same binary. I've tried Quartus 9.1, 10.1, 13.1 - nothing similar to binary spectrum_140812_r306.rbf.
My binaries from r306 are about 304kb-309kb, while your compiled binary is 321kb. Source code of r306/r309 is not complete and cannot be compiled without importing some additional files added later. So, can you tell me secret of r309 binary? :)

—
Reply to this email directly or view it on GitHub.

[sorgelig]

It's unlikely to produce the same binary. It's likely timings are specified too tightly.

yes and no. Actually there are 2 binaries always working correctly. R306 binary actually has two versions. They are compiled at the same day and pushed with the same name. I just restored the previous version (before Video fix) and it also works. The second version actually should have name R309. And then something happened after these releases and all later versions don't work.
I believe source code of R306 and R309 commits in SVN doesn't reflect exact source code on Till's computer because it cannot be compiled without errors as i've mentioned earlier.

My original idea was to check the source code difference between R309 and the next one to pinpoint the problem.

[harbaum]

I've done major changes to the SDRAM timing. The SDRAM now runs at 56 MHz (as opposed to the 112MHz before). I've also changed the overall timing. The current source tree already gives me quite reliably a running core. There are still a few things to verify. For me this core e.g. also works without the esxdos rom and boots in the typical 128k main menu then.

The new code is in the source repository but no binaries have been released yet. Please give it a try.

[ghost]

Thanks Till,

Sorgelig, With FPGA PAR you can have the same code producing a good build
one time then a bad one next build if the timings are too tight. Sounds
like Till's change will loosen up some of these timings and help matters.

Cheers
Stephen

On Wed, Dec 2, 2015 at 4:02 PM, Till Harbaum notifications@github.com
wrote:

I've done major changes to the SDRAM timing. The SDRAM now runs at 56 MHz
(as opposed to the 112MHz before). I've also changed the overall timing.
The current source tree already gives me quite reliably a running core.
There are still a few things to verify. For me this core e.g. also works
without the esxdos rom and boots in the typical 128k main menu then.

The new code is in the source repository but no binaries have been
released yet. Please give it a try.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

Stephen Leary

[harbaum]

One thing that's very unlike software development is that compiling (synthesizing in this case) a core from the very same sources on the same machine with the same tools will result in different cores. This is due to the fact that the placement of logic cells inside the FPGA may change from build to build. If there's something in the core designed very close to the limits of the FPGA then the minor timing variations caused by these small build-to-build differences may result in one core working and the other one not. Also adding debug stuff like signaltap may cause such a core not to work anymore all of a sudden.

This problem of "build to build instabilities" can be quite nasty.

Edit: Ah, Stephen just explained the very same thing ...

[sorgelig]

Unfortunately it didn't help.
I don't know why you insist to lower RAM clock. It's supposed to work on up to 120MHz. So, the clock is not the issue at all.
Since i'm studying ZX core code i'm more and more sure the problem is not in RAM refresh as it looked originally. The problem is in startup procedure. Once core successfully started, it works well. I even can press ZX-reset button many times or choose reset from OSD - it will successfully reset Spectrum. But if core hangs on startup, then pressing ZX-reset(OSD reset) doesn't help.

[ghost]

The ram will work at 128mhz no problem. But there is another build to build issue that needs resolved first.

Till, I could give this core the verilator treatment to get a working simulator like the BBC core if you think that might help.

Sent from my iPhone

On 2 Dec 2015, at 16:28, sorgelig notifications@github.com wrote:

Unfortunately it didn't help.
I don't know why you insist to lower RAM clock. It's supposed to work on up to 120MHz. So, the clock is not the issue at all.
Since i'm studying ZX core code i'm sure the problem is not in RAM refresh as it looked originally. The problem is in startup procedure. Once it successfully started, it works well. I even can press ZX-reset button or choose reset from OSD - it will successfully reset Spectrum. But if core hangs on startup, then pressing ZX-reset(OSD reset) doesn't help.

—
Reply to this email directly or view it on GitHub.

[harbaum]

In most of your comments in this bug report you suggested that there were sdram timing problems. Now that I have worked on that you ask me why I do that?

Sdram definitely was a mess. Also reducing clocks always is a good idea. While it's sure possible to run the sdram at 133 mhz it's also much more difficult to achieve stable operation at that speed than at 56mhz. Since I lowered the clock I haven't seen any of the typical ram timing related problems anymore.

Next I'll try to see what may cause startup problems. I haven't looked at that at all as I have always loaded the core via the usb blaster and never from sd card the last few days.

[harbaum]

I now played hours with the core, did small adjustments here and there, reduced the fitter effort etc etc ... and every single core booted reliably. I really start to wonder what your problems are.

Are you doing these test with the scandoubler disabled? I didn't test that yet and it make difference as this changes the memory access timing of the video engine.

[sorgelig]

Except video projector in another room, i don't have any display devices accepting 31Khz@50Hz. So, my test platform requires standard TV PAL(or NTSC) signal. So, i always disable scandoubler.

I've just tried with scandoubler on projector your new commits and it works stable! Well, almost. I have to press ZX-reset button after every core start. So, when core start i see empty screen. Then i press ZX-reset button (or use OSD reset) and then Spectrum 128 welcome dialog appears.

So, you are close now! :)
Just don't stop. You need to make TV PAL mode work as well. May be, disable TV output while core start? Because it seem produce problem only on startup.

[sorgelig]

I have an idea how to fix problem in PAL mode:
Since in PAL mode it need to skip every other tick of clock, is it possible not to skip read from memory but skip output? So the rate of memory read by video module will be equal to VGA mode.

[sorgelig]

by the way, i found some inconsistency in code:
check here

    sdram_addr <= io_addr when ioctl_cycle = '1' else
        ("000000" & vid_addr) when vid_rd_n = '0' else ("0000" & cpu_addr);

and then here

        if cpu_cycle = '1' then
            sdram_oe <= not cpu_mreq_n and not cpu_rd_n;  -- any cpu read enables ram
            sdram_we <= sram_write;    -- cpu_wr_n incl.  -- write only for memory used as ram
            sdram_di <= cpu_do;
        elsif ioctl_cycle = '1' then
            sdram_oe <= tape_rd;
            sdram_we <= ioctl_used;
            sdram_di <= ioctl_ram_data;
        else
            -- no cpu sccess. Thus do video access
            sdram_oe <=  not vid_rd_n;
            sdram_we <= '0';    -- video never writes
            sdram_di <= "00000000";
        end if;

the priorities are not match, so it's possible in some cases sdram_addr won't match sdram_oe/sdram_we/sdram_di.

[harbaum]

That wasn't a problem as the timing usually matched (at least in VGA mode). But i have cleaned that part up and it's now much more readable. Also if there's a timing mismatch between video and the rest then the cpu now has priority and will continue to work while the video will suffer from the resulting mismatches. This is/was actually happening in 15khz mode while it shouldn't.

I've taken a look at the memory timing of the 15khz mode and adjusted a few things here and there. It's totally untested since i current don't have a 15khz capable screen on my test setup. I may actually already work, but i need to test it myself.

[sorgelig]

In spectrum_mist.vhd i see many sichronizations to 28mhz. But ZX spectrum has no such high frequency. Base ZX spectrum frequency is 3.5Mhz and code should sync to it. Memory accesses in spectrum_mist.vhd should be synchronized to respective clocks like vid_clk, dio_clk, cpu_clk and so on.
This should greatly relax timings, IMHO.

[sorgelig]

Congratulations! No more problems with memory in PAL mode.
The only problem remains is ZX-reset requirement after core start.
How to reproduce:

1. Put only core.rbf into root of SD card, (i.e. without spectrum.rom) and boot from SD card, not from JTAG.
2. I see blue border with black screen inside and system sticks on this state.
3. Press F11, or ZX-reset, or OSD reset and then ZX Spectrum will finish to boot and present Spectrum 128 welcome dialog.

This happens in both PAL and VGA modes for me.
It doesn't happen if i add spectrum.rom.

[sorgelig]

By the way, is it possible to use DivMMC and boot into Spectrum 128 dialog? I would like to get the best from both parts :)

[harbaum]

Yeah, i am little impressed by myself that i fixed 15khz mode without being able to test it :-)

I'll have a look at that boot problem. The fact that i need to remove the spectrum.rom to trigger that issue was missing.

I don't know anything about the esxdos/divmmc. I thus cannot answer questions regarding its ability to boot into the original spectrum 128 menu. I've never seen a real spectrum let alone a divmmc equipped one.

[harbaum]

Can you do benchmarks? How accurate is the CPU speed?

[sorgelig]

It seams there is problem with performance..
i've played Lyra II demo:
http://www.worldofspectrum.org/infoseekid.cgi?id=0007538
The part with dancing girl is slowing down time after time. You can hear it from music.
It's the same for both PAL and VGA modes.

If you have some specific benchmarks to compare VGA and PAL modes, give me the link.

[sorgelig]

Older versions (112mhz RAM) have the same performance issue.

[ghost]

The shock megademo is the best test

Sent from my iPhone

On 3 Dec 2015, at 17:40, sorgelig notifications@github.com wrote:

Older versions (112mhz RAM) have the same performance issue.

—
Reply to this email directly or view it on GitHub.

[sorgelig]

First part of Shock Megademo is slower than original (and may be balls part, but not so obvious). Border effect in first part is totally messed because it requires very precise timings.
And i didn't find any noticeable difference between VGA and PAL modes. Thus, let's assume there is no performance difference between PAL and VGA.

[harbaum]

The boot problems have been fixed by extending the reset a little bit. Actually i extended the reset to be able to trace the problem. But that was already the fix. Dunno what exactly is/was the problem ... will investigate this a little further one day. Perhaps ...

[harbaum]

Can you give performance numbers? Perhaps the timing of some basic loop? How much too slow is this? I can adjust things by e.g. giving it the CPU some of the free memory bandwidth in the video blanking times.

And no need to test TV vs VGA. The CPU timing is the same in both setups.

[sorgelig]

Unfortunately i don't know exact timings.
Can you add bandwidth to CPU just blindly? I mean, add some bandwidth if there is a room. I will test it.
For precise timings (for proper border effects for eaxmple), i think we need to find some technical book about ZX spectrum. I will try to find. ZX spectrum was very popular in Russia and had many DIY clones, so may be i can find Russian books ;)

[sorgelig]

The boot problems have been fixed by extending the reset a little bit.

nope. It didn't fix the problem for me. Still have to press ZX-reset.
P.S.: 32000000 helped to fix. But i think it's not correct fix.

[sorgelig]

i've improved extended reset time. Made it only for coldboot. So pressing ZX-reset won't take long time.
I didn't push to repository because i don't know if you agree with this:

From aae610f4bdb893a16e7967e5679be4d7e65dd071 Mon Sep 17 00:00:00 2001
From: sorgelig <pour.garbage@gmail.com>
Date: Fri, 4 Dec 2015 06:58:01 +0800
Subject: [PATCH] [SPECTRUM] Extended reset time only for core coldboot

---
 cores/spectrum/spectrum_mist.vhd | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/cores/spectrum/spectrum_mist.vhd b/cores/spectrum/spectrum_mist.vhd
index 6b8a220..7dd3afd 100755
--- a/cores/spectrum/spectrum_mist.vhd
+++ b/cores/spectrum/spectrum_mist.vhd
@@ -1014,10 +1014,13 @@ begin
    -- delay reset so sdram can be initialized etc. especially clearing the
    -- divmmc ram after esxdos upload needs some time (9.3ms)
    process(clock, pll_locked, status, buttons)
-       variable reset_cnt : integer range 0 to 28000000;
+       variable reset_cnt : integer range 0 to 32000000 := 32000000;
    begin
        if pll_locked = '0' or status(0) = '1' or status(1) = '1' or buttons(1) = '1' then
-           reset_cnt := 28000000;
+          -- don't clear core coldboot reset time
+           if reset_cnt < 280000 then 
+               reset_cnt := 280000;
+           end if;
        elsif rising_edge(clock) then
            if reset_cnt /= 0 then
                reset_cnt := reset_cnt - 1;
-- 
1.8.3.msysgit.0

[harbaum]

Yes, the root of the problem is probably something else. But i am little too lazy at the moment to fix this. Most importantly the core now works for you (and hopefully everybody else as well).

Can you please close this issue if the subject of this issue has been fixed?