Re: [M100] TPDD service manual

[Brian White]

Nope.

I think it's Mark J. Blair, aka Stardust on OSHPark, who has posted about
these similar boards once or twice here on the list. It doesn't look like
it's one of these boards, but a new version that isn't public. The new one
uses a through hole db25 mounted flat on the pcb like MounT. And none of
these are like that.

https://oshpark.com/profiles/Stardust/

So it looks like he's aiming to sell these so there are no plans or code,
and if it's not quite ready for sale yet then there is no purchase site yet
either.

Which now that think about it, when he posted about it to the list before,
he said he started with dlplus and then highly modified it. Which means
he's obligated to post his code somewhere because dlplus is gpl.

-- 
bkw

On Sat, Mar 20, 2021, 11:03 PM Kurt McCullum  wrote:

> That is very cool! Do you have a link to the actual project.
>
> On Sat, Mar 20, 2021, at 5:25 PM, Brian K. White wrote:
>
> Someone else is just finishing a different approach where he designed a
> custom board with everything including the mcu.
>
>
> https://www.facebook.com/groups/Model.T.Computers/permalink/4297639010296577
>
> --
> bkw
>
>
>

Re: [M100] TPDD service manual

[Kurt McCullum]

That is very cool! Do you have a link to the actual project.

On Sat, Mar 20, 2021, at 5:25 PM, Brian K. White wrote:
> Someone else is just finishing a different approach where he designed a 
> custom board with everything including the mcu.
> 
> https://www.facebook.com/groups/Model.T.Computers/permalink/4297639010296577
> 
> -- 
> bkw
> 

Re: [M100] TPDD service manual

[Brian K. White]

On 3/20/21 7:56 PM, Darren Clark wrote:
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.


There are already a couple such projects.

I did one based on the idea of using an off-the-shelf microcontroller 
dev board that already has an sd card reader and uarts and lipo battery 
manager built in (and/or getting power from the BCR port), and the only 
part you have to make is just enough adapter to attach the dev board to 
the 100 (a pcb with a db25 and max3232 and caps). The idea was to make 
it where you can build it yourself because the part you build is 
limited. It does tpdd emulation including a bootstrap mode to install a 
dos. It's a bit shaky still but the basics are there & working.


https://youtu.be/LTtkjnuTSZw


Someone else is just finishing a different approach where he designed a 
custom board with everything including the mcu.


https://www.facebook.com/groups/Model.T.Computers/permalink/4297639010296577

--
bkw

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 > 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>
>> wrote:

so I did it brute-force.

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]

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-

 
	Virus-free. www.avg.com 
 

Re: [M100] TPDD service manual

[Brian White]

ah ok thanks

On Sat, Mar 20, 2021, 9:59 AM Jeffrey Birt  wrote:

> It is not that it is just ‘less sensitive’. I’m really stretching my
> memory from the research I did on the subject here but as I recall the
> composition of the coating of the disk is different (something like the
> particle size of the ferrous material being smaller). To flip the domain on
> this new HD coating requires a stronger magnetic field. The DD drive cannot
> output a strong enough magnetic field to properly magnetize the new HD
> coating.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Brian
> White
> *Sent:* Saturday, March 20, 2021 8:49 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> Not that it changes anything, but I thought the problem with the density
> difference was that the lower density drive would put out a stronger signal
> needed for the less sensitive media, and so the problem with using hd media
> in a dd drive would be that the dd drive would overdrive the media making a
> distorted signal?
>
>
>
> Is it actually  the opposite, that the way they achieved higher density is
> by using less sensitive media driven by a stonger head?
>
>
>
> On Sat, Mar 20, 2021, 8:35 AM Jeffrey Birt  wrote:
>
> Oh, sorry I misread what you wrote. But to your point, that could be done.
> I use a SuperCard Pro to image floppies which is just a PIC uC with
> supporting HW and some spiffy firmware/software. It can image TPDD1/2 disks
> easily using a standard 3.5” 1.44MB drive. The software does know how to
> interpret the data, it is just a flux map. The .SCP format is well
> documented though so one could figure out how to recreate the disk file
> structure from it.
>
> There is a similar device called the Flux Engine that has already done the
> file system decoding and can image/interpret TPDD disks using a standard
> 3.5” 1.44MB drive.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 7:28 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> not exactly the point I was trying to make.
>
> pretty clearly a TPDD1 cannot use an HD floppy.
>
> but a small microcontroller that speaks TPDD protocol and has integrated
> FDC function could interface with a modern FDD.
>
> ..steve
>
>
>
> On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt 
> wrote:
>
> High density disks, both 3.5 and 5.25, require a much higher flux level to
> write. A system designed for DD disks will not be able to write to them
> reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for
> example only to find that it reads for a while but after a few weeks or
> months it no longer does. You can generally write to lower density disks
> with a HD drive. The exception being that it is best to write 360K
> 5.25”disks with a 360K drive as the head on these drives was physically
> larger and the narrower track written by a higher density drive may not
> work well on all 360K drives.
>
> My take on the TPDD is that it was designed to be cheap (simple) and
> portable. Thus, they used a simple 8-bit micro to control everything and
> not one of the floppy disc controller ASICs that were available at that
> time. But, they wound up with something that would run on AA batteries and
> use standard media at the time even if the storage capacity was limited.
>
>
>
> Jeff Birt
>
>
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 5:59 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> 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.
>
>
>
>

