128 more bytes ;) On Tue, Jan 23, 2024 at 3:28 PM Stephen Adolph <[email protected]> wrote:
> It was a first pass attempt. I captured it as 128 blocks of 32 bytes. > Was it > > 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 >>> ;---------------------------------------------------------- >>> >>> >>> >>>
<<attachment: firmware_TPDD2.zip>>
