Amiga RTG support (Update: Released!)

[robinsonb5]

To those distressed by the concept of utilising the ARM CPU to expand a virtual Amiga's functionality, MiSTer's ability to recreate hardware in FPGA is superb, and there's no reason a faithful, original specs Amiga in pure FPGA can't coexist with one which expands possibilities & functionality using the ARM CPU. Why impose unnecessary restrictions on developers? If you don't personally want to use some features because they are not "pure FPGA" no one will hold that against you. Developers are free to develop as they wish, and you can use your MiSTer in any way you want.

I think the concern here isn't about "purity" as such, more that there are already situations where input responsiveness (which is one of the Amiga's defining characteristics) is slightly compromised - such as during disk access. This is certainly noticeable If I do a side-by-side comparison between TC64 Minimig (which has PS/2 mouse decoded in the FPGA) and MiST (which has USB mouse handled by ARM and sent over SPI to the FPGA).

I don't imagine it will be an insurmountable problem, but certainly something to keep in mind as more facilities are handed off to the ARM.

[chaos]

Maybe if disk speed is of concern, a better option would be to implement direct SD card access in the FPGA. Actually, that is something I'll put on my TODO list ...

[guddler]

Nice to see discussions on this topic. At the end of the day, I’m not averse to whatever works best and feels right. All I know is to date every emulated experience I’ve tried so far doesn’t quite feel right. I suspect down to increased latency but I’ve never been able to exactly put my finger on what’s up. If handing off various tasks to Arm works and feels right then great

[limi]

Maybe if disk speed is of concern, a better option would be to implement direct SD card access in the FPGA. Actually, that is something I'll put on my TODO list ...

Let’s move that part of the discussion to viewtopic.php?f=4&t=410&p=8927#p8927?

[mahen]

@Chaos : the problem is not really the disk accesses being slow, but the mouse / keyboard / joystick USB input being frozen / slowed down when there is a significant disk access actually. This is bound to occur the ARM is responsible for another CPU intensive task I guess ?

I guess it doesn't happen when using I/O boards with db9 ports.

Cheers !

[chaos]

I haven't looked into how the ARM <-> FPGA communication is implemented in MiSTer, so I can only speculate what might the problem be. Linux in general does offer many options to tune CPU and IO usage, so that is something that could be looked at.

Moving the CPU to ARM, which handles reading the SD card, could actually prove beneficial, as there would be less need to transfer IDE data from ARM to FPGA.

But an even better option would probably be to use the secondary SD card, and either add a small CPU in the FPGA to handle it, or even better, implement raw direct access to SDcard, that is, implement an IDE to SD card converter.

And there's still the option of writing a DMA IDE driver and implementing a DMA capable SD card interface.

Just some thoughts, but something that I''ll look into in the future.

[Lisko]

I haven't looked into how the ARM <-> FPGA communication is implemented in MiSTer, so I can only speculate what might the problem be. Linux in general does offer many options to tune CPU and IO usage, so that is something that could be looked at.

Moving the CPU to ARM, which handles reading the SD card, could actually prove beneficial, as there would be less need to transfer IDE data from ARM to FPGA.

But an even better option would probably be to use the secondary SD card, and either add a small CPU in the FPGA to handle it, or even better, implement raw direct access to SDcard, that is, implement an IDE to SD card converter.

And there's still the option of writing a DMA IDE driver and implementing a DMA capable SD card interface.

Just some thoughts, but something that I''ll look into in the future.

For all of us big amiga fans, this would be the best option and will retain the system snappy even in disk intensive operations. One thing I noticed tough is that most of the resources saturation happens during floppy operations, so it's something that should be considered too as an ide2sd wouldn't be sufficient.

[kolla]

Why not go the way of uaehf.device and not use emulated gayle at all?

Or for that matter, now that the "MiSTerFilesystem" exists - make sure it works really well and just use directories on the "Linux side" as partitions on the Amiga side. (This is preferred way with FS-UAE, it keeps all amiga filsystem metadata in .uaem files.)