Re: [M100] TPDD service manual

[Jeffrey Birt]

It is not that it is just ‘less sensitive’. I’m really stretching my memory 
from the research I did on the subject here but as I recall the composition of 
the coating of the disk is different (something like the particle size of the 
ferrous material being smaller). To flip the domain on this new HD coating 
requires a stronger magnetic field. The DD drive cannot output a strong enough 
magnetic field to properly magnetize the new HD coating.

 

Jeff Birt

 

From: M100  On Behalf Of Brian White
Sent: Saturday, March 20, 2021 8:49 AM
To: m...@bitchin100.com
Subject: Re: [M100] TPDD service manual

 

Not that it changes anything, but I thought the problem with the density 
difference was that the lower density drive would put out a stronger signal 
needed for the less sensitive media, and so the problem with using hd media in 
a dd drive would be that the dd drive would overdrive the media making a 
distorted signal?

 

Is it actually  the opposite, that the way they achieved higher density is by 
using less sensitive media driven by a stonger head?

 

On Sat, Mar 20, 2021, 8:35 AM Jeffrey Birt mailto:bir...@soigeneris.com> > wrote:

Oh, sorry I misread what you wrote. But to your point, that could be done. I 
use a SuperCard Pro to image floppies which is just a PIC uC with supporting HW 
and some spiffy firmware/software. It can image TPDD1/2 disks easily using a 
standard 3.5” 1.44MB drive. The software does know how to interpret the data, 
it is just a flux map. The .SCP format is well documented though so one could 
figure out how to recreate the disk file structure from it.

There is a similar device called the Flux Engine that has already done the file 
system decoding and can image/interpret TPDD disks using a standard 3.5” 1.44MB 
drive.

 

Jeff Birt

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Stephen Adolph
Sent: Saturday, March 20, 2021 7:28 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] TPDD service manual

 

not exactly the point I was trying to make.

pretty clearly a TPDD1 cannot use an HD floppy.  

but a small microcontroller that speaks TPDD protocol and has integrated FDC 
function could interface with a modern FDD.

..steve

 

On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt mailto:bir...@soigeneris.com> > wrote:

High density disks, both 3.5 and 5.25, require a much higher flux level to 
write. A system designed for DD disks will not be able to write to them 
reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for example 
only to find that it reads for a while but after a few weeks or months it no 
longer does. You can generally write to lower density disks with a HD drive. 
The exception being that it is best to write 360K 5.25”disks with a 360K drive 
as the head on these drives was physically larger and the narrower track 
written by a higher density drive may not work well on all 360K drives.

My take on the TPDD is that it was designed to be cheap (simple) and portable. 
Thus, they used a simple 8-bit micro to control everything and not one of the 
floppy disc controller ASICs that were available at that time. But, they wound 
up with something that would run on AA batteries and use standard media at the 
time even if the storage capacity was limited.

 

Jeff Birt

 

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Stephen Adolph
Sent: Saturday, March 20, 2021 5:59 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] TPDD service manual

 

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.

 

Re: [M100] TPDD service manual

[Brian White]

Not that it changes anything, but I thought the problem with the density
difference was that the lower density drive would put out a stronger signal
needed for the less sensitive media, and so the problem with using hd media
in a dd drive would be that the dd drive would overdrive the media making a
distorted signal?

Is it actually  the opposite, that the way they achieved higher density is
by using less sensitive media driven by a stonger head?

On Sat, Mar 20, 2021, 8:35 AM Jeffrey Birt  wrote:

