Changes to V3.16 (08/30/93) -------------------------------------------------------------------------- * Corrected the timing for sound support. Let us know how it works! * Corrected a problem with v3.16 that would not let the emulation allocate any 32 bit memory if your system contained 8 megs or less of system memory. ************************************************************************** Changes to V3.16 (08/30/93) -------------------------------------------------------------------------- * Added full stereo sound support. *NOTE* There is a stereo/mono jumper on the EMPLANT hardware (consult your EMPLANT hardware manual for location). You must set this jumper to stereo in order for the MAC to think it is capable of producing sound through BOTH channels, otherwise, only the MAC's LEFT channel will be used. The emulation will always output sound to the Amiga's LEFT AND RIGHT channels, even if the jumper is set to mono mode. Sound support is selectable in the TASK CONTROL menu option. The default setting is 'ON'. The emulation allocates ALL of the Amiga audio channels. This means that when the emulation is running, and you have set 'Sound Support' to be 'ON', the Amiga will *not* be capable of producing ANY sound. There are some known problems with sound. We are working on these problems right now. The problems have to do with interrupt timing and the speed of the Amiga. Because everybody uses a different type of Amiga (A3000/4000/040 boards/etc.) it is very difficult to calculate the relative timing necessary for the EMPLANT hardware to match the system it is being used on. 'Close' has worked in the past, but it needs to be perfect for the sound interrupts. One more reason why a 'software only' version of our emulation is not possible. All of the interrupt timing is handled by the EMPLANT hardware to insure that all interrupts happen at the proper time, and in the proper sequence. If you are experiencing 'Bus Errors' when attempting to use a program with sound, please let us know what program it is. This will greatly speedup the correction of this problem. As many of you have probably heard, there was at one point a v3.15 software released to beta testers. We have only 6 beta testers outside of our company, and apparently one of them gave it to somebody they shouldn't have. So, as a result, we are forced to no longer use beta testers outside of our company, which will cause longer time periods between updates. * Fixed a *very* serious problem that we have had since the very first release of our emulation software. If you have a 12 meg or 16 meg (FAST memory, we don't count CHIP memory) system, and you attempted to use too much memory, and you did *not* get a warning message telling you that you have selected too much memory, then the graphics data (amongst other things) was probably corrupted when Finder appeared. The MAC's memory ALWAYS starts at location $0. The maximum amount of memory that a 256K ROM'd machine can have is 8 megs ($800000). If the memory was allocated at $400000 (common with a Picasso video board) and you selected 4 megs of memory for the emulation, the ROM image and possibly the video data would end up outside of the $800000 limit. We wrote a routine to fix this problem, but it was never called! We never noticed any serious problems due to the routine never getting called. (This is rather amazing since anytime memory was used outside of the 8 meg boundry, the entire system was only a wrong keystroke from disaster). * Corrected and interesting problem with keyboard and mouse interactions. While using PhotoShop, a customer noticed that if you held the space bar (hot key for the 'hand' used for dragging laso'd data) and attempted to move the mouse (actually dragging the data), the mouse would not move. Further investigation lead us to the problem.... we forgot that the Amiga keyboard generates repeated keys. So, we were passing the same key down message over and over to the MAC when there was no key up message. The MAC became confused and the ADB went into a reset state, halting the mouse. EVERYTHING that uses the keyboard is *much* better and less CPU intensive than before. Games are noticeably quicker at keyboard response (Maelstrom, for example!). * Added support for the Piccolo and EGS/Spectrum video boards. NOTE: The screen name must be defined as the following for EITHER the Piccolo or the EGS/Spectrum board (same driver for both boards): PICo:VGA 640x480 PICo:VGA 1024x768 PICo:VGA 1280x1024 * New HardKickMMU and SoftKickMMU. There is no longer a HardKickExt version for people with extended memory. It is now built into the HardKickMMU program. THERE HAVE BEEN REPORTED PROBLEMS using these latest MMU programs with Progressive 040 boards. We are trying to figure out what we 'broke'. We don't have a Progressive board ourselves, so we are flying blind here. DO NOT DELETE your old version of Hard/SoftKickMMU if you have a Progressive 040 board. The latest versions of Hard/SoftKickMMU are *required* for using the Piccolo or EGS/Spectrum boards. * New RsrvMem37ii written to allow more CPU time for MAC deferred tasks. Deferred tasks are most commonly used for sound drivers. If there are no deferred tasks, CPU usage is normal. Real MACs will very often skip audio or produce weird noises when there wasn't enough CPU time to keep the audio in sync. * Increased the speed of the 'PicassoVideo' driver's 16 and 32 bit modes by 5%. Not a big deal, but it was easy enough to do. * 256K of memory is now reserved as 'protection' against unwanted weird things happening (64K was previously reserved). The problem we have heard of is when a customer has a device selected in the DEVICE menu that allocates a cache for itself. If the cache is too large (or if you have a lot of devices selected), you could easily exceed the 64K saftey margin we had before. * EVERYONE REJOICE!! We found the problem that has been haunting people since the v2.1 to v2.2 update. We found the nasty problem that would cause the Amiga's serial.device to 'hang' (sometimes the Amiga would hang/crash too). The Amiga's level 6 interrupt handles the serial.device's incomming data. Well, since we take over the level 6 vector (nasty but necessary), we check the pending interrupt and see if it was for the Amiga or for the MAC and handle it accordingly...wrong. The only time we were checking the Amiga's level 6 is if the MAC also had a level 6 pending. Since we have all of our systems AppleTalk'd together, a level 6 interrupt is always happening on the MAC side, and so the Amiga side got processed too...thus, we never could duplicate this mysterious 'lockup' problem reported by so many customers.... that is until Jim forgot to plug in an AppleTalk connector after comming back from a show in Las Vegas....attempted to log onto GEnie... whamo! Crash! $@%#^!@# ... fixed. :-) Another note about modems: If you are using a hardware handshaking cable on the EMPLANT's serial port, please remember to set your modem to ignore DTR transistions. This is the same for a real MAC too. You need to use this string to setup the DTR correctly: AT&D0 * Included 'empscsi.device' and 'empscsi.amhd'. 'empscsi.device' is a SCSI device driver that uses EMPLANT's SCSI interface. Currently, devices do not automount with this driver. This will change. Follow the documentation in EMPLANT's Hardware User's Guide. The 'empscsi.amhd' file allows customers using AMAX to use EMPLANT's SCSI interface for their hard drives. ++++++++++++++ A T T E N T I O N P L E A S E +++++++++++++ There have been some drastic changes made to our emulation software in preparation for the next release (32 bit clean ROM support). * Our emulation is no longer a MAC II/x/cx machine. Our emulation is now a 'GENERIC' MAC emulation. When you now go to 'About this Macintosh' you will probably not find 'MAC IIx' listed as the machine type. The speed of your emulation is computed, and the equivalent MAC machine type is displayed. For example: A3000/25Mhz machines will show up as 'Macintosh IIci', A4000/040 machines will show up as 'Quadra 700'. This is based on the speed of the emulation running on your machine, so if you have something intensive running in the background on the Amiga side, and you start the emulation, your machine type just might be different (slower MAC). * The 'Total Memory' and 'System Memory' values shown in 'About this Macintosh' are now correct. * You can NO LONGER SELECT 'CHIP' or 'RANGER' MEMORY TYPES. The MAC does not have different speed memory, and people have been putting things like the ROM image into CHIP memory. The emulation crashed (not right away) because of this. So, you are now limited to using either 16 bit or 32 bit memory. It is *highly* recommended that you use 32 bit memory if you have it!! * Added MAC IIci/si and Quadra hardware bit information. The emulation is now setup to report the various hardware found in the 512K and 1 meg (Quadra/Centris) ROMs, even though our emulation uses only 256K ROMs. * Fixed a bug in the Converter program that caused files created with the old converter format to not load/write properly.