Picasso96Modes in the MinimigAGA Core​

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Herr Schönfeld, that was only a "Flüchtigkeitsfehler". But we all get old. I myself had completely forgotten the workaround for the intuition.library 45.13 (see above) and had to read it again first, even though I had implemented it on all my platforms when AmigaOS 3.1.4 was published. ;-)

  • I just tested the new Core 2020-08-23. The behavior is the same as with the predecessor, since you have not made any changes to the screen modes. But I noticed that the error does not occur because 640x400x8 has the same values as 640x480x16 at the same time.


    I recreated the screenmode 640x400 today. Initially only 640x400x8 with the values of 640x400x16. The test image was OK, while an image in PPaint 7.3c again had the known error (image shift). If I took the above value of 640x400x8 everything was OK. Mind you, the resolution 640x400x16 was not yet defined!


    So why does 640x400x8 with the values of 640x400x16 produce a first-class test image, but a shifted image in PPaint 7.3c?


    Cheers

    SID-6581

  • I recreated the screenmode 640x400 today. Initially only 640x400x8 with the values of 640x400x16. The test image was OK, while an image in PPaint 7.3c again had the known error (image shift). If I took the above value of 640x400x8 everything was OK. Mind you, the resolution 640x400x16 was not yet defined!


    So why does 640x400x8 with the values of 640x400x16 produce a first-class test image, but a shifted image in PPaint 7.3c?

    Hi,


    Thanks for testing, but as you correctly guessed there are no changes in this release that affect RTG.


    I haven't been able to reproduce your problem here, which makes it very difficult for me to find the cause. Would you be able to send me an HDF or SD card image that exhibits the issue, so that I can try and track it down?

  • ...today i have tried to install picasso96 driver on my TC64 (MinimigAGA Core)...but when i see the list of graphic card i don't know what i have to choose!.


    there is not a RTG card!


    ..i have downloaded the last version driver.


    HELP!

  • You can choose any - we'll introduce a "install no driver" option with the next update, so 3rd-party drivers can be installed manually afterwards (which is what you need to do here).

  • If you have unzipped the zip file with the Minimig Core, you will find the file "MinimigUtils.adf". Inside is a folder called RTG. There you will find a readme file that describes everything.

  • I do just have a simple up-counter at the moment - though it is added to a base address so there is already an adder in the mix. For the initial version I did my utmost to keep the logic footprint as low as possible, so I'm actually re-using the AGA chipset's existing CRTC to create video framing, then simply filling a FIFO from SDRAM any time it's not full, and emptying the FIFO onto the screen any time the blanking signals are both inactive. It's arguably an overly simplistic solution, but it made very little difference to the core size, which was my main goal.


    If I still have spare logic elements after adding a couple of other features I'll look again at adding modulo support, but since the core already contains a scandoubler, routing the RTG through that is probably going to be the easiest solution, and will probably be smaller than dealing with resyncing the FIFO every scanline.


    Thanks Alastair for releasing a new core from 09/21/2020. I installed it and it works very well. The graphics problem described above still exists, but if one read your release notes, it's no wonder either. ;-)


    But I assume that the problem will have been solved as soon as you have implemented "modulo support".


    Since you have implemented a CPU bugfix for Graftgold games in your current core, I would also like to draw your attention to a graphics error in a game. It's about ZoolAGA. On a real Amiga and under amiberry, the game runs flawlessly. There are graphics errors under the MinimigCore. Mostly around the token. As far as I know, the Unamigacore also has this problem. I therefore believe that there is a bug in the MinimigCore. What do you mean?


    Cheers

    SID-6581

  • Thanks Alastair for releasing a new core from 09/21/2020. I installed it and it works very well. The graphics problem described above still exists, but if one read your release notes, it's no wonder either. ;-)


    But I assume that the problem will have been solved as soon as you have implemented "modulo support".


    Since you have implemented a CPU bugfix for Graftgold games in your current core, I would also like to draw your attention to a graphics error in a game. It's about ZoolAGA. On a real Amiga and under amiberry, the game runs flawlessly. There are graphics errors under the MinimigCore. Mostly around the token. As far as I know, the Unamigacore also has this problem. I therefore believe that there is a bug in the MinimigCore. What do you mean?

    Regarding the P96 problem - I still can't reproduce that on my system, even using exactly the same settings, software version, etc. I will investigate further at some point, but equally I don't want to spend too much time chasing a problem with an obscure screenmode that could be better spent on more widely applicable improvements.


    Modulo support probably isn't going to happen, because (a) it will make the logic significantly larger, and (b) mean I have to adjust the RTG's RAM FIFO so that it can stop and retrace a line, throwing away what it's prefetched. What I will try to do instead is move the scandoubler, which is currently deep within the Minimig, out to the toplevel where it can be used with RTG screenmodes too - this should achieve the same thing (i.e. making low-res RTG screenmodes usable) without ballooning the core size.


    Thanks for confirming the Zool 2 problem - this release did include an upstream fix or two that might have changed this, but I hadn't yet had time to check.

  • Hello Alastair, I found a bug in the new core. After you inserted "LED Audio filter", I can no longer hear the lady saying "Test Drive TWO" in the opening credits to Test Drive II. The sounds of the cars have also disappeared in the opening credits. You can only hear the music there. So no longer the sampled language / engine noises. In the game itself, the engine noises are back.


    If you then simply wait and the game starts demo mode and then brings up the opening credits again, the language and the engine noises are there again. But why not at the start of the game???


    The "LED Audio filter" themselves actually sound good. Can you please explain to us what "LED Audio filter" are and what they do?


    Cheers

    SID-6581


    P.S.: I like the new drivesounds. :-)

  • The "LED Audio filter" themselves actually sound good. Can you please explain to us what "LED Audio filter" are and what they do?

    The real Amiga has two levels of filtering built in - one that's active all the time, and another one that's software-selectable. The software selectable one is tied to the state of the Power LED on the Amiga, hence LED filter. The reason I say it's not accurate is that (for space reasons) I implemented the simplest IIR filter I could find. The filter on a real Amiga has much steeper rolloff - but the simple one is good enough that the tunnel effect in Lotus II is audible, which was my goal.


    Thanks for the test drive II report. I doubt it's related directly to the filter - there were some upstream chipset changes in this release too - but I'll see what I can find out. Does disabling turbo chip RAM make any difference?

  • You can choose any - we'll introduce a "install no driver" option with the next update, so 3rd-party drivers can be installed manually afterwards (which is what you need to do here).

    For the use of the P96 drivers under WinUAE and Amiberry it would, in my opinion, also make sense to support uaegfx.

  • The real Amiga has two levels of filtering built in - one that's active all the time, and another one that's software-selectable. The software selectable one is tied to the state of the Power LED on the Amiga, hence LED filter. The reason I say it's not accurate is that (for space reasons) I implemented the simplest IIR filter I could find. The filter on a real Amiga has much steeper rolloff - but the simple one is good enough that the tunnel effect in Lotus II is audible, which was my goal.


    Thanks for the test drive II report. I doubt it's related directly to the filter - there were some upstream chipset changes in this release too - but I'll see what I can find out. Does disabling turbo chip RAM make any difference?

    Thanks for the explanation. Turbo Chipram was already switched off during the test. The error is gone with TurboChipram ON.


    Addendum:

    So that's strange. After I activated the TurboChipram once, the error has now also disappeared when TurboChipram is deactivated again. This also applies if the TurboChamelon64 is switched off and restarted. I can't explain it to myself, the sound problem was present in my tests yesterday. I hadn't done anything with the TurboChipram either.

  • The audio state machine of Paula (which handles Amiga audio) is not 100% understood. The patent is completely bogus, the hardware reference manual is plain wrong, and therefore all implementations are "best-guesses". We've found exactly that with the audio implementation of Indivision AGA MK3: It's hardly known how registers are initialized, and when counters are (p)reset. I wouldn't be surprised if the truth is even different from all the existing implementations.

  • The audio state machine of Paula (which handles Amiga audio) is not 100% understood. The patent is completely bogus, the hardware reference manual is plain wrong, and therefore all implementations are "best-guesses". We've found exactly that with the audio implementation of Indivision AGA MK3: It's hardly known how registers are initialized, and when counters are (p)reset. I wouldn't be surprised if the truth is even different from all the existing implementations.

    Oh, good to know. That would be an explanation. ;-)