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 <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 0xFFFF (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 <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 <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 >>> >>>