> Oh, sorry I misread what you wrote. But to your point, that could be done.
> I use a SuperCard Pro to image floppies which is just a PIC uC with
> supporting HW and some spiffy firmware/software. It can image TPDD1/2 disks
> easily using a standard 3.5” 1.44MB drive. The software does know how to
> interpret the data, it is just a flux map. The .SCP format is well
> documented though so one could figure out how to recreate the disk file
> structure from it.
>
> There is a similar device called the Flux Engine that has already done the
> file system decoding and can image/interpret TPDD disks using a standard
> 3.5” 1.44MB drive.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 7:28 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> not exactly the point I was trying to make.
>
> pretty clearly a TPDD1 cannot use an HD floppy.
>
> but a small microcontroller that speaks TPDD protocol and has integrated
> FDC function could interface with a modern FDD.
>
> ..steve
>
>
>
> On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt 
> wrote:
>
> High density disks, both 3.5 and 5.25, require a much higher flux level to
> write. A system designed for DD disks will not be able to write to them
> reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for
> example only to find that it reads for a while but after a few weeks or
> months it no longer does. You can generally write to lower density disks
> with a HD drive. The exception being that it is best to write 360K
> 5.25”disks with a 360K drive as the head on these drives was physically
> larger and the narrower track written by a higher density drive may not
> work well on all 360K drives.
>
> My take on the TPDD is that it was designed to be cheap (simple) and
> portable. Thus, they used a simple 8-bit micro to control everything and
> not one of the floppy disc controller ASICs that were available at that
> time. But, they wound up with something that would run on AA batteries and
> use standard media at the time even if the storage capacity was limited.
>
>
>
> Jeff Birt
>
>
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 5:59 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> 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.
>
>
>
>

Re: [M100] TPDD service manual

[Jeffrey Birt]

Oh, sorry I misread what you wrote. But to your point, that could be done. I 
use a SuperCard Pro to image floppies which is just a PIC uC with supporting HW 
and some spiffy firmware/software. It can image TPDD1/2 disks easily using a 
standard 3.5” 1.44MB drive. The software does know how to interpret the data, 
it is just a flux map. The .SCP format is well documented though so one could 
figure out how to recreate the disk file structure from it.

There is a similar device called the Flux Engine that has already done the file 
system decoding and can image/interpret TPDD disks using a standard 3.5” 1.44MB 
drive.

 

Jeff Birt

 

From: M100  On Behalf Of Stephen Adolph
Sent: Saturday, March 20, 2021 7:28 AM
To: m...@bitchin100.com
Subject: Re: [M100] TPDD service manual

 

not exactly the point I was trying to make.

pretty clearly a TPDD1 cannot use an HD floppy.  

but a small microcontroller that speaks TPDD protocol and has integrated FDC 
function could interface with a modern FDD.

..steve

 

On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt mailto:bir...@soigeneris.com> > wrote:

High density disks, both 3.5 and 5.25, require a much higher flux level to 
write. A system designed for DD disks will not be able to write to them 
reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for example 
only to find that it reads for a while but after a few weeks or months it no 
longer does. You can generally write to lower density disks with a HD drive. 
The exception being that it is best to write 360K 5.25”disks with a 360K drive 
as the head on these drives was physically larger and the narrower track 
written by a higher density drive may not work well on all 360K drives.

My take on the TPDD is that it was designed to be cheap (simple) and portable. 
Thus, they used a simple 8-bit micro to control everything and not one of the 
floppy disc controller ASICs that were available at that time. But, they wound 
up with something that would run on AA batteries and use standard media at the 
time even if the storage capacity was limited.

 

Jeff Birt

 

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Stephen Adolph
Sent: Saturday, March 20, 2021 5:59 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] TPDD service manual

 

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.

 

Re: [M100] TPDD service manual

[Stephen Adolph]

not exactly the point I was trying to make.
pretty clearly a TPDD1 cannot use an HD floppy.
but a small microcontroller that speaks TPDD protocol and has integrated
FDC function could interface with a modern FDD.
..steve

On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt  wrote:

