blitter accuracy

[mithrendal]

Blitter works well enough to get the graphics displayed, but when the trackdisk.device uses it, it just produces garbage...

[h5n1xp]

Also note that currently, the chipset.c function blitter_execute() is just called on the first available DMA slot(due to my pipeline, actually 2nd available slot), at which point the whole blitter operation is completed.

[mithrendal]

assuming you are correctly blaming your specific blitter implemention as the reason for it, I think ... there are the following approaches for this kind of issue... a) Unit test the blitter code. b) stop at failure and debug and look whats wrong c) look at a correctly functional piece of blitter code (WinUAE or SAE) and debug that to the same position or a few lines before and look into the state of both machines while stepping forward. Then every difference in the state of both machines might be the reason for the issue. d) look at a correctly functional piece of blitter code and try to spot the differences in the implementation.

did I maybe forget one ?

The question is how to best approach this issue to solve it in a minimal amount of time ...

I think a) is not working because we have no test cases. Although one might create them, you never know whether they are complete and cover the functionality of the issue... b.) Is also somewhat difficult, because it does crash in 68k code, for which you probably have no debugger at the hand. c.) is maybe a good one d.) is maybe ok too.

What do you think ?

I would personally prefer c.) 1.insert the same kickstart and disk which you are inserting in Omega into this puppy ;-) http://scriptedamigaemulator.net/ 2.insert some javascript breakpoints into here https://github.com/naTmeg/ScriptedAmigaEmulator/blob/master/sae/blitter.js

3. do the same in Omega and step forward to the error and watch out for the differences...

an implementation of the blitter written in verilog HDL can be found here https://github.com/rkrajnc/minimig-de1/blob/master/rtl/minimig/Blitter.v ( @dirkwhoffmann has found some hints for the implementation of "incomplete address encoding" in his vAmiga in Gary.v, so maybe this might work with the Blitter.v too !?)

BTW: I just discovered that @rkrajnc who manitains the verilog code of the minimig has given a star to your omega ;-) Cool!

an implementation of the blitter written in cpp or Javascript can be found here https://github.com/tonioni/WinUAE/blob/master/blitter.cpp or here https://github.com/naTmeg/ScriptedAmigaEmulator/blob/master/sae/blitter.js

[dirkwhoffmann]

SAE can be debugged conveniently in Chrome with the Chrome dev tools. The only problem is the complexity of the SAE code.

I didn't look at the Verilog Blitter code yet (I'm way behind with my emulator and struggling with memory initialisation at the beginning of the Kickstart code 😉), but I think it's worth a try.

[h5n1xp]

assuming you are correctly blaming your specific blitter implemention as the reason for it, I think ... there are the following approaches for this kind of issue... a) Unit test the blitter code. b) stop at failure and debug and look whats wrong c) look at a correctly functional piece of blitter code (WinUAE or SAE) and debug that to the same position or a few lines before and look into the state of both machines while stepping forward. Then every difference in the state of both machines might be the reason for the issue. d) look at a correctly functional piece of blitter code and try to spot the differences in the implementation.

did I maybe forget one ?

The question is how to best approach this issue to solve it in a minimal amount of time ...

I think a) is not working because we have no test cases. Although one might create them, you never know whether they are complete and cover the functionality of the issue...

Agreed, too difficult for this problem I think.

b.) Is also somewhat difficult, because it does crash in 68k code, for which you probably have no debugger at the hand.

I can easily get the 68K emu to spit out the disassembled code once the trackdisk device starts to use the Blitter. It was being able to see the 68k code being executed which has got me this far... Especially though the tricky exec initialisation process :)

The difficulty is getting other emulators I don't have full control over to give me as much detail. My two debugging tools are an A500 with an Action Replay III cart and WinUAE 4 running in Wine...

c.) is maybe a good one d.) is maybe ok too.

What do you think ?

I would personally prefer c.) 1.insert the same kickstart and disk which you are inserting in Omega into this puppy ;-) http://scriptedamigaemulator.net/ 2.insert some javascript breakpoints into here https://github.com/naTmeg/ScriptedAmigaEmulator/blob/master/sae/blitter.js

3. do the same in Omega and step forward to the error and watch out for the differences...

an implementation of the blitter written in verilog HDL can be found here https://github.com/rkrajnc/minimig-de1/blob/master/rtl/minimig/Blitter.v ( @dirkwhoffmann has found some hints for the implementation of "incomplete address encoding" in his vAmiga in Gary.v, so maybe this might work with the Blitter.v too !?)

BTW: I just discovered that @rkrajnc who manitains the verilog code of the minimig has given a star to your omega ;-) Cool!

That is cool, I hope he might spot some mistakes... Unfortunately I don't know verilog to read it :(

My debugging process is to run tests though it and confirm the output, this is how I got the line mode working, but that took, I think, 5 days solid work, which I could do since I was not at work last year. I don't have that sort of time now, so I'm going to need to be much smarter about this.

[h5n1xp]

SAE can be debugged conveniently in Chrome with the Chrome dev tools. The only problem is the complexity of the SAE code.

Trying to read JavaScript is much harder than writing it 😄

I didn't look at the Verilog Blitter code yet (I'm way behind with my emulator and struggling with memory initialisation at the beginning of the Kickstart code 😉), but I think it's worth a try.

Kickstart is VERY fussy about memory, you need to have all sorts of traps and shadows to fool it into thinking it is running on a real amiga. Look at my memory.c file, it is probably the oldest file in the project as every time I tried to clean the code up the emulator stopped working!!

[h5n1xp]

Ok, so I have poured through the Chipram to see if I could see anything which looked like the first track of my Workbench 1.3 disk... and I found the bootblock! And here I find corruption at byte 518! now to find out why.

DecodedBootBlock.txt

[h5n1xp]

While debugging the Blitter MFM decoding, I noticed illegal characters in the data... sure enough, my floppy loader was letting 0s into the data stream. Fixing that means Omega now boots floppy disks, they have read write errors, so it can be slow going. I will leave this issue open as it think my blitter code is still having random issues, but not as severe as initially thought!

[mithrendal]

Wow that looks cool ! 😃

[h5n1xp]

I have uploaded a few more ADFs to the repository, raw3.adf is the "Amiga 500 Tutorial" disk, that came with my old Screen Gems A500, it seems to be showing up more blitter errors... I will try to investigate.

raw5.adf contains DPaint, which also shows blitter some errors, much more reproducible!

[h5n1xp]

Bug spotted by aros-sg on EAB, I was preserving the unmasked version of Channel A. Fixed now. Blitter seems to be working without error for the two currently implemented modes.