Vamiga: Tests cputim1 and cputim1b fail

[dirkwhoffmann]

Both tests execute experimental code that syncs the CPU to a specific raster position (if somebody knows an easy solution for that problem, please let me know). The sync code is drawing in dark red, blue and yellow. The CPU draws in gray. Syncing works if the yellow bar is aligned and the image stable.

In both tests cases, vAmiga hangs in the sync routine. UAE syncs well:

cputim1b (UAE): 👍

cputim1b (vAmiga): 🙈

[mithrendal]

https://github.com/dirkwhoffmann/vAmigaTS/blob/master/CPU/cputim/cputim1/cputim1.s

I interprete the result in vAmiga (red screen) in that way, that the CPU hangs in synccpu3 because the horizontal bits of VHPOSR never gets zero...

Strange ... you recently fixed it on tonis advice so that vertical part contains previous line value if horizontal part (H8-H1) is 0 and only current line when 2. But that should not be the cause of the hanger as far as I see it...

Is this really the test prg ? Or do you use a "b" version?

[dirkwhoffmann]

the CPU hangs in synccpu3 because the horizontal bits of VHPOSR never gets zero...

Yes, exactly. Actually, it was a stupid out-by-one error in function peekVHPOSR():

This is the old code:

   // To get the correct result, we need to advance the horizontal position by 4 cycles.
    posh += 4;
    if (posh > HPOS_MAX) {
        posh -= HPOS_MAX;
        posv++;
        if (posv >= frameInfo.numLines) posv = 0;
    }

This is wrong and needs to be replace by:

   // To get the correct result, we need to advance the horizontal position by 4 cycles.
    posh += 4;
    if (posh > HPOS_MAX) {
        posh -= HPOS_CNT;
        posv++;
        if (posv >= frameInfo.numLines) posv = 0;
    }

With this simple change, the test runs just fine in vAmiga:

In UAE there is a small blue stripe at the very left. In vAmiga, this area already belongs to the HBLANK area which can be seen in the DMA debugger. The HBLANK area is the grey area. The black area is unused texture space:

The red lines on the right side mark the DMA cycles which are blocked by the Amiga to perform DRAM refresh.

The really cool thing about this code is that it enables me to sync the CPU to a specific raster position. Formerly, only my Copper tests were pixel exact. All tests that utilised the CPU either had a visible jitter or more than one stable states (which means that the image can look slightly different when running the test again).

The sync code is working in two stages. In the first stage, I do horizontal syncing. This is again done in multiple stages. First, I force the CPU into a 16-cycle raster. After that, I force it into a 32-cycle raster. When this has been achieved, the code waits in a loop until hpos equals 0.
In the second stage, the code loops until the vertical position has been reached. In each iteration, I consume the right amount of cycles to reach exactly the same horizontal position in the next line (the yellow stripes on blue).

Although I think the code is kind of 😎 (now, as I wrote Moira, I know for the first time what I am really doing when writing 68000 assembler code), I think it can be improved. In theory, it should be possible to achieve horizontal syncing by jumping in a NOP field with an offset computed out of the current value in VHPOSR. This is the standard way to sync the CPU of the C64 to to a specific raster position.

[dirkwhoffmann]

New test cputim1c: Syncing code is visible at the top at the screen (magenta). Below are the Copper reference lines, grey bars drawn by the CPU, and a red/white/red stripe drawn by a level 1 IRQ triggered by the Copper. No more jitter. The image is completely stable on the real machine:

Here is what UAE is drawing: 👍

Here is how vAmiga/Moira performs (note the difference in the syncing code): 😎