> High density disks, both 3.5 and 5.25, require a much higher flux level to
> write. A system designed for DD disks will not be able to write to them
> reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for
> example only to find that it reads for a while but after a few weeks or
> months it no longer does. You can generally write to lower density disks
> with a HD drive. The exception being that it is best to write 360K
> 5.25”disks with a 360K drive as the head on these drives was physically
> larger and the narrower track written by a higher density drive may not
> work well on all 360K drives.
>
> My take on the TPDD is that it was designed to be cheap (simple) and
> portable. Thus, they used a simple 8-bit micro to control everything and
> not one of the floppy disc controller ASICs that were available at that
> time. But, they wound up with something that would run on AA batteries and
> use standard media at the time even if the storage capacity was limited.
>
>
>
> Jeff Birt
>
>
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 5:59 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> 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.
>
>
>

Re: [M100] TPDD service manual

[Jeffrey Birt]

High density disks, both 3.5 and 5.25, require a much higher flux level to 
write. A system designed for DD disks will not be able to write to them 
reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for example 
only to find that it reads for a while but after a few weeks or months it no 
longer does. You can generally write to lower density disks with a HD drive. 
The exception being that it is best to write 360K 5.25”disks with a 360K drive 
as the head on these drives was physically larger and the narrower track 
written by a higher density drive may not work well on all 360K drives.

My take on the TPDD is that it was designed to be cheap (simple) and portable. 
Thus, they used a simple 8-bit micro to control everything and not one of the 
floppy disc controller ASICs that were available at that time. But, they wound 
up with something that would run on AA batteries and use standard media at the 
time even if the storage capacity was limited.

 

Jeff Birt

 

 

From: M100  On Behalf Of Stephen Adolph
Sent: Saturday, March 20, 2021 5:59 AM
To: m...@bitchin100.com
Subject: Re: [M100] TPDD service manual

 

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.

Re: [M100] TPDD service manual

[Stephen Adolph]

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

[Stephen Adolph]

I have a tpdd2 board.  ;)

On Friday, March 19, 2021, Darren Clark  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  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 >>> > 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]

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 > 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>
>> wrote:

so I did it brute-force.
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

[Stephen Adolph]

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  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 >> > 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 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 > wrote:

so I did it brute-force.
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

[Stephen Adolph]

I do ... but it would not work for some reason.

On Thursday, March 18, 2021, John R. Hogerhuis  wrote:

> Ok. I thought you had a login since you do the Rex support through the
> wiki.
>
> On Thu, Mar 18, 2021, 5:14 PM Stephen Adolph  wrote:
>
>> John, couldn't make that work..login prevented.
>>
>> so I did it brute-force.
>> https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual
>>
>>
>>
>>
>> On Thu, Mar 18, 2021 at 7:43 PM John R. Hogerhuis 
>> wrote:
>>
>>> You have to be logged in to upload
>>>
>>> http://bitchin100.com/wiki/index.php?title=Special:Upload
>>>
>>> On Thu, Mar 18, 2021 at 4:15 PM Stephen Adolph 
>>> wrote:
>>>
 ah  good idea.  is there a files area?


 On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis 
 wrote:

> Very cool!
>
> You can upload it to Bitchin100 wiki. The File Uploads feature.
>
> -- John.
>
> On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph 
> wrote:
>
>> Via a user on facebook, the TPDD service manual has been found!
>> Who knew we would still be discovering documents in 2021.
>>
>> Need to make arrangements to post this at Club100.
>> It is too large to send to the mailing list..
>> Steve
>>
>>

Re: [M100] TPDD service manual

[John R. Hogerhuis]

Ok. I thought you had a login since you do the Rex support through the
wiki.

On Thu, Mar 18, 2021, 5:14 PM Stephen Adolph  wrote:

> John, couldn't make that work..login prevented.
>
> so I did it brute-force.
> https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual
>
>
>
>
> On Thu, Mar 18, 2021 at 7:43 PM John R. Hogerhuis 
> wrote:
>
>> You have to be logged in to upload
>>
>> http://bitchin100.com/wiki/index.php?title=Special:Upload
>>
>> On Thu, Mar 18, 2021 at 4:15 PM Stephen Adolph 
>> wrote:
>>
>>> ah  good idea.  is there a files area?
>>>
>>>
>>> On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis 
>>> wrote:
>>>
 Very cool!

 You can upload it to Bitchin100 wiki. The File Uploads feature.

 -- John.

 On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph 
 wrote:

> Via a user on facebook, the TPDD service manual has been found!
> Who knew we would still be discovering documents in 2021.
>
> Need to make arrangements to post this at Club100.
> It is too large to send to the mailing list..
> Steve
>
>

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 > wrote:

so I did it brute-force.
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

[Brian K. White]

