If you've already broken compatibility in other ways for the speed, then what's the argument anyway?
I see no reason for rexcpm to be limited to 6.2. A real drive isn't, and it's a pretty easy change for the few tpdd servers that are current. Rexcpm already breaks compatibility all kinds of other ways, like by plugging up the bus connector, to say nothing of the wild bcr port hack. -- bkw On Fri, Jun 12, 2020, 5:23 PM John R. Hogerhuis <[email protected]> wrote: > > > On Fri, Jun 12, 2020 at 2:01 PM Brian White <[email protected]> wrote: > >> TPDD protocol supports 8.3. >> There is no reason I see the tpdd code in rexcpm can't do tpdd with full >> native filenames, if full native filenames are only 8.3. >> > > True but none of the TPDD services were designed to support the new 8.3 > use cases. So it's a new need. > > The deal is the TPDD services are file transfer systems, they are not TPDD > emulators aiming for accuracy. Just utility. > > Since no one in Model T land was using 8.3 names, the TPDD code written > just met the 6.2 use case. > > At some point for example when I wanted DLPlus and LaddieCon to work with > the WP-2 I modified their code for 8.2 support and also for traversing the > directory backwards which only the WP-2 does. > > So adding 8.3 support will add compatibility for a use case that we didn't > care about before. > > Meanwhile on the extensions/incompatibility front I did some work on > LaddieAlpha for the REXCPM project which is completely incompatible with a > real TPDD to increase data throughput (larger packet sizes, high baud rate). > > Need to get that released at least... it works but we need a simple set of > command line options. > > -- John. >
