Curiouser, I added support for request 0x47, including the detail that
it only works if dl2 is in strict tpdd1 mode.
In default or explicit tpdd2 mode, it ignores the command the same as a
real TPDD2 does.
When I run with strict tpdd1 emulation, PAKDOS sends the 0x47 status
command once per directory list. As expected.
When I run without that, which defaults to enabling TPDD2 features, and
ignores 0x47 as unrecognized, PAKDOS tries 0x47, only waits a few ms for
the response and then sends a normal 0x07.
So, it's not the case that James just mistakenly thought that 0x47 was
the status command. He sends it, and then only if that fails, then does
0x07.
So it was even more deliberate than it already looked. Don't ask me why!
--
bkw
On 1/10/24 10:49, Brian K. White wrote:
The TPDD2 service manual in all of its glory...
While going through starting to update dl2 with all this new info, I
also tried a new (old) DOS I recently found called PAKDOS by James Yi.
http://tandy.wiki/TPDD_client:PAKDOS
And it tries to use a command 0x47 every time it does a directory
listing.
Well that's a new one. Never saw request format 0x47 anywhere before.
I figured out what it is and it's weird.
PAKDOS apparently expects no-response might be possible since it
doesn't care that dl2 ignores it, and the directory listing works with
no hint of any problem on the portable side.
The command is given with no parameters or payload data, and wrapped
in a valid Operation-mode packet, IE, the packet has all components
and is consistent.
format byte is 0x47
there are no params or data, and the len byte is 0x00, so that fits,
and there is a checksum byte 0xB8 after that, which is correct.
So, it's not just random data.
The first guess maybe it's a synonym for drive_status, because:
* 0x07 is drive status
* drive status has a payload length of 0
* for TPDD2, some commands do have an alternate version that is the
normal format code plus 0x40 to make the command operate on bank1
instead of bank0.
all checks out and adds up
But a real TPDD2 does not respond to this command.
... BUT a TPDD1 DOES, and it indeed does the drive status command.
It doesn't just respond with a valid standard 0x12 return format for
"ok" but for instance if the disk is ejected it says so.
Whatever! Easy enough to handle, just completely unexpected that a
tpdd1 would respond to a 0x4n request and a tpdd2 does not!
