View topic - Sniffing control flow between legacy devices over PATA/ATAPI

Main » Forums home » Research and development

All times are UTC - 5 hours [ DST ]

Forum rules

Please do not post questions about data recovery cases here (use this forum instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...

Sniffing control flow between legacy devices over PATA/ATAPI

Page 12 of 12

[ 238 posts ]

Go to page Previous 1 ... 8, 9, 10, 11, 12

Previous topic | Next topic

Author

Message

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 2nd, 2024, 12:55

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

HaQue wrote:

adapter working? Translatable to English: https://www.phantom.sannata.org/viewtopic.php?t=40212&start=165

Quote:

Hello everyone, I'm fine, the development of the device has not been abandoned, but has been paused.
I don’t want to open source it yet, maybe later.
I didn’t unsubscribe to the topic because I didn’t see the notifications... Such a monstrous coincidence.

The latest available firmware has added:
* advanced multi-level CLI
* ATA bus debugging mode: the device is connected third to a standard cable, captures messages on the bus, caches them in the controller memory and displays them in the CLI.
* ZIP support improvements: soft-eject support, compatibility with music equipment, successfully tested on Boss BR8, Roland SP808, Roland SP808ex, Roland VS840vx.
* error correction.

Yes this works very well, i worked with user Sintechi to get the emulator working perfectly with the SP808. Due to the sanctions placed on Russia and because of the political unease, he is taking a break from the project, but he has re-spun a new version of the board.

The emulator has a bus sniff function, which allows all data on the IDE bus to be captured. This allowed us to see the interaction between the SP808 and the ZIP drive. I have put logs here: https://github.com/hsiboy/Roland_SP-808_Reverse_Engineering/blob/default/Roland_SP-808_to_ZIP_Drive_sniff.md

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 2nd, 2024, 12:56

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

HaQue wrote:

Anyone know anything about these expansion boards for the SP?

https://reverb.com/au/item/56525330-rare-roland-sp808-op2-scsi-digital-i-o-expansion-board-for-sp-808-sp-808ex-worldwide-shipping

Quote:

Very Rare Roland SP808-OP2 expansion card for SP-808, SP-808EX.
Adds SCSI, Digital In/Out, and balanced stereo input / output with XLR Mic input.

Quote:

Two XLR Inputs with Line/Mic switch - Two XLR Outputs - Digital SP/DIF In/Out - SCSI port for adding an extra Zip drive.

I wonder if this port is useful in any way?

Attachment:

expansion.jpg

Hey @HaQue - I have one of these interfaces, unfortunately it only works as a backup device. So you can save a copy of your ZIP to the backup device or restore from a backup, but you can not play from it.

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 2nd, 2024, 13:06

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

HaQue wrote:

Wondering if it is possible to use the technique in this post to somehow access other parts of the system. Namely put CPU in a different mode that ignores onboard OTPROM and boot from flash with some code.

https://hackaday.io/project/188508-repu ... 039-h8300h

Also wondering about how the buttons tell the OS what to do. Looking to see if a button press is sent via an ascii code or some protocol, what happens if we send something unexpected?

I edited together some images of the test mode. The RAM looks interesting. Not sure what PRAM0, PRAM1, IRAM0, IRAM1, GRAM and ERAM are. I have seen reference to IRAM being CPU Instruction RAM, but not so sure that is what it is here.

Attachment:

TestMode.jpg

@HaQue did you see the "special" mode?

Code:

Status + FX A --> MIDI Update
Status + FX B --> Zip Update
Status + FX C --> Develop Monitor
Status + FX D --> Diagnostic Mode

Midi update is interesting to me, i think this is using Hitachi UART, look at the PCB ;-)

If you damage IC9 (flash IC), you get this message:

Code:

<< EMERGENCY >>
SYSTEM is BROKEN !
Please consult quali -
fied Roland Service.

Those string do not exist in the firmware file!

Top

Buzunki

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 23rd, 2024, 9:24

Joined: September 6th, 2023, 7:16
Posts: 8
Location: United Kingdom

Don’t know if this is relevant but in case you guys have not seen it.

https://superuser.com/questions/1429096 ... -hangs-fir