[kathleen]

I've just tried the new Miniming-RTG beta core for the Mist. After having installed the Picasso96 and applied some required changes, I was able to run the workbench in RTG resolutions, none of the programs I tried worked but this is normal. It is really an early beta version. The good thing is to see that the work is moving forward. Cannot wait to see this new Minimig core mature and also ported to the Mister.

[dhoelzer]

I've just tried the new Miniming-RTG beta core for the Mist. After having installed the Picasso96 and applied some required changes, I was able to run the workbench in RTG resolutions, none of the programs I tried worked but this is normal. It is really an early beta version. The good thing is to see that the work is moving forward. Cannot wait to see this new Minimig core mature and also ported to the Mister.

This is VERY exciting. Thanks for the update!

[limi]

Where can we find (or support) this experimental core?

(Never mind, didn’t see that it was for MiST, not MiSTer. Will stay patient)

[NovaCoder]

Very cool to see!

Hopefully it will be coming to MiSTer soon

[kolla]

none of the programs I tried worked but this is normal.

What programs? Of course a lot of classic software was written for native chipset and will never work well with RTG.

[kathleen]

none of the programs I tried worked but this is normal.

What programs? Of course a lot of classic software was written for native chipset and will never work well with RTG.

I tried Deluxe paint V which did not work and also Abank, I tried a 3rd one but don't remember the name. I was knowing that there was few chances to get them running and it was not the aim of my test, just wanted to at least be sure that the WB was well working in the RTG resolution which is for me already a great step forward. I understood that this is quite challenging with the Mist, but this is a good starting point for the Mist of course but also for the Mister.

[kolla]

Right. DeluxePaint is one of those programs that rely heavily on the chipset. One of the features of DPaint V was RTG support, but mind you - this was 1995, RTG as we know it today was at its infancy, CyberGraphX had just been introduced, P96 still didn't exist, people with graphics cards were more likely to be using "old" RTGs like EGS, Retina etc.

