Strange inaccuracy in some emulators
Strange inaccuracy in some emulators
Today I noticed on the Russian forum an interesting claim, that some emulators wont draw the screen correctly in 128k mode.
The demo "Song in Lines 4" is shown as an example.
Fuse and Baremulator were mentioned, I also checked Es.Pectrum and SpecIde (as very precise emulators) and they all inaccurately draw the screen in the same way at the up right corner.
On the other hand, SpecEmu, Spectaculator and ZX Mak 2, display the screen perfectly.
I haven't checked other emulators, there are probably more examples like this.
Does anyone know what is the cause of this issue?
The demo "Song in Lines 4" is shown as an example.
Fuse and Baremulator were mentioned, I also checked Es.Pectrum and SpecIde (as very precise emulators) and they all inaccurately draw the screen in the same way at the up right corner.
On the other hand, SpecEmu, Spectaculator and ZX Mak 2, display the screen perfectly.
I haven't checked other emulators, there are probably more examples like this.
Does anyone know what is the cause of this issue?
Re: Strange inaccuracy in some emulators
It's simple - the cause is inaccurate emulation of Z80 commands (OUT, as far as I remember).
Re: Strange inaccuracy in some emulators
Thanks.
In that case, I will have to redefine my list of the most accurate emulators, again.
Re: Strange inaccuracy in some emulators
That's why I use Spectaculator for everything: to develop, to play, to test... It's the best one, without a doubt.
If something works, don't touch it !!!! at all !!!
Re: Strange inaccuracy in some emulators
Spectaculator is not quite accurate too. The most accurate emulator is SpecEmu at the moment, it seems like it is the only emulator that correctly emulates the HALT command. The timings in it are also very accurate.
Re: Strange inaccuracy in some emulators
You can't rely on any emulator to test code, they're all fallible.
Spectaculator hasn't been updated for ages. You'd think that in 2021 spectrum emulation would be a solved problem, bit we keep finding errors in our understanding of the hardware.
Re: Strange inaccuracy in some emulators
Spectaculator is far from perfect, he has errors in some other tests, but here he did the job right.
btw, I tested this demo last night on zxuno, with spark2k06 and Kyp128 cores and both also give an inaccurate screen display.
However, when I made a snapshot file at this point, changed the timing from 128k to 48k and reload, the picture became perfect.
This workaround is a compromise solution on zxuno, but this is 128k demo and cannot be applied to majority of emulators, without changing the timing on the fly.
As far as I remember, only Unreal Speccy can do that...
btw, I tested this demo last night on zxuno, with spark2k06 and Kyp128 cores and both also give an inaccurate screen display.
However, when I made a snapshot file at this point, changed the timing from 128k to 48k and reload, the picture became perfect.
This workaround is a compromise solution on zxuno, but this is 128k demo and cannot be applied to majority of emulators, without changing the timing on the fly.
As far as I remember, only Unreal Speccy can do that...
Re: Strange inaccuracy in some emulators
There are some more Emulators which support "Hotswap": Thread "Which emulators can change machine type / hardware without reset?" on: https://worldofspectrum.org/forums/disc ... hout-reset
Re: Strange inaccuracy in some emulators
Everything is much weirder with this demo
First screenshot of 4 emulators:
(Spectaculator 7 version, the rest of the emulators are all for yesterday
What can be said about them ...
Spectaculator and SpecEmu show the correct picture. right?
Press the big SPACEBAR
And what we see upon close examination
In the Spectaculator, the scroller does not match for one clock cycle, so a somewhat twitchy scroll is quite visible.
It's the same in Spud, plus the top red square is shaking
The smoothest and most flawless image on the Zero. Winner!!
Well, and the worst image, oddly enough, is in SpecEmy - the border is shifted to the left quite strongly, even in the screenshot it is noticeable. (Woody - hello!)
Well, I'll tell you about Spectramine. The same as in the Spectaculator - a little scrolling shakes.
First screenshot of 4 emulators:
(Spectaculator 7 version, the rest of the emulators are all for yesterday
What can be said about them ...
Spectaculator and SpecEmu show the correct picture. right?
Press the big SPACEBAR
And what we see upon close examination
In the Spectaculator, the scroller does not match for one clock cycle, so a somewhat twitchy scroll is quite visible.
It's the same in Spud, plus the top red square is shaking
The smoothest and most flawless image on the Zero. Winner!!
Well, and the worst image, oddly enough, is in SpecEmy - the border is shifted to the left quite strongly, even in the screenshot it is noticeable. (Woody - hello!)
Well, I'll tell you about Spectramine. The same as in the Spectaculator - a little scrolling shakes.
Re: Strange inaccuracy in some emulators
As far as I remember it's not accurate emulation - scrolling shakes on real machines too.The smoothest and most flawless image on the Zero. Winner!!
It's just because the border in SpecEmu is smaller than in other emulators.Well, and the worst image, oddly enough, is in SpecEmy - the border is shifted to the left quite strongly, even in the screenshot it is noticeable.
Re: Strange inaccuracy in some emulators
But there is a timing bug in SpecEmu - It is noticeable that there is a break in the big letters scrolling on the left transition from border to paper.
Alas.
Alas.
-
- Microbot
- Posts: 117
- Joined: Mon Apr 13, 2020 3:07 pm
Re: Strange inaccuracy in some emulators
BTW, ZXDS gets it right, too, FWIW.
-
- Microbot
- Posts: 100
- Joined: Wed Feb 03, 2021 5:18 am
Re: Strange inaccuracy in some emulators
Hi all,
I think I've found the cause of the problem in SpecIde. (And it's not the Z80 implementation).
This pattern of red-black lines with white text is done by switching the active screen on each scan. Say, screen 5 has the white text on black paper, and screen 7 has the white text on red paper. The problem seems to be that SpecIde (and all the rest of the emulators with this flaw) are switching the memory pages as soon as the pagination regs are altered. If the screen page is changed too soon, you get the effect you see.
There is a test from Patrik Rak that gives the needed information to solve this: ptime.tap. I think I've got a fix for SpecIde already, using this test (thanks, Patrik). The idea is hold the page switch until no accesses are in course. The +2A/+3 are more permissive with this, because the access seems to be held back until no video RAM accesses are in course. For ZX Pentagon, however, it "more or less works". I'd need to check how the page switching logic is implemented.
I'll have to run some tests, and then I'll update the binaries.
(Also, thanks for these threads; they're really helpful for polishing emulators...)
I think I've found the cause of the problem in SpecIde. (And it's not the Z80 implementation).
This pattern of red-black lines with white text is done by switching the active screen on each scan. Say, screen 5 has the white text on black paper, and screen 7 has the white text on red paper. The problem seems to be that SpecIde (and all the rest of the emulators with this flaw) are switching the memory pages as soon as the pagination regs are altered. If the screen page is changed too soon, you get the effect you see.
There is a test from Patrik Rak that gives the needed information to solve this: ptime.tap. I think I've got a fix for SpecIde already, using this test (thanks, Patrik). The idea is hold the page switch until no accesses are in course. The +2A/+3 are more permissive with this, because the access seems to be held back until no video RAM accesses are in course. For ZX Pentagon, however, it "more or less works". I'd need to check how the page switching logic is implemented.
I'll have to run some tests, and then I'll update the binaries.
(Also, thanks for these threads; they're really helpful for polishing emulators...)
Re: Strange inaccuracy in some emulators
[mention]TheMartian[/mention] yeah, it seems that you are right. at least i remember several inaccuracies in ZXEmuT due to page switching. sadly, there's only "test conformance" way of doing it, afaik. i mean, there's no proper timing documentation for various models. T_T
Re: Strange inaccuracy in some emulators
Thanks Marta for this explanation, your emulator has always been one of the most accurate and I am glad you continue to improve it.TheMartian wrote: ↑Tue Dec 07, 2021 2:43 am Hi all,
I think I've found the cause of the problem in SpecIde. (And it's not the Z80 implementation).
This pattern of red-black lines with white text is done by switching the active screen on each scan. Say, screen 5 has the white text on black paper, and screen 7 has the white text on red paper. The problem seems to be that SpecIde (and all the rest of the emulators with this flaw) are switching the memory pages as soon as the pagination regs are altered. If the screen page is changed too soon, you get the effect you see.
There is a test from Patrik Rak that gives the needed information to solve this: ptime.tap. I think I've got a fix for SpecIde already, using this test (thanks, Patrik). The idea is hold the page switch until no accesses are in course. The +2A/+3 are more permissive with this, because the access seems to be held back until no video RAM accesses are in course. For ZX Pentagon, however, it "more or less works". I'd need to check how the page switching logic is implemented.
I'll have to run some tests, and then I'll update the binaries.
(Also, thanks for these threads; they're really helpful for polishing emulators...)
Please let us know when a new update is ready.
-
- Microbot
- Posts: 100
- Joined: Wed Feb 03, 2021 5:18 am
Re: Strange inaccuracy in some emulators
Hi,
First of all: I uploaded new binaries for Windows at the usual place - the links are in the README.md, section "How to get it". I really should be serious about version numbers, actually.
What's new?
- The fix in this thread.
- I've forced the antialiasing option, and now the pixel aspect ratio matches the expected one from the pixel clock. I did this because...
- SpecIde now does some emulation of the Amstrad CPC 464/664/6128 (Heresy! Betrayal! At least is not C64!) . It is still very incomplete, and the keyboard is a major issue, but you can play some games and some demos... All the needed ROMs are in the bundle, I think. As soon as I fix the keyboard, I'll put up an SpecIde thread in the emulation section to track changes.
Regarding the fix:
I'm having a look at Velesoft's HAL/PAL10H8 equations in his "Unrainer" page, and turns out that the only thing this PAL does is convert addresses. The other part of the circuit is IC31, which is a 74LS174. This is a multiple D-Q register which latches on BANK falling edge (because there is an inverter in the way). So I guess the new bank is latched on IORQ# going up, which is consistent with what tests show. (All of this is for 128K/+2).
On +2A/+3, all this bank selection logic is inside Amstrad's 40077 Gate Array, so we have to guess. The guess of keeping the bank address stable during memory accesses seems to work fine, though.
On ZX Pentagon, after a quick glance to the schematic, it looks pretty much the same as 128K. Still, I've got some differences to Patrik's info on ptime, and atime seems one cycle too early. (I do not own a ZX Pentagon, so I've got to guess...)
On the British machines everything looks fine. I've tried the whole set of btime/stime/atime/ptime/minfo, and also SIL4 and 70908 by Scoopex.
Feedback is welcome.
First of all: I uploaded new binaries for Windows at the usual place - the links are in the README.md, section "How to get it". I really should be serious about version numbers, actually.
What's new?
- The fix in this thread.
- I've forced the antialiasing option, and now the pixel aspect ratio matches the expected one from the pixel clock. I did this because...
- SpecIde now does some emulation of the Amstrad CPC 464/664/6128 (Heresy! Betrayal! At least is not C64!) . It is still very incomplete, and the keyboard is a major issue, but you can play some games and some demos... All the needed ROMs are in the bundle, I think. As soon as I fix the keyboard, I'll put up an SpecIde thread in the emulation section to track changes.
Regarding the fix:
I'm having a look at Velesoft's HAL/PAL10H8 equations in his "Unrainer" page, and turns out that the only thing this PAL does is convert addresses. The other part of the circuit is IC31, which is a 74LS174. This is a multiple D-Q register which latches on BANK falling edge (because there is an inverter in the way). So I guess the new bank is latched on IORQ# going up, which is consistent with what tests show. (All of this is for 128K/+2).
On +2A/+3, all this bank selection logic is inside Amstrad's 40077 Gate Array, so we have to guess. The guess of keeping the bank address stable during memory accesses seems to work fine, though.
On ZX Pentagon, after a quick glance to the schematic, it looks pretty much the same as 128K. Still, I've got some differences to Patrik's info on ptime, and atime seems one cycle too early. (I do not own a ZX Pentagon, so I've got to guess...)
On the British machines everything looks fine. I've tried the whole set of btime/stime/atime/ptime/minfo, and also SIL4 and 70908 by Scoopex.
Feedback is welcome.
Re: Strange inaccuracy in some emulators
[mention]TheMartian[/mention]
I just tried the new version and here are some impressions and questions.
First the good news, this tricky demo is now working properly.
Now, the questions.
Emulator syncs the image very well with the 50Hz refresh rate, when I connect it to the TV.
However, even in this new version, I still have a problem with the sound sync on my laptop with standard 60hz screen, the sound simply skips or goes too fast.
The cfg file says, that the sync option is only useful in 50hz mode, but when I turn it off, whole emulation becomes painfully slow, although the cpu occupancy shows only about 35% usage.
I'm using the win7 32bit (MinGW) version of SpecIde from your github page and I'm wondering if there's a way to get synchronized audio somehow on standard pc monitor ?
Didnt try 64bit win10 version, maybe it works better.
Apart from this, emulator works very nicely, I would only have a suggestion, if possible, to get support for some snapshot format (sna, z80), as well as beta disk support for the Pentagon in the future...
I just tried the new version and here are some impressions and questions.
First the good news, this tricky demo is now working properly.
Now, the questions.
Emulator syncs the image very well with the 50Hz refresh rate, when I connect it to the TV.
However, even in this new version, I still have a problem with the sound sync on my laptop with standard 60hz screen, the sound simply skips or goes too fast.
The cfg file says, that the sync option is only useful in 50hz mode, but when I turn it off, whole emulation becomes painfully slow, although the cpu occupancy shows only about 35% usage.
I'm using the win7 32bit (MinGW) version of SpecIde from your github page and I'm wondering if there's a way to get synchronized audio somehow on standard pc monitor ?
Didnt try 64bit win10 version, maybe it works better.
Apart from this, emulator works very nicely, I would only have a suggestion, if possible, to get support for some snapshot format (sna, z80), as well as beta disk support for the Pentagon in the future...
Re: Strange inaccuracy in some emulators
Just tried the win10 32 bit version and the sound issue is gone, sound is perfect, but only in fullscreen mode!
I don't know what is the cause of the problem with the MinGW version, still this one for win10, works equally well on my win7 so, for now problem is solved.
I don't know what is the cause of the problem with the MinGW version, still this one for win10, works equally well on my win7 so, for now problem is solved.
Re: Strange inaccuracy in some emulators
I've updated JSpeccy to v0.94 (first time from 2015) to correct the SIL4 demo.
Additionally, includes support for the ZX Recreated keyboard.
The updated sources are in my GitHub account (JSpeccy). By now, I'm don't publish a compiled JAR.
Additionally, includes support for the ZX Recreated keyboard.
The updated sources are in my GitHub account (JSpeccy). By now, I'm don't publish a compiled JAR.
Re: Strange inaccuracy in some emulators
Personally, I would have preferred to see this fix on Baremulator, but that's how it is.
If I remember correctly, JSpeccy and Baremulator share a lot of code, so that would be a relatively easy job.
Unfortunately you decided that BM was "doomed from the start", but JSpeccy is obiously not.
Don't get me wrong, JSpeccy is a fine emulator (although I don't like Java apps), but just one of many we have.
On the other hand, BM is a unique baremetal emulator on Spectrum and I find it far more interesting.
But, that's just me.
Re: Strange inaccuracy in some emulators
ZXBaremulator is beyond any possible redemption. Throw it by the bath window and forget it.Pegaz wrote: ↑Thu Dec 09, 2021 12:53 pmPersonally, I would have preferred to see this fix on Baremulator, but that's how it is.
If I remember correctly, JSpeccy and Baremulator share a lot of code, so that would be a relatively easy job.
Unfortunately you decided that BM was "doomed from the start", but JSpeccy is obiously not.
Don't get me wrong, JSpeccy is a fine emulator (although I don't like Java apps), but just one of many we have.
On the other hand, BM is a unique baremetal emulator on Spectrum and I find it far more interesting.
But, that's just me.
- desUBIKado
- Microbot
- Posts: 108
- Joined: Sun Jan 10, 2021 10:27 am
-
- Microbot
- Posts: 117
- Joined: Mon Apr 13, 2020 3:07 pm
Re: Strange inaccuracy in some emulators
The paging logic may be the same, but the prefetch of values from RAM is completely different. There is no contention, the video memory is simply sampled all the time, alternating pixel and attribute areas, 1 fetch per cycle. The location shifts each 4 T cycles. Only when CPU accesses the memory, this fetch is skipped. But because the CPU can block this only for 1 T cycle every 3 T cycles, you are guaranteed to fetch both pixels and attributes during each 4 T cycle period.TheMartian wrote: ↑Tue Dec 07, 2021 2:39 pm On ZX Pentagon, after a quick glance to the schematic, it looks pretty much the same as 128K. Still, I've got some differences to Patrik's info on ptime, and atime seems one cycle too early. (I do not own a ZX Pentagon, so I've got to guess...)
Unfortunately, the counter which drives this is not reset on reset, so you never know if the order is pixels/attributes or attributes/pixels. That's why some demos ask you to press some keys to adapt to what is the case...
Hope this explanation helps a bit.
Patrik
-
- Microbot
- Posts: 100
- Joined: Wed Feb 03, 2021 5:18 am
Re: Strange inaccuracy in some emulators
Ok, this definitely helps. I'll have to go over the schematics to fully understand what happens inside the Pentagon yet. At the moment, the "no contention" I'm implementing seems enough for many demos, and I think I got the border emulation right, but there is still room for improvement. I've also got yet to implement the BetaDIsk, so, there's work to do!Patrik Rak wrote: ↑Wed Dec 15, 2021 5:34 pm The paging logic may be the same, but the prefetch of values from RAM is completely different. There is no contention, the video memory is simply sampled all the time, alternating pixel and attribute areas, 1 fetch per cycle. The location shifts each 4 T cycles. Only when CPU accesses the memory, this fetch is skipped. But because the CPU can block this only for 1 T cycle every 3 T cycles, you are guaranteed to fetch both pixels and attributes during each 4 T cycle period.
Unfortunately, the counter which drives this is not reset on reset, so you never know if the order is pixels/attributes or attributes/pixels. That's why some demos ask you to press some keys to adapt to what is the case...
Thanks!