I've added a rom_dump command to pdd.sh
https://github.com/bkw777/pdd.sh
You just say "rom_dump filename" and it dumps the rom to filename as binary.
Accepts rom_dump or dump_rom equally.
If you don't give a filename, it just prints the hex to the screen.
$ pdd rom_dump pdd1_rom.bin
Works on both TPDD1 and TPDD2, and detects the type of drive automatically.
For TPDD1, it uses the machine code you (Darren) provided at
https://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes
Which is AWESOME thank you for writing that!
I didn't have to add any special character delays, it's both writing the
S-records and reading the results as fast as the tty will go. though
rts/cts is in effect, so maybe with a 3-wire cable some delay would need
to be injected. I haven't tried without flow control yet.
I'm currently parsing the returned ascii hex dump to generate the
binary, but could you possibly make a version that just sends the raw
binary bytes? Even better one that can take parameters or even just have
a few bytes edited on the fly to dump an arbitrary address & length?
For TPDD2 it's just using the normal mem_read command.
ROM images collected this way for both TPDD1 and 2 are both at
http://tandy.wiki/TPDD#Documentation
in case you want to compare them.
Now I'll dump the FB-100, KnitKing FDD19, and Purple Computing D103 just
to see if they're all identical.
Session capture...
With a TPDD1 plugged in, letting pdd.sh figure out the model itself
------------------------------------------------------------
bkw@fw:~/src/pdd.sh$ pdd
PDD(-:6.2,F)> rom_dump pdd1_rom.bin
ROM DUMP for TPDD1 / FB-100
https://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes
This process requires the drive to be configured to receive S-records.
Do the following now before proceeding:
1 - Turn the drive power OFF.
2 - Set all 4 dip switches to ON.
(or close all 4 solder-jumper pads with solder)
3 - Turn the drive power ON.
If the dip switches were already set from a previous attempt,
still cycle the power switch once right now.
If the low battery light is flashing, cycle the power.
Ready to proceed (y/N)? y
Saving to file: pdd1_rom.bin
File Exists: Are you sure? (y/N) y
Switching serial port to 9600 baud.
/dev/ttyUSB0 is open
speed: 9600
Sending S-records to the drive cpu...
S10E8515CEF000C608860DBD854F8621
S11385200ABD854F3C328100271EBD855A32BD8568
S11385305A863ABD854FA600BD855A8620BD854F13
S1138540085AC10027D220EE8658BD854F20FE3739
S1138550D611C42027FA971333393644444444BD12
S1138560856532840F810A2B028B078B30BD854FC2
S104857039CD
S901FE
F000:0F 8E 87 FF 86 FC 97 00
F008:86 34 97 02 86 FF 97 04
[...]
FFF0:F0 00 F0 00 F0 00 F0 00
FFF8:F0 00 F0 00 F0 00 F0 00
Restoring serial port to 19200 baud.
/dev/ttyUSB0 is open
speed: 19200
Wrote 4096 bytes to pdd1_rom.bin
Return the drive to normal configuration.
1 - Turn the drive power OFF.
2 - Set all 4 dip switches to OFF.
3 - Turn the drive power ON.
PDD(opr:6.2,F)> q
bkw@fw:~/src/pdd.sh$
------------------------------------------------------------
With a TPDD2 plugged in, letting pdd.sh figure out the model itself
------------------------------------------------------------
bkw@fw:~/src/pdd.sh$ ./pdd
PDD(-:6.2,F)> rom_dump pdd2_rom.bin
Reading cpu memory, addr:0xF000 length:0x1000
to file: "pdd2_rom.bin"
[########################################] 100% (4096/4096 bytes)
PDD(pdd2[0]:6.2,F)> q
bkw@fw:~/src/pdd.sh$
Looking at the results
------------------------------------------------------------
bkw@fw:~/src/pdd.sh$ ls -l *.bin
-rw-rw-r-- 1 bkw bkw 4096 Jan 24 19:23 pdd1_rom.bin
-rw-rw-r-- 1 bkw bkw 4096 Jan 24 19:24 pdd2_rom.bin
bkw@fw:~/src/pdd.sh$
bkw@fw:~/src/pdd.sh$ xxd -g 1 -u pdd1_rom.bin
00000000: 0F 8E 87 FF 86 FC 97 00 86 34 97 02 86 FF 97 04 .........4......
00000010: 97 05 86 A0 B7 40 00 F6 40 01 C4 F0 37 54 54 54 .....@..@...7TTT
[...]
00000fe0: F3 5B 44 F3 C8 4D F4 00 00 FF 00 FF 00 FF F0 00 .[D..M..........
00000ff0: F0 00 F0 00 F0 00 F0 00 F0 00 F0 00 F0 00 F0 00 ................
bkw@fw:~/src/pdd.sh$
bkw@fw:~/src/pdd.sh$ xxd -g 1 -u pdd2_rom.bin
00000000: 8E 87 FF CC 0C 10 DD 02 CC FC 11 DD 00 CC FF C7 ................
00000010: DD 04 B6 40 00 8A 80 B7 40 00 86 B2 B7 40 00 CC ...@....@....@..
[...]
00000fe0: 43 29 20 4D 2E 46 55 54 41 4D 55 52 41 FF F7 16 C) M.FUTAMURA...
00000ff0: FF 5E FF 2A FF 5E FF 5E FF 5E FF 13 F0 00 F0 00 .^.*.^.^.^......
bkw@fw:~/src/pdd.sh$
--
bkw
On 1/23/24 22:01, Darren Clark wrote:
Awesome!
Looks a lot better, I just ran it through my decompiler and posted the
first pass here:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
There are still some invalid opcodes floating around, I need to dig
deeper and see what is going on there. I also see several lookup tables
at the end, I'll look into those and document them.
It looks like the calls to the CPLD/gate array are the same, it's only
using address 0x4000 to 0x4003 for those (same as TPDD1). Other than
that the code base is almost completely different from the TPDD1 which
is interesting since the hardware is almost the same.
I might write up a 6301 emulator and try running the code to test some
serial I/O on it. I think I can fake most of the other IO since it goes
through the CPLD.
Thank you very much for dumping the ROM, I'm wondering what undocumented
secrets we'll find in there!
Darren Clark
On 1/23/24 21:27, Stephen Adolph wrote:
128 more bytes ;)
On Tue, Jan 23, 2024 at 3:28 PM Stephen Adolph <twospru...@gmail.com>
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 <biggran...@gmail.com>
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
<biggran...@gmail.com> 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
;----------------------------------------------------------
--
bkw
