Problems with int 0x13 ah 0x42, DAP: readSector();

[Ariethenor]

I am going to say in advanced that i am sorry if this proplem has already been solved elsewhere, i have scoured the forums for hours to no avail:

Here is the problem, I am trying to write a "readSector()" method. needless to say it is not working.


my code:

Code: Select all

//prototypes
void main(void);
int readSector(char* buf, unsigned long sector);

typedef struct{
	unsigned int res_SoDAP;
	unsigned int  numBlocks;
	unsigned int bufferOff;
	unsigned int bufferSeg;
	unsigned long startABSL;
	unsigned long startABSH;
}DAP, *pDAP;

void main(void){
    char buffer[512];     //buffer for readSector()
    
    // some other stuff kernel "init()" and what not (all this works).

    buffer[0]='t'; // debugging purposes, this should be overwritten by readSector();
    readSector(buffer, 30); // a text file is loaded with dd on sector 30.
    printString(buffer); // already know this procedure works, "kernel loaded" is displayed on lower left right hand corder after init() stuff is ran.
    //prints the " 't' " that i manually loaded, not the message in the text file. (this is the result of the bug i can't find).

    // some more stuff, the program "OS" does this stuff so it is making it past the readSector procedure without hanging, but not doing as told.
};

compiler listing for snipet above:

Code: Select all

! 80 	readSector(buffer,30);
! Debug: list int = const $1E (used reg = )
mov	ax,*$1E
push	ax
! Debug: list * char message = S+$246-$243 (used reg = )
lea	bx,-$241[bp]
push	bx
! Debug: func () int = readSector+0 (used reg = )
call	_readSector
add	sp,*4
!BCC_EOS
! 81 	printString(message);
! Debug: list * char message = S+$244-$243 (used reg = )
lea	bx,-$241[bp]
push	bx
! Debug: func () int = printString+0 (used reg = )
call	_printString
inc	sp
inc	sp

readSector():

Code: Select all

int readSector(char* buf, unsigned long sector){
	DAP rsDAP;
	pDAP prsDAP = &rsDAP;
	
	rsDAP.res_SoDAP = (unsigned int)0x0010;
	rsDAP.numBlocks = (unsigned int)0x0001;
	rsDAP.bufferOff = (unsigned int)buf;
	rsDAP.bufferSeg = (unsigned long)0xFFFF;
	rsDAP.startABSL = (unsigned long)sector;
	rsDAP.startABSH = (unsigned long)0x00000000;
	
	asm("mov si, -$16[bp]\n\t" \
		"mov ah, *$42\n\t" \
		"mov dl, *$80\n\t" \
		"int *$13");
	
	return 1;
};

compiler listing: (kernel is in HiMem area)

Code: Select all

! 229 int readSector(buf,sector)
! 230 # 229 "kernel.c"
! 229 char* buf;
export	_readSector
_readSector:
!BCC_EOS
! 230 # 229 "kernel.c"
! 229 unsigned long sector;
!BCC_EOS
! 230 # 229 "kernel.c"
! 229 {
! 230 	DAP rsDAP;
!BCC_EOS
! 231 	pDAP prsDAP = &rsDAP;
push	bp
mov	bp,sp
push	di
push	si
add	sp,*-$12
! Debug: eq * struct  rsDAP = S+$18-$16 to * struct  prsDAP = [S+$18-$18] (used reg = )
lea	bx,-$14[bp]
mov	-$16[bp],bx
!BCC_EOS
! 232 	
! 233 	rsDAP.res_SoDAP = (unsigned int)0x0010;
! Debug: eq unsigned int = const $10 to unsigned int rsDAP = [S+$18-$16] (used reg = )
mov	ax,*$10
mov	-$14[bp],ax
!BCC_EOS
! 234 	rsDAP.numBlocks = (unsigned int)0x0001;
! Debug: eq unsigned int = const 1 to unsigned int rsDAP = [S+$18-$14] (used reg = )
mov	ax,*1
mov	-$12[bp],ax
!BCC_EOS
! 235 	rsDAP.bufferOff = (unsigned int)buf;
! Debug: eq unsigned int buf = [S+$18+2] to unsigned int rsDAP = [S+$18-$12] (used reg = )
mov	ax,4[bp]
mov	-$10[bp],ax
!BCC_EOS
! 236 	rsDAP.bufferSeg = (unsigned long)0xFFFF;
! Debug: eq unsigned long = const $FFFF to unsigned int rsDAP = [S+$18-$10] (used reg = )
mov	ax,#$FFFF
mov	-$E[bp],ax
!BCC_EOS
! 237 	rsDAP.startABSL = (unsigned long)sector;
! Debug: eq unsigned long sector = [S+$18+4] to unsigned long rsDAP = [S+$18-$E] (used reg = )
mov	ax,6[bp]
mov	bx,8[bp]
mov	-$C[bp],ax
mov	-$A[bp],bx
!BCC_EOS
! 238 	rsDAP.startABSH = (unsigned long)0x00000000;
! Debug: eq unsigned long = const 0 to unsigned long rsDAP = [S+$18-$A] (used reg = )
xor	ax,ax
xor	bx,bx
mov	-8[bp],ax
mov	-6[bp],bx
!BCC_EOS
! 239 	
! 240 	asm("mov si, -$16[bp]\n\tmov ah, *$42\n\tmov dl, *$80\n\tint *$13"
!BCC_ASM
	mov si, -$16[bp]
	mov ah, *$42
	mov dl, *$80
	int *$13
! 241 
! 242 
! 243 );
!BCC_ENDASM
!BCC_EOS
! 244 	
! 245 	return 1;
mov	ax,*1
add	sp,*$12
pop	si
pop	di
pop	bp
ret
!BCC_EOS
! 246 };

