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.
  • Hello friends,

    with great pleasure I installed the new MinimigAGACore on my TC64V1.

    The Core has recently added RTG support and is known to be available for download here: http://retroramblings.net/?page_id=1422


    Thank you very much Alastair Robinson!!!


    The P96 driver V2.4.6 is installed on my 4GB AmigaOS 3.1.4.1 HDF file.

    Alastair Robinson has kindly added a P96 configuration file in which the common screen resolutions can be found. Everything is going fine so far.


    But I still miss the NTSC / PAL resolutions 320x200, 320x256, 640x400 and 640x512. I would like to use this to open images in my graphics programs (without interlace flicker).


    Has anyone managed to implement such resolutions? My own attempts have so far failed to produce an image that is in the middle and without cut edges.


    Cheers

    SID-6581

  • 640x400 should be do-able (in a form that relatively modern monitors can tolerate) since it's a standard VGA resolution - the others might be trickier. 640x512 is easy enough to define, but being a non-standard mode, a modern LCD monitor will likely misidentify it and give poor results.


    The problem with 320x200 and 320x256 is that I don't currently have any kind of line doubling for the RTG output - it just spews out the contents of a flat framebuffer in strictly sequential order, so it's not capable of repeating lines.

    This means that, while you can define a 320x200 resolution, the refresh rate ends up being crazy fast and the monitor won't accept it.


    In the longer term I may be able to persuade the existing scandoubler into operating on RTG modes as well as Amiga modes, which would solve the problem.

  • Thanks Alastair for the technical background information. I don't know to what extent an FPGA is comparable to an emulator in this respect, but "amiberry" for the Raspberry Pi solved the problem quite well. Therefore I suspect that there could be a software solution.


    Cheers

    SID-6581

  • The problem with 320x200 and 320x256 is that I don't currently have any kind of line doubling for the RTG output

    Just a practical suggestion: Introduce another counter-bit below the currelt LSB of the line counter. Keep that at "always 1" for standard operation, and make it count for line-doubling. A simple threshold of "number of lines" switches between the modes (or you make it software-settable, whatever is smaller).


    If you are really just working with an up-counter for the memory address, it's of course more complicated, as you need to introduce modulos for going from one line to the next, requiring a full-adder. The module doesn't have to implemented in a single cycle; if you have trouble meeting timing, you can always pipeline the calculation, as you have plenty of time during the blanking periods to count bit-by-bit instead of doing a full adder.

  • If you are really just working with an up-counter for the memory address, it's of course more complicated, as you need to introduce modulos for going from one line to the next, requiring a full-adder. The module doesn't have to implemented in a single cycle; if you have trouble meeting timing, you can always pipeline the calculation, as you have plenty of time during the blanking periods to count bit-by-bit instead of doing a full adder.

    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 the technical background information. I don't know to what extent an FPGA is comparable to an emulator in this respect, but "amiberry" for the Raspberry Pi solved the problem quite well. Therefore I suspect that there could be a software solution.

    Without looking at it I can't be sure, but I'd imagine they put the Amiga's screen either on a texture and let the GPU scale it, or used a video overlay (if the GPU supports RGB overlays), again letting the PI's hardware deal with the scaling.


    Edit: I've just tried to create a 640x400 screenmode, and my monitor refuses to identify it as such - it's detected as either 720x400 or 640x350. The picture's there but the quality's poor because the monitor's expecting the wrong number of pixels. Your monitor might play nicer with this resolution than mine, though. Specs here: http://tinyvga.com/vga-timing/640x400@70Hz

    Watch out for sync polarity - this mode should have negative hsync, positive vsync.

  • Edit: I've just tried to create a 640x400 screenmode, and my monitor refuses to identify it as such - it's detected as either 720x400 or 640x350. The picture's there but the quality's poor because the monitor's expecting the wrong number of pixels. Your monitor might play nicer with this resolution than mine, though. Specs here: http://tinyvga.com/vga-timing/640x400@70Hz

    Watch out for sync polarity - this mode should have negative hsync, positive vsync.


    Thanks for the hint. I was able to successfully realize the screen resolution 640x400 with the following data:




    Only missing 320x200, 640x512 and 320x256. ;-)


    Cheers

    SID-6581

  • Thanks for the hint. I was able to successfully realize the screen resolution 640x400 with the following data

    Nice!

    So if both those timings work fine on your monitor, you may as well use the 15-bit timings for 8-bit too - since they make slightly lighter demands of the SDRAM, leaving it clearer for the CPU.

  • Nice!

    So if both those timings work fine on your monitor, you may as well use the 15-bit timings for 8-bit too - since they make slightly lighter

    OK, I tried that. Although the test picture is without flaws, a 640x400 picture opened in PPaint is then displayed vertically shifted. Strange! I have therefore returned to the previous values.

  • OK, I tried that. Although the test picture is without flaws, a 640x400 picture opened in PPaint is then displayed vertically shifted. Strange! I have therefore returned to the previous values.

    Yeah, very strange! You did change the pixel clock to match? Anyhow, if what you're using works, that's fine - hopefully I'll be able to address the other issues in due course.

  • Yeah, very strange! You did change the pixel clock to match? Anyhow, if what you're using works, that's fine - hopefully I'll be able to address the other issues in due course.

    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.

  • "version intuition.library" results in "intuition.library 40.87".

    In addition, I inform you that I am using Kickstartrom 3.1.4 for the Amiga 1200.

    Does not compute. The intuition library you're quoting is from Kick/WB 3.1, but you claim to ahve 3.1.4 installed? This sounds like a mix of versions, which is just asking for trouble.

  • I read the version with DirectoryOpus. There I clicked "Read". Many illegible symbols are then read out, but also "intuition.library intuition 45.13 (3.11.2018)". Why is that different than the version command issues ??? I also have both the intuition.library and the intuition-v45.library in the "libs" folder.

  • Why is that different than the version command issues ?

    THis is going beyond normal customer support - your installation is obviously a mix of different versions that you may need to clean up. I don't know if this really causes a problem, as the P96 update was made when intuition.library V46 was released, but since PPaint may trigger a similar bug, I believe it's a good idea to keep everything up to date before you report any bug. There's lots of development going on in the Amiga community, and I'm happy to relay a proper bug report, but we should keep other sources of trouble out of the equation before we waste the valuable time of a developer.

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