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 <[email protected]
<mailto:[email protected]>> 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
