active minimig coder

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

[boing4000]

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.

[RedskullDC]

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

[TheDaddy]

>>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 :-)

[boing4000]

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

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

[TheDaddy]

@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.
 :-)

[boing4000]

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  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.

[TheDaddy]

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

 :-)

[boing4000]

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.

[TheDaddy]

>>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 :-)

[boing4000]

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 with included description AND source.

[straycat]

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   :-)

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

[boing4000]

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.

[AJCopland]

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)

Sorry for the **'s but the site censors swearwords, I'm sure you can work it out.