exxos's Atari, Amiga & retro forum

Cyprian wrote: ↑Fri Oct 16, 2020 8:17 pm there the CPU starts the BLiTTER 4 cycles (1 bus access) later.

Interesting.. so how many bus cycles does it take each line then ?

Cyprian wrote: ↑Fri Oct 16, 2020 8:17 pm great news looks almost perfect.
I wonder about two things:
- "1st image" - the right part - marked "Sprahlaphobia". CPU bars (white/grey/red) above the BLiTTER activity are skewed but should be straight like those below the BLiTTER activity area. Looks like something delays the CPU by 4 cycles (one bus access) each line.

I will take a look at that. Thanks for the pointer.

Cyprian wrote: ↑Fri Oct 16, 2020 8:17 pm - "2nd image" are you sure they are marked correctly? For me the right part, marked "Sprahlaphobia" is actually the real STE, and the left part is "Sprahlaphobia" - there the CPU starts the BLiTTER 4 cycles (1 bus access) later.

Yes you are right. I have the two screenshots on the 2nd picture round the wrong way.

So from your descriptions there seems to be a 4 cycle delay indicated in both images.

@exxos @Icky
unfortunately I have a busy day ahead, I'll try write more tomorrow evening .
Long short story: 1) I have a suspicion about your FPGA BLiTTER register $FFFF8A38, write to it could introduce 4 CPU cycle delay (red part before the BLiTTER is fired). 2) In general the FPGA BLiTTER cycles look ok, but internal split between bus mastering and data access looks strange (blue green black pattern in the 2nd screen)

1st image / BLiT_H6a.s "The green stairs" - One green step is 1 bus cycle long (4 low res pixels / 4 CPU clocks)

Top - real STE
Red box has 4 bus cycles width (four green steps). Below is the code responsible: Bottom - Sparklaphobia
Red box has 5 bus cycles width (five green steps)
This is one bus cycle more than real STE, and it could be caused by additional waitstate? in "move.w D0,(A0)" (write to the BLiTTER register)



2nd image / BLiT_H6a4f The red line (just below a red box) is responsible for starting the BLiTTER. I highlighted it with the green stairs

Top - real STE
The green stairs have 5 steps. They start 1 bus cycle earlier than red box. Below is the code responsible: Bottom - Sparklaphobia
The green stairs have 6 steps. They start in the same spot/column as than red box.
1) The delay is caused by issue with "move.w D0,(A0)" as above
2) 6 green steps - it means that the Sparklaphobia starts one bus cycle later than the BLiTTER
3) The red arrows show green spot which is in the different place (one bus cycle later) maybe due to point 2)


Attached (BLiT_R1.zip - binary plus source code) you can find a new test which writes some data to the BiTTER without starting it. We could see whether the BLiTTER/Sparklaphobia access time is the same or different.
There are five red boxes:
3x Red/Green boxes - this is a control area (only the CPU)
2x Red boxes - test write to the BLiTTER/Sparklaphobia. The first box - write to BLiTTER Y COUNT, the second one - BLiTTER Halftone. Usage:
BLiT_R1
SPACE - quit
1 - 50Hz
2 - 60Hz


Btw BLiT_H6a4f usage is:
SPACE - quit
1 - 50Hz
2 - 60Hz
3 - Delay 2
4 - Delay 1

Thanks @Cyprian. I know you said you had a busy day yesterday so appreciate the effort. I will take a look with your new program later as I too am distracted by non-Atari things this morning.

Hopefully we can zero in on where the issue is in the core or the board and solve this

Just a side note on verification of this kind of problem. I have some experience with this.

If you have a test case that can be put in the registers of an emulator and simultaneously put in the registers of the new blitter then my approach has been to get a fast PC do the same test in the emulator C code and using a Verilator model then compare RAM.

Then put this test into a for loop N times with each loop generating random inputs that get passed to both tests.

This worked a treat verifying that the Amber CPU had bugs in some of its ALU functions.

Thanks @terriblefire will look into that as well. My FPGA skills are still growing and this is going to be another learning curve

A little bit more progress but I think still a long way to go....

After trying out @Cyprian's 3rd program on the Sparkalaphobia I got the below pattern which clearly was not right:


I played around with the clocks and timings and managed to get the third program on the Sparkalaphobia to look like this:


Which if you compare it to the same program in the same STFM with an original Blitter the pattern there is as follows, which looks identical unless anyone can spot a difference in there:


Now running the other two programs there are some very slight differences but one that sticks out is the black square on the first program on the original is at the top right and on the sparkalaphobia its moved just off centre to the left and down a bit.


Original - program 1:
Sparkalaphobia - program 1:
The second program looks like I have got the green stairs in @Cyprian's description down to 5 steps and but they look shifted to the left by one:


Original - program 2:
Sparkalaphobia - program 2:
BUT these changes have pushed the GEMBench scores up and we are now in the 99%-100% ranges where as before we were in the 98%-100% ranges across all the tests:

Great progress @Icky

One remark, regarding 2nd image / BLiT_H6a4f (actually the same issue is in the 1st but easier shows it here). The first Sparkalaphobia line is 1 bus access shorter than the BLiTTER's one. The difference is visible in the second line:
- it starts 1 bus cycle earlier (should be 2 bus cycles between each lines beginnings);
- and also green spot should be at the beginning of the second line but in case of Sparkalaphobia, it is on the second position (marked with the red arrow in my previous post);
and also in the first line - the ending "red" should be under "3", in case of Sparkalaphobia it is between "2" and "3"

Thanks @Cyprian that will be my next focus.