Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI:Notes (not really an issue) #1

Open
geowar1 opened this issue Nov 20, 2022 · 3 comments
Open

FYI:Notes (not really an issue) #1

geowar1 opened this issue Nov 20, 2022 · 3 comments

Comments

@geowar1
Copy link

geowar1 commented Nov 20, 2022

Not really an issue per se… more of an FYI. (didn't see any other place to leave comments.)

CP/M 3.x allows user #'s up to 31 (0x1F).

There are "reserved" user numbers for labels (32 (0x20), time stamps (33 (0x21)… and I think one more (but can't remember it off the top of my head).

[Note: I use 46 (0x2E) to create virtual sub-directories that map to logical drive partitions. I have CP/M (3.x) versions of mkdir, cd, pwd, etc. ;-)]

I'd probably add code to "fix" illegal filename.ext characters by ether 1)setting them to space or 2) mark the file as erased. #1 would probably be better… especially if the file has multiple directory entries. Or if it does fsck could do a "best guess" match against any additional directory entries and based on partial filename.ext match and/or contiguous allocation block numbers.

No action(s) required here… you may close this issue as "not to be fixed". ;-)

@rundel-tech
Copy link
Owner

Hi geowar1. You raise some interesting points. I was considering only CP/M 2.2 when I wrote fsck. However, my homebrew Z80 system ZARC was designed with later versions in mind including MP/M. Hence I may yet produce a version for later CP/Ms. In the meantime, I think a reasonable approach might be to simply warn that CP/M 3.x features were encountered.

I am not keen to have fsck make changes to the disk, as this risks making things worse. My intent was to verify that all is well with the filesystem, and then fix with PIP, FORMAT and the like if it wasn't.

@geowar1
Copy link
Author

geowar1 commented Nov 24, 2022

ZCPR was a popular CCP/BDOS replacement for CP/M 2.2. IIRC it used 0x21 for its file date/time stamps also. Labels were also part of CP/M 2.2 (and used 0x20).

I usually use zap or du to (manually) repair bad directory entries. ;-)

@rundel-tech
Copy link
Owner

Despite the time, I haven't forgotten about this. I think another way of putting it is a request for CP/M 3 support, plus some extras. My hobby project ("ZARC") doesn't run CP/M 3 yet, and I would need this first as a development platform. Other aspects of life are severely limiting my hobby time at the moment, but I hope to complete it at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants