active minimig coder

[boing4000]

Hello,

is there any other active minimig coder arround? I would like to share informations and ideas to fix some bugs in the FPGA core.

Priority could be:
- bitplane distortion (possible due to ddfstart and ddfstop issue)
- blitter (some player character are invisible - not sprites)
- sprites (minor things)

I already did some changes to the core in order to figure this problem out.
With combined power we should make minimig working just as an A500 :-)

Regards
boing4000

[Phantom]

Believe it or not, these things are holding me not to buy MiniMig yet. I hope to see a new firmware, that I can play Speedball 2 (or can I?).

[HenryCase]

boing4000 wrote:
is there any other active minimig coder arround?

You'll find some here:
http://gamesource.groups.yahoo.com/group/minimigtg68/
There are other active Minimig developers around, but the Yahoo Group in the link above is a decent place to start.

[boing4000]

Believe it or not, these things are holding me not to buy MiniMig yet. I hope to see a new firmware, that I can play Speedball 2 (or can I?).

You can! Its working really great on minimig (terrible loading behavior ;-) ).
Many other games also work but show minor or mayor display problems. So it should be fixable.

[boing4000]

HenryCase wrote:

You'll find some here:
http://gamesource.groups.yahoo.com/group/minimigtg68/
There are other active Minimig developers around, but the Yahoo Group in the link above is a decent place to start.

Thanks but this is for DE1 and DE2 developer board from Altera. This ppl did a portation to another hardware and FPGA. Also using a Z80 cpu to load the core and simulate floppy.
I asked them for compatibility before, basicly its the same core but with changes to different FPGA design.

I'll take a look at the sources, perhaps there are already some bugs fixed.

[boing4000]

Perhaps I found a major bug trace. Using kickstart 2.0 raw cli, dragging the screen down will shift or "destroy" bitplane below line 200 (NTSC range). In Kickstart 1.x it is working correct, most likely 2.0 use a different copper list.

I already change the copper and got a bit better result, also in some demos it shows little improvement.
Still this instruction $FFDF,$FFFE (copper jump over range) could not work right or will be ignored?
Would be nice if somebody could crosscheck this.

digest of copper.v in this matter (very last part):

Code: [Select]


//the last cycle in a line is not usable by the copper(?)
always @(selins or selreg or horbeam[1:0])
if( (horbeam[1:0]==2'b01) && (selins || selreg) )//request dma cycle
// (horbeam[8:2]!=7'b1110001) && <removed for testing, shows little improvement>
reqdma=1;
else
reqdma=0;


[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!

[TheDaddy]

You can play Speedball 2 on the Minimig but on mine the sound is corrupted so no "Ice Cream!, Ice Cream!"

Minimig case is coming!  :-D

[straycat]

boing4000 wrote:

Believe it or not, these things are holding me not to buy MiniMig yet. I hope to see a new firmware, that I can play Speedball 2 (or can I?).

You can! Its working really great on minimig (terrible loading behavior ;-) ).
Many other games also work but show minor or mayor display problems. So it should be fixable.

For some odd reason I've only tried this game with Kick 3.1...  will have to try it with 1.3 now!

[boing4000]

@alexh

thanks for your ideas and argument. 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.

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.
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.
Maybe the copper can not handle the further copperlist after that command right. it would at least explain the distortion.

further on I have reason to believe that something in dualplayfield or ddfstart/stop handling is incorrect. many demos show a destroyed screen, mostly in scrolltexts and logos. this could caused by mismatch of blitter modulo and bitplane width.

[boing4000]

TheDaddy wrote:
You can play Speedball 2 on the Minimig but on mine the sound is corrupted so no "Ice Cream!, Ice Cream!"

One missing sample makes the game unplayable? Here (in PAL50 mode) it is working fine. perhaps due to the PAL60 patch the timing is incorrect. Did you try the same adf on real amiga?
I found out that this PAL60 hack is not very compatible, many games/demos wants to wait for raster line 254 or at least something beyond 200 what the NTSC range is.
This games/demos simply stop or freez at 60Hz refresh rate, so it is no real NTSC simulation.

[BraindeaD]

Hi all.

AFAIK Yaqube is working too in Minimig's improvements.

Regards

[TheDaddy]

The same ADF works fine under WinUAE, I haven't tested on a real Amiga.

My Minimig is the standard one from ACube.

Thanks  :-)

[boing4000]

BraindeaD wrote:
AFAIK Yaqube is working too in Minimig's improvements.

Yaqube did not release the source code to the PAL60 with bilinear filter firmware! so one could only guess what the changes are :madashell:
GPL clearly indicate that source must be release (at latest by request) to a public binary release.