(btw, one thing that doesn't work here, is IBrowse internal image decoders, they draw garbled pixels outside of their frames and most often crash the Workbench process with 8000 0004, even when IBrowse runs on a dedicated screen)

[bbond007]

I tried Deluxe paint V which did not work and also Abank, I tried a 3rd one but don't remember the name. I was knowing that there was few chances to get them running and it was not the aim of my test, just wanted to at least be sure that the WB was well working in the RTG resolution which is for me already a great step forward. I understood that this is quite challenging with the Mist, but this is a good starting point for the Mist of course but also for the Mister.

Right. DeluxePaint is one of those programs that rely heavily on the chipset. One of the features of DPaint V was RTG support, but mind you - this was 1995, RTG as we know it today was at its infancy, CyberGraphX had just been introduced, P96 still didn't exist, people with graphics cards were more likely to be using "old" RTGs like EGS, Retina etc.

Have you tried TV Paint? I agree DpaintV never was a well-behaved RTG app...

https://forum.tvpaint.com/viewtopic.php?t=11

[kathleen]

Thanks to both of you for your comments. No I haven't, It is a good idea, I will try it as soon as I can and will let you know the outcome.

[kathleen]

Have tried TVpaint, but it hangs after start. Actually TVpaint needs an FPU To my recollection there is an FPU emulator for the Amiga, will redo the test later on.

[kolla]

FEMU on MiST sounds painful, hehe

But it can be a great exercise in catching tg68 bugs

[attle]

P96Speed should work well for testing/benchmarking: http://aminet.net/package/util/misc/P96Speed
You can also try PPaint (doesn't require FPU)

[kathleen]

Just a quick feedback, I tried yesterday PPAINT (thanks @attle for the advise) and I got it working in 800/600 in 15 Bit, YES!, It ran as it should, this is already a good news. I'm more mitigate regarding the speed, don't remember how fast a Picasso card worked back in the day, but I think this will be improved once the core will be ported to the Mister (at least I cross my fingers for having this happens)
I tried then P96Speed, the weird thing (maybe this is normal, I do not know) is that I have "No Graphic Card" shown at the screen but anyway I started the whole test and I saw it running, unfortunately I left my place and when I came back, it was the workbench w/o P96speed running. I guess that it hanged and reboot by its own. I'll redo the test this evening and try to catch the issue.

[kolla]

Right, the way this chunky mode framebuffer is implemented on MiST, it is more as an extension of AGA than as a dedicated graphics card

Old picasso cards on zorro2 were also quite slow too btw

Speed on RTG relies a lot on the CPU, because, as I have mentioned numerous times now, RTG is most of all software.

[Sorgelig]

High speed of implemented RAM with cache comes from the fact that mostly it's speed of read. Read is greatly accelerated by cache. When it comes to RTG, it's mostly write which is not accelerated by cache at all. So if RTG is implemented by SDRAM like it's done on MiST, then it should be quite slow. Especially SDRAM is heavily loaded already by rendering and other tasks.
When it comes to MiSTer then it should be much faster if (and it should!) it will be implemented in DDR3. The random writing time to DDR3 is very short. Unless DDR3 controller rises WAIT signal, the write is instant. By using framebuffer mode, additional rendering process will be eliminated as well. Overall performance of RTG on MiSTer should be much better than AGA and mostly limited by CPU speed.

[limi]

Grabulosaure posted a test build with RTG support:

Minimig with RTG support : http://temlib.org/pub/mister/minimig/

Installation procedure : https://www.fpgaarcade.com/kb/how-to-se ... 6-drivers/ Replace "replay" with "minimig".

[uigiflip]

tried few things somethings crash has some rtg things require 040 n 060 with rtg enabled

https://youtu.be/kJ7eRgj7ceg

[uigiflip]

found deluxe paint v crashes when try to open in a rtg mode also iv and 5.2

[schroediman]

Wow. That's really great for an initial test build .
PerfectPaint works (as long as I don't try to load a jpeg) and FinalWriter seems ok, too.
At least in 800x600 8bit. I'll play with it a bit more during the next days.
Is it possible to use non 4x3 resolutions, too ? Linke 1920x1080 ?
Thanks !

[kolla]

found deluxe paint v crashes when try to open in a rtg mode also iv and 5.2

This is quite normal - DPaint5 predates P96 and CGfX3, was put together in a hurry and is quite buggy all over. DPaint4.6 on AGA is the most rock solid combination.

It would be amazing if Electronic Arts still had sources for DPaintV and could make them available, so proper RTG support could be fixed.

[kolla]

I think the concern here isn't about "purity" as such, more that there are already situations where input responsiveness (which is one of the Amiga's defining characteristics) is slightly compromised - such as during disk access.
I don't imagine it will be an insurmountable problem, but certainly something to keep in mind as more facilities are handed off to the ARM.

My “concern” (not really) is that as more and more is handed off to the ARM... why not just go all the way, and run FS-UAE on the ARM? That would give RTG, fast CPU, fast I/O etc that people want, right?

[rhester72]

I think the concern here isn't about "purity" as such, more that there are already situations where input responsiveness (which is one of the Amiga's defining characteristics) is slightly compromised - such as during disk access.
I don't imagine it will be an insurmountable problem, but certainly something to keep in mind as more facilities are handed off to the ARM.

My “concern” (not really) is that as more and more is handed off to the ARM... why not just go all the way, and run FS-UAE on the ARM? That would give RTG, fast CPU, fast I/O etc that people want, right?

Oh dear word no. The ARM side is nowhere near fast enough to provide satisfaction. It MIGHT be enough for the 020 core itself, but certainly not for the custom chipset or beyond. It wouldn't even handle AGA.