Today the most common mode to emulate a classic Amiga is use UAE in different flavors like WinUAE, FS-UAE, etc..
It's ok but, maybe, could be at least another way to got a virtual Amiga classic board, using QEMU https://www.qemu.org/.

We can already emulate, in a very good way, an AmigaNG system like a Sam460ex wirh OS4 or a Mac99 machine with MorphOS.
But if I want to go with a classic m68k board like n A500 ..simply I can't
Sadly no one have still build a virtual board tu run AmigaOS 3.x under QEMU and I don't know if it's possible.

..So why QEMU?
QEMU project is maintained in a really good way by a lot of developers and it's opensource.
It's also compatible with most common OS like Linux, MacOS and Windows and can emulate (and virtualize) a lot of different boards and cpus, from 8bit to most recent 64bit ones.

I think it could be an excellent solution, so why not?

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

UAE works well enough for classic Amiga hardware, and QEMU has to support all kinds of platforms already. It's probably a better use of QEMU developer time if it only deals with NG hardware emulation and leaves classic hardware to UAE.

Qemu already emulates 68k systems, and it's great for example for Linux/m68k, NetBSD/68k etc - operating systems that don't really use the Amiga chipset or the myrads of special Amiga hardware that the various UAE incarnations emulate. I suspect that a lot of the 68k CPU emulation in Qemu actually comes from UAE... like it does in Aranym and various other 68k emulators.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I’m not sure but probably not.
It should be a completely new engine based on QEMU TCG.
In these days some developers are building a new Mac quadra 800 virtual board.
I hope something like this could be done to emulate an A4000 with 68060.

Last edited by Fl@sh on 03-Jan-2020 at 02:37 PM.
Last edited by Fl@sh on 03-Jan-2020 at 02:36 PM.
Last edited by Fl@sh on 03-Jan-2020 at 02:34 PM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

Quote:

I think it could be an excellent solution, so why not?

Because UAE is better for anything Amiga related (including OS4 emulation).

@pavlor

MorphOS has OS4 emulation.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla


Not exactly, it does really emulate OS4, it’s just an incomplete wrapper.

Ever tried Wine on Linux it stinks.

Last edited by NutsAboutAmiga on 03-Jan-2020 at 07:01 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Swooosh... that was the point flying over your head.

Wine is not an emulator, and UAE does not emulate OS4, it emulates Amiga hardware.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Fl@sh: Nice idea, but why? WinUAE and E-UEA are really nearly perfect on the emulator-front, there are FPGA-boards like Vampire, MiST etc., who are a good replacement to original 68k-Amigas and there ist really good emulation for 68k-software (without Amiga-chipset) in AOS4 and MOS.

For me a perfect AOS4-Virtual-machine on PPC-Macs would be more interesting. But this is far from perfection, so I go for Tabor (for anything else I have FlowerPot and WinUAE/AOS4-Classic on my MacBookPro)

Last edited by AP on 03-Jan-2020 at 09:03 PM.

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

@Fl@sh

It depends how far you want the emulation to go. Up to OS3.x level or A500 hardware level?

For OS level QEMU would need to watch for Amiga specific hardware locations and ignore them. It would need some patching to work. I don't know if a custom ROM would need to be built that hits the hardware as less as possible. Such an emulator setup would work very similar to how Amithlon did.

For full A500 hardware level I woud say, even without being an expert on the topic, that QEMU would be unsuitable for the job. To emulate a Sam460ex, for example, it would have custom hardware in the memory map it would need to emulate. But for an A500, given all that needs to be emulated, UAE is more than suitable for the job. Also, as an A500 has a 68000 in the usual configuration, speed ups using JIT woudln't be suitable. Since, being without a cache, emulating a 68000 in a static emulator would be a better match. Especially for timing. Unless you had a 68020 or 68030 CPU in mind.

What would be the benefit?

Winuae is maintained by the guy that knows more about amiga hardware than anyone else, and that gets ported into fuse for unix platforms. Who can do better?

Now, if use were ported into qemu, and the winuae guy moved his work there, that could be something. But if not, then it would just be some fun project for someone wanting to build amiga into qemu, but not likely superior result to winuae...

Would be nice to get update to PPC chunk of winuae, I understand that is hard to do by someone that tried.

_________________
All glory to the Hypnotoad!

I hope people do know that the PPC plugin for WinUAE and FS-UAE actually *is* Qemu?? Or did that too fly above peoples’ heads?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

With QEMU you can build a virtual board and let it be exactly like an A500 or A4000, mapping any chip present on real hardware via software.
As I said some guys are making a Mac quadra board, but a lot of other esoteric boards with many different cpu are already done and fully (or even partially) working.
As example a very common solution under QEMU is using a Q35 chipset to emulate or virtualise a pc with Linux or windows os.
The Q35 chipset is quite complex but all it’s working as on real pc and a lot of virtual servers are running in this way.
With QEMU you can build a virtual version of many boards and also build a non real one, just to experiment or have fun.
A lot of cpus are well emulated, i.e. from x86 to mips, ppc, arm and others, but also m68k.
So a great and very complex part of work is already done.

As Amiga like system we have already a sam460ex partially emulated with sm501 gfx chip.
It’s working and os4 runs quite well on a recent pc.
Zoltan Balaton is working also on a peg 2 virtual board and ati gfx card, it’s all a work in progress and for now he was able to boot into bios.

So if some other Amiga guy want try to help could be really great.

Last edited by Fl@sh on 06-Jan-2020 at 10:24 AM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

WinUAE is open source, why not try importing source code of chipset emulation (and any other Amiga hardware you wish) from there?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Completely different software I don’t think we can grab any source from uae and put it inside qemu.
Lukly Amiga chipset ecs and aga are really well known so both could be implemented in qemu from scratch.
there’s room to add also rtg inside zorro space, some gfx chipsets used in Amiga rtg cards are already supported, i.e. cirrus, permedia, and others too.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

Okay I can see what you are saying. So QEMU can offer features that UAE doesn't?

I don't know exactly how QEMU handles hardware emulation. This tends to be the slowest part in computer emulation. Having learnt about it myself, emulating CPU instructions can be broken down into little steps where code simulates the instruction, leaving the result in a virtual register or memory. Instruction codes themselves masked off and used in jump tables for speed. In the simplest case, nothing would change and it would go to the next code; in a more complex case, the simulator would read in more data in and write the results out.

The emulation of code, compared to hardware, can be thought of as rather trivial. Even with CPU clock timings, that need to be taken into account per instruction, the emulation can keep count. With hardware, it is more complex. Generally hardware is memory mapped. So when the emulation reads or writes to memory, it can't simply do it in emulated memory space, because it could be RAM or it could be other hardware. It usually handles this by going through a hook. The hook will check the location to see if it's RAM or a hardware location. This is where it gets complex. The hardware location could be transparent and be readable and writeable. But regardless, the operation must be simulated, to what the hardware would have done when accessed. And it might need to do a lot and check a few things to put a process into motion.

A lot of emulators were line emulators. They calculated the number of CPU clocks per one screen line. Then they would emulate one line of screen, render the graphics to the host, then move onto the next. Sound would also be handled in a similar way with a sound buffer mixed down. I don't know how QEMU deals with this kind of thing. It may work without such restrictions. But intergrating an Amiga core into it would need to be aware of how to simulate the complex hardware.