It talks about pins 21 and 29 in IDE interface not being connected on SP-808, I wonder if the same is true of the A6 - presumably not since it is factory fitted with a HD, can’t seem to find the A6 service manual. Might be worth asking Roland for it?

I’m still very much interested in a solution even though currently my SP-808 is working happily with the Akai card reader.

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 23rd, 2024, 15:37

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

Yeah, that is a factor, but, the Iomega zip drive sends a specific response to a given ATAPI command that is an extension to the ATPI specification. Its vendor specific, and other devices don't know how to respond.

Also, the zip drive returns data in a specific way, and the SP-808 expects to get the data in those specific sized chunks, and if it doesn't, it sends a reset to the drive and starts again.

All this is documented on my GitHub repo.

Top

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 27th, 2024, 1:53

Joined: December 4th, 2012, 1:35
Posts: 3862
Location: Adelaide, Australia

I will be struggling for time next 4 weeks or so, due to work. My main laptop becoming unbootable is a P.I.T.A. as well.

@Hsiboy I need to go back and check out the special mode in more detail, as really I have only been documenting what I am finding, without going into too much research mode on the individual interesting parts. The CPU certainly has firmware. I am not sure it is updateable/dumpable though. to use any CPU I/O I would assume you would need to write code and get it to execute to setup the serial comms, and I am sure there would be vectors to do that, I don't know how yet.

Where did you see this? :
Status + FX A --> MIDI Update
Status + FX B --> Zip Update
Status + FX C --> Develop Monitor
Status + FX D --> Diagnostic Mode

my mind is a bit foggy on what I've been doing, but I can't remember seeing this anywhere.

as for disassembly, specify Hitachi H8S advanced, and H8S/2215R. Closest I go to the actual CPU.
the following seemed to work for a dodgy memory map. not sure how accurate it is because this is from my work PC, and I may have worked on it more on my laptop that is currently only got a new install of win11, with the SSD out of it hoping I can recover it. My fault for getting a new laptop and simply swapping SSDs, installing new drivers and hoping it would carry on. didn't expect blue screen and all methods of recovery not working. dammnit!

I started adding the memory map from the CPU docs, but to be honest, wasn't making a whole lot of sense to me!

Attachment:

segments.JPG [ 76.15 KiB | Viewed 82435 times ]

@Buzunki, the service notes can be found in these places:
https://www.synthxl.com/wp-content/uploads/2020/01/Roland-A-6-Service-Manual.pdf

https://www.manualslib.com/manual/1829457/Roland-A-6.html

The more I look at this project, the more I feel I need to know!

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 28th, 2024, 7:27

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

this looks very interesting ;-)

http://forums.openecu.org/viewtopic.php?f=15&t=394

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 29th, 2024, 12:16

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

@HaQue

Power off the SP-808
Hold down the STATUS & EFFECTS buttons for Track A and then power on the SP-808
The display reads "MIDI UPDATE - Waiting MIDI . . ."

Status + FX A --> MIDI Update
Status + FX B --> Zip Update
Status + FX C --> Develop Monitor
Status + FX D --> Diagnostic Mode

This code is from the mask ROM

I've tried sniffing the midi interface when in Develop Mode, but there's no traffic i can see, so i'm hoping the UART that's brought out to unpopulated CN7 on the PCB has something.

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 29th, 2024, 12:24

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

From my notes on. github...

Looking at the PCB
Pin 83 STBY is held high.

Pin 82 NMI (Non Maskable Interrupt) is held high, which means NMI is not being used.
MIDI is communicated via pin 61 (P30 / RXD0) and pin 59 (P32 / TXD0).

Pin 60 is TXD1 and pin 62 is RXD1, this serial interface is brought out on pin 33 as TX1 and pin 32 as RX1 on unpopulated connecter CN7. Pin 31 of CN7 carries XRST, while neighbouring pins 34-37 are GND and pins 38-40 are VCC.

On the PCB, the pins (MD2 to MD0) that control the MCU Operating Mode are set as follows:

Pin 123 - MD0 = Low
Pin 124 - MD1 = High
Pin 125 - MD2 = High

Which means the CPU is running in Mode 6 - "On-chip ROM enabled, expansion mode".

This means the MCU is running in Advanced mode!

The address space is 16 Mbytes in modes 4 to 7 (advanced modes). The on-chip ROM of H8S/2655 contains 128 kbytes, but only 56 kbytes are available in modes 2 and 3 (normal modes). The address space is divided into eight areas for modes 4 to 7.

In Advanced mode, Linear access is provided to a 16-Mbyte maximum address space (architecturally a maximum 16-Mbyte program area and a maximum 4-Gbyte data area, with a maximum of 4 Gbytes for program and data areas combined).

Note - While the CPU’s architecture allows for 4 Gbytes of address space, the H8S/2655 Group can actually accesses a maximum of 16 Mbytes.

Modes 1, 2, and 4 to 6 are externally expanded modes that allow access to external memory and peripheral devices.

The external expansion modes allow switching between 8-bit and 16-bit bus modes. After program execution starts, an 8-bit or 16-bit address space can be set for each area, depending on the bus controller setting. If 16-bit access is selected for any one area, 16-bit bus mode is set; if 8-bit access is selected for all areas, 8-bit bus mode is set.

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: February 29th, 2024, 12:28

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

HaQue wrote:

as for disassembly, specify Hitachi H8S advanced, and H8S/2215R. Closest I go to the actual CPU.
the following seemed to work for a dodgy memory map.

Smashing, let me see what i used :good:

Top

Dubbylabby

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: March 15th, 2024, 3:31

Joined: August 9th, 2023, 11:40
Posts: 3
Location: Barcelona

Hi,
Glad to see some forward movement is happen.

Sadly on my side after contact MidiManiac over wallapop and sent him a whatsapp messaging the conversation didn’t flow (he made an appointment and never return)
Maybe he moved on this topic since I found him selling his sp808 with MCD drive…

Top

grounder314

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: March 31st, 2024, 16:24

Joined: January 10th, 2022, 13:36
Posts: 4

From the creators of SCSI2SD and ZuluSCSI, looks like there 'may' finally be and alternative to the ZIP in the SP-808:

JUST RELEASED...

https://www.zuluide.com
https://github.com/rabbitholecomputing/ZuluIDE-firmware

ZuluIDE™ is a IDE computer storage emulation platform, where CD-ROM drive images are stored on a standard FAT32 or exFAT-formatted SD card. SDXC cards of up to 512GB are supported.

Features
Emulates IDE/ATAPI CD-ROM drives of any size.
Emulates ZIP100 ATAPI removable media.
Open-source firmware, licensed under the GPLv3

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: December 29th, 2024, 21:57

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

@HaQue - It's that time of year again

. Have you made any progress?

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: December 29th, 2024, 22:09

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

grounder314 wrote:

I have two of these, sent by the creator Alex Perez after he used my published data from this little project. I can confirm that they do work with the SP808, but, the workflow is a little bit janky when you want to change disks. No more than ZuluScsi or Bluepill Scisi or even the Russian emulator from Sintechi, so i continue to take a look when i have spare time (not very often), with the hopes of patching the SP808 so it will use a non zip drive.

Note to @HaQue:

I think i found where the ATAPI commands are stored. They appear to be sent to the Seiko/Epson GAL with a control byte:

Code:

ROM:00171ABB aSelf:                .ascii "SELF"<0>
ROM:00171AC0 aZip_0:               .ascii "ZIP "<0>
ROM:00171AC5 aHd:                  .ascii "HD  "<0>
ROM:00171ACA aCd:                  .ascii "CD  "<0>
ROM:00171ACF byte_171ACF:          .byte 0x2D                                      ; DATA XREF: sub_10617A+112↑r
ROM:00171AD0 aSzhc:                .ascii "SZHC"                                   ; 06 00 00 00 00 00 00     // Command entry 1
ROM:00171AD0                                                                       ; 06 1B 00 00 00 00 00     // START/STOP UNIT
ROM:00171AD0                                                                       ; 06 1E 00 00 00 00 00     // PREVENT/ALLOW MEDIA REMOVAL
ROM:00171AD0                                                                       ; 06 03 00 00 00 00 00     // REQUEST SENSE
ROM:00171AD4 word_171AD4:          .word 0x600                                     ; DATA XREF: sub_12AA72:loc_12AAB0↑o
ROM:00171AD6                       .word 0
ROM:00171AD8                       .word 0
ROM:00171ADA word_171ADA:          .word 6                                         ; DATA XREF: sub_12AAF2+30↑o
ROM:00171ADA                                                                       ; sub_12AB76+4A↑o
ROM:00171ADC                       .byte 0x1B
ROM:00171ADD                       .byte 0
ROM:00171ADE                       .byte 0
ROM:00171ADF                       .byte 0
ROM:00171AE0                       .byte 0
ROM:00171AE1                       .byte 0
ROM:00171AE2 byte_171AE2:          .byte 6                                         ; DATA XREF: sub_12AC0E+4E↑o
ROM:00171AE3                       .byte 0x1E
ROM:00171AE4                       .byte 0
ROM:00171AE5                       .byte 0
ROM:00171AE6                       .byte 0
ROM:00171AE7                       .byte 0
ROM:00171AE8                       .byte 0
ROM:00171AE9 byte_171AE9:          .byte 6                                         ; DATA XREF: sub_12ACB0+4A↑o
ROM:00171AEA                       .byte 3
ROM:00171AEB                       .byte 0
ROM:00171AEC                       .byte 0
ROM:00171AED                       .byte 0
ROM:00171AEE                       .byte 0
ROM:00171AEF                       .byte 0
ROM:00171AF0 aIomega:              .ascii "IOMEGA  "<0>                            ; DATA XREF: sub_12AE88+130↑o
ROM:00171AF9 aIomega_0:            .ascii "iomega  "<0>                            ; DATA XREF: sub_12AE88+148↑o
ROM:00171B02 aZip:                 .ascii "ZIP"<0>                                 ; DATA XREF: sub_12AE88+166↑o
ROM:00171B06 byte_171B06:          .byte 6                                         ; DATA XREF: sub_12AE88+6E↑o
ROM:00171B07                       .byte 0x12                                      ; ATAPI 06 12 00 00 00 00 00     // INQUIRY

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: December 30th, 2024, 13:24

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

a bit more poking about today...

It looks like we have the device validation code sequence:

Code:

sub_12E8E0+11A  ; ---------------------------------------------------------------------------
sub_12E8E0+11A
sub_12E8E0+11A  loc_12E9FA:                                                           ; CODE XREF: sub_12E8E0+106↑j
sub_12E8E0+11A                  sub.w   e5, e5                                        ; Subtract binary
sub_12E8E0+11C
sub_12E8E0+11C  loc_12E9FC:                                                           ; CODE XREF: sub_12E8E0+E2↑j
sub_12E8E0+11C                                                                        ; sub_12E8E0+112↑j
sub_12E8E0+11C                  mov.w   e5, e5                                        ; Move data
sub_12E8E0+11E                  bne     loc_12E9C4:8                                  ; Branch if not equal
sub_12E8E0+120                  mov.b   r5l, r0l                                      ; Move data
sub_12E8E0+122                  extu.w  r0                                            ; Extend as unsigned
sub_12E8E0+124                  extu.l  er0                                           ; Extend as unsigned
sub_12E8E0+126                  mov.b   @(1:16,er6), r1l                              ; Move data
sub_12E8E0+12A                  and.b   #0x80, r1l                                    ; Logical AND
sub_12E8E0+12C                  mov.b   @er6, r2l                                     ; Move data
sub_12E8E0+12E                  and.b   #0x7F, r2l                                    ; Logical AND
sub_12E8E0+130                  or.b    r2l, r1l                                      ; Logical OR
sub_12E8E0+132                  mov.b   r1l, @(0x41E864:32,er0)                       ; Move data
sub_12E8E0+13A                  mov.l   #8, er0                                       ; Move data
sub_12E8E0+140                  push.l  er0                                           ; Push data on stack
sub_12E8E0+144                  mov.l   #aIomega, er1                                 ; Move data
sub_12E8E0+14A                  mov.l   er6, er0                                      ; Move data
sub_12E8E0+14C                  adds    #4, er0                                       ; Add with sign extension
sub_12E8E0+14E                  adds    #4, er0                                       ; Add with sign extension
sub_12E8E0+150                  jsr     unk_400228:24                                 ; Jump to subroutine
sub_12E8E0+154                  adds    #4, sp                                        ; Add with sign extension
sub_12E8E0+156                  mov.b   r0l, r0l                                      ; Move data
sub_12E8E0+158                  bne     loc_12EA5C:8                                  ; Branch if not equal
sub_12E8E0+15A                  mov.l   #8, er0                                       ; Move data
sub_12E8E0+160                  push.l  er0                                           ; Push data on stack
sub_12E8E0+164                  mov.l   #aIomega_0, er1                               ; Move data
sub_12E8E0+16A                  mov.l   er6, er0                                      ; Move data
sub_12E8E0+16C                  adds    #4, er0                                       ; Add with sign extension
sub_12E8E0+16E                  adds    #4, er0                                       ; Add with sign extension
sub_12E8E0+170                  jsr     unk_400228:24                                 ; Jump to subroutine
sub_12E8E0+174                  adds    #4, sp                                        ; Add with sign extension
sub_12E8E0+176                  mov.b   r0l, r0l                                      ; Move data
sub_12E8E0+178                  beq     loc_12EBB4:16                                 ; Branch if equal
sub_12E8E0+17C
sub_12E8E0+17C  loc_12EA5C:                                                           ; CODE XREF: sub_12E8E0+158↑j
sub_12E8E0+17C                  mov.l   #3, er0                                       ; Move data
sub_12E8E0+182                  push.l  er0                                           ; Push data on stack
sub_12E8E0+186                  mov.l   #aZip, er1                                    ; Move data
sub_12E8E0+18C                  mov.l   er6, er0                                      ; Move data
sub_12E8E0+18E                  add.l   #0x10, er0                                    ; Add binary
sub_12E8E0+194                  jsr     unk_400228:24                                 ; Jump to subroutine
sub_12E8E0+198                  adds    #4, sp                                        ; Add with sign extension
sub_12E8E0+19A                  cmp.b   #1, r0l                                       ; Compare
sub_12E8E0+19C                  bne     loc_12EAA4:8                                  ; Branch if not equal
sub_12E8E0+19E                  mov.b   r5l, r0l                                      ; Move data
sub_12E8E0+1A0                  extu.w  r0                                            ; Extend as unsigned
sub_12E8E0+1A2                  extu.l  er0                                           ; Extend as unsigned
sub_12E8E0+1A4                  mov.b   #1, r1l                                       ; Move data
sub_12E8E0+1A6                  mov.b   r1l, @(0x41E8AC:32,er0)                       ; Move data
sub_12E8E0+1AE                  mov.b   r5l, r0l                                      ; Move data
sub_12E8E0+1B0                  bsr     sub_12F40E:16                                 ; Branch to subroutine
sub_12E8E0+1B4                  mov.b   r5l, r0l                                      ; Move data
sub_12E8E0+1B6                  bsr     sub_12F482:16                                 ; Branch to subroutine
sub_12E8E0+1BA                  mov.b   r5l, r0l                                      ; Move data
sub_12E8E0+1BC                  bsr     sub_12F6B0:16                                 ; Branch to subroutine
sub_12E8E0+1C0                  jmp     loc_12EBB4:24                                 ; Jump
sub_12E8E0+1C4  ; ---------------------------------------------------------------------------
sub_12E8E0+1C4

Lets break this down (i'd welcome someone to check my homework):

1. Initial Status Setup:

Code:

mov.b   r5l, r0l                  ; Get device ID/index
extu.w  r0                        ; Zero-extend to word
extu.l  er0                       ; Zero-extend to long
```

2. Status Bits Manipulation:

Code:

mov.b   @(1:16,er6), r1l         ; Get byte from er6+1
and.b   #0x80, r1l               ; Keep only bit 7
mov.b   @er6, r2l                ; Get byte from er6
and.b   #0x7F, r2l               ; Keep bits 0-6
or.b    r2l, r1l                 ; Combine the bits
mov.b   r1l, @(0x41E864:32,er0)  ; Store to status array at 0x41E864+device_id

3. First IOMEGA Check (Case sensitive):

Code:

mov.l   #8, er0                  ; Length = 8
push.l  er0                      ; Push length
mov.l   #aIomega, er1            ; "IOMEGA  " string
mov.l   er6, er0                 ; Buffer pointer
adds    #8, er0                  ; Buffer+8
jsr     unk_400228              ; Compare strings

4. Second IOMEGA Check (Case insensitive):

Code:

mov.l   #8, er0                  ; Length = 8
push.l  er0 
mov.l   #aIomega_0, er1          ; "iomega  " string
mov.l   er6, er0                 ; Same buffer
adds    #8, er0                  ; Buffer+8
jsr     unk_400228              ; Compare strings

5. ZIP Check:

Code:

mov.l   #3, er0                  ; Length = 3
push.l  er0
mov.l   #aZip, er1               ; "ZIP" string
mov.l   er6, er0                 ; Buffer pointer
add.l   #0x10, er0               ; Buffer+16
jsr     unk_400228              ; Compare strings

6. If ZIP is Found:

Code:

cmp.b   #1, r0l                 ; Check result
bne     loc_12EAA4              ; Skip if not ZIP
mov.b   r5l, r0l                ; Get device ID
mov.b   #1, r1l                 ; Set flag = 1
mov.b   r1l, @(0x41E8AC:32,er0) ; Store flag to array at 0x41E8AC+device_id

This code appears to be validating a device by:
1. Looking for "IOMEGA " (with both case variations)
2. Looking for "ZIP" at offset 0x10
3. Maintaining device status in arrays at 0x41E864 and 0x41E8AC (note the dreaded 0x40xxxx address space)

I'm working through more of the logic, particularly:
1. What happens at loc_12EAA4 (failure path)
2. The code at sub_12F40E, sub_12F482, and sub_12F6B0
3. What happens after a successful validation

Merry Christmas!

Top

Hsiboy

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: December 31st, 2024, 6:07

Joined: January 7th, 2022, 6:43
Posts: 24
Location: United Kingdom

continued....

NOTE: This is the EDIROL A6 firmware.

Aha, I think this completes the validation flow! What i think is happening:

1. If second byte >= 0x50:

Code:

loc_12EB76:
mov.b   r5l, r0l                    ; Get device ID
mov.b   #2, r1l                     ; Status = 2
mov.b   r1l, @(0x41E8AC:32,er0)    ; Store status for device

2. Then check a magic number:

Code:

mov.l   @er4, er0                   ; Get constructed value
cmp.l   #0x951229, er0          ; Compare with 0x951229
bcs     loc_12EBA2                  ; Jump if less than
; If greater or equal:
mov.b   #3, r1l                     ; Status = 3
mov.b   r1l, @(0x41E8AC:32,er0)    ; Store new status

3. Common endpoint (loc_12EBA2):

Code:

mov.b   r5l, r0l
bsr     sub_12F40E                  ; Initialize something - guessing here, need to look.
bsr     sub_12F54C                  ; More initialization?
bsr     sub_12F646                  ; Final initialization??

So I think we have a complete validation sequence that:
1. First checks for "IOMEGA"/"iomega" and "ZIP"
- If found, sets status = 1
2. If not ZIP, builds validation value from device data
- If second byte < 0x50, sets status = 1
- If second byte >= 0x50, sets status = 2
- If constructed value >= 0x951229, sets status = 3

I assume (hope) that the different status values (1,2,3) indicate different device types or capabilities.

TODO:
1. Look at the initialisation routines (sub_12F40E, sub_12F54C, sub_12F646)
2. Track how these status values are used.
3. Analyse what device information is being used to construct the validation value.

Top

Buzunki

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: January 10th, 2025, 18:27

Joined: September 6th, 2023, 7:16
Posts: 8
Location: United Kingdom

@Hsiboy great sleuthing!

Top

Buzunki

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: Yesterday, 16:09

Joined: September 6th, 2023, 7:16
Posts: 8
Location: United Kingdom

I noticed Roger (Midi Maniac) on youtube has done a video about using the ZuluIDE board, I still think a firmware have to allow any IDE card reader is better, because it will hopefully allow larger cards like the Akai MCD does, and it will be a better long term solution. The ZuluIDE currently only supports 100mb which hopefully will change in the future.

Top

Page 12 of 12

[ 238 posts ]

Go to page Previous 1 ... 8, 9, 10, 11, 12

Main » Forums home » Research and development

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum