Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 31

Thread: DOS Disk file access help.

  1. #1

    Default DOS Disk file access help.

    Initially I tried to access disc files in CP/M using the file control blocks (FCB). It all worked very well, open the file, zero a record counter, set the DTA to my preferred address read a record (128 bytes) increment the record counter , test number of records read and exit or increment the buffer address and loop to the next record. This enabled me to put large image hex files in memory in the SOL-20 exactly where I wanted them.

    I have now tried to do this in my 5155 computer in DOS 3.3 using the FCB method at least initially (I know its probably better to use the Xenix/Unix file handle system, which I will try later).The example of the file handle method I have in my books move sectors, and I want to read & move 128 byte records if possible.

    But so far I have had no success trying to get a 61440 byte disk file to memory in DOS . Part of it might relate to memory segmentation and me not knowing how to deal with it. For example, to open a file or read a file the effective address of the FCB is held in ds,dx and that has to be in the PSP area where the FCB is. The DTA (data transfer area) is also defined by ds,dx. I have tried to reassign ds to 3000h (where I would like to put the data at 3000:0000) but pushing & popping ds doesn't work. I also tried a block move program from the effective address of the DTA to higher memory , but I couldn't get that working either.

    The other interesting thing is that in the case of CP/M, you don't have to inform the system of any details of the FCB related to the file you want to read aside from the size, the function calls just use the FCB, but it appears in DOS, using the FCB system, that the calling program has to send a value for the current record which has a 20h address offset from the start of the FCB.

    Any tips on doing this or 8088 assembly program fragments would help me.

  2. Default

    FCBs were just a carry-over from CP/M. You're better off using file handles.

    If you just want to get some file into memory, just use debug. The file will be found starting at 0x100 at the current offset.

  3. #3

    Default

    Quote Originally Posted by Robbbert View Post
    FCBs were just a carry-over from CP/M. You're better off using file handles.

    If you just want to get some file into memory, just use debug. The file will be found starting at 0x100 at the current offset.
    Yes, I have used Debug for this and it works well, but ideally I need a .exe program that does it quickly for any named file on the floppy in my 5155.

  4. Default

    Why does the record size matter?

    If you are porting working code from CP/M, the DOS functions should all be compatible, as long as you properly initialize the FCB to zero and don't modify any internal fields. Sequential read automatically increments the record number.

    When setting the DTA, DOS saves both the DS and DX value in its data area, so the segment can be different from where the FCB is located.

    Or simply use the file handle functions, it is a lot easier. You can read the entire file at once if it's less than 64K:

    Code:
    ;open file for reading
    	mov dx,offset FileName
    	mov ax,3d00h
    	int 21h
    	jc error
    	xchg ax,bx
    
    ;read it
    ;BX = handle, CX = bytes to read, DS:DX => buffer
    	mov cx,61440	;size
    	push ds
    	mov dx,3000h	;segment
    	mov ds,dx
    	xor dx,dx	;offset (zero)
    	mov ah,3fh
    	int 21h
    	pop ds
    	jc error
    
    ;close file
    	mov ah,3eh
    	int 21h
    Instead of relying on a hardcoded memory location, it would be better to include a buffer in your program (can be in its own segment), or allocate it dynamically.

  5. #5

    Default

    Quote Originally Posted by dreNorteR View Post
    Instead of relying on a hardcoded memory location, it would be better to include a buffer in your program (can be in its own segment), or allocate it dynamically.
    The record size doesn't matter too much, I just got used to it in CP/M

    Thanks, I will try this code.

    The reason I want to keep the starting address hard coded is that a number of smaller programs I wrote (that I want to hitch together) already had that address hard coded . Really it should have been an address reference. But initially when I developed the programs and was testing that they were manipulating the bytes properly, I needed to know exactly where they were. When the assembler assigns the addresses I sometimes have trouble finding exactly where the data is.

    One question:

    How does mov dx, offset Filename work (equivalent to LEA dx,Filename probably). Is it required to load the effective address of the filename first from the FCB + 1 where the file name begins in the PSP , or is this function automatic in DOS with the file handle method ?

    (When done with the FCB method when the program is invoked, if the filename.ext immediately follows in the command line, Command com puts that file's FCB at 5ch, so the file's name doesn't have to be hard coded into the program code itself which is very handy).
    Last edited by Hugo Holden; August 14th, 2019 at 04:06 AM.

  6. Default

    Quote Originally Posted by Hugo Holden View Post
    How does mov dx, offset Filename work (equivalent to LEA dx,Filename probably). Is it required to load the effective address of the filename first from the FCB + 1 where the file name begins in the PSP , or is this function automatic in DOS with the file handle method ?

    (When done with the FCB method when the program is invoked, if the filename.ext immediately follows in the command line, Command com puts that file's FCB at 5ch, so the file's name doesn't have to be hard coded into the program code itself which is very handy).
    The file name isn't the same format as in the FCB, it needs to be null-terminated and have a dot between the name and extension. In my example I assumed that it was part of the program, if it should be a parameter you have to parse it from the command line.

  7. #7

    Default

    Quote Originally Posted by dreNorteR View Post
    The file name isn't the same format as in the FCB, it needs to be null-terminated and have a dot between the name and extension. In my example I assumed that it was part of the program, if it should be a parameter you have to parse it from the command line.
    Thanks. Can you show me the code which will parse a file from the command line ?

  8. #8
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,336
    Blog Entries
    1

    Default

    If you want a complete primer on command line parsing, look at http://www.plantation-productions.co...13/CH13-9.html

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,012
    Blog Entries
    18

    Default

    If you're using to parsing CP/M 2.2 command lines, MSDOS/Windows works the same way. Everything after the command is stored in PSP+81h, terminated by a 0dh; 80h is the byte count. DOS never forgot its CP/M roots.

  10. #10

    Default

    Quote Originally Posted by Chuck(G) View Post
    If you're using to parsing CP/M 2.2 command lines, MSDOS/Windows works the same way. Everything after the command is stored in PSP+81h, terminated by a 0dh; 80h is the byte count. DOS never forgot its CP/M roots.
    Chuck, does that mean I can use the PSP +81h as the effective address for the filename prior to the start of the code listed in post #4 ? or would it require more steps ?

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •