qemu emualtion of AmigaONE XE

@Maijestro

small video
amigaONE started with 2gb
only with the boot cd-rom
and starting "Ranger"

I wanted to ask do I need to boot from hard-disk
is there any trick to do as for pegasos2 ?

Thank you

I'm sorry but time passes and I'm a bit lazy I don't do it on purpose
it's just the age

and thanks also to @balaton for this experiment he wanted to do.

https://youtu.be/X5APihbAVDc

@Maijestro

ok i read the thread,
I tried a little bit of everything and the speed is good
I'll make a video later

it is essential to find a way to do a hard reset of the machine
to work well.

HERE QUAKE TEST TIMEDEMO MODE
https://youtu.be/majQUP6jXPM


the test was done with the old one
siliconmotion502.chip

current tests with rtl8139 lose connection
very often as reported by @Maijestro

currently the system is complete in all its parts and sfs latest version is used.

I hope it can be useful and share the various configurations to use.
They are just tests, which I hope will help in some way.

As soon as possible I'll make a more complete video of the whole system.
As soon as I configure all the programs.

@Maijestro
I sent a PM

@whiteQuote:

Thanks for the video it seems to run well on your machine too.

Maybe in the future the sound and network problems will be solved.

Since you can not save boot settings in the firmware, NVRAM would of course be advantageous.

And finally of course 32 bit output borvorzugt 3D accelerated. Then we would have a perfect Qemu AmigaOs4.1 machine, but I'm dreaming again

@Maijestro

Yes you are right,
There have been many steps forward in emulation.

You can do many things with the current emulation is already a good result.

Too bad about the policies applied by hardware developers in general.
A change of course would be nice especially on hardware prices.

A question
Do you think it's possible OS 3.9 (ppc) with AmigaONE ?
Have you tried it had crossed my mind just out of curiosity to give it a try.

But I probably don't think it's possible.


What are your opinions about 3.9 on AmigaONE ?

@white
Quote:AmigaOS 3.9 is m68k, not PPC, but running it inside UAE on AmigaOS 4.x (or on any other system with an UAE port) is possible.
Downgrading to the illegal AmigaOS 3.1.x/3.2.x versions doesn't help, they are m68k only as well, and much worse than AmigaOS 3.9 was.

@joerg

I don't really want to get into this topic, because almost everything is "illegal" with them, someone must have commissioned Hyperion-Entertainment to distribute AmigaOs4.1, AmigaOs3.1.x, I don't have the knowledge how they have it, but as far as I know there is probably no other way to be able to develop AmigaOs in any form, because AmigaOs is not OpenSource like e.g. MorphOs, where it seems to run a bit better because of that.

I keep neutral to everything and of course I am happy to be able to use AmigaOs4.1 in some form at all. There were just too many disputes in the past years. We should be glad that the development continues, even if quite slowly.

I also appreciate their knowledge as they often helped with problems. We should end this topic, it's really not good.

@joerg
@Maijestro

My question was harmless just out of curiosity.
I have yet to have somewhere in the external hd "moana loader"
As well as amithlon is everything else.

I don't know the architecture well as I said before
Many years ago I chose the "ps1" instead of "ppc+voodoo"
And since then I have only emulated AmigaOS
I remember using winUAE 0.8xx with a GPRS phone to connect to the internet

@Maijestro
Quote:Hyperion has (or had) a licence from Amiga Inc. for developing AmigaOS 4.x on PPC systems, but limited to classic Amigas and "AmigaOne" NG systems.
Hyperion has (or had) a licence from Amiga Inc. for using AmigaOS 3.1 (and older versions), but limited to the unmodified Kickstart and Workbench image/ADF files for the UAE included in AmigaOS 4.x.

Hyperion never had any licence to use the AmigaOS sources for updated AmigaOS 3.1/m68k versions. Additionally some parts of AmigaOS 3.[12].x are based on stolen AmigaOS 4.x sources and were illegally ported to m68k. The usual licences of the OS4 developers to Hyperion were of course PPC only, for example my AmigaOS 4.x CDFileSystem port was illegally backported to AmigaOS 3.x/m68k and included in AmiagOS 3.[12].x.
Even if it would have been covered by my CDFileSystem licence, which isn't the case, Hyperion would have had to pay me the x cent licence fee per copy of AmigaOS sold including it, which they didn't do since about 2005 for the AmigaOS 4.x/PPC versions any more, let alone the pirate copy AmigaOS 3.[12].x/m68k versions of it.

Quote:Since when is AROS/PPC, aka MorphOS, open source?
AROS is open source, but AFAIK not any of the hundreds, or even thousands, of bug and AmigaOS compatibility fixes the MorphOS developers had to add to the AROS sources to make them usable.

@Balaton

Ok, I understood a bit how to debug the AHI output a bit. Not sure if you or anyone else can do anything with it.

I debugged it like this...AmigaOs4.1 completely booted Sound.prefs opened debug output set to full with kernel.debug. After that I started the startup sound of Amigaos4.1 and recorded the output.

I also passed the information to Volker, maybe you can do something with it too.

@Maijestro
The log is not useful to me but hopefully Volker can find out something from it. I think he said previously that the AHI prefs test sound uses too small buffers so it won't play correctly but other apps do it differently. But maybe not on amigaone, I don't know and only hope Volker is interested enough to find this out. What you could try is getting the same logs with pegasos2 as well where it works and try to compare if any settings are different (apart from memory addresses which would of course be different) but that needs some digging of the AHI sources to find out what the numbers in the debug log actually mean. That's why they aren't useful to me because I don't want to spend time to read the AHI source and find out. Maybe somebody who already knows it could look at it or somebody who interested enough to learn this.

@Balaton

Together with Volker and the last es1370 patch series from 17.09 I wanted to do a trace output with -msg timestamp=on -trace "es1370_*" on the Qemu AmigaOne branch. But there is no output neither with -msg timestamp=on -trace "es1370_*" nor with -trace enable="via*" on the official source Qemu master I can record it without problems with -trace enable="via*" but since here the patch series from 17.09 was not installed, there is also no output with the es1370.

I'm not sure, but it seems to not work via the source https://osdn.net/projects/qmiga/scm/git/qemu/summary.

Do you have any idea what this could be?

Edit: Problem solved -serial stdio has prevented the trace output after removing this line it works.


Would it be helpful to record the trace output of ac97 from Pegasos2/AmigaOne so that we can compare why there is no sound output under the AmigaOne emulation?

@Maijestro
This may depend on the trace backend you compiled QEMU with. I usually use --enable-trace-backends=log which just logs to the stdout/stderr and can be redirected from there but Volker preferred simpletrace that writes a binary file and needs to be processed with a python script to get the logs instead. I don't know what you did but seems to be solved anyway.

I can't debug QEMU audio stuff so whatever is useful for Volker. If need some help from me you can cc me on emails but probably can't help much as I don't know how these things work. I've just implemented the emulation of the sound part following the chip datasheet then the rest is done by QEMU and AmigaOS so don't know what those parts are doing so if the problem comes from those parts we need an expert on those to find it.

@balaton

According to Volker it looks like a problem with the AmigaOne interrupts.



Quote Volker: AmigaOS uses two audio buffers for playback. One buffer is written while the other is played back. An interrupt informs the operating system that a buffer has been played back completely and can now be rewritten. If an interrupt is lost, the buffer that is currently being replayed is rewritten. These are the audible audio problems. With the next lost interrupt everything is correct again.

The audio interrupt is still not reset by the interrupt routine 11ms after the interrupt was set. But I can't tell from the log file if the interrupt latency is just too long or if the interrupt was really lost. The es1370 audio device is not responsible for this. QuoteEnd

Since you have implemented the AmigaOne part this would probably be interesting for you that there is a problem within the AmigaOne emulation and it is not due to the es1370 part, maybe this is also the reason why ac97 does not work, but I am not sure.

If Volker is right, it won't be long before we find the problem. I just wanted to inform you about the progress, if you think of anything else, let me know.

@Maijestro
As the interrupt handling is slightly different between amigaone and pegasos2 I suspected it's some problem there but without more details I can't find it. Now testng with Volker seems to confirm this but it's still not sure if this is because something is not emulated correctly or roo frequent interrupts are just too slow in emulation. If it's just slow maybe increasing the buffer size in AHI could avoid this as that should make the interrupts less frequent but I don't know how to set that and have no time to experiment with it.

