OS4 compatible UAE expansion development status
 

Design for OS4 compatible (Of course it is also all m68k AOS compatible) UAE expansion device support is finally starting to take shape. It really looks it is possible to rewrite the hook system without major changes to other parts of code. Old-style direct $f00000 area jumps of course can't work but uae.resource method should still work.

Next step: Implementation.

uaehf.device (hardfiles) support is probably the simplest expansion to support and debug before moving to more complex UAE expansions. Unfortunately uaehf.device is most useless too..

Donations are accepted, doing OS4 related stuff is quite uninteresting (did you expect something else? :)), unfortunately there really is no other ways to make it more interesting for me. Thanks.

More details will be posted when/if implementation advances.

Hehehe Toni, we know. :)
You need donations to be interested?
Ok, it's done. :D

Thanks. Different tasks require different kinds of motivation.

Note that there is no guarantee directory harddrives or hardfiles can work and/or can autoboot under OS4. Technically it should work but also technically exec/AddMemList() was also supposed to add memory to system pool... (Even OS4 exec autodoc does not mention any limits!)

Unfortunately there is no shortcuts, hook system needs to be nearly fully implemented before it can be tested. Unless someone who knows OS4 internals fully says something.

I wonder why the Hyperion Entertainment is not helping yet - they must have noticed increased OS4 sales after you and Frode made it possible to run this system on UAE...

Hi Toni. I may not have understood well but you're talking about implementing hooks from os4 ppc to "native code devices" like winuae does for 68k AmigaOS rtg, ahi sound,... right ? Not talking about dates or commitments, do you have any roadmap in mind ? (ie which features should/may come first).

I don't know exactly what is the dependency of ALICE project on those new features, but I suppose they would greatly improve ALICE performance and user experience with OS4. Is this project part of the reasons why you re-considered working on those hooks ?

I must admit I'm really curious about where ALICE will lead... having Jan and you onboard this project is already a good presage ��

whats ALICE?

Maybe he was talking about this project:
http://www.amiga-news.de/en/news/AN-...-00029-EN.html

or http://www.alice.org (j/k)

Even... ;)

Moved from QEMU thread.

Exactly. I assume reasons are politics only.. (But lets not discuss that here..)

Yes.

I'll update this thread when more information is available. Next step is insert UAE boot rom in new expansion device used for trap interface and add simple Amiga side to PC side hook. This is the first important phase.

If UAE side sees the hook access when running under OS4: test passed.

Obviously it helps any OS4 in emulation experience :)

IMHO, the first best thing to have is access to the host os files directly (is it uaehf.device job?). currently it's somewhat complicated, but not a big issue, you just need to setup everything correctly and get used to it.

Autoconfig board with UAE Boot ROM attached now works in OS3. No more need for ROM at $f00000 or somewhere, it is all in single 128k autoconfig board. Previous (and original since the beginning) method was single 64k autoconfig board and separate boot ROM. ("Old method" will not go away and stays the default)

OS4 test with above config seems to confirm that UAE Boot ROM DiagPoint code is really executed by OS4 m68k emulator, I can't be 100% sure but addresses accessed by QEMU match expected m68k code addresses. Until it crashes because it hit first UAE trap.

Post #9 test passed!

Next step is to implement alternate trap system.. This is much more complex part.

Yes and no, uaehf.device has nothing to do with it, it is only for UAE hardfiles. But uaehf.device is far simpler, it is the best test case, directory filesystem code needs lots of boring changes..

Shouldn't uaehf.device be faster than emulated A1200 controller? I think the A1200 IDE does not allow DMA...

I believe your question should be "Is uaehf.device faster than the emulated Cyberstorm SCSI?" as (I believe) that's currently the recommended (i.e. fastest) means to use .hdf drives under OS 4.1 in WinUAE.

Toni: hypothetically, could this lead towards uaegfx support in OS 4.1? (please say yes! :D)

Alice? https://www.youtube.com/watch?v=CsrfovOPcjk

No. Cyberstorm PPC = 128 MB OS4-visible RAM, Blizzard PPC = 256 MB OS4-visible RAM. If we have a fast OS4-compatible replacement for the A1200 IDE, then BPPC emulation might became more interesting for running the OS4...

Is that all that's holding the Blizzard PPC emulation back?

Anything is faster than PIO IDE (or SCSI).

But first versions of UAE<>Amiga-side communication in "OS4 mode" will make it more PIO-like, memory accesses are done by OS4 m68k emulator, it won't be DMA (UAE does direct writes to emulated memory). It probably still is much faster than PIO IDE.

DMA-like transfer support needs OS4 specific support code because of virtual memory and/or non-1:1 physical/logical mapping. Much much later..

Yes. It will allow working OS4<>UAEGFX communication but it does not guarantee anything else.

Awesome! Donation incoming just as soon as I get paid next week :) (not that you don't deserve it anyway!)

http://bit.ly/ALICE-news

Have a look at team members :)

Big update!

uaehf.device ("UAE" controller) hardfile works in OS4!. Directly booting from UAE hardfile not yet tested but at least automount works as expected.

Communication protocol is currently very simple, not thread safe, busy looping, lots of logging and so on. Don't ask about performance. Functionality and stability always comes first.

There is still some really nasty and tricky cases to support before directory hardfiles or bsdsocket or any other more complex expansion can work, for example ability to call Amiga library functions from host side.

This is not yet stable enough for public tests but soon, I expect something usable will be available in few days to 1 week or so..

This information can be posted in other forums/news sites. I think many users have been waiting for this.. And donations are still accepted :)