subject:"\[M100\] Tandy Portable Disk Drive 2"

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

2024-01-28 Thread 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

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

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

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

2024-01-28 Thread 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

2024-01-28 Thread 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

2024-01-28 Thread 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

2024-01-28 Thread 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

2024-01-27 Thread 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

2024-01-24 Thread 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

2024-01-24 Thread 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

2024-01-24 Thread 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


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

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 service manual PDF now available.

2024-01-23 Thread Brian White

I had that thing about request format 0x47  backwards. Tpdd1 ignores 0x47,
tpdd2 responds to it, which makes more sense, since it's just like several
other commands on tpdd2. Doesn't matter to anyone but just for the record
to correct saying it backwards before.

bkw

On Wed, Jan 10, 2024, 11:49 AM Brian K. White  wrote:

> Curiouser, I added support for request 0x47, including the detail that
> it only works if dl2 is in strict tpdd1 mode.
> In default or explicit tpdd2 mode, it ignores the command the same as a
> real TPDD2 does.
>
> When I run with strict tpdd1 emulation, PAKDOS sends the 0x47 status
> command once per directory list. As expected.
>
> When I run without that, which defaults to enabling TPDD2 features, and
> ignores 0x47 as unrecognized, PAKDOS tries 0x47, only waits a few ms for
> the response and then sends a normal 0x07.
>
> So, it's not the case that James just mistakenly thought that 0x47 was
> the status command. He sends it, and then only if that fails, then does
> 0x07.
> So it was even more deliberate than it already looked. Don't ask me why!
>
> --
> bkw
>
> On 1/10/24 10:49, Brian K. White wrote:
> >> The TPDD2 service manual in all of its glory...
> >
> > While going through starting to update dl2 with all this new info, I
> > also tried a new (old) DOS I recently found called PAKDOS by James Yi.
> > http://tandy.wiki/TPDD_client:PAKDOS
> >
> > And it tries to use a command 0x47 every time it does a directory
> > listing.
> >
> > Well that's a new one. Never saw request format 0x47 anywhere before.
> >
> > I figured out what it is and it's weird.
> >
> > PAKDOS apparently expects no-response might be possible since it
> > doesn't care that dl2 ignores it, and the directory listing works with
> > no hint of any problem on the portable side.
> >
> > The command is given with no parameters or payload data, and wrapped
> > in a valid Operation-mode packet, IE, the packet has all components
> > and is consistent.
> > format byte is 0x47
> > there are no params or data, and the len byte is 0x00, so that fits,
> > and there is a checksum byte 0xB8 after that, which is correct.
> > So, it's not just random data.
> >
> > The first guess maybe it's a synonym for drive_status, because:
> > * 0x07 is drive status
> > * drive status has a payload length of 0
> > * for TPDD2, some commands do have an alternate version that is the
> > normal format code plus 0x40 to make the command operate on bank1
> > instead of bank0.
> >
> > all checks out and adds up
> >
> > But a real TPDD2 does not respond to this command.
> >
> > ... BUT a TPDD1 DOES, and it indeed does the drive status command.
> > It doesn't just respond with a valid standard 0x12 return format for
> > "ok" but for instance if the disk is ejected it says so.
> >
> > Whatever! Easy enough to handle, just completely unexpected that a
> > tpdd1 would respond to a 0x4n request and a tpdd2 does not!
> >
>
>

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

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

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

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


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


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 service manual PDF now available.

2024-01-23 Thread Greg Swallow

Thanks Bert,

Already got the belts replaced, but good to be ready for working on my two 
TPDD2 in the ffuture.

GregS <><
Sent from my iPad

> On Jan 8, 2024, at 10:23 AM, bir...@soigeneris.com wrote:
> 
> 
> The TPDD2 service manual in all of its glory...
>  
> https://archive.org/details/tpdd-2-service-manual
>  
> Jeff Birt

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

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

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 service manual PDF now available.

2024-01-10 Thread Brian K. White

Curiouser, I added support for request 0x47, including the detail that 
it only works if dl2 is in strict tpdd1 mode.
In default or explicit tpdd2 mode, it ignores the command the same as a 
real TPDD2 does.


When I run with strict tpdd1 emulation, PAKDOS sends the 0x47 status 
command once per directory list. As expected.


When I run without that, which defaults to enabling TPDD2 features, and 
ignores 0x47 as unrecognized, PAKDOS tries 0x47, only waits a few ms for 
the response and then sends a normal 0x07.


So, it's not the case that James just mistakenly thought that 0x47 was 
the status command. He sends it, and then only if that fails, then does 
0x07.

So it was even more deliberate than it already looked. Don't ask me why!

--
bkw

On 1/10/24 10:49, Brian K. White wrote:

The TPDD2 service manual in all of its glory...


While going through starting to update dl2 with all this new info, I 
also tried a new (old) DOS I recently found called PAKDOS by James Yi.

http://tandy.wiki/TPDD_client:PAKDOS

And it tries to use a command 0x47 every time it does a directory 
listing.


Well that's a new one. Never saw request format 0x47 anywhere before.

I figured out what it is and it's weird.

PAKDOS apparently expects no-response might be possible since it 
doesn't care that dl2 ignores it, and the directory listing works with 
no hint of any problem on the portable side.


The command is given with no parameters or payload data, and wrapped 
in a valid Operation-mode packet, IE, the packet has all components 
and is consistent.

format byte is 0x47
there are no params or data, and the len byte is 0x00, so that fits,
and there is a checksum byte 0xB8 after that, which is correct.
So, it's not just random data.

The first guess maybe it's a synonym for drive_status, because:
* 0x07 is drive status
* drive status has a payload length of 0
* for TPDD2, some commands do have an alternate version that is the 
normal format code plus 0x40 to make the command operate on bank1 
instead of bank0.


all checks out and adds up

But a real TPDD2 does not respond to this command.

... BUT a TPDD1 DOES, and it indeed does the drive status command.
It doesn't just respond with a valid standard 0x12 return format for 
"ok" but for instance if the disk is ejected it says so.


Whatever! Easy enough to handle, just completely unexpected that a 
tpdd1 would respond to a 0x4n request and a tpdd2 does not!

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

2024-01-10 Thread Brian K. White


The TPDD2 service manual in all of its glory...


While going through starting to update dl2 with all this new info, I 
also tried a new (old) DOS I recently found called PAKDOS by James Yi.

http://tandy.wiki/TPDD_client:PAKDOS

And it tries to use a command 0x47 every time it does a directory listing.

Well that's a new one. Never saw request format 0x47 anywhere before.

I figured out what it is and it's weird.

PAKDOS apparently expects no-response might be possible since it doesn't 
care that dl2 ignores it, and the directory listing works with no hint 
of any problem on the portable side.


The command is given with no parameters or payload data, and wrapped in 
a valid Operation-mode packet, IE, the packet has all components and is 
consistent.

format byte is 0x47
there are no params or data, and the len byte is 0x00, so that fits,
and there is a checksum byte 0xB8 after that, which is correct.
So, it's not just random data.

The first guess maybe it's a synonym for drive_status, because:
* 0x07 is drive status
* drive status has a payload length of 0
* for TPDD2, some commands do have an alternate version that is the 
normal format code plus 0x40 to make the command operate on bank1 
instead of bank0.


all checks out and adds up

But a real TPDD2 does not respond to this command.

... BUT a TPDD1 DOES, and it indeed does the drive status command.
It doesn't just respond with a valid standard 0x12 return format for 
"ok" but for instance if the disk is ejected it says so.


Whatever! Easy enough to handle, just completely unexpected that a tpdd1 
would respond to a 0x4n request and a tpdd2 does not!


--
bkw

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

2024-01-09 Thread 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

2024-01-09 Thread 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

2024-01-09 Thread Darren Clark


TPDD2 firmware dumping - breaking this into a new thread.

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


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


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


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


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

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



Darren Clark


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

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

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

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

2024-01-09 Thread Brian K. White


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

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

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


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

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

Doesn't exist on TPDD 1 / 2.

-- John.


Oh very nice, thank you.
--
bkw

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

2024-01-09 Thread John R. Hogerhuis

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

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

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

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

Doesn't exist on TPDD 1 / 2.

-- John.

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

2024-01-09 Thread Brian K. White


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



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


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

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


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

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

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

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

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

)

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


--
bkw

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

2024-01-09 Thread Brian K. White


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


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




Obviously I hadn't noticed page 72 yet

--

bkw

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

2024-01-08 Thread Brian K. White

On 1/8/24 12:22, bir...@soigeneris.com wrote:

The TPDD2 service manual in all of its glory...

https://archive.org/details/tpdd-2-service-manual

Jeff Birt

Oh man awesome. A real reference for the error codes and other software
bits...

There is an actual explaination of "mystery command 0x23" !!
https://github.com/bkw777/pdd.sh/blob/6f75515c1c5b8aa74c701c0cf61069c3cd126de2/pdd.sh#L1043

There is an "execute program" command to run arbitrary machine code!
Well we already saw that in tpdd1 right in the bootstrap directions, but
that uses dip switch setting to put the drive into a special mode, while
this is just a normal function like any other.

Already cleared up a few mysteries. A while back I really dug in to
stuff like the TPDD2 sector modes to add to the work KenP and KurtM and
others already did. I was very satisfied to be able to figure some stuff
out that were still unknown, but I was still left with some real mysteries.

What I call "cache_load" pg 96 in the service manual,
is for moving data between the disk media and the drives ram.
(here I say "load" to mean media-to-ram
and unload to mean ram-to-media)
I had:
# 5-byte request data
# 00|02 action 0=load 2=unload
# 00unknown
# 00-4F track
# 00unknown
# 00-01 sector

