No, the video timing in the spectrum next is very accurate. We have a minor discrepancy in the +3 contention but it will get ironed out when I get around to looking into it. There is one game not displaying properly but I think the problem is elsewhere - we have very high confidence in the contention, video timing and video generation for all models (48k, 128k, pentagon) except for the minor problem in the +3.
The problems on hdmi are separate and has nothing to do with the accuracy of the spectrum next's hardware. This is due to the mismatch between hdmi requirements and the spectrum's video timing as you're saying. hdmi tvs do not tolerate even minor deviations from the hdmi frame so the current solution in the next hardware is to change the spectrum's video timing slightly to match the hdmi requirements. This breaks the precise relationship between the cpu and video generation that some demos and games rely on. This is the problem that will be addressed when the display hardware is revisited.
The z80 in the next (and the uno, the mister, anything without a physical z80) is a clone. This means it was created to behave the same as the z80 but it's not using the same circuit. It's very much like the difference between an AMD x86 and an Intel x86. Intel defines what the instructions do and AMD makes sure the instructions do the same thing but they are not the same circuit at all.Is the failure in some of the tests which are run to check the implementation of z80 features and other stuff due to this also, or is this due to errors made in the (programming - is it still called that?) of the FPGA?
In principle, the behaviour of a clone can be made identical to a physical z80 but that depends on the implementer knowing about all the observable behaviour that can be seen on a physical z80. The particular clone that everyone is using is derived from the T80 which was originally created about 20 years ago. It has been used all over the place. In that time, bugs have been found and have been corrected by various people differently with some noticing different bugs than others.
With the known bugs removed, the t80 works very well as a clone implementing all the documented and undocumented instructions and generating proper bus cycles for external hardware. However there is some esoteric behaviour that was only recently found (well recent in retro terms
). As is the want in emulation circles, once those were found test programs were created to find out what various instructions did with the new undocumented flags behaviour. It turns out various z80 versions behave a little differently: the nmos z80 is different from the nec z80 is different from the cmos z80, etc. This has to do with discrepancies in some internal implementation detail. Anyway, whereas the z80 versions I listed were a little different, the T80 is a lot different. That's not surprising since the implementer wouldn't have known about this.So some people have gone to the effort to patch up the t80 to be almost the same as, say, the nmos z80. This comes at some expense since these patches are usually bolt-ons to the hardware and doing things that way makes the implementation bigger on an fpga, eg. We could copy those things but we can't do it haphazardly because (1) becoming bigger is an issue for us as the fpga is near capacity and (2) we have made other changes required that fix up the bus cycles for hardware compatibility. None of these other projects are concerned about hardware compatibility as they don't have external interfaces so it's doubtful they've fixed that or even know about all the problems. So we have a temporary situation where the Next doesn't implement some undocumented flags behaviour as well as some other T80 implementations.
And now a word on the importance of those undocumented flags. It's approximately zero as far as I can tell. The undocumented flag behaviour is not particularly useful nor was it known until recent times. Software doesn't and won't depend on it. If it does you could end up in a situation where some software only runs on an nmos z80 or one of the other specific z80s.
What I am more concerned with is the possibility of other functional bugs being found in the T80. With a 20 year history, the chances should be small but guess what? I know there is at least one more because I can see it in the bus cycles and it shows up in hardware compatibility. In those 20 years, I think it's been very rare that the T80 has been used in a hardware setting so I think that's why we are seeing such things.
I will spend the time to go through the whole processor but when depends on priorities. The hardware bug is important; the undocumented flags not so much. Honestly I don't like the T80 implementation very much and I'd rather just create a new z80 clone from scratch but that is a giant time sink.
Yes VGA and RGB are really easy to target because they will tolerate the spectrum video signal unchanged. HDMI is a more difficult problem and that's why it hasn't been done before in the spectrum fpga scene. The mister is an exception but that is a machine with a giant fpga that has the resources to do whatever you want.There seems to be a view here that maybe some FPGA implementations are more accurate than others. Why is this? I notice that some cores only support one video standard such is VGA. Does this make it easier for the developer to get more accurate 'emulation'?
For the spectrum, other discrepancies have to do with the quality of the ula implementation and how the differences in the spectrum models is handled. Remember that the 48K spectrum, 128K spectrum and +3 are very incompatible with each other.
The Next's hardware is very accurate and it does a lot of new things to handle hardware and software compatibility with the original machines. It is quite annoying to read uninformed comments about incompatibility issues; real demonstrable issues are welcome -- we 've spent a lot of time making sure the machine has very high compatibility and that process hasn't stopped.
Standby alert 
)
