On Fri, Jul 3, 2020 at 4:08 PM Gary Weber <[email protected]> wrote: > 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. > > It's transparent to the user. LaddieAlpha is translating them. So on the Host disk FUBAR.COM would present as FUBAR.COM. Presented over the protocol as FUBAR___COM (no dot, underscores here representing spaces). STARDISK.COM Directory command presents as FUBAR___.COM on the screen. Stardisk understands unpadded FUBAR.COM if typed at prompt as well. It pads it out, and removes the '.' I uploaded a version with all fixes to date (83 and the input-past-EOF fix) to Google Drive please use the latest if you test. -- John. >
