[M100] Model 100 Speed Mod on Hackaday

[Darren Clark]

The speed mod made it to Hackaday.

https://hackaday.com/2024/02/18/doubling-the-cpu-speed-of-the-trs-80-model-100-with-a-mod-board/

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

[Darren Clark]

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


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


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

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

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



Darren Clark




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


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


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


Here is some of the logic:

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


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

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

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

Index    Command    Function

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

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


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



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


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




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


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

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

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


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

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

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

The tpdd2 backup.ba <http://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 5

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

[Darren Clark]

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


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

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


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


E1 = ??

E2 = ??

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


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



Daren Clark


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

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

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


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


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

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

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

Steve





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

Thanks Darren.

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

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

Steve

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

[Darren Clark]

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


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


;--
;I/O ports
;Port.Bit    I/O        Pin#    ID    Function
;--
;Port1.B0    Input    Pin18    P10    CTS
;Port1.B1    Input    Pin19    P11    DSR
;Port1.B2    Output    Pin20    P12    RTS
;Port1.B3    Output    Pin22    P13    DTR
;Port1.B4    Output    Pin23    P14    Alarm
;Port1.B5    Output    Pin24    P15    WC on R/W module
;Port1.B6    Output    Pin25    P16    Drives LED1
;Port1.B7    Output    Pin26    P17    Scan

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

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

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

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

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



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

Thanks Darren.

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


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

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

Steve






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

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

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

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

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

Some other interesting tables are at 0xFF67 and 0xFF6D

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

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

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

[Darren Clark]

