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