• Please review our updated Terms and Rules here

RAMdisk CP/M 2.2 (MDDIR)

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
396
As I start to put together the framework of how I want this to work, there are 96 possible directory entries, each taking up 32 bytes. The first byte of each directory entry is a 0 if the entry is empty, or a 1 if the directory has an entry. So, in order to list all the files in the directory, I need to check the first byte, then increment 32 bytes to check the next, and so forth. I'm trying to figure out an efficient way to step a counter by 32 each time I need to go through this process to check all 96 possible directory entries...... Hmmmmm
 
It doesn't really need to be efficient. Just add 32 to it each time. Even hold the location of the directory in memory in HL and make DE 32 and then add this each time you need to. You can scan through the directory name, but anything specific works well as an offset if you put it into an index register, and you can use labels for the offset each time.

If it's inefficient, that just means it takes a second instead of 100 milliseconds... Anything under 5 seconds is acceptable. Even if you incremented 32 times with a DJNZ loop, it's still going to appear to be instant to a user.
 
Well, looks like the RAMdisk directory program (MDDIR.COM) is complete and working. The '-' is an indicator that the file is read/write and the '+' indicator is for a read-only file. I loaded the direcory with some dummy data for the test and one of the files spanned multiple entries (indicating the file was larger that one 2K block), and it only lists the file once. So, that part of the test passed as well. So, On to the next program in the suite...

1687812145261.png
 
Nice ! Congratulations on getting it all working.

I like that you went five across.
Thanks, so my calculations were, for an 80 column display..... (80 - (protection bit+space+filename+period+extension)*5)/5 which gave me 2. So I added two blank spaces to each entry, and the screen wrapped as planned. My next program in the suite is going to be the MDERA for file deletion. The hard ones will be MDLOAD & MDSAVE.
 
I hadn't thought of that - 16 characters per entry and just keep on going. I wonder why they didn't do that under CP/M.... It looks much nicer. Maybe it affects scrolling time on some older terminals?
 
Well, I did the calculation on paper for an 80 column display, and just hard coded the padding into the code. So nothing fancy. Screens of different sizes aren't gonna work so well.
 
Just curious, why didn't you configure the DPB for the RAMdisk with 96 (95 in the table as it is directory size-1) and just use CP/M dir command on drive M: or what ever drive letter you assigned to the RAMDisk in the BIOS?


Peter
 
If you want to change CCP you can patch the CP/M 2.2 build system. The code extract will produce 2 columns on a 40 character screen and 4 columns on an 80 column screen.

CCP QUERY 'Bias (0/100H)'

; patch for 2 dir columns 40 chars, 4 columns 80 chars.

CCP_BLANK EQU CCP+0A2H ; ccp routine to o/p space to con:
CCP_CRLF EQU CCP+98H ; ccp routine to o/p CRLF to con:
CCP_DIR4 EQU CCP+4F9H

no_spaces EQU 5 ; spaces to pad dir list to 20 chars

ORG CCP+4B4H
CALL Z,CCP_CRLF
CALL pad_out_directory_with_spaces

ORG CCP+4DFH
JR CCP_DIR4 ; don't truncate trailing blanks

pad_out_directory_with_spaces:
LD B,no_spaces ; pad directory entry to 20 chars.
1$:
CALL CCP_BLANK
DJNZ 1$
RET


Peter
 
Peter, it's a long story, but given the many years since I fiddled with S-100, Z-80, and CP/M stuff, I figured doing things outside of altering (and screwing up) my CP/M environment, would be best as I re-learn stuff. This is all working on my Z-80 based STD bus system at the moment. As I gain knowledge, I'm sure things will change when I port stuff to the S-100 system. Like full integration of the RAMdisk to possibly be the boot device, a printer driver integrated into CP/M, an actual video board so no more serial console, etc.
 
Back
Top