Minor correction. Any commands that get translated to an index higher
than 0x13 will return an invalid command, not crash the firmware.
This statement is incorrect: "I haven't looked for any other logic that
would prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to
0x3F will select addresses past the jump table (author name and reset
vector table) causing the firmware to crash and reset."
[F104] [58 ] [X ] ASL B ;B*2 - set pointer
correctly for function table
[F105] [C1 26 ] [ & ] CMP B #0x26 ;if command > 0x13
branch to Command_FMT_Invalid
[F107] [24 2E ] [$. ] BCC Command_FMT_Invalid
The "I haven't looked..." part is true, I found it at F014 and F105. So
the firmware does protect against invalid commands.
Darren Clark
On 1/28/24 12:40, Darren Clark wrote:
The part of the code that picks out the commands is a bit goofy, but I
believe it's like this to maintain a standard command set across
multiple drives with other added functionality.
There is a bit mask for the command, so we're only looking at the
lower 6 bits (0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is
masked out of the command selection code. It'll require some more
digging around to see where it is used.
Here is some of the logic:
If the command = 0x23 (line F0F5), make the command 0x09. This is
the Drive Version Info command.
If the command > 0x30, subtract 0x22 from it.
That makes the following commands into index positions:
0x30 = 0x0E
0x31 = 0x0F
0x32 = 0x10
0x33 = 0x11
0x34 = 0x12
The end result is the command becomes the index of the jump table:
Index Command Function
0x00 0x00 ;Command_FMT00_CreateDirectory
0x01 0x01 ;Command_FMT01_FileOpen
0x02 0x02 ;Command_FMT02_FileClose
0x03 0x03 ;Command_FMT03_FileRead
0x04 0x04 ;Command_FMT04_File_Write
0x05 0x05 ;Command_FMT05_FileDelete
0x06 0x06 ;Command_FMT06_DiskFormat
0x07 0x07 ;Command_FMT07_DriveStatus
0x08 0x08 ;Command_FMT_Invalid
0x09 0x23 ;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A 0x0A ;Command_FMT_Invalid
0x0B 0x0B ;Command_FMT_Invalid
0x0C 0x0C ;Command_FMT0C_DriveCondition
0x0D 0x0D ;Command_FMT0D_FileNameChange
0x0E 0x30 ;Command_FMT30_SectorModeReadWrite
0x0F 0x31 ;Command_FMT31_DriveMemorySet
0x10 0x32 ;Command_FMT32_DriveMemoryGet
0x11 0x33 ;Command_FMT33_SystemVersionInfo (SM Page 92)
0x12 0x34 ;Command_FMT34_ExecuteProgram
I haven't looked for any other logic that would prevent this, but a
command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select
addresses past the jump table (author name and reset vector table)
causing the firmware to crash and reset.
Also command 0x0F is the same as 0x31, so it returns the memory set
return block 0x38. And looking at the table, there are several other
overlapping commands: 0x0E, 0x10, 0x11, 0x12
The memory write commands set flags in the internal RAM, these need to
still be deciphered.
There is also a block of code that reads a file off of a disk into the
2K external RAM and executes it.
On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead
of full of mysteries and "here we recite the words lest the gods be
angry".
Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like
that too where an undocumented code results in some other response
than the invalid code response.
It's like it's not checking the entire value but masking bits, and
looking at fewer than all 8 bits, and multiple values can give the
same bits.
Definitely bank 1 must work that way. A bunch of commands that all
get one part of their meaning changed by adding 0x40, which is just
flipping 1 bit on the normal command code.
IE 0x00 is dirent, 0x40 is dirent in bank 1.
Ah speaking of "we don't know why we do this but we must recite the
words here" there are a few things exactly like that.
The service manual describes a routine it calls "reset drive status"
on pg 102. It's just using mem_write to write 3 bytes at 3 addresses
but doesn't explain what they do.
write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094
And with dl2 I have captured TS-DOS doing exactly that sequence.
The tpdd2 backup.ba <http://backup.ba> also does something similar
but not the same, just before each each cache commit (write cache to
disk):
write 0x00 to 0x0083
write 0x00 to 0x0096
To be clear it never does the other 3 bytes, it just does these 2
before each cache write-to-disk.
https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 38 01 00 C6
17/08/2016 20:03:01.676 [M100] - 5A 5A 31 04 01 00 96 00 33
17/08/2016 20:03:01.679 [TPDD] - 38 01 00 C6
...
They are in the cpu internal 128 bytes is all I can tell.
Maybe one of those bytes holds the drive status/condition bit flags
used by the status or condition commands?
Also I just realized I was dumb to talk about reading the external 2k
ram on TPDD1 before. On TPDD1 you can't read any ram without
rebooting into the special cpu mode anyway, so it's not like you can
examine the ram to see where the drive stored bits of info about the
disk or a loaded sector or anything like that, so there is no point
to a more generic version of the rom dumper.
... and as soon as I said that I thought, well maybe as a drive
diagnostic tool, you could read the sensors directly instead of
relying on the drive firmware to report error conditions while trying
to repair a drive or something. Maybe even operate the gate array?
It is a marvel getting that much functionality out of so few bytes.
--
bkw
On Sun, Jan 28, 2024, 12:19 AM Darren Clark <[email protected]> wrote:
Spent some time digging through the source of the TPDD2 firmware,
adding
comments, labels, and variable names.
It's documented (as far as I got so far) here:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
Doesn't look like any hidden commands exist in the firmware. This
is the
list from the command table at 0xFFB9:
code 0xF230 Command_FMT00_CreateDirectory
code 0xF4D0 Command_FMT01_FileOpen
code 0xF495 Command_FMT02_FileClose
code 0xF69D Command_FMT03_FileRead
code 0xF63D Command_FMT04_File_Write
code 0xF425 Command_FMT05_FileDelete
code 0xF212 Command_FMT06_DiskFormat
code 0xF6F3 Command_FMT07_DriveStatus
code 0xF137 Command_FMT_Invalid
code 0xF75F Command_FMT23_DriveVersionInfo
code 0xF746 Command_FMT0C_DriveCondition
code 0xF365 Command_FMT0D_FileNameChange
code 0xF801 Command_FMT30_SectorModeReadWrite
code 0xF76B Command_FMT31_DriveMemorySet
code 0xF78E Command_FMT32_DriveMemoryGet
code 0xF757 Command_FMT33_SystemVersionInfo
code 0xF7DC Command_FMT34_ExecuteProgram
Some other interesting tables are at 0xFF67 and 0xFF6D
[FF67] [80 ] [ ] Table_SysInfo: DB 0x80 ;Hard
sector data port address MSB
[FF68] [13 ] [ ] DB 0x13 ;Hard
sector data
port address LSB
[FF69] [05 ] [ ] DB 0x05 ;Buffer size MSB
[FF6A] [00 ] [ ] DB 0x00 ;Buffer size LSB
[FF6B] [10 ] [ ] DB 0x10 ;CPU type.
0x10 =
HD6301
[FF6C] [E1 ] [ ] DB 0xE1 ;Model code
[FF6D] [41 ] [A ] Table_Version: DB 0x41
;System Version Number MSB
[FF6E] [10 ] [ ] DB 0x10 ;System Version
Number LSB
[FF6F] [01 ] [ ] DB 0x01 ;Number of sides
[FF70] [00 ] [ ] DB 0x00 ;Number of
tracks MSB
[FF71] [50 ] [P ] DB 0x50 ;Number of
tracks LSB
[FF72] [05 ] [ ] DB 0x05 ;Sector
length MSB
[FF73] [00 ] [ ] DB 0x00 ;Sector
length LSB
[FF74] [02 ] [ ] DB 0x02 ;Sectors per
track
[FF75] [00 ] [ ] DB 0x00 ;Directory
Entries MSB
[FF76] [28 ] [( ] DB 0x28 ;Directory
Entries LSB
[FF77] [00 ] [ ] DB 0x00 ;Max files
[FF78] [E1 ] [ ] DB 0xE1 ;Model code
There is also a BAUD rate table at 0xFF85, I see logic for
reading the
dip switch setting from the CPLD at the program initialization. 2
switches for the BAUD rate and the other 2 for some other mode
settings.
Just a w.a.g. it almost looks like the programming on the CPLD
could be
the same on the TPPD2 as the TPPD1. It might be possible to set
9600 and
38400 BAUD, just guessing though as I don't have any TPDD2
hardware to
play with.
Overall an amazing amount of work went into this firmware. From
what I
can see, it's all hand coded and has a lot of space saving
optimizations
in it. Out of 4K of available space, there is only 15 bytes of
unused
space, and the author put his name into it (with one byte filled
with a
0xFF):
[FFDF] [***********] [ ] DB '(C) M.FUTAMURA',0xFF
;Author
Darren Clark