Now I know it is:
# 5-byte request data
# 00-02 action 0=load 1=unload 2=unload+verify
# 00track MSB (always 00)
# 00-4F track LSB
# 00side (always 00)
# 00-01 sector

Well, in the end, it's gratifying to see it doesn't change anything,
that although we didn't know what the the two 00 bytes really were,
in the end they never would be any other value and they were being
handled correctly.

Another example, reading data from the drives ram to the client.
(pg 89)
I had:
# 4-byte request data
# 00 area 0=data 1=meta
# -04C0 offset
# 00-FC length

I assumed it was both incomplete and probably wrong for the "meta" mode.

I called the first byte "mode" because it seemed to be some kind of mode
switch where it did two different things depending on that byte,

and now it was in fact called mode.
And I just assumed there might be other modes but nope, just those two.

And what I called "meta" really just means reading from the drives own
working memory vs the disk cache. So although the guesswork label isn't
a good fit, the usage was still right.

It did seem like something like that.
I had assumed that in mode 1 that the 2 bytes in the address or offset
field probably had some other meaning in "meta" mode, but no, it still
means address, just now it's from the cpus working space instead of the
sector buffer.

The "meta" mode I just got from seeing that the backup program uses this
mode to read 4 bytes from a certain address, but using pdd.sh to poke at
the drive and see what it does, I noticed that you can read as many
bytes as you want from any address you want, and get back unknown random
seeming data.

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

Anyway it will be very satisfying to update everything to fill in these
little missing mystery bytes in pdd.sh, dl2, & PDDuino.

Thank you for getting this scanned. Nice clean job to, thanks.

--
bkw

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

2024-01-08 Thread birt_j

I rendered it at 300DPI and OCRd it. When you try to uber compress the file the 
schematics start to become unreadable. 

 

Jeff

 

From: M100  On Behalf Of John R. Hogerhuis
Sent: Monday, January 8, 2024 1:24 PM
To: m...@bitchin100.com
Subject: Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now 
available.

 

Birt,

 

would it be a big deal to render this to somewhat lower fidelity? Or split into 
multiple files? I'm trying to send it to my kindle scribe through Amazon's 
service.

It's 80Mb... gmail's largest attachment size is 25mb. Supposedly I could send 
it as a zipped attachment but that only brings it down to 60mb.

There's a dedicated Send To Kindle windows app but its max is 50mb. And It 
won't accept a zipped file.

 

So one 50mb file would work. Or multiple parts < 25mb each would work

 

If it is a big deal, no problem, I will look for a way to split it up or resize 
it myself.

 

-- John.

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

Perfect, thanks Steve. Now I can curl up in bed with the TPDD2 manual on my
Kindle Scribe.

Hosted at

https://bitchin100.com/files/hardware/TPDD2_Service_Manual.pdf

-- John.

On Mon, Jan 8, 2024 at 11:48 AM Steve Baker  wrote:

> Greetings! Thanks for the opportunity to send this along — hopefully it’ll
> work!
>
> Cheers and thanks,
> Steve
>
>

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

If you email it to me jho...@pobox.com I can upload it to a bitchin100 file
area and I'll share the link.

-- John.

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

2024-01-08 Thread Steve Baker

Hello folks — I was able to compress the PDF to about 15mb at 144 psi, medium 
quality. The compressed file looks good and the detailed bits are quite 
legible. Might there be a place where I could upload or send the file?

Cheers,
SB


--
Greetings from Steve Baker (he/him/his)
“Gravity brings me down…”




> On Jan 8, 2024, at 2:24 PM, John R. Hogerhuis  wrote:
> 
> Birt,
> 
> would it be a big deal to render this to somewhat lower fidelity? Or split 
> into multiple files? I'm trying to send it to my kindle scribe through 
> Amazon's service.
> 
> It's 80Mb... gmail's largest attachment size is 25mb. Supposedly I could send 
> it as a zipped attachment but that only brings it down to 60mb.
> 
> There's a dedicated Send To Kindle windows app but its max is 50mb. And It 
> won't accept a zipped file.
> 
> So one 50mb file would work. Or multiple parts < 25mb each would work
> 
> If it is a big deal, no problem, I will look for a way to split it up or 
> resize it myself.
> 
> -- John.
>

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

2024-01-08 Thread Walt Perko

Hi, 

 

Try MS WORD to split it into two parts.  

 

 

 

 

 

==
C U L8r,  °|°  Walt Perko  °|°"Kids ... teach them the good stuff, and 
they still learn the bad stuff on their own."

 <http://www.r2pv1.com/> http://www.R2Pv1.com/  RoboGuts™ Intelligent content 
for 3D printing making S.T.E.A.M. education better, easier and more affordable  

 

Experiments to learn how to use various Electronic Components, Structured 
Computer Programming, Phonemes for Speech  in any language, and Art.


 "The World Needs a New Economic Model"
==



Sent from the Cyber7 

 

 

From: M100 On Behalf Of John R. Hogerhuis
Sent: Monday, January 8, 2024 11:24 AM
To: m...@bitchin100.com
Subject: Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now 
available.

 

Birt,

 

would it be a big deal to render this to somewhat lower fidelity? Or split into 
multiple files? I'm trying to send it to my kindle scribe through Amazon's 
service.

It's 80Mb... gmail's largest attachment size is 25mb. Supposedly I could send 
it as a zipped attachment but that only brings it down to 60mb.

There's a dedicated Send To Kindle windows app but its max is 50mb. And It 
won't accept a zipped file.

 

So one 50mb file would work. Or multiple parts < 25mb each would work

 

If it is a big deal, no problem, I will look for a way to split it up or resize 
it myself.

 

-- John.

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

Birt,

would it be a big deal to render this to somewhat lower fidelity? Or split
into multiple files? I'm trying to send it to my kindle scribe through
Amazon's service.

It's 80Mb... gmail's largest attachment size is 25mb. Supposedly I could
send it as a zipped attachment but that only brings it down to 60mb.

There's a dedicated Send To Kindle windows app but its max is 50mb. And It
won't accept a zipped file.

So one 50mb file would work. Or multiple parts < 25mb each would work

If it is a big deal, no problem, I will look for a way to split it up or
resize it myself.

-- John.

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

2024-01-08 Thread Tim Russell

Thanks, I figured it HAD to be a typo, otherwise it would be rather ironic
for it to have more than 5x as much RAM as the standard 100 could support.

On Mon, Jan 8, 2024, 12:05 Darren Clark  wrote:

