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

    If I turn Turbo ON the grafic error in Zool AGA is gone. Turbo OFF brings it back. I alway have Turbo OFF, because i have otherwise grafic issues in "No Second Prize". There the sun gets a bar. But I also have this error on all other platforms with the game as soon as a turbo is activated.

  • If I turn Turbo ON the grafic error in Zool AGA is gone. Turbo OFF brings it back. I alway have Turbo OFF, because i have otherwise grafic issues in "No Second Prize". There the sun gets a bar. But I also have this error on all other platforms with the game as soon as a turbo is activated.

    Well that makes sense - with Turbo off, Chip RAM accesses happen at A500 speeds, while turbo gives you nearer A1200 speeds.


    As a rule of thumb you should have turbo turned off for ECS games if you have compatibility issues - but for AGA games it should always be turned on.

  • When I activate the Turbo for the Kickrom, I regularly get read / write errors on my HDF files. I've just tried that again, which is why I leave the Kickrom-Tturbo deactivated. What is the Kickrom-Turbo supposed to do?


    Currently the MinimigAGACore needs about twice as long to boot my AmigaOS 3.1.4.1 HDF file as my real Amiga 1200 with the AmigaOS 3.1.4.1 from CF card. Are there ways to accelerate the boot process of the MinimigAGACore?

  • When I activate the Turbo for the Kickrom, I regularly get read / write errors on my HDF files. I've just tried that again, which is why I leave the Kickrom-Tturbo deactivated. What is the Kickrom-Turbo supposed to do?


    Currently the MinimigAGACore needs about twice as long to boot my AmigaOS 3.1.4.1 HDF file as my real Amiga 1200 with the AmigaOS 3.1.4.1 from CF card. Are there ways to accelerate the boot process of the MinimigAGACore?

    The KickROM turbo simply selects whether the range of memory that contains the ROM is accessed through the Minimig itself, so at chipset speeds, or through the Fast RAM interface (but without caching), so somewhat faster. Apart from that there's no difference.


    I have seen issues with hardfile corruption, which seems to affect some SD cards and not others. I've suspected that the card's speed has something to do with it - and I didn't know that the turbo kickstart has an effect, so that's useful data. I suspect there's some kind of race condition between the Gayle emulation and control CPU or SD card - though I don't yet have a clue how to track it down or fix it!


    As for speed, there's probably not a lot I can do using Gayle emulation, but since the Amiga and control CPU can share some of the RAM I might be able to create some kind of direct access mode with an associated driver. This will all take time, though.

  • The KickROM turbo simply selects whether the range of memory that contains the ROM is accessed through the Minimig itself, so at chipset speeds, or through the Fast RAM interface (but without caching), so somewhat faster. Apart from that there's no difference.


    I have seen issues with hardfile corruption, which seems to affect some SD cards and not others. I've suspected that the card's speed has something to do with it - and I didn't know that the turbo kickstart has an effect, so that's useful data. I suspect there's some kind of race condition between the Gayle emulation and control CPU or SD card - though I don't yet have a clue how to track it down or fix it!


    As for speed, there's probably not a lot I can do using Gayle emulation, but since the Amiga and control CPU can share some of the RAM I might be able to create some kind of direct access mode with an associated driver. This will all take time, though.

    Thanks Alastair, that was once again a very informative answer. I would like to clarify my statement. So far I have either always activated both turbos (Kick + Chipram) or switched both off. I don't have any HDF problems (at least none that I have noticed) when Kick + Chipramturbo are switched off. If both are activated there are problems. I assumed it would be the KickRom-Turbo ... but that was just a guess.

  • Here is my report:



    Experimental setup:

    ------------------------

    The folder "1" is created with DirectoryOpus 4.16 on drive DH1. There is still 314.9 MB free space on DH1.

    From DH0: the folders "Reflections 3D", "Sculpt-Animate 4D" and "Super-Duper" are copied to DH1: 1.


    Result:

    --------

    1. If each folder is copied individually and copied one after the other, there are no problems.


    2. If all three folders are selected and then copied, DirectoryOpus 4.16 will hang as soon as the second folder

    "Sculpt-Animate 4D" is copied. DirectoryOpus' time display continues to run. Calling up the minimig menu

    with the F12 key is then no longer possible. If the TC64V1 is then switched off and on again, a checksum

    error message appears for DH1 :.


    This happens regardless of whether Turbo-Chipram is switched on or off (Turbo-Kickrom is always off).


    3. But if I activate Turbo-Chipram + Turbo-Kickrom, DirectoryOpus 4.16 will get stuck if I just copy "Refections 3.0".

    In this case I can then call up the minimig menu with F12 and perform a reboot. Then the chechsum error appears for DH1.


    4. If only the Turbo-Kickrom is activated, it is as in point 3. DirectoryOpus 4.16 gets stuck if I just copy only "Refections 3.0".

    A reboot via the minimig menu leads to a checksum error message for DH1.



    Assumption of the tester:

    ------------------------------

    Could the test result indicate that there is already a problem with the KickRom-processing of the MinimigAGACore,

    which is only amplified when the turbo is activated?


    Cheers

    SID-6581



    P.S .: Of course, I replaced the HDF files on the SD card with backup copies after every attempt.

  • You're trying to copy large archives with a large program. Not sure what Dopus 4 does in terms of stack, but you might want to try increasing the stack to 100k, just to make sure you're not running into this kind of problem.

  • You're trying to copy large archives with a large program. Not sure what Dopus 4 does in terms of stack, but you might want to try increasing the stack to 100k, just to make sure you're not running into this kind of problem.

    I repeated the above tests, setting the DirectoryOpus 4.16 stack to 100000. The result remains the same.

  • Thanks, it's all useful data.

    Thanks Alastair for the publication of the MinimigAGACore from October 23rd, 2020. Since you have also implemented "CPU bug fixes from Tobiflex and cache improvements from Slingshot", I ask whether this should also have an effect on the above tests, so that I should test again.

  • Thanks Alastair for the publication of the MinimigAGACore from October 23rd, 2020. Since you have also implemented "CPU bug fixes from Tobiflex and cache improvements from Slingshot", I ask whether this should also have an effect on the above tests, so that I should test again.

    I don't think the fixes will make any difference to the problems you've seen, but I'm not 100% sure.


    I'm still considering how to go about debugging the HDF corruption problem.


    You're on V1 hardware, yes? (Asking because I have one SD card here that resolutely refuses to work with Minimig on V2 hardware, even though it's fine on all other platforms, and works from the Chameleon core on V2, too. Very odd!)

  • I don't think the fixes will make any difference to the problems you've seen, but I'm not 100% sure.


    I'm still considering how to go about debugging the HDF corruption problem.


    You're on V1 hardware, yes? (Asking because I have one SD card here that resolutely refuses to work with Minimig on V2 hardware, even though it's fine on all other platforms, and works from the Chameleon core on V2, too. Very odd!)

    Thanks for the information. Yes, I am using a TC64V1. Above I uploaded a photo of the SD card I am using.

  • After the results of the above tests had not changed with a stack of 100000 for DirectoryOpus, I finally set the stack to 500000. Look at the results:


    !!!TurboChipram ON or OFF + TurboKickrom OFF: All three folders are copied without errors. !!!


    TurboChipram ON or OFF + TurboKickrom ON: DirectoryOpus no longer hangs, but windows with the error message "AmigaOS 3.1.4.1 has a checksum error in disk block ..." appear while the three folders are being copied.


    This result should be taken as proof, that the TurboKickrom leads to checksum errors on the HDF files.


    Cheers

    SID-6581

  • Thanks for taking the time to test this again - it's much appreciated. Half a meg is a *huge* stack - I suspect the root cause of this is going to be something much more subtle. I'm fairly certain it's timing-related, which is why the Turbo KickRom function makes a difference - but in a system that employs burst transfers and cachelines, timing can be affected by something as simple as the load address - so the larger stack could have affected it in that way, rather than because the software actually needs it.

  • Thanks for taking the time to test this again - it's much appreciated. Half a meg is a *huge* stack - I suspect the root cause of this is going to be something much more subtle. I'm fairly certain it's timing-related, which is why the Turbo KickRom function makes a difference - but in a system that employs burst transfers and cachelines, timing can be affected by something as simple as the load address - so the larger stack could have affected it in that way, rather than because the software actually needs it.

    A very interesting approach. Do you think a solution is feasible? Would it be very complex or rather simple?


    I found another problem:

    When I start NON-WHDLoad games (PAL) like Austerlitz, the picture is shifted to the left. The writing is no longer legible on the left edge. There are no problems with this in WHDLoad games. I'm not talking about the edge of the monitor, but the edge of the image displayed. The folder Devs/Monitors only contains the files PAL, NTSC and Minimig.

  • THe picture shifting might be caused by a hardware difference between V1/V2 Chameleon hardware. We just today found that the H/V Sync output polarity is not properly documented in the FPGA coder's manual. In short:


    V1 hardware outputs the H/V Sync signals inverted

    V2 hardware outputs the H/V sync signals non-inverted.


    Most monitors don't care, but shift the picture a little. Some monitors might just fail displaying the picture. In order to bring both hardware revisions in line, Alastair should change his toplevel designs to make that difference. Note that this is just an implementation detail of the target hardware that can be easily taken care of in the core- but it should be taken care of, otherwise bug regports might come in totally weird and not reproducable for Alastair.

  • Ah... that would explain it.


    I must correct myself. I have the left shift in all PAL games, no matter if WHDLoad or NON-WHDLoad.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.