Maybe it helps if I write down what I know which is what I've written. The VIA chip has two embedded ISA PICs, these are created in hw/isa/vt82686.c::via_isa_realize() calling i8259_init() and just use the existing QEMU ISA PIC emulation that should generally work as all other machines using ISA PIC use this although we had to add some legacy mode which nothing else used but AmigaOS so there may be some corner cases but it's less likely. This emulation is used by both amigaone and pegasos2. The PCI interrupts are also connected to VIA chip and this may not be emulated in all detail but should work as long as everything is mapped to a single interrupt as it is in pegasso2 and amigaone apparently. This was discussed in the email thread on qemu list I've linked in the other thread when discussing passed through GPU interrupts and the patches in the pegasos2 branch of the qmiga repo tried to solve but testing with those patches made no difference so maybe this isn't the problem either but could be if something in AmigaOS relies on something that happens differently on real hardware. The ISA and PCI interrupts should raise the cpu_intr of the VIA chip which is connected to the PPC CPU external interrupt in hw/ppc/amigaone.c (the pegasos2 routes this through the MV64361 GPP input so it's a bit more complex there). Then acknowledging the interrupts can either be done writing PIC registers or using a virtual acknowledge register of the north bridge which seems to be used in AmigaOS, this is emulated in hw/pci-host/articia.c for amigaone and hw/pci-host/mv64361.c for pegasos2.

That's all I did and don't know if any of these could be wrong or something missing. For that I'd need some advice from somebody who actually knows how these machines work and how AmigaOS uses these. We apparently have some problem with interrupts which is causeing problems on amigaone and likely also the netowork freeze issue on pegasos2 but I don'w know what to fix or even what to check without some help so I'm not working on this just wait for somebody to find out what the problem is so we can then think about how to fix it. The hard part is identifying the problem, once it's understood, implementing a fix is usually simple.

@balaton

We all have little time, I also work full time and not on Qemu and AmigaOs4.1

Thanks for the hint, I will forward it to Volker, maybe he can do something with it. Unfortunately I don't understand much about it, but I know how to keep people busy, because I like to use this emulation with AmigaOs4.1 very much and I know how well it has developed and works.

I'll keep you posted on how things develop

@Maijestro
Yes I know all this takes time, that's why I'd like more people to add in some time otherwise it will take forever for me alone.

In the little free time I had I've tried compiling a U-Boot from source for amigaone which would be needed to be able to submit the patches for inclusion in QEMU. I found that old U-Boot versions don't compile with newer gcc any more and newer U-Boot versions dropped the AmigaOneG3SE board. I could add back this board in the sam460ex 2010.06.05 U-Boot version and compile that and it starts but crashes within the BIOS emulator even if I use the same bios emulator that works with the sam460ex U-Boot. So something is still wrong in either the board support code, bios emulator glue code or in CPU support for 74xx CPUs. Also the sources for the AmigaOne board seem to be missing parts and the binary U-Boot says Board: AmigaOne while the one in upstream U-Boot says Board: AmigaOneG3SE so I think what's upstream is not the complete source for the AmigaOne binary U-Boot we're using and I could not reconstruct it.

That's where I'm stuck now in upstreaming amigaone patches. I've written to some people asking for the U-Boot source but hot no reply so far so if somebody has a source that at some point should have worked please pass it to me. (I have all the U-Boot versions in git so don't need any of those but actual AmigaOne U-Boot source corresponding to the binary on Hyperion's site that should have been available on asking in the 3 years it was released. Somebody should have asked and saved it I hope. If I can't get this I'd need to emulate U-Boot as well which is more work I'd like to avoid.

@balaton

What does that mean exactly that you can't merge the new AmigaOne emulation to Qemu Master 8.2 without U-Boot (Source) ?

It would be fantastic if we could have it available in Qemu 8.2 for everyone. Volker will surely be able to solve the problem with the sound and the AmigaOne emulation is really very fast and in parts (sdl1) even a bit more compatible than the Pegasos2 emulation.

Again other things are missing like nvram, because we use U-Boot as firmware, which does not save firmware configurations permanently. I'm not sure if Volker only cares about the Qemu sound part, but maybe he could help with that too.

@Maijestro
Adding nvram should not be diffucult but to include the machine in QEMU it should be able to boot something without needing non-free stuff that's redistributable with QEMU. Since U-Boot is GPL it's only redistributable with source (or even if it would be OK to reditribute the binary QEMU wants to be able to reproduce all binaries from source so I can't include just binsries without source). So we need the U-Boot source to build the amigaone firmware or have to implement -kernel command line option to be able to boot a Linux kernel at least but then people wanting to run AmigaOS would need to download firmware separately or I'd need to emulate too much of U-Boot which is more work. So easiest way is if somebody digs up the source for the AmigaOne firmware which should have been available before so I'm sure somebody still has it so would just need to make it available which is legal to do because of the GPL. If it does not compile now that's not a problem, I can look at fixing it but I don't want to rewrite it from scratch or from the fragments that were upstream in U-Boot in the past.

@all

I ask again is there someone who knows where the source code for (U-Boot 1.1.1) for AmigaOneXe/MicroA1 is or can provide it for Qemu AmigaOneXe?

Balaton needs this source to add the AmigaOneXe emulation together with the U-Boot firmware in Qemu. The AmigaOneXe emulation is in some parts even better than the Pegaso2 emulation and we would have 2 fully fledged machines that people could use. In addition we could add functions to the free U-Boot firmware.

The AmigaOneXe emulation already works very well, there is only one problem with the sound to solve, but also here someone is working since last week to fix this.

Please support the AmigaOneXe project.

Who can give hints should do it here in the thread, or contact Balaton directly.

@Maijestro
Quote:Complete source code for the U-Boot image files for the AmigaOne SE and XE should have been available, but not for the µA1:
The µA1-C has a twice as large EEPROM compared to the SE and XE and in addition to U-Boot includes the BIOS ROM for the onboard ATI Radeon 7000 gfx card.
(And yes, that's GPL compatible, the U-Boot code wasn't linked to the ATI BIOS code in any way, it's just 2 independent BIOS binaries in a single file/EEPROM.)

The AmigaOne emulation in QEmu is getting more important, I guess nearly all Pegasos2 AmigaOS 4.1 licences are sold out already and only AmigaOne licences are still available, not only do a lot of former AmigaOne users with broken hardware still have one, but the AmigaOS 4.1 AmigaOne licences sold to AmigaOS dealers should have been at least 50 times as much as Pegasos2 ones as well.