> I think the 128K or RAM is a typo and should only be 128 bytes. Looking at
> page 97 (set the data to drive's memory) and page 89 (get the data from the
> drive's memory), there is only enough room to request 125 bytes at a time.
>
> Also from my disassembly of the TPDD1 ROM and the very similar
> architecture (same CPU and RAM and CPLD), there is only 128 bytes of
> scratch ram.
>

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

2024-01-08 Thread Darren Clark

I think the 128K or RAM is a typo and should only be 128 bytes. Looking 
at page 97 (set the data to drive's memory) and page 89 (get the data 
from the drive's memory), there is only enough room to request 125 bytes 
at a time.


Also from my disassembly of the TPDD1 ROM and the very similar 
architecture (same CPU and RAM and CPLD), there is only 128 bytes of 
scratch ram.



Darren Clark



On 1/8/24 13:55, Tim Russell wrote:
Geez, up-front the manual said 128K of RAM!  I was thinking one could 
reprogram the ROM to make it a ram disk for a sec there, but the parts 
list only shows 2K of SRAM unless I missed something?


Anyway, thanks much for the efforts, all!  Great stuff.

Tim


On Mon, Jan 8, 2024, 10:23  wrote:

The TPDD2 service manual in all of its glory...

https://archive.org/details/tpdd-2-service-manual

Jeff Birt

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

In LaddieAlpha source, I have the following mystery commands:

14, // $0E
35, // $23
48, // $30
49 // $31

14 /$0E remains a mystery.
23 is Get Version Number...solved!
48 is Read/Write Data in Sector Mode... I guess that was already solved it
just didn't matter to Laddie
49 is Read/Write Data to sector or drive RAM

So very nice stuff to have.
I guess with 49 writing to Drive RAM, TPDD2 could be a coprocessor with
128K of RAM? Maybe LaddieAlpha could get a 6301 emulation?

Also the Error Code table is very nice.

-- John.

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

2024-01-08 Thread Tim Russell

Geez, up-front the manual said 128K of RAM!  I was thinking one could
reprogram the ROM to make it a ram disk for a sec there, but the parts list
only shows 2K of SRAM unless I missed something?

Anyway, thanks much for the efforts, all!  Great stuff.

Tim

On Mon, Jan 8, 2024, 10:23  wrote:

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

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

2024-01-08 Thread Kurt McCullum

Thanks Jeff,

A lot of this looks similar to the TPDD1 with the exception of the sector 
protocols. Quite a few years ago I wrote some software to copy sectors. It 
would have been nice to have had this at the time. Great to finally have it.

Kurt

On Mon, Jan 8, 2024, at 9:22 AM, bir...@soigeneris.com wrote:
> The TPDD2 service manual in all of its glory...
>  
> https://archive.org/details/tpdd-2-service-manual
>  
> Jeff Birt

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

2024-01-08 Thread Ken St. Cyr

Wonderful quality scans – thanks Jeff!

//Ken S

From: M100  on behalf of 
bir...@soigeneris.com 
Date: Monday, January 8, 2024 at 12:23 PM
To: m...@bitchin100.com 
Subject: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.
The TPDD2 service manual in all of its glory...

https://archive.org/details/tpdd-2-service-manual

Jeff Birt

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

2024-01-08 Thread birt_j

The TPDD2 service manual in all of its glory...

 

https://archive.org/details/tpdd-2-service-manual

 

Jeff Birt

Re: [M100] Tandy Portable Disk Drive 2, but really 1

2022-11-23 Thread Gregory McGill

I'm starting to make my own :)  just need to make them .. i have put some
in stock in the meantime

had to figure out how to do it with a greaseweazel usb drive interface
..lots of fun

Greg

On Tue, Nov 22, 2022 at 7:58 PM Brian K. White  wrote:

> Yes well, yes, TPDD1 is almost entirely different. There is some
> overlap, some backwards compatibility from TPDD2 to TPDD1, but you need
> to be using the TPDD1 version of any and all directions.
>
> If Greg is out of TPDD1 util disks, you can create your own with pdd.sh
> if you want, but you don't need to bother.
>
> You don't need the util disk unless you just want to use the original
> software just for the heck of it. TS-DOS, DSKMGR, and TEENY are all
> available already from downloads, with a convenient bootstrapper
> installer from a pc, and ts-dos is better than Floppy anyway. And you
> said you also even have a ts-dos option rom which is even better than
> installing the ram version. So you're already all set even better than
> having the original disk.
>
> I have a stack of 100 blank disks right next to me that I was supposed
> to make 50 each tpdd1 & 2 disks for Greg since probably over two years
> ago. (Sorry Greg) So I imagine he's out of them, unless he started
> making them himself or got someone else to. Anyone can make them now.
> The means are all available on-line.
>
> pdd.sh comes with disk images of both tpdd1 & 2 util disks ready to go,
> with the command line right in the readme, and even links to the nice
> labels I made for the original set I made for Greg a few years ago so
> anyone can reproduce them, both the data and the labels. The label
> software is open source and the label design files even include links to
> where to buy the exact blank labels.
>
> So it's all reproducible and open source* if anyone really wants one and
> is sick of waiting for me to make some more for Greg. And the only
> hardware you need is the same tpdd drive you want the disk for, and a
> serial connection, all described in the hardware document linked in the
> pdd.sh readme.
>
> * Except of course the actual data in the disk image is copyright Tandy
> but, shrug, that would matter more to me if you could still call up a RS
> parts line and order a replacement 26-3808 or 26-3814 disk.
>
> --
> bkw
>
>
> On 11/19/22 14:35, Spencer wrote:
> > Does everybody want to hear a funny???  Guess what?  After reading links
> > from Brian (not the sheep dip guy Bruce) I realized there is a BIG
> > difference with the TPPD1 and the TPPD2. IT ACTUALLY says Portable Disk
> > Drive for TPPD1 and Portable Disk Drive 2 for TPPD2 right on the face!
> > What about that?? ;-)  Yep brain fart!  So I can do the bootstrap, but
> > no Utility Disk.  I looked at the link Brian gave me where I can buy the
> > Utility Disk for $15 BUT what I have to wait???.  ;-) Dang!
> >
> > All this time I was treating it like a TPPD2 - wow!  Too much on my mind!
> >
> > Spencer
> >
> > P.S. Let me hear the chuckles now.  ;-)
> >
> > On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White
> >  wrote:
> >
> >
> > On 11/15/22 20:12, Spencer wrote:
> >  > I found this llink
> >  > (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
> >  > (archive.org)
> >  >
> > <
> https://ia802901.us.archive.org/13/items/tandyportablediskdriveservicemanual263808stext/Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
> <
> https://ia802901.us.archive.org/13/items/tandyportablediskdriveservicemanual263808stext/Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf>>)
>  and
> it says "Service Manual" on the first page. It's not the typical service
> manuals I've seen.
> >
> > That's the software manual and is known, and is for TPDD1 not TPDD2.
> > One of the pages I linked already has it:
> > tandy.wiki/TPDD
> > And there you will also find an actual normal service manual, but again
> > for TPDD1 not TPDD2.
> >
> > When I said no one has turned up a service manual, I meant for TPDD2
> > because you were talking about a TPDD2.
> >
> > I also didn't realize you already had a whole other working TPDD2 to
> > compare against.
> >
> > If I had known you already had a whole other TPDD2 and already made it
> > work, I could have skipped a lot of that because you've already
> > successfully done it, which proves your 200 is ok, your disk is ok, you
> > have the right kind of disk, your cable is ok, and you know how to
> > perform the bootstrap.
> >
> > If you have TS-DOS in rom, then really that's the best, and in that
> > case, you actually don't want to try to install Floppy because they
> > conflict. Just use one or the other. I mean there are ways but it's not
> > worth getting into that. The simple answer is if you have TS-DOS,
> > especially in ROM or via REX#, then just use that and don't even bother
> > with the bootstrap procedure or Floppy.
> >
> > I brought up pdd.sh just for interrogating the drive at a lower level so
> > you can debug what's wrong. It can show at least if the

Re: [M100] Tandy Portable Disk Drive 2, but really 1

2022-11-22 Thread Brian K. White

Yes well, yes, TPDD1 is almost entirely different. There is some
overlap, some backwards compatibility from TPDD2 to TPDD1, but you need
to be using the TPDD1 version of any and all directions.

If Greg is out of TPDD1 util disks, you can create your own with pdd.sh
if you want, but you don't need to bother.

You don't need the util disk unless you just want to use the original
software just for the heck of it. TS-DOS, DSKMGR, and TEENY are all
available already from downloads, with a convenient bootstrapper
installer from a pc, and ts-dos is better than Floppy anyway. And you
said you also even have a ts-dos option rom which is even better than
installing the ram version. So you're already all set even better than
having the original disk.

I have a stack of 100 blank disks right next to me that I was supposed
to make 50 each tpdd1 & 2 disks for Greg since probably over two years
ago. (Sorry Greg) So I imagine he's out of them, unless he started
making them himself or got someone else to. Anyone can make them now.
The means are all available on-line.

pdd.sh comes with disk images of both tpdd1 & 2 util disks ready to go,
with the command line right in the readme, and even links to the nice
labels I made for the original set I made for Greg a few years ago so
anyone can reproduce them, both the data and the labels. The label
software is open source and the label design files even include links to
where to buy the exact blank labels.

So it's all reproducible and open source* if anyone really wants one and
is sick of waiting for me to make some more for Greg. And the only
hardware you need is the same tpdd drive you want the disk for, and a
serial connection, all described in the hardware document linked in the
pdd.sh readme.

* Except of course the actual data in the disk image is copyright Tandy
but, shrug, that would matter more to me if you could still call up a RS
parts line and order a replacement 26-3808 or 26-3814 disk.

--
bkw

On 11/19/22 14:35, Spencer wrote:
Does everybody want to hear a funny??? Guess what? After reading links
from Brian (not the sheep dip guy Bruce) I realized there is a BIG
difference with the TPPD1 and the TPPD2. IT ACTUALLY says Portable Disk
Drive for TPPD1 and Portable Disk Drive 2 for TPPD2 right on the face!
What about that?? ;-) Yep brain fart! So I can do the bootstrap, but
no Utility Disk. I looked at the link Brian gave me where I can buy the
Utility Disk for $15 BUT what I have to wait???. ;-) Dang!

All this time I was treating it like a TPPD2 - wow! Too much on my mind!

Spencer

P.S. Let me hear the chuckles now. ;-)

On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White
wrote:

On 11/15/22 20:12, Spencer wrote:
> I found this llink
> (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
> (archive.org)
>
>) and it says "Service Manual" on the first page. It's not the typical service manuals I've seen.

That's the software manual and is known, and is for TPDD1 not TPDD2.
One of the pages I linked already has it:
tandy.wiki/TPDD
And there you will also find an actual normal service manual, but again
for TPDD1 not TPDD2.

When I said no one has turned up a service manual, I meant for TPDD2
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to
compare against.

If I had known you already had a whole other TPDD2 and already made it
work, I could have skipped a lot of that because you've already
successfully done it, which proves your 200 is ok, your disk is ok, you
have the right kind of disk, your cable is ok, and you know how to
perform the bootstrap.

If you have TS-DOS in rom, then really that's the best, and in that
case, you actually don't want to try to install Floppy because they
conflict. Just use one or the other. I mean there are ways but it's not
worth getting into that. The simple answer is if you have TS-DOS,
especially in ROM or via REX#, then just use that and don't even bother
with the bootstrap procedure or Floppy.

I brought up pdd.sh just for interrogating the drive at a lower level so
you can debug what's wrong. It can show at least if the drive firmware
is running and communicating and it's just a physical problem for
instance. "drive not ready" from TS-DOS doesn't tell you really anything.

Re: [M100] Tandy Portable Disk Drive 2

2022-11-19 Thread Spencer

 I'll look into teeny, but first I want to see if I can work out using TS-DOS 
with my TpDD1. Now when I try to format a new disk it fails with Communication 
Error. Eh one frustration after another.
On Saturday, November 19, 2022 at 07:22:37 PM EST, Stephen Adolph 
 wrote:  

 Well that would be good news I think.
Question-* did you try to load up TEENY.CO?  If you can get that running, it 
can work with TPDD directly without needing the Utility disk.
If you transfer this attached TEENY.DO to your laptop via serial transfer, 
Then load and run in BASIC,You will get TEENY.CO in the directory.
Depending on what memory location TEENY is set up to run at, you can issue a 
CLEAR command in BASIC, and then it should run right away.
Go into BASICtypeLOADM "TEENY.CO
you will get three locations 
Start  
End   
EXE  

