[Vampire] The AMIGA Future Is NOW! AROS!

[psxphill]

as a comptent person you probably are aware that 68k mmu emulation wont work with jit.

It is perfectly possible to emulate an mmu in a jit.

You could probably even use the native mmu.

[psxphill]

Ideally, a new 68K would be as compatible as the '020/'030 but have pipelining and scalar advantages that would speed up operations and make them more concurrent.

The whole "compatible as the 020/030" issue was pretty much solved in the 1990's. I'd rather not have another project poisoned.

If someone is going to do something like a 68060, then doing a 68060 clone would be ideal.

[psxphill]

thats not what toni says, im afraid.

What does toni say?

Because toni has a lot of experience with winuae and not a hypothetical jit that runs natively on x64. So I can't tell whether you misunderstood what he was saying, or whether to disagree with him.

what i wanted to say actually is that i suspect, whatever the core is being identified as, the software supposedly will work, as all instructions are available.

Unless it needs the instructions to trap.

[psxphill]

yesterday toni fixed an annoying bug we were tracing for years, that prevented aros to fully boot from some internal amiga ide controllers (a4k, probably a600), which may have also caused some problems to boot it on vampirized hardware. tested it succesfully this night and hope toni commits it soon..

If it's this https://github.com/ezrec/AROS-mirror/commit/7f51cc5dcc9b49e29bdc99b1007a91cd676da10d then

Then the patch only skips reading the alternative status register if you have an IDE doubler. So I would expect it will only affect you if you are using an IDE doubler.

Reading the status register acknowledges an interrupt and you're supposed to write your code so that it only reads it when you're processing interrupts. The alternative status register doesn't acknowledge interrupts, but you can't read it when you are using an IDE doubler. IDE has cs0 and cs1, each has the potential for 8 registers but cs1 only has 2 that aren't commonly used (I think the original scsi.device from commodore doesn't use them). IDE doublers use the amiga cs1 for the second set of drives cs0 & don't give any way of accessing the drives cs1 registers.

I've not found what it actually does if you ask for the alt status and it can't read it. Although if it falls back to reading the actual status, then it would explain the behaviour.

Fortunately in that place the alt status is only used in DEBUG mode for logging, so now it's not being read then it's just logging the wrong value.

This line will potentially cause a problem if you have an IDE doubler and are using irq mode and compile in DEBUG:

 DATAPI(bug("[ATAPI] Status after packet: %lx\n", ata_ReadAltStatus(bus)));

Ideally the code would be changed to avoid needing to read the alternative status register in all circumstances, at least it should only use it for logging and skip the logging when you are using an IDE doubler.

[psxphill]

i cannot judge this, as im not familiar with the lowlevel hardware subjects. in fact tonis patch fixed ide behaviour on two different a4000 models i tried this with (no ide doubles) and didnt negatively affected a1200 (tested).

It's certainly possible that there is a bug so that it always thinks the a4000 cannot access "alt io". I don't believe it's an actual limit on the a4000 because this http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=599 exists.

It may also get it wrong on a600/a1200 or vampire but I can't find that part of the code in the git mirror, so either it's missing from git or the code is generated with some macro fu that makes it hard to search for.

This is when the alt io stuff was originally added.

https://trac.aros.org/trac/changeset/46722/AROS

This is where ide doublers are detected....

https://github.com/michalsc/AROS/blob/master/arch/m68k-amiga/hidd/gayle_ata/probe.c

and then this is where they are used

https://github.com/ezrec/AROS-mirror/blob/148fa41943c6090ddc3a82efa2259a43ce23faea/AROS/arch/m68k-amiga/devs/ata/ata_amiga.c

But I haven't figured out how that builds a ATA_BusInterface yet.

FWIW it looks like whoever wrote https://en.wikibooks.org/wiki/Aros/Developer/Docs/Devices/ATA knew about the issues too.

[psxphill]

from toni:


