On 9/16/2020 7:26 PM, John R. Hogerhuis wrote:
On Wed, Sep 16, 2020 at 4:40 PM RETRO Innovations
<go4re...@go4retro.com <mailto:go4re...@go4retro.com>> wrote:
On 9/16/2020 4:46 PM, John R. Hogerhuis wrote:
Right now, (since you're listening), most of the TPDD.cs I
grok, but I am wondering about a few things:
* In FOrmatDirResponse, 0x1e is for a file larger than
$ffff, I assumed that's an extension.
Nope. It's real TPDD behavior I reverse engineered long ago. Not
saying no one else did, but at least I also did.
Hmm, interesting. I realize 1e is the number of bytes sent back
(differs by 2), so that answers that, but the 'P' seems odd, as I
would think it would still be the free numbers of sectors. During
testing, was it always 'P' on various disks with different numbers
of sectors free?
No recollection. It was like 2004 or 2005 I think.
Likely the disk was blank though.
I'm not sure it matters much... there are no "sectors" to report on a
TPDD service that isn't over a real floppy.
I understand. My hope is to document the most "correct" behavior, since
one has to send back something in that spot either way.
As a test, I did place a 65932 byte file on the drive and feed it back
to to TS-DOS 4.1, but it does not understand the 4 byte 0x11 return. It
handles it OK, but claims the file is 65932-65536 bytes in size.
And I don't know that it is actually referring to free sectors. I
always figured the 'P' and the 'F' were structural components of the
message when dealing with a 64K or greater file size.
Well, you send the 'F' earlier int he response, as an attribute. But,
then send the 'P' as the free sector count.
* If the file < ffff, you send 0x9d as the sectors free,
but I see other guidance saying just send 0x80 back. Why
0x96d?
Is there a reason you send x09d as opposed to 0x80 here?
It looks like 9d * 1280 sectors per logical sector = 200960, or a
completely empty TPDD2. VirtualT sends it back as well, though it looks
like dl doesn't put anything in there (00, I assume).
* I assume the 'P', the len >> 24 and the len >> 16 is to
send the upper 2 bytes of the > ffff size file, but why
big endian when the original code was small endian? And,
is this part of the extension previously defined?
What original code was little endian?
Ah, you're right. I was looking at seek, which is little endian.
Seek is definitely an extension.
I'm surprised it was done as little endian when the rest of the protocol
used big endian for multi-byte.
* In SelectFile, it looks like the select code always tries
to look for matches in the root dir that of DOS*.CO
format. Is there a reason?
Turns out I write very little code without a reason ;-)
It's so that DOS100.CO <http://DOS100.CO> TS-DOS tpdd client (RAM
version) can be found even if it's not your current directory
based on changing directories using the TS-DOS directory extension.
I figured there was a reason, but it's always good to leave the
question open ended. But, the response doesn't clarify, at least
for me. What is the use case that the read needs to see TS-DOS
even when you're not in that directory?
Probably the bootstrap programs that inload the DOS100.CO
<http://DOS100.CO> isn't directory aware.
It's for compatibility.
I added it for Kurt McCullum I think
If Kurt's on the list, I'd be interested to hear of the need. I'd
assume one would just restart LaddieAlpha, which should place it back in
the root.
* Is reference.previous an extension? Regardless, is there
an app that uses it (PDDuino doesn't have that
functionality, but I would like to add and test).
No. It's a real TPDD feature. I added when I found the WP-2 using
it. WP-2 traverses the directory backwards if you move the cursor
backwards in the file list.
OK... Hmm, don't have one of those to test with, so will have to
write some test code
* Not sure I see why there is an option for a FilteredRead
in RequestReadBlock. Is there more docs on this?
Feature... NUL and EOF in .DO files will corrupt a model t's
memory file system. So they get filtered out when interacting
with a model t.
It looks like you filter them out regardless of platform (Model T,
etc.), correct?
Maybe. Not in my local copy. Being able to turn it off / on easily is
being changed for CP/M compatibility.
GOt it.
Wow, it looks like when the file is opened for reading, you read
it fully, counting bad chars, deducting those from the total,
using that as the total for the filelength. Hmmm, that's doable
on uCs, but expensive... I wonder if there's a way to just
replace with another non printing char.
Yeah, it's complicated but negligible on a desktop.
Other option is just don't filter them. A real TPDD doesn't do it.
I do it because I have come to consider LaddieAlpha a Model 100 to PC
file transfer service, not a disk emulator per se. So conversion
filters particularly for safety are a reasonable feature and weren't
to tricky to add.
The bigger problem has been turning them off.
BTW, the other filtering I do is extension correction for BA versus DO
files. Many BA files around on Club100 are not real, tokenized BA
files, and if you try to inload them with TS-DOS you'll crash your
Model 100.
So LaddieAlpha detects them and presents them as DO files if they have
DO content.
I didn't see that. Is there a function I should focus on?
I'll warn you a couple of our members don't like the fact that
LaddieAlpha has filters. So if you do implement it you may want to add
an option to turn it on / off.
Fair enough :-)
Thanks for the notes.
-- John.
--
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com
