Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: boing4000 on June 04, 2008, 12:38:01 AM
-
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
-
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?).
-
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.
-
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.
-
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.
-
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):
//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;
-
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.
-
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!
-
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
-
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!
-
@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.
-
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.
-
Hi all.
AFAIK Yaqube is working too in Minimig's improvements.
Regards
-
The same ADF works fine under WinUAE, I haven't tested on a real Amiga.
My Minimig is the standard one from ACube.
Thanks :-)
-
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.
-
TheDaddy wrote:
The same ADF works fine under WinUAE, I haven't tested on a real Amiga.
My Minimig is the standard one from ACube.
Then the adf should be ok. my minimig is also "standard" ACube one, the loaded firmware inside the FPGA is the real magic. Any minimig is "dumb" when powering up. Every different firmware makes it operate different.
Therefor this PAL60 hack could very well be the reason for many disfunction.
-
Hi Boing4000,
boing4000 wrote:
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)
Yes, doing a bit of work on Minimig (the Altera DE1 port specifically) here, though time is rather limited for the next 3 weeks or so.
My focus is on completing ECS compatibility (about 50% done), plus porting to a couple of other boards I have
(Digilent Nexys2-1200, Cyclone3 NIOS kit).
Happy to share code/ideas (no EGO's here at Amiga.org I hope :roll: )
See you have posted on the tg68 group already, at least I think that is you...
Cheers,
Red
-
>>Then the adf should be ok. my minimig is also "standard" ACube one, the loaded firmware inside the FPGA is the real magic.
My Speedball 2 adf workd on WinUAE perfectly but on standard Minimig its sound is all scrambled up and corrupted, so annoying, any help?
Thanks :-)
-
Yes thats me, there was a longer time no action in this Yahoo group and Im happy to see some reaction.
I think it would be best for all to share the information and source. Also to find a common line of development. Else there could be many different firmware and features releases.
Vesalia and maybe AmigaKit also would like to see a combined development to offer their customers some new (supportable) firmware.
Else it could give e.g. 10 version with 20 different features. A normal user with no programming skill would be unable to use all features at once or have to swap the core (minimig1.bin) all the time.
Also another developer did not know how some feature is realized and it can take much more time to grep a thing out and use this in own project.
Comparing to GNU Linux kernel, minimig needs a bit of guidance to let evereything go the same way. I think that may be of best interest for all minimig platform porting and its users of course :-)
Regards
boing4000
-
TheDaddy wrote:
My Speedball 2 adf workd on WinUAE perfectly but on standard Minimig its sound is all scrambled up and corrupted, so annoying, any help?
Thanks :-)
Thats right the mentioned problem. A released firmware (without source code) is not working fine. How can anybody support this or even upgrading to full operation?
@TheDaddy
sorry I can not help right now. I also have this PAL60 binary and will try it out. As pointed out before, this NTSC hack could cause many unknown problems, I also encounter some while testing.
EDIT: you are right, all sounds in speedball 2 with PAL60 firmware are trashed down. In original Dennis' firmware and own expansions it works correct even with slowram enabled.
What can I say... ask for the source and lets find out the problem.
-
@boing4000
>>EDIT: you are right, all sounds in speedball 2 with PAL60 firmware are trashed down. In original Dennis' firmware and own expansions it works correct even with slowram enabled.
What can I say... ask for the source and lets find out the problem.
What do you mean by "In original Dennis firmware"? Isn't the firmware in the ACube's Minimigs the one from Dennis?
All I know is that my Minimig (sold to me by ACube and never upgraded to anything) doesn't run SB2 properly. Graphics are fine the sound is trashed.
:-)
-
Yes and no... Dennis released 2 firmware version. I dont know what version ACube shipped with because I did not get my minimig with prepared sd-card.
I use this (http://home.hetnet.nl/~weeren001/downloads/minimig1_build_27_04_2008.zip) Dennis' current version from his website (and altered the source code a bit). Even untouched this firmware works very fine with speedball 2.
I believed you also can only use PAL60 on your TFT screen??
This firmware only supports PAL (50Hz) with 15 and 31KHz by jumper setting.
Please tell me exactly what firmware (minimig1.bin) you are using.
-
>>Yes and no... Dennis released 2 firmware version. I dont know what version ACube shipped with because I did not get my minimig with prepared sd-card.
I didn't get the SD Card from ACube, they just sent me minimig1.bin (212KB) and I put it on my own SD Card. It's not version 27_04_2008 I am sure. It's the previous one they had on their site.
Thanks
:-)
-
yeah then just download the current version and try again. the core is not changed that much but it could work better with it.
at least here speedball 2 works very nice and without any error. but still only in 50Hz refresh rate mode.
ps: minimig1.bin will always be the same file size. it depends on spartan xc3s400-4pq208 internal layout. just the file date can tell what version it could be.
-
>>yeah then just download the current version and try again.
The latest one is the one on ACube's site isn't it?
SO I unzip it on my pc and copy minimig.bin on the sd card and replace the old one correct?
Thanks :-)
-
100% correct procedure. dont worry, nothing will be damaged but rename or save the other minimig1.bin somewhere.
power down minimig and restart with new firmware on sd-card!
without power-down the spartan may keep some bits from the older firmware inside and will not act as it should. I found this out by testing many changes on the core with sometimes strange results.
here is my version: download (http://asc.dyndns.org/minimig/download/Minimig-29-05-2008.zip) with included description AND source.
-
boing4000 wrote:
EDIT: you are right, all sounds in speedball 2 with PAL60 firmware are trashed down. In original Dennis' firmware and own expansions it works correct even with slowram enabled.
What can I say... ask for the source and lets find out the problem.
Wow this is a bit of an eye opener for me. I only have a LCD at my house so the vast majority of my testing has been done with the yaqube hacked firmware. I think I'll update my additions on the compatibility wiki to show I've used the hacked firmware. Not too enthralled about making a retrograde step to a CRT (IMO) so (at least for now) I'll keep my fingers X for an 'official' 60Hz firmware update :-)
-
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 (http://www.amiga.org/forums/showthread.php?t=19361) 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.
-
Sorry my english is not that perfect... I try to explain all this in my (translated) words. Its pretty complex to discuss that stuff via text only.
I will check things out and report (hopefully understandable) the result here.
(WTF is my HRM?)
??? is my ??? - all alien to me.
-
boing4000 wrote:
(WTF is my HRM?)
??? is my ??? - all alien to me.
In this case:
WTF = Where The F*k (usually it means "What-The-F**k")
HRM = Hardware Reference Manual
Therefore: "Where The F**k is my Hardware Reference Manual" :-D (HRM pic) (http://www.amigahistory.co.uk/ahrm3rd.jpg)
Sorry for the **'s but the site censors swearwords, I'm sure you can work it out.
-
Yep I did ;) unfortunately I also dont have a HRM to look at.
Right now Im working out that ddfstart/stop problem. Seems to be a combination of 2 signals. Bitplane data fetch stops but bitplane DMA is still working on until end of display line. That may explain heavy distortion in my beloved Vision Megademo IV and other games/demos.
I'll keep you informed about any progress.
-
Hi Boing4000,
boing4000 wrote:
Yep I did ;) unfortunately I also dont have a HRM to look at.
Right now Im working out that ddfstart/stop problem. Seems to be a combination of 2 signals. Bitplane data fetch stops but bitplane DMA is still working on until end of display line. That may explain heavy distortion in my beloved Vision Megademo IV and other games/demos.
I'll keep you informed about any progress.
Have emailed you privately.
I suspect the problem you have with overscan is in the agnus.v: beamcounter module
.....
//generate start of line signal
assign sol=(horbeam==453)?1:0;
.....
Start of line signal is hard-coded to a horizontal beam position. Not sure this this is correct when overscan is in operation.
Cheers,
Red
-
Hello RedSkull,
thanks for your email and explanation in this function.
I also think overscan must be handled intelligent instead of fixed point. I tried to change the sol pointer, even in the slightest change has fatal impact to the generated VGA signal and make my TFT go crazy ;)
Set to 454 the picture appears for 0.2 sec and disappear again. Set to 452 will show no picture at all!
I belief in time your ECS implementation will do this job as in real Agnus chip :)
-
Who is also coding the FPGA core here?
There are a few things I want to change and/or add to the minimig.
For instance:
- make reset funktion in OSD working
- add OSD control via joystick in port 2 (up/down/fire) when active
- simulate left and right mouse button on key "print" and "pause"
If somebody could assist/help, it will be welcome!
-
Yaqube is over in the "Question for MiniMig users (http://www.amiga.org/forums/showthread.php?t=36797)" thread he started the other day. Post in there and maybe PM him as well and you might get some more info. I'm still building my MiniMig :-(
Andy
-
Thanks :-)