MiSTer FPGA Forum

Typically the analog out port can display "normal" Amiga video (OCS/ECS...) while HDMI will display the RTG output.

“Typically” on real Amiga, yes, but this is MiSTer, it already displays native modes on HDMI, and the analogue port seems to mirror what’s on the HDMI, so I suspect it’s not possible to seperate them.

Thanks for the useful info, Sorgelig and Grabulosaure.

kolla wrote: ↑Fri Jul 31, 2020 10:47 am “Typically” on real Amiga, yes, but this is MiSTer, it already displays native modes on HDMI, and the analogue port seems to mirror what’s on the HDMI, so I suspect it’s not possible to seperate them.

I get the impression that it's the other way around - the HDMI normally mirrors what's on the analogue port, but doesn't have to - for RTG mode it can be made to display something different instead.

kolla wrote: ↑Thu Jul 30, 2020 1:04 pm Is it at all possible to simultaneously have different outputs on the HDMI and the IO-board analogue port, or are they very much linked together?

Although I'm sporting a monitor that can take 15kHz on the VGA, and does auto-switching between these inputs (Acer G276HL Kbix). Having additional options is always pretty cool.
In most cases, you end up with one of these screens displaying nothing but the static. I would imagine that the most people using de10-nano are either plugging a modern HDMI monitor or CRT for the VGA (if they have the analog IO board).

Though, you can't expand out the WB over two screens, like in windows. You can however run one program on screen1 and second program on screen 2 at the same time.

SpringMaus is a small utility for using 2 monitors with AmigaOS
http://www.steamdraw.homepage.t-online.de/

In Russia we call it as "Splitting the skin of not yet killed bear."

Sorgelig wrote: ↑Mon Aug 03, 2020 4:43 am In Russia we call it as "Splitting the skin of not yet killed bear."

Similar in France: "Selling the bear skin before it was killed"

Sorgelig wrote: ↑Mon Aug 03, 2020 4:43 am In Russia we call it as "Splitting the skin of not yet killed bear."

We (Norway) say "selling the skin before the bear is shot", and from experience, this is the business model of many IT companies

Anyways, was just curious. Back in the days of CBM, this was how RTG was done on Amiga with EGS - you run most regular software on native RGB and dedicated EGS software on the graphics card output - two monitors required. On my A3000 I even had three monitors - native rgb, CVPPC and CV64, all working just fine (CyberGraphX 4) - and no garbled output on any, there are switches (env vars) that tell the RTG to keep all screens active and clear.

EDIT: Someone made youtube video presenting EGS - https://youtu.be/kFHdxdG2Hyc

If CMB/Amiga had not folded, EGS would probably have been the standard "classic" Amiga would have taken for graphics, I remember lots of discussions regarding "workbench emulation" with EGS - the "current" RTGs came years later, CyberGraphX in 1995 and Picasso96 in 1996, long after CBM was gone

I would personally love to see RTG added to the MiniMig core so that my newer ports could be playable on the MiSTer (which I have just brought ).

I just released a special build of ZDOOM AGA with 030 support that I hope is playable on the current MiniMig core. I can easily recompile more current RTG 060 ports for 030 if we can get RTG support.

Are there any plans to further enhance the speed of the current 020 MiniMig core, add FPU support or to maybe expand it with basic 040/060 support?

Strictly speaking, Minimig is the chipset and the CPU cores are Fx68k for 68000 and TG68 for 020. For discussions regarding the CPU cores, there are threads over at atari-forum.com

What has been discussed here is so called “hybrid emulation”, using software CPU, emulated 68k on the ARM CPU, along with chipset on FPGA.

Hi Kolla,

Long time, no see

Yes that makes sense re the 'hybrid emulation' it has also been discussed on the Amiga forums (using something like a Raspberry Pi Zero + FPGA to simulate a real 68K CPU).

I'd love to see RTG resolution desktops at the high bit depths. I wouldn't really care on the technical details of how they are acheived but I wouldn't want to resort to UAE. If I wanted that I'd just use my main PC.

One probably very minor request. Should (for example) a resolution such as 1280x720 be implemented (at a decent colour depth and speed), would it be possible to have an additional menu option for 'Auto' screen ratio? At the moment if I'm in 720p 16:9 for my workbench I need to set 16:9 but then I start a game, the res switches to PAL and everything is stretched so I have to change to 4:3. If it's remotely possible 'Auto' would be perfect for aspect ratio.

Other than that, I leave you to it

Oh, to answer the original question, I'd offer some donation but that discussion seemed to go by the wayside I think!

So, any news for the RTG part?

I think the voices of those that would like to see it were largely drowned out by those that couldn't see the point. I'd very much like to see it but am not capable of doing so myself (like 99% of us)

guddler wrote: ↑Thu Aug 20, 2020 7:32 pm I think the voices of those that would like to see it were largely drowned out by those that couldn't see the point. I'd very much like to see it but am not capable of doing so myself (like 99% of us)

Since this has got a bit confusing, here's the "Story So Far"...

I've got a basic RTG system working on the Turbo Chameleon 64's Minimig core - basic because the FPGA on that platform is nearly full, so it's been an exercise in frugality where logic is concerned.

Building upon that work to create a better RTG system for MiSTer should be fairly straightforward. I don't, as yet have a MiSTer, however.

In the meantime, Mahen mentioned that someone else is planning to implement RTG, but didn't say who. This person was probably Chaos, who said he planned to implement it if no-one beat him to it, but he wanted to work on the ARM-based CPU emulation first. (I suppose there's just an outside chance that Mahen meant someone else, and that there's actually three of us with RTG on our radar!)

I was very kindly offered a MiSTer so that I could work on this. I haven't heard otherwise, so I'm assuming that's still happening - but I haven't heard anything on the subject for a few weeks. I haven't chased it up, since chasing up a freebie would be rude, and in these covid-complicated times I'm not looking to add to anyone's stress.

So that's where things stand right now. No need to worry about the idea being derailed by people who can't see the point of it - if that mattered, no niche project would ever happen! If and when I have the necessary hardware I'll put some time into implementing an RTG framebuffer for the MiSTer's Minimig core, and write the necessary P96 driver for it. If, on the other hand, someone more familiar with the MiSTer is already working on it, I'll happily defer to them.

Thats really cool to hear!

Where in the world are you? PM / DM if you don't want to say publicly. If it's anywhere near SW England then my MiSTer is not doing a huge amount right now as our house is on the market so it's all about keeping things as tidy as possible.

Just saying in case you end up stuck. I'd prefer if it was drivable rather than shipping though.

@robinsonb5: Yep I was Indeed referring to Chaos !

@robinsonb5 Definitely let us know where you live in the world, and we’ll find out how to best get you a DE-10 Nano — feel free to DM me

Thanks everyone - I'm in Norfolk, in the UK.

Probably best if I give "plan A" another week or so then chase it up - if it turns out to be a dead end we'll explore other options at that point?

Sounds good, just let us know

robinsonb5 wrote: ↑Thu Aug 20, 2020 9:58 pm In the meantime, Mahen mentioned that someone else is planning to implement RTG, but didn't say who.

Hey robinsonb5,

yes, I planned to work on the RTG, but at the time I didn't know you were already working on it. There's really no point both of us doing it, plus I would really love to try the 68k CPU emulation on ARM.

I already have the DE10 nano (thanks mahen!), still waiting on the other MiSTer parts to arrive. In the meantime, I can already play with the linux side and test some things out

Hopefully you will get the RTG working soon, it will really expand the possibilities of minimig!

chaos wrote: ↑Fri Aug 21, 2020 6:07 pm

robinsonb5 wrote: ↑Thu Aug 20, 2020 9:58 pm In the meantime, Mahen mentioned that someone else is planning to implement RTG, but didn't say who.

Hey robinsonb5,

yes, I planned to work on the RTG, but at the time I didn't know you were already working on it. There's really no point both of us doing it, plus I would really love to try the 68k CPU emulation on ARM.

I already have the DE10 nano (thanks mahen!), still waiting on the other MiSTer parts to arrive. In the meantime, I can already play with the linux side and test some things out

