Not a rexcpm function. It is handled by import and export written by Philip.
I can say that I believe import and export use tpdd routines that mirror the rex routines and are based on Code built by Wilson van alst. I'd have to do some work to understand how the name is structured. I think it is fixed length. Steve On Saturday, March 16, 2024, Brian K. White <b.kenyo...@gmail.com> wrote: > On 3/16/24 13:48, Stephen Adolph wrote: > >> regarding file transfer, use >> IMPORT >> or >> EXPORT >> in CP/M. Included in package. >> These programs access a "TPDD". Filenames are 8.3 format, >> >> cheers >> Steve >> > > What is the ATTR byte? Presumably F ? > > And is that fixed-length space-filled like what Floppy or WP-2 do or not? > "a_______.txt" or "a.txt_______"? > > And do you know if what REXCPM does matches what other CP/M systems that > use a TPDD do? > > I think there is something that can use a tpdd from a NEC PC-8401 and > PC-8500 but I never used it yet and don't know what it exactly writes to > the drive, or expects to find on a drive. > > I have a REXCPM and both a 8401 and 8500 so I can test and answer all > those myself some time. I'm not asking for real unless you do just happen > to know. > > The reason I ask is I would add a CP/M compatibility mode to both dl2 and > pdd.sh if I knew what it should be. > > And, if REXCPM and PC-8401/8500 don't currently match each other, I > suggest REXCPM should change to match NEC, so that you can move files and > disks between the two. > > There are settings in both dl2 and pdd.sh to manually configure every > detail, so already right now neither program is actually limited to the > baked-in convenience modes, but it's not as convenient. > > For instance to use dl2 in this case I'm guessing you probably want > "dl -0 -a F" > > "-0" sets a "raw" mode where dl2 doesn't care about spaces or dots or > anything in the filename, doesn't re-write filenames to different formats, > and sets the ATTR field to ' ' (0x20, space). In other words acts like a > real drive, which also doesn't have opinions on any of that. > > And "-a F" sets ATTR to F, overriding that -0 set it to space. > (I should clean that up to make a more consistent interface but that's the > way it works currently) > > And attr only matters for new files created on the pc or from the internet. > > A real drive never fabricates an attr value, or cares what it is, it just > saves whatever a client supplies when creating a file, and then reads it > later when accessing files. The byte can be anything, and must match from > one operation to the next only for the same reason a byte in the filename > must match. And on a real drive, ALL files had to have been created by a > client saving them initially. There are no files that come directly from > the internet to the disk and need some attr value fabricated. > > A couple months ago I added xattr support so that dl2 now acts even more > like a real drive. When creating a file (when a client saves a file, > meaning dl2 has to create a new local file on the pc side), instead of > ignoring the attr field from the client dirent() request, dl2 now saves it > in a xattr metadata field attached to the file. And when listing or > accessing existing files, instead of fabricating attr=F for all files, it > gets a real attr value from xattr, and only fabricates the default value if > there is no xattr. > > So in one sense dl2 already works fully (should anyway), at least to the > extent of matching a real drive. > > -- > bkw > > >> On Sat, Mar 16, 2024 at 1:36 PM Will Senn <will.s...@gmail.com <mailto: >> will.s...@gmail.com>> wrote: >> >> __ >> I broke down and started reading the manuals (REXCPM, CP/M 2.2, >> etc). It's starting to come together (again?)... I've inlined the >> answers I figured out for posterity or the next clueless newb who >> comes along. >> >> On 3/16/24 11:00 AM, Will Senn wrote: >> >>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes >>> more memory: >>> >>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0 >>> >>> Yes, it does recognize more memory and it serves up an A: drive >> that's a big chunk of that 2MBs. Solid. Talked about here: >> http://bitchin100.com/wiki/index.php?title=M100_CP/M >> <http://bitchin100.com/wiki/index.php?title=M100_CP/M> >> >> My questions are as follows: >>> >>> 4. In CP/M, how do I get back to MENU? >>> >>> Duh, F8 :). >> >> 5. When I start CP/M, is it just running CP/M against the M100's >>> memory or am I in some special whizbang virtual environment where >>> I have additional disks available somehow? >>> >> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: >> drive. >> >> As for my broken ASM, another duh, thanks John for the tip - I need >> to write a CP/M friendly program that call it's routines and not the >> ROM calls. >> >> CP/M seems the way to go, though. It kinda reminds me of RT11, but >> with ASM instead of MACRO11. ed... well, after you figure out that >> you need to retrieve the file contents into the buffer, it kinda >> makes sense - nice video - I love ED: >> https://www.youtube.com/watch?v=7pqaj050X7g >> <https://www.youtube.com/watch?v=7pqaj050X7g> >> >> Still need to figure out how to get files into and out of cp/m >> though... >> >> Off to read some more. >> >> -will >> >> > >
