English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   OS4 compatible UAE expansion development status (http://eab.abime.net/showthread.php?t=81146)

Toni Wilen 14 January 2016 19:00

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.

huepper 14 January 2016 20:53

Quote:

Originally Posted by Toni Wilen (Post 1062719)
...

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.

...

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

Toni Wilen 14 January 2016 21:33

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.

Romanujan 14 January 2016 22:02

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...

ccapublic 14 January 2016 23:08

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 ��

Locutus 15 January 2016 00:03

whats ALICE?

AnnaWu 15 January 2016 01:10

Quote:

Originally Posted by Locutus (Post 1062779)
whats ALICE?

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

Saghalie 15 January 2016 04:17

Quote:

Originally Posted by AnnaWu (Post 1062787)
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... ;)

Toni Wilen 15 January 2016 08:38

Moved from QEMU thread.

Quote:

Originally Posted by Romanujan (Post 1062761)
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...

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

Quote:

Originally Posted by ccapublic (Post 1062771)
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).

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.

Quote:

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 ?
Obviously it helps any OS4 in emulation experience :)

Michael 15 January 2016 15:46

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.

Toni Wilen 15 January 2016 20:12

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.

Quote:

Originally Posted by Michael (Post 1062864)
IMHO, the first best thing to have is access to the host os files directly (is it uaehf.device job?).

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..

Romanujan 15 January 2016 21:17

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

Aegis 15 January 2016 21:24

Quote:

Originally Posted by Romanujan (Post 1062944)
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)

spudje 15 January 2016 21:27

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

Romanujan 15 January 2016 21:48

Quote:

Originally Posted by Aegis (Post 1062945)
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.

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...

Aegis 15 January 2016 21:55

Quote:

Originally Posted by Romanujan (Post 1062953)
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?

Toni Wilen 15 January 2016 22:13

Quote:

Originally Posted by Romanujan (Post 1062944)
Shouldn't uaehf.device be faster than emulated A1200 controller? I think the A1200 IDE does not allow DMA...

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..

Quote:

Originally Posted by Aegis (Post 1062945)
Toni: hypothetically, could this lead towards uaegfx support in OS 4.1? (please say yes! :D)

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

Aegis 16 January 2016 00:26

Quote:

Originally Posted by Toni Wilen (Post 1062958)
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!)

ccapublic 16 January 2016 00:29

Quote:

Originally Posted by Locutus (Post 1062779)
whats ALICE?

http://bit.ly/ALICE-news

Have a look at team members :)

Toni Wilen 16 January 2016 18:10

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 :)


All times are GMT +2. The time now is 23:16.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.

Page generated in 0.05821 seconds with 11 queries