By Michael Webb, Editor-in-Chief, MikeWebb@CompuServe.COM
It is fairly inevitable with computers that difficulties will come up from time to time. I've seen a few of them in my time with this A4000T, and while I've been able to solve most problems quickly, some have proven obstinate, and may be a legitimate concern for anybody considering buying an A4000T. Many of the things I cover here are mentioned elsewhere in this review, but not in this context, and probably not in detail.
The first such problem I would like to mention is the one which I have found most disturbing. Sometime in the last few months, I was attempting to install AmigaOS 3.1 onto a RAD: recoverable RAM disk, and so for the first time with the A4000T, began to boot from the AmigaOS Install floppy. Shortly into the boot, before anything appeared onscreen, a crash occurred. This proceeded to recur every time, even with a different AmigaOS 3.1 Install disk. I disconnected the second floppy drive and tried various jumper settings on drive DF0:, but nothing changed. I eventually made a copy of the Install disk and experimented with the Startup-Sequence, and determined that the crash was occuring at the invocation of SetPatch. I copied the SetPatch command over from the Workbench disk, which does boot properly, but there was no change. If I invoked SetPatch at a later time instead, however, the crash did not occur. This is among the most bizarre of all computer problems I have ever seen, and I have no idea what it means. I have been unable to reach Software Hut technical support by phone, as the line has always been busy, and they have yet to respond to an e-mail message I sent over a month ago. If an answer to this problem ever surfaces, I will publish it here. Furthermore, if anybody out there knows a possible explanation, please feel free to write to us.
Continuing on the subject of floppy drives, I have had a variety of problems with the disk subsystem. When I ordered the A4000T, I asked for a high-density floppy drive to be added, but instead, they took out the double-density drive and put the high-density one in its place. I had them send the original, and I had to install it myself, not what you would call an easy task. Physically attaching the drive was easy enough, but because the only small power connector was already in use, I had to dig up an obscure adapter to connect the second floppy drive to a larger power connector. Subsequently, the second drive did not work at all until I experimented with both drives' jumper settings, which were, incidentally, completely undocumented. For months, I periodically got errors while formatting in either drive (especially while having both do so simultaneously), and using high-density floppies was extraordinarily flaky. As I mentioned above, one day, I took apart the machine and did all manner of experiments with the floppy drives, including disconnecting one or the other and changing jumper settings. This was mainly an attempt to isolate the source of the Install disk problem, but that failed, and I put the system back together exactly as it had been, jumpers and all. However, from that day forward, the floppy system worked much better, even with high-density disks. But still, there are occasional problems.
Along with the unanswered, I will include here the "partly answered." When I first got the machine, instead of installing four 4-MB SIMM's on the motherboard as I had asked, Software Hut had placed a single 16-MB SIMM on the CyberStorm. I arranged an exchange, and proceeded to install the four SIMM's, which was easy enough. But when I booted the system, 12, not 16, megabytes of the memory were available. I tried removing them one by one, and isolated what I thought was the bad SIMM. To verify this, I placed it in a different socket, but then it worked! I thought I had a bad socket then, but when I put the now displaced SIMM in the suspect socket, it too worked, and all 16 MB were available. I didn't want to mess with it from then on, seen as how it finally worked right, but a possible explanation I heard suggests that minute timing differences among the SIMM's could cause a recognition problem depending on the order in which they are polled, so to speak. I don't know if that's true, but it's the best reason I've heard so far.
A second quirk apparently related to memory was a strange jumpiness in the mouse pointer that disappeared when certain applications, such as IBrowse, were running. This occurred as long as I had only 16 MB of fast RAM via the motherboard sockets; after I added a 32-MB SIMM to the CyberStorm board, the mouse pointer hardly ever jumped at all, and when it has, it has generally been attributable to use of the 68040 and 68060 libraries without CyberPatcher running (after 68881/68882 instructions not present in the 68040/68060 FPU have been used).
When the machine was new, after we installed the "omitted" memory and floppy drive, the system failed to boot. Completely. There were no boot colors, no boot menu, nothing. After experimenting with various connections, we found something that caused the initial colors to show up, anyway, and when we disconnected this cable (which turned out to lead to the hard disk), we finally got the familiar boot animation. When we reconnected the hard disk, everything worked again. The problem repeated itself, however, the following day after the system was moved to a new location. When I called Software Hut, they told me this is actually not an unheard-of problem, and that it could be averted if anti-static material were wedged between the processor card and the drive frame. I haven't done this, but the system has been moved twice again since that time, without further complications.
I'm not going to dwell on software problems, but one I consider worthy of mention concerns the public domain System Prefs Editor, which allows things like CPU caches, memory access speed, and the audio filter to be set via a GUI. One day, this program began to not run at all whenever the computer booted from my current system partition. This isn't an uncommon type of problem, but when I carried out the usual troubleshooting procedures (such as disabling WBStartup and User-Startup, and commenting out any added lines in the Startup-Sequence), nothing in particular proved to be the culprit. I can't think of any library, device, or handler I added that might be at fault, and I'm not big on making complicated changes to the system. Short of reinstalling the OS, I suppose I could track down the problem by systematically restoring original components, but I frankly haven't felt motivated to make that large an effort for one small program. If anybody knows of a common problem with this preferences editor, again, please feel free to write to us. I will publish any useful information, along with credit for the source.
One day, when I was experiencing that familiar syndrome caused by having more memory than ever before, I decided to use the AmigaDOS "LoadResource" command to preload various devices and libraries. Unfortunately, when I first rebooted after making these changes, the system experienced one of those nasty crashes that temporarily invalidates the hard disk (probably indicating that something was getting written to the disk at the time). I was unable to isolate the specific resource that was causing this, and I didn't consider it particularly wise or productive to repeatedly invalidate my hard disk in an attempt to do so. So I gave up on that, and just removed all the instances of "LoadResource." If I have time to kill one day, I may try adding some resources one-by-one, but for now, the question remains.
The last problem I am going to mention here actually has been solved, but it sure was a doozy, and I'd like to save other people some trouble if possible. Anyway, I am a registered user of ShapeShifter, one of the current software Macintosh emulators. I had set up a nice, useful Mac system on the A500, and thought I'd try out the emulation on the A4000T. From the first moment, this was problematic. Rather than outlining all the steps I took in trying to isolate the problem, I'll get to the root of the matter: if you have an A4000T with a CyberStorm MKII 68060 board, don't try to use Apple's System 7.0.1 under ShapeShifter. This may very well be universally true of 68060's, but I cannot verify that. The first suggestion to users of phase 5 68060 boards for dealing with ShapeShifter problems is to disable CyberPatcher, but believe me, this is one of the first things I tried. The problem is a tricky one, because in my situation, most Mac applications crashed under 7.0.1 (which has functioned perfectly on the A500 with its 68030) on the A4000T, and this includes installers for newer versions of the Mac OS. This also precludes using many popular public domain ShapeShifter boot disks. What you have to do is boot from a Mac OS Install floppy or CD-ROM (which I did; this involves using the empcd.device as described in the ShapeShifter documentation), with some version other than 7.0.1. I don't have a whole list of what works and what doesn't, but 7.5 and 7.6 have both worked. If you do use 7.5, be sure to download an update to 7.5.3 or 7.5.5 from an Apple FTP server or forum (if you are with an online service that has one), because 7.5 is very flaky. Incidentally, I recently purchased FUSION, the other current Mac emulator, and I have not yet determined whether System 7.0.1 will work with it on a 68060. Information about FUSION seems to indicate that it puts a special focus on processor compatibility, so I wouldn't be surprised if 7.0.1 would work.