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