Hopefully you will get the RTG working soon, it will really expand the possibilities of minimig!

When we're talking 68k, are we including 68040 and 68060 (so with MMU/FPU) or just offloading 68000/68020 to the ARM CPU?

Fularu wrote: ↑Fri Aug 21, 2020 7:46 pm When we're talking 68k, are we including 68040 and 68060 (so with MMU/FPU) or just offloading 68000/68020 to the ARM CPU?

Well, I am aiming for the whole shebang - 68040 / 060 + MMU & FPU

chaos wrote: ↑Fri Aug 21, 2020 8:03 pm

Fularu wrote: ↑Fri Aug 21, 2020 7:46 pm When we're talking 68k, are we including 68040 and 68060 (so with MMU/FPU) or just offloading 68000/68020 to the ARM CPU?

Well, I am aiming for the whole shebang - 68040 / 060 + MMU & FPU

CPU on the ARM with custom chips and RTG on the FPGA seems like the best approach for a very faithful Amiga recreation. Sounds super promising and would probably mean retiring my A500/2000/1200 (the 1000 is already boxed up)

I would probably even make a dedicated Amiga MiSTer setup for that sole purpose!

Hi ! Sounds great Indeed !!! The current 020 implementation is not cycle-exact anyway. My only fear is the risk of bringing the ARM down ! ATM when copying files or making other i/o intensive tasks on the Minimig, the OSD and mouse are frozen.

Maybe it's due to priorities handling / the fact I enabled 1000 Hz polling ? I'm kinda worried a software cpu could raise input lag too ?

Cheers !!

I'd definitely need to house my MiSTer in that old A600 if this comes to fruition. I was actually on the list for a Vampire 600 but opted to get the MiSTer instead. If high end Amiga's can be implemented then literally everything I wish for would be available in a single device.

C64 & Amiga are joint No 1 priorities for me, of all the 30+ systems I've owned & used, they still sit sit at the top of the tree. I'd consider donating to this project if I'm able to.

My first computer was the C64 & my 2nd was an A1200. I was incredibly lucky to grow up using these two amazing machines.

ZigZag wrote: ↑Sat Aug 22, 2020 8:36 am I'd definitely need to house my MiSTer in that old A600 if this comes to fruition. I was actually on the list for a Vampire 600 but opted to get the MiSTer instead. If high end Amiga's can be implemented then literally everything I wish for would be available in a single device.

C64 & Amiga are joint No 1 priorities for me, of all the 30+ systems I've owned & used, they still sit sit at the top of the tree. I'd consider donating to this project if I'm able to.

My first computer was the C64 & my 2nd was an A1200. I was incredibly lucky to grow up using these two amazing machines.

I own both, a Vampire (installed in an Amiga 2000) and a Mister, from my point of view you did a very good choice. Especially if you want to do what you did back in the day and not trying to run doom on an Amiga (which for me is a nonsense) . Since I have the Mister, I do not use anymore my Vampire even if the Vampire is much faster at the day of today compared to the Amiga core of the Mister, the Mister corresponds much more to what I need. It is an incredible hardware where we do have to thank all the guys working hard for us in order to bring to life the computers that we owned back in the day or that we always dreamed to own.

kathleen wrote: ↑Sat Aug 22, 2020 8:55 am

ZigZag wrote: ↑Sat Aug 22, 2020 8:36 am I'd definitely need to house my MiSTer in that old A600 if this comes to fruition. I was actually on the list for a Vampire 600 but opted to get the MiSTer instead. If high end Amiga's can be implemented then literally everything I wish for would be available in a single device.

C64 & Amiga are joint No 1 priorities for me, of all the 30+ systems I've owned & used, they still sit sit at the top of the tree. I'd consider donating to this project if I'm able to.

My first computer was the C64 & my 2nd was an A1200. I was incredibly lucky to grow up using these two amazing machines.

