Writing a new Amiga emulator... well, sort of.

[skurk]

I had this idea a few years ago, but never really had the time to do anything with it.  I barely started writing it, and I thougth I'd check with you guys to see if I'm walking a dead end road or not.

I'm thinking of writing a new Amiga emulator from scratch.

Ok, now, before you all start screaming at me, hear me out. This MIGHT just be something cool.

The idea is to write an Amiga "GUI emulator" that works with 100% system friendly applications only: it executes 68k instructions and translates all library calls to something similar on your current system.

For example, if a call is made to _LVOOpenWindow(), it actually opens a REAL window on your OS.  Applications will appear to be native, and not run inside some emulator window.

So far I figured C++/Qt might be a good combination for this.  Portability is important.

I've written the base and I'm currently able to run some simple DOS programs, like C:Avail.  As soon as I get my head around how ReadArgs work, I'll be able to take it one step further.

So, does this sound plausible?  Maybe I'm unable to see some major show stoppers ahead...?  If others want to help, I can create an SVN repository for it.

[DBAlex]

Sounds cool...

 :-D

Maybe if you can do things like this you could work on getting 68K support for AROS... thats a big ask though.

 :-)

[Crumb]

Perhaps you could take a look at AROS. They had a layers.library that used X11 years ago.

[tonyyeb]

Sounds like a nice idea. A bit like Wine?

It would be better if this sort thing was in AROS appearing to run 68k apps natively.

[Piru]

@skurk

Maybe I'm unable to see some major show stoppers ahead...?

There will be problems with anything that peeks and pokes the window and screen structure (which is perfectly legal in most cases). Also, on amiga the windows are rendered to the screen bitmap, if you detach the window from the screen (that will certainly happen here), problems will arise.

The interaction between the emulated and native UI will be tricky to get right.

The same problems arise for anything that has the structures exposed to the application programmer: Any changes on the native side must be relayed to the structure, and any (legal) change to the structure inside the emulation must reflected to the native resource. You will have headaches here.

It might work with some simple apps however.

[skurk]

tonyyeb wrote:
Sounds like a nice idea. A bit like Wine?

Yes, it'll be exactly like Wine :-)

It would be better if this sort thing was in AROS appearing to run 68k apps natively.

I thought AROS was able to run system-friendly 68k apps already?  (Or am I confusing AROS with MorphOS now?)

[Piru]

@skurk

Yes, it'll be exactly like Wine

Except that Wine doesn't emulate the CPU, but oh well... :-)

I thought AROS was able to run system-friendly 68k apps already? (Or am I confusing AROS with MorphOS now?)

It isn't. You are.

[bloodline]

@skurk

AROS Hosted on 68k-Linux would do what you want... though without the CPU emulation...

[Piru]

@bloodline

AROS Hosted on 68k-Linux would do what you want... though without the CPU emulation...

Would it? As far as I know AROS is not binary compatible, even on m68k.

[skurk]

Piru wrote:
@skurk

Yes, it'll be exactly like Wine

Except that Wine doesn't emulate the CPU, but oh well... :-)

..and it's not emulating Windows either, but you get my point.

[bloodline]

Piru wrote:
@bloodline

AROS Hosted on 68k-Linux would do what you want... though without the CPU emulation...

Would it? As far as I know AROS is not binary compatible, even on m68k.

It is "supposed" to be binary compatible on a 68k... Incompatibilty on the 68k is considered a bug.

This sounds like a really cool project. It's the sort of idea that can be implemented incrementally - slow and steady wins the race and all...

Are you planning to make the software open source?

[Hans_]

@skurk

Piru has already gone through the issues. The direct access to structures is going to be a pain because you'll somehow have to synchronize these structures with the OS' own structures.

BTW, I wouldn't call it an emulator; it's really an implementation of the Amiga OS API on another system. The Wine project is called a "compatibility layer," and "an Open Source implementation of the Windows API on top of X, OpenGL, and Unix."

Hans

[skurk]

Hans_ wrote:
BTW, I wouldn't call it an emulator; it's really an implementation of the Amiga OS API on another system.

Well, it's somewhere in the middle.  The CPU is emulated, so it's not exactly like Wine.  And since "Wine Is Not an Emulator", I don't know where I'm going with this.

Anyway.

It's a cool project to play with.  It's really easy to get carried away with..  And since I don't have much spare time, then yeah - it will be open source and open for other contributors.  If that is of interest to anyone.

[jupo42]

I don't really know anything at all when it comes to this, but shouldn't it be easier to do this as a P96 driver, that could then be loaded into the likes of UAE? Seems like it would make more sense than rewriting emulation from scratch - you already have the emulator, and you already have RTG hardware abstraction, and there's a fallback to the regular UAE window for apps that aren't RTG friendly.