RAMdisk CP/M 2.2 (MDFRMT)

[MykeLawson]

So, now that to test code is finished, and the hardware design has finally been debugged, and in large part by all the great help you all have given me, the next thing to do is format the memory so I can actually use it. At some point, I suspect as I migrate to the S-100 version of this thing, I will incorporate this memory disk as NVRAM and into CP/M 2.2 or 3.0. But for now, it will be a standalone entity.

The file directory structure I'm going for has 12 entries for each of the first 12 blocks of 256 bytes, for a total of 96 directory entries. Each file entry contains track & sector addresses for 8 blocks of 256 bytes, so each file consumes 2,048 bytes of memory. Not the most efficient method I'm sure, but it is a start for me to build with. Each of the 96 file entries will look like this:



U will be a 0 if unused and a 1 if used. P will be a 0 if unprotected and a 1 if write protected. S will indicate the sequence; 0 if only one block used and 1 through n for files larger than 2,048 bytes. Similar to CP/M, if I issue MDSAVE 'n' FILENAME.EXT, the file will take up as many directory entries as the 'n' indicates, each one having the same filename but the S value will contain the sequence. For file that are equal to 2,048 bytes or less, S will equal 0.

I'll see how well that works and tweak it as I go.

 

[geowar1]

Not sure why you’re reinventing the directory structure… Why not just add the MDisk R/W code to the BIOS and let CP/M deal with the directories?

 

[cj7hawk]

Nice, I like it. No need to translate tracks and sectors to a logical format and back again like with allocations..... And it's not all that different to the concept of the LBR file.

I'm curious as to why the space and the decimal - I could guess the reason if you were using a high level language, but I'm pretty sure you're using z80, and it means you're locked into using a lexical analyzer to prepare the filename.

As a thought, you could copy the basic components of the CP/M filename at least and apply your own details to the rest, then your applications will work with the command line under the CCP, even if you use your own Sector/Track allocation format.

If you type in a command, eg, MDSAVE FILENAME.EXT it automatically populates the zero page with FILENAME.EXT starting at address 5C, without the dot, eg, xFILENAMEEXT where x is most likely 00 and if you have a second name, eg, MDPIP FILE1.EXT=FILE2.EXT, you will file FILE2.EXT sitting at 6C, and you can just pluck it out, then open up FILE1.EXT with the BDOS, all clean and ready to go, with the filename neatly cut into 8+3 format.

Though the first byte is the drive specified, which will be either 0 or have the drive number, so the filename starts at 5D or 6D in 8.3 format.

The alternative is to pick it up from the buffer, but then you have to write your own lexical analyzer which increases the complexity significantly.

David

p.s. To see what I mean, rewrite your DUMP program to dump the memory from $0050 to $007F and call it with some following filenames, eg, DUMP FILENAME.EXT NEXTFILE.MRE and see what shows up in those memory locations.

 

[MykeLawson]

To be honest, the biggest driver in this project is to gain back my abilities to design hardware & software that I used to have many eons ago. so.... That said, my original design had the directory structure like this:



Where the 'X' contained contained the U, P, & S flags; where the byte is structured as:



I like the idea of have the track & sector locations be part of the directory entry to lessen the need to calculate the values in the code. This second method does cut down on wasted disk space and give me 192 directory entries vs the 96 with the other method.

 

[cj7hawk]

If you ever look up the LBR specification, they are similar to what you've done, though for them it's just file offsets.

Given your stated objectives, your strategy is well aligned with the outcomes - I'm looking forward to hearing it's working and seeing what kind of code you come up with ( that's if it's something you're going to make public - Otherwise a description is more than enough -

 

[MykeLawson]

Public? Absolutely. I consider all my stuff as a community effort given all the support you all provide me. Wish there was a 'repository' on VCF for that kind of stuff. If there is, and I'm just not seeing it, please point me there.

 

[cj7hawk]

It's kind of this forum *is* the repository - I find some gold using the search function.... Even through Google.

 

[durgadas311]

Public? Absolutely. I consider all my stuff as a community effort given all the support you all provide me. Wish there was a 'repository' on VCF for that kind of stuff. If there is, and I'm just not seeing it, please point me there.

github does provide a lot more than just source-code-control. With README.md allowing hyperlinks, plus github wiki, github issues, and just "readers" for PDFs and text, you can put quite a bit of a project in github. A github repo could replace much of what you do on this forum (i.e. github is the forum, and you just put a link here to the github repo)!

 

[MykeLawson]

Looks like I need to re-think that change to my original plan. If I go back to that, the size of the directory will actually double based on the fact that it used two blocks of 256 bytes (2 sectors) versus the new way which uses 8 block of 256 bytes (8 sectors). So, for now, I'll stick with the first plan I posted.

 

[cj7hawk]

You could also use linked lists as a way to track the files as well - which is a bit more efficient since you only need one byte (or two) for each allocation unit.

 

[MykeLawson]

Well, I'm still plugging away at this RAMdisk project, but progress is slow, and I was off on something else for a bit. But I have a very weird issue I'm thinking I may need to bring before the 'Council of Intelligent People" (you all) quite soon. So, stay tuned....... I just didn't want anyone to think I gave up.....

 

[MykeLawson]

Well Bill (Plasmo) flipped the switch in my brain that got me on the part to fixing the weird issue I was having with the MDTEST part of this RAMdisk project. Now back at the MDFRMT program, I am trying to figure out something that has always kind of bothered me, assembler directives. So, the code I have is writing 'something', just not the right 'something'. The logic appears to be correct, so I'm leaning toward a misuse of the assembler directive. Probably another rookie mistake.....

 

[MykeLawson]

Well, after some head scratching and countless re-assembly, upload, and test cycles, I have the MDFRMT program working the way I want and formatting the RAMdisk memory as desired. So, the next module in this project is MDDIR so I can see what is on the disk. I need to write a short test program to stick some dummy directory entries in so I can debug things as I go. Anyway, here is the MDFRMT program.