Difference between revisions of "TPDD Design Notes"

From Bitchin100 DocGarden
Jump to: navigation, search
m
Line 47: Line 47:
 
  </UL>
 
  </UL>
 
</UL>
 
</UL>
 +
 +
== Update: Work Completed! ==
 +
 +
[[:file:PDD Reverse Engineering.zip|PDD Reverse Engineering]]
  
 
[[Category:Model T Developer Reference]]
 
[[Category:Model T Developer Reference]]

Revision as of 22:45, 29 November 2016

The initial purpose is to document an effort to reverse engineer the TPDD and TPDD-2, in order to get a better understanding of the protocols that they support.

Major silicon components

According to the schematics of the TPDD and TPDD-2, the major components of interest are:

  • HD6301: CPU (a 6800 derivative with 128 bytes of onboard RAM, 4K of onboard ROM and a UART). Datasheet: Media:Hd6301.pdf‎
  • uPD449G (TPDD) / HM6117 (TPPD-2): RAM
  • uPD65002: CMOS Gate Array

Initial Thoughts

The idea for dumping the ROM of the TPDD came from the IPL boot code of the TPDD (need to check that this is the same for TPDD-2):

10 OPEN "COM:88N1DNN" FOR OUTPUT AS #1
20 PRINT #1, "S10985157C00AD7EF08B3AS901FE"
30 LOAD "COM:88N1ENN", R

It was noted that line 20 is S Record format, and breaks down as:

S1 09 8515 7C 00 AD 7E F0 8B 3A 
S9 01 FE

which translates to "starting at address 8515, load the bytes 7C 00 AD 7E F0 8B", then terminate. Note that the termination record ("S9") is shorter than normal as it is missing the address component (possibly legal, but unusual).

The BASIC program then loads a program from the serial port (in this case, attached TPDD).

Given that we know the CPU type of the TPDD, disassembling those bytes gives:

8515 INC  $00AD
8518 JMP  F08B

These locations match up with what is known from the datasheet of the HD6301 (internal RAM maps from $0080 to $00FF, internal ROM maps from $F000 to $FFFF).

The question is, what else could we do with that line 20? Could we possibly coerce the TPDD into spilling its ROM contents over the serial port?

Current thoughts on plans of attack are:

  • Seeing how much wiggle room there is in the boot code space (i.e. how much extra can we upload?)
  • How the uploaded boot code interacts with the boot sequence
    • at what point does the uploaded code get executed? Are we patching a known location that the ROM calls? (is location 8515 magical?)?
    • (partly related to above) what triggers the execution? On receipt of the S9 record?
    • what is the significance of address $00AD?

Update: Work Completed!

PDD Reverse Engineering