timg@cbmtor.UUCP (Tim Grantham ) (10/13/89)
I've spent the last week trying to get the A-max Macintosh emulator to work with the LUCAS/FRANCES combination on my A1000. Actually, it works fine with LUCAS -- it's FRANCES that won't work with A-max. Happily, I can report that with the help of a lot of people I have been able to get it work, and work well. My system is as follows: an A1000, LUCAS board with 12 MHz 68020 and 68881 parts, FRANCES board with 2 Mb of 70 nsec. DRAMs, an A1020 5.25" drive, a SystemGate M300 Mac compatible 800K floppy, and the A-max hardware. Note that I have nothing on the expansion bus, which probably explains why I can run the whole thing at 20 MHz with 1.5 wait states (well, 1 most of the time, 2 some- times). The problem arises because the Mac operating system in the 64 Kb and 128 Kb ROMs uses the upper 8 bits in addresses for private things. But the FRANCES board also uses the top 2 bits (A31 and A30): the FRANCES address decode PAL conditions A31 with other jumpers to program the DRAM controller. A30 is used when addressing the memory if it has been put outside of the regular Amiga memory map. When the Mac OS asserts A31, it may cause the DRAM controller to be inadver- tently reprogrammed; if both A30 and A31 are asserted, the FRANCES decode PAL will say ``this isn't a FRANCES address'' and the Mac OS will try to write to memory that doesn't exist. Brad Fowles suggested I try switching A30 and A31 at the FRANCES decode PAL to ground, after the initial programming of the DRAM controller (which is done with Eric Haberfellner's AFM program), like this: ______ ________ | | | | FRANCES | | 68020 PAL | | |______________________ \__________|A30 | \ | | / | |_________\____________ \__________|A31 | \ / | | / \ 1K Ohm | | \ --- | _____| / - |_______ \ 1K Ohm --- - In other words, the switches are closed during normal Amiga operation, open during Mac OS operation. During Mac OS operation, the FRANCES PAL sees A30 and A31 as always zero. The timing of the change-over proved to be crucial. A31 must be switched out after the AFM memory configuration program is run and before Mac OS operation begins. A30 must be switched out *after starting the A-max program but before the A-max program loads in the Mac ROMs*. I don't know why this should be so; neither does Simon Douglas, the programmer of A-max. But unless A30 is switched out *after* starting A-max, A-max will not find the FRANCES memory, *even though Exec knows the FRANCES memory is there!* My hardware mod, at this point, consists of bending up pins 8 and 9 on the FRANCES PAL, and running wires from those pins and from their respective sockets to a DPST switch and the resistors. Then, once I have A-max's con- figuration screen up, I through the switch and command A-max to start loading the ROMs. I am now able to run the ROMs out of either the WCS RAM or out of 32-bit RAM. I have been able to run numerous Mac programs without problems, including Adobe Illustrator (only under Finder, I don't have enough memory to run it under Multifinder), Quark Express, SmartCom, MacDraw, Paint 2.0, Microsoft Word, Freeterm, etc.,. I have been able to run load and run several applications under Multifinder. Ok, I lied: two problems. I have not been able to print PostScript files generated by Mac applications on a NEC PostScript laserprinter; and sometimes my Mac-compatible floppy cannot read files when the Mac ROMs are running out of 32-bit RAM -- it reads them fine when the ROMs are running out of the WCS. This is probably some kind of timing problem with either the floppy or the emulation software. I'm still working on rough benchmarks for this system but I can report one preliminary result. The operation consists of a blend operation with 500 steps between two 100-unit diameter circles, 300 units apart, done in Adobe Illustrator. On a Mac II, equipped with a math chip, this took 1:52. On my system it took 4:54. On a standard A2000, this took 13:10. (this is minutes:seconds). This test does not require any screen refreshes (except for the ticking watch icon) and does not require any disk I/O, so I beleive it's a fair comparison of CPU performance. I hope this message is reasonably clear. Maybe if Brad Fowles sees this, he can correct/elaborate. Thanks to Brad Fowles, Eric Haberfellner, Bruce Becker, Doug Lee, Craig Hubley and Paul Bosacki for their help. (and Simon Douglas, too). Tim.
johnf@stew.ssl.berkeley.edu (John Flanagan) (10/17/89)
In article <137@cbmtor.UUCP> timg@cbmtor.UUCP (Tim Grantham ) writes: <...> >The problem arises because the Mac operating system in the 64 Kb and 128 Kb >ROMs uses the upper 8 bits in addresses for private things. <...> Wait, let me get this straight: Apple used the upper 8 bits of the address for DATA? What, did they hire European hackers to write their OS? :-) (Note smiley -- no offense intended to Europeans; cf. the perennnial discussion on programming practices :-). Didn't they read the Commodore programming guidelines from the first DevCon? :-) John Flanagan Space Sciences Laboratory johnf@sag4.ssl.berkeley.edu University of California (...!ucbvax!sag4.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 642-7635