OK so far STARTDISK.COM (CP/M on a NEC-8500) against LaddieAlpha has resulted in the following changes to LaddieAlpha:
1) Had to disable various M100 specific filters and fixups when in 8.3 mode. What I probably need to do is add CP/M specific filters and fixups, because CP/M pads its files with $1E to 128 byte boundaries and my TPDD services are not exactly TPDD emulators, they are file transfer utilities. 2) STARDISK doesn't include a '.' in filenames it writes/reads from TPDD filenames. So the disk service cannot rely on it as a separator, it has to know that you want to do exactly 8.3. So I had to add 8.3 handling. 3) STARDISK sends mystery command 48 and requires a response. I just send a $38-$01-$00-$C6 response, it seems to be OK with that and responding unsticks things. But I don't know what the request means or if a real TPDD would send that response. 4) I've seen STARDISK send 5B 5A 0C 00 which might be a Drive Condition command, but instead of starting with ZZ it starts with a Z with the low bit set, so [Z . When it sends it I have no response and it gets stuck. Restart STARDISK.COM and it doesn't do it again and the transfer works. I've never seen that before. It might be a bug in STARDISK. Might be valid TPDD or TPDD-2 speak. I don't know and I haven't checked it on a TPDD. 5) STARDISK relies on an "input past EOF" error to stop reading when inloading a file. Basically when you read a file each read returns a length and some bytes. Each read can return between 0-128 bytes. If the read is less than 128 then on THE NEXT read you need to return a $3F error. So the server needs an "EOF" state or some way to know that it has already done the "last" read so it can return the error. If I don't do send the $3F error then STARDISK goes into an infinite loop and dies with an out of memory error. So 5) is actually a bug in LaddieAlpha. Which means the bug may also exist in other TPDD services. Interestingly it probably doesn't exist in DLPilot since my notes show I understood the exact TPDD EOF handling situation in the early 2000's and put an EOF state in my state madhine, but either forgot about it or didn't care because TS-DOS doesn't rely on this error. Either TS-DOS reads based on the file length (FLOPPY does that too) or it knows to not keep reading past the last read that returns < 128 bytes. Fixed in my development version, will be released soon. As to the current 8.3 handling, it may or not be helpful with REXCPM depending on how it would format an 8.3 filename. I really don't like the fact that STARDISK.COM leaves out the '.' but at this point the question is do we do it the way it does it or do we handle both ways. Either 83 or 8.3. -- John.