type 
CLEAR0,   where  is the value of START.
exit BASIC, and select TEENY.  Should be running.
Teeny howto is here:http://bitchin100.com/wiki/index.php?title=TEENY

On Sat, Nov 19, 2022 at 2:36 PM Spencer  wrote:

 Does everybody want to hear a funny???  Guess what?  After reading links from 
Brian (not the sheep dip guy Bruce) I realized there is a BIG difference with 
the TPPD1 and the TPPD2. IT ACTUALLY says Portable Disk Drive for TPPD1 and 
Portable Disk Drive 2 for TPPD2 right on the face!  What about that?? ;-)  Yep 
brain fart!  So I can do the bootstrap, but no Utility Disk.  I looked at the 
link Brian gave me where I can buy the Utility Disk for $15 BUT what I have to 
wait???.  ;-) Dang!
All this time I was treating it like a TPPD2 - wow!  Too much on my mind!
Spencer
P.S. Let me hear the chuckles now.  ;-)
On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White 
 wrote:  

 On 11/15/22 20:12, Spencer wrote:
> I found this llink 
> (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf 
> (archive.org) 
> )
>  and it says "Service Manual" on the first page. It's not the typical service 
> manuals I've seen.

That's the software manual and is known, and is for TPDD1 not TPDD2.
One of the pages I linked already has it:
tandy.wiki/TPDD
And there you will also find an actual normal service manual, but again 
for TPDD1 not TPDD2.

When I said no one has turned up a service manual, I meant for TPDD2 
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to 
compare against.

If I had known you already had a whole other TPDD2 and already made it 
work, I could have skipped a lot of that because you've already 
successfully done it, which proves your 200 is ok, your disk is ok, you 
have the right kind of disk, your cable is ok, and you know how to 
perform the bootstrap.

If you have TS-DOS in rom, then really that's the best, and in that 
case, you actually don't want to try to install Floppy because they 
conflict. Just use one or the other. I mean there are ways but it's not 
worth getting into that. The simple answer is if you have TS-DOS, 
especially in ROM or via REX#, then just use that and don't even bother 
with the bootstrap procedure or Floppy.

I brought up pdd.sh just for interrogating the drive at a lower level so 
you can debug what's wrong. It can show at least if the drive firmware 
is running and communicating and it's just a physical problem for 
instance. "drive not ready" from TS-DOS doesn't tell you really anything.

But it's barely documented so it's also kind of arcane to try to use 
unless you're me I guess. But for instance maybe if you try a format, 
and it spins the drive and steps the head, but always fails verify, or 
if trying to read a raw sector always yields all 00's or drive not 
ready, maybe that means there's a problem with the head or the cable to 
the head. If the head never steps, that's a separate cable if I remember 
correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple 
of the cables can be a tricky. So there is some chance still for a 
pretty easy fix by checking just major functions like that to see if 
some parts work and only some parts don't work, before having to think 
about maybe something more complicated wrong with the electronics.

Could be something really mechanically simple too like the disk media 
isn't being pressed against the head if there's anything wrong with that 
black arm or the little microfiber pad or the metal part that raises and 
lowers the arm.

As for the crazy rocket science, that is just what's going on behind the 
scenes. The procedure is fast and easy and works, if you do it exactly 
as specified in the manual, but I have seen people fail to do that, but 
think they were doing what it said, and think it didn't work. Because 
although the directions work, they don't say why they work. So I was 
just showing what is actually happening.

-- 
bkw

> 
> Yes I

Re: [M100] Tandy Portable Disk Drive 2

2022-11-19 Thread Stephen Adolph

Well that would be good news I think.

Question-
* did you try to load up TEENY.CO?  If you can get that running, it can
work with TPDD directly without needing the Utility disk.

If you transfer this attached TEENY.DO to your laptop via serial transfer,
Then load and run in BASIC,
You will get TEENY.CO in the directory.

Depending on what memory location TEENY is set up to run at, you can issue
a CLEAR command in BASIC, and then it should run right away.

Go into BASIC
type
LOADM "TEENY.CO

you will get three locations
Start  
End   
EXE  

type
CLEAR0,   where  is the value of START.

exit BASIC, and select TEENY.  Should be running.

Teeny howto is here:
http://bitchin100.com/wiki/index.php?title=TEENY





On Sat, Nov 19, 2022 at 2:36 PM Spencer  wrote:

> Does everybody want to hear a funny???  Guess what?  After reading links
> from Brian (not the sheep dip guy Bruce) I realized there is a BIG
> difference with the TPPD1 and the TPPD2. IT ACTUALLY says Portable Disk
> Drive for TPPD1 and Portable Disk Drive 2 for TPPD2 right on the face!
> What about that?? ;-)  Yep brain fart!  So I can do the bootstrap, but no
> Utility Disk.  I looked at the link Brian gave me where I can buy the
> Utility Disk for $15 BUT what I have to wait???.  ;-) Dang!
>
> All this time I was treating it like a TPPD2 - wow!  Too much on my mind!
>
> Spencer
>
> P.S. Let me hear the chuckles now.  ;-)
>
> On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White <
> b.kenyo...@gmail.com> wrote:
>
>
> On 11/15/22 20:12, Spencer wrote:
> > I found this llink
> > (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
> > (archive.org)
> > <
> https://ia802901.us.archive.org/13/items/tandyportablediskdriveservicemanual263808stext/Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf>)
>  and
> it says "Service Manual" on the first page. It's not the typical service
> manuals I've seen.
>
> That's the software manual and is known, and is for TPDD1 not TPDD2.
> One of the pages I linked already has it:
> tandy.wiki/TPDD
> And there you will also find an actual normal service manual, but again
> for TPDD1 not TPDD2.
>
> When I said no one has turned up a service manual, I meant for TPDD2
> because you were talking about a TPDD2.
>
> I also didn't realize you already had a whole other working TPDD2 to
> compare against.
>
> If I had known you already had a whole other TPDD2 and already made it
> work, I could have skipped a lot of that because you've already
> successfully done it, which proves your 200 is ok, your disk is ok, you
> have the right kind of disk, your cable is ok, and you know how to
> perform the bootstrap.
>
> If you have TS-DOS in rom, then really that's the best, and in that
> case, you actually don't want to try to install Floppy because they
> conflict. Just use one or the other. I mean there are ways but it's not
> worth getting into that. The simple answer is if you have TS-DOS,
> especially in ROM or via REX#, then just use that and don't even bother
> with the bootstrap procedure or Floppy.
>
> I brought up pdd.sh just for interrogating the drive at a lower level so
> you can debug what's wrong. It can show at least if the drive firmware
> is running and communicating and it's just a physical problem for
> instance. "drive not ready" from TS-DOS doesn't tell you really anything.
>
> But it's barely documented so it's also kind of arcane to try to use
> unless you're me I guess. But for instance maybe if you try a format,
> and it spins the drive and steps the head, but always fails verify, or
> if trying to read a raw sector always yields all 00's or drive not
> ready, maybe that means there's a problem with the head or the cable to
> the head. If the head never steps, that's a separate cable if I remember
> correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple
> of the cables can be a tricky. So there is some chance still for a
> pretty easy fix by checking just major functions like that to see if
> some parts work and only some parts don't work, before having to think
> about maybe something more complicated wrong with the electronics.
>
> Could be something really mechanically simple too like the disk media
> isn't being pressed against the head if there's anything wrong with that
> black arm or the little microfiber pad or the metal part that raises and
> lowers the arm.
>
> As for the crazy rocket science, that is just what's going on behind the
> scenes. The procedure is fast and easy and works, if you do it exactly
> as specified in the manual, but I have seen people fail to do that, but
> think they were doing what it said, and think it didn't work. Because
> although the directions work, they don't say why they work. So I was
> just showing what is actually happening.
>
> --
> bkw
>
>
>
> >
> > Yes I ran the IPL from Bank1 which was a file I created by following the
> > TPDD2 Operations Manual; within the IPL file it was simply => RUN
> >

Re: [M100] Tandy Portable Disk Drive 2

2022-11-19 Thread Spencer

 Does everybody want to hear a funny???  Guess what?  After reading links from 
Brian (not the sheep dip guy Bruce) I realized there is a BIG difference with 
the TPPD1 and the TPPD2. IT ACTUALLY says Portable Disk Drive for TPPD1 and 
Portable Disk Drive 2 for TPPD2 right on the face!  What about that?? ;-)  Yep 
brain fart!  So I can do the bootstrap, but no Utility Disk.  I looked at the 
link Brian gave me where I can buy the Utility Disk for $15 BUT what I have to 
wait???.  ;-) Dang!
All this time I was treating it like a TPPD2 - wow!  Too much on my mind!
Spencer
P.S. Let me hear the chuckles now.  ;-)
On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White 
 wrote:  

 On 11/15/22 20:12, Spencer wrote:
> I found this llink 
> (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf 
> (archive.org) 
> )
>  and it says "Service Manual" on the first page. It's not the typical service 
> manuals I've seen.

That's the software manual and is known, and is for TPDD1 not TPDD2.
One of the pages I linked already has it:
tandy.wiki/TPDD
And there you will also find an actual normal service manual, but again 
for TPDD1 not TPDD2.

When I said no one has turned up a service manual, I meant for TPDD2 
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to 
compare against.

If I had known you already had a whole other TPDD2 and already made it 
work, I could have skipped a lot of that because you've already 
successfully done it, which proves your 200 is ok, your disk is ok, you 
have the right kind of disk, your cable is ok, and you know how to 
perform the bootstrap.