I know the dap structure is different, but I had to combine/be creative about it, the bits are assembling in the correct order, I used a Hex viewer and compared the DAP "struct" to the same "DAP" i used in my boot loader which works. I had to combine the size of dap and reserved word creating res_SoDAP (the "short ints" weren't being allocated properly making my DAP structure the wrong size, I had to make them a single int). I read a note on OSDev somewhere that when segment and offset are separate, offset must be declared first. I had to split the quadword into two dwords as i have no qword type specifier. I am pretty sure it is structured correctly, I have tried all permutations including flipping it upside down, and none works, the current configuration is identical to the structure that loads my OS into HiMem, and that works.

I am just looking for the small detail I missed, Thanks in advance, I have been debugging this one issue for 3 days now and would like to move forward.

[Mikemk]

are you compiling it for real mode?

[Ariethenor]

yes i am compiling it for real mode.

[DavidCooper]

I can't follow the code you've posted, but it looks as if there isn't enough there to work with. Even so, it shouldn't matter because you're going to debug this yourself. You need to write a routine to display the contents of your DAP at the point just after it's been formed and then post the result here if you aren't sure if it is right or not. The FFFF sector value suggests you're wanting to load something in above the 1MB point, but as your kernel is above that there can't be any issue with the A20, so assuming that you're actually running your code in real mode and in low memory, there isn't a lot else that can go wrong, although often the problem is that people try to load data from the wrong disk location, so you ought to check to see if something is being loaded in in the right place (if you haven't already done that).

[Ariethenor]

The problem "magically" *&%#$^ fixed itself... I was writing a debugging routine to check it... finished writing the routine, and compiled, but did not implement the routine, ('cause I always compile before i implement to make sure there are no typo's), fired the program up in bochs... just to make sure things are still "as it should be" or "as it was (as is frequently the case)" and readSector() worked as it was supposed to. Don't know what actaully changed. I love OS developement , but now I have a working memory dump routine too!!!

[DavidCooper]

Things that fix themselves by magic are dangerous - they tend to unfix themselves by magic later on at a time when tracking them down is a lot more inconvenient. It is never a good idea to move on without finding out why it failed and why it suddenly stopped failing, unless you know of a specific change you make which eliminated some badly designed code that was likely to have been causing the bug. Don't leave a magical fix in your code.

[Ariethenor]

I am pretty sure i found it... i had to do a restart of my "real" computer running ubuntu linux, and i think it stored my file i was trying to load into a temporary buffer instead of straight to the hdd image that i boot from or something like that(my best guess)... 'cause it was after the restart that everything worked... it just happened that it was also after that restart that i wrote the debug code that i was intending to use to find the problem. The other thing that it may have been is that i remember reading somewhere one time that the dap has to be word alligned on a 0x10 boundry or something, but I have seen other posts saying it doesn't... but i have been adding more to my OS, testing, removing, changing without any "alignment checking" and things are still working correctly, so i am more convinced(for now) it was something on the linux/bochs end of things more then in the programming itself. the OS also boots "raw" from a bootable flashdrive and works correctly so, all I can do is run with it for now untill perhaps it rears its ugly head again.