TEK - Rampage issues

[mras0]

Pouet link ADF: TekRampage.zip

• Looks like the sliding TEK logo might have missing some blocks (not sure if this is in the real vAmiga, see screenshot below).
• Crashes in "spaceship part"

Works in WinUAE 4.9.1 with classic A500 quickstart (KS1.3/512K chip/512K slow) and on my real A1200. Note that I tested it because it was mentioned in the "Problematic Demos" thread on EAB (probably for a good reason).

Just tested a few configs (including vAmigaWeb) and issues are the same. (It also crashes in my emulator, but haven't debugged it).

[dirkwhoffmann]

Amazing. Seems like the whole screen is drawn by the Copper.

[dirkwhoffmann]

I think the graphics glitch is not a bug. It is also visible in UAE if the screen geometry is switched to "Extreme" (just notices that I am still running 4.9.0, need to check if this makes a difference...):

On my A500, there is no visible glitch, because the erroneous stripe is outside the visible area. If vAmiga is run with the same screen geometry as my TFT, it looks just fine, too.

BTW, I've written a bunch of new test cases that verify BPLCON1 behaviour in the overscan area (overscan1 - overscan6, overscan1b - overscan6b).

Update: Same in UAE 4.9.1

[mras0]

sorry, yes, you're right about the gap being in the non-visible area. The part appears to be a "standard" BPL1CON "compression", btw like the bouncing logo in Desert Dream (writing lower and lower values to BPLCON1).

Second issue I think is this part:

00038c34  3d40 0058                 MOVE.W      D0, $0058(A6)     ; Start blit
00038c38  43fa 002e                 LEA.L       $002e(PC), A1     ; A1 := $00038c68
00038c3c  21c9 006c                 MOVE.L      A1, $006c.W
00038c40  3d7c c040 009a            MOVE.W      #$c040, $009a(A6) ; Enable blitter interrupt
00038c46  0440 0040                 SUB.W       #$0040, D0
00038c4a  3340 0038                 MOVE.W      D0, $0038(A1)     ; Update blitsize in interrupt code
00038c4e  2228 003c                 MOVE.L      $003c(A0), D1
00038c52  7400                      MOVEQ.L     #$00, D2
00038c54  3428 000c                 MOVE.W      $000c(A0), D2
00038c58  d481                      ADD.L       D1, D2
00038c5a  2341 0002                 MOVE.L      D1, $0002(A1)
00038c5e  2342 000c                 MOVE.L      D2, $000c(A1)
00038c62  2342 0016                 MOVE.L      D2, $0016(A1)
00038c66  4e75                      RTS
00038c68  23fc 0000 0000 00df f04c  MOVE.L      #$00000000, $00dff04c.L
00038c72  23fc 0000 0000 00df f050  MOVE.L      #$00000000, $00dff050.L
00038c7c  23fc 0000 0000 00df f054  MOVE.L      #$00000000, $00dff054.L
00038c86  42b9 00df f062            CLR.L       $00dff062.L
00038c8c  23fc 0d3c 0000 00df f040  MOVE.L      #$0d3c0000, $00dff040.L
00038c96  33fc 4040 00df f09c       MOVE.W      #$4040, $00dff09c.L
00038c9e  33fc 0000 00df f058       MOVE.W      #$0000, $00dff058.L
00038ca6  21fc 0003 8cb0 006c       MOVE.L      #$00038cb0, $006c.W
00038cae  4e73                      RTE

In WinUAE I can see that the interrupt is triggered after the SUB.W instruction at 00038c46 while at least in my emulator it's only after the blit size is updated => Corruption of all interrupt vectors and a messy end shortly after. Likely same or similar issue in vAmiga.

Made a quick test. It's green in WinUAE and blue in vAmiga indicating interrupt happens too fast. That's actually the opposite of what I was expecting, but a difference none the less.
intena.zip

[dirkwhoffmann]

It's green in WinUAE and blue in vAmiga

On my A500, the winner is cyan:

I'll add a INTENA timing tests with a properly synced CPU to the test repo (although your btst syncing code should be enough in this test case). If I remember correctly, I've never written any timing test for this register.

[mras0]

Very interesting, so actual time is (probably) even longer? Of course, the issue might be different in vAmiga, but since I got this debug output if figured it was very close:

[4038] (  9,200) 038C9E  0 BCBSDA 6044 17A2 XFILES: Overwriting existing Blitter event
[4038] ( 13, 32) 00001C  6 BCBSDA 6044 37A2 XFILES: lineFException(ffff)

Looked at the IPL timing of SUBI.W #...,Dn in WinUAE and IPL fetch happens before prefetch which is why I guessed that the issue was interrupt triggering too late.

I didn't figure I needed any elaborate sync for the test, since I just wanted VERTB set in INTREQ (of course could have just set it myself or something similar) and thought only time from INTENA write to interrupt mattered.

[dirkwhoffmann]

Made a quick test.

You've implemented an interesting test case here. I've written some INTENA / INTREQ (enatim1 - enatim4) tests for which I thought they would catch everything your test catches, but they don't.

A major difference is that my tests utilise the Copper to write into INTENA / INTREQ. Needs more investigation later this week...

I haven't found any IPLissue w.r.t the SUB instruction either. I've modified the existing IPL/ADD1.w test by replacing all ADDs with SUBs. As expected, the test image remained the same. Bottom. line: There is no difference between ADD and SUB.

[dirkwhoffmann]

I didn't figure I needed any elaborate sync for the test, since I just wanted VERTB set in INTREQ

If I remember correctly, the VERTB interrupt is signalled at (0,0). There is memory refresh DMA going on in cycles 1,3,5 which might possibly interfere. I am not sure if this could really make the test case indeterministic, but it might be safer to run the code sequence in the middle of the scanline.

[dirkwhoffmann]

I've written two more tests which basically mimic the INTENA test written by @mras0 (enabling IRQ by letting the CPU write into INTENA and running a MOVE reg,reg chain afterwards).

Despite some strange OCS / ECS difference (see #709), vAmiga does it right (it matches the ECS output pixel by pixel).

After running out of options, I decided to run the mras-test again on both of my stock ECS and OCS machines. On these machines, I get a different result. The winner is "blue" on both:

Summary:

• A500 with ACA500plus: Cyan
• Stock A500 ECS: Blue
• Stock A500 OCS: Blue

[dirkwhoffmann]

More findings: I tried to run IPL test IPL/S/SUB1w.adf in UAE. For whatever reason, the ADF does not boot. If include "ministartup.s" is commented out, it boots. However, it's completely off. My CPU sync code does not manage to stabilise the CPU in UAE which results in a flickering image. Here is a still:

vAmiga:

This is the reference image (A500 OCS):

The discrepancies mean that UAE either uses wrong IPL timing for the SUB command or the mismatch is due to a more general interrupt timing issue.

Putting all together, there is another hypothesis we might have to consider: Maybe vAmiga does the right thing (i.e., modifying a Blitter register while the Blitter is active) and crashes because it does not handle this case correctly.

[mras0]

A500 with ACA500plus: Cyan
Ah, yes, that would explain it. I only considered A500 + maybe slow ram when writing the test. That will teach me to throw something together quickly.

Since I last posted the post on EAB has been updated, and latest WinUAE beta now also shows blue in my test. So vAmiga was right all along.

Putting all together, there is another hypothesis we might have to consider: Maybe vAmiga does the right thing (i.e., modifying a Blitter register while the Blitter is active) and crashes because it does not handle this case correctly.

Yes, I asked Ross (Guru from EAB), and while I located the right place where things go wrong my diagnosis was incorrect. It's not related to interrupt timing, but as you guessed, it's because of the write to BLTCON0. Apparently that change causes blitter channel sequence to change to BAC (i.e. no longer writing to D). In other words this crash is expected until "blitter accuracy=3" is supported.

Sorry for the wild goose chases! You can close this one and maybe just leave a mention in #647.

[mras0]

IPL/S/SUB1w.adf is stable in 4.9.1 with A500 "Most common" configuration for me. Config I'm using:a500.zip

Looks like this:

In latest (unstable) beta:

[dirkwhoffmann]

Sorry for the wild goose chases!

That's totally fine. Although there was no bug to fix, it was worth debugging. Firstly, the test suite grew by a few more tests which is good. Secondly, by reviewing my own code, I've seen that I need to verify the timing of the Copper COPJMP instruction. Thirdly, I've levelled up by peeking into your test cases. E.g., I wasn't aware that there is a rep command which allows me to shorten my assembler sources quite a bit in future.