I'm a bit late to answer, but you seem to be active so chances are you will see this reply.
Before I answer your questions I'll ask you a couple:
1. What version of MagicMac are you running?
2. What Mac hardware are you running on?
3. What version of MacOS do you have installed?
I run MagicMac 6.2 exclusively on 68K hardware, namely a Mystic Color Classic and a PowerBook 540C. The CC has 128MB RAM and the PB 36MB. Both are running MacOS 8.1
To your questions:
- Cleanly written GEM applications should run without issue. That means software that doesn't try to access address space of an Atari machine that doesn't exist on a Mac. There are just too many working apps to list here but there are quite a few that absolutely refuse to work.
- You have a couple of things you can do:
- If you have a PCI PowerMac you must use FPUPATCH. More on that below.
- If you are running MagicMac 6.2, you have three memory settings for the lower I/O area. More on that below as well.
- You have several CPU cache options (depending on your CPU)
- I know of people developing on the MagiCMac. Back when Atari folded and the TT/Falcon didn't cut it anymore, a lot of people exclusively used MagiCMacs for everything Atari. They claimed even better compatibility than the clones like the Milan and Hades.
- Only GEM games run and I don't think there are any I ever enjoyed. Atari ST games are absolutely not going to work.
Ok, so this FPUPATCH thing. Here's an exerpt from the attached MagiC 6.2 manual I translated and re-created:
MagiCMac on PCI PowerMacs
When you start MagiC Mac for the first time on a Power Macintosh with a PCI bus, a warning message appears
on the screen stating that the upper I/O address range cannot be hidden on your computer, which is used by
many ATARI programs to test for the presence of certain hardware (e.g., FPU).
Since such programs "freeze" when accessing this memory area, Application Systems has developed a special
program with which affected applications must be treated once to run stably on PCI PowerMacs. This patch program
called
FPUPATCH.TOS can be found after installing MagiC Mac in the folder
C:\GEMSYS\MAGIC\UTILITY\ZUSATZ\PCI_FPU
. You should drag each program file you use onto the program icon of
FPUPATCH.
The file will then be checked for problematic memory accesses, which will be "defused". The functionality of the
program does not change. For more information, please refer to the documentation
FPUPATCH.TXT.
Sometimes it may also be necessary to treat program add-ons or libraries of programming languages with
FPUPATCH, as these files may also contain problematic program code.
Then the three memory settings. Here's what I translated from an old post from the newsgroups:
Even the 68000 in the ST is already internally a 32-bit processor that works with 32-bit addresses.
However, the resulting 4 gigabyte address space on the 68000 can only be partially used because only the lower 24 bits of the addresses are actually output from the processor. This results in only 16 megabytes of actually usable address space. The upper eight bits are simply ignored.
However, ATARI has now placed the hardware control registers in the ST at the end of the available address space. What was actually meant were the addresses $FFFFxxxx (i.e., at the very end of the 4 gigabyte address space).
Unfortunately, many programmers have fallen into the misunderstanding that the hardware should be addressed in the address range $00FFxxxx ("the upper eight bits aren't used, so they must be set to zero...").
On the ST this actually doesn't matter; On the TT however, it does!
The 68030 (and all its "full-size" successors) has a complete 32-bit address bus; And so the well-intended $00FFxxxx accesses initially ended up in nowhere.
As a result, ATARI was forced by these sloppy programs to not only place the I/O area at the correct address $FFFFxxxx, but to additionally "mirror" it at the "misunderstood" address $00FFxxxx.
The TT address space:
Code:
SSSSSSSSSSSSSSSiTTTTTTTTTTTTTTTTTTTTTTTTTT....TTTRRRRi
| | | | |
| | | ROM |
| | | |
| | | "correct" I/O area
| | |
| | TT-RAM (max. fast 4GB)
| |
| "mirrored" I/O area
|
ST-RAM (max. 15MB)
And this led to the "gap" between ST-RAM and TT-RAM.
Under MagiCMac, the ATARI hardware registers naturally don't exist anymore and direct access to them can be dangerous. Therefore, the upper I/O area is generally blocked by MagiCMac.
Since access to the lower I/O area is only attempted by "dirty" programs, MagiCMac can be configured differently. (I still remember the CeBit when I kept pestering Thomas Tempelmann until he implemented it (right there at the trade show)...
)
The settings for the lower I/O area mean:
Setting "Reserved (Bus Error)":
The lower I/O area is reserved and blocked.
Any "malicious" access to any ATARI hardware address immediately leads to a bus error (program crash).
Code:
MMMMMMMMMMMSSSSxTTTTTTTTTTTTTTTTTTTTTTTTTT...........x
| | | | |
| | Bus Error | Bus Error
| | TT-RAM
| ST-RAM
MacOS
Here you can also see where the problem with PowerMacs lies:
MacOS has grown so large by now that for the ST-RAM there is absolutely no space left!
Setting "Reserved (No Bus Error)":
The lower I/O area is reserved but not blocked. Any "malicious" access to any ATARI hardware address goes into nowhere. "Dirty" programs might at most wonder why the Mac memory doesn't behave the way ATARI hardware would...
Code:
MMMMMMMMMMMSSSS_TTTTTTTTTTTTTTTTTTTTTTTTTT...........x
| | | | |
| | RAM (unused) | Bus Error
| | TT-RAM
| ST-RAM
MacOS
Setting "Available for Programs":
The lower I/O area is ignored: The ST-RAM simply continues up to the end of the assigned area. This is why there is then more than 15MB of ST-RAM and no TT-RAM at all anymore.
"Bad" accesses would however overwrite programs or data that happen to be located in the area of the lower I/O region. In this mode, therefore, only "clean" programs may be used.
Code:
MMMMMMMMMMMSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS...........x
| | |
| | Bus Error
| ST-RAM (continuous)
MacOS
This option is especially recommended for working with CSL, since it naturally never accesses the lower I/O area, but greatly benefits from the unified memory. This mode remains problem-free even when MacOS uses more than 16MB.
If you use a different mode in that case, you only have TT-RAM (and some programs have problems with that).
In conclusion, I too struggle a lot with systems crashes and complete lockups but that's mostly because I'm testing software and trying different things. But if I were to keep to the known working apps, everything is pretty sweet.
Alright, that's all for now. Hope this helps.