I own both, a Vampire (installed in an Amiga 2000) and a Mister, from my point of view you did a very good choice. Especially if you want to do what you did back in the day and not trying to run doom on an Amiga (which for me is a nonsense) . Since I have the Mister, I do not use anymore my Vampire even if the Vampire is much faster at the day of today compared to the Amiga core of the Mister, the Mister corresponds much more to what I need. It is an incredible hardware where we do have to thank all the guys working hard for us in order to bring to life the computers that we owned back in the day or that we always dreamed to own.

While I dont want to over simplify, the best way to put the Mister vs Vampire is like this, the Mister is for recreating the past very well, the Vampire is for the what-if future of the Amiga that never sorta really happened but should have/tricked out maxed fantasy 060 class Amiga you never owned but always wanted .. so if you are looking to stick with a good recreation of the past, and only the pasts "stock or near stock/factory machines", the Mister nails it, if you are looking for more a high end "future" "what if" 68k machine then the Vampire is a better option (like Kathleen, I own a V500 v2+ and a V4SA as well as a Mister (and a mist) .. and also an Ultimate 64 .. along with several real machines and Pi setups ) .. they all do things well and they each fill certain unique niches .. I dont see them as mutually exclusive but covering different aspects and doing their special focus well.

Fularu wrote: ↑Fri Aug 21, 2020 9:12 pm CPU on the ARM with custom chips and RTG on the FPGA seems

RTG is not something that is "on the FPGA" - RTG is SOFTWARE (like P96 and CyberGraphX, with their drivers) and as such runs on the CPU (wherever it is) - that is the entire point of RTG. The question is whether RTG driver should use FPGA to render the display or if it should just let the ARM do it. If the "CPU" is already on the ARM (emulated), does it even make sense to _not_ use the ARM also for rendering the display, uaegfx.card style? And if the FPGA is to be used, does it make most sense to implement a "zorro graphics card" on the FPGA, or to extend the existing Amiga chipset with chunky modes (like SAGA does on Vampire V4), or perhaps something else (like "SAGA" on Vampire V2 - an address space mapped by P96 driver, directly accessible from CPU, no Zorro... but how do you do that if CPU is on ARM - oh no, meh!)

Well, there can be several implementations with different methods and goals

(and there could also be a MiSTer specific UAE that uses the MiSTer framework as setup frontend)

I was not intending to suggest Vampire & MiSTer are exactly comparable devices, just that having to chose one or the other (due to cost) I was personally delighted I'd chosen MiSTer.

I was expressing delight that the full potential of the DE10 Nano may be harnessed, CPU & FPGA combined, and a new, upgraded Amiga implementation could be available to us.

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'd personally use both a fully FPGA, basic Amiga setup & an expanded Amiga with emulated components for more advanced stuff. To have both options available in a single bit of hardware saves money & space. It'd also attract a lot of interest in the capabilities & potential of MiSTer hardware & expand it's user base. That cannot be a bad thing.

kolla wrote: ↑Sun Aug 23, 2020 6:18 am RTG is not something that is "on the FPGA" - RTG is SOFTWARE (like P96 and CyberGraphX, with their drivers) and as such runs on the CPU (wherever it is) - that is the entire point of RTG.

While you're absolutely right about that, when people talk about RTG on an FPGA device what they usually mean is the combination of some of kind of virtual graphics card on the FPGA and the software that drives it.

The question is whether RTG driver should use FPGA to render the display or if it should just let the ARM do it. If the "CPU" is already on the ARM (emulated), does it even make sense to _not_ use the ARM also for rendering the display, uaegfx.card style?

Depends what you mean by "rendering" - it might be possible to let the ARM do some kind of graphics card blitter, with the CPU coordinating it - but it would all still need to go through some kind of virtual hardware register, be it a chipset extension or a virtual Zorro card.

And if the FPGA is to be used, does it make most sense to implement a "zorro graphics card" on the FPGA, or to extend the existing Amiga chipset with chunky modes (like SAGA does on Vampire V4), or perhaps something else (like "SAGA" on Vampire V2 - an address space mapped by P96 driver, directly accessible from CPU, no Zorro... but how do you do that if CPU is on ARM - oh no, meh!)

What I did with the Chameleon64 was to add some new hardware registers beyond the normal Akiko registers, since I was already decoding that range for C2P.