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

    As it happens, I had already noticed and taken care of the sync inversion with V1 hardware.


    I think the problem you're seeing happens with system-friendly games that open a low-res screen?

    Also DPaint / PPaint show it too, if you open a 320x256 screen - but are OK if you open a 640x256 screen?


    As a temporary workaround, use overscan prefs to set PAL overscan to its minimum width and rightmost position.

  • Thanks for the tip. After I edited the overscan, the image is still not displayed in the center of the monitor, but at least the entire PAL screen content is displayed correctly again.


    Can the timing problem you suspect while using the TurboKickrom be fixed?

  • Thanks for the tip. After I edited the overscan, the image is still not displayed in the center of the monitor, but at least the entire PAL screen content is displayed correctly again.


    Can the timing problem you suspect while using the TurboKickrom be fixed?

    Glad to hear the overscan tip helped. I traced this problem to border-blank utlities - there's a bug in the chipset implementation which I've fixed, so this problem will go away in the next release.


    As for the Turbo KickROM / timing problem - the exact nature of that bug is still just a theory - I can only fix it if I can figure out exactly what's going on. I don't yet have any idea how to isolate one failing write out of hundreds of thousands, in order to observe the error - but I am giving some thought to the best way of approaching it.


    In the meantime, I did find and fix an SDRAM refresh timing bug which may also make a difference - I'll make a test core available soon, because if the SDRAM refresh isn't correct other tests aren't going to give repeatable and reliable results. (I think Jens said once before that the SDRAM chip used on the TC64 is quite forgiving in some regards, but not with regards to refresh.)


    (The other thing that might make a difference, since you're on V1 hardware, is that the SD card signals go through a multiplexer so I might have to slow them down a bit more.)

  • As for the Turbo KickROM / timing problem - the exact nature of that bug is still just a theory - I can only fix it if I can figure out exactly what's going on. I don't yet have any idea how to isolate one failing write out of hundreds of thousands, in order to observe the error - but I am giving some thought to the best way of approaching it.

    "one in a few thousand" is something where I would look for corner-cases such as "refresh request coming in during write" or "write comes in while refresh is in progress" - this is where you may be closing the row too early. Note that after a write, you need to give RAM an extra clock cycle before precharging the row. In my own SD-Ram controller designs, most state machines just run until the end before they allow the start of a new action, but if you have some strategy like "keep the row open if next access is in the same row", then you might violate the write-precharge timing. In essence, your write arrives in the row amplifiers "just after" the contents have been written back into the array with the precharge command.


    This error becomes more likely if you don't close the row on your own timing, but if you're using auto-precharge. However, even if you use manual precharge, you might want to double-check if you're giving the "precharge all" command (A10=1 during precharge), as your row address might already be invalid by that time. This might make you lose a whole row of data.

  • "one in a few thousand" is something where I would look for corner-cases such as "refresh request coming in during write" or "write comes in while refresh is in progress" - this is where you may be closing the row too early. Note that after a write, you need to give RAM an extra clock cycle before precharging the row. In my own SD-Ram controller designs, most state machines just run until the end before they allow the start of a new action, but if you have some strategy like "keep the row open if next access is in the same row", then you might violate the write-precharge timing. In essence, your write arrives in the row amplifiers "just after" the contents have been written back into the array with the precharge command.

    Thanks for the hints - I'll double-check all those things in the SDRAM controller, but I believe it's OK. It doesn't do anything smart with regards to leaving rows open since it's very hard to do that and maintain the absolute deterministic response time the Minimig core requires - but it does make good use of bank interleave. Its only major weakness is write performance.


    But the bug we're talking about here relates to SD card writes rather than SDRAM writes. There's a possibility that the refresh timing bug I fixed could have interacted with the turbo kickstart setting to cause corruption of file copy buffers.

  • Hello Alastair,

    thanks for the new Minimg AGA Core from December 5th, 2020. The above-mentioned read / write errors have now been corrected, even if the Directory Opus Cache is reset from 500000 to 50000. Great work!


    I'm also very happy about the new RTG 16-bit support and the 2.5 MB extra fast RAM.


    The FDD and HDD drive sounds are especially fun. You get a real Amiga feeling!

    A nice Christmas present from you. Thank you!



    Cheers

    SID-6581 :-)



    PS: I found a problem with the HDD drive sound. After a reboot of my TC64V1 you can no longer hear the HDD drive sound, although it is still activated in the menu. Only when the drive sound is switched off and then on again in the menu is it reactivated. I don't have the problem with a reset.

  • Oh great, that sounds good. :-)


    If you were able to use the "RR-Net MK3" under the MinimigAGACore so that Internet is available under the Workbench, that would be a reason for me to buy the "RR-Net MK3". But the question is whether that would even be possible. Of course, this could only be realized once your schedule allows it.

  • Making the clockport available in the core shouldnt be terribly hard - but that doesnt mean it would magically work with any software :) You'd still need some drivers for the rr-net, which afaik do not exist for the amiga.

  • You'd still need some drivers for the rr-net, which afaik do not exist for the amiga.

    Correct, these don't exist, and it does not make sense to develop something like that. The CS8900 Ethernet chip of RR_Net is in 8-bit mode, where it can't issue IRQs properly. As a result, the Amiga would be spending an enormous amount of time in poll-loops to make sure it does not miss any incoming traffic. Multitasking would be constantly switching to the driver task, completely breaking usability of the machine. Anyone who would spend the time to implement such a driver will be completely disappointed that his efforts were completely useless. We've had this discussion over and over again during the past years, as so many people wanted to have a cheap clock-port based Ethernet card for the Amiga.


    The smallest denominator for the Amiga is a 16-bit chip with IRQ capability. I have pushed the cost for this down a lot with the X-Surf-500, a 100MBit Ethernet card for the ACA500plus. I do see a possibility for a Docking station that lets you use this, which would make MUCH more sense than "anything clock port". Yes, it would cost additional money and yes, this 100MBit Ethernet port would not be usable from the C64 side. However, it would be the only thing that results in a usable system.

  • The smallest denominator for the Amiga is a 16-bit chip with IRQ capability. I have pushed the cost for this down a lot with the X-Surf-500, a 100MBit Ethernet card for the ACA500plus. I do see a possibility for a Docking station that lets you use this, which would make MUCH more sense than "anything clock port". Yes, it would cost additional money and yes, this 100MBit Ethernet port would not be usable from the C64 side. However, it would be the only thing that results in a usable system.


    If the price was kept within a reasonable range, I would be very interested in such a product for the docking station. I think that this would also be interesting for even more customers, since nowadays the Internet is almost a matter of course for the Amiga. But the MinimigAGACore would have to support the product first. ;-)

  • The RTC time is now displayed under the workbench and the HDD sound problem during a reboot has now also been fixed. Thank you Alastair. You and your family have a healthy and successful year 2021! :-)

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

    I would like to ask again on the subject. Have you already had the opportunity to start your project with regard to the Scandoubler?

  • Hello Alastair,

    I would like to draw your attention to this video.

    https://www.youtube.com/watch?v=VhUsCgTI0o0


    Please have a look at the minute 8:13. The minimig menu for the MISTer is shown there. Apparently a Scandoubler function has already been integrated there. What do you think of the idea of looking at the MinimigAGA Core for the MISTer to see how the Scandoubler was integrated?


    Cheers

    SID-6581

  • Please have a look at the minute 8:13. The minimig menu for the MISTer is shown there. Apparently a Scandoubler function has already been integrated there. What do you think of the idea of looking at the MinimigAGA Core for the MISTer to see how the Scandoubler was integrated?

    Not really much help there, I'm afraid - the MiSTer's a completely different animal. Moving the scandoubler to the toplevel so I can pipe the RTG output through it as well as the Amiga's video is on my To Do list - but as with all such projects, no promises as to when it will reach the top! ;)

  • Hello Alastair,

    thanks for the new firmware version from 07/26/2021.


    I particularly like the fact that a primary hard disk and a secondary hard disk, each with a master and slave, can now be selected in the configuration and thus a total of 4 hard disks can be used.


    I would like to point out a problem to you.

    Hard disk files that are specified as a secondary hard disk as master and slave are not recognized by the system.


    I only use 4 GB hard disk files. As a master on the primary hard disk I set up AmigaOS 3.2, as a slave a hard disk file as storage. That’s going great.


    But if I use the hard disk files HDD3.hdf and HDD4.hdf as master and slave as secondary hard disks, they are not displayed on the Workbench.

    If I alternately use HDD3.hdf and HDD4.hdf as slave as primary hard disk, they are displayed correctly. So the hard disk files are OK. There must be a problem with the secondary hard disk in the MinimigAGA Core ... at least that's what I suspect.


    Cheers

    SID-6581

  • Do you have AtapiMagic or IDEFix installed?

    By default OS3.2 doesn't enable the second channel, for stability reasons - the AtapiMagic module (downloadable from Aminet) is the easiest way to enable it.

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