Apple Mac emulation
ROMsEmplant demanded a 256K ROM image, keeping things simple for the emulator patches but making it obsolescent - 256K Mac ROM sets are rare in the 1990s, and unsupported since System 7.6. Fusion and ShapeShifter handle ROM sizes from 256K up. Most 68030 systems have 512K ROMs, with megabyte ROMs supporting the copyback cache in the fastest 68K Macs. 2 Mb PowerBook and PowerMac PPC ROMs are useless on current Amigas.
AMax and Emplant ROM sockets let you plug chips from a real Mac into your Amiga, and copy the code to an Amiga file. ShapeShifter introduced a different approach, later followed by Fusion. You need access to a working Mac, but don't need to take it apart to extract the chips.
A Mac program, supplied, copies the system ROM contents to disk, for transfer to the Amiga. The transfer each way must use PC format disks, as they can be read and written on both machines, with FileExchange on the Mac and MessyDOS or CrossDOS on the Amiga. Fusion 1 was incompatible with some of the claimed 143 Mac ROM variants; version 2 is more tolerant, but still not perfect and - typically - lacks any list of what will and will not work.
Like the Amiga, the Mac has a healthy proportion of its system code ready
to run in pre-programed ROM (Read Only Memory) chips. This must be
available to the Amiga - with due deference to copyright laws - before the
emulators will run. You also need the Mac system files, normally supplied
by Apple on CD or HD floppy, which are the equivalent of Amiga Workbench
disks - but more so.|
Most modern Macs and emulators run 32 bit system files, known as version 7. The original 7.0 release works with ShapeShifter but not Fusion, which requires at least version 7.1 and prefers 7.5 or 7.6 - intermediate versions were not released. A third digit signifies minor changes, e.g. 7.5.3. Later versions mainly gain Power PC code. The new release 8.0 occupies almost 300 Mb of CD space; it runs on Fusion but not ShapeShifter, and has some problems with 68060 processors, which Apple skipped in favour of Power PCs.
AMax, designed for 16 bit systems, runs Versions 4 to 6, all limited to 24 bit addressing like the A1000, A500 and Zorro 2 Amigas. Emplant and Amax Zorro boards can run system 6 or system 7, and Fusion can emulate 24 bit addressing with the MMU, to placate buggy old programs.
Hit the BuffersEmulated drives can appear to the Amiga as partitions or HardFiles. These are slower than dedicated partitions, but much easier to copy, backup and move because the Amiga regards them as large but otherwise normal files.
Access lags because the system cannot move directly to a given block. It must read the file sequentially to get to any position, because the blocks could be scrambled or 'fragmented' across the disk. The larger the HardFile, the longer this takes.
The 'cure' is to dedicate a partition, or add buffers. The standard block size is 512 bytes, when one block in every 73 contains a 'map' recording the location of that part of the file. This map must be re-read unless there's a spare 'buffer' to hold it in memory, so you normally need about one buffer per 36K for fast access to a large file, and over 1000 buffers (512K) for a 40 Mb 'hard drive'.
Fast File System 3.1 (v40.1 or later) lets you use bigger blocks. This can make a terrific difference. First back up the partition, as changing the block size zaps the original contents. Then run HDToolbox (in sys:tools), selecting a drive and partition. Choose 'advanced options' then 'change...' to see the file system characteristics, and choose bigger blocks; values from 1K to 32K are allowed. Select OK, adjust the preset number of Buffers (bottom left) and OK again to exit.
You don't necessarily need Kickstart 3.1, as the file system Add/Update option lets you put a later version, overriding ROM code, in the startup area of your drive. Amiga International's web site has an 'experimental' v43 fast file system, supporting bigger blocks, enormous drives, and ATAPI CDs.
The table shows how this works in practice, with boot times in seconds for a given block size and buffer count. The test system used ShapeShifter 3.1, Mac OS 7.0, a 50 Mb hard file and an 800 by 600 chunk CyberGraphX display; PCX, Fusion and PC Task deliver very similar results.
Doubling the block size quadruples the space each buffer can control (twice as many blocks, each twice as big) and boosts transfer speed as the disk interface takes bigger gulps. There's a 'right number' of buffers for a given size of file. An extra 90 half K buffers don't help at all,while 120 two K buffers are enough for hard files over 100 Mb long!
Tiny files waste some disk space as they always occupy a whole number of blocks, and tired old programs like AmiBack may be confused, but the RAM versus time trade-off is massively improved. 60K or 240K deliver ten times the speed if you use 2K blocks instead of four times as many half K buffers.
Mac file formatsMac Files are divided into forks - rather than keep separate icon and program files, as on the Amiga, most files have a 'data fork' and 'resource fork'. Resource forks contain code, tooltypes, locale information and pointers to applications that created the data.
This split gives all Mac programs easily-customised windows, keys, graphics and text without affecting the underlying code. A wonderful tool, ResEdit, lets you hack up a custom system, so - contrary to prejudice - strait-laced Macs can be customised, although less than Amiga or Unix systems.
Handlers on the Amiga generally distinuish between forks by adding a prefix or suffix to the name. Macs support longer file names than Amigas, but this is rarely a problem. You can rename any file on a Mac by pointing under the icon, double-clicking, and editing the name.
Common archive formats for Mac files are .SIT - short for StuffIT, a shareware compressor - and .HQX. The latter files are expanded, rather than compressed, so binary data can be represented just with printable characters - rather like MIME or UUencoded files on Unix and Amiga. MacBinary is similar but shorter, using all eight bits without error checking.
LHA is available for Macs, and on our CD, but little used except to transfer files from an Amiga. ZIP is also supported, but uncommon, and sadly LZX is unknown to Macs.
Modern Apple applications are bloated by the inclusion of code for Power PCs as well as 68K Macs. Such 'fat binary' files contain both programs, and can be stripped to a fraction of their size if you know the bloated Power PC code is not required.
DocumentationBoth Fusion and ShapeShifter come with documentation in AmigaGuide form. Emplant had a printed manual, but Fusion has nothing but the inlay to get you started. ShapeShifter's manual is longer and more helpful than the Fusion one, but even that's an improvement on Drew's previous efforts, which tended to assume you had a working system, with scant help with set -up or diagnostics.
The Fusion guide includes a glossary for anyone still clueless about terms like 'icon', 'Mac' and 'hard drive' and troubleshooting answers to fifty questions, but it has no index and is utterly inadequate for a commercial product, expecially one that stops dead or crashes if not set up just right!
The Emplant manual was worse, but the product was simpler and at least it came printed on paper. It helps to convert Fusion's guide with a utility like Guide2Text, printing it out to ensure you've not missed anything. Ironically the best Amiga Mac emulator manual by far is that for AMax - well written and printed, with a seven page index and lots of practical advice.
Macs are easy to use, even by Amiga standards, but if you want to tweak the configuration you'll probably need help from a Mac guide, human or printed. The emulator documents make no attempt to introduce the Mac system or file organisation, but most of it is self-evident if you've used Amiga OS or PC Windows, which owe much to ideas pioneered on the Mac.
AppleGuide tries to replace printed documentation with hypertext, and fails for want of structure, detail and ease of use. Multitasking is feeble by Amiga standards. Bubble help, as in MUI, tells you the purpose of buttons your mouse pointer lingers nearby. Error messages are rare but typically useless - if a Mac program needs to issue a message, it's a design failure!
Mac OS 8 demands 16 Mb RAM and about 100 Mb just to install, though you can
trim the redundant PPC code with the 'fat stripper' utility. Typical games
require 8 Mb on the Mac side, supported by two to 8 Mb just for the Amiga.|
Without CPU-card expansion, Amiga users will struggle to make enough RAM available. Worse, all the memory needs to be in one contiguous block. Macs cannot cope with memory in 'fragments', as the Amiga system can, and often must.
Fusion's virtual memory support trades up to 767 Mb of hard disk space - and time - for real memory. Like all Fusion's wildest hacks, it's system -dependent and may be hard to set up, but crucial for compatibility with greedy programs like PhotoShop.
Without the support of MicroCode Solutions and Blittersoft, Fusion would be too 'bleeding edge' to be useable. It's a pig to start up and still needs more testing on the myriad potentially-suitable Amiga configurations. It's ambitious, clever and good value if you've got the time and patience to get to grips with it.
|On AFCD 20|