o 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]    [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

[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

[Darren Clark]

 decode the functionality. 
As i figure out more I'll update my GitHub and this list.



Darren Clark


On 1/24/24 19:36, Brian K. White wrote:
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?

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

[Darren Clark]

Awesome!

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


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


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


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


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


Darren Clark




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

128 more bytes ;)

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


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

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

Hello Steve,

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

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

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

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

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

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

Darren Clark


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

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. Steve


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

TPDD2 firmware dumping - breaking this into a new thread.

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

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

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

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

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

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


Darren Clark


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

;--
;Memory Map of PDD (using mode 6):
;--
;-001F    Internal Registers (see below)
;0080-00FF    Internal RAM
;4000-4003    CPLD (Glue Logic + Hardware IO Control)
;8000-87FF    External RAM (2K)
;F000-    Internal ROM (4K)
;--
;I/O ports
;Port.Bit    I/O        Pin#    ID    Function
;--
;Port1.B0    Input    Pin18    P10    CTS
;Port1.B1    Input    Pin19    P11    DSR
;Port1.B2    Output    Pin20    P12    RTS
;Port1.B3    Output    Pin22

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

[Darren Clark]

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




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

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

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


these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. Steve


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

TPDD2 firmware dumping - breaking this into a new thread.

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

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

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

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

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

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


Darren Clark


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

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

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

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

[Darren Clark]

Hello Steve,

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


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



Darren Clark


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

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. Steve


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

TPDD2 firmware dumping - breaking this into a new thread.

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

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

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

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

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

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


Darren Clark


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

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

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

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

[Darren Clark]

Hello Steve,

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


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


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


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


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


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

Darren Clark


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

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. Steve


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

TPDD2 firmware dumping - breaking this into a new thread.

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

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

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

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

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

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


Darren Clark


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

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

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

Re: [M100] NEC 8201 with unknown mod

[Darren Clark]

It is a very basic 300 BAUD modem built into the case and wired up to 
unused pins on the RS232 connector where a custom phone line adapter 
plug would be used.


The MN74HC943N is a 300 BAUD modem chip 
https://www.digchip.com/datasheets/parts/datasheet/321/MM74HC943N.php


The NM80C98N is a 3 state hex inverter


Darren Clark


On 1/10/24 20:05, David Plass wrote:

Hi all,
I just bought an NEC 8201 and it has a strange mod inside: there's a 
daughterboard on top of the motherboard with 5 or 6 alligator clips 
attached to various spots on the board including 3 or 4 on the RS-232 
connector.


For more details, I published a video to see what I'm talking about: 
https://www.youtube.com/watch?v=Q7G7Ozaf_mk


Does anyone know what this is?

-David

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

[Darren Clark]

TPDD2 firmware dumping - breaking this into a new thread.

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


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


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


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


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

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



Darren Clark


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

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

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

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

[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] Photo from ARRL handbook or QST article for Model 100 packet radio

[Darren Clark]

I found this a while ago, Tandy 200 being used with some kind of SAT 
uplink hardware


https://www.reddit.com/r/retrobattlestations/comments/nrap9n/tandy_200_in_the_field/


Darren Clark



On 5/6/22 01:11, Douglas Quagliana wrote:
I'm looking for a photo which was probably published in the ARRL 
handbook or perhaps in an issue of QST showing a Model 100 being used 
with a TNC for (I think) Field Day packet radio.  There might also 
have been a large solar panel.

This was probably in the mid-to-late 1980s.

Does anyone know what year's ARRL Handbook or what issue of QST this 
might have been published in?


Thanks,
Douglas

Re: [M100] TPDD service manual

[Darren Clark]

I think an Arduino (328P) would have enough horsepower to emulate the 
TPPD protocol and read/write to a SD card. Could probably even burn the 
utilities disk image to the 328P and start it up in "utilities" mode to 
download the disk manager to the 100 or 200.




On 3/20/21 6:58 AM, Stephen Adolph wrote:

this is quite interesting, and nice detective work.
It would seem like an interesting use case here could be to modify 
this firmware to make it target a standard 1.44MB floppy disk drive.
Maybe it would seem a bit backwards because SD cards are more 
mainstream, but still interesting to think about.


I see you have the disassembly in place.

On Fri, Mar 19, 2021 at 8:36 PM Darren Clark <mailto:biggran...@gmail.com>> wrote:


There are 2 memory modes on that processor, Mode0 which uses the
internal RAM and ROM (which is how the PDD is being used), and
Mode 1 which addresses external memory and masks the internal ROM.
The modes are selected at startup and can't be switched until the
chip is reset.

I used an internal function of the PDD ROM to place a small ASM
program into RAM and then execute it, which then read the ROM and
output the contents to the UART of the chip. I do not know if this
attack vector is present on the PDD2. Judging by the fact that the
PDD1 uses almost 100% of the ROM (only 6 unused bytes out of 4K),
that function may have been removed to allow for new functions on
the PDD2.

Attack vector described here:


https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.INFO

https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.ASM


For the PDD2 I would use probably a timing or glitch attack with
external memory (read only); make the address 0x0100 to 0xE000 all
NOPs with the code to initialize the UART, read the ROM, and send
it to the UART between 0xE001 and 0xEFFF. With a bunch of timing
and reset glitches it's possible to get the processor to start
executing code somewhere between 0x0100 and 0xE000 and fly through
all the NOPs until it hits the payload. In the release notes it
states that location 0xFFFE and 0x (which store the reset
vector) may get read externally in Mode0. I would also hard code
these address with a reset vector to point to 0xE001, that way if
a glitch forced a reset in Mode0 but accidentally read the
external memory it would jump to the payload and run it.

But for all this to work I would need to remove the processor from
the board and put it onto a new PCB so I could have control over
the clock, power, mode, and reset pins, and connect it to a
suitable external memory. That is why I'm looking for a
not-working PDD2 with a working processor.


Darren Clark



On 3/19/21 7:18 PM, Stephen Adolph wrote:

I wonder if there is a way to boot that processor off of external
memory, such that the firmware could be extracted...

    On Friday, March 19, 2021, Darren Clark mailto:biggran...@gmail.com>> wrote:

That is awesome to see! I was hoping it would talk a little
more about the firmware running on the HD63A01, but the
information on the pinout of the gate array chip is
interesting and matches up pretty well with what I reverse
engineered from the firmware.

I'll have to revisit my reverse engineering of the firmware
on the TPDD and see if there is anything to update with this
new information. Looks like the returned error codes may be
something to add.

Here is a link to the firmware I pulled and decoded from the
PDD1:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM

And the whole project: https://github.com/BiggRanger/Tandy_PDD

Maybe if someone has a bad TPDD2 or 2 I can try to get the
    firmware off of that too.

Darren Clark





On 3/18/21 9:59 PM, Brian K. White wrote:

On 3/18/21 8:31 PM, Joshua O'Keefe wrote:

On Mar 18, 2021, at 5:13 PM, Stephen Adolph
mailto:twospru...@gmail.com>
<mailto:twospru...@gmail.com
<mailto:twospru...@gmail.com>>> wrote:

so I did it brute-force.

https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual

<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>


In the interest of preservation and putting our eggs
in multiple baskets, I have mirrored this file to my
S3 bucket


Similarly I put it in archive.org <http://archive.org>

Re: [M100] TPDD Service Manual

[Darren Clark]

Hello Charles, Stephen,

    I would be interested in a TPDD-2 PCB. FYI, the processor would 
have to be un-soldered from the PCB and soldered to another PCB 
(break-out board) to address the new external memory and be able to 
glitch the power, clock, and mode pins. But I would be more than happy 
to put it back on the original PCB again and ship everything back to 
you. The whole process isn't without risks, that is why I'm looking for 
a not-working TPDD-2 in hoped that it is the power supply or a 
mechanical issue and not a bad processor. I would hate to ruin a good 
working PPD; actually I would probably refuse to do this to a good 
working TPPD-2.


If you're still interested in contributing to the better understating of 
the inner working of the TPPD-2, drop me an e-mail and we can discuss it 
further.



Darren Clark



On 3/20/21 6:40 AM, Charles Hudson wrote:

Darren, Stephen:

I have a TPDD-1 and a TPDD-2.  Both are basket cases.  I had hoped to 
resurrect one or the other but in the interest of the general good you 
are welcome to cannibalize either, on condition that you at least 
return the parts to me when you are finished.


If you are interested you can email me or respond here.

-CH-

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 
	Virus-free. www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 

Re: [M100] TPDD service manual

[Darren Clark]

There are 2 memory modes on that processor, Mode0 which uses the 
internal RAM and ROM (which is how the PDD is being used), and Mode 1 
which addresses external memory and masks the internal ROM. The modes 
are selected at startup and can't be switched until the chip is reset.


I used an internal function of the PDD ROM to place a small ASM program 
into RAM and then execute it, which then read the ROM and output the 
contents to the UART of the chip. I do not know if this attack vector is 
present on the PDD2. Judging by the fact that the PDD1 uses almost 100% 
of the ROM (only 6 unused bytes out of 4K), that function may have been 
removed to allow for new functions on the PDD2.


Attack vector described here:

https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.INFO

https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.ASM


For the PDD2 I would use probably a timing or glitch attack with 
external memory (read only); make the address 0x0100 to 0xE000 all NOPs 
with the code to initialize the UART, read the ROM, and send it to the 
UART between 0xE001 and 0xEFFF. With a bunch of timing and reset 
glitches it's possible to get the processor to start executing code 
somewhere between 0x0100 and 0xE000 and fly through all the NOPs until 
it hits the payload. In the release notes it states that location 0xFFFE 
and 0x (which store the reset vector) may get read externally in 
Mode0. I would also hard code these address with a reset vector to point 
to 0xE001, that way if a glitch forced a reset in Mode0 but accidentally 
read the external memory it would jump to the payload and run it.


But for all this to work I would need to remove the processor from the 
board and put it onto a new PCB so I could have control over the clock, 
power, mode, and reset pins, and connect it to a suitable external 
memory. That is why I'm looking for a not-working PDD2 with a working 
processor.



Darren Clark



On 3/19/21 7:18 PM, Stephen Adolph wrote:
I wonder if there is a way to boot that processor off of external 
memory, such that the firmware could be extracted...


On Friday, March 19, 2021, Darren Clark <mailto:biggran...@gmail.com>> wrote:


That is awesome to see! I was hoping it would talk a little more
about the firmware running on the HD63A01, but the information on
the pinout of the gate array chip is interesting and matches up
pretty well with what I reverse engineered from the firmware.

I'll have to revisit my reverse engineering of the firmware on the
TPDD and see if there is anything to update with this new
information. Looks like the returned error codes may be something
to add.

Here is a link to the firmware I pulled and decoded from the PDD1:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM
<https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM>

And the whole project: https://github.com/BiggRanger/Tandy_PDD
<https://github.com/BiggRanger/Tandy_PDD>

Maybe if someone has a bad TPDD2 or 2 I can try to get the
    firmware off of that too.

Darren Clark





On 3/18/21 9:59 PM, Brian K. White wrote:

On 3/18/21 8:31 PM, Joshua O'Keefe wrote:

On Mar 18, 2021, at 5:13 PM, Stephen Adolph
mailto:twospru...@gmail.com>
<mailto:twospru...@gmail.com
<mailto:twospru...@gmail.com>>> wrote:

so I did it brute-force.
https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual

<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual

<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>>


In the interest of preservation and putting our eggs in
multiple baskets, I have mirrored this file to my S3 bucket


Similarly I put it in archive.org <http://archive.org>

Re: [M100] TPDD service manual

[Darren Clark]

That is awesome to see! I was hoping it would talk a little more about 
the firmware running on the HD63A01, but the information on the pinout 
of the gate array chip is interesting and matches up pretty well with 
what I reverse engineered from the firmware.


I'll have to revisit my reverse engineering of the firmware on the TPDD 
and see if there is anything to update with this new information. Looks 
like the returned error codes may be something to add.


Here is a link to the firmware I pulled and decoded from the PDD1: 
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM


And the whole project: https://github.com/BiggRanger/Tandy_PDD

Maybe if someone has a bad TPDD2 or 2 I can try to get the firmware off 
of that too.


Darren Clark





On 3/18/21 9:59 PM, Brian K. White wrote:

On 3/18/21 8:31 PM, Joshua O'Keefe wrote:
On Mar 18, 2021, at 5:13 PM, Stephen Adolph <mailto:twospru...@gmail.com>> wrote:

so I did it brute-force.
https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual 
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>


In the interest of preservation and putting our eggs in multiple 
baskets, I have mirrored this file to my S3 bucket


Similarly I put it in archive.org

Re: [M100] TPDD service manual

[Darren Clark]

That is awesome to see! I was hoping it would talk a little more about 
the firmware running on the HD63A01, but the information on the pinout 
of the gate array chip is interesting.


I'll have to revisit my reverse engineering of the firmware on the TPDD 
and see if there is anything to update.


https://github.com/BiggRanger/Tandy_PDD

Darren Clark



On 3/18/21 9:59 PM, Brian K. White wrote:

On 3/18/21 8:31 PM, Joshua O'Keefe wrote:
On Mar 18, 2021, at 5:13 PM, Stephen Adolph <mailto:twospru...@gmail.com>> wrote:

so I did it brute-force.
https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual 
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>


In the interest of preservation and putting our eggs in multiple 
baskets, I have mirrored this file to my S3 bucket


Similarly I put it in archive.org

Re: [M100] Back in the hospital yet again

[Darren Clark]

Ken,

   Wishing you all the best, take care, rest, and let the doctors do 
their magic!




On 11/9/20 9:37 PM, Kenneth Pettit wrote:

Hey gang,

Well I’m back in the hospital again with angina and shortness of breath.  
Hopefully it will be just. A couple of days for a stent or two and then home 
again.  Will let you know.

Ken

Sent from my iPhone

Re: [M100] Back in the hospital yet again

[Darren Clark]

Ken,

   Wishing you all the best, take care, rest, and let the doctors do 
their magic!






On 11/9/20 9:37 PM, Kenneth Pettit wrote:

Hey gang,

Well I’m back in the hospital again with angina and shortness of breath.  
Hopefully it will be just. A couple of days for a stent or two and then home 
again.  Will let you know.

Ken

Sent from my iPhone

[M100] Memory prices...

[Darren Clark]

Thinking about bumping my laptop from 16GB to 32GB, 2x 8GB DDR3 RAM is 
$49.99. No, too expensive


Thinking back to this weekend... 2x 24KB modules for my Tandy 200 on 
eBay for $46.64, PURCHASE! I'll get them Friday (I hope).



It's interesting where the priorities are.



Darren Clark

Re: [M100] RS232 IO BASIC question

[Darren Clark]

Thank you very much! It's working now, I can ask for a status and 
receive the reply!


Darren Clark




On 8/5/20 10:36 AM, Ron Lauzon wrote:

You can have the COM port open for both input and output at the same time.

I did a TPDD-ish experiment a while ago and wrote some BASIC programs 
to work with it.


Example:
https://github.com/rlauzon54/rdos/blob/master/Clients/RLIST.BA

--
Weblog: http://ronsapartment.blogspot.com/

TRS-80 Pocket Computer 2 - TRS-80 Pocket Computer 4 - TRS-80 Model 
100/102 - Tandy 1100FD - Tandy 1400LT - Commodore 64 - TRS-80 Model 4P
RC2014 (Mini and Pro) - Altair-Duino with TI Silent 700 - VT320 
terminal/Raspberry Pi 0
Some people like to work on old cars.  But old computers are cheaper 
and don't require a big garage.




Aug 5, 2020, 09:57 by biggran...@tds.net:

Hello Everybody,

  I have a quick question about serial IO. I have a serial
plotter connected to my 200 and have been sending commands to it,
but I haven't been able to read responses back. I posed it here
(only sending commands):

https://pay.reddit.com/r/retrobattlestations/comments/i3ol8w/we_dont_get_enough_working_pen_plotters_here_so/
if you want to see it working.

This is the code for sending commands to the plotter:

5 F$ = "COM:88N1ENN"
10 OPEN F$ FOR OUTPUT AS 1
20 PRINT #1, "IN"
30 PRINT #1, "SV1"
40 PRINT #1, "EC"
50 PRINT #1, "AS4"
60 PRINT #1, "LB++1050HELLO REDDIT"
70 PRINT #1, "LB++0900/U/BiggRanger"
80 PRINT #1, "LB++0750/August4,2020/"


I want to read responses back, I've tried closing the port and
then opening as "FOR INPUT", but that isn't working. I think it
may be clearing the input buffer when opening the port.

I want to create a subroutine the sends a command to check the
status of the plotter, receive the string back and parse it to see
if the plotter is busy and keep looping until it's not busy, or
there is an error. I just can't figuer out sending and receiving
over serial with the 200.


Darren Clark

[M100] RS232 IO BASIC question

[Darren Clark]

Hello Everybody,

  I have a quick question about serial IO. I have a serial plotter 
connected to my 200 and have been sending commands to it, but I haven't 
been able to read responses back. I posed it here (only sending 
commands): 
https://pay.reddit.com/r/retrobattlestations/comments/i3ol8w/we_dont_get_enough_working_pen_plotters_here_so/ 
if you want to see it working.


This is the code for sending commands to the plotter:

5 F$ = "COM:88N1ENN"
10 OPEN F$ FOR OUTPUT AS 1
20 PRINT #1, "IN"
30 PRINT #1, "SV1"
40 PRINT #1, "EC"
50 PRINT #1, "AS4"
60 PRINT #1, "LB++1050HELLO REDDIT"
70 PRINT #1, "LB++0900/U/BiggRanger"
80 PRINT #1, "LB++0750/August4,2020/"


I want to read responses back, I've tried closing the port and then 
opening as "FOR INPUT", but that isn't working. I think it may be 
clearing the input buffer when opening the port.


I want to create a subroutine the sends a command to check the status of 
the plotter, receive the string back and parse it to see if the plotter 
is busy and keep looping until it's not busy, or there is an error. I 
just can't figuer out sending and receiving over serial with the 200.



Darren Clark

Re: [M100] CCR-82

[Darren Clark]

I ordered all my belts from here: https://www.turntableneedles.com/

Darren


On 4/25/20 3:37 AM, Jonathan Yuen wrote:

Hello,

Just out of curiosity, where does one order belts for an old cassette tape 
recorder?  I have a Superscope CD-320 and while it works (mostly) OK, the belt 
for the little counter has stretched to the point where that doesn't work 
anymore.  I imagine the other belts will eventually go.  I've been using it to 
digitize some old recordings but the lack of the counter is annoying but not 
fatal.

Jonathan

jonathan.y...@mykopat.slu.se

Från: M100 [m100-boun...@lists.bitchin100.com] för me [m...@scifidan.com]
Skickat: den 25 april 2020 00:32
Till: m100@lists.bitchin100.com
Ämne: [M100] CCR-82

I just ordered this

https://www.ebay.com/itm/143565229494

Also ordered a bag of 80 or so tape belts of various sizes.

I'll replace the belts but I'm also sure the caps will be replacing.
Anyone sell cap kits for it? I'm going to look for the service manual.

If I can't get it working, it'll be used for parts. He had a cheaper
shipping method available so I took the plunge.

---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 

E-mailing SLU will result in SLU processing your personal data. For more information 
on how this is done, click here 

Re: [M100] CCR-82

[Darren Clark]

I have a CCR-81 and a CCR-82, both are running great with only replacing 
the belts. Audio is just fine and my Model 200 can load programs off of 
30+ year old cassette tapes.


Darren




On 4/24/20 9:17 PM, Doug Jackson wrote:

I'm not confident that the capacitors will need replacing.

There are two factors at play here.

Firstly... in the PC era a major manufacturer of capacitors had a 
failed run with a stolen electrolyte.  That caused major issues for 5 
or so years as devices failed with cap issues.


That's not normal.  I've got audio gear from the 70s and 80s that is 
running beautifully.   Built long before the 2000s cap manufacturing 
issues.


Secondly... It's normal to replace caps in valve gear... It's also 
normal to replace the carbon composition resistors in them as well.  
It turns out that components made in the 40s and 50s didn't have the 
longevity.


My advice is to replace the belt and run the device first.  Don't do 
work unless it's needed.


Doug


On Sat, 25 Apr. 2020, 8:45 am B4 Me100, > wrote:


Here is a link to the service manual:
https://colorcomputerarchive.com/repo/Documents/Manuals/Hardware/CCR-82%20S
ervice%20Manual%20(Tandy

).pdf


On 24/4/20, 3:32 PM, "M100 on behalf of me"
mailto:m100-boun...@lists.bitchin100.com> on behalf of
m...@scifidan.com > wrote:

>
>I just ordered this
>
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ebay
>.com%2Fitm%2F143565229494&data=02%7C01%7C%7C5cf9354759674f4823f208d7e8
>9f6d81%7C84df9e7fe9f640afb435%7C1%7C0%7C637233643739084075&
>;sdata=dlQYKVcY2MkgDLu7XxRZOfJWdwUc6ZKyErBbYkQqt1w%3D&reserved=0
>
>Also ordered a bag of 80 or so tape belts of various sizes.
>
>I'll replace the belts but I'm also sure the caps will be replacing.
>Anyone sell cap kits for it? I'm going to look for the service
manual.
>
>If I can't get it working, it'll be used for parts. He had a cheaper
>shipping method available so I took the plunge.
>

Re: [M100] replacement Molex 8878 socket?

[Darren Clark]

I remember a discussion a year or 2 back about 3D printing them.

Someone posted files on ThingiVerse here -> 
https://www.thingiverse.com/thing:3821586







On 3/7/20 4:42 PM, Dave Everett wrote:

On 8/03/2020 8:27 am, Brian K. White wrote:

On 3/7/20 11:22 AM, Stephen Adolph wrote:
hi, has anyone ever come across a supplier today for the ModelT 
optrom socket, the Molex 8878?

I could use a few new ones.
thanks,
Steve


I scored a load of about 100 of them on ebay a couple years ago. I 
have been giving them to whoever needs them for any use I consider 
legitimate like that.


IE, they aren't replaceable, so, I won't just consume them for 
something dumb, but for repairs of old machines and maybe a small 
number of programming jigs or something. I gave some to a museum to 
have in inventory for repairs. If I die and still have 75 of them and 
someone else keeps them and dies with still having 60 of them, and so 
they are available for repairs for the longest time possible, and 50 
years from now there is still a box of 50 of them... that is my ideal 
goal.



Hi Brian, I have been looking for one of these to make a basic rom for 
my PX-8.  Would you be prepared to send one to Australia?


If so lease let me know how much you want including shipping.

Thanks,

Dave Everett

Sydney, NSW Australia

Re: [M100] Article I wrote on a Tandy 102

[Darren Clark]

"hi club 100!"

Love it, great article!

Thanks for sharing.


On 12/1/19 11:57 AM, Mitch Parker wrote:

Good afternoon!

I write monthly for CSO Online, and was able to write a large chunk of 
my July blog on my 102.


It's about data conversion and the challenges we face with legacy data 
and systems.


I even took a picture of mine in my office uploading the text.

You can find it here:

https://www.csoonline.com/article/3407703/stranger-things-data-provenance-intelligent-systems-and-data-conversion.html 



Have a great week and holiday season!

Mitch