please, dont shoot the messanger;)

That explains it. I was starting to come to the conclusion that it never read the alt status on amiga, even though the code in some places was giving the impression that it would. I couldn't track down where it fell back to reading the actual status. Aros is unfortunately not a panacea. You can blame me for being dumb, but
building barriers around source code that mean you can't just follow code easily is a bad idea. It's why I stepped out of AROS development in the first place, I was coincidentally building a custom 68k kickstart but I only had an amiga at home and wrestling with building it with the compilers available was just too much hassle. I made some progress & had "something" that booted, but ultimately I got a Windows laptop (circa 2001) and my Amiga use faded away.

"because it is
practically guaranteed there are Gayle/A4000 IDE based IDE designs that
don't implement altstatus (or devcon) at all"

I disagree with "practically guaranteed", the registers are in the drive & All gayle/a4000 IDE designs support reading the registers or you wouldn't be able to fit a 4 port ide adapter in the first place. It's only the ide doubler that affects it & in your test sample then none of them had one. However I'd argue against using alt status apart from logging and not to read it at all when it's impossible to read it, which in this case is what toni did. However there are still a load of cases where it reads the alt status, some in DEBUG code and some are always read which he hasn't done anything about. Which leaves race conditions waiting to happen. I am perfectly happy to leave him to it.

[psxphill]

to be honest i dont know if and how to run 68k binary under aros x86.

You have to run them under uae, which would either use kickstart or aros 68k. It's possible to have the 68k windows appear as if they are on the x86 desktop. You can't use 68k libraries in x86 programs etc.

To mix 68k and x86 applications under the same aros instance would require something like the amithlon gcc compiler that generated x86 code that was big endian. I don't think anyone has ever looked at doing that, but for me this would be awesome. Especially with a decent jit that can compile 68k & ppc binaries into x86 (or x64).

[psxphill]

This was not used for AROS as we want to have AROS run at maximum native speed when running on the native platforms and thus not use of unnatural endianess or structure packing.

I understand why the decision was made, I just think having the option would be more interesting.

In my opinion, an AROS that allows seemless mixing of 68k/ppc/x64 would outweigh the loss of speed on what are insanely fast cpu's. It may also persuade someone to do a x64 accelerator for the Amiga.

[psxphill]

Firstly, the (likely little endian) endianness of the host processor mean all multibyte memory access MUST be byte swapped, this means that host applications and 68k applications cannot share any data structures.

This is why you would use something like the amithlon gcc compiler to make a big endian x86/x64.

I've never seen an emulator that uses byte swapping. For a 32 bit cpu then 32 bit data that is aligned would be written natively & bytes are written by xor'ing the address with 3. Aligned words are written by xor'ing the address with 2. Unaligned data is handled with shifting.

The second problem which didn't occur to me until I had actual built the software was the address space issue. 68k applications only have 32bit pointers, so live within 4gig... But any modern host processor will be 64bit

It wouldn't be the end of the world to limit an application to only working within the first 4gb of ram if it loads a 68k library.

These two things coupled with the fact that many (older) Amiga applications expect the Amiga Chipset to be present,

A lot don't. Some packers write to colour registers to show progress, some programs wait for mice button presses. They can be handled with something a lot more light weight than uae.

[psxphill]

The problem I have is that my software has no idea what the data size of 68k application's data structures actually are. I have found examples where data was written sequentially as bytes and then read back using long words.

You can't ever know, which is why you need to use the same endian all of the time. You can't change the endian of the 68k legacy code, so that leaves compiling your native code to use big endian. This was the path that amithlon went for when it added support for native code. It's the only workable solution.

we can optimize os as a whole. since nick last commits after wider aros/vampire discussion aros is actually usable on my a4000/060 and bearable with 040.

Hopefully more interest in AROS 68k will continue that to the point where it's usable on even an 020. I'm not sure that 68k compilers have had much love in a long time.