On 3/18/21 8:31 PM, Joshua O'Keefe wrote:
On Mar 18, 2021, at 5:13 PM, Stephen Adolph > wrote:

so I did it brute-force.
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

--
bkw

Re: [M100] TPDD service manual

[Joshua O'Keefe]

On Mar 18, 2021, at 5:13 PM, Stephen Adolph  wrote:
> so I did it brute-force.
> 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

http://public.nachomountain.com/files/m100/ 

Re: [M100] TPDD service manual

[Jeffrey Birt]

Awesome, thanks for sharing.

 

Jeff Birt

 

From: M100  On Behalf Of Stephen Adolph
Sent: Thursday, March 18, 2021 7:14 PM
To: m...@bitchin100.com
Subject: Re: [M100] TPDD service manual

 

John, couldn't make that work..login prevented.

 

so I did it brute-force.

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

 

 

 

 

On Thu, Mar 18, 2021 at 7:43 PM John R. Hogerhuis mailto:jho...@pobox.com> > wrote:

You have to be logged in to upload

http://bitchin100.com/wiki/index.php?title=Special:Upload

 

On Thu, Mar 18, 2021 at 4:15 PM Stephen Adolph mailto:twospru...@gmail.com> > wrote:

ah  good idea.  is there a files area?

 

 

On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis mailto:jho...@pobox.com> > wrote:

Very cool!

You can upload it to Bitchin100 wiki. The File Uploads feature.

 

-- John.

 

On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph mailto:twospru...@gmail.com> > wrote:

Via a user on facebook, the TPDD service manual has been found!

Who knew we would still be discovering documents in 2021.

 

Need to make arrangements to post this at Club100.

It is too large to send to the mailing list..

Steve

 

Re: [M100] TPDD service manual

[Stephen Adolph]

John, couldn't make that work..login prevented.

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




On Thu, Mar 18, 2021 at 7:43 PM John R. Hogerhuis  wrote:

> You have to be logged in to upload
>
> http://bitchin100.com/wiki/index.php?title=Special:Upload
>
> On Thu, Mar 18, 2021 at 4:15 PM Stephen Adolph 
> wrote:
>
>> ah  good idea.  is there a files area?
>>
>>
>> On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis 
>> wrote:
>>
>>> Very cool!
>>>
>>> You can upload it to Bitchin100 wiki. The File Uploads feature.
>>>
>>> -- John.
>>>
>>> On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph 
>>> wrote:
>>>
 Via a user on facebook, the TPDD service manual has been found!
 Who knew we would still be discovering documents in 2021.

 Need to make arrangements to post this at Club100.
 It is too large to send to the mailing list..
 Steve

Re: [M100] TPDD service manual

[John R. Hogerhuis]

You have to be logged in to upload

http://bitchin100.com/wiki/index.php?title=Special:Upload

On Thu, Mar 18, 2021 at 4:15 PM Stephen Adolph  wrote:

> ah  good idea.  is there a files area?
>
>
> On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis 
> wrote:
>
>> Very cool!
>>
>> You can upload it to Bitchin100 wiki. The File Uploads feature.
>>
>> -- John.
>>
>> On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph 
>> wrote:
>>
>>> Via a user on facebook, the TPDD service manual has been found!
>>> Who knew we would still be discovering documents in 2021.
>>>
>>> Need to make arrangements to post this at Club100.
>>> It is too large to send to the mailing list..
>>> Steve
>>>
>>>

Re: [M100] TPDD service manual

[Stephen Adolph]

ah  good idea.  is there a files area?


On Thu, Mar 18, 2021 at 7:06 PM John R. Hogerhuis  wrote:

> Very cool!
>
> You can upload it to Bitchin100 wiki. The File Uploads feature.
>
> -- John.
>
> On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph 
> wrote:
>
>> Via a user on facebook, the TPDD service manual has been found!
>> Who knew we would still be discovering documents in 2021.
>>
>> Need to make arrangements to post this at Club100.
>> It is too large to send to the mailing list..
>> Steve
>>
>>

Re: [M100] TPDD service manual

[John R. Hogerhuis]

Very cool!

You can upload it to Bitchin100 wiki. The File Uploads feature.

-- John.

On Thu, Mar 18, 2021 at 3:56 PM Stephen Adolph  wrote:

> Via a user on facebook, the TPDD service manual has been found!
> Who knew we would still be discovering documents in 2021.
>
> Need to make arrangements to post this at Club100.
> It is too large to send to the mailing list..
> Steve
>
>