TPDD Design Notes - Revision history

Jhoger: /* Update: Work Completed! */

2016-11-30T06:50:39Z

Update: Work Completed!

← Older revision		Revision as of 23:50, 29 November 2016
Line 51:		Line 51:

	[[:file:PDD Reverse Engineering.zip\|PDD Reverse Engineering]]		[[:file:PDD Reverse Engineering.zip\|PDD Reverse Engineering]]

			From Darren Clark:

			Hello all,
			I see on the Wiki that someone was working on trying to dump the ROM on the PDD, but that page was last updated in 2009. Well I took the challenge and wrote this little program to try it.

			I've also posted the S-REC too so anybody can try it. In order to get the S-REC to work do the following:

			# Switch your PDD to 9600 BUAD, the switches on the bottom need to be set to ON.
			# Connect your PDD to a PC and connect with Hyper Terminal or another terminal program.
			# Settings are 9600-8-n-1, no flow control. Set the line delay and character delay to 20mS, otherwise we're pushing data to the CPU too fast and will get a blinking light.
			# Paste each line of the S-REC into the terminal program, but do not include the CR/LF (i.e. only highlight the text).
			# If the Low Battery light starts blinking, start over because something bad happened (like accidently included a CR/LF).
			# When the last line is pasted "S901FE", this triggers the program running in the ROM to jump to address 0x8515 and execute the program
			# The ROM (F000-FFFF) is now dumped to the terminal program in the following format:
			<pre>
			F000:0F 8E 87 FF 86 FC 97 00
			F008:86 34 97 02 86 FF 97 04
			F010:97 05 86 A0 B7 40 00 F6
			F018:40 01 C4 F0 37 54 54 54
			F020:54 CE FF B7 3A A6 00 97
			F028:80 B7 40 01 86 10 97 01
			F030:86 0C 97 10 86 0A 97 11
			F038:CE 00 81 CC 00 7F BD F9
			F040:AD 72 FF 86 C6 64 BD F9
			F048:BC BD F4 51 33 C1 D0 24
			</pre>

			Darren Clark.


	[[Category:Model T Developer Reference]]		[[Category:Model T Developer Reference]]

Jhoger at 06:45, 30 November 2016

2016-11-30T06:45:20Z

New page

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:

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

== 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 [http://en.wikipedia.org/wiki/S-record 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:

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

== Update: Work Completed! ==

[[:file:PDD Reverse Engineering.zip|PDD Reverse Engineering]]

[[Category:Model T Developer Reference]]

Jhoger at 08:17, 27 February 2009

2009-02-27T08:17:13Z

New page

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:

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

== 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 [http://en.wikipedia.org/wiki/S-record 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.

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:

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

[[Category:Model T Developer Reference]]