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

[R IV]

Sent from my iPad

On Jan 28, 2024, at 5:29 PM, Darren Clark  wrote:



Minor correction. Any commands that get translated to an index higher than 0x13 
will return an invalid command, not crash the firmware.

This statement is incorrect: "I haven't looked for any other logic that would 
prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will 
select addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset."

[F104][58 ][X   ]ASL B;B*2 - set pointer 
correctly for function table
[F105][C1 26  ][ &  ]CMP B #0x26  ;if command > 0x13 
branch to Command_FMT_Invalid
[F107][24 2E  ][$.  ]BCC Command_FMT_Invalid

The "I haven't looked..." part is true, I found it at F014 and F105. So the 
firmware does protect against invalid commands.


Darren Clark




On 1/28/24 12:40, Darren Clark wrote:

The part of the code that picks out the commands is a bit goofy, but I believe 
it's like this to maintain a standard command set across multiple drives with 
other added functionality.

There is a bit mask for the command, so we're only looking at the lower 6 bits 
(0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is masked out of the command 
selection code. It'll require some more digging around to see where it is used.

Here is some of the logic:

If the command = 0x23 (line F0F5), make the command 0x09. This is the Drive 
Version Info command.

If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
0x30 = 0x0E
0x31 = 0x0F
0x32 = 0x10
0x33 = 0x11
0x34 = 0x12

The end result is the command becomes the index of the jump table:

IndexCommandFunction

0x000x00;Command_FMT00_CreateDirectory
0x010x01;Command_FMT01_FileOpen
0x020x02;Command_FMT02_FileClose
0x030x03;Command_FMT03_FileRead
0x040x04;Command_FMT04_File_Write
0x050x05;Command_FMT05_FileDelete
0x060x06;Command_FMT06_DiskFormat
0x070x07;Command_FMT07_DriveStatus
0x080x08;Command_FMT_Invalid
0x090x23;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A0x0A;Command_FMT_Invalid
0x0B0x0B;Command_FMT_Invalid
0x0C0x0C;Command_FMT0C_DriveCondition
0x0D0x0D;Command_FMT0D_FileNameChange
0x0E0x30;Command_FMT30_SectorModeReadWrite
0x0F0x31;Command_FMT31_DriveMemorySet
0x100x32;Command_FMT32_DriveMemoryGet
0x110x33;Command_FMT33_SystemVersionInfo (SM Page 92)
0x120x34;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a command 
0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select addresses past the jump 
table (author name and reset vector table) causing the firmware to crash and 
reset.

Also command 0x0F is the same as 0x31, so it returns the memory set return 
block 0x38. And looking at the table, there are several other overlapping 
commands: 0x0E, 0x10, 0x11, 0x12


The memory write commands set flags in the internal RAM, these need to still be 
deciphered.

There is also a block of code that reads a file off of a disk into the 2K 
external RAM and executes it.



On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead of full 
of mysteries and "here we recite the words lest the gods be angry".

Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like that too 
where an undocumented code results in some other response than the invalid code 
response.
It's like it's not checking the entire value but masking bits, and looking at 
fewer than all 8 bits, and multiple values can give the same bits.
Definitely bank 1 must work that way. A bunch of commands that all get one part 
of their meaning changed by adding 0x40, which is just flipping 1 bit on the 
normal command code.
IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the words here" 
there are a few things exactly like that.

The service manual describes a routine it calls "reset drive status" on pg 102. 
It's just using mem_write to write 3 bytes at 3 addresses but doesn't explain 
what they do.
write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba also does something similar but not the 
same, just before each each cache commit (write cache to disk):
write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 before each 
cache write-to-disk.
https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 

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

[R IV]

E

Sent from my iPad

On Jan 28, 2024, at 5:29 PM, Darren Clark  wrote:



Minor correction. Any commands that get translated to an index higher than 0x13 
will return an invalid command, not crash the firmware.

This statement is incorrect: "I haven't looked for any other logic that would 
prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will 
select addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset."

[F104][58 ][X   ]ASL B;B*2 - set pointer 
correctly for function table
[F105][C1 26  ][ &  ]CMP B #0x26  ;if command > 0x13 
branch to Command_FMT_Invalid
[F107][24 2E  ][$.  ]BCC Command_FMT_Invalid

The "I haven't looked..." part is true, I found it at F014 and F105. So the 
firmware does protect against invalid commands.


Darren Clark




On 1/28/24 12:40, Darren Clark wrote:

The part of the code that picks out the commands is a bit goofy, but I believe 
it's like this to maintain a standard command set across multiple drives with 
other added functionality.

There is a bit mask for the command, so we're only looking at the lower 6 bits 
(0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is masked out of the command 
selection code. It'll require some more digging around to see where it is used.

Here is some of the logic:

If the command = 0x23 (line F0F5), make the command 0x09. This is the Drive 
Version Info command.

If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
0x30 = 0x0E
0x31 = 0x0F
0x32 = 0x10
0x33 = 0x11
0x34 = 0x12

The end result is the command becomes the index of the jump table:

IndexCommandFunction

0x000x00;Command_FMT00_CreateDirectory
0x010x01;Command_FMT01_FileOpen
0x020x02;Command_FMT02_FileClose
0x030x03;Command_FMT03_FileRead
0x040x04;Command_FMT04_File_Write
0x050x05;Command_FMT05_FileDelete
0x060x06;Command_FMT06_DiskFormat
0x070x07;Command_FMT07_DriveStatus
0x080x08;Command_FMT_Invalid
0x090x23;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A0x0A;Command_FMT_Invalid
0x0B0x0B;Command_FMT_Invalid
0x0C0x0C;Command_FMT0C_DriveCondition
0x0D0x0D;Command_FMT0D_FileNameChange
0x0E0x30;Command_FMT30_SectorModeReadWrite
0x0F0x31;Command_FMT31_DriveMemorySet
0x100x32;Command_FMT32_DriveMemoryGet
0x110x33;Command_FMT33_SystemVersionInfo (SM Page 92)
0x120x34;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a command 
0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select addresses past the jump 
table (author name and reset vector table) causing the firmware to crash and 
reset.

Also command 0x0F is the same as 0x31, so it returns the memory set return 
block 0x38. And looking at the table, there are several other overlapping 
commands: 0x0E, 0x10, 0x11, 0x12


The memory write commands set flags in the internal RAM, these need to still be 
deciphered.

There is also a block of code that reads a file off of a disk into the 2K 
external RAM and executes it.



On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead of full 
of mysteries and "here we recite the words lest the gods be angry".

Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like that too 
where an undocumented code results in some other response than the invalid code 
response.
It's like it's not checking the entire value but masking bits, and looking at 
fewer than all 8 bits, and multiple values can give the same bits.
Definitely bank 1 must work that way. A bunch of commands that all get one part 
of their meaning changed by adding 0x40, which is just flipping 1 bit on the 
normal command code.
IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the words here" 
there are a few things exactly like that.

The service manual describes a routine it calls "reset drive status" on pg 102. 
It's just using mem_write to write 3 bytes at 3 addresses but doesn't explain 
what they do.
write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba also does something similar but not the 
same, just before each each cache commit (write cache to disk):
write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 before each 
cache write-to-disk.
https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 

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

[Darren Clark]

Minor correction. Any commands that get translated to an index higher 
than 0x13 will return an invalid command, not crash the firmware.


This statement is incorrect: "I haven't looked for any other logic that 
would prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to 
0x3F will select addresses past the jump table (author name and reset 
vector table) causing the firmware to crash and reset."


[F104]    [58 ]    [X   ] ASL B            ;B*2 - set pointer 
correctly for function table
[F105]    [C1 26  ]    [ &  ]        CMP B #0x26 ;if command > 0x13 
branch to Command_FMT_Invalid

[F107]    [24 2E  ]    [$.  ]        BCC Command_FMT_Invalid

The "I haven't looked..." part is true, I found it at F014 and F105. So 
the firmware does protect against invalid commands.



Darren Clark




On 1/28/24 12:40, Darren Clark wrote:


The part of the code that picks out the commands is a bit goofy, but I 
believe it's like this to maintain a standard command set across 
multiple drives with other added functionality.


There is a bit mask for the command, so we're only looking at the 
lower 6 bits (0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is 
masked out of the command selection code. It'll require some more 
digging around to see where it is used.


Here is some of the logic:

    If the command = 0x23 (line F0F5), make the command 0x09. This is 
the Drive Version Info command.


    If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
    0x30 = 0x0E
    0x31 = 0x0F
    0x32 = 0x10
    0x33 = 0x11
    0x34 = 0x12

The end result is the command becomes the index of the jump table:

Index    Command    Function

0x00    0x00 ;Command_FMT00_CreateDirectory
0x01    0x01    ;Command_FMT01_FileOpen
0x02    0x02    ;Command_FMT02_FileClose
0x03    0x03    ;Command_FMT03_FileRead
0x04    0x04    ;Command_FMT04_File_Write
0x05    0x05    ;Command_FMT05_FileDelete
0x06    0x06    ;Command_FMT06_DiskFormat
0x07    0x07    ;Command_FMT07_DriveStatus
0x08    0x08    ;Command_FMT_Invalid
0x09    0x23    ;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A    0x0A    ;Command_FMT_Invalid
0x0B    0x0B    ;Command_FMT_Invalid
0x0C    0x0C    ;Command_FMT0C_DriveCondition
0x0D    0x0D    ;Command_FMT0D_FileNameChange
0x0E    0x30    ;Command_FMT30_SectorModeReadWrite
0x0F    0x31    ;Command_FMT31_DriveMemorySet
0x10    0x32    ;Command_FMT32_DriveMemoryGet
0x11    0x33    ;Command_FMT33_SystemVersionInfo (SM Page 92)
0x12    0x34    ;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a 
command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select 
addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset.


Also command 0x0F is the same as 0x31, so it returns the memory set 
return block 0x38. And looking at the table, there are several other 
overlapping commands: 0x0E, 0x10, 0x11, 0x12



The memory write commands set flags in the internal RAM, these need to 
still be deciphered.


There is also a block of code that reads a file off of a disk into the 
2K external RAM and executes it.




On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead 
of full of mysteries and "here we recite the words lest the gods be 
angry".


Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like 
that too where an undocumented code results in some other response 
than the invalid code response.
It's like it's not checking the entire value but masking bits, and 
looking at fewer than all 8 bits, and multiple values can give the 
same bits.
Definitely bank 1 must work that way. A bunch of commands that all 
get one part of their meaning changed by adding 0x40, which is just 
flipping 1 bit on the normal command code.

IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the 
words here" there are a few things exactly like that.


The service manual describes a routine it calls "reset drive status" 
on pg 102. It's just using mem_write to write 3 bytes at 3 addresses 
but doesn't explain what they do.

write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba  also does something similar 
but not the same, just before each each cache commit (write cache to 
disk):

write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 
before each cache write-to-disk.

https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 38 01 00 C6
17/08/2016 20:03:01.676 [M100] - 5A 5A 31 04 01 00 96 

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

[Brian K. White]

This doesn't matter but on the TPDD1, if you set the dip switches to
OFF ON ON ON, then you can dump the rom at 19200, and in that case I 
need to add a sleep after each S-record. I added 30ms just based a note 
for something else somewhere in the service manual that you should wait 
25ms to between sending and reading, and 20ms didn't work, 25 did. So I 
just padded that to 30 to be safe.

No per-char delay, just one per S-rec.

The other "init 19200" setting in the manual seems to be something that 
reads the disk automatically like tpdd2 does.


The tpdd1 software manual dip switch table says:
"
mode baud   1   2   3   4
init 9600   ON  ON  ON  ON *
init19200*  OFF ON  ON  ON *
init19200*  ON  OFF ON  ON
[...]
* First 19200 is for initialization. Second 19200 is for boot sequence 
(operation mode).

"

And the rom dumper works at 19200 with OFF ON ON ON,

And ON OFF ON ON does the following right at power-on:

- With no drive inserted, door open or closed:
  Batt light flash rapidly and continuously.

- With a disk inserted but not the tpdd1 util disk, this includes a 
regular filesystem disk, a raw data disk (no filesystem, ie the sardine 
dictionary disk), or a tpdd2 disk that the drive can't read at all.:
  Drive access light and disk motor on for about 1 second, then off, 
repeat forever.


- With the tpdd1 util disk inserted:
  Drive access light and disk motor on for about one second, then off, 
and stays off.


But although something about the tpdd1 util disk satisifies the drive in 
some way, it doesn't work like the tpdd2 bootstrap where you just open 
the com port before powering on and the drive will start spitting 
something out the serial port without having to send those srecords from 
the normal tpdd1 boot directions.


I can only guess this was never intended for the fb-100 or knitting 
machines, since the fb-100 has only solder-jumpers in place of the dip 
switches. But maybe the same drive was going to be built in to some word 
processor or typewriter.


On 1/28/24 13:11, Darren Clark wrote:
Nice find! I wasn't looking at port 4 data since I assumed it was all 
address outputs, but P43, P44, P45 are configured as inputs on the TPDD2 
(not on the TPPD1).


;Port4.B0    I/O        Pin37    P40    A8
;Port4.B1    I/O        Pin36    P41    A9
;Port4.B2    I/O        Pin35    P42    A10
;Port4.B3    Input    Pin32    P43    A11 E1    *Config jumper pulled hi
;Port4.B4    Input    Pin31    P44    A12 E2    *Config jumper pulled hi
;Port4.B5    Input    Pin30    P45    A13 E3    *Config jumper pulled hi
;Port4.B6    I/O        Pin29    P46    A14 *CS1 on CPLD
;Port4.B7    I/O        Pin28    P47    A15 *CS0 on CPLD

I've renamed the variable from '(RAM_INT)SerDatTX_2' to 
'(RAM_INT)PCB_ConfigSwitchesE1E2E3' this makes more sense.


I see in the code (F1FE to F210) the firmware is looking at E3 to 
determine while transmitting data to the serial port if it should use 
hardware flow control or XON (0x11) / XOFF (0x13), and then reads the 
serial data looking for an XON or XOFF byte.


E1 = ??

E2 = ??

E3 = Flow control - open is hardware, closed is software.


Another TPDD2 secret discovered! I'll do some more documenting in the 
code and update my GitHub tonight.



Daren Clark


On 1/28/24 08:48, Stephen Adolph wrote:

I'll add some info from your nicely documented code.

* A13 value is tested at 0xF1FE, and controls a branch to 0xF1EB; 
seems to change the way serial data is transmitted. hardware default 
is to branch.
* A12 value is tested at 0xF071, not sure what it does yet.  hardware 
default is to branch.
* A11 value is tested at 0xFF48, seems to change hardware interrupt 
handling. hardware default is to branch.


On Sun, Jan 28, 2024 at 8:31 AM Stephen Adolph  
wrote:


Darren, another question,
There are some inputs on pins 30,31,32 (called A13, A12, A11) that
correspond to P45, P44, P43 on the HD6301.

Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28
for P40-P47.

I'll go look at the code, but these 3 inputs are configurable.   I
wonder what they do?

Steve





On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph
 wrote:

Thanks Darren.

Now that we have the real tpdd firmware I wonder what we can
do with it.  Some of those variables look tempting, like side
and # of tracks.

Another question.. it looks like was there a second
unpopulated serial port on the drive? Anything in the code on
that?
P7 is unpopulated and not in the schematic, but it is there.

Steve







--
bkw

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

[Darren Clark]

Nice find! I wasn't looking at port 4 data since I assumed it was all 
address outputs, but P43, P44, P45 are configured as inputs on the TPDD2 
(not on the TPPD1).


;Port4.B0    I/O        Pin37    P40    A8
;Port4.B1    I/O        Pin36    P41    A9
;Port4.B2    I/O        Pin35    P42    A10
;Port4.B3    Input    Pin32    P43    A11 E1    *Config jumper pulled hi
;Port4.B4    Input    Pin31    P44    A12 E2    *Config jumper pulled hi
;Port4.B5    Input    Pin30    P45    A13 E3    *Config jumper pulled hi
;Port4.B6    I/O        Pin29    P46    A14 *CS1 on CPLD
;Port4.B7    I/O        Pin28    P47    A15 *CS0 on CPLD

I've renamed the variable from '(RAM_INT)SerDatTX_2' to 
'(RAM_INT)PCB_ConfigSwitchesE1E2E3' this makes more sense.


I see in the code (F1FE to F210) the firmware is looking at E3 to 
determine while transmitting data to the serial port if it should use 
hardware flow control or XON (0x11) / XOFF (0x13), and then reads the 
serial data looking for an XON or XOFF byte.


E1 = ??

E2 = ??

E3 = Flow control - open is hardware, closed is software.


Another TPDD2 secret discovered! I'll do some more documenting in the 
code and update my GitHub tonight.



Daren Clark


On 1/28/24 08:48, Stephen Adolph wrote:

I'll add some info from your nicely documented code.

* A13 value is tested at 0xF1FE, and controls a branch to 0xF1EB; 
seems to change the way serial data is transmitted. hardware default 
is to branch.
* A12 value is tested at 0xF071, not sure what it does yet.  hardware 
default is to branch.
* A11 value is tested at 0xFF48, seems to change hardware interrupt 
handling. hardware default is to branch.


On Sun, Jan 28, 2024 at 8:31 AM Stephen Adolph  
wrote:


Darren, another question,
There are some inputs on pins 30,31,32 (called A13, A12, A11) that
correspond to P45, P44, P43 on the HD6301.

Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28
for P40-P47.

I'll go look at the code, but these 3 inputs are configurable.   I
wonder what they do?

Steve





On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph
 wrote:

Thanks Darren.

Now that we have the real tpdd firmware I wonder what we can
do with it.  Some of those variables look tempting, like side
and # of tracks.

Another question.. it looks like was there a second
unpopulated serial port on the drive? Anything in the code on
that?
P7 is unpopulated and not in the schematic, but it is there.

Steve

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

[Darren Clark]

I don't see anything in the code that reads the drive parameter table 
other than the command to output that data. I'm guessing Brother may 
have other drives with more capabilities and this is only there to tell 
the host how the drive is configured.


Also I don't see anything for a second serial port in the code. What is 
P7 connected to? I'd like to see some pictures since I don't have the 
hardware. But looking at the CPU so far, it seems almost every pin is in 
use.


;--
;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    Alarm
;Port1.B5    Output    Pin24    P15    WC on R/W module
;Port1.B6    Output    Pin25    P16    Drives LED1
;Port1.B7    Output    Pin26    P17    Scan

;Port2.B0    Output    Pin11    P20    Serial Output enable, Mode 
(pulled Low)

;Port2.B1    Input    Pin12    P21    Mode (pulled Hi)
;Port2.B2    Input    Pin13    P22    (SCI) CLKOUT from CPLD for BAUD 
rate (start Hi)

;Port2.B3    Input    Pin14    P23    (SCI) /RXD
;Port2.B4    Output    Pin15    P24    (SCI) /TXD
;Port2.B5    N/A
;Port2.B6    N/A
;Port2.B7    N/A

;Port3.B0    I/O        Pin51    P30    AD0
;Port3.B1    I/O        Pin50    P31    AD1
;Port3.B2    I/O        Pin45    P32    AD2
;Port3.B3    I/O        Pin44    P33    AD3
;Port3.B4    I/O        Pin43    P34    AD4
;Port3.B5    I/O        Pin42    P35    AD5
;Port3.B6    I/O        Pin41    P36    AD6
;Port3.B7    I/O        Pin40    P37    AD7

;Port4.B0    I/O        Pin37    P40    A8
;Port4.B1    I/O        Pin36    P41    A9
;Port4.B2    I/O        Pin35    P42    A10
;Port4.B3    Input    Pin32    P43    A11 E1    *Config jumper pulled hi
;Port4.B4    Input    Pin31    P44    A12 E2    *Config jumper pulled hi
;Port4.B5    Input    Pin30    P45    A13 E3    *Config jumper pulled hi
;Port4.B6    I/O        Pin29    P46    A14 *CS1 on CPLD
;Port4.B7    I/O        Pin28    P47    A15 *CS0 on CPLD



On 1/28/24 08:21, Stephen Adolph wrote:

Thanks Darren.

Now that we have the real tpdd firmware I wonder what we can do with 
it.  Some of those variables look tempting, like side and # of tracks.


Another question.. it looks like was there a second unpopulated serial 
port on the drive?  Anything in the code on that?

P7 is unpopulated and not in the schematic, but it is there.

Steve






On Sunday, January 28, 2024, Darren Clark  wrote:

Spent some time digging through the source of the TPDD2 firmware,
adding comments, labels, and variable names.

It's documented (as far as I got so far) here:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM

Doesn't look like any hidden commands exist in the firmware. This
is the list from the command table at 0xFFB9:

code    0xF230 Command_FMT00_CreateDirectory
code    0xF4D0            Command_FMT01_FileOpen
code    0xF495            Command_FMT02_FileClose
code    0xF69D            Command_FMT03_FileRead
code    0xF63D            Command_FMT04_File_Write
code    0xF425            Command_FMT05_FileDelete
code    0xF212            Command_FMT06_DiskFormat
code    0xF6F3            Command_FMT07_DriveStatus
code    0xF137            Command_FMT_Invalid
code    0xF75F            Command_FMT23_DriveVersionInfo
code    0xF746            Command_FMT0C_DriveCondition
code    0xF365            Command_FMT0D_FileNameChange
code    0xF801            Command_FMT30_SectorModeReadWrite
code    0xF76B            Command_FMT31_DriveMemorySet
code    0xF78E            Command_FMT32_DriveMemoryGet
code    0xF757            Command_FMT33_SystemVersionInfo
code    0xF7DC            Command_FMT34_ExecuteProgram

Some other interesting tables are at 0xFF67 and 0xFF6D

[FF67]    [80 ]    [    ] Table_SysInfo:    DB 0x80   
;Hard sector data port address MSB
[FF68]    [13 ]    [    ]        DB    0x13    ;Hard
sector data port address LSB
[FF69]    [05 ]    [    ]        DB    0x05 ;Buffer size MSB
[FF6A]    [00 ]    [    ]        DB    0x00 ;Buffer size LSB
[FF6B]    [10 ]    [    ]        DB    0x10    ;CPU type.
0x10 = HD6301
[FF6C]    [E1 ]    [    ]        DB    0xE1 ;Model code

[FF6D]    [41 ]    [A   ]    Table_Version:    DB 0x41   
;System Version Number MSB
[FF6E]    [10 ]    [    ]        DB    0x10 ;System
Version Number LSB
[FF6F]    [01 ]    [    ]        DB    0x01 ;Number of sides
[FF70]    [00 ]    [    ]        DB    0x00 ;Number of
tracks MSB
[FF71]    [50 ]    [P   ]        DB    0x50 ;Number of
tracks LSB
[FF72]    [05   

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

[Darren Clark]

The part of the code that picks out the commands is a bit goofy, but I 
believe it's like this to maintain a standard command set across 
multiple drives with other added functionality.


There is a bit mask for the command, so we're only looking at the lower 
6 bits (0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is masked out 
of the command selection code. It'll require some more digging around to 
see where it is used.


Here is some of the logic:

    If the command = 0x23 (line F0F5), make the command 0x09. This is 
the Drive Version Info command.


    If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
    0x30 = 0x0E
    0x31 = 0x0F
    0x32 = 0x10
    0x33 = 0x11
    0x34 = 0x12

The end result is the command becomes the index of the jump table:

Index    Command    Function

0x00    0x00 ;Command_FMT00_CreateDirectory
0x01    0x01    ;Command_FMT01_FileOpen
0x02    0x02    ;Command_FMT02_FileClose
0x03    0x03    ;Command_FMT03_FileRead
0x04    0x04    ;Command_FMT04_File_Write
0x05    0x05    ;Command_FMT05_FileDelete
0x06    0x06    ;Command_FMT06_DiskFormat
0x07    0x07    ;Command_FMT07_DriveStatus
0x08    0x08    ;Command_FMT_Invalid
0x09    0x23    ;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A    0x0A    ;Command_FMT_Invalid
0x0B    0x0B    ;Command_FMT_Invalid
0x0C    0x0C    ;Command_FMT0C_DriveCondition
0x0D    0x0D    ;Command_FMT0D_FileNameChange
0x0E    0x30    ;Command_FMT30_SectorModeReadWrite
0x0F    0x31    ;Command_FMT31_DriveMemorySet
0x10    0x32    ;Command_FMT32_DriveMemoryGet
0x11    0x33    ;Command_FMT33_SystemVersionInfo (SM Page 92)
0x12    0x34    ;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a 
command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select 
addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset.


Also command 0x0F is the same as 0x31, so it returns the memory set 
return block 0x38. And looking at the table, there are several other 
overlapping commands: 0x0E, 0x10, 0x11, 0x12



The memory write commands set flags in the internal RAM, these need to 
still be deciphered.


There is also a block of code that reads a file off of a disk into the 
2K external RAM and executes it.




On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead 
of full of mysteries and "here we recite the words lest the gods be 
angry".


Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like 
that too where an undocumented code results in some other response 
than the invalid code response.
It's like it's not checking the entire value but masking bits, and 
looking at fewer than all 8 bits, and multiple values can give the 
same bits.
Definitely bank 1 must work that way. A bunch of commands that all get 
one part of their meaning changed by adding 0x40, which is just 
flipping 1 bit on the normal command code.

IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the 
words here" there are a few things exactly like that.


The service manual describes a routine it calls "reset drive status" 
on pg 102. It's just using mem_write to write 3 bytes at 3 addresses 
but doesn't explain what they do.

write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba  also does something similar but 
not the same, just before each each cache commit (write cache to disk):

write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 
before each cache write-to-disk.

https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 38 01 00 C6
17/08/2016 20:03:01.676 [M100] - 5A 5A 31 04 01 00 96 00 33
17/08/2016 20:03:01.679 [TPDD] - 38 01 00 C6
...

They are in the cpu internal 128 bytes is all I can tell.

Maybe one of those bytes holds the drive status/condition bit flags 
used by the status or condition commands?


Also I just realized I was dumb to talk about reading the external 2k 
ram on TPDD1 before. On TPDD1 you can't read any ram without rebooting 
into the special cpu mode anyway, so it's not like you can examine the 
ram to see where the drive stored bits of info about the disk or a 
loaded sector or anything like that, so there is no point to a more 
generic version of the rom dumper.


... and as soon as I said that I thought, well maybe as a drive 
diagnostic tool, you could read the sensors directly instead of 
relying on the drive firmware to report error conditions while trying 
to repair a drive or something. Maybe even operate the 

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

[Brian K. White]

This is great for making the emulators and clients definitive instead of 
full of mysteries and "here we recite the words lest the gods be angry".


Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like that 
too where an undocumented code results in some other response than the 
invalid code response.
It's like it's not checking the entire value but masking bits, and 
looking at fewer than all 8 bits, and multiple values can give the same 
bits.
Definitely bank 1 must work that way. A bunch of commands that all get 
one part of their meaning changed by adding 0x40, which is just flipping 
1 bit on the normal command code.

IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the 
words here" there are a few things exactly like that.


The service manual describes a routine it calls "reset drive status" on 
pg 102. It's just using mem_write to write 3 bytes at 3 addresses but 
doesn't explain what they do.

write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba  also does something similar but 
not the same, just before each each cache commit (write cache to disk):

write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 before 
each cache write-to-disk.

https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 38 01 00 C6
17/08/2016 20:03:01.676 [M100] - 5A 5A 31 04 01 00 96 00 33
17/08/2016 20:03:01.679 [TPDD] - 38 01 00 C6
...

They are in the cpu internal 128 bytes is all I can tell.

Maybe one of those bytes holds the drive status/condition bit flags used 
by the status or condition commands?


Also I just realized I was dumb to talk about reading the external 2k 
ram on TPDD1 before. On TPDD1 you can't read any ram without rebooting 
into the special cpu mode anyway, so it's not like you can examine the 
ram to see where the drive stored bits of info about the disk or a 
loaded sector or anything like that, so there is no point to a more 
generic version of the rom dumper.


... and as soon as I said that I thought, well maybe as a drive 
diagnostic tool, you could read the sensors directly instead of relying 
on the drive firmware to report error conditions while trying to repair 
a drive or something. Maybe even operate the gate array?


It is a marvel getting that much functionality out of so few bytes.

--
bkw

On Sun, Jan 28, 2024, 12:19 AM Darren Clark  wrote:

   Spent some time digging through the source of the TPDD2 firmware,
   adding
   comments, labels, and variable names.

   It's documented (as far as I got so far) here:
   https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM

   Doesn't look like any hidden commands exist in the firmware. This is
   the
   list from the command table at 0xFFB9:

   code    0xF230 Command_FMT00_CreateDirectory
   code    0xF4D0            Command_FMT01_FileOpen
   code    0xF495            Command_FMT02_FileClose
   code    0xF69D            Command_FMT03_FileRead
   code    0xF63D            Command_FMT04_File_Write
   code    0xF425            Command_FMT05_FileDelete
   code    0xF212            Command_FMT06_DiskFormat
   code    0xF6F3            Command_FMT07_DriveStatus
   code    0xF137            Command_FMT_Invalid
   code    0xF75F            Command_FMT23_DriveVersionInfo
   code    0xF746            Command_FMT0C_DriveCondition
   code    0xF365            Command_FMT0D_FileNameChange
   code    0xF801            Command_FMT30_SectorModeReadWrite
   code    0xF76B            Command_FMT31_DriveMemorySet
   code    0xF78E            Command_FMT32_DriveMemoryGet
   code    0xF757            Command_FMT33_SystemVersionInfo
   code    0xF7DC            Command_FMT34_ExecuteProgram

   Some other interesting tables are at 0xFF67 and 0xFF6D

   [FF67]    [80 ]    [    ] Table_SysInfo:    DB 0x80    ;Hard
   sector data port address MSB
   [FF68]    [13 ]    [    ]        DB    0x13    ;Hard sector
   data
   port address LSB
   [FF69]    [05 ]    [    ]        DB    0x05    ;Buffer size MSB
   [FF6A]    [00 ]    [    ]        DB    0x00    ;Buffer size LSB
   [FF6B]    [10 ]    [    ]        DB    0x10    ;CPU type.
   0x10 =
   HD6301
   [FF6C]    [E1 ]    [    ]        DB    0xE1    ;Model code

   [FF6D]    [41 ]    [A   ]    Table_Version:    DB 0x41
   ;System Version Number MSB
   [FF6E]    [10 ]    [    ]        DB    0x10    ;System Version
   Number LSB
   [FF6F]    [01 ]    [    ]        DB    0x01    ;Number of sides
   [FF70]    [00 ]    [    ]        DB    0x00    ;Number of
   tracks MSB
   [FF71]    

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

[Stephen Adolph]

I'll add some info from your nicely documented code.

* A13 value is tested at 0xF1FE, and controls a branch to 0xF1EB; seems to
change the way serial data is transmitted. hardware default is to branch.
* A12 value is tested at 0xF071, not sure what it does yet.  hardware
default is to branch.
* A11 value is tested at 0xFF48, seems to change hardware interrupt
handling. hardware default is to branch.

On Sun, Jan 28, 2024 at 8:31 AM Stephen Adolph  wrote:

> Darren, another question,
> There are some inputs on pins 30,31,32 (called A13, A12, A11) that
> correspond to P45, P44, P43 on the HD6301.
>
> Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28 for
> P40-P47.
>
> I'll go look at the code, but these 3 inputs are configurable.   I wonder
> what they do?
>
> Steve
>
>
>
>
>
> On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph 
> wrote:
>
>> Thanks Darren.
>>
>> Now that we have the real tpdd firmware I wonder what we can do with it.
>> Some of those variables look tempting, like side and # of tracks.
>>
>> Another question.. it looks like was there a second unpopulated serial
>> port on the drive?  Anything in the code on that?
>> P7 is unpopulated and not in the schematic, but it is there.
>>
>> Steve
>>
>>
>>
>>
>>
>>

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

[Stephen Adolph]

Darren, another question,
There are some inputs on pins 30,31,32 (called A13, A12, A11) that
correspond to P45, P44, P43 on the HD6301.

Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28 for
P40-P47.

I'll go look at the code, but these 3 inputs are configurable.   I wonder
what they do?

Steve





On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph  wrote:

> Thanks Darren.
>
> Now that we have the real tpdd firmware I wonder what we can do with it.
> Some of those variables look tempting, like side and # of tracks.
>
> Another question.. it looks like was there a second unpopulated serial
> port on the drive?  Anything in the code on that?
> P7 is unpopulated and not in the schematic, but it is there.
>
> Steve
>
>
>
>
>
>
> On Sunday, January 28, 2024, Darren Clark  wrote:
>
>> Spent some time digging through the source of the TPDD2 firmware, adding
>> comments, labels, and variable names.
>>
>> It's documented (as far as I got so far) here:
>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
>>
>> Doesn't look like any hidden commands exist in the firmware. This is the
>> list from the command table at 0xFFB9:
>>
>> code0xF230 Command_FMT00_CreateDirectory
>> code0xF4D0Command_FMT01_FileOpen
>> code0xF495Command_FMT02_FileClose
>> code0xF69DCommand_FMT03_FileRead
>> code0xF63DCommand_FMT04_File_Write
>> code0xF425Command_FMT05_FileDelete
>> code0xF212Command_FMT06_DiskFormat
>> code0xF6F3Command_FMT07_DriveStatus
>> code0xF137Command_FMT_Invalid
>> code0xF75FCommand_FMT23_DriveVersionInfo
>> code0xF746Command_FMT0C_DriveCondition
>> code0xF365Command_FMT0D_FileNameChange
>> code0xF801Command_FMT30_SectorModeReadWrite
>> code0xF76BCommand_FMT31_DriveMemorySet
>> code0xF78ECommand_FMT32_DriveMemoryGet
>> code0xF757Command_FMT33_SystemVersionInfo
>> code0xF7DCCommand_FMT34_ExecuteProgram
>>
>> Some other interesting tables are at 0xFF67 and 0xFF6D
>>
>> [FF67][80 ][] Table_SysInfo:DB0x80;Hard
>> sector data port address MSB
>> [FF68][13 ][]DB0x13;Hard sector data
>> port address LSB
>> [FF69][05 ][]DB0x05;Buffer size MSB
>> [FF6A][00 ][]DB0x00;Buffer size LSB
>> [FF6B][10 ][]DB0x10;CPU type. 0x10 =
>> HD6301
>> [FF6C][E1 ][]DB0xE1;Model code
>>
>> [FF6D][41 ][A   ]Table_Version:DB 0x41;System
>> Version Number MSB
>> [FF6E][10 ][]DB0x10;System Version
>> Number LSB
>> [FF6F][01 ][]DB0x01;Number of sides
>> [FF70][00 ][]DB0x00;Number of tracks
>> MSB
>> [FF71][50 ][P   ]DB0x50;Number of tracks
>> LSB
>> [FF72][05 ][]DB0x05;Sector length MSB
>> [FF73][00 ][]DB0x00;Sector length LSB
>> [FF74][02 ][]DB0x02;Sectors per track
>> [FF75][00 ][]DB0x00 ;Directory Entries MSB
>> [FF76][28 ][(   ]DB0x28 ;Directory Entries LSB
>> [FF77][00 ][]DB0x00;Max files
>> [FF78][E1 ][]DB0xE1;Model code
>>
>> There is also a BAUD rate table at 0xFF85, I see logic for reading the
>> dip switch setting from the CPLD at the program initialization. 2 switches
>> for the BAUD rate and the other 2 for some other mode settings. Just a
>> w.a.g. it almost looks like the programming on the CPLD could be the same
>> on the TPPD2 as the TPPD1. It might be possible to set 9600 and 38400 BAUD,
>> just guessing though as I don't have any TPDD2 hardware to play with.
>>
>> Overall an amazing amount of work went into this firmware. From what I
>> can see, it's all hand coded and has a lot of space saving optimizations in
>> it. Out of 4K of available space, there is only 15 bytes of unused space,
>> and the author put his name into it (with one byte filled with a 0xFF):
>>
>> [FFDF][***][] DB'(C) M.FUTAMURA',0xFF;Author
>>
>>
>>
>> Darren Clark
>>
>>
>>
>>
>>
>>

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

[Stephen Adolph]

Thanks Darren.

Now that we have the real tpdd firmware I wonder what we can do with it.
Some of those variables look tempting, like side and # of tracks.

Another question.. it looks like was there a second unpopulated serial port
on the drive?  Anything in the code on that?
P7 is unpopulated and not in the schematic, but it is there.

Steve






On Sunday, January 28, 2024, Darren Clark  wrote:

> Spent some time digging through the source of the TPDD2 firmware, adding
> comments, labels, and variable names.
>
> It's documented (as far as I got so far) here:
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
>
> Doesn't look like any hidden commands exist in the firmware. This is the
> list from the command table at 0xFFB9:
>
> code0xF230 Command_FMT00_CreateDirectory
> code0xF4D0Command_FMT01_FileOpen
> code0xF495Command_FMT02_FileClose
> code0xF69DCommand_FMT03_FileRead
> code0xF63DCommand_FMT04_File_Write
> code0xF425Command_FMT05_FileDelete
> code0xF212Command_FMT06_DiskFormat
> code0xF6F3Command_FMT07_DriveStatus
> code0xF137Command_FMT_Invalid
> code0xF75FCommand_FMT23_DriveVersionInfo
> code0xF746Command_FMT0C_DriveCondition
> code0xF365Command_FMT0D_FileNameChange
> code0xF801Command_FMT30_SectorModeReadWrite
> code0xF76BCommand_FMT31_DriveMemorySet
> code0xF78ECommand_FMT32_DriveMemoryGet
> code0xF757Command_FMT33_SystemVersionInfo
> code0xF7DCCommand_FMT34_ExecuteProgram
>
> Some other interesting tables are at 0xFF67 and 0xFF6D
>
> [FF67][80 ][] Table_SysInfo:DB0x80;Hard
> sector data port address MSB
> [FF68][13 ][]DB0x13;Hard sector data
> port address LSB
> [FF69][05 ][]DB0x05;Buffer size MSB
> [FF6A][00 ][]DB0x00;Buffer size LSB
> [FF6B][10 ][]DB0x10;CPU type. 0x10 =
> HD6301
> [FF6C][E1 ][]DB0xE1;Model code
>
> [FF6D][41 ][A   ]Table_Version:DB 0x41;System
> Version Number MSB
> [FF6E][10 ][]DB0x10;System Version
> Number LSB
> [FF6F][01 ][]DB0x01;Number of sides
> [FF70][00 ][]DB0x00;Number of tracks
> MSB
> [FF71][50 ][P   ]DB0x50;Number of tracks
> LSB
> [FF72][05 ][]DB0x05;Sector length MSB
> [FF73][00 ][]DB0x00;Sector length LSB
> [FF74][02 ][]DB0x02;Sectors per track
> [FF75][00 ][]DB0x00 ;Directory Entries MSB
> [FF76][28 ][(   ]DB0x28 ;Directory Entries LSB
> [FF77][00 ][]DB0x00;Max files
> [FF78][E1 ][]DB0xE1;Model code
>
> There is also a BAUD rate table at 0xFF85, I see logic for reading the dip
> switch setting from the CPLD at the program initialization. 2 switches for
> the BAUD rate and the other 2 for some other mode settings. Just a w.a.g.
> it almost looks like the programming on the CPLD could be the same on the
> TPPD2 as the TPPD1. It might be possible to set 9600 and 38400 BAUD, just
> guessing though as I don't have any TPDD2 hardware to play with.
>
> Overall an amazing amount of work went into this firmware. From what I can
> see, it's all hand coded and has a lot of space saving optimizations in it.
> Out of 4K of available space, there is only 15 bytes of unused space, and
> the author put his name into it (with one byte filled with a 0xFF):
>
> [FFDF][***][] DB'(C) M.FUTAMURA',0xFF;Author
>
>
>
> Darren Clark
>
>
>
>
>
>

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

[Darren Clark]

Spent some time digging through the source of the TPDD2 firmware, adding 
comments, labels, and variable names.


It's documented (as far as I got so far) here: 
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM


Doesn't look like any hidden commands exist in the firmware. This is the 
list from the command table at 0xFFB9:


code    0xF230 Command_FMT00_CreateDirectory
code    0xF4D0            Command_FMT01_FileOpen
code    0xF495            Command_FMT02_FileClose
code    0xF69D            Command_FMT03_FileRead
code    0xF63D            Command_FMT04_File_Write
code    0xF425            Command_FMT05_FileDelete
code    0xF212            Command_FMT06_DiskFormat
code    0xF6F3            Command_FMT07_DriveStatus
code    0xF137            Command_FMT_Invalid
code    0xF75F            Command_FMT23_DriveVersionInfo
code    0xF746            Command_FMT0C_DriveCondition
code    0xF365            Command_FMT0D_FileNameChange
code    0xF801            Command_FMT30_SectorModeReadWrite
code    0xF76B            Command_FMT31_DriveMemorySet
code    0xF78E            Command_FMT32_DriveMemoryGet
code    0xF757            Command_FMT33_SystemVersionInfo
code    0xF7DC            Command_FMT34_ExecuteProgram

Some other interesting tables are at 0xFF67 and 0xFF6D

[FF67]    [80 ]    [    ] Table_SysInfo:    DB    0x80    ;Hard 
sector data port address MSB
[FF68]    [13 ]    [    ]        DB    0x13    ;Hard sector data 
port address LSB

[FF69]    [05 ]    [    ]        DB    0x05    ;Buffer size MSB
[FF6A]    [00 ]    [    ]        DB    0x00    ;Buffer size LSB
[FF6B]    [10 ]    [    ]        DB    0x10    ;CPU type. 0x10 = 
HD6301

[FF6C]    [E1 ]    [    ]        DB    0xE1    ;Model code

[FF6D]    [41 ]    [A   ]    Table_Version:    DB 0x41    
;System Version Number MSB
[FF6E]    [10 ]    [    ]        DB    0x10    ;System Version 
Number LSB

[FF6F]    [01 ]    [    ]        DB    0x01    ;Number of sides
[FF70]    [00 ]    [    ]        DB    0x00    ;Number of tracks MSB
[FF71]    [50 ]    [P   ]        DB    0x50    ;Number of tracks LSB
[FF72]    [05 ]    [    ]        DB    0x05    ;Sector length MSB
[FF73]    [00 ]    [    ]        DB    0x00    ;Sector length LSB
[FF74]    [02 ]    [    ]        DB    0x02    ;Sectors per track
[FF75]    [00 ]    [    ]        DB    0x00 ;Directory Entries MSB
[FF76]    [28 ]    [(   ]        DB    0x28 ;Directory Entries LSB
[FF77]    [00 ]    [    ]        DB    0x00    ;Max files
[FF78]    [E1 ]    [    ]        DB    0xE1    ;Model code

There is also a BAUD rate table at 0xFF85, I see logic for reading the 
dip switch setting from the CPLD at the program initialization. 2 
switches for the BAUD rate and the other 2 for some other mode settings. 
Just a w.a.g. it almost looks like the programming on the CPLD could be 
the same on the TPPD2 as the TPPD1. It might be possible to set 9600 and 
38400 BAUD, just guessing though as I don't have any TPDD2 hardware to 
play with.


Overall an amazing amount of work went into this firmware. From what I 
can see, it's all hand coded and has a lot of space saving optimizations 
in it. Out of 4K of available space, there is only 15 bytes of unused 
space, and the author put his name into it (with one byte filled with a 
0xFF):


[FFDF]    [***]    [    ] DB    '(C) M.FUTAMURA',0xFF    ;Author



Darren Clark

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

[Brian K. White]

No biggie about the binary output.
The script is converting it fine.

I thought not having to output ascii hex pairs and the rest of the line 
formatting, would make the code actually smaller and simpler, and maybe 
fit all inside the internal 128 bytes allowing to read all of the 
external 2k.


I have now also dumped one each of Brother FB-100, KnitKing FDD19, and 
Purple Computing D103, and confirmed that all have the identical rom as 
the TPDD1. Not a single byte different.


It means anyone wanting to repair a drive by swapping parts, is really 
free to do so even if you're trying to preserve every detail, because 
for example there is definitely no different functionality or even id 
numbers or anything different between them.


--
bkw

On 1/24/24 21:40, Darren Clark wrote:

Hello Brian, Steve,

  There is a very limited space in RAM on the TPDD1 to load the 
dumping program into and I needed to make it as small and usable as 
possible, and for me it was easier to dump to a formatted HEX output and 
capture that in a terminal program.


I'll poke around and try updating the up-loadable assembly program to 
dump the data in binary and put in some spots where a start word and 
length byte can be modified this weekend. And you're right, I made up a 
simple RS-232 cable with only RX, TX, and GND when I was working on 
dumping the ROM. I should have used the hardware flow control lines too, 
but thinking back I wasn't sure if the hardware flow control bits for 
the UART in the 6301 would have been set. But looking at the source now, 
they were. Also, at the end of my code I jump into an infinite loop, 
I've not played around with returning to the running firmware, but this 
might be possible too. That could allow for running multiple 'external' 
programs without power cycling the TPPD1.


I'm glad you put the TPPD2 firmware on the web too. I've been poking 
around the firmware that Steve supplied and there are some things that 
weren't making sense and I thought there might have been some dumping 
errors still, but your copy is exactly the same.


But now looking the the stuff that didn't make sense again, it's 
actually a pretty cool implementation of some code compaction tricks.


*Weird thing #1 - the array of CPX statements.*

[FD77]    [26 1D  ]    [&   ]     BNE A_FD96
[FD79]    [DE 99  ]    [    ]    A_FD79:    LDX A_99
[FD7B]    [A6 02  ]    [    ]        LDA A 0x02, X
[FD7D]    [97 89  ]    [    ]    A_FD7D:    STA A A_89
[FD7F]    [C6 B2  ]    [    ]    A_FD7F:    LDA B #0xB2
[FD81]    [F7 40 00   ]    [ @  ]        STA B (CPLD)4000
[FD84]    [71 BF 02   ]    [q   ]        AIM #0xBF, (register)PORT1Data
[FD87]    [39 ]    [9   ]    A_FD87:    RTS
[FD88]    [C6 40  ]    [ @  ]    A_FD88:    LDA B #0x40
*[FD8A]    [8C C6 4B   ]    [  K ]        CPX #0xC64B*
[FD8D]    [9E 81  ]    [    ]        LDS A_81
*[FD8F]    [8C C6 42   ]    [  B ]        CPX #0xC642
[FD92]    [8C C6 41   ]    [  A ]        CPX #0xC641
[FD95]    [8C C6 49   ]    [  I ]        CPX #0xC649
[FD98]    [8C C6 4A   ]    [  J ]        CPX #0xC64A*
[FD9B]    [D7 8E  ]    [    ]        STA B A_8E
[FD9D]    [86 FF  ]    [    ]    A_FD9D:    LDA A #0xFF
[FD9F]    [20 DC  ]    [    ]        BRA A_FD7D

These just didn't make sense at first, and also the branches and jumps 
pointed to the middle of the opcoode (the C6 in the middle). But this is 
just code compaction. What makes this cool is C6 is a load accumulator B 
command that takes 2 bytes. So what is really happening? Since in this 
part of the code we're not concerned with the index register, those 
commands are just superfluous.


What the code is doing is loading acc B with 0x40, 0x4B, 0x42, 0x49, or 
0x4A without a lot of extra branches or jumps between opcodes. Looking 
at line FD77 there is a BNE (branch if not equal) to address FD96, the 
middle of the CPX #0xC649 opcode, which turns out to be C6 49, or LDA B 
#0x49. The next opcode is CPX #0xC64A, which does nothing in this code, 
but hides C6 AA, or LDA B #0x49 (there is other code that jumps to 
that). Seems a little complicated, but the author saved 5 bytes by not 
having 2 byte branch opcodes between each LDA in this section alone. And 
when you only have 4K of space, every byte counts. Especially if you 
want to put your name in the code, you need to do what you can!



*Weird thing #2 - Software interrupts and invalid opcodes.*

[FD73]    [3F ]    [?   ] SWI
[FD74]    [13 ]    [    ]        INVALID

When de-compiling I often look for invalid opcodes to locate issues or 
data tables. What I noted was just before many of the invalid opcodes 
was a SWI, or software interrupt. This is cool because the software 
interrupt jumps to a block of code that gets the SWI address out of of 
the stack and gets the next byte after that address, which is the 
invalid or nonsensical opcodes after the SWI. I still need to dig deeper 
into what these are all doing, 

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

[Darren Clark]

Hello Brian, Steve,

 There is a very limited space in RAM on the TPDD1 to load the 
dumping program into and I needed to make it as small and usable as 
possible, and for me it was easier to dump to a formatted HEX output and 
capture that in a terminal program.


I'll poke around and try updating the up-loadable assembly program to 
dump the data in binary and put in some spots where a start word and 
length byte can be modified this weekend. And you're right, I made up a 
simple RS-232 cable with only RX, TX, and GND when I was working on 
dumping the ROM. I should have used the hardware flow control lines too, 
but thinking back I wasn't sure if the hardware flow control bits for 
the UART in the 6301 would have been set. But looking at the source now, 
they were. Also, at the end of my code I jump into an infinite loop, 
I've not played around with returning to the running firmware, but this 
might be possible too. That could allow for running multiple 'external' 
programs without power cycling the TPPD1.


I'm glad you put the TPPD2 firmware on the web too. I've been poking 
around the firmware that Steve supplied and there are some things that 
weren't making sense and I thought there might have been some dumping 
errors still, but your copy is exactly the same.


But now looking the the stuff that didn't make sense again, it's 
actually a pretty cool implementation of some code compaction tricks.


*Weird thing #1 - the array of CPX statements.*

[FD77]    [26 1D  ]    [&   ]     BNE A_FD96
[FD79]    [DE 99  ]    [    ]    A_FD79:    LDX A_99
[FD7B]    [A6 02  ]    [    ]        LDA A 0x02, X
[FD7D]    [97 89  ]    [    ]    A_FD7D:    STA A A_89
[FD7F]    [C6 B2  ]    [    ]    A_FD7F:    LDA B #0xB2
[FD81]    [F7 40 00   ]    [ @  ]        STA B (CPLD)4000
[FD84]    [71 BF 02   ]    [q   ]        AIM #0xBF, (register)PORT1Data
[FD87]    [39 ]    [9   ]    A_FD87:    RTS
[FD88]    [C6 40  ]    [ @  ]    A_FD88:    LDA B #0x40
*[FD8A]    [8C C6 4B   ]    [  K ]        CPX #0xC64B*
[FD8D]    [9E 81  ]    [    ]        LDS A_81
*[FD8F]    [8C C6 42   ]    [  B ]        CPX #0xC642
[FD92]    [8C C6 41   ]    [  A ]        CPX #0xC641
[FD95]    [8C C6 49   ]    [  I ]        CPX #0xC649
[FD98]    [8C C6 4A   ]    [  J ]        CPX #0xC64A*
[FD9B]    [D7 8E  ]    [    ]        STA B A_8E
[FD9D]    [86 FF  ]    [    ]    A_FD9D:    LDA A #0xFF
[FD9F]    [20 DC  ]    [    ]        BRA A_FD7D

These just didn't make sense at first, and also the branches and jumps 
pointed to the middle of the opcoode (the C6 in the middle). But this is 
just code compaction. What makes this cool is C6 is a load accumulator B 
command that takes 2 bytes. So what is really happening? Since in this 
part of the code we're not concerned with the index register, those 
commands are just superfluous.


What the code is doing is loading acc B with 0x40, 0x4B, 0x42, 0x49, or 
0x4A without a lot of extra branches or jumps between opcodes. Looking 
at line FD77 there is a BNE (branch if not equal) to address FD96, the 
middle of the CPX #0xC649 opcode, which turns out to be C6 49, or LDA B 
#0x49. The next opcode is CPX #0xC64A, which does nothing in this code, 
but hides C6 AA, or LDA B #0x49 (there is other code that jumps to 
that). Seems a little complicated, but the author saved 5 bytes by not 
having 2 byte branch opcodes between each LDA in this section alone. And 
when you only have 4K of space, every byte counts. Especially if you 
want to put your name in the code, you need to do what you can!



*Weird thing #2 - Software interrupts and invalid opcodes.*

[FD73]    [3F ]    [?   ] SWI
[FD74]    [13 ]    [    ]        INVALID

When de-compiling I often look for invalid opcodes to locate issues or 
data tables. What I noted was just before many of the invalid opcodes 
was a SWI, or software interrupt. This is cool because the software 
interrupt jumps to a block of code that gets the SWI address out of of 
the stack and gets the next byte after that address, which is the 
invalid or nonsensical opcodes after the SWI. I still need to dig deeper 
into what these are all doing, but it's a neat way to pass a parameter 
to a function without using a register.


*Weird thing #3 - Other standalone invalid opcodes.
*

The 6301 traps invalid opcodes, and I see that there are many standalone 
invalid opcodes that make no sense. But when using the TRAP, the invalid 
opcodes become a 1 byte call to a subroutine instead of a 3 byte call. 
Another form of code compaction.



So thank you Steve and Brian for helping out with this! There are some 
really cool things to discover in these ancient devices.



This firmware is completely different form the TPPD1, and a lot more 
complicated. It'll take a while to decipher and figure out the little 
tricks that were used to save space, and also decode the functionality. 
As i figure out more I'll update my GitHub and this 

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

[Brian K. White]

I've added a rom_dump command to pdd.sh
https://github.com/bkw777/pdd.sh


You just say "rom_dump filename" and it dumps the rom to filename as binary.

Accepts rom_dump or dump_rom equally.

If you don't give a filename, it just prints the hex to the screen.

$ pdd rom_dump pdd1_rom.bin

Works on both TPDD1 and TPDD2, and detects the type of drive automatically.

For TPDD1, it uses the machine code you (Darren) provided at 
https://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes

Which is AWESOME thank you for writing that!

I didn't have to add any special character delays, it's both writing the 
S-records and reading the results as fast as the tty will go. though 
rts/cts is in effect, so maybe with a 3-wire cable some delay would need 
to be injected. I haven't tried without flow control yet.


I'm currently parsing the returned ascii hex dump to generate the 
binary, but could you possibly make a version that just sends the raw 
binary bytes? Even better one that can take parameters or even just have 
a few bytes edited on the fly to dump an arbitrary address & length?


For TPDD2 it's just using the normal mem_read command.

ROM images collected this way for both TPDD1 and 2 are both at
http://tandy.wiki/TPDD#Documentation
in case you want to compare them.

Now I'll dump the FB-100, KnitKing FDD19, and Purple Computing D103 just 
to see if they're all identical.



Session capture...


With a TPDD1 plugged in, letting pdd.sh figure out the model itself


bkw@fw:~/src/pdd.sh$ pdd
PDD(-:6.2,F)> rom_dump pdd1_rom.bin

ROM DUMP for TPDD1 / FB-100
https://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes

This process requires the drive to be configured to receive S-records.
Do the following now before proceeding:

1 - Turn the drive power OFF.
2 - Set all 4 dip switches to ON.
(or close all 4 solder-jumper pads with solder)
3 - Turn the drive power ON.

If the dip switches were already set from a previous attempt,
still cycle the power switch once right now.
If the low battery light is flashing, cycle the power.

Ready to proceed (y/N)? y

Saving to file: pdd1_rom.bin
File Exists: Are you sure? (y/N) y
Switching serial port to 9600 baud.
/dev/ttyUSB0 is open
speed: 9600

Sending S-records to the drive cpu...

S10E8515CEF000C608860DBD854F8621
S11385200ABD854F3C328100271EBD855A32BD8568
S11385305A863ABD854FA600BD855A8620BD854F13
S1138540085AC10027D220EE8658BD854F20FE3739
S1138550D611C42027FA971936BD12
S1138560856532840F810A2B028B078B30BD854FC2
S104857039CD
S901FE

F000:0F 8E 87 FF 86 FC 97 00
F008:86 34 97 02 86 FF 97 04
[...]
FFF0:F0 00 F0 00 F0 00 F0 00
FFF8:F0 00 F0 00 F0 00 F0 00

Restoring serial port to 19200 baud.
/dev/ttyUSB0 is open
speed: 19200

Wrote 4096 bytes to pdd1_rom.bin

Return the drive to normal configuration.
1 - Turn the drive power OFF.
2 - Set all 4 dip switches to OFF.
3 - Turn the drive power ON.

PDD(opr:6.2,F)> q
bkw@fw:~/src/pdd.sh$




With a TPDD2 plugged in, letting pdd.sh figure out the model itself


bkw@fw:~/src/pdd.sh$ ./pdd
PDD(-:6.2,F)> rom_dump pdd2_rom.bin
Reading cpu memory, addr:0xF000  length:0x1000
to file: "pdd2_rom.bin"
[] 100% (4096/4096 bytes) 


PDD(pdd2[0]:6.2,F)> q
bkw@fw:~/src/pdd.sh$


Looking at the results


bkw@fw:~/src/pdd.sh$ ls -l *.bin
-rw-rw-r-- 1 bkw bkw 4096 Jan 24 19:23 pdd1_rom.bin
-rw-rw-r-- 1 bkw bkw 4096 Jan 24 19:24 pdd2_rom.bin
bkw@fw:~/src/pdd.sh$


bkw@fw:~/src/pdd.sh$ xxd -g 1 -u pdd1_rom.bin
: 0F 8E 87 FF 86 FC 97 00 86 34 97 02 86 FF 97 04  .4..
0010: 97 05 86 A0 B7 40 00 F6 40 01 C4 F0 37 54 54 54  .@..@...7TTT
[...]
0fe0: F3 5B 44 F3 C8 4D F4 00 00 FF 00 FF 00 FF F0 00  .[D..M..
0ff0: F0 00 F0 00 F0 00 F0 00 F0 00 F0 00 F0 00 F0 00  
bkw@fw:~/src/pdd.sh$


bkw@fw:~/src/pdd.sh$ xxd -g 1 -u pdd2_rom.bin
: 8E 87 FF CC 0C 10 DD 02 CC FC 11 DD 00 CC FF C7  
0010: DD 04 B6 40 00 8A 80 B7 40 00 86 B2 B7 40 00 CC  ...@@@..
[...]
0fe0: 43 29 20 4D 2E 46 55 54 41 4D 55 52 41 FF F7 16  C) M.FUTAMURA...
0ff0: FF 5E FF 2A FF 5E FF 5E FF 5E FF 13 F0 00 F0 00  .^.*.^.^.^..
bkw@fw:~/src/pdd.sh$


--
bkw



On 1/23/24 22:01, Darren Clark wrote:

Awesome!

Looks a lot better, I just ran it through my decompiler and posted the 
first pass here: 
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM


There are still some invalid opcodes floating around, I need to dig 
deeper and see what is going on there. I also see several lookup tables 
at the end, I'll look into those and document them.


It looks like the calls to the CPLD/gate array are the same, it's only 
using address 0x4000 to 0x4003 for those (same as TPDD1). Other than 

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

[Darren Clark]

Awesome!

Looks a lot better, I just ran it through my decompiler and posted the 
first pass here: 
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM


There are still some invalid opcodes floating around, I need to dig 
deeper and see what is going on there. I also see several lookup tables 
at the end, I'll look into those and document them.


It looks like the calls to the CPLD/gate array are the same, it's only 
using address 0x4000 to 0x4003 for those (same as TPDD1). Other than 
that the code base is almost completely different from the TPDD1 which 
is interesting since the hardware is almost the same.


I might write up a 6301 emulator and try running the code to test some 
serial I/O on it. I think I can fake most of the other IO since it goes 
through the CPLD.


Thank you very much for dumping the ROM, I'm wondering what undocumented 
secrets we'll find in there!


Darren Clark




On 1/23/24 21:27, Stephen Adolph wrote:

128 more bytes ;)

On Tue, Jan 23, 2024 at 3:28 PM Stephen Adolph  
wrote:


It was a first pass attempt.  I captured it as 128 blocks of 32
bytes.  Was it

On Tuesday, January 23, 2024, Darren Clark 
wrote:

Hello Steve,

 Looks awesome so far! I've started to manually decompile
it and some things are not making sense.

The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the
stack pointer at address 0x87FF, the top of the external RAM.
This is good.

Normally there is some other housekeeping at the entry point
0xF000, something like disabling interrupts so the start of
the program can initialize the CPU without interruptions. With
the TPDD1 the SEI instruction was at 0xF000, then the stack
pointer is set at 0x87FF. This may be fine though, I need to
do a deeper dive and see if the address alignments all work out.

What I do notice is missing is the last 128 bytes of the ROM
image, 0xFF80 to 0x.  0xFFEE to 0x is the vector table
for interrupts, and resets. The ROM image should be 4096 bytes
in total.

When I get home this evening I'll run the binary through my
decomplier and check the address alignments, that should prove
whether the start byte is correct or not too.

Either way, we're 95% there. Thanks for working on this!

Darren Clark


On 1/22/24 23:21, Stephen Adolph wrote:

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. 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):
;--
;-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    

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

[Stephen Adolph]

128 more bytes ;)

On Tue, Jan 23, 2024 at 3:28 PM Stephen Adolph  wrote:

> It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.
> Was it
>
> On Tuesday, January 23, 2024, Darren Clark  wrote:
>
>> Hello Steve,
>>
>>  Looks awesome so far! I've started to manually decompile it and some
>> things are not making sense.
>>
>> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
>> pointer at address 0x87FF, the top of the external RAM. This is good.
>>
>> Normally there is some other housekeeping at the entry point 0xF000,
>> something like disabling interrupts so the start of the program can
>> initialize the CPU without interruptions. With the TPDD1 the SEI
>> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
>> may be fine though, I need to do a deeper dive and see if the address
>> alignments all work out.
>>
>> What I do notice is missing is the last 128 bytes of the ROM image,
>> 0xFF80 to 0x.  0xFFEE to 0x is the vector table for interrupts, and
>> resets. The ROM image should be 4096 bytes in total.
>>
>> When I get home this evening I'll run the binary through my decomplier
>> and check the address alignments, that should prove whether the start byte
>> is correct or not too.
>>
>> Either way, we're 95% there. Thanks for working on this!
>>
>> Darren Clark
>>
>>
>> On 1/22/24 23:21, Stephen Adolph wrote:
>>
>> these look like 6301 opcodes.  Maybe this worked.
>> take a look please when you can. thanks. 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

[Stephen Adolph]

It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.  Was
it

On Tuesday, January 23, 2024, Darren Clark  wrote:

> Hello Steve,
>
>  Looks awesome so far! I've started to manually decompile it and some
> things are not making sense.
>
> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
> pointer at address 0x87FF, the top of the external RAM. This is good.
>
> Normally there is some other housekeeping at the entry point 0xF000,
> something like disabling interrupts so the start of the program can
> initialize the CPU without interruptions. With the TPDD1 the SEI
> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
> may be fine though, I need to do a deeper dive and see if the address
> alignments all work out.
>
> What I do notice is missing is the last 128 bytes of the ROM image, 0xFF80
> to 0x.  0xFFEE to 0x is the vector table for interrupts, and
> resets. The ROM image should be 4096 bytes in total.
>
> When I get home this evening I'll run the binary through my decomplier and
> check the address alignments, that should prove whether the start byte is
> correct or not too.
>
> Either way, we're 95% there. Thanks for working on this!
>
> Darren Clark
>
>
> On 1/22/24 23:21, Stephen Adolph wrote:
>
> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. 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

[Stephen Adolph]

It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.
I'll check that I didn't cut off the file by accident.


On Tuesday, January 23, 2024, Darren Clark  wrote:

> Hello Steve,
>
>  Looks awesome so far! I've started to manually decompile it and some
> things are not making sense.
>
> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
> pointer at address 0x87FF, the top of the external RAM. This is good.
>
> Normally there is some other housekeeping at the entry point 0xF000,
> something like disabling interrupts so the start of the program can
> initialize the CPU without interruptions. With the TPDD1 the SEI
> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
> may be fine though, I need to do a deeper dive and see if the address
> alignments all work out.
>
> What I do notice is missing is the last 128 bytes of the ROM image, 0xFF80
> to 0x.  0xFFEE to 0x is the vector table for interrupts, and
> resets. The ROM image should be 4096 bytes in total.
>
> When I get home this evening I'll run the binary through my decomplier and
> check the address alignments, that should prove whether the start byte is
> correct or not too.
>
> Either way, we're 95% there. Thanks for working on this!
>
> Darren Clark
>
>
> On 1/22/24 23:21, Stephen Adolph wrote:
>
> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. 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]

Interesting, going down the rabbit hole Futamura is referenced in 
this patent https://uspto.report/patent/grant/6202001 for an embroidery 
data creating device for Brother. If I remember correctly the TPDD was 
originally sourced or is the same as a drive used in a Brother 
embroiderymachine.




On 1/22/24 23:22, Stephen Adolph wrote:

Oh yeah and we know who wrote it:
M.FUTAMURA

On Mon, Jan 22, 2024 at 11:21 PM Stephen Adolph  
wrote:


these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. 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):
;--
;-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 - firmware dumping and reverse engineering

[Darren Clark]

Hello Steve,

 I RDP's into my home system and ran the binary through my 
decompiler. It looks like there might be an issue with how the ROM was 
pulled. It's missing a byte every 32 bytes, so I'm getting a lot of 
invalid opcodes. That could also explain the missing 128 bytes at the 
end too.


Would you mind sharing the program you used to dump the firmware so I 
can have a quick look through?



Darren Clark


On 1/22/24 23:21, Stephen Adolph wrote:

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. 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):
;--
;-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 - firmware dumping and reverse engineering

[Darren Clark]

Hello Steve,

 Looks awesome so far! I've started to manually decompile it and 
some things are not making sense.


The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack 
pointer at address 0x87FF, the top of the external RAM. This is good.


Normally there is some other housekeeping at the entry point 0xF000, 
something like disabling interrupts so the start of the program can 
initialize the CPU without interruptions. With the TPDD1 the SEI 
instruction was at 0xF000, then the stack pointer is set at 0x87FF. This 
may be fine though, I need to do a deeper dive and see if the address 
alignments all work out.


What I do notice is missing is the last 128 bytes of the ROM image, 
0xFF80 to 0x.  0xFFEE to 0x is the vector table for interrupts, 
and resets. The ROM image should be 4096 bytes in total.


When I get home this evening I'll run the binary through my decomplier 
and check the address alignments, that should prove whether the start 
byte is correct or not too.


Either way, we're 95% there. Thanks for working on this!

Darren Clark


On 1/22/24 23:21, Stephen Adolph wrote:

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. 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):
;--
;-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 - firmware dumping and reverse engineering

[Stephen Adolph]

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. 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

[Stephen Adolph]

Oh yeah and we know who wrote it:
M.FUTAMURA

On Mon, Jan 22, 2024 at 11:21 PM Stephen Adolph 
wrote:

> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. 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

[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
;--