Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: nyteschayde on February 07, 2012, 07:02:53 AM
-
Is it possible to access the 68K processor from OS4 just like we were once able to access the PPC from OS3.x? Basically RunInUAE is a great idea but is more or less completely unusable under OS4 Classic (at least with my BlizPPC).
It kills me I have a 68060 sitting there dreaming while the 603e struggles to emulate a 68K for E-UAE. Any chance of passing through to the real 68K (ala ShapeShifter for MacOS, etc...)
-
under os4.x 68k on classic is only used to bootstrap. live with it. and shape shifter doesnt run without uae on ops4?
-
It must be possible, the damn thing is still there on the bus after all. Irrespective of that I can`t think of a sensible reason not to just boot into OS3 - you could write a script to reboot from an adf in RAD or something I dunno...
-
Is it possible to access the 68K processor from OS4 just like we were once able to access the PPC from OS3.x? Basically RunInUAE is a great idea but is more or less completely unusable under OS4 Classic (at least with my BlizPPC).
It kills me I have a 68060 sitting there dreaming while the 603e struggles to emulate a 68K for E-UAE. Any chance of passing through to the real 68K (ala ShapeShifter for MacOS, etc...)
Sounds like the problem is OS4. Get rid of that and everything will work fine.
-
OS4.1 is really quite nice. One very nice thing about RunInUAE is that it allows me to use the RTG graphics card for running classic OS games (in theory).
My reference to Shapeshifter was the direct use of the CPU in the emulated environment. This direct CPU usage was the only thing that allows Amigas to emulate 68K Macs at almost as fast, and sometimes faster, speeds as compared to a real one.
I've heard from the author/supporter of RunInUAE Christopher Handley that one of the main reasons RunInUAE is so slow is that there isn't a JIT being used in the emulation.
Anyhow, it doesn't look like this has been done or that people have tried to do it (access the 68k from OS4). Just thought I'd ask is all.
-
Sounds like the problem is OS4. Get rid of that and everything will work fine.
sounds like the problem are crooks bored to post on moo****ingbunny lately!
-
Sorry?
-
sounds like the problem are crooks bored to post on moo****ingbunny lately!
The trolls are hungry :D
-
OS4.1 is really quite nice. One very nice thing about RunInUAE is that it allows me to use the RTG graphics card for running classic OS games (in theory).
....
Anyhow, it doesn't look like this has been done or that people have tried to do it (access the 68k from OS4). Just thought I'd ask is all.
See this thread: http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=1296&forum=3&post_id=15422
Steve
-
I had my own crazy idea for co-opting the 68K, but I am not really sure how practical it is. Probably entirely impractical. However, if we note for a moment that it can read and write all the same address space the PPC can, then we could envisage it as a programmable DMA controller for motherboard resources, such as the IDE, PCMCIA etc. In this scenario, it has a small work area reserved for it (unpageable from the PPC side) that it can cache (for code and small amount of working set), but otherwise it regards the rest of the address space as uncacheable. It could then be invoked to transfer data to/from legacy devices independently of the PPC. From the latter's perspective, you'd obviously need to do the Pre/Post DMA calls for regions affected by any operation you intend to perform. Uncached memory access from the 68K would be suboptimal, but at the same time faster than any of the IO devices it would be talking to, so they'd almost always be the bottleneck. For a lot of block stuff, with luck, you could use move16, thus avoiding cache pollution so that your 68K manages to keep it's local working data and code in it's cache, avoiding unwanted memory accesses that aren't part of the transfer you are performing.
Of course, this nebulous hand-wavy description overlooks many important technical details (arbitrated access to the "DMA controller", interrupt control, scheduling etc), though I see it as being slightly less complicated than trying to actually use the 68K for running actual 68K applications under any kind of inverted WarpOS scenario.
-
See this thread: http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=1296&forum=3&post_id=15422
Steve
That helps but simply raises more questions. E-UAE under OS4.1 doesn't have a JIT. Petunia is a perfectly working JIT but lacks the environment provided by E-UAE in order to make older games function correctly.
Has anybody done any dev work on OS4 that takes advantage of or directly works with Petunia? Do we know if there are APIs of any type exposed to allow this happen?
I've sent an email to Chris and Álmos about just this. If people want to chat more about it, feel free to do so; otherwise I'll update this thread later when/if I hear more from them.
-
So Karlos, have you worked with the 68K or even accessed it at all from OS4? I know you have a lot of experience working with the PPC from 68K code but was curious if you've done anything from OS4 regarding the 68K?
-
That helps but simply raises more questions. E-UAE under OS4.1 doesn't have a JIT. Petunia is a perfectly working JIT but lacks the environment provided by E-UAE in order to make older games function correctly.
Has anybody done any dev work on OS4 that takes advantage of or directly works with Petunia? Do we know if there are APIs of any type exposed to allow this happen?
I've sent an email to Chris and Álmos about just this. If people want to chat more about it, feel free to do so; otherwise I'll update this thread later when/if I hear more from them.
On that topic, see here: http://amigabounty.net/index.php?function=viewproject&projectid=35 and here http://euaejit.blogspot.com/ :)
Steve
-
I'll forward that link to Chris and Álmos
UPDATE: I'm a dork. If I actually read closely I would have found the link to http://euaejit.blogspot.com/. On this page, the author of Petunia, Álmos is already working and likely nearing completion a JIT for E-UAE for OS4.1.
Still it would be nice to know more about this stuff being a dev myself who is getting into Amiga programming.
-
So Karlos, have you worked with the 68K or even accessed it at all from OS4? I know you have a lot of experience working with the PPC from 68K code but was curious if you've done anything from OS4 regarding the 68K?
Afraid not. It was simply a thought experiment, one that would likely require quite a lot of work to evaluate the feasibility of. As interesting as the idea seems to me for now, there are more pressing things to work on (in the limited time I have in the day in which to cram it in).
-
Sure, I understand you're busy. I'm so fragmented with my time as well I never seem to get anything done. Just was curious on your level of experience with the OS4->68K usage as opposed to your past experiences.
-
Theoretically, ShapeShifter should work at full speed using the OS4 68K JIT, since ShapeShifter is more in line with today's virtual machines like VMWare and Parallels than a true emulator, since it uses the host's own CPU as-is and just emulates the additional bits. If it doesn't work, it's probably due to limitations of the OS4 JIT (it doesn't emulate everything). The 68K BasiliskII might be a better test under OS4, since I think it's a little "cleaner" on the hardware-banging side (and also doesn't emulate the CPU).
Point being, there could also theoretically be a version of 68K UAE built the same way - use the native CPU instead of emulating. I'm not sure how big a project that would be. Maybe adapting the in-program JIT for PPC is easier! :)
-
Theoretically, ShapeShifter should work at full speed using the OS4 68K JIT, since ShapeShifter is more in line with today's virtual machines like VMWare and Parallels than a true emulator, since it uses the host's own CPU as-is and just emulates the additional bits. If it doesn't work, it's probably due to limitations of the OS4 JIT (it doesn't emulate everything). The 68K BasiliskII might be a better test under OS4, since I think it's a little "cleaner" on the hardware-banging side (and also doesn't emulate the CPU).
Point being, there could also theoretically be a version of 68K UAE built the same way - use the native CPU instead of emulating. I'm not sure how big a project that would be. Maybe adapting the in-program JIT for PPC is easier! :)
Has anyone actually got 68k Basilisk 2 to boot into MacOS on an amiga
-
Is it possible to access the 68K processor from OS4 just like we were once able to access the PPC from OS3.x? Basically RunInUAE is a great idea but is more or less completely unusable under OS4 Classic (at least with my BlizPPC).
It kills me I have a 68060 sitting there dreaming while the 603e struggles to emulate a 68K for E-UAE. Any chance of passing through to the real 68K (ala ShapeShifter for MacOS, etc...)
It might be possible but there are a few things you may need to consider.
Shapeshifter is not emulating the MAC's video hardware in the same sense that UAE emulates the every detail of the Amiga's chipset. Apple has an abstraction layer on the hardware (QuickDraw) and Shapeshifter patches into that.
The slowness with UAE may not even be the CPU emulation anyway. The bottleneck is far more likely emulating the custom chipset.
Finally, the architecture of UAE. For example the custom chip emulation may require hooks into the CPU emulation.
-
sounds like the problem are crooks bored to post on moo****ingbunny lately!
geez and you're surprised ? it's the norm here on every single OS4 thread sadly:(
-
It might be possible but there are a few things you may need to consider.
Shapeshifter is not emulating the MAC's video hardware in the same sense that UAE emulates the every detail of the Amiga's chipset. Apple has an abstraction layer on the hardware (QuickDraw) and Shapeshifter patches into that.
The slowness with UAE may not even be the CPU emulation anyway. The bottleneck is far more likely emulating the custom chipset.
Finally, the architecture of UAE. For example the custom chip emulation may require hooks into the CPU emulation.
That may be, but other than the amount of work it would take to tap into the existing chips (and I understand there may be work there that is not easy; i.e. securing direct access to the chipset if that's even possible), all those custom chips are actually available and shouldn't need emulating. It's likely that the E-UAE Amiga port simply did the least amount of work as possible and avoided using the real hardware even though it does exist and is within easy reach.
Emulating an Amiga on an Amiga should be a fast process.