Duo Dock Strange Boot Icon (Picture)
- Thread starter jmacz
- Start date
jmacz
Well-known member
Thanks!
jmacz
Well-known member
@joevt in your post #11 (in the other thread) the BBEdit file you attached has the icon I'm looking for. Of the five icons in that doc, it's #2 and #3 (it's animated). This is great and means what I'm looking for is in the Duo Dock rom. Thanks for the help!
How I found the icons:
You can see the checkerboard icon using GraphicConverter RAW import of the 64K file "part00.bin" extracted from the first 64K of EC-A697_F2.bin.
0xe4e is an offset of some data that contains a checkerboard pattern that has multiple of these:
which you can find in the "EC-A697_F2.parsed.txt" file and the "EC-A697_F2.txt" file.
The icon at 0xe4e is followed immediately by a similar icon. Each icon is 128 bytes. So the address of the similar icon is 0xe4e+128.
Those two icons are in the sRsrc with ID 50 which is an unknown format.
The unknown sRsrc is at offset 0x06CC and appears to begin with a 32-bit length
The icon at 0x80a in the same sRsrc I found by looking at the GraphicConverter RAW import. The icon was at pixel Y coordinate 514. Each row is 4 bytes, so the offset is approximately 2056 = 0x808. 0x808 is a RTS, so the icon probably begins after that at 0x80a. The icon includes a mask, so the length is 256 bytes total instead of 128.
Looking at the photo of the icon in the other post, you can tell that it is approximately 32 pixels wide. It contains a flat top
If you don't have GraphicConverter, then I suppose you could use the xxd/perl script to convert the entire file to the ASCII art format.
Set the font size to 1 so you can see more pixels at once. Set the font size back to 9 to zoom in.
Then you can find the first icon at line 515. subtract 1 so that the line numbers are zero based, and multiply by 4 to get the byte offset.
You can see the checkerboard icon using GraphicConverter RAW import of the 64K file "part00.bin" extracted from the first 64K of EC-A697_F2.bin.
0xe4e is an offset of some data that contains a checkerboard pattern that has multiple of these:
AAAA AAAA for even rows5555 5555 for odd rows (ASCII UUUU)which you can find in the "EC-A697_F2.parsed.txt" file and the "EC-A697_F2.txt" file.
The icon at 0xe4e is followed immediately by a similar icon. Each icon is 128 bytes. So the address of the similar icon is 0xe4e+128.
Those two icons are in the sRsrc with ID 50 which is an unknown format.
Code:
22 97 000640 FEFE0698
0 01 000010 FEFE06A8 ; sRsrcType 0020=CatDock 0001=TypStation 0001=DrSWApple 0001=DrHWDeskBar
1 02 000014 FEFE06B0 ; sRsrcName "Dock_Station_Apple_DuoDock"
2 50 00002C FEFE06CC ; sRsrcUnknown
3 FF 000000 FEFE06A4 ; endOfListThe unknown sRsrc is at offset 0x06CC and appears to begin with a 32-bit length
FEFE06CC: 0000 0882 which is 2178 bytes. It appears to contain code (you can tell by the multiple occurrences of Nu which is the ASCII for a common 68K instruction 0x4E75 which is RTS.The icon at 0x80a in the same sRsrc I found by looking at the GraphicConverter RAW import. The icon was at pixel Y coordinate 514. Each row is 4 bytes, so the offset is approximately 2056 = 0x808. 0x808 is a RTS, so the icon probably begins after that at 0x80a. The icon includes a mask, so the length is 256 bytes total instead of 128.
Looking at the photo of the icon in the other post, you can tell that it is approximately 32 pixels wide. It contains a flat top
7FFF FFFF and vertical sides (multiple of 4000 0001). Since the picture is not 100% clear, you might look for variations that begin or end at different pixels, such as 7FFF FFFE and 4000 0002.If you don't have GraphicConverter, then I suppose you could use the xxd/perl script to convert the entire file to the ASCII art format.
xxd -b -c 4 "$thefile" | perl -pE 's/ //g; s/\w+:(\w{32}).*/$1/; s/0/ /g; s/1/██/g;'Set the font size to 1 so you can see more pixels at once. Set the font size back to 9 to zoom in.
Then you can find the first icon at line 515. subtract 1 so that the line numbers are zero based, and multiply by 4 to get the byte offset.
jmacz
Well-known member
Cool thanks.
Last night I mapped out the code chunks in the Duo Dock ROM, looking specifically for 4E75 (RTS) and Slot Manager calls (A06E). I had most of the valid code regions disassembled. Your earlier post this morning helped me identify the data region that had the icons I was interested in (0xe4e and 0xe4e+128). I had started with the primary init and secondary init but didn't see anything that interesting. Burned myself again getting confused with the timeviadb loop handling (thanks @cheesestraws) for the second time in a year. But as I was looking up references, traps, etc in the supermario code base, I stumbled upon what looks to be the Duo Dock ROM (or a version of it) in the supermario code base itself.
github.com
The primary init looks to be exactly the same, the secondary init is just a couple instructions different, and the source contains the docking handler and the video driver. I scanned these before jumping into a work meeting and didn't immediately notice anything that would render those icons, at least in this folder. But a subsequent search shows docking code littered throughout the code base including a docking manager. Will need to look further through the code base but at minimum the source files should help quickly map out the ROM code.
Last night I mapped out the code chunks in the Duo Dock ROM, looking specifically for 4E75 (RTS) and Slot Manager calls (A06E). I had most of the valid code regions disassembled. Your earlier post this morning helped me identify the data region that had the icons I was interested in (0xe4e and 0xe4e+128). I had started with the primary init and secondary init but didn't see anything that interesting. Burned myself again getting confused with the timeviadb loop handling (thanks @cheesestraws) for the second time in a year. But as I was looking up references, traps, etc in the supermario code base, I stumbled upon what looks to be the Duo Dock ROM (or a version of it) in the supermario code base itself.
supermario/base/SuperMarioProj.1994-02-09/DeclData/VSCDeclData at master · elliotnunn/supermario
Contribute to elliotnunn/supermario development by creating an account on GitHub.
github.com
The primary init looks to be exactly the same, the secondary init is just a couple instructions different, and the source contains the docking handler and the video driver. I scanned these before jumping into a work meeting and didn't immediately notice anything that would render those icons, at least in this folder. But a subsequent search shows docking code littered throughout the code base including a docking manager. Will need to look further through the code base but at minimum the source files should help quickly map out the ROM code.
jmacz
Well-known member
The Docking Manager implements a _DockingDispatch trap, and one of the operations seems to be to get a special floppy icon. This calls a docking handler which I believe calls into the duo dock ROM and returns one of the icons that @joevt extracted, but not the two I'm looking for. This sequence is in the SonyIcon.a source for rendering a model specific floppy icon. Need to continue looking.
jmacz
Well-known member
Ok found it. The reference to the icon is at offset 0xfefe0d78 and I see the CopyBits call near there. It's also near some SCSI trap calls so feels like it will be SCSI related which makes sense since I saw the behavior with the ZuluSCSI but not a spinning disk. And I don't see this specific code inside the supermario code base.
At the end of the DuoDock DeclData is the
This is found in supermario source code in PowerMgr.a and PwrControlsPatches.a
Its name is
This version is not in the supermario code.
It's also in the DeclData of the PowerBook ROM ending at 0xA0000.
Its name is
This name is in the supermario code.
The other two things described in the DuoDock DeclData are these:
There's an example of a
Its name is
The ID=50 is hex for ID=80 which is
VSCDockingHandler.a does not include a CopyBits or PlotIcon or whatever.
The beginning of the VSCDockingHandler.a code has a selector table. The selectors are listed in DockEqu.a
Which selector leads to the code with the icons and the
RussSWC! signature mentioned at #63 This is found in supermario source code in PowerMgr.a and PwrControlsPatches.a
ROMSigLo, ROMSigHi at address 0xFEFFFFE4.0003=CatDisplay 0001=TypVideo 0001=DrSWApple 0020=DrHWVSC is in the DuoDock DeclData.Its name is
Display_Video_Apple_VSCThis version is not in the supermario code.
It's also in the DeclData of the PowerBook ROM ending at 0xA0000.
Its name is
Display_Video_Apple_ViSCThis name is in the supermario code.
The other two things described in the DuoDock DeclData are these:
Code:
0020=CatDock 0001=TypStation 0001=DrSWApple 0001=DrHWDeskBar
"Dock_Station_Apple_DuoDock"
0001=CatBoard 0000=TypBoard 0000=DrSWBoard 0000=DrHWBoard
"Macintosh Duo Dock"There's an example of a
DeskBar in VSCDeclData.a of supermario but it's a little different.Its name is
Dock_Desk_Apple_ViSC/KeystoneThe ID=50 is hex for ID=80 which is
sRsrcDock which points to the code in VSCDockingHandler.a of supermario.VSCDockingHandler.a does not include a CopyBits or PlotIcon or whatever.
The beginning of the VSCDockingHandler.a code has a selector table. The selectors are listed in DockEqu.a
Which selector leads to the code with the icons and the
_CopyBits? Probably dockBootHook.
Code:
sRsrcDockStart=$((0x6d0))
sRsrcDockSize=$((0x0882))
selectortablestart=$((0x6fe))
selectortablesize=$((0xc8))
IFS=$'\n'
dd if="$thefile" bs=1 skip="$selectortablestart" count="$selectortablesize" 2> /dev/null | xxd -o "$selectortablestart" -c 8 | perl -nE '
if (/(.{8}): .{9} (.{4}) (.{4}) (....)..../) {
$selectorAddr = hex($1);
$selector = $4;
$data = hex($2 . $3);
$addr = $data + $selectorAddr + 4;
printf("%04x: '"'"'%s'"'"' ", $selectorAddr, $selector);
if ($addr >= '${selectortablestart}' + '${selectortablesize}' && $addr < '${sRsrcDockStart}' + '${sRsrcDockSize}') {
printf("code: %04x\n", $addr);
} else {
printf("data: %04x\n", $data);
}
}
'
06fe: 'dock' data: 001c
0706: 'sltc' data: 3000
070e: 'sccr' data: fee08000
0716: 'sccw' data: fee08000
071e: 'scc#' data: 0003
0726: 'scsi' data: fee02000
072e: 'sdma' data: fee04000
0736: 'shsk' data: fee06000
073e: 'snd ' data: 0011
0746: 'sctp' data: 0001
074e: 'vers' data: 1018002
0756: '....' data: 0000
075e: 'lock' code: 07ce
0766: 'ejct' code: 07de
076e: 'ejsw' code: 07ea
0776: 'dicn' code: 0802
077e: 'hdwr' code: 090c
0786: 'init' code: 092c
078e: 'mhz ' code: 0a92
0796: 'powr' code: 0adc
079e: 'pctl' code: 0af8
07a6: 'diag' code: 0b38
07ae: 'slep' code: 0bbe
07b6: 'wake' code: 0c1e
07be: 'boot' code: 0ca2
# Use capstone disassembler to look at the code for the 'boot' selector.
# Note: capstone doesn't understand A-Traps.
bootStart=$((0x0ca2))
cstool m68k $(dd if="$thefile" bs=1 skip=$bootStart count=$((sRsrcDockStart + sRsrcDockSize - bootStart)) 2> /dev/null | xxd -p -c 99999999) | perl -pE 's/^ *(\w+) ((?: [0-9a-f]{2})+) (.*)/\1:\2\t\3/' > bootcode.txtjmacz
Well-known member
This is the snippet of code in the Duo Dock ROM that grabs the 0xe4e icon and blits it:
But before it even gets to this code, it runs some SCSI calls. If any fail, it will drop into the above drawing routine and note that within this routine, it continues attempting to make the same SCSI calls.
The SCSI calls are:
Maybe I'm reading this wrong but the call to SCSI Select seems to be hard coded to check SCSI Target ID = 1? My Duo's internal ID = 0. There's no drive in the Duo Dock but looking at the manual for the Duo Dock, it suggests if you put a hard disk inside, to set the ID = 1.
Code:
fefe0d52 : 2d78 0904 fffc MOVE.L $00000904,-4(A6)
fefe0d58 : 4bee fff8 LEA -8(A6),A5
fefe0d5c : 21cd 0904 MOVE.L A5,$00000904
fefe0d60 : 1f38 08f3 MOVE.B $000008f3,-(A7) ;
fefe0d64 : 486e fff4 PEA -12(A6)
fefe0d68 : a86e _InitGraf ; InitGraf
fefe0d6a : 11df 08f3 MOVE.B (A7)+,$000008f3
fefe0d6e : 486e febe PEA -322(A6)
fefe0d72 : a86f _OpenPort ; OpenPort
fefe0d74 : 41ee feb0 LEA -336(A6),A0
fefe0d78 : 43fa 00d4 LEA +212(PC) {$fefe0e4e},A1
fefe0d7c : 20c9 MOVE.L A1,(A0)+
fefe0d7e : 30fc 0004 MOVE.W #$0004,(A0)+
fefe0d82 : 7420 MOVEQ #$20,D2
fefe0d84 : 302e fec6 MOVE.W -314(A6),D0
fefe0d88 : d06e feca ADD.W -310(A6),D0
fefe0d8c : 9042 SUB.W D2,D0
fefe0d8e : e240 ASR.W #1,D0
fefe0d90 : 322e fec8 MOVE.W -312(A6),D1
fefe0d94 : d26e fecc ADD.W -308(A6),D1
fefe0d98 : 9242 SUB.W D2,D1
fefe0d9a : e241 ASR.W #1,D1
fefe0d9c : 30c0 MOVE.W D0,(A0)+
fefe0d9e : 30c1 MOVE.W D1,(A0)+
fefe0da0 : d042 ADD.W D2,D0
fefe0da2 : d242 ADD.W D2,D1
fefe0da4 : 30c0 MOVE.W D0,(A0)+
fefe0da6 : 30c1 MOVE.W D1,(A0)+
fefe0da8 : 7640 MOVEQ #$40,D3
fefe0daa : d683 ADD.L D3,D3
fefe0dac : 486e feb0 PEA -336(A6)
fefe0db0 : 486e fec0 PEA -320(A6)
fefe0db4 : 486e feb6 PEA -330(A6)
fefe0db8 : 2f17 MOVE.L (A7),-(A7)
fefe0dba : 4267 CLR.W -(A7)
fefe0dbc : 42a7 CLR.L -(A7)
fefe0dbe : a8ec _CopyBits ; CopyBits
fefe0dc0 : d7ae feb0 ADD.L D3,-336(A6) ; set up image offset
fefe0dc4 : 4483 NEG.L D3 ; set up d3 for next image flip
fefe0dc6 : 611a BSR $fefe0de2 ; SCSI check again
fefe0dc8 : 57cc ffe2 DBEQ D4,$fefe0dac ; check D4 and go blit again
fefe0dcc : 486e febe PEA -322(A6)
fefe0dd0 : a87d _ClosePort ; ClosePort
fefe0dd2 : 21ee fffc 0904 MOVE.L -4(A6),$00000904But before it even gets to this code, it runs some SCSI calls. If any fail, it will drop into the above drawing routine and note that within this routine, it continues attempting to make the same SCSI calls.
The SCSI calls are:
Code:
fefe0de2 : 7aff MOVEQ #$FF,D5 ; d5 = $ff
fefe0de4 : 3d45 fe9a MOVE.W D5,-358(A6) ;
fefe0de8 : 554f SUBQ.W #2,A7 ;
fefe0dea : 3f3c 0001 MOVE.W #$0001,-(A7) ; $01 = SCSIGet
fefe0dee : a815 _SCSIDispatch ; SCSIDispatch
fefe0df0 : 4a57 TST (A7) ;
fefe0df2 : 664c BNE $fefe0e40 ;
fefe0df4 : 3f3c 0001 MOVE.W #$0001,-(A7) ; SCSI ID = $0001
fefe0df8 : 3f3c 0002 MOVE.W #$0002,-(A7) ; $02 = SCSISelect
fefe0dfc : a815 _SCSIDispatch ; SCSIDispatch
fefe0dfe : 4a57 TST (A7) ;
fefe0e00 : 663e BNE $fefe0e40 ;
fefe0e02 : 7a01 MOVEQ #$01,D5 ; d5 = $01
fefe0e04 : 486e fe92 PEA -366(A6) ;
fefe0e08 : 3f3c 0006 MOVE.W #$0006,-(A7) ;
fefe0e0c : 3f3c 0003 MOVE.W #$0003,-(A7) ; $03 = SCSICmd
fefe0e10 : a815 _SCSIDispatch ; SCSIDispatch
fefe0e12 : 4a57 TST (A7) ;
fefe0e14 : 660a BNE $fefe0e20 ;
fefe0e16 : 486e fe9c PEA -356(A6) ;
fefe0e1a : 3f3c 0005 MOVE.W #$0005,-(A7) ; $05 = SCSIRead
fefe0e1e : a815 _SCSIDispatch ; SCSIDispatch
fefe0e20 : 486e fe9a PEA -358(A6) ;
fefe0e24 : 486e fe98 PEA -360(A6) ;
fefe0e28 : 703c MOVEQ #$3C,D0 ;
fefe0e2a : 2f00 MOVE.L D0,-(A7) ;
fefe0e2c : 3f3c 0004 MOVE.W #$0004,-(A7) ; $04 = SCSIComplete
fefe0e30 : a815 _SCSIDispatch ; SCSIDispatch
fefe0e32 : 4a6e fe9a TST -358(A6) ;
fefe0e36 : 6608 BNE $fefe0e40 ;
fefe0e38 : 7a00 MOVEQ #$00,D5 ; d5 = $00
fefe0e3a : 544f ADDQ.W #2,A7 ;
fefe0e3c : 4a45 TST D5 ;
fefe0e3e : 4e75 RTS ;
fefe0e40 : 701e MOVEQ #$1E,D0 ;
fefe0e42 : d0b8 016a ADD.L $0000016a,D0 ;
fefe0e46 : b0b8 016a CMP.L $0000016a,D0 ;
fefe0e4a : 6efa BGT $fefe0e46 ;
fefe0e4c : 60ec BRA $fefe0e3a ;Maybe I'm reading this wrong but the call to SCSI Select seems to be hard coded to check SCSI Target ID = 1? My Duo's internal ID = 0. There's no drive in the Duo Dock but looking at the manual for the Duo Dock, it suggests if you put a hard disk inside, to set the ID = 1.
mdeverhart
Well-known member
Out of curiosity, what SCSI IDs are you using for images on your ZuluSCSI? Just one image of ID=0, or are there other images present?
jmacz
Well-known member
Just one image named HD0.img.
jmacz
Well-known member
I tried naming the internal Duo drive image to be HD1.img to see what would happen. Still got stuck on the icon but with ID=1, the image did not animate, it was stuck on the first frame until it unfreezes 10 seconds later and continues booting.
I enabled debugging mode on the ZuluSCSI to see if there was anything interesting.
Looking at this, the first SCSI command for ID=0 doesn't come in until very late.
This seems similar to what I was seeing with the HD sleep issues with PowerBooks and ZuluSCSI/BlueSCSI where immediately after powering up the HD, the OS sends a SCSI instruction but the ZuluSCSI/BlueSCSI isn't ready in time and misses it which results in a pause until a 180 second timeout triggers. I was able to work around that one with my SD Aide extension which causes the OS to wait N seconds after powering up the drive before issuing its first instruction.
My guess at this point is that the Zulu isn't reading messages on the bus until that 1891ms after power up and in those ~2 seconds, when the Duo is inside the dock, some SCSI instruction came in that was missed by the Zulu. And there's a 20-ish second timeout that is being waited on before things start working again. Unfortunately, since this is in ROM and before any disk reads have happened, my previous hack won't work. At least it's only 10 seconds.
I enabled debugging mode on the ZuluSCSI to see if there was anything interesting.
Code:
[12ms] Platform: ZuluSCSI RP2040
[12ms] FW Version: 25.02.11-release Feb 11 2025 17:57:30
[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
[21ms] SD Name: SD32G
[21ms] SD Date: 2/2024
[22ms] SD Serial: 0x7748C502
[23ms] Speed grade set to Default, skipping reclocking
[24ms] Reading configuration from zuluscsi.ini
[24ms] Active configuration:
[24ms] -- SelectionDelay = 255
[25ms] -- EnableUnitAttention = No
[25ms] -- EnableSCSI2 = Yes
[25ms] -- EnableSelLatch = No
[25ms] -- MapLunsToIDs = No
[26ms] -- EnableParity = Yes
[58ms] Finding images in directory /:
[59ms] -- Opening /HD0.img for id:0 lun:0
[59ms] DBG ---- Image file is contiguous, SD card sectors 24640 to 1560639
[60ms] ---- Configuring as disk drive drive
[60ms] ---- Read prefetch enabled: 8192 bytes
[61ms] -- Platform supports ROM drive up to 16028 kB
[61ms] ---- ROM drive image not detected
[62ms] SCSI ID: 0, BlockSize: 512, Type: 0, Quirks: 0, Size: 768000kB
[71ms] Clock set to: 125000000Hz
[71ms] Initialization complete!
[1891ms] DBG -- BUS_BUSY
[1891ms] DBG -- BUS_FREE
[2854ms] DBG -- BUS_BUSY
[2854ms] DBG -- BUS_FREE
[3818ms] DBG -- BUS_BUSY
[3818ms] DBG -- BUS_FREE
[4783ms] DBG -- BUS_BUSY
[4783ms] DBG -- BUS_FREE
[5747ms] DBG -- BUS_BUSY
[5747ms] DBG -- BUS_FREE
[6712ms] DBG -- BUS_BUSY
[6712ms] DBG -- BUS_FREE
[7676ms] DBG -- BUS_BUSY
[7676ms] DBG -- BUS_FREE
[8640ms] DBG -- BUS_BUSY
[8640ms] DBG -- BUS_FREE
[9604ms] DBG -- BUS_BUSY
[9604ms] DBG -- BUS_FREE
[10569ms] DBG -- BUS_BUSY
[10569ms] DBG -- BUS_FREE
[11533ms] DBG -- BUS_BUSY
[11533ms] DBG -- BUS_FREE
[12498ms] DBG -- BUS_BUSY
[12498ms] DBG -- BUS_FREE
[13462ms] DBG -- BUS_BUSY
[13462ms] DBG -- BUS_FREE
[14426ms] DBG -- BUS_BUSY
[14426ms] DBG -- BUS_FREE
[15391ms] DBG -- BUS_BUSY
[15391ms] DBG -- BUS_FREE
[16355ms] DBG -- BUS_BUSY
[16355ms] DBG -- BUS_FREE
[17319ms] DBG -- BUS_BUSY
[17319ms] DBG -- BUS_FREE
[18284ms] DBG -- BUS_BUSY
[18284ms] DBG -- BUS_FREE
[19248ms] DBG -- BUS_BUSY
[19248ms] DBG -- BUS_FREE
[20212ms] DBG -- BUS_BUSY
[20212ms] DBG -- BUS_FREE
[21177ms] DBG -- BUS_BUSY
[21177ms] DBG -- BUS_FREE
[22141ms] DBG -- BUS_BUSY
[22141ms] DBG -- BUS_FREE
[22618ms] DBG -- BUS_BUSY
[22619ms] DBG -- BUS_FREE
[23097ms] DBG -- BUS_BUSY
[23097ms] DBG -- BUS_FREE
[23575ms] DBG -- BUS_BUSY
[23575ms] DBG -- BUS_FREE
[24053ms] DBG -- BUS_BUSY
[24053ms] DBG -- BUS_FREE
[24531ms] DBG -- BUS_BUSY
[24531ms] DBG -- BUS_FREE
[25009ms] DBG -- BUS_BUSY
[25009ms] DBG ---- SELECTION: 0
[25011ms] DBG ---- COMMAND: Read6
[25011ms] DBG ------ OUT: 0x08 0x00 0x00 0x00 0x01 0x00
[25011ms] Toolbox enabled = 0
[25012ms] DBG ------ Read 1x512 starting at 0
[25013ms] DBG ---- DATA_IN
[25013ms] DBG ---- Total IN: 512 OUT: 0 CHECKSUM: 31398
[25014ms] DBG ---- STATUS: 0 GOOD
[25018ms] DBG ---- MESSAGE_IN
[25018ms] DBG ------ IN: 0x00Looking at this, the first SCSI command for ID=0 doesn't come in until very late.
- 71ms after power - Zulu reports Initialization complete
- 1891ms after power - Zulu starts logging bus busy / free debug messages
- << my observation is around 15000ms after power the video display comes on with icon in question >>
- 25009ms after power - Zulu sees the SCSI read command for ID = 0
This seems similar to what I was seeing with the HD sleep issues with PowerBooks and ZuluSCSI/BlueSCSI where immediately after powering up the HD, the OS sends a SCSI instruction but the ZuluSCSI/BlueSCSI isn't ready in time and misses it which results in a pause until a 180 second timeout triggers. I was able to work around that one with my SD Aide extension which causes the OS to wait N seconds after powering up the drive before issuing its first instruction.
My guess at this point is that the Zulu isn't reading messages on the bus until that 1891ms after power up and in those ~2 seconds, when the Duo is inside the dock, some SCSI instruction came in that was missed by the Zulu. And there's a 20-ish second timeout that is being waited on before things start working again. Unfortunately, since this is in ROM and before any disk reads have happened, my previous hack won't work. At least it's only 10 seconds.
jmacz
Well-known member
That's a great idea. Let me drop another ZuluSCSI into the dock itself on ID=1 and enable debug logs on that one too.
I guess thinking about it further, if I'm understanding everything correctly, these two test results mean that what's happening with ID 1 on the internal dock drive is irrelevant. That's really, really weird, especially given that the ZuluSCSI debug trace doesn't show anything happening with ID 0 prior to 25 seconds after poweron.
jmacz
Well-known member
Ran 5 tests using three different Zulu devices.
I have different versions of the firmware running on these so I'm going to try upgrading both to see if I see a difference in behavior.
- Duo Zulu
- RP2040 red (2023a) laptop version.
- Firmware: 25.02.11
- SCSI ID: 0
- Dock Zulu
- RP2040 green (2023b) compact home brew version.
- Firmware: 24.05.17
- SCSI ID: 1
- External Zulu
- Original ARM based external form factor Mini version.
- Firmware: 23.07.01
- SCSI ID: 5
- Test 1 - Duo Zulu, Dock Zulu, External Zulu + external power
- Booted up quickly (weird icon screen showed for a split second only)
- External power seems to have powered both the External Zulu and the Dock Zulu, but not the Duo Zulu
- External Zulu and Dock Zulu initialized early since they had external power
- Duo Zulu:
- 70ms - init complete
- 1892ms - first busy/free msgs in log
- 4491ms - first SCSI read command
- Ignoring other logs because they are delayed due to receiving power early and given no difference with test 2, skipping this.
- Test 2 - Duo Zulu, Dock Zulu, External Zulu (no external power)
- Booted up quickly (weird icon screen showed for a split second only)
- Duo Zulu:
- 71ms - init complete
- 1961ms - first busy/free msgs in log
- 4313ms - first SCSI read command (selection 0)
- Dock Zulu:
- 225ms - init complete
- 17779ms - SCSI bus reset
- 24985ms - first busy/free msgs in log
- 24985ms - first SCSI read command (selection 1)
- External Zulu:
- 132ms - init complete
- 17851ms - SCSI bus reset
- 25096ms - first busy/free msgs in log
- 25820ms - first SCSI read command (selection 5)
- Test 3 - Duo Zulu, Dock Zulu
- Booted up quickly (weird icon screen showed for a split second only)
- Duo Zulu:
- 71ms - init complete
- 1892ms - first busy/free msgs in log
- 4613ms - first SCSI read command (selection 0)
- Dock Zulu:
- 225ms - init complete
- 3479ms - SCSI bus reset
- 10866ms - first busy/free msgs in log
- 10866ms - first SCSI read command (selection 1)
- Test 4 - Duo Zulu, (Dock Zulu exists but no SD card inserted)
- Stuck in icon screen for ~10 seconds
- Duo Zulu:
- 113ms - init complete
- 2677ms - first busy/free msgs in log
- 24745ms - first SCSI read command (selection 0)
- Test 5 - Dock Zulu, (Duo Zulu exists but no SD card inserted)
- Booted up quickly (weird icon screen showed for a split second only)
- Dock Zulu:
- 227ms - init complete
- 3470ms - SCSI bus reset
- 10866ms - first busy/free msgs in log
- 10868ms - first SCSI read command (selection 1)
I have different versions of the firmware running on these so I'm going to try upgrading both to see if I see a difference in behavior.
jmacz
Well-known member
So latest firmware didn't change a thing.
- Zulus by themselves on either the external or internal dock work fine.
- Duo Zulu works fine only if one also exists on the internal dock connector.
- Duo Zulu gets delayed 10 seconds on boot if the only SCSI device.
jmacz
Well-known member
I mentioned in my previous post that the Duo Zulu works fine IF another SCSI device exists on the internal dock connector. I tested to see what happens with a Duo Zulu and a SCSI device on the external connector instead of the internal dock connector. Didn't work. Was delayed.
Testing further though, I found that it's not the internal dock connector or the external docker connector that matters. It's whether those devices have an ID=1. So it looks like the Duo Zulu will work as long as there's a SCSI device with ID=1 in the dock, using either the external connector or the internal connector.
So then I had to see what happens if I placed both an ID=0 and an ID=1 image on the Duo Zulu (without any other SCSI devices connected to the dock). It worked?!? With the internal Duo Zulu having both an HD0.img and an HD1.img, I get no delays... Hmmm...
Logs from this test:
So this means it's not a timing / startup issue. But there's something going on here. The Duo Dock ROM is certainly making specific SCSI calls looking for a device ID=1. Theoretically it should not find it and move on. And it does move on with a normal hard drive on ID=0. But with the Zulu, something happens where the Duo Dock ROM doesn't like it and stalls for 10 seconds.
The brain dead fix would be for me to park a small ID=1 drive image on my internal Duo ZuluSCSI. It's not enough to rename the only drive image to be ID=1 as that didn't work.
I am curious though what's going on.
Testing further though, I found that it's not the internal dock connector or the external docker connector that matters. It's whether those devices have an ID=1. So it looks like the Duo Zulu will work as long as there's a SCSI device with ID=1 in the dock, using either the external connector or the internal connector.
So then I had to see what happens if I placed both an ID=0 and an ID=1 image on the Duo Zulu (without any other SCSI devices connected to the dock). It worked?!? With the internal Duo Zulu having both an HD0.img and an HD1.img, I get no delays... Hmmm...
Logs from this test:
Code:
[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
[18ms] SDIO checksum error in reception: block 0 calculated 0xF1726FF07055E00F expected 0x97B80CCB0A39C1FF
[19ms] SdioCard::readSector(0x00000000) failed: 6
[20ms] SDIO checksum error in reception: block 0 calculated 0xF1726FF07055E00F expected 0x97B80CCB0A39C1FF
[21ms] SdioCard::readSector(0x00000000) failed: 6
[22ms] SDIO checksum error in reception: block 0 calculated 0xE7E931FD4567CA38 expected 0x6878B1DCB3B18C1F
[23ms] SdioCard::readSector(0x00000000) failed: 6
[23ms] SDIO checksum error in reception: block 0 calculated 0x0F000F0FF00FF00F expected 0xFFFFFFFFFFFFFFFF
[24ms] SdioCard::readSector(0x00000000) failed: 6
[25ms] DBG SD card init failed, sdErrorCode: 6 sdErrorData: 0
[30ms] SD card init succeeded after retry
[32ms] SD card detected, FAT64 volume size: 29548 MB
[32ms] SD MID: 0x27, OID: 0x50 0x48
[33ms] SD Name: SD32G
[33ms] SD Date: 2/2024
[33ms] SD Serial: 0x7748C502
[34ms] Speed grade set to Default, skipping reclocking
[35ms] Reading configuration from zuluscsi.ini
[36ms] Active configuration:
[36ms] -- SelectionDelay = 255
[36ms] -- EnableUnitAttention = No
[37ms] -- EnableSCSI2 = Yes
[37ms] -- EnableSelLatch = No
[37ms] -- MapLunsToIDs = No
[38ms] -- EnableParity = Yes
[83ms] Finding images in directory /:
[84ms] -- Opening /HD0.img for id:0 lun:0
[84ms] DBG ---- Image file is contiguous, SD card sectors 24640 to 1560639
[84ms] ---- Configuring as disk drive drive
[85ms] ---- Drive geometry from image size: SectorsPerTrack=60 HeadsPerCylinder=16 total sectors 1536000 (divisible)
[86ms] ---- Read prefetch enabled: 8192 bytes
[88ms] -- Opening /HD1.img for id:1 lun:0
[90ms] ---- WARNING: file /HD1.img is not contiguous. This will increase read latency.
[91ms] ---- Configuring as disk drive drive
[91ms] ---- Drive geometry from image size: SectorsPerTrack=60 HeadsPerCylinder=16 total sectors 1536000 (divisible)
[93ms] ---- Read prefetch enabled: 8192 bytes
[93ms] -- Platform supports ROM drive up to 16028 kB
[94ms] ---- ROM drive image not detected
[94ms] SCSI ID: 0, BlockSize: 512, Type: 0, Quirks: 0, Size: 768000kB
[95ms] SCSI ID: 1, BlockSize: 512, Type: 0, Quirks: 0, Size: 768000kB
[110ms] Clock set to: 125000000Hz
[110ms] Initialization complete!
[1710ms] DBG ---- SELECTION: 1
[1711ms] DBG ---- COMMAND: Read6
[1711ms] DBG ------ OUT: 0x08 0x00 0x00 0x00 0x01 0x00
[1712ms] Toolbox enabled = 0
[1712ms] DBG ------ Read 1x512 starting at 0
[1713ms] DBG ---- DATA_IN
[1714ms] DBG ---- Total IN: 512 OUT: 0 CHECKSUM: 31398
[1714ms] DBG ---- STATUS: 0 GOOD
[1719ms] DBG ---- MESSAGE_IN
[1719ms] DBG ------ IN: 0x00
[1720ms] DBG -- BUS_FREE
[2198ms] DBG -- BUS_BUSY
... a bunch of SCSI commands against ID = 1 and then ...
[4242ms] DBG -- BUS_FREE
[4242ms] DBG ---- SELECTION: 0
[4243ms] DBG ---- COMMAND: Read6
[4243ms] DBG ------ OUT: 0x08 0x00 0x00 0x00 0x01 0x00
[4244ms] DBG ------ Read 1x512 starting at 0
[4245ms] DBG ---- DATA_IN
[4246ms] DBG ---- Total IN: 512 OUT: 0 CHECKSUM: 31398
[4246ms] DBG ---- STATUS: 0 GOOD
[4252ms] DBG ---- MESSAGE_IN
[4252ms] DBG ------ IN: 0x00So this means it's not a timing / startup issue. But there's something going on here. The Duo Dock ROM is certainly making specific SCSI calls looking for a device ID=1. Theoretically it should not find it and move on. And it does move on with a normal hard drive on ID=0. But with the Zulu, something happens where the Duo Dock ROM doesn't like it and stalls for 10 seconds.
The brain dead fix would be for me to park a small ID=1 drive image on my internal Duo ZuluSCSI. It's not enough to rename the only drive image to be ID=1 as that didn't work.
I am curious though what's going on.
Last edited:
