Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Brian White]

Absolutely.

I've also wanted to dump the roms from all the fb100 clones someday just to
see if they're identical or not. They're probably all the same code, but it
is possible.

By now I have one each of tpdd1 (a few actually), tpdd2, fb100, fdd19, and
purple computing d103. So if I could manage to follow your recipe I am in a
position to dump them all.

bkw

On Tue, Jan 9, 2024, 6:54 PM Darren Clark  wrote:

> TPDD2 firmware dumping - breaking this into a new thread.
>
> It would be interesting to see if we can use the command 'Request Block'
> from page 89 to read the ROM of the CPU...
>
> I dumped the ROM of the TPDD1 and got a good start at reverse
> engineering it and documenting it here
> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
> was over 7 years ago!
>
> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
> just like with TPDD1, that places the firmware/ROM between 0xF000 and
> 0x in memory.
>
> Is there anybody with a TPDD2 willing to try and dump 4K of data from
> 0xF000 to 0x and send it to me so I can start reverse engineering
> and documenting it? It should look somewhat similar to this
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
> outputting good data.
>
>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>
> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
> 64 bytes comes out.
>
>
> Darren Clark
>
>
> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>
> ;--
> ;Memory Map of PDD (using mode 6):
> ;--
> ;-001FInternal Registers (see below)
> ;0080-00FFInternal RAM
> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
> ;8000-87FFExternal RAM (2K)
> ;F000-Internal ROM (4K)
> ;--
> ;I/O ports
> ;Port.BitI/OPin#IDFunction
> ;--
> ;Port1.B0InputPin18P10CTS
> ;Port1.B1InputPin19P11DSR
> ;Port1.B2OutputPin20P12RTS
> ;Port1.B3OutputPin22P13DTR
> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
> ;Port1.B6OutputPin25P16To MA7340
> ;Port1.B7OutputPin26P17SCAN
>
> ;Port2.B0InputPin11P20Mode (pulled Low)
> ;Port2.B1InputPin12P21Mode (pulled Hi)
> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
> ;Port2.B3InputPin14P23(SCI) /RXD
> ;Port2.B4OutputPin15P24(SCI) /TXD
> ;--
>
>
>
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

I happen to have a TPDD2 controller board from a dead drive.  Maybe I could
figure this out.
Steve

On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:

> TPDD2 firmware dumping - breaking this into a new thread.
>
> It would be interesting to see if we can use the command 'Request Block'
> from page 89 to read the ROM of the CPU...
>
> I dumped the ROM of the TPDD1 and got a good start at reverse
> engineering it and documenting it here
> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
> was over 7 years ago!
>
> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
> just like with TPDD1, that places the firmware/ROM between 0xF000 and
> 0x in memory.
>
> Is there anybody with a TPDD2 willing to try and dump 4K of data from
> 0xF000 to 0x and send it to me so I can start reverse engineering
> and documenting it? It should look somewhat similar to this
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
> outputting good data.
>
>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>
> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
> 64 bytes comes out.
>
>
> Darren Clark
>
>
> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>
> ;--
> ;Memory Map of PDD (using mode 6):
> ;--
> ;-001FInternal Registers (see below)
> ;0080-00FFInternal RAM
> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
> ;8000-87FFExternal RAM (2K)
> ;F000-Internal ROM (4K)
> ;--
> ;I/O ports
> ;Port.BitI/OPin#IDFunction
> ;--
> ;Port1.B0InputPin18P10CTS
> ;Port1.B1InputPin19P11DSR
> ;Port1.B2OutputPin20P12RTS
> ;Port1.B3OutputPin22P13DTR
> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
> ;Port1.B6OutputPin25P16To MA7340
> ;Port1.B7OutputPin26P17SCAN
>
> ;Port2.B0InputPin11P20Mode (pulled Low)
> ;Port2.B1InputPin12P21Mode (pulled Hi)
> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
> ;Port2.B3InputPin14P23(SCI) /RXD
> ;Port2.B4OutputPin15P24(SCI) /TXD
> ;--
>
>
>
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Darren Clark]

TPDD2 firmware dumping - breaking this into a new thread.

It would be interesting to see if we can use the command 'Request Block' 
from page 89 to read the ROM of the CPU...


I dumped the ROM of the TPDD1 and got a good start at reverse 
engineering it and documenting it here 
https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that 
was over 7 years ago!


Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6 
just like with TPDD1, that places the firmware/ROM between 0xF000 and 
0x in memory.


Is there anybody with a TPDD2 willing to try and dump 4K of data from 
0xF000 to 0x and send it to me so I can start reverse engineering 
and documenting it? It should look somewhat similar to this 
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is 
outputting good data.


From page 89 GET THE DATA FROM THE DRIVE'S MEMORY

Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of 
64 bytes comes out.



Darren Clark


Here is a memory map of the TPDD1 from my reverse engineering earlier:

;--
;Memory Map of PDD (using mode 6):
;--
;-001F    Internal Registers (see below)
;0080-00FF    Internal RAM
;4000-4003    CPLD (Glue Logic + Hardware IO Control)
;8000-87FF    External RAM (2K)
;F000-    Internal ROM (4K)
;--
;I/O ports
;Port.Bit    I/O        Pin#    ID    Function
;--
;Port1.B0    Input    Pin18    P10    CTS
;Port1.B1    Input    Pin19    P11    DSR
;Port1.B2    Output    Pin20    P12    RTS
;Port1.B3    Output    Pin22    P13    DTR
;Port1.B4    Output    Pin23    P14    PS Alarm (Low Battery LED)
;Port1.B5    Output    Pin24    P15    LED101 (Drive Access LED)
;Port1.B6    Output    Pin25    P16    To MA7340
;Port1.B7    Output    Pin26    P17    SCAN

;Port2.B0    Input    Pin11    P20    Mode (pulled Low)
;Port2.B1    Input    Pin12    P21    Mode (pulled Hi)
;Port2.B2    Input    Pin13    P22    (SCI) CLKOUT from CPLD for BAUD rate
;Port2.B3    Input    Pin14    P23    (SCI) /RXD
;Port2.B4    Output    Pin15    P24    (SCI) /TXD
;--

Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.

[Brian K. White]

On 1/9/24 17:58, John R. Hogerhuis wrote:

Seek/Tell is a community extension to the TPDD file-access-mode protocol

             // Seek (Ken Pettit's proposal) for random access
             // file must have been opened in mode 2 or 4
             // ZZ, $09, $05, (type: Begin = 1, Current = 2, End = 3), 
Little Endian 32-bit offset, checksum


The idea being random access disk images for use with CP/M

LaddieAlpha implements it. NADSBox since it was Ken's proposal.

Doesn't exist on TPDD 1 / 2.

-- John.


Oh very nice, thank you.
--
bkw

Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.

[John R. Hogerhuis]

Seek/Tell is a community extension to the TPDD file-access-mode protocol

// Seek (Ken Pettit's proposal) for random access
// file must have been opened in mode 2 or 4
// ZZ, $09, $05, (type: Begin = 1, Current = 2, End = 3),
Little Endian 32-bit offset, checksum

The idea being random access disk images for use with CP/M

LaddieAlpha implements it. NADSBox since it was Ken's proposal.

Doesn't exist on TPDD 1 / 2.

-- John.

Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.

[Brian K. White]

The TPDD2 service manual in all of its glory...
https://archive.org/details/tpdd-2-service-manual 



I had previously discovered request formats 0x11 and 0x33 which I just 
called UNK11 and UNK33, not yet documented anywhere at the time.
Both do exactly the same thing, which is return a short string of canned 
bytes like "UNK23" does (previously "TS-DOS Mystery") but a different 
set bytes and fewer of them.


The new manual documents 0x23 as Get Version Number,
and 0x33 as Get System Information,
and does not document 0x11

It almost looks like there might be a bitmask going on internally where 
multiple different values might set the right bits to invoke a given 
function, but for official use or documentation they want to avoid 
having request format numbers from the same range as return format 
numbers, so all the requests come from 0x00-0F and returns start at 
0x10, and maybe 0x23 is just an exception. Except there are both 
requests and returns in the same 0x30-3F range, though no full overlaps 
like 0x11.


So I'll just consider 0x11 an undocumented synonym for 0x33 and only 
actually use 0x33 in software now.

That de-mysteries 0x11, 0x23, and 0x33.

A few things that might "do something" or at least respond without 
crashing, but still not documented in either TPDD1 or TPDD2:

(operation-mode request formats)
#define REQ_SEEK  0x09 // ???
#define REQ_TELL  0x0A // ???
#define REQ_SET_EXT   0x0B // ???
#define REQ_EXT_QUERY 0x0E // ???
#define REQ_COND_LIST 0x0F // ??? - TPDD2 responds RET_CACHE_STD

( RET_CACHE_STD is the documented return format 0x38
  #define RET_CACHE_STD 0x38 // TPDD2 shared return format for: 
cache_load cache_write cond_list

)

I don't remember where I got those labels from.
I don't have implementations for any of them in either dl2 or pdd.sh so 
they must just be something I saw somewhere and put in as placeholders 
to fill in as possible later.


--
bkw

Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.

[Brian K. White]

On 1/8/24 22:37, Brian K. White wrote:


Doesn't really answer all questions. What IS the whole memory map that 
those 4 bytes come from, and what even do those 4 bytes mean? Is there 
really a larger field that just always happens to be only 4 out of 16 
bytes used, or are those 4 bytes all there are? I can clone disks by 
copying them, but I still don't know what they mean. I couldn't craft 
a totally synthetic sector & metadata for instance like I could for 
TPDD1.




Obviously I hadn't noticed page 72 yet

--

bkw