Unable to install Daynaport drivers

[snhirsch]

My ZuluSCSI Slim is connecting to wifi without any problems (at least that's what is reported in the log), but any and all attempts at installing the Daynaport drivers result in a system crash (at worst) or simply closing the "Unknown" app with "Error 1".

I've tried two different copies of the installer diskette with similar results.

The machine in question is an SE/30 with 2MB ROM Simm (IIsi firmware) and System 7.5.5 installed. It's otherwise running properly.

Any suggestions for troubleshooting this further?

[aperezbios]

@snhirsch not off the top of my head. Without knowing which driver you used and where you sourced it from, it's impossible for us to attempt to replicate.

I've moved this to a Q&A Discussion, as does not appear to be directly related to ZuluSCSI firmware. We can continue the dialogue there.

[snhirsch]

The driver installer is the one you've linked to from the installation instructions (MacGarden). It expanded and mounted with no complaints, so not obviously corrupted.

[aperezbios]

@snhirsch Thanks, can you please provide a copy of the log file your ZuluSCSI generates?

[snhirsch]

Sure, here's the log:

[12ms] FW Version: 25.02.11-release Feb 11 2025 17:58:58
[12ms] DIP switch settings: debug log 0, termination 1
[12ms] SCSI termination is enabled
[12ms] Flash chip size: 2048 kB
[12ms] SCSI target/disk mode selected by DIP switch, acting as a SCSI disk
[30ms] SD card detected, FAT32 volume size: 30424 MB
[31ms] SD MID: 0x03, OID: 0x53 0x44
[31ms] SD Name: SK32G
[31ms] SD Date: 11/2024
[31ms] SD Serial: 0x83D33A56
[40ms] Speed grade set to Default, skipping reclocking
[41ms] Reading configuration from zuluscsi.ini
[50ms] Active configuration:
[50ms] -- SelectionDelay = 255
[50ms] -- EnableUnitAttention = No
[50ms] -- EnableSCSI2 = Yes
[50ms] -- EnableSelLatch = No
[50ms] -- MapLunsToIDs = No
[51ms] -- EnableParity = Yes
[93ms] Finding images in directory /:
[97ms] -- Opening /HD1.img for id:1 lun:0
[521ms] ---- Configuring as disk drive drive
[522ms] ---- Read prefetch enabled: 4608 bytes
[526ms] -- Opening /NE4.img for id:4 lun:0
[527ms] ---- Configuring as network based on image name
[531ms] -- Opening /HD0.img for id:0 lun:0
[579ms] ---- Configuring as disk drive drive
[580ms] ---- Read prefetch enabled: 4608 bytes
[582ms] -- Platform supports ROM drive up to 1468 kB
[582ms] ---- ROM drive image not detected
[582ms] SCSI ID: 0, BlockSize: 512, Type: 0, Quirks: 1, Size: 524336kB
[583ms] SCSI ID: 1, BlockSize: 512, Type: 0, Quirks: 1, Size: 2097152kB
[583ms] SCSI ID: 4, Type: 6, Quirks: 1
[1448ms]  
[1448ms] === Network Initialization ===
[2313ms] Wi-Fi MAC: 00:80:19:08:E3:67
[2313ms] Connecting to Wi-Fi SSID "TP-Link_44C4" with WPA/WPA2 PSK
[2494ms] Clock set to: 133000000Hz
[2494ms] Initialization complete!
[5239ms] Successfully connected to Wi-Fi SSID "TP-Link_44C4"
[9771ms] Toolbox enabled = 0

In the interim, I found a different diskcopy image of the Daynaport installer that does start and run. However, it fails to detect the emulated hardware. I tried forcing the installation of the SCSI driver by choosing 'Custom'. After doing that, the 'Alternate Ethernet' device showed up in the TCP/IP dialog, but it is not functional.

[aperezbios]

@snhirsch thanks, everything appears to be configured correctly on the ZuluSCSI, so we can rule that out as a possible cause. Are there any other devices on the SCSI bus, or is the ZuluSCSI the only device present? If it is not the only device, please ensure you do not have a SCSI ID conflict.

[snhirsch]

The only physical device on the bus is ZuluSCSI. It has hard disk images defined as Id 0 and 1 (1 is the boot drive) and the DaynaPort device as ID 4.

[snhirsch]

Figured it out... There were a number of issues:

1. There's something wrong with the image at MacGarden. Attached is a Dayna installation diskette that runs properly on System 7.5.5

2. The installer was unable to see the emulated Daynaport SCSI device because I had defined a specific disk vendor and product name. This was done while initially setting up the ZuluSCSI as the boot device. For some reason it refused to boot without that setting. Problem is that the ZuluSCSI firmware then blindly applies that configuration to all devices including the network device (NE4.img) which showed up under a SCSI test program as a Quantum Fireball hard disk (!). Once I removed that stanza from the .ini file the installer was able to see the device with it's proper name. I would strongly suggest you consider a code change to ensure that a disk device definition will never be applied to an NEx.img device file.

3. After updating .ini, the Dayna installer was able to see the device but refused to run the "Easy" install, complaining that it couldn't replace a file called 'Network'. I was unable to find such a file on the system volume. Finally I selected 'Custom' install and told it to only install the SCSI port driver. That finally did the trick and networking is operational.

Hopefully this information will be useful in the event that others run into any/all of these roadblocks. In addition to requesting a user's .ini file you should probably ask them to run a tool that identifies and names all devices on the SCSI bus. I used Alliance Power Tools, but there are plenty of other such apps out there.
DaynaPORT_7.5.3-DiskCopy6.zip

[aperezbios]

I would strongly suggest you consider a code change to ensure that a disk device definition will never be applied to an NEx.img device file.

Completely agreed. We should absolutely implement some sort of lock-out mechanism. That said, I would strongly recommend against setting any global device/vendor strings ever, unless you truly need to. You can accomplish something similar by using the "System=Mac" directive instead. The whole reason why that setting exists is to allow for what I suspect you were attempting to accomplish, in a much more user-friendly one-line way.

[snhirsch]

When I first brought up the Pico Slim I used 'System=Mac' and 'Quirks=1' settings and formatted the new device using Alliance Power Tools (which also installs a driver). I was able to copy the contents of the original hard drive to the new volume, but that volume absolutely refused to boot after setting it in the boot picker and restarting. Then I got into "flail around" mode and made two changes for the next round: Re-init the Pico volume with a patched Apple SC HD setup application - and - added that stanza to Pico .ini. Since it now works fine with the disk definition removed I think it's clear what the real answer was.