It was a first pass attempt. I captured it as 128 blocks of 32 bytes. I'll check that I didn't cut off the file by accident.
On Tuesday, January 23, 2024, Darren Clark <[email protected]> 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 0xFFFF. 0xFFEE to 0xFFFF 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 <[email protected]> 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 >> 0xFFFF in memory. >> >> Is there anybody with a TPDD2 willing to try and dump 4K of data from >> 0xF000 to 0xFFFF 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): >> ;---------------------------------------------------------- >> ;0000-001F Internal Registers (see below) >> ;0080-00FF Internal RAM >> ;4000-4003 CPLD (Glue Logic + Hardware IO Control) >> ;8000-87FF External RAM (2K) >> ;F000-FFFF 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 >> ;---------------------------------------------------------- >> >> >> >>
