amiga.library

[motorollin]

I had a thought today, while I was writing some shell scripts to automate launching classic games on my Pegasos.

It would be really cool if the core of UAE could be made into "amiga.library". There would then be "aga.library" and "ecs.library" depending on the graphics requirements of the game, and "68000.library"-"68060.library" for emulating different processors. These extra libraries would in effect be modules of amiga.library.

When a classic game is started, MorphOS' 68k emulation would kick in. If the emulation detected the custom chips were going to be used, it would automatically redirect this to amiga.library. amiga.library would be able to tell which graphics library (aga/ecs) and which processor library (68000-68060) to use.

Basically, the game would still be running in UAE. But instead of mucking about with UAE config files and shell scripts to launch the game, it would be taken care of automatically by MorphOS and amiga.library.

I don't know if this kind of thing is feasible, or even desirable. It was just a crazy idea I had :-)

--
moto

[Homer]

Would it need 8Mb of chip ram ?  :lol:

[motorollin]

Yes, it would use leirbag's 8MB chip ram hack :lol:

--
moto

[Piru]

When a classic game is started, MorphOS' 68k emulation would kick in. If the emulation detected the custom chips were going to be used, it would automatically redirect this to amiga.library.

This is where it fails. To detect such access, the application needs to be started. Once custom chip access would be detected, the application would need to be frozen (Emulation can't know how to quit it in the middle of execution). So you would end up with stuck executable that could for example hold critical OS semaphore, and lock up the whole system.

Another problem is that there is no way for the emulation to know how the application was started. In fact, the emulation doesn't even know which application some code belongs to (well you could look into seglists, but lot of stuff use custom decrunchers and such which AllocMem the destination buffer). The MorphOS 68K emulation is totally transparent, there is no difference in PPC and 68K applications. Regardless, even if the emulation could idenfity the seglist, it still wouldn't know how to launch it with UAE.

However, it's very possible to have adf doubleclick to launch uae (trivial with new Ambient). That laucher could for example have UAE config database for various adfs, maybe identified with MD5SUM or filename.

Oh, and 68040.library and 68060.library names conflict with system libraries (MorphOS refuses to OpenLibrary libraries with these names to avoid compatibility issues).

[motorollin]

Piru wrote:

When a classic game is started, MorphOS' 68k emulation would kick in. If the emulation detected the custom chips were going to be used, it would automatically redirect this to amiga.library.

This is where it fails. To detect such access, the application needs to be started. Once custom chip access would be detected, the application would need to be frozen (Emulation can't know how to quit it in the middle of execution). So you would end up with stuck executable that could for example hold critical OS semaphore, and lock up the whole system.

Would it make any difference if the amiga.library was started before the 68k app?

Piru wrote:
Another problem is that there is no way for the emulation to know how the application was started. In fact, the emulation doesn't even know which application some code belongs to (well you could look into seglists, but lot of stuff use custom decrunchers and such which AllocMem the destination buffer). The MorphOS 68K emulation is totally transparent, there is no difference in PPC and 68K applications. Regardless, even if the emulation could idenfity the seglist, it still wouldn't know how to launch it with UAE.

Hmmm, tooltype maybe? If the icon has the tooltype "classic" then it uses amiga.library.

Piru wrote:
However, it's very possible to have adf doubleclick to launch uae (trivial with new Ambient). That laucher could for example have UAE config database for various adfs, maybe identified with MD5SUM or filename.

Well, have written shell scripts to automate launching of UAE. But you still have to duplicate the script and modify it with the correct path every time you get a new game.

Piru wrote:
Oh, and 68040.library and 68060.library names conflict with system libraries (MorphOS refuses to OpenLibrary libraries with these names to avoid compatibility issues).

I did wonder that. Well, it's simple: use 680x0emu.library.

--
moto

[Piru]

Would it make any difference if the amiga.library was started before the 68k app?

No. The concept of detecting the access fault and then lauching uae is flawed.

Hmmm, tooltype maybe? If the icon has the tooltype "classic" then it uses amiga.library.

And how would it know which icon to look into? Same problem, only this time it'd need to know which .info to look into.

If you're going to launch emulation right away, it doesn't make any difference if you have it in some "amiga.library" or if the emulation is static binary. UAE is GPL aswell, so it can't be integrated tightly to closed source project.

[motorollin]

Ok, so it was a bad idea :-)

--
moto

[Thomas]

If the icon has the tooltype "classic" then it uses amiga.library.

What's the difference between having a tool icon with "classic" tooltype and having a project icon with UAE as default tool ?

The latter is already possible (kind of). Have a look at Aminet or OS4Depot (don't remember which). Somebody wrote a set of scripts for E-UAE which lets you launch ADF files by double click. As these are only scripts they should run on all of OS3, OS4 and MOS.

And UAE can have 8MB of chip ram without any hack.

Bye,
Thomas