active minimig coder

[alexh]

Talking to Toni Wilen, author of WinUAE, Dennis author of MiniMig or RedSkullDC might get you some ideas.

The code you've taken out was there for a reason. I doubt that it was in there just for fun ;-)

The comments say that the copper cannot generate a dmareq on the last cycle in a line... I have no idea if this is true (WTF is my HRM?)

(horbeam[8:2]!=7'b1110001) &&

This is the compare which (supposedly) prevents this dmareq on the last cycle of a line...

horbeam is a counter which counts pixels in a horizontal line.... so is 452 (horbeam[8:2]!=7'b1110001) always the last cycle in a line??

Regardless... this seems to have nothing to do with vertical problems you are seeing??

Interestingly enough, if you read the change log... the bit you commented out was the last thing to be added by dennis.

[alexh]

I dunno quite how "sensitivity lists" work in verilog but in the original copper.v, this line:

always @(selins or selreg or horbeam[1:0])

should have been:

always @(selins or selreg or horbeam)

But I doubt it makes any difference when synthesised. Try it, you never know!

[alexh]

boing4000 wrote:
First of all I mentioned that it could be the cause. also by taking out the last cycle command fetch some "bug" was gone and the copper appears more like the original one.

??

boing4000 wrote:
Also I did not add "always @(selins or selreg or horbeam[1:0])" it is contained in the original code 27_04_2008 release from Dennis' website.

I know... I said that in my post, I just noticed that there was an error in it. But it probably has no effect.

boing4000 wrote:
In my understanding the last cycle in this "jump over range" line is $FFDF,$FFFE (wait for column $DF in line $FF) this is no "regular" command, it is just for skipping over line $FF.

I do not understand what you mean by the last cycle in this "jump over range" line?? And I dont see what the WAIT instruction has to do with the lines you highlighted in the code?

I can see that a "wait for last line, last pixel" would probably correspond to this cycle whereby the copper cannot generate a DMAREQ. Should that matter?

Dennis said in an earlier post that he'd fixed a copper bug about this subject.

Dennis wrote:
The copper bug is fixed, the bug was caused by a broken wait state after the WAIT instruction. This caused the copper to immediately process the instuction after a wait for the end of line 255 ($FFDF,$FFFE), this WAIT instruction actually ends before the end of line 255 ($df instead of $E2) and depends on some kind of delay to take the copperlist to the beginning of line 256.

If you search for "dummy cycle" in copper.v you'll see how he said he fixed it within the WAIT instruction.