Thanks.
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.
You can't rely on any emulator to test code, they're all fallible.
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
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.
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...)
Personally, I would have preferred to see this fix on Baremulator, but that's how it is.
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.
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...)
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...
