John, This is exciting news. Thanks for the update on this and for diving right into the issue so quickly.
> ... 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. So, I'm just thinking about this from a host-centered usability perspective. * Would the changes you're currently looking at still preserve the ability to copy a filename like "FUBAR.COM" into the Root area on the host PC and LaddieAlpha would translate the filename so it serves up the file to STARDISK as an 83 padded filename like "FUBAR COM"? * When filenames that have been recorded from STARDISK are padded like that, would LaddieAlpha translate the filenames into a proper 8.3 "FUBAR.COM" format inside the Root area on the host filesystem? * Or would the user be required to do any manual renaming of files in order for LaddieAlpha to be able to serve them up to a STARDISK client? I think the biggest use case is that the user is going to download a file like "FUBAR.COM" from the internet and put it inside their Root area, and expect that this file can be loaded onto their CP/M machine be it either to a Starlet via STARDISK.COM or to a REXCPM-enabled Model T via IMPORT. It would be great if their TPDD server just handles the situation, and doesn't require the user manually rename any files inside of Root to be "compatible" with STARDISK. You know, I'm just thinking out loud here, but one alternative with trying to go through hoops for STARDISK would be to kiss that utility goodbye, and just port IMPORT / EXPORT over to the CP/M that runs on the NEC Starlet. Gary On Fri, Jul 3, 2020 at 3:20 PM John R. Hogerhuis <[email protected]> wrote: > 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. >
