(image courtesy DayStar Digital)
(image courtesy DayStar Digital) |
The Unofficial Turbo 601 SiteEccentricities, Bugs & Solutions |
Introduction |
A to G |
H to O |
P to Z |
Return to Main Index | |||
27 April - Jubel Chen has sent some information about RAM Doubler.
8 April - Posted an update on the Agfa Scanner problem (which has not yet been sorted). Ed Binder sent some really useful info which includes a ResEdit hack for versions 2.08 and 2.09 of Agfa's FotoLook software which cannot be patched by the FLDriver SCSI Patch.
30 March - Jeff Walther has sent lots of information about various "eccentricities" he has encountered with SCSI Manager 4.3 since installing a JackHammer card. Jeff's experiences confirm my findings that using the Turbo 601 with SCSI Manager 4.3 can cause all sorts of unpredicatable "strangeness".
Jeff also reminded me that the Radius PhotoEngine H/W and S/W doesn't work with the Turbo 601.
3 Feb - Willi Murray has added some information about SCSI Manager extensions to the SCSI Manager 4.3 topic
2 Feb - Willi Murray's SCSI Manager 4.3 problem has been solved.
21 Jan - The functionality of Disk Release 4 of the DayStar Software has been clarified.
19 Jan - Jubel Chen has got his board back after sending it to DayStar for the ROM update for the 256 colours problem. It came with a new version of the DayStar Software and we've added a section on that topic.
11 Jan - Jubel Chen has sent info which should help solve the problem with Zip Drive Software.
10 Jan - DayStar are set to start shipping cards with the ROM update for the 256 colours problem on Monday 13 Jan.
9 Jan - Confirmation that SoftWindows 95 and the Turbo 601 are incompatible. We have received a report that getting the ROM update for the 256 colours problem is proving difficult.
5 Jan 1997 - More info added about SCSI Manager 4.3 problem.
30 Dec 1996 - Info about problems with SCSI Manager 4.3 and Agfa Scanners added.
This section describes problems that users have experienced with specific applications, control panels and extensions when using the Turbo 601.
Many of these problems occur when using Systems 7.5.3 or 7.5.5. and it is worth repeating here that:
DayStar do not, at present, support any System later that 7.5.1 running on a Turbo 601.
More information on this as well as a general discussion on System-related topics can be found in the MacOS Issues section of this web site.
Problems related to specific Macintosh models have been placed at the beginning of the A to G section.
Thomas Linn informed us that when using a Turbo 601 in his Mac IIsi, he ran into tons of crashes until he removed the rear expansion cover to provide better air flow. Bronson remembers that the fan on his old IIsi was rather small!
Thomas also reports that the 365 MB hard drive that was working fine in his IIsi, began to have many disk errors after installing a Turbo 601. Replacing that hard drive with a 170 MB hard drive seemed to make the problem better, but the problem persisted until a 40 MB (the one that was shipped with the IIsi) was placed in the IIsi. This seems a bit strange, and the reasons are not at all clear. It may be related to the overheating problem, and that the larger hard drives have higher power requirements, causing the computer to overheat faster. It may also be related to disk driver issues, but we don't really have to enough information to speculate usefully on this one!
DayStar have acknowledged two problems specific to these computers when a Turbo 601 is installed:
(i) DayStar's Turbo 601 FAQ states that when using internal video these machines cannot display more than 256 colours. See the Monitor Problems paragraphs below.
(ii) DayStar's System 7.5.3 Installation Tips and Issues FAQ states that if System 7.5.3 is installed on any of these machines fitted with a Turbo 601 then the 'floppy disk drive will operate improperly'. This problem is described in more detail in the MacOS Issues, Systems 7.5.3 & 7.5.5 section of this web site.
This isn't a problem caused by the Turbo 601, but it's worth noting nonetheless. Willi Murray writes:
I recently installed an FWB JackHammer SCSI accelerator in my Mac IIvi/Turbo 601. When SCSI Manager 4.3 (required for the JackHammer to work) was enabled in the Turbo 601 Control Panel the Mac couldn't communicate with the scanner, a two year old Agfa StudioScan IIsi. The scanner worked OK if SCSI Manager 4.3 was disabled.
I found a driver patch (FLDriver SCSI Patch) in Agfa's CompuServe forum which is intended for any PowerMac driving an 'older' Agfa Scanner. Apparantly 'older' Agfa scanners don't operate properly with the 'new' SCSI Manager 4.3 commands which the scanner driver issues when SCSI Manager 4.3 is enabled on a PowerMac (68k Macs and SCSI Manager 4.3 are OK). The patch modifies the scanner driver and forces it to use pre-SCSI Manger 4.3 commands. I patched the scanner driver as instructed and found that the scanner worked perfectly OK with SCSI Manager 4.3 after doing this.
Agfa UK's technical support staff confirmed my findings and suggested that I needed a firmware update (from version 1.5 to 2.3) for my scanner. I received the EPROM with the new firmware within four days of my telephone call (thanks to the folks at Agfa UK for this excellent service!), installed it straightaway, and unfortunately it didn't make any difference!
I'll continue using the patched driver meantime and post the final solution to the problem when it's sorted.
Note - the FLDriver SCSI Patch is only available from Agfa's library in their CompuServe forum - it's not available from any of their web sites. If you need more information about the FLDriver SCSI patch contact Willi Murray.
This problem has still not been sorted in spite of upgrading to the latest version of FotoLook (2.09) as suggested by Agfa Tech Support UK - a complete waste of £125. Furthermore, since the original posting on 30 December a number of people have confirmed this problem and it is NOT only confined to DayStar accelerated Macs and it affects all verions of FotoLook from 2.05 to 2.09 inclusive.
Here is a summary of the facts we have to date:
The Agfa FotoLook scanner driver cannot communicate with the scanner when either SCSI Manager 4.3 is installed AND/OR a when a second SCSI bus has been installed using a JackHammer (or similar). This occurs in either 030 mode or 601 mode.
If SCSI Manager 4.3 is disabled (remember that if a JackHammer is installed in a Turbo 601 upgraded Mac you will have to physically remove it before disabling SCSI Manager 4.3) then the FotoLook scanner driver works perfectly OK.
In addition, Agfa's SCSI ID Checker (similar to SCSI probe) cannot see ANYTHING on the Mac's internal SCSI bus when either SCSI Manager 4.3 is installed OR a when a second SCSI bus has been installed using a JackHammer (or similar).
Again, if SCSI Manager 4.3 is disabled or the JackHammer removed then SCSI ID Checker functions correctly and will identify all items on the internal SCSI bus.
This problem is NOTHING to do with the Turbo 601 as it also occurs when the Macs are in 030 mode. It clearly seems to be something to do with Agfa's software implementation.
Note that the FLDriver SCSI Patch described in the original posting will only patch FotoLook versions 2.05 to 2.07 inclusive. It will not patch FotoLook versions 2.08 and 2.09. I am indebted, however, to Ed Binder for describing a ResEdit hack which will get FotoLook versions 2.08 and 2.09 up and running if you have this problem (this ResEdit hack effectively does the same thing as the FLDriver SCSI Patch).
Ed writes:
The patch worked for me, albeit indirectly. Apparently it will not readily patch 2.09. I got an error about STR# 16515 not being as expected. So I fired up ResEdit and looked at both the patcher and the FLDriver 2.0 file. I found the STR# with that number (named *Custom Values) in the FLDriver file and saw a value there that said OLDSCSIMANAGER=0. I could see from the patcher resources that it was trying to put a 1 somewhere in the STR# 16515 resource, so I just changed that string to=1 instead of 0 and now the scanner works!!!!!!!!!!!!!!!! with the Jackhammer present and active.
So you can fix any version of the driver this way, even if the patcher won't do it for you.
I know we should not have to be doing this kind of stuff in the first place but at least it all plays together for me now. I don't agree with the AGFA explanation of faster SCSI Manager 4.3 or faster PPC/PCI Macs since this was happening to me on a IIci, with and without a Turbo 040, no PPC hardware at all, using the IIci's slow built-in SCSI bus (2 Meg/sec max with the Turbo 040). I don't think the scanner ROMs could have any effect here. Further AGFA's stand alone SCSI ID checker app would see nothing on the built-in bus, not even the Mac at ID7 or my old hard disk at 0, let alone the scanner.
Yet with no Jackhammer, all would look normal. My best guess is that AGFA is mishandling the SCSI info when there are multiple buses present and not seeing anything. Also supporting this is the fact that OmniPage would work fine with the Jackhammer present. It uses its own chooser based scanner driver. So if the scanner hardware was the problem, I'd expect OmniPage to have the similar troubles.
Anyway I am happy now. The scanner speed is acceptable too...better than no scanning at all.
Note again that Ed experienced the problem with and without the Turbo 040 installed in his Mac IIci.
I wonder if this problem is unique to older II-series Macs with SCSI Manager 4.3 or dual SCSI busses installed. I would have expected an outcry from users if this problem existed for owners of the newer PCI-based Macs.
If anyone has any more information about this, or has managed to get anything sensible out of Agfa I'd be really glad to hear from them.
All new Turbo 601 cards shipped up to Jan 1997 were supplied with Disk Release 3 of the DayStar Software. This comprises:
When Jubel Chen got his board back from DayStar following modification to fix 256 colours problem he got Disk Release 4 of the DayStar software. This comprises:
The ReadMe file for Disk Release 4 has been posted to this site.
Update (21 Jan)
Willi Murray received clarification from DayStar today about the functionality of Disk Release 4 of the Turbo 601 software:
Disk Release 4 software only adds functionality to Turbo 601 boards that have been modified to fix the 256 colours problem with IIvx, IIvi and Performa 600s. The Disk Release 4 software works with the modified boards to enable the 'Thousands' of colours option.
Other than the very minor bug fixes mentioned in the Disk Release 4 ReadMe file, the new version of the software offers NO new functionality for other Turbo 601 users.
If you don't have a modified board, you don't need it.
Disk Release 4 has not been posted to DayStar's FTP site.
Digital Storefront is a hardware/software 'Telephony' device for the Mac. Jim Tugman reports that in PowerPC mode, running MacOS 7.5.3 or 7.5.5, the Digital Storefront software has an error upon launch, with a dialog box that says 'Sound input device not available'. He also reports that this problem goes away when he uses System 7.5.1, and when he switches back to 68030 mode. This might be related to the Microphone problem reported below.
Certain applications (like TechTool by MicroMat) check the hardware of the computer to determine what type of Macintosh you are running. If you are using System 7.5.3 or 7.5.5 and a Turbo 601, such an application will report that you are using a LC 575 w\PPC (Gestalt ID 104). Apple assigns a new ID (called through the Gestalt manager) for every Mac that they release.We are not sure if Mac clones have a unique ID or not, but for whatever reasons Apple and/or DayStar decided to assign ID 104 to the Turbo 601. Even though you are not actually running a LC 575, that computer is the decided approximation of any Mac with a Turbo 601. This only started happening in System 7.5.3 because it was with this release that the Gestalt Manager started to return only a general description of the computer (i.e. Power Macintosh) rather than a specific identification. TechTool calls the hardware directly, we think, and this is why it reports back the LC 575 stuff.
If you use System 7.5.1 your machine will be identified as a PowerPC Macintosh IIvi, PowerPC Macintosh IIci... etc.
David Murray tells us that when he runs System 7.5.1 on his Performa 600/Turbo 601 the machine type is set to PowerPC IIvm (yes, M)!
Roman Brice brought to our attention the fact that the Turbo 601 causes problems with the microphone on his computer. DayStar's comment on this issue was (supposedly) that it would be impossible to fix the problem due to the low level changes in the ROMs by Apple.
DayStar's Turbo 601 FAQ acknowledges a problem which limits the display on the IIvi, IIvx and Performa 600 to a maximum of 256 colors even if enough video RAM is installed to display thousands of colours. This problem affects all Systems including 7.5 and 7.5.1. The FAQ has recently been updated to state that this '256 colours issue' can now be sorted by a component change. (Note that this problem only affects internal video, add-on NuBus graphics cards are unaffected by this problem and will function correctly.)
When Sigvard Svensson contacted DayStar about the issue, he got this response:
We have just released a hardware fix which will require us to upgrade the board with new ROMs. Leslie Gwin, our Tech Support Manager is compiling a list of those individuals who have contacted us regarding this fix. We will be contacting you to upgrade your board in the order in which we received initial contact from you. If you are interested in the fix please send a brief e-mail to Leslie at lgwin@daystar.com. Thank you for your patience. (MacFixIt 9 Oct 1996)
Note that this means that you can only get the Turbo 601 upgraded. DayStar never manufactured new boards with the fix. John Carson got this note from DayStar (dated 16 Oct 1996) pertaining to that issue:
In the IIvx, the thousands of colors is built in and we limit you to 256 colors. The Apple ROM found on our standard boards (for IIci and IIsi) do not support the colors version when installed into a IIvx. The cost to run a separate production run of IIvx versions with a new Apple ROM would make the end-user price excessive.
Update (9 Jan)
Sigvard Svensson got the following eMail from Leslie Gwin at DayStar on 10 Oct 1996:
I have some boards available for swap, what speed is your board? Please send your serial number, name, shipping address, phone number and fax number. I will fax back the return authorization.
For a number of reasons Sigvard's response to this eMail was delayed until 12 Nov. When he contacted DayStar on this date he
got an immediate response saying the fax should be sent later that morning. Nothing showed up, and a kind reminder ten days later have so far not resulted in anything...
So far Sigvard has been waiting nearly two months for his return authorisation. We would be interested to hear how this compares with other peoples' experiences.
Update (10 Jan)
We indebted to Jubel Chen for the following information, some good news for a change!
As of 6pm on Thursday, Jan 9, 1997, my Turbo 601 is on its way back to Daystar via FedEx.
This is for the ROM fix concerning the Turbo 601 with only 8-bit color even though there is 1MB VRAM on the motherboard.
Here is the deal. I got called by DayStar saying they are going to start shipping the replacement Turbo 601 on Monday. The sooner I send mine in, the sooner I get a new one. You can do it this way and it should be back shortly, probably within a week or so. If you can't spare the time WITHOUT your Turbo 601, Daystar is willing to ship you the new one if you provide a credit card. Upon receipt of your old card, they will immediately credit your card. The price of that is $499 + Tax.
BTW, Daystar is shipping 2nd Day Air and the shipping is covered. You only have to pay the shipping TO Daystar. I am not sure wether they will ship FedEx or UPS.
Update (19 Jan)
Jubel got his board back on Fri 17 Jan and reports that it is working very well. DayStar therefore appear to be turning the boards round very quickly.
Jubel's board came with updated DayStar Software and now returns different ROM version data.
After installing a Turbo 601 in his Macintosh IIci, Bronson found that the monitors control panel got a bit weird when using internal video. Now, the 'Options' box no longer lets him change the amount of memory he wants to allocate for internal video (the options are there, but they are mostly hidden by an improperly sized 'Options' window).
There have been a few reports of problems when using Netscape 3.0 on a Turbo 601 enhanced computer. We reckon that this probably isn't due to Netscape itself, but is more probably due to RAM Doubler or some other extension.
Netscape 3.0 Gold works fine on Bronson Trevor's IIci/Turbo 601.
You might not believe this, but Netscape 3.0 and 3.0.1 has NEVER crashed on Willi Murray's IIvi/Turbo 601 (it's true!).
QuickDraw GX doesn't seem to work at all. Bronson's computer crashed the first time it was started up with it installed under 7.5.3.
Thanks to Jeff Walther for the following:
I have aquired two Thunder IV GX 1360's through judicious net trading and have discovered (and had confirmed by Radius) that the PhotoEngine daughter card on the Thunder IV GX, which provides the Photoshop acceleration, is not compatible with the Turbo 601. You can install the card and the regular Quickdraw acceleration works fine, but if you attempt to load the Radius DSP extension that enables the PhotoEngine the machine will freeze during the booting process--just about exactly after the extension loads.
To reduce heat and save power, I removed the PhotoEngine daughter card from the Thunder IV GX. Radius confirms that this is okay to do. In fact, if you have a Thunder IV GX 1152, after you remove the PhotoEngine you will have a Thunder 24/GT.
RAM Doubler and Speed Doubler (Connectix Corp), cause multitudes of problems, none of which seem to be fixed in the newest versions available (RAM Doubler v2.0 caused Bronson's computer to lock up all together upon startup). Gary Zimmerman reports, however, that on his IIsi/Turbo 601, RAM Doubler 1.6.1 works fine under OS 7.5.5. He also tells us that Speed Doubler causes the LaserWriter icon in the Chooser to disappear (that could get annoying...!).
Another good bit of information and advice came from Don Fuller :
RAM Doubler 1.6.2 with System 7.5.5 now works well and seems more stable than it was with System 7.5.3. I only have 20 MB and regularly run PhotoShop and Navigator in large partitions over 12 MB. One culprit I found was a PhotoShop Acquire Plug-in for a scanner making memory demands.
Two areas that seem to make a lot of difference in stability are additional System and Finder Heap spaces. I have consistently used Now Startup Manager to reserve an extra 15-20% of System Heap. And, now have also used Finder Heap Fix 1.0.1 to conveniently set Finder Heap at 256K. I don't know if the Turbo 601 System Enabler or my scanner Acquire Plug-in make extra demands, or what's goin' on. But there has been a consistent, repeatable pattern of better stability with conservative, additional heap settings.
Jubel Chen reports that RAM Doubler 2.0.1 works fine with his IIvx/Turbo 601 MacOS 7.6.1 combination:
I have installed RAM Doubler 2.0.1 on my computer as well. I have been experimenting with the settings, from 20MBs to 60MBs. The best result seems to be the 20MB setting. Even though this setting doesn't give you anything more than your physical memory, the presence of RAM Doubler made RAM footprint from applications a lot smaller. Performance was pretty good with this setting as well.
He sent the this follow-up a few day's after he sent the original information.
I have been playing with the settings again. It seems that RAM Doubler 2.0.1 is stable enough when you are doubling or tripling your memory. Your performance does suffer quite a bit when you use the Triple Memory setting. However, I am not quite sure about the 1.5x or 2.5x (the in-between settings). One of my crashes, I am not certain if it was RAM Doubler related or not, ocurred right after I changed the setting from physical memory only to the 1.5x setting. At this moment, I am using 3.5x to test the stability. Oh yes, if you think 20MB is enough and don't want to run VM, still keep RAM Doubler installed. This will seriously reduce the RAM requirement on all PPC native/FAT applications.
Willi Murray recently installed an FWB JackHammer SCSI accelerator in his Mac IIvi. This requires SCSI Manager 4.3 to operate. Unfortunately Willi has discovered that when SCSI Manager 4.3 is enabled in the Turbo 601 Control Panel then any attempt to use his IIvi's floppy drive will invariably cause the Mac to freeze. The freeze can occur during any of the following possible operations:
More often than not, the IIvi will completely freeze when trying to mount an inserted floppy disk.
The floppy drive works perfectly OK when SCSI Manager 4.3 is disabled in the Turbo 601 Control Panel.
DayStar Technical Support were FAX'd about this on 30 Dec 1996.
Update (5 Jan 1997)
Installed MacsBug 6.5.3 to try and trap the problem. Found that when MacsBug is installed the floppy drive works much more reliably. Problem returns immediately when MacsBug is de-activated. When MacsBug is installed and the freeze occurs the machine doesn't jump into MacsBug, it still just freezes completely.
Update (2 Feb) - Problem Solved!
DayStar Technical Support eventually replied to my FAX and following an exchange of eMails this problem has been fixed. Unfortunately no single clear cause was identified. Everything worked fine after Willi re-installed his System software AND installed FWB's HDT 1.8s drivers on ALL his hard and removeable media disk drives. Prior to this, the FWB HDT drivers were only installed on the drives connected to the JackHammer card (2GB AV hard disk, 640MB Optical and 200MB Syquest). The hard disk on the internal SCSI bus still had the Apple HD SC 7.3.5 driver installed).
Hopefully the following general information relating to SCSI Manager 4.3 and the JackHammer card might prove useful to others:
Note - Willi Murray's recently purchased JackHammer card came bundled with FWB HDT version 1.8s. HDT v1.8s is OK if you're still using System 7.5.1 (which Willi is at the moment). If you're brave enough to use System 7.5.3, or 7.5.5, or even System 7.6 with a Turbo 601/JackHammer combination you should really upgrade to the latest version of HDT (currently 2.0.5).
Even if you're playing safe with System 7.5.1 however, it's a good idea to upgrade to the latest version of HDT (Willi ordered his upgrade today!).
Update (3 Feb) - Some Notes on the SCSI Manager 4.3 and 4.3.1 Extensions
The SCSI Manager 4.3 option in the Turbo 601 Control Panel enables/disables a version of SCSI Manager 4.3 that is in the Apple PowerMac ROMs on the Turbo 601 card. The separate SCSI Manager extension that is installed with Systems 7.5 and 7.5.1 is therefore not required and can actually cause problems when you are running in PowerPC mode with the ROM version of SCSI Manager 4.3 enabled. When the Turbo 601 is operated in PowerPC mode the SCSI Manager 4.3 (or 4.3.1) extension should be removed from the extensions folder or disabled with Extensions Manager (or similar).
The only reason you would want to keep a SCSI Manager extension is if you have a JackHammer card (or similar) in your Turbo 601 upgraded Mac and you want to boot in 030 mode. Under these circumstances use Extensions Manager (or similar) to enable the SCSI Manager 4.3 extension before restarting in 030 mode, and disable the SCSI Manager 4.3 extension before restarting in PowerPC mode.
If you need to keep a SCSI Manager extension for booting in 030 mode the correct one to use is SCSI Manager 4.3. SCSI Manager 4.3.1 which is mistakenly installed on Turbo 601 upgraded Macs by System Update 1.0 (System 7.5.1) is intended only for some Centris, Quadra 630 and 040 AV Macs and offers no benefit for 030-based Macs.
If you've installed System Update 1.0 to get System 7.5.1, you'll have the SCSI Manager 4.3.1 extension. If you need the SCSI Manager 4.3 extension you'll need to do a System 7.5 installation. The easiest way to get SCSI Manager 4.3 extension is to first delete the SCSI Manager 4.3.1 extension from the extensions folder. Next, do a 'Clean Install' of System 7.5 and then boot from a floppy. Move the SCSI Manager 4.3 extension from the extensions folder in the new 'System Folder' to the extensions folder in the 'Previous System Folder'. Then delete the new 'System Folder' and rename the 'Previous System Folder' 'System Folder' and restart.
At the risk of repeating myself, you only need to enable SCSI Manager 4.3 in the Turbo 601 Control Panel if you have installed a JackHammer card (or similar) to provide a second, fast, SCSI bus. Don't enable SCSI Manager 4.3 if you don't need it, because DayStar have confirmed that weird things can happen if, for example, SCSI Manager 4.3 is enabled without a JackHammer card being installed.
If you're not using SCSI Manager 4.3 you can safely delete any SCSI Manager extension that's been installed on your machine.
Note that from System 7.5.3 onwards the SCSI Manager extension functionality is integrated into the System file and that when you install System 7.5.3, or later, any SCSI Manager extension found on your machine will be deleted.
Update (30 March) - Jeff Walther writes:
I recently added a FWB/StreamLogic JackHammer with RAID ToolKit 1.8s. With SCSI Manager 4.3 enabled, and regardless of whether the JackHammer is installed, APS's Power Tools will not see any devices on the internal SCSI bus. It sees devices connected to the JackHammer just fine, but nothing on the IIci's bus. Drives that are already formatted function okay. I had a problem because I had a manual mount partition on an APS formatted disk that I soon discovered I could no longer mount, because the APS software no longer acknowledged the existence of any SCSI devices.
I have tried versions 4.0, 4.04, 4.07 and 4.09 of APS Power Tools. If I disable the JackHammer in the control panel, boot in '030 mode and disable SCSI Manager 4.3, APS PT still won't see any drives. If I remove the JackHammer but leave SCSI Manager enabled then APS PT won't see any drives. APS PT only returns to normal if I both remove the JackHammer and disable SCSI Manager 4.3.
If SCSI Manager 4.3 is enabled and the JackHammer card is not installed, then the driver for my NEC 3X CD-ROM drive will not load. It appears with a red X through it. If the JackHammer is installed, then the CD-ROM driver works fine. This is the CD-ROM driver that is based on Casa Blanca's product. It is version 5.0a. On the bright side, I have not had any trouble with my floppy drive.
Retrospect will not scan the internal bus for tape drives with the JackHammer installed. It will only scan the JackHammer bus. I have a 68 pin to 50 pin adapter cable with the top 18 pins terminated so I was able to move the tape drive to the JackHammer and there it works fine.
Retrospect sees all the hard drives on both busses for purposes of backing up from or restoring to just fine. It is only when it is scanning for a device to back up to or restore from (e.g. a tape drive) that this problem occurs. Dantz was wonderful and responded to my e-mail in a day. They called me and after a bit of diagnoses provided a fix. There is an undocumented option under the Configure window in Retrospect. By option-clicking on the Options under Configure a screen appears from which you can choose "SCSI". That gives you a box labeled "Enable Cousin ITT" which enables or when unclicked, disables use of SCSI Manager 4.3 by Retrospect.
Disabling this option, caused Retrospect to only scan my internal SCSI bus for tape drives. Since I don't intend to put any tape drives on the JackHammer bus this is just what I wanted.
BTW, when the tape drive was on the JackHammer bus, Retrospect couldn't load a driver for it, if there was a hard drive on the internal bus set to the same SCSI ID. For example, with the tape drive at ID2 on the JackHammer, and a hard disk at ID 2 on the Mac IIci bus, Retrospect couldn't load a driver for the tape drive, because it already had the hard disk driver loaded and of course that didn't work for the tape drive. This weird since they were on seperate busses. This problem goes away when the tape drive is moved to the IIci bus.
I have the following: IIci, Turbo 601/66 modified to run at 94 MHz, CPU fan stuck to the Turbo 601 heat sink, 4-4 MB SIMM's, 4-16 MB composite SIMM's (these have 32 chips each on them), a JackHammer, a Thunder IV GX 1360 sans PhotoEngine, and a Futura IISX currently installed. I have a Media Vision PAS 16 sound card, another Thunder IV GX and an Ethernet card that I occasionally use but can't install simultaneously because, tragically, I am out of slots. I usually use System 7.5.1. I have System 7.5 on another volume and I have recently installed 7.5.5 on a different drive. All three seem to work okay.
Bill Corea reports that he ran into problems using SoftWindows 95 on his Mac IIci/Turbo 601 setup. He got the following information from Insignia Solutions
If you need to use your DayStar (accelerator), you cannot use version SW 95...at all. DayStar will only work with SW 3.0. Also, you cannot install a lower version (ver 3.0) on top of SW95...Please call Customer Service for an exchange.
David Murray uses SoftWindows on his Performa 600/Turbo 601. He sent the following info:
I find SoftWindows 3.X.X runs very reliably although it is no speed demon. Windows 3.1 is quite usable (if you like that sort of thing).
I imagine the rare problems I have...are only the same software conflicts that any Mac user will encounter.
Update (9 Jan)
Tom Cox sent the following info:
When I tried to install SoftWindows 95 on my IIci with Turbo 601, it crashed. When I then contacted Insignia Solutions, the publisher of SoftWindows 95, the tech support guy told me that there was a recognized incompatibility between their product and the Turbo 601 upgrade. He claimed that Insignia had approached DayStar a number of times, at a variety of levels up to CEO, proposing joint work to resolve the problem. Apparantly DayStar didn't respond to Insignia's approaches.
We feel we must point out that this is only one side of the story. If this true however, it's rather worrying because it seems to imply that DayStar are reluctant to embark on any engineering work required to support the Turbo 601.
Stereo sound became a bit of a problem after Bronson installed the Turbo 601. Instead of the clean, crisp stereo sound that he had come to expect from his Mac, now when the computer plays stereo sounds, it sounds like a popping and clicking LP. He reckons the problem got better when he installed OS 7.5.5.
A work-around for this problem is a little extension called NoStereo. Even though it disables stereo output from your Mac, it does eliminate the clicking and popping caused by the Turbo 601. We have only tested it in Bronson's Mac IIci, but there is no reason why it shouldn't work in other configurations.
See RAM Doubler.
The Iomega Driver (v4.3) caused many problems when Bronson installed OS 7.5.5. Bronson has to use the FWB removable driver if he wants to use his Zip drive under 7.5.5. There is a 4.3.2 version of the Iomega driver available, but we don't know if it fixes the problem as Bronson prefers to use the FWB driver.
Update (11 Jan) - Jubel Cheng sent the following info:
It's not ONLY a problem between Turbo 601 and the Zip software, but between Zip software and ALL MacOS CPUs. There is way around this. Rename 'Iomega Driver' by adding 2 or more spaces before the name. This generally solves the problem. BTW, the latest version of Iomega Tools is 5.0.1. It can be downloaded from the Iomega Web site, the size is about 1.26MB download.