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.
  • OK, so V46 hasn't been published yet, and P96 got the update ahead of time :-)


    I'll leave the two of you to figure out if this is a driver- or a P96-bug. If it turns out to be the latter, we'll of course log that in for fixing.

  • AmigaOS 3.1.4.X comes with two intuition libraries. A 40.87 (09.09.18) and a 45.13 (03.11.18) version. The newer version does not work with CyberGraphX. That is all in the F.A.Q. on the Hyperion website, also how to enable the V45. Maybe the version number V46 has been come into play because of the startup sequence necessary for enabling intuition V45:

    Code
    1. If Exists C:LoadModule
    2.   C:Version exec.library version 46 >NIL:
    3.   If Warn
    4.      C:LoadModule ROMUPDATE
    5.   EndIf
    6. EndIf

    But this obviously checks the version of the exec.library.


    Regards, Thomas

  • Thank you Mate, i read it. But you forgot something.

    As you can read here, you should replace that with: C:LoadModule ROMUPDATE


    How do I install the V45 intuition.library?


    On my other Amiga-Plattforms i replaced it with:


    LoadModule LIBS:intuition.library


    With this option you can move windows outside the screen. On that platforms "version intuition.library" outputs version 45.13.

    I will try that option later on the MinimigCore.

  • I can report that replacing

    Code
    1. If Exists C:LoadModule
    2. C:Version exec.library version 46 >NIL:
    3. If Warn
    4. C:LoadModule ROMUPDATE
    5. EndIf
    6. EndIf

    with

    Code
    1. C:LoadModule LIBS:intuition.library

    in the startup-sequence and renaming LIBS:intuition-v45.library to LIBS:intuition.library,

    results in the output of "version intuition.library" -> "intuition.library 45.13".


    Unfortunately, this does not affect the screen resolution error reported above.


    Cheers

    SID-6581

  • Yes, both resolutions had exactly the same values as 640x400x16. Both gave a perfect test picture. In PPAint 7.3c, a 640x400 picture was then shifted. The menu bar was so high that it was no longer visible, but also shifted a bit to the left. It was as if the screen resolution was now 840x488 (see Settings) and not 640x400.

    OK I've just tried it here and I can reproduce it. I'm not sure, however, whether it's a driver bug or a problem with the monitor misdetecting the screenmode. My monitor's a Dell 2311H - with the settings you used for 640x400x16 my monitor reckons its looking at 720x400, and the image is shifted upwards slightly, and over to the left with a blank stripe at the right hand side. If I uncheck the vertical "SyncPolarity" checkmark, it now identifies the mode as 640x350 but it actually looks OK.


    Does unchecking the sync polarity box make any difference for you? And which monitor are you using?

  • Hi Alastair,


    Running 640x400x8 with the same values as 640x400x16 and unchecked vertical "SyncPolarity" had no effect. The error was the same.

    Running 640x400x8 with 640x400x8 settings and unchecked vertical "SyncPolarity" resulted in a black screen.


    So i left the settings as on the pictures above. I use the LG M2232D-PZ.


    Cheers

    SID-6581

  • I'm not sure, however, whether it's a driver bug or a problem with the monitor misdetecting the screenmode.

    In my opinion, this must be a bug, because the test image is OK if I use 640x400x8 with the settings of 640x400x16. But as soon as I open a 640x400 picture in PPaint 7.3c, the error occurs. So the question is where the error is.

  • In my opinion, this must be a bug, because the test image is OK if I use 640x400x8 with the settings of 640x400x16. But as soon as I open a 640x400 picture in PPaint 7.3c, the error occurs. So the question is where the error is.

    Yes, there's definitely a (driver or hardware) bug which causes some screens to display too high up. I see it on the test screen, too though, not just in PPaint.


    Your monitor doesn't support 640x400, by the way, so it will always try to interpret that screenmode as 720x400. That could account for the left-shifting (though it shouldn't do - you should just get the ugly artifacts that happen when the monitor samples a scanline with a wildly incorrect pixel clock.)


    Is it getting shifted left with a blank area on the right, or is what's supposed to be on the left getting wrapped around to the right?

  • The best thing to do is to take a look yourself.


    1. 640x400x8 with 640x400x8 settings:

    If I open the picture in PPaint 7.3c in 256 or 16 million colors it looks like this:





    2. 640x400x8 with 640x400x16 settings:

    If I open the picture in PPaint 7.3c in 256 or 16 million colors it looks like this:





    Cheers

    SID-6581



    PS: Above you can see the TC64V1 with the Docking Station 2, the Joystick VS-7000

    and the Cherry G80-3000 mechanical keyboard, which I can warmly recommend to everyone. :-)


    The Docking Station 2 has Midi-Ports. Will the MinimigAGACore support this one day?

  • In my opinion, this must be a bug, because the test image is OK if I use 640x400x8 with the settings of 640x400x16. But as soon as I open a 640x400 picture in PPaint 7.3c, the error occurs. So the question is where the error is.

    I have not expressed myself precisely enough here. I don't think that the problem is with my monitor, as the test image is displayed correctly in 640x400x8 with the settings 640x400x16.

  • Thanks for the pictures - the scrambled data at the bottom prove that it's not the monitor. It looks like the video fetch is starting a few rows too early. I have seen that effect here before but annoyingly I can't currently make it happen!

    (The MIDI ports should already be supported - I'll double check them later today.)

  • I've just pushed out an update which fixes an issue with loading config files, as well as some behind-the-scenes stuff. I did find an issue with the RTG support, and if you update the driver from the utils disk, you shouldn't see the stray lines of garbage pixels at the foot of the screen any more. I'm not sure whether it will have helped with the offset problem or not - so feedback would be appreciated.

    http://retroramblings.net/?page_id=1422


    Oh, and I've confirmed that the MIDI ports are working on both V1 and V2 hardware when used with the V2 docking station.

  • Hello Alastair,

    Thank you for your work! Here comes my report:


    The Picasso96 settings had to be changed so that 640x400x8 and 640x400x16 again produced perfect test images.


    When I gave 640x400x8 the same (new) settings of 640x400x16 again, the picture problem was exactly the same as in

    the photo above... wait ... the picture problem was not exactly the same. This time the scrambled data at the bottom was gone.


    After I changed the clock from 22.69 MHz to 25.21 MHz for 640x400x8, the "Back to the Amiga" image was displayed again

    without errors in PPAint 7.3c.


    It is noticeable that the problem only occurs when 640x400x8 and 640x400x16 have the same settings. :/

    Maybe you should do some research there.



    Cheers

    SID-6581



    PS: It's fantastic that your Core offers Midi and RTG! This is how your MinimigAGACore differs from all other ports. :love:

    You should clearly advertise this on your website for everyone to see. ;-)

  • There must be an error in calculation of the frequencies, as the same settings with different pixel clock will result in different horizontal&vertical frequencies. I wonder where that's located.


    Further, didn't Alastair already find that you rmonitor does not support the low resolution you're trying to use?

  • There must be an error in calculation of the frequencies, as the same settings with different pixel clock will result in different horizontal&vertical frequencies. I wonder where that's located.

    The horizontal and vertical frequencies are different with different pixel clock. ;-)

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