CPU bug?

This section is for discussing everything about Next hardware and latest updates.
azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Mon Apr 05, 2021 7:40 pm

Alcoholics Anonymous wrote:
Mon Apr 05, 2021 4:35 pm
and I've found it affects the border colour timing on the Pentagon. I'm seeing the effect in "Across the Edge"
I do not consider the "Edge" demo as a benchmark.
For me, the standard of timings in the Pentagon is the demo Rage - or rather the very last part of it, the finale. when rotation stops. But on the original deme you can't wait for this, it takes half an hour or an hour, so I made a shortened version to check), when everything stopped - the lines vertical on the screen and the border should match perfectly.

https://drive.google.com/drive/folders/ ... sp=sharing

Well, the test is yes. you need to note the time and run for a few hours :) see how much is in a hurry for long periods

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

Re: CPU bug?

Postby Alcoholics Anonymous » Mon Apr 05, 2021 9:53 pm

azesmbog wrote:
Mon Apr 05, 2021 7:40 pm
I do not consider the "Edge" demo as a benchmark.
For me, the standard of timings in the Pentagon is the demo Rage - or rather the very last part of it, the finale. when rotation stops. But on the original deme you can't wait for this, it takes half an hour or an hour, so I made a shortened version to check), when everything stopped - the lines vertical on the screen and the border should match perfectly.
All those tests run properly on both builds with and without im2 vector fix. But only without does the Across the Edge demo run properly. I think it's quite likely a change was introduced in the timing of iorq in the io write cycle. Whether it fixes it or breaks it is important to know before addressing it :)

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

Re: CPU bug?

Postby azesmbog » Mon Apr 05, 2021 10:57 pm

across_the_edge_by_demarche exists 4! variants, from fix_0 to fix_4
It's not just that the authors made them)
What, all 4 fail now ??

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

Re: CPU bug?

Postby Alcoholics Anonymous » Mon Apr 05, 2021 11:18 pm

azesmbog wrote:
Mon Apr 05, 2021 10:57 pm
across_the_edge_by_demarche exists 4! variants, from fix_0 to fix_4
It's not just that the authors made them)
What, all 4 fail now ??
Everything worked before. Now it doesn't. The im2 vector fix should be completely unrelated but it is not so an unintentional change to the bus cycles occurred, most likely in the io write cycle.

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

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Apr 06, 2021 1:50 pm

Alcoholics Anonymous wrote:
Mon Apr 05, 2021 5:33 pm
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.
I ran it overnight for 6 hr 53 min 15 sec. The Next showed 53 min 13.95 sec in VGA-0 (hours are not accumulated) so I think it's quite accurate. A 62/60 error would show 7 hr [7 min 1.5 sec] and a 61/60 error would show 7 hr [0 min 8.25 sec].

There is a change in the im2 logic from 3.01.09 concerning missed interrupts for brief signals like the ctc's which are only asserted for one clock period at 28 MHz. I wonder if this could explain a difference but it would show as a slower clock rather than a faster one.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Thu Apr 08, 2021 9:29 am

Alcoholics Anonymous wrote:
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.
As I wrote it on GitLab, it looks like two factors:
- The fixed CPU inserts the correct wait states to the intack cycle in every case. Previously it could happen that only 1 wait states was inserted instead of two, when the interrupt occured during an IO instruction. There's an occurrence of this at the pseudo-loader stage, just before the first scene where the error happens. Then the CPU is HALTed one cycle later, comes out of HALT because of an interrupt also one cycle later, everything is shifted by one cycle.

- The Pentagon mode can change the border register in one pixel granularity. Shifting by one CPU clock means a shift of two pixels at the border effect - this could be seen in the failed demo. It doesn't affect 48K or 128K, as it loads the attribute register at a constant pace even in the border area.

I'm not sure how to fix it without breaking anything else. The Rage end scene is OK for example (no such bad interrupt event happens when it's loaded). It's strange that the Across demo relies on bad CPU behaviour.
Maybe the attribute loading of Pentagon can be changed to two pixel granularity (one CPU clock), then one cycle shift doesn't count if it's done in the middle of the IO cycle, as IORQ is active for 2,5 half cycles. If you check The Rage carefully, you can see the diagonal lines in the border area are only 2 pixels precise, so probably the original machine also works on CPU clock level for border attribute setting, not at pixel clock level (Upd.: maybe this theory is stupid, because in one case you must write at T2, other case in Tw, effectively using a 4-pixel granularity, which is probably not good enough).


Who is online

Users browsing this forum: No registered users and 9 guests