CPU bug?

This section is for discussing everything about Next hardware and latest updates.
slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Fri Apr 02, 2021 3:49 pm

azesmbog wrote:
Fri Apr 02, 2021 3:05 pm
https://web.archive.org/web/20180829085 ... /index.htm

As far as I remember, all the test cases worked for me, with a green border at the top and a yellow one at the bottom.
But now for some reason only the first example works on the emulator.
In the Next - the green border does not work, so the error has been fixed?

Maybe this will help you figure it out? :-))
If there's no green border for the test1, then it means no bug - and I don't see why the T80 should be buggy. The IFF2 clearing and the LD A,[I/R] doesn't overlap, nor the synchronous design of the T80 core allows a race condition here, unless there's some unseen side-effect.

azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Fri Apr 02, 2021 4:32 pm

In emulators, test1 has a green border.
But as far as I remember, test2 worked for me, with yellow at the top and green at the bottom. But now it does not work in emulators either. It’s strange.
Well, there is no mistake in T80 - and it's good that there isn't. And it is not needed.

Request. I would ask you to understand the timings when working with DMA. There are several old demos and even games for DMA.
So, the demo pictures look terribly bad :( And this is definitely related to the timings.
But perhaps this is due to the incomplete simulation of the Z80DMA.
I would like authenticity :)

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: CPU bug?

Postby Ped7g » Fri Apr 02, 2021 5:02 pm

WRT to DMA: make sure you use the $0B port to get Zilog DMA emulation (which is quite decent AFAIK).
The $6B port is "zxnDMA" which behaves slightly differently, the length of transfer is not -1, etc...

I tried to write down some technical details (adding them at bottom of original article) how they differ from real chips on the Next wiki:
https://wiki.specnext.dev/DMA

And I used the interactive "test" I wrote, to check different byte sequences:
https://github.com/MrKWatkins/ZXSpectru ... nteractive
There are also few photos from testing with original Zilog DMA chip. (I had some more done on UA858D chip, and of course I did rerun all of these on my actual Next from first kickstarter, but seems I did upload to github only the Zilog ones, so others may be lost now)

I don't remember any demo completely broken due to timing (maybe something in border may be shifted 8px left or right, can't recall if I did test that level of accuracy), the timings are quite near on Next. But the $6B usage instead of $0B does hurt quite some code, like Busy's DMA demo gets corrupted quickly.

azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Fri Apr 02, 2021 6:17 pm

I know about two different ports.
But I tried to run it in the Next mode - the picture looks terrible.
Now I tried to run it in zx128 mode with DMA enabled - now the picture more or less corresponds to my expectations :)
Image
I figured out for myself that you shouldn't run old demos in Next mode. Well, or correct the timings in this mode.
I will not attach a picture - see for yourself.
>request canceled

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: CPU bug?

Postby Ped7g » Fri Apr 02, 2021 8:07 pm

:shrug: the "Next" mode is +3 timing. The DMA timing is AFAIK identical in both modes (the Next is actually "like +3, but without accurate +3 I/O contention" IIRC, not sure if that makes any difference in DMA performance).

So if that demo works on real +3 well, then I guess there's something which could be improved on Next side.

Oh also, the "Next" mode when selected in TAP loader/etc keeps the NextZXOS ROM, while the 48/128 modes have legacy ROM images in latest OS versions? So the different ROM may be another source of differences, if you run something in "Next" mode.

Ie. you either dig deep and figure out exactly what differs, or I would assume it's not DMA timing (or you have some demo which is really on-the-edge and requires perfect emulation down to +-32T (which is like error I expect from Next at worst from my rough testing of DMA)), but something else.

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Sat Apr 03, 2021 7:14 am

Yes you have to pick the correct machine configuration when running software.

Next = +3 timing with no contention, NextZXOS roms, all hardware enabled
128K = 128K timing with contention, 128K roms, most hardware disabled
48K = 48K timing with contention, 48K roms, most hardware disabled
Pentagon = Pentagon timing with no contention, 128K roms, most hardware disabled

If running SNA or Z80, +2 roms may also come in depending on the save flags in those snapshots.

The dma operates in two modes depending on what port is used to access it. Through port 0x0B the dma acts as a z80 dma and through port 0x6B it acts as a new zxn dma. Port 0x0B is to maintain compatibility with the MB02 and MB03 and their software but it must also be running within the correct frame and contention for those programs to run the same (usually 128K).

The z80 dma mode and zxn dma mode are almost the same right now but there may be major differences if the dma module is upgraded as is the plan. At 14MHz+ the dma bus cycles must be matched to the Next's internal sram cycle requirements to avoid additional wait states. At slower speeds, the bus cycles can be made to match the z80 dma cycles exactly and the only speed where that is important is 3.5MHz anyway.

The z80 dma is a chip with quirks because it's pipelined and there's a few discrepancies because of that that Ped and others have spent some time documenting. The bus cycles at 3.5MHz are slightly different in z80 dma mode as well because of some of these things. So some old dma sw does display slightly incorrectly, off by a byte here or there. An older version of the zxn dma is used in the MB03 where lmn chased down the discrepancies so that the dma there does run all demos properly. I have the changes he applied but the dma in the zxn continued to evolve after that such that the changes can't be applied unchanged. Instead I am waiting to write the next version to tackle that.

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Sun Apr 04, 2021 5:22 pm

azesmbog wrote:
Fri Apr 02, 2021 3:05 pm
Yeah you would have to run for at least 1000 minutes before you might expect to see it count 1.
for me for six hours (360 min) of work of this test the variable "count 3" has counted up to three.
This is normal?
and further. The timer runs a little faster, approximately 62/60 sec.
It's a random event that ctc3 will count up depending on the tightness of the loop, cpu speed and when the program started within the ula frame. We just know for sure that you are not going to see very many of them :)

The reported time is going to depend on the accuracy of the system clock. On VGA-0, which this program is assuming, Fsys = 28 MHz but if you are running for a different display setting the system clock is different. HDMI is 27 MHz, eg, and VGA-1 is a little faster than 28 MHz. And maybe I introduced off by one errors in selecting the count periods. (Should I be setting the counter to 59 rather than 60 when counting seconds?)

azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Sun Apr 04, 2021 5:34 pm

I have a good monitor, and 50 Hz keeps the sweep, and 49 Hz in Pentagon mode.
So I ran in VGA-0 mode
but it's not hard for me to double-check, run for a few hours.
And yet, I do not have the latest hardware version 3.10, but the previous one, 3.09. But I think this should not affect the result.
You can of course try to set the counter to 59 and run the test.

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Mon Apr 05, 2021 4:35 pm

@slingshot, I did some testing with the im2 vector patch applied only (the last two merge commits March 31) and I've found it affects the border colour timing on the Pentagon. I'm seeing the effect in "Across the Edge" which is in the following zip and must be run from Pentagon personality:

https://drive.google.com/file/d/1-3-o4y ... sp=sharing

You can see the problem near the beginning where the border colour change does not line up with the pixel area.

The Pentagon does not have contention so the only thing I can think of is the adjustment in iorq timing has affected the io write / read cycles so that the border colour write to port 0xfe is being picked up by the ula too early. I don't see any changes in 128K demos so far but this sort of thing might be hidden by port contention.

The other possibility is you've fixed a broken io write cycle in which case I should adjust when the interrupt occurs in a Pentagon frame or i should delay when port 0xfe changes are seen by the ula.

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Mon Apr 05, 2021 5:33 pm

azesmbog wrote:
Sun Apr 04, 2021 5:34 pm
And yet, I do not have the latest hardware version 3.10, but the previous one, 3.09. But I think this should not affect the result.
You can of course try to set the counter to 59 and run the test.
There are some small changes in the ctc and the im2 interrupt logic but I don't think they would affect counted periods.

The counters count down to zero and then immediately reload the count period. So a value of 1 will count to zero then pop up to 1 immediately. So that means a period of 1 will mean one tick received.

The timers count up from 0 to 15 or 0 to 255 to do the prescaler division which I think is correct for dividing the 28 MHz clock by 16 or 256. Then the output of this enters the count function which I think is correct as described above.

So I think anything looking wrong will be down to the accuracy of the system clock. I'll let it run overnight and see what happens.


Who is online

Users browsing this forum: Timbucus and 11 guests