Duo Dock Strange Boot Icon (Picture)

[jmacz]

The TL;DR for this thread thus far:

• The icon shown in my first post in this thread is related to SCSI and is some type of indicator that the dock is encountering something it does not expect while looking for a SCSI device ID = 1 (which is what a dock with a hard drive normally would be set to).
• The icon is found inside the Duo Dock ROM (which is readily available) at offset 0x0e4e (second frame at 0x0e4e + 128 since it's animated).
• The code that renders this icon begins around offset 0xfefe0d68 in the Duo Dock ROM.
• The SCSI calls that are causing the delay begin around offset 0xfefe0de2 in the Duo Dock ROM.
• The problem seems to be how a ZuluSCSI installed inside the Duo is responding to these SCSI calls against selection ID = 1.
• Current work around is to have a second blank or populated HD at ID = 1 on the ZuluSCSI. It's not enough to rename the only drive image to be ID = 1 as that did not work. It must have an ID = 0 and a second image at ID = 1.
• Tips on sniffing out bitmaps in ROM images from @joevt in post #24.

 

[dougg3]

That's really interesting. If I'm not mistaken, the dock's SCSI (and its external SCSI connector) is a different physical bus than the internal hard drive SCSI, because the docks have their own SCSI chips and none of the pins on the dock connector have anything to do with SCSI. So it sort of makes sense that the bus reset you see on the external bus doesn't show up on the internal bus at the same timestamp.

I was going to suggest trying to sniff the SCSI traffic going to the physical internal PowerBook hard drive using an external powered ZuluSCSI, but I don't think that'll work because it's a different physical bus so the traffic won't show up there.

Is there any way to keep the internal ZuluSCSI powered when you try it with only an HD0 image, to totally be 100% confident it's not a startup timing issue with the ZuluSCSI taking too long? I'm wondering if it's trying ID 0 really fast at startup, the ZuluSCSI's not ready, then it falls back to trying other IDs or something. I'm just throwing ideas out there, not really sure. It's just bizarre to me that in the case of only a single internal drive with ID 0, a physical hard drive would work fine but the ZuluSCSI would have the huge delay.

 

[jmacz]

Yeah, very weird.

Let me try having it powered externally to see what happens.

 

[jmacz]

With external power provided to the ZuluSCSI sitting inside my Duo (no other SCSI devices) and with this Zulu only having a single HD0.img, it works fine.

[12ms] Platform: ZuluSCSI RP2040
[12ms] FW Version: 25.03.19-release Mar 19 2025 16:54:38
[13ms] SCSI termination is determined by the DIP switch labeled "TERM"
[14ms] Flash chip size: 16384 kB
[14ms] SCSI target/disk mode selected by DIP switch, acting as a SCSI disk
[21ms] SD card detected, FAT64 volume size: 29548 MB
[21ms] SD MID: 0x27, OID: 0x50 0x48
[22ms] SD Name: SD32G
[22ms] SD Date: 2/2024
[22ms] SD Serial: 0x7748C502
[23ms] Speed grade set to Default, skipping reclocking
[24ms] Reading configuration from zuluscsi.ini
[25ms] Active configuration:
[25ms] -- SelectionDelay = 255
[25ms] -- EnableUnitAttention = No
[25ms] -- EnableSCSI2 = Yes
[26ms] -- EnableSelLatch = No
[26ms] -- MapLunsToIDs = No
[26ms] -- EnableParity = Yes
[72ms] Finding images in directory /:
[73ms] -- Opening /HD0.img for id:0 lun:0
[73ms] DBG ---- Image file is contiguous, SD card sectors 24640 to 1560639
[74ms] ---- Configuring as disk drive drive
[74ms] ---- Drive geometry from image size: SectorsPerTrack=60 HeadsPerCylinder=16 total sectors 1536000 (divisible)
[75ms] ---- Read prefetch enabled: 8192 bytes
[77ms] -- Platform supports ROM drive up to 16028 kB
[78ms] ---- ROM drive image not detected
[78ms] SCSI ID: 0, BlockSize: 512, Type: 0, Quirks: 0, Size: 768000kB
[87ms] Clock set to: 125000000Hz
[87ms] Initialization complete!
[20878ms] DBG BUS RESET
[25888ms] DBG -- BUS_BUSY
[25888ms] DBG -- BUS_FREE
[26850ms] DBG -- BUS_BUSY
[26850ms] DBG -- BUS_FREE
[27814ms] DBG -- BUS_BUSY
[27814ms] DBG -- BUS_FREE
[28778ms] DBG -- BUS_BUSY
[28779ms] DBG -- BUS_FREE
[29743ms] DBG -- BUS_BUSY
[29743ms] DBG -- BUS_FREE
[30708ms] DBG -- BUS_BUSY
[30708ms] DBG -- BUS_FREE
[31186ms] DBG -- BUS_BUSY
[31186ms] DBG -- BUS_FREE
[31664ms] DBG -- BUS_BUSY
[31664ms] DBG -- BUS_FREE
[32142ms] DBG -- BUS_BUSY
[32142ms] DBG -- BUS_FREE
[32620ms] DBG -- BUS_BUSY
[32620ms] DBG -- BUS_FREE
[33576ms] DBG -- BUS_BUSY
[33576ms] DBG ---- SELECTION: 0
[33577ms] DBG ---- COMMAND: Read6
[33577ms] DBG ------ OUT: 0x08 0x00 0x00 0x00 0x01 0x00
[33578ms] Toolbox enabled = 0
[33578ms] DBG ------ Read 1x512 starting at 0
[33579ms] DBG ---- DATA_IN
[33580ms] DBG ---- Total IN: 512 OUT: 0 CHECKSUM: 31398
[33580ms] DBG ---- STATUS: 0 GOOD
[33585ms] DBG ---- MESSAGE_IN
[33585ms] DBG ------ IN: 0x00
[33585ms] DBG -- BUS_FREE

The times are higher because the Zulu booted early with the external power provided (before I started up the Duo). There is a BUS reset in the above logs. It worked with no delays. So it does look like a timing/readiness thing.

 

[dougg3]

Agreed, this seems to be evidence that the Duo is trying to do something before the ZuluSCSI is ready. That bus reset definitely wasn't showing up in the Duo's ZuluSCSI debug log earlier.

 

[jmacz]

Ok, I'm going to park this for now. I'm using the work around of having a second disk image at ID=1 on the same Zulu. It works that way.