• Please review our updated Terms and Rules here

CP/M 2.2 STAT command

Well.....I've been playing around with the CP/M ED command. I can make a text file and edited it with no troubles. Seems that it also makes a back up copy as *.BAK. At first, I was a little confused in that the very first BAK file was empty. Well, so is the source file at the beginning. As you edit the file again and again then the BAK file has some thing in it.

I have run into another problem. This time it is with the TYPE command. When I first started I had small text files, less than 128 bytes or one record. The TYPE command worked fine displaying these small files. Later when I started to make larger files, more than one record, the TYPE command didn't work completely. For some reason, it will display the first record as before, but for the next n records of the file, it just re-displays the first record, n times. It doesn't seem to increment the record number when displaying the file. Yet when I display the same file in ED with a '20T' it is displayed properly and if it is changed, those changes are also correct. I checked using IMD to see if the extent #, allocation blocks, etal in the directory were correct and everything looks OK. I'm wondering if my ED.COM that I copied from my original 8" disk may be corrupt. Mike
 
Have you considered adding a bit of debug code in CBIOS disk read/write code to display what you're doing (i.e. read track/sector/cylinder)? That would be my first move. The TYPE function is pretty brain-dead.

How do things look if you try PIP CON:=yourfile ?
 
I've had code in my CBIOS on and off just to do whatyou suggest. I should make a routine to make it easier.

I tried PIP CON:=myfile.txt and it displays just like it should. Still think there is a problem in the TYPE command. Looking through the code. Even if it's not there, it's fun to figure out how this stuff works. Thanks, Mike
 
Well..... I'm on the trail of this problem. So far I have found that the program has made the correct request for sectors. I have a sample.txt file that has three records. I found that the cpm program requests the correct drive, track, sector and dma address for each of the records in this file. I checked the disk with IMD and found that these are the correct sectors and they indeed have the data that is needed. Hopefully today, maybe I can verify that each sector made it to the sector buffer at 000 200 (00 80h). Mike
 
I'm not sure, but I think my problem is that the DMA parameters are not being set each time a sequential record is being requested. My test file, sample.txt has 3 records and the first record is being read into the sector buffer at 80h. But the 2nd and 3rd are not. My SETDMA code in CBIOS sets the address, the terminal count, enables and unmasks. I think that maybe CPM thinks that once the address is set once it doesn't need to set it again. The TYPE command reads sequential records in to the buffer 80h each time. I have not found the spot where the DMA is set during the type command. My SETDMA code looks like this;
Code: 
SETDMA, PUSHPSW
             LDA DMALSBAD  ;load LSB of DMA
             OUT DMAADDRPT
             LDA DMAMSBAD ;load MSB of DMA
             OUT DMAADDRPT
             OUT DMAFF
             MVIA DMA TC    ;load lsb  terminal count
             OUT DMATCPT
             MIVA 000          ;load msb terminal count
             OUT DMATCPT
             MVIA DMACREN  ;enable DMA
             OUT DMACTRLPT
             MVIA DMAUNM0  ;unmask channel 0
             OUT DMAMSKPT
             OUT DMAFF
             POPPSW
             RET
I think I'll try to trap when SETDMA is called to see if this maybe the problem. I'm wondering if I need to have the DMA chip do a auto initialize or something like that. Mike
 
I think that maybe CPM thinks that once the address is set once it doesn't need to set it again.
Click to expand...

Definitely true. The same goes for track and sector as well. Your CBIOS is expected to remember those from the last call. In other words, 5 successive calls to READ without any other intervening calls are expected to read the same sector into the same location as the first.
 
Interesting. I do save the Drive, Track, Sector and DMA address, but do not re initialize the DMA terminal count. I had thought that for each READ or WRITE, the SETDMA routine would be called. I 'll try adding some code to set the DMA terminal count at the beginning of the READ and WRITE. I really should not have to enable or un mask the channel everytime. Mike
 
Now you understand why the SETxxx routines are best implemented by saving the information and delaying until you get a READ or WRITE call. CP/M can't multitask disk functions (although MP/M can), so there's no benefit to be gained by not doing things that way.
 
Chuck you mention MP/M from time to time, but nobody seems to be interested in it? Wikipedia article about MP/M or CP/M Plus is extremely concise. I am wondering if there is good source of information and perhaps some recent implementation of these "better" CP/Ms. Is it worth try?
 
From what I understand MP/M is sort of like a multitasking/multiuser server-edition of CP/M. When using it for an actual multi-user setup you better need a fast system.

The manuals, at least, are available online.
 
Structurally, the differences between MP/M and CP/M are considerable. While a CBIOS is necessary for booting, the implementor must also supply an XIOS, which is more the strategy/interrupt model. Bankswitching, although not strictly necessary, is also pretty much a a requirement for practical operation. There is also a timer interrupt. Use of PRL rather than COM files for utilities is also pretty much necessary for efficient memory usage.

It took me about three times as much effort to implement an I/O system for MP/M than that required for CP/M. Crashes were frequent and very hard to pin down. When it worked, it worked well, considering the use of a "flat" directory structure using "User area" qualifiers to separate user spaces. No security, of course, at all.

MP/M II is much improved over original MP/M.
 
You must log in or register to reply here.
Back
Top