If you have TS-DOS in rom, then really that's the best, and in that 
case, you actually don't want to try to install Floppy because they 
conflict. Just use one or the other. I mean there are ways but it's not 
worth getting into that. The simple answer is if you have TS-DOS, 
especially in ROM or via REX#, then just use that and don't even bother 
with the bootstrap procedure or Floppy.

I brought up pdd.sh just for interrogating the drive at a lower level so 
you can debug what's wrong. It can show at least if the drive firmware 
is running and communicating and it's just a physical problem for 
instance. "drive not ready" from TS-DOS doesn't tell you really anything.

But it's barely documented so it's also kind of arcane to try to use 
unless you're me I guess. But for instance maybe if you try a format, 
and it spins the drive and steps the head, but always fails verify, or 
if trying to read a raw sector always yields all 00's or drive not 
ready, maybe that means there's a problem with the head or the cable to 
the head. If the head never steps, that's a separate cable if I remember 
correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple 
of the cables can be a tricky. So there is some chance still for a 
pretty easy fix by checking just major functions like that to see if 
some parts work and only some parts don't work, before having to think 
about maybe something more complicated wrong with the electronics.

Could be something really mechanically simple too like the disk media 
isn't being pressed against the head if there's anything wrong with that 
black arm or the little microfiber pad or the metal part that raises and 
lowers the arm.

As for the crazy rocket science, that is just what's going on behind the 
scenes. The procedure is fast and easy and works, if you do it exactly 
as specified in the manual, but I have seen people fail to do that, but 
think they were doing what it said, and think it didn't work. Because 
although the directions work, they don't say why they work. So I was 
just showing what is actually happening.

-- 
bkw

> 
> Yes I ran the IPL from Bank1 which was a file I created by following the 
> TPDD2 Operations Manual; within the IPL file it was simply => RUN 
> "COM:98N1ENN." I ran it with the drive off then I turned it on - nothing 
> happens. With my drive that works this command works fine, but with this 
> one with problems it doesn't work. Agree running this command from basic 
> would do the same thing. On pg 8 of the Ops Manual it says exactly what 
> to do as far as saving this IPL BA file. No rocket science or convoluted 
> details but simple straight forward details. I know it's not the serial 
> cable or port on the T200 because it works with my other TPDD2. So on 
> the misbehaving drive it never shows the "INITIAL PROGRAM LOADER II" 
> header. Didn't get any message about "SYSTEM EXISTS" - nada. Got the 
> Util diskette with Backup.ba and Fremem.ba and other files. My serial 
> cable is the one that I bought 2 years ago that came with the drive and 
> the Utility diskette and they work. I'm assuming it's the original cable 
> because it was nicely packed

Re: [M100] Tandy Portable Disk Drive 2

2022-11-17 Thread Spencer

 lol. I needed a smile today. Everybody makes an occasional typo, well most 
anyway.
Oh I meant to say Brian not Bruce. I worked with a Bruce White for twenty years 
and he was alot like you: super-hacker etc. When I needed technical advisement 
I went to him first.
Spencer
On Thursday, November 17, 2022 at 12:35:31 PM EST, Brian K. White 
 wrote:  

 And what was I thinking when I wrote "buy now" ? a used car?
  haha

-- 
bkw

On 11/17/22 10:56, Spencer wrote:
> yeah typo. I must have been thinking of a Bruce White I used to work with.
> 
> On Thursday, November 17, 2022 at 12:52:56 AM EST, Daryl Tester 
>  wrote:
> 
> 
> "He's Brian, and so's his wife!" - I think Bruce was in charge of the 
> sheep dip.
> 
> On 17/11/22 12:06, Spencer wrote:
> 
>  > Thanks for your suggestions and time Bruce!
>  >
>  > Spencer
>  >
>  > On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
> mailto:b.kenyo...@gmail.com>> wrote:
> 

-- 
bkw

Re: [M100] Tandy Portable Disk Drive 2

2022-11-17 Thread Brian K. White

And what was I thinking when I wrote "buy now" ? a used car?
 haha

--
bkw

On 11/17/22 10:56, Spencer wrote:

yeah typo. I must have been thinking of a Bruce White I used to work with.

On Thursday, November 17, 2022 at 12:52:56 AM EST, Daryl Tester 
 wrote:

"He's Brian, and so's his wife!" - I think Bruce was in charge of the 
sheep dip.

On 17/11/22 12:06, Spencer wrote:

 > Thanks for your suggestions and time Bruce!
 >
 > Spencer
 >
 > On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
mailto:b.kenyo...@gmail.com>> wrote:

--
bkw

Re: [M100] Tandy Portable Disk Drive 2

2022-11-17 Thread Spencer

 yeah typo. I must have been thinking of a Bruce White I used to work with.
On Thursday, November 17, 2022 at 12:52:56 AM EST, Daryl Tester 
 wrote:  

 "He's Brian, and so's his wife!" - I think Bruce was in charge of the sheep 
dip.

On 17/11/22 12:06, Spencer wrote:

> Thanks for your suggestions and time Bruce!
> 
> Spencer
> 
> On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
>  wrote:

Re: [M100] Tandy Portable Disk Drive 2

2022-11-17 Thread Bert Put


LOL You could not ask for a more Australian response :-)

Regards,Bert

On 11/16/22 23:24, Daryl Tester wrote:
"He's Brian, and so's his wife!" - I think Bruce was in charge of the 
sheep dip.


On 17/11/22 12:06, Spencer wrote:


Thanks for your suggestions and time Bruce!

Spencer

On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
 wrote:

Re: [M100] Tandy Portable Disk Drive 2

2022-11-16 Thread Daryl Tester


"He's Brian, and so's his wife!" - I think Bruce was in charge of the sheep dip.

On 17/11/22 12:06, Spencer wrote:


Thanks for your suggestions and time Bruce!

Spencer

On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
 wrote:

Re: [M100] Tandy Portable Disk Drive 2

2022-11-16 Thread Spencer

 Thanks for your suggestions and time Bruce!
Spencer
On Wednesday, November 16, 2022 at 05:17:31 PM EST, Brian K. White 
 wrote:  
 
 What can I say, buy now, I am simply clairvoyant. haha

People ask for more info but that's for beginners. All I need to hear is 
where you eat lunch and I can tell you it's from the kickback spikes on 
the power lines from the large electric motors in a factory elsewhere in 
your office building.

-- 
bkw

On 11/15/22 23:36, Spencer wrote:
> VERY interesting!  You may have hit on something I'll look into.  That 
> part you mentioned "
> black arm or the little microfiber pad or the metal part that raises and
> lowers the arm" makes me think it could be that. Why do I say this?  The 
> first problem I had to remedy was when I first tried to insert a floppy 
> it wouldn't go in the drive.  When I opened it the mechanism was 
> stuck/out of place/gummed up or someone jammed it up, and there was some 
> green (looked like corrosion) goo I had to clean, but the metal pieces 
> were not hooking up right keeping the diskette from being inserted, and 
> the black arm was under that small piece of metal and it didn't look 
> right. I opened my other drive and the black arm piece, if memory serves 
> me right, was on top of that small piece of metal. I gently but with 
> slight pressure put the piece back right when comparing my other drive. 
> I also thought the black arm pad didn't look quite as close to the mylar 
> (when I inserted the diskette) as my other drive. SO it's likely you hit 
> the nail on the head (excuse the pun). I'll look again, but to repair 
> this may be out of my league to repair. Repairing floppy heads should be 
> done by the experienced imho unless a guided procedure is easily understood.
> 
> Thanks!
> 
> On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White 
>  wrote:
> 
> 
> On 11/15/22 20:12, Spencer wrote:
>  > I found this llink
>  > (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
>  > (archive.org)
>  > 
>   
> >)
>  and it says "Service Manual" on the first page. It's not the typical service 
> manuals I've seen.
> 
> That's the software manual and is known, and is for TPDD1 not TPDD2.
> One of the pages I linked already has it:
> tandy.wiki/TPDD
> And there you will also find an actual normal service manual, but again
> for TPDD1 not TPDD2.
> 
> When I said no one has turned up a service manual, I meant for TPDD2
> because you were talking about a TPDD2.
> 
> I also didn't realize you already had a whole other working TPDD2 to
> compare against.
> 
> If I had known you already had a whole other TPDD2 and already made it
> work, I could have skipped a lot of that because you've already
> successfully done it, which proves your 200 is ok, your disk is ok, you
> have the right kind of disk, your cable is ok, and you know how to
> perform the bootstrap.
> 
> If you have TS-DOS in rom, then really that's the best, and in that
> case, you actually don't want to try to install Floppy because they
> conflict. Just use one or the other. I mean there are ways but it's not
> worth getting into that. The simple answer is if you have TS-DOS,
> especially in ROM or via REX#, then just use that and don't even bother
> with the bootstrap procedure or Floppy.
> 
> I brought up pdd.sh just for interrogating the drive at a lower level so
> you can debug what's wrong. It can show at least if the drive firmware
> is running and communicating and it's just a physical problem for
> instance. "drive not ready" from TS-DOS doesn't tell you really anything.
> 
> But it's barely documented so it's also kind of arcane to try to use
> unless you're me I guess. But for instance maybe if you try a format,
> and it spins the drive and steps the head, but always fails verify, or
> if trying to read a raw sector always yields all 00's or drive not
> ready, maybe that means there's a problem with the head or the cable to
> the head. If the head never steps, that's a separate cable if I remember
> correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple
> of the cables can be a tricky. So there is some chance still for a
> pretty easy fix by checking just major functions like that to see if
> some parts work and only some parts don't work, before having to think
> about maybe something more complicated wrong with the electronics.
> 
> Could be something really mechanically simple too like the disk media
> isn't being pressed against the head if there's anything wrong with that
> black arm or the little microfiber pad or the metal part that raises and
> lowers the arm.
> 
> As for the crazy rocket science, that is just what's going on behind the
>

Re: [M100] Tandy Portable Disk Drive 2

2022-11-16 Thread Brian K. White

What can I say, buy now, I am simply clairvoyant. haha

People ask for more info but that's for beginners. All I need to hear is
where you eat lunch and I can tell you it's from the kickback spikes on
the power lines from the large electric motors in a factory elsewhere in
your office building.

--
bkw

On 11/15/22 23:36, Spencer wrote:
VERY interesting! You may have hit on something I'll look into. That
part you mentioned "

black arm or the little microfiber pad or the metal part that raises and
lowers the arm" makes me think it could be that. Why do I say this? The
first problem I had to remedy was when I first tried to insert a floppy
it wouldn't go in the drive. When I opened it the mechanism was
stuck/out of place/gummed up or someone jammed it up, and there was some
green (looked like corrosion) goo I had to clean, but the metal pieces
were not hooking up right keeping the diskette from being inserted, and
the black arm was under that small piece of metal and it didn't look
right. I opened my other drive and the black arm piece, if memory serves
me right, was on top of that small piece of metal. I gently but with
slight pressure put the piece back right when comparing my other drive.
I also thought the black arm pad didn't look quite as close to the mylar
(when I inserted the diskette) as my other drive. SO it's likely you hit
the nail on the head (excuse the pun). I'll look again, but to repair
this may be out of my league to repair. Repairing floppy heads should be
done by the experienced imho unless a guided procedure is easily understood.

Thanks!

On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White
wrote:

When I said no one has turned up a service manual, I meant for TPDD2
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to
compare against.

But it's barely documented so it's also kind of arcane to try to use
unless you're me I guess. But for instance maybe if you try a format,
and it spins the drive and steps the head, but always fails verify, or
if trying to read a raw sector always yields all 00's or drive not
ready, maybe that means there's a problem with the head or the cable to
the head. If the head never steps, that's a separate cable if I remember
correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple
of the cables can be a tricky. So there is some chance still for a
pretty easy fix by checking just major functions like that to see if
some parts work and only some parts don't work, before having to think
about maybe something more complicated wrong with the electronics.

Could be something really mechanically simple too like the disk media
isn't being pressed against the head if there's anything wrong with that
black arm or the little microfiber pad or the metal part that raises and
lowers the arm.

As for the crazy rocket science, that is just what's going on behind the
scenes. The procedure is fast and easy and works, if you do it exactly
as specified in the manual, but I have seen people fail to do that, but
think they were doing what it said, and think it didn't work. Because
although the directions work, they don't say why they work. So I was
just showing what is

Re: [M100] Tandy Portable Disk Drive 2

2022-11-15 Thread Spencer

 VERY interesting!  You may have hit on something I'll look into.  That part 
you mentioned "black arm or the little microfiber pad or the metal part that 
raises and
lowers the arm" makes me think it could be that. Why do I say this?  The first 
problem I had to remedy was when I first tried to insert a floppy it wouldn't 
go in the drive.  When I opened it the mechanism was stuck/out of place/gummed 
up or someone jammed it up, and there was some green (looked like corrosion) 
goo I had to clean, but the metal pieces were not hooking up right keeping the 
diskette from being inserted, and the black arm was under that small piece of 
metal and it didn't look right. I opened my other drive and the black arm 
piece, if memory serves me right, was on top of that small piece of metal. I 
gently but with slight pressure put the piece back right when comparing my 
other drive. I also thought the black arm pad didn't look quite as close to the 
mylar (when I inserted the diskette) as my other drive. SO it's likely you hit 
the nail on the head (excuse the pun). I'll look again, but to repair this may 
be out of my league to repair. Repairing floppy heads should be done by the 
experienced imho unless a guided procedure is easily understood.
Thanks!
On Tuesday, November 15, 2022 at 09:35:51 PM EST, Brian K. White 
 wrote:  

 On 11/15/22 20:12, Spencer wrote:
> I found this llink 
> (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf 
> (archive.org) 
> )
>  and it says "Service Manual" on the first page. It's not the typical service 
> manuals I've seen.

That's the software manual and is known, and is for TPDD1 not TPDD2.
One of the pages I linked already has it:
tandy.wiki/TPDD
And there you will also find an actual normal service manual, but again 
for TPDD1 not TPDD2.

When I said no one has turned up a service manual, I meant for TPDD2 
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to 
compare against.

If I had known you already had a whole other TPDD2 and already made it 
work, I could have skipped a lot of that because you've already 
successfully done it, which proves your 200 is ok, your disk is ok, you 
have the right kind of disk, your cable is ok, and you know how to 
perform the bootstrap.

If you have TS-DOS in rom, then really that's the best, and in that 
case, you actually don't want to try to install Floppy because they 
conflict. Just use one or the other. I mean there are ways but it's not 
worth getting into that. The simple answer is if you have TS-DOS, 
especially in ROM or via REX#, then just use that and don't even bother 
with the bootstrap procedure or Floppy.

I brought up pdd.sh just for interrogating the drive at a lower level so 
you can debug what's wrong. It can show at least if the drive firmware 
is running and communicating and it's just a physical problem for 
instance. "drive not ready" from TS-DOS doesn't tell you really anything.

But it's barely documented so it's also kind of arcane to try to use 
unless you're me I guess. But for instance maybe if you try a format, 
and it spins the drive and steps the head, but always fails verify, or 
if trying to read a raw sector always yields all 00's or drive not 
ready, maybe that means there's a problem with the head or the cable to 
the head. If the head never steps, that's a separate cable if I remember 
correctly. TPDD2 is a lot easier than TPDD1, but even on TPDD2 a couple 
of the cables can be a tricky. So there is some chance still for a 
pretty easy fix by checking just major functions like that to see if 
some parts work and only some parts don't work, before having to think 
about maybe something more complicated wrong with the electronics.

Could be something really mechanically simple too like the disk media 
isn't being pressed against the head if there's anything wrong with that 
black arm or the little microfiber pad or the metal part that raises and 
lowers the arm.

As for the crazy rocket science, that is just what's going on behind the 
scenes. The procedure is fast and easy and works, if you do it exactly 
as specified in the manual, but I have seen people fail to do that, but 
think they were doing what it said, and think it didn't work. Because 
although the directions work, they don't say why they work. So I was 
just showing what is actually happening.

-- 
bkw

> 
> Yes I ran the IPL from Bank1 which was a file I created by following the 
> TPDD2 Operations Manual; within the IPL file it was simply => RUN 
> "COM:98N1ENN." I ran it with the drive off then I turned it on - nothing 
> happens. With my drive that works this command works fine, but with this 
> one with problems it doesn't work. Agree running this command from basic 
> would do the same thing. On pg 8 of the Ops Manual

Re: [M100] Tandy Portable Disk Drive 2

2022-11-15 Thread Brian K. White

On 11/15/22 20:12, Spencer wrote:
I found this llink
(Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf
(archive.org)
) and it says "Service Manual" on the first page. It's not the typical service manuals I've seen.

When I said no one has turned up a service manual, I meant for TPDD2
because you were talking about a TPDD2.

I also didn't realize you already had a whole other working TPDD2 to
compare against.

--
bkw

Yes I ran the IPL from Bank1 which was a file I created by following the
TPDD2 Operations Manual; within the IPL file it was simply => RUN
"COM:98N1ENN." I ran it with the drive off then I turned it on - nothing
happens. With my drive that works this command works fine, but with this
one with problems it doesn't work. Agree running this command from basic
would do the same thing. On pg 8 of the Ops Manual it says exactly what
to do as far as saving this IPL BA file. No rocket science or convoluted
details but simple straight forward details. I know it's not the serial
cable or port on the T200 because it works with my other TPDD2. So on
the misbehaving drive it never shows the "INITIAL PROGRAM LOADER II"
header. Didn't get any message about "SYSTEM EXISTS" - nada. Got the
Util diskette with Backup.ba and Fremem.ba and other files. My serial
cable is the one that I bought 2 years ago that came with the drive and
the Utility diskette and they work. I'm assuming it's the original cable
because it was nicely packed with the nice little blue carrying case
with Tandy written on it.

I have TS-DOS on ROM, but haven't tried it yet with a TPDD2.

The TPL I'm referring is the file that Ops Manual suggested creating and
adding the COM line to it (just one line above).

Ultimately with the drive that works I simply ran the IPL, turned on the
drive and it did it's thing, then I began using the utility diskette
with backup and made copies of the Utility disk, so this times me the
problem is with the troublesome drive. I would run the IPL, turn on the
drive and nothing. I even went upstairs for a cup of coffee and still
nothing when I returned, so shift-break to get out of it. That's all
I've got.

Thanks for your time! It's appreciated.

Re: [M100] Tandy Portable Disk Drive 2

2022-11-15 Thread Spencer

 I found this llink (Tandy_Portable_Disk_Drive_Service_Manual_26-3808S_text.pdf 
(archive.org)) and it says "Service Manual" on the first page. It's not the 
typical service manuals I've seen.
Yes I ran the IPL from Bank1 which was a file I created by following the TPDD2 
Operations Manual; within the IPL file it was simply => RUN "COM:98N1ENN." I 
ran it with the drive off then I turned it on - nothing happens. With my drive 
that works this command works fine, but with this one with problems it doesn't 
work. Agree running this command from basic would do the same thing. On pg 8 of 
the Ops Manual it says exactly what to do as far as saving this IPL BA file. No 
rocket science or convoluted details but simple straight forward details. I 
know it's not the serial cable or port on the T200 because it works with my 
other TPDD2. So on the misbehaving drive it never shows the "INITIAL PROGRAM 
LOADER II" header. Didn't get any message about "SYSTEM EXISTS" - nada. Got the 
Util diskette with Backup.ba and Fremem.ba and other files. My serial cable is 
the one that I bought 2 years ago that came with the drive and the Utility 
diskette and they work. I'm assuming it's the original cable because it was 
nicely packed with the nice little blue carrying case with Tandy written on it.
I have TS-DOS on ROM, but haven't tried it yet with a TPDD2. 
The TPL I'm referring is the file that Ops Manual suggested creating and adding 
the COM line to it (just one line above). 
Ultimately with the drive that works I simply ran the IPL, turned on the drive 
and it did it's thing, then I began using the utility diskette with backup and 
made copies of the Utility disk, so this times me the problem is with the 
troublesome drive. I would run the IPL, turn on the drive and nothing. I even 
went upstairs for a cup of coffee and still nothing when I returned, so 
shift-break to get out of it. That's all I've got.
Thanks for your time!  It's appreciated.Spencer




On Monday, November 14, 2022 at 11:40:10 PM EST, Brian K. White 
 wrote:  
 
 The operation manual is on-line several places.
http://tandy.wiki/TPDD

I don't think anyone has ever turned up a service manual or programming 
manual for it yet.

I'm confused by what you said earlier.
You said you ran the IPL from ram, but, the boot procedure for TPDD2 
doesn't require saving any IPL. You just manually enter a single command 
in BASIC and the drive does the rest.

But there is more to it than that. You don't just run the command, you 
have to arrange several details and conditions exactly a certain way and 
THEN run the command at a certain point in a short sequence of 
procedures. If you omit any steps or do anything out of order, it 
doesn't work, and some of the details don't seem important so it's 
natural to gloss over things not realizing they actually matter.

It requires the special util disk for TPDD2 (the TPDD1 one won't work on 
TPDD2), the special serial cable (includes transistors inside, it's not 
an ordinary cable).

Start with the drive connected and turned OFF.
Make sure the write-protect hole on the TPDD2 util disk is OPEN.
Insert the TPDD2 util disk.
Type into BASIC:
  RUN "COM:98N1ENN"
and hit Enter
Only now turn the drive ON.

The drive does the rest itself.

The drive is checking a few different things one time at power-on to 
decide if it should do the bootstrap.
* disk must be inserted
* disk must be write-protected
* DSR pin must be low
* disk must contain the necessary data in the expected location on disk 
(I don't know the exact rules the firmware is following, just that the 
util disk satisfies it.)
All that has to be in place before power-on. It doesn't matter any other 
time. You can't trigger the bootstrap after the fact. It's a one-time 
check right at power-on.


You can also skip the normal util disk and just use any other TPDD 
client instead of Floppy. You can use a bootstrapper to install TS-DOS 
onto the 200 from a PC, and then us TS-DOS with the drive.
You only need the util disk if you want to run the original Floppy tpdd 
client that came with the drive. But it's not the best DOS so there 
isn't really much reason to bother with it except just for academic 
reasons. If you just want to use the drive, none of the bootup procedure 
matters since the util disk is the only disk know that does it. Every 
other program has to be installed some other way.

To install TS-DOS from a pc, If Windows try github.com/bkw777/tsend
if mac or linux, try github.com/bkw777/dlplus
each one's readme has further details. You want TS-DOS.200 in either 
case since you have a 200.


Possible problems:

The serial cable is special and has transistors inside. Do you have an 
original cable or a proper replacement (github.com/bkw777/TPDD_Cable), 
or something that's just wire and connectors without the level-shifting 
transistors? The original cables have a sharp bend at the plug that I am 
amazed isn't broken wires on everyone's cables by now. Most

Re: [M100] Tandy Portable Disk Drive 2

2022-11-14 Thread Brian K. White


The operation manual is on-line several places.
http://tandy.wiki/TPDD

I don't think anyone has ever turned up a service manual or programming 
manual for it yet.


I'm confused by what you said earlier.
You said you ran the IPL from ram, but, the boot procedure for TPDD2 
doesn't require saving any IPL. You just manually enter a single command 
in BASIC and the drive does the rest.


But there is more to it than that. You don't just run the command, you 
have to arrange several details and conditions exactly a certain way and 
THEN run the command at a certain point in a short sequence of 
procedures. If you omit any steps or do anything out of order, it 
doesn't work, and some of the details don't seem important so it's 
natural to gloss over things not realizing they actually matter.


It requires the special util disk for TPDD2 (the TPDD1 one won't work on 
TPDD2), the special serial cable (includes transistors inside, it's not 
an ordinary cable).


Start with the drive connected and turned OFF.
Make sure the write-protect hole on the TPDD2 util disk is OPEN.
Insert the TPDD2 util disk.
Type into BASIC:
  RUN "COM:98N1ENN"
and hit Enter
Only now turn the drive ON.

The drive does the rest itself.

The drive is checking a few different things one time at power-on to 
decide if it should do the bootstrap.

* disk must be inserted
* disk must be write-protected
* DSR pin must be low
* disk must contain the necessary data in the expected location on disk 
(I don't know the exact rules the firmware is following, just that the 
util disk satisfies it.)
All that has to be in place before power-on. It doesn't matter any other 
time. You can't trigger the bootstrap after the fact. It's a one-time 
check right at power-on.



You can also skip the normal util disk and just use any other TPDD 
client instead of Floppy. You can use a bootstrapper to install TS-DOS 
onto the 200 from a PC, and then us TS-DOS with the drive.
You only need the util disk if you want to run the original Floppy tpdd 
client that came with the drive. But it's not the best DOS so there 
isn't really much reason to bother with it except just for academic 
reasons. If you just want to use the drive, none of the bootup procedure 
matters since the util disk is the only disk know that does it. Every 
other program has to be installed some other way.


To install TS-DOS from a pc, If Windows try github.com/bkw777/tsend
if mac or linux, try github.com/bkw777/dlplus
each one's readme has further details. You want TS-DOS.200 in either 
case since you have a 200.



Possible problems:

The serial cable is special and has transistors inside. Do you have an 
original cable or a proper replacement (github.com/bkw777/TPDD_Cable), 
or something that's just wire and connectors without the level-shifting 
transistors? The original cables have a sharp bend at the plug that I am 
amazed isn't broken wires on everyone's cables by now. Most original 
cables still seem to work actually, but I just suspect that cable until 
proven working, or if it looks like it hasn't been flexed a lot right at 
the db25 boot and "looks good".


The disk is special. Do you have an original TPDD2 util disk or a proper 
copy on 720K media, or something else? TPDD1 util disk is different and 
won't work. A copy made on a 1.44M disk may work but is untrustworthy. A 
copy made by manually copying the files instead of using the backup 
utility won't work.


If by IPL you mean the 3 or-so line BASIC for TPDD1, that won't work for 
TPDD2. If you mean the single command for TPDD2, it requires more than 
just running the command but I already went over that above.


If you have a linux or mac machine, and can scrounge up the necessary 
9-25 & gender-change adapters *without* null-modem, you can interrogate 
the drive manually with this bash tpdd client:

github.com/bkw777/pdd.sh
see the hardware link in the readme for links to the right adapters.

After install just try "$ pdd ls"
bkw@fw:~$ pdd ls
-  Directory Listing   [0]  -
AFLOPY2.SYS  | F |  11475
BACKUP.BA| F |   1940
FREMEM.BA| F |372
-
186880 bytes free[WP]
bkw@fw:~$

(that A in AFLOPY2.SYS is really reverse video, and stands for a 
normally non-printable binary byte 0x01 that's on the disk but not 
normally visible in any normal DOS like Floppy or TS-DOS, it's part of 
what makes this disk "special")


If you don't get a file listing, you could try increasing the debug 
verbosity to 1, 2, 3 or more, and try the "status" command, or 
"condition" (a similar but different command), or "ls" again, and see 
what kind of error code(s) the drive returns.


$ DEBUG=3 pdd status

"drive not ready" could be all kinds of things, but the drive firmware 
actually returns a bunch of different possible numeric error codes as 
part of the response to every commend, and pdd.sh will display a text 
meaning of the numerical code. (you

Re: [M100] Tandy Portable Disk Drive 2

2022-11-14 Thread Mike Stein

If you don't mind spending a few bucks, maybe Jeff Birt can look at it for
you. On the other hand, there are a few better storage options available
these days ..

m

On Mon, Nov 14, 2022 at 10:47 PM Spencer  wrote:

> Sorry folks for all the chatter on this. This is my last email on this. If
> I find a fix I'll share. I haven't been using the T200s all that long, but
> learned alot. I also learned that the earlier models did in fact have
> jumpers and when you opened the little door you saw them. Later models you
> only see the shield when opening the door, and I found the service manual;
> it told me I was wrong about the default settings of the switches; I
> thought they were off, but the default is on, so I changed the switches to
> ON (apparently a previous owner changed them all to OFF), and it still
> didn't help.  So I'll keep reading the service manual for hopefully more
> insight, but I may determine it's some hardware issue with the drive that I
> may need parts to repair. Who knows what has been done to this drive over
> the 28 + years.
>
> Thanks again for your help.
> Spencer
>
> On Monday, November 14, 2022 at 06:09:49 PM EST, Spencer <
> spencer...@yahoo.com> wrote:
>
>
> Found nothing of value when I looked again. I found that on some earlier
> models (so it appears) it had a physical dip block, but on later models it
> had four jumpers on SW1 but were soldered (or etched in the board) at the
> factory and the bottom part of the four switches showed the contacts as
> open. It looks like they should be off, but please set me straight if my
> assumption is wrong. In any event still the "drive not ready" error still
> there ;-(. I'll see if I can find a service manual unless any of you have
> one you wouldn't mind sending me.
>
> Thanks for your help!
>
> On Monday, November 14, 2022 at 04:57:18 PM EST, Spencer <
> spencer...@yahoo.com> wrote:
>
>
> Ok I popped the hood and YES there is a dip block of four switches and all
> are off, and yes it's covered by the shield so opening that little door
> shows just the shiled. If anyone knows how they should be please let me
> know. Something I did find was the power supply has a white connector that
> plugs into a board with the fuse and it was some pulled out from one side
> but not all the way. Actually don't know if I pulled it out when I opened
> it or not. Btw the 1A fuse is good. Everything looks good. Don't see any
> popped/leaking caps or broken solder joints, but I'll try it again and
> share what I find.
>
> Thanks
>
> On Monday, November 14, 2022 at 03:26:44 PM EST, John R. Hogerhuis <
> jho...@pobox.com> wrote:
>
>
>
>
> On Mon, Nov 14, 2022 at 11:59 AM Greg Swallow  wrote:
>
> Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had.
> Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never
> had to change anything so never opened it before now.
>
>
> And my recollection is that means short of somehow populating the DIP
> (which may or may not work) you're locked at 19200bps on the TPDD-2. The
> TPDD-1 is actually a rebadged Brother FB-100. The FB-100 has the dip
> switches, but defaults to 9600bps which the Brother Knitting machine
> devices are locked to. So although TPDD-1's can be used with Brother
> Knitting Machines, the TPDD-2 cannot.
>
> -- John.
>

Re: [M100] Tandy Portable Disk Drive 2

 Sorry folks for all the chatter on this. This is my last email on this. If I 
find a fix I'll share. I haven't been using the T200s all that long, but 
learned alot. I also learned that the earlier models did in fact have jumpers 
and when you opened the little door you saw them. Later models you only see the 
shield when opening the door, and I found the service manual; it told me I was 
wrong about the default settings of the switches; I thought they were off, but 
the default is on, so I changed the switches to ON (apparently a previous owner 
changed them all to OFF), and it still didn't help.  So I'll keep reading the 
service manual for hopefully more insight, but I may determine it's some 
hardware issue with the drive that I may need parts to repair. Who knows what 
has been done to this drive over the 28 + years.
Thanks again for your help.Spencer
On Monday, November 14, 2022 at 06:09:49 PM EST, Spencer 
 wrote:  
 
  Found nothing of value when I looked again. I found that on some earlier 
models (so it appears) it had a physical dip block, but on later models it had 
four jumpers on SW1 but were soldered (or etched in the board) at the factory 
and the bottom part of the four switches showed the contacts as open. It looks 
like they should be off, but please set me straight if my assumption is wrong. 
In any event still the "drive not ready" error still there ;-(. I'll see if I 
can find a service manual unless any of you have one you wouldn't mind sending 
me.
Thanks for your help!
On Monday, November 14, 2022 at 04:57:18 PM EST, Spencer 
 wrote:  
 
  Ok I popped the hood and YES there is a dip block of four switches and all 
are off, and yes it's covered by the shield so opening that little door shows 
just the shiled. If anyone knows how they should be please let me know. 
Something I did find was the power supply has a white connector that plugs into 
a board with the fuse and it was some pulled out from one side but not all the 
way. Actually don't know if I pulled it out when I opened it or not. Btw the 1A 
fuse is good. Everything looks good. Don't see any popped/leaking caps or 
broken solder joints, but I'll try it again and share what I find.
Thanks
On Monday, November 14, 2022 at 03:26:44 PM EST, John R. Hogerhuis 
 wrote:  
 
 

On Mon, Nov 14, 2022 at 11:59 AM Greg Swallow  wrote:

Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had. 
Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never had 
to change anything so never opened it before now.


And my recollection is that means short of somehow populating the DIP (which 
may or may not work) you're locked at 19200bps on the TPDD-2. The TPDD-1 is 
actually a rebadged Brother FB-100. The FB-100 has the dip switches, but 
defaults to 9600bps which the Brother Knitting machine devices are locked to. 
So although TPDD-1's can be used with Brother Knitting Machines, the TPDD-2 
cannot.
-- John.

Re: [M100] Tandy Portable Disk Drive 2

 Found nothing of value when I looked again. I found that on some earlier 
models (so it appears) it had a physical dip block, but on later models it had 
four jumpers on SW1 but were soldered (or etched in the board) at the factory 
and the bottom part of the four switches showed the contacts as open. It looks 
like they should be off, but please set me straight if my assumption is wrong. 
In any event still the "drive not ready" error still there ;-(. I'll see if I 
can find a service manual unless any of you have one you wouldn't mind sending 
me.
Thanks for your help!
On Monday, November 14, 2022 at 04:57:18 PM EST, Spencer 
 wrote:  
 
  Ok I popped the hood and YES there is a dip block of four switches and all 
are off, and yes it's covered by the shield so opening that little door shows 
just the shiled. If anyone knows how they should be please let me know. 
Something I did find was the power supply has a white connector that plugs into 
a board with the fuse and it was some pulled out from one side but not all the 
way. Actually don't know if I pulled it out when I opened it or not. Btw the 1A 
fuse is good. Everything looks good. Don't see any popped/leaking caps or 
broken solder joints, but I'll try it again and share what I find.
Thanks
On Monday, November 14, 2022 at 03:26:44 PM EST, John R. Hogerhuis 
 wrote:  
 
 

On Mon, Nov 14, 2022 at 11:59 AM Greg Swallow  wrote:

Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had. 
Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never had 
to change anything so never opened it before now.


And my recollection is that means short of somehow populating the DIP (which 
may or may not work) you're locked at 19200bps on the TPDD-2. The TPDD-1 is 
actually a rebadged Brother FB-100. The FB-100 has the dip switches, but 
defaults to 9600bps which the Brother Knitting machine devices are locked to. 
So although TPDD-1's can be used with Brother Knitting Machines, the TPDD-2 
cannot.
-- John.

Re: [M100] Tandy Portable Disk Drive 2

 Ok I popped the hood and YES there is a dip block of four switches and all are 
off, and yes it's covered by the shield so opening that little door shows just 
the shiled. If anyone knows how they should be please let me know. Something I 
did find was the power supply has a white connector that plugs into a board 
with the fuse and it was some pulled out from one side but not all the way. 
Actually don't know if I pulled it out when I opened it or not. Btw the 1A fuse 
is good. Everything looks good. Don't see any popped/leaking caps or broken 
solder joints, but I'll try it again and share what I find.
Thanks
On Monday, November 14, 2022 at 03:26:44 PM EST, John R. Hogerhuis 
 wrote:  
 
 

On Mon, Nov 14, 2022 at 11:59 AM Greg Swallow  wrote:

Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had. 
Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never had 
to change anything so never opened it before now.


And my recollection is that means short of somehow populating the DIP (which 
may or may not work) you're locked at 19200bps on the TPDD-2. The TPDD-1 is 
actually a rebadged Brother FB-100. The FB-100 has the dip switches, but 
defaults to 9600bps which the Brother Knitting machine devices are locked to. 
So although TPDD-1's can be used with Brother Knitting Machines, the TPDD-2 
cannot.
-- John.

Re: [M100] Tandy Portable Disk Drive 2

 Hmm that's funny. I always wondered why is there a cover there with nothing!  
;-) Now I know.
On Monday, November 14, 2022 at 02:59:19 PM EST, Greg Swallow 
 wrote:  
 
 Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had. 
Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never had 
to change anything so never opened it before now.
God Bless,GregS <><
Sent from my iPad

On Nov 14, 2022, at 12:36 PM, John R. Hogerhuis  wrote:





On Mon, Nov 14, 2022 at 11:17 AM Greg Swallow  wrote:

   Yes indeed. TPDD2 does have a little cover for the DIP switch. Just flip it 
over, it's just the other side from the battery compartment. 
 
 God Bless, 
 
 GregS <>< 
  




That's my recollection too, that there's a cover. But is there actually a DIP 
switch under there? Can't recall, and the box of TPDD's is on a high shelf :-)
-- John.

Re: [M100] Tandy Portable Disk Drive 2

2022-11-14 Thread John R. Hogerhuis

On Mon, Nov 14, 2022 at 11:59 AM Greg Swallow  wrote:

> Oh my. Checked for cover and assumed DIP under it as the TPDD1 I once had.
> Opened the TPPD2 lid to expose bright shiney shield. No DIP switches. Never
> had to change anything so never opened it before now.
>
>
And my recollection is that means short of somehow populating the DIP
(which may or may not work) you're locked at 19200bps on the TPDD-2. The
TPDD-1 is actually a rebadged Brother FB-100. The FB-100 has the dip
switches, but defaults to 9600bps which the Brother Knitting machine
devices are locked to. So although TPDD-1's can be used with Brother
Knitting Machines, the TPDD-2 cannot.

-- John.

Re: [M100] Tandy Portable Disk Drive 2

2022-11-14 Thread Greg Swallow

Yes indeed. TPDD2 does have a little cover for the DIP switch. Just flip it 
over, it's just the other side from the battery compartment.

God Bless,

GregS <><

Nov 14, 2022 9:42:45 AM Charlie Hoey :

> Not sure if the TPDD2 model has dip switches, but perhaps they're in the 
> wrong setting?

Re: [M100] Tandy Portable Disk Drive 2