Hi all!

Just a question, isn't it possible to run an Apple emulator under MorphOS? I used both Fusion and ShapeShifter on my old Amiga, but none of these seams to work with MorphOS. What's the trouble? I have lots of games and software for 68k mac, and I definetaly wish to use the MacOS on my Ambient Is it that hard work to reprogramm it for MorphOS?

Please don't speak about MacOnLinux, I'm not interested currently (I mean in this thread!!!).

Thanks and bye.

Well unfortunately none of the Amiga emulator programs for mac work with MOS. This is becuase they hit the original Amiga chipset that the Pegasos does not have..

You really should go see your friend Tux in Linuxland and run MOL. It is incredible.. check out my sig.

magnetic

Well, I know, why it doesn't work, but what I don't understand is, why didn't anyone fix it? All these emulators use drivers as for gfx so for sfx, so why?

And when You started with MOL... What does one need to make it working? I mean I have the pegxlin installed with MOL instalator 'enabled', but what more? I mean where to get MacOS? How expensive it is? And so and so...

Quote:

hi Mark!
As you will remember you used a program called prepareemul or rsrvcold/warm to reserve the first kilobytes of memory for the mac emu. It's used directly by MacOS to store local variables and it seems that it's not easy to patch the rom to use other location. There are various solutions for this:

1.- Write a tool that reserves the memory area from 0x000 to 0x3000 (that may require help from the main MOS developers because no info is available about memory management functions).

2.- Write a tool that uses the MMU to remap the damn memory area to another location. (surprise, surprise, no docs from Ralph and he don't wants to release it) This point causes that a MOL port is impossible for MOS because 3.x functions aren't enough.

3.- Recompile basilisk2 completely for PPC. You would use UAE's 68k emu and you would not use real memory locations and you would have to convert the addresses (for example adding an offset). This is slow, but the only thing you can do without the memory management docs.

But don't expect to make SheepShaver run (or the 68k mac amiga emus to run directly), you'll need the area from 0x0000 to 0x3000 free for your emus or the damn MMU functions. And as Ralph Schimidt hasn't any interest in helping the MorphOS emu community and don't wants to allow developers to create new interesting apps (with Memory Management functions we would be able to port nallehpuh, puhderbaer etc and have PAULA emulation just like in Amithlon).

Sorry Mr Schmidt, but this is disapointing.

-edit- Remember that these memory functions are already available in OS4 for example and that will cause that we'll have less emulators and that the most interesting ones (like ppc mac for example) will never work on MorphOS.

Quote:
I wouldn't really say "slow", it might well be faster than any real 68k Mac. But yes, the emulation COULD be faster than that...

Okay, so MOL seems to be the way forward.

I've tried the install guide (http://www.attention-software.com/pxlmolguide.html) but there seems to be a problem....the http://people.debian.org/~luther/pegasos/2.4.22/ directory is dead. I've tried to download and install vmlinuz-2.4.23 but that wouldn't work, and I can't find another suitable 2.4.22 version. Can someone re-upload the original content of the /2.4.22/ directory or point me to a site where I can get it?

-> I did try to run MOL without the 2.4.22 linuz files, but it reported missing files after the "startmol --cdboot" command and refused to run. Molvconfig worked though :( If someone nows how to get MOL to run on a standard PegXLin install, than I would be just as happy ;)

"Okay, so MOL seems to be the way forward. "

In Linux yes. In MorphOS there's no way to have a ppc mac emu without documentation about the memory management functions (if they really exist).

4. Write a 68k/PowerPC emulator (for PowerPC) and a JIT one. This way, you would have a full CPU (and all addresses you want). This could work pretty well.
There are already several 68k emu available and emulate a PowerPC on a PowerPC should be less hard than it seens.

You see, you don't absolutly need MMU !!
I guess that if the MMU API is not public there are several good reasons anyway.

In fact, it's a more common way to emulate something. For example, MAME 68k doesn't use MMU stuff to redirect the instruction to the real 68k on our Amiga...
Playing with MMU to emulate on AmigaOS 68k is a hack, and remenber AmigaOS 68k doesn't take care at all of the MMU.

Bye

NicoPPC:

MAME is a completely different emulator and I don't understand how you can compare them. MAME requires cycle exact emulation and Mac emus for Amiga 68k or MOL/SheepShaver on Linux have more in common with virtual machines than with emulators.

"emulate a PowerPC on a PowerPC should be less hard than it seens."
(lol) The idea of emulating a PowerMac emulating the entire cpu has no sense. It would be dead slow (yes, have you tried pc emus on pcs? they run FAR slower than the real thing).

your point 4 is exactly the same as my point 3. Adding JIT or not is a matter of changing the cpu engine, but the memory layout changes anyway and you have to convert addresses

"Playing with MMU to emulate on AmigaOS 68k is a hack, and remenber AmigaOS 68k doesn't take care at all of the MMU."

If you don't use MMU.library or any standard method then yes, it's a hack. If there are functions available and documented then it's not hack.

But we are talking about MOS here, we wouldn't need MMU if the first kilobytes were free for Mac emus. That would be enough to have SheepShaver working, and 68k mac emus would be able to use directly memory, boosting perfomance.

If we talk about MAC emus that use the cpu directly you will see that ALL of them use MMU, including SheepShaver(unless you have freed the first kilobytes, then it would be optional) and MOL

"I guess that if the MMU API is not public there are several good reasons anyway."

I can't see any good reason.
ALL modern OSes have an API to manage memory, yes you could even do that in a standard way in OS3.x if you used MMU.library, you can do it in windows, beos, qnx, linux, amigaos4, macos, macosx and any OS that is not MSDOS.

If there are good reasons I'd like to see a list.

Actually MacOS _requires_ an MMU; so it's definately necessairly.

With MacOS 8/9 you could go away with a simplified MMU abstraction; but it would be insanly difficult to implement on MorphOS that provides no tools however to remap the address space for a task. (and that's with the insanely lame excuse that the application will break in the future)

MacOS X requires a full MMU implementation; there's no way around it.

And even if there was an MMU interface available it wouldn't be a simple thing to write a MacOS emulator;
Sheepshaver would be easier to port; but unfortunately Sheepshaver is quite out of date.
MOL would still be very tricky to port as it needs to manage the page allocation table of the host system (which in turn requires the host system to use virtual memory.).

I don't think it would be dead slow. But yes, slower than native stuff.
By the way, the PowerPC has some complex instruction that should be hard to emulate on a x86 for example.

But, I don't know/think we really have the choice.
I was thinking that in order to emulate something like a PowerMac you need all the CPU functions, including supervisor mode, supervisor register, some kind of access to emlated physical memory...

So if you emulate the whole CPU, you have all of that, whereas if you "only" get MMU you still miss supervisor ...

For example, MOL needs a kernel module to work, so it can get these.

Even if you have some kind of access to 0x0 -> 0x3000, it's only for "old style" mac not for "new World" one. So you emulator/VM is still glue to old stuff. I may be wrong of that point.

In conclusion, VM are faster but more OS/hardware dependant. Emulator are slower (I don't think it would be that slower on the same CPU) but more OS/hard independant

PS: I'm not a low-level CPU/OS specialist so I may be wrong, but that's only my mind.

Bye

It would be very slow to emulate the PowerPC on the PowerPC.

Regarding the PowerPC having complex instructions that sohuld be hard to emulate on the x86; care to give any examples, I'm not aware of any complex instructions that could be tricky to emulate. The problem as I see it is that the PowerPC (32 general purpose registers) has an tremendous amount of registers; and the x86 has few (about 8 base registers if I remember correctly. (there's some more in extended mode))

Yes you need to provide a supervisor environment if you want to emulate a NewWorld architecture; MacOS 9 might look old on the surface but there's a fully preemptive kernel in the background that runs the BlueTask (on new world macs) (this works similar to ABox on MorphOS).
Low mem variables ain't the largest problem; it's the speed issue, you can sure implement the whole system in software but it would be horribly slow.

And yes you're correct that the Low Mem is only relevant to Old world style; (which don't run MacOS X for that matter.)
Old world style is also what sheepshaver emulates although it makes some trickery to reduce overheads in emulation.

having access to the MMU allows you to push time expensive task onto the hardware; it can be the difference between a usable and an unusable emulator.

ShapeShifter needs CIA timers and I believe IFusion is tightly tied to old Amiga hardware too...

"By the way, the PowerPC has some complex instruction that should be hard to emulate on a x86 for example."

SheepShaver already emulates a non-MMU 604. But I think that adding MMU emulation would half the speed

"I was thinking that in order to emulate something like a PowerMac you need all the CPU functions, including supervisor mode, supervisor register, "

If I remember correctly SheepShaver and MOL patch the MacOS ROM/Kernel to avoid the need of that so it runs in user mode. I think that Basilisk2 does the same on Amiga. Shapeshifter was more agressive with the OS and the MacOS ran in Supervisor mode because it patched exec.

"So if you emulate the whole CPU, you have all of that, whereas if you "only" get MMU you still miss supervisor ..."

no, you only have to patch the ROM as in SheepShaver or MOL.

"Even if you have some kind of access to 0x0 -> 0x3000, it's only for "old style" mac not for "new World" one. So you emulator/VM is still glue to old stuff. I may be wrong of that point."

I'm not sure about that, SheepShaver is designed to allow the use of "new world" roms but it's not clearly documented or visible in the sourcecode if it's obligatory to have reserved the first kilobytes of memory with "new world" roms.

It would be a matter of checking MOL sources (too many files for my taste, I find it confusing). But MOL requires advanced memory management functions not available in MOS...

"In conclusion, VM are faster but more OS/hardware dependant. Emulator are slower (I don't think it would be that slower on the same CPU) but more OS/hard independant"

uh? emulating a CPU with the same CPU is SLOW. If you use a very optimized JIT engine you could make it run at a fraction of the real speed. Check out QEmu for example. It's one of the fastest x86 emus and the old benchmarks without MMU emulation run 4-5 times slower than the real CPU. If MMU emulation is added it will be at least twice slow, so you are stuck with an emu eight times slower than the real thing.

And what we want is to run the OS, not to emulate the machine, and to run the apps at the fastest speed. An emu like Sheepshaver/MOL is the fastest way to do this, not an emu that tries to emulate everything.

If emulating a CPU with the same CPU is enough fast show me an emu for my classic Amiga that can run at decent speeds. Megadrive, Atari, UAE with P96, anything you want. All of them will run slow.

ey! good news from yesterday

from www.emaculation.com:
"SheepShaver: 2.2-20040224 clockwise
Wednesday, February 25 @ 00:33:00 EST



Gwenole Beauchesne took to the news groups to promote SheepShaver today.

Additionally, he posted the following to the mailing list:

"...[r]emaining bits prior to a formal release would include runtime depth switching from B2 and fixes for DGA displays + other ports. Possibly ethernet too, but I am still not satisfied with the current fixes.

Note that you no longer needs the -hacks patch, as I finally committed another variant for now. That should make it more user-friendly to build & get something working with MacOS 8.6 out-of-the box.


Official website: [here]

Sources (CVS snapshots) + precompiled binaries as RPM: [here]

Files: SheepShaver-2.2-20040224.tar.bz2, SheepShaver-2.2-10.*.rpm

What's new from previous test release?

Improved generic JIT, also now translates FPU instructions

AltiVec emulation, thus enabling the PVR to match a 7400 (G4)

Partial port to Darwin/PPC, i.e. it runs but some features may be missing
"

I hope they integrate it more with the Basilisk2 sources and that they add support for MacOS 9.x