Games behaving differently on the Next

[Ast A. Moore]

Cool Novelties are fine. I have bought various cables from them. If you get an issue (I’ve not had one myself), they will send a replacement.

I second that. I bought a couple of hard-to-find sockets (like 13-pin DINs) and few other little things. No issues.

[Pegaz]

Too bad I don't live in Jordan, Iraq, Lebanon or Yemen, so I'll have to order elsewhere.

It's been a tough day, and I don't understand. Could you explain? Sorry.

He doesn't ship to Canada, Norway, Switzerland, Japan and half the EU, but he sends to the countries I mentioned.
I hope it's some mistake...

btw, has anyone tried the Shock Mega demo or Mescaline demo?
Do they work well with a VGA cable?

I'm also struggling with this Arkanoid 128k version:
http://retrospec.sgn.net/users/tomcat/y ... +1_128.tap

[1024MAK]

so that everything is matching (It's that OCD again!).... Are you sure you don't want your username changed to start with a letter? I'm on a mission!

Me > runs for cover....!

With your OCD, you definitely don’t want to come anywhere near my electronic workshop graveyard

The resistors are arranged in individual component drawers though.

Mark

PS my user name is common across all the forums that I am a member of

[PeterJ]

Do you have those nice racks of little clear pull out boxes for your components?

[1024MAK]

Mark

[PeterJ]

If I was aware of the emoji for drooling I was be using it Mark.

[Patrik Rak]

Nobody has denied there is a difference in the results given for one particular synthetic CPU test between the Next and any particular Z80 CPU variant you care to name. This is quite different from being an actual problem, however, unless real-world software shows up that is incompatible as a result. If this was to be the case, then these differences would quickly move up the priority list from a mere curiosity to an actual issue, and would be acted on.

Well, how can you be so sure there are no differences in real software being run on Next and on real Spectrum? How can you be so sure that no software which will behave differently will be written using Next in the future? That people won't be scratching their heads why something which works on this machine doesn't work on another? It took people ages before they figured out why the rhino in SabreWulf runs backwards - I think it's quite likely there might be other cases where it goes unnoticed first, but it is different regardless.

How do you want to emulate Next if no one knows how exactly it implements the Z80? Do you think emulator authors are happy about having to emulate another Z80 behavior?

I am not particularly excited about the fact that the software I have written with good intentions of perfecting Z80 emulation is used as a bash hammer against anyone. OTOH, as a Next backer myself, I am kinda disappointed this wasn't taken care of. If they can't get the Z80 emulation right, how am I supposed to trust them with the rest? It's been known since 2012, and if Uno can get it right, I see no reason why Next couldn't.

Let's be honest - so it wasn't done. OK. There are many other things to do and they may be more important. Maybe the authors weren't even aware of those tests. I think it's fine to admit that. But saying it's not important because of X is just an excuse. If you have the chance of making it work like a real Zilog processor did, not doing so is nothing but a missed opportunity, if not just plain stupid. It doesn't help anything, it just brings more incompatibility in the long run. Future generations definitely won't be glad about that... If people invested time into fixing it rather than musing about why fixing it is not important, it might have been already fixed.

Just my 2p.

Patrik

[PeterJ]

[mention]antoniovillena[/mention] is still making the ZX-Uno, and the one I purchased on the original crowdfunding campaign got damaged beyond repair (It's a long story), so I just ordered one from him. It does have very good compatibility. It's also nice to know that his version has USB keyboard ports rather than the PS/2 ones of the original.

[andydansby]

@antoniovillena is still making the ZX-Uno, and the one I purchased on the original crowdfunding campaign got damaged beyond repair (It's a long story), so I just ordered one from him. It does have very good compatibility. It's also nice to know that his version has USB keyboard ports rather than the PS/2 ones of the original.

Even though it's an USB connector on it, I'm fairly certain the keyboard has to support the PS/2 protocols in order to work.

[cha05e90]

It's been a tough day, and I don't understand. Could you explain? Sorry.

He doesn't ship to Canada, Norway, Switzerland, Japan and half the EU, but he sends to the countries I mentioned.
I hope it's some mistake...

No, no, Lebanon is excluded, too! I just double-checked!

[Pegaz]

He doesn't ship to Canada, Norway, Switzerland, Japan and half the EU, but he sends to the countries I mentioned.
I hope it's some mistake...

No, no, Lebanon is excluded, too! I just double-checked!

Well, that's a relief.

btw, another tricky tap file to test, I fail to get digitized music at startup.
http://s000.tinyupload.com/index.php?fi ... 2652916518
We talked about this music last year, I was so impressed and didn't even notice that there was a Czech adventure game, also with a really nice background music.
Just press a button twice to enter the game.
If I'm not mistaken the game is called TOTO and I didn't notice it in the SC database.

[Seven.FFF]

I get digitized AY music (Moonlight Shadow) in all tap loading modes apart from 48K (pressing 4). This was a deliberate choice to disable AY in 48K mode, based on feedback from some early incompatibility reports. Some games do machine detection through the AY ports instead of testing the timing or ROM, so disabling in 48K mode allows those to correctly detect a 48K model. Also some 48K-only games accidentally write to the AY ports.

You can override this and enable AY in 48K mode too, by pressing A for the Advanced Hardware Options menu, then A for AY Sound in 48K Mode, Space to return to the loading menu, and 4 to load the program.

The music later in the startup sequence seems to be beeper, and is enabled in all modes.

[PeterJ]

btw, another tricky tap file to test, I fail to get digitized music at startup.
http://s000.tinyupload.com/index.php?fi ... 2652916518
We talked about this music last year, I was so impressed and didn't even notice that there was a Czech adventure game, also with a really nice background music.
Just press a button twice to enter the game.
If I'm not mistaken the game is called TOTO and I didn't notice it in the SC database.

Is this it [mention]Pegaz[/mention]?

https://spectrumcomputing.co.uk/index.p ... 6&id=35410

[Pegaz]

Yes [mention]PeterJ[/mention], this is the game.
Thanks.

[Lethargeek]

oh, forgot to mention it the last time

HDMI is not one standard, with one set of timings, but a whole bunch of different video standards. Not all TVs will accept all the different video standards. If the majority of HDMI TVs did accept HDMI signals with a 50Hz refresh and with a suitable resolution, there would not be a problem.

But alas, this is not the case. Hence the Next generates HDMI video to a standard that most HDMI TVs will accept.

umm, does it mean that even with those Spectrum-incompatible timings HDMI still won't work for some of the TVs?

Because the video data is not double buffered, the hardware has to stream the video data at the rate that is correct for the HDMI standard in use. This is a different refresh rate/field rate compared to the 50Hz used by PAL-I.

But this means the timing has to be fudged, as a different refresh rate/field rate will give different time periods between the interrupt seen by the CPU. If a higher refresh rate/field is used, then CPU will execute less instructions between each interrupt. Which messes up any software that has really tight timing in respect of the interrupt. There are also other timing problems.

Sorry, it’s all rather technical.

Sorry, but this is not technical enough for me and doesn't make things any more clear. Could you please give us actual HDMI-Next timings numbers (even better if beside the range allowed by the standard) so it will be possible to compare it against the numbers in the ULA book.

[Pegaz]

Can anyone clarify this post, written by Henrique, almost two years ago on the fb group.
If I understand it well, the Next team previously had a perfect HDMI timing solution, but they don't use it for compatibility reasons with some TVs.
Now, the last paragraph is quite unclear to me, does this mean that the solution exists, but only for HDMI monitors or what ?


https://www.facebook.com/groups/specnex ... 7684899222

[Patrik Rak]

The Next uses a programmable logic array chip known as an FPGA. This is like a modern version of a ULA on steroids. But it has limitations. It does not have enough memory to store and double buffer the video data unless you reduce the number of features available.

Out of curiosity, sure it can't double buffer everything, but what prevents buffering single scan line worth of data and then output it as needed by the HMDI standard? Can't you really find space for 2x256 bits in the FPGA? IMO this would allow decoupling the timings completely and allow proper contention timings for the CPU while feeding the HDMI correctly. Unless the HDMI consumes less input than the Spectrum generates, I don't see any reason why you couldn't use required padding on both horizontal and vertical levels as needed, while the emulated CPU runs at the exact same T cycles like the original machine did.

I am indeed just wondering...

Patrik

[PeterJ]

Giving credit to Mark here, it must be hard to explain stuff to people who want reasonable detail, but don't need to know the exact ins and out (like me), and others who need every detail. Thanks Mark and others for their efforts to cover all bases and a wide range of audiences.

[1024MAK]

Can anyone clarify this post, written by Henrique, almost two years ago on the fb group.
If I understand it well, the Next team previously had a perfect HDMI timing solution, but they don't use it for compatibility reasons with some TVs.
Now, the last paragraph is quite unclear to me, does this mean that the solution exists, but only for HDMI monitors or what ?


https://www.facebook.com/groups/specnex ... 7684899222

If you happen to have a TV or monitor with a HDMI input that supports the required resolution with a refresh/field rate of 50Hz, yes it’s possible and practical to have a core in your Next that works without the timing problems.

You will however have to ask the team if they intend to release such a version (myself, apart from being backer and user, I have nothing to do with the Next).

Edit, see a later post of mine. The manual says it is possible to change to a 50Hz HDMI mode.

Mark

[1024MAK]

The Next uses a programmable logic array chip known as an FPGA. This is like a modern version of a ULA on steroids. But it has limitations. It does not have enough memory to store and double buffer the video data unless you reduce the number of features available.

Out of curiosity, sure it can't double buffer everything, but what prevents buffering single scan line worth of data and then output it as needed by the HMDI standard? Can't you really find space for 2x256 bits in the FPGA? IMO this would allow decoupling the timings completely and allow proper contention timings for the CPU while feeding the HDMI correctly. Unless the HDMI consumes less input than the Spectrum generates, I don't see any reason why you couldn't use required padding on both horizontal and vertical levels as needed, while the emulated CPU runs at the exact same T cycles like the original machine did.

I am indeed just wondering...

Patrik

Conventional (CRT) display systems “draw” one line on the screen, then move down and draw another line. This repeats until the bottom of the screen is reached. Then it starts “drawing” at the top again. The time between the system starting at the top, and then starting at the top again is the field rate (for interlaced video). The problem is that on a 50Hz PAL-I system this is 0.02 seconds. With a 60Hz field rate, the time period is 0.0166 seconds.

So let’s look at what happens when comparing a 60Hz and a 50Hz system. At the start, everything is okay. But very soon the different systems get out of step, as the 60Hz takes less time to get to the bottom of the screen compared to a 50Hz system. Effectively the 60Hz system needs the data quicker than the 50Hz system can produce it. So buffering a single scan line is not enough. Hence why you see the term ‘frame buffer’ used. A frame being two fields if interlaced video (to a broadcast standard) is being used. As one field is only every other line, so you need both fields. With the ZX Spectrum, it cheats, and instead only ever displays one field, then it simply displays the same field again. So that helps a little. But you still need a lot of fast RAM...

And before you ask, yes there are other ways to cheat. But as soon as you have animation or moving pictures, you get flicker, and other picture artefacts.

But you say, but HDMI is digital. True, but a lot of the data streams are still based on the old analogue timing systems. Because for the most part, it is American and Japanese companies that are behind it, there is less support for the 50Hz European video standards. That’s just one reason why I am not impressed with it.

Mark

[Lethargeek]

this is getting more and more weird

why even bring 60Hz here when HDMI supports 50Hz and the problem is in 50Hz mode

[1024MAK]

this is getting more and more weird

why even bring 60Hz here when HDMI supports 50Hz and the problem is in 50Hz mode

Because not all TVs and monitors support a suitable 50Hz mode.

Mark

[Lethargeek]

Because not all TVs and monitors support a suitable 50Hz mode.

and what 60Hz has to do with it? nobody expected multicolor to work in 60Hz

[1024MAK]

Another way of trying to demonstrate the difference between a 50Hz and a 60Hz system, is to compare playing a record (I hope people remember vinyl) at the wrong speed.

If you play a 45 RPM single at 33 RPM, it sounds all wrong. The record deck is not getting the audio information fast enough to generate the correct audio frequencies...

Mark

[Lethargeek]

Another way of trying to demonstrate the difference between a 50Hz and a 60Hz system,

another way to evade explaining the differences between two 50Hz systems