OSDev.org

The Place to Start for Operating System Developers
It is currently Sun Oct 20, 2019 12:46 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: issue with int 0x13
PostPosted: Mon Oct 07, 2019 7:30 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
At this point in time, I have successfully written a FAT12 boot loader that can successfully load into memory the FAT12 FS, find the kernel on disk and load that into memory and then jump to the executing point of the kernel. I then started work on a disk driver for the kernel. An incredibly rudimentary one using the 0x13 interrupt. The kernel, from what. I can gather, successfully loads finds the File in the root director, retrieves the cluster number of said file, converts it to LBA and then calls for the data to be read from disk. It is at this point the carry flag is set, and the value 0x01 is placed in AH indicating. an invalid command. I have searched through this piece of code for days, Heres the code:

Code:
ReadDisk:
   pusha
   clc         ;0000) Clear the carry flag just in case set which would flag this as failing
   mov ax, 0xF000      ;0000) Test location, needs to be changed when the kernel is finished
   mov es, ax      ;0000) Test location, needs to be changed when the kernel is finished
   mov si, CylinderSector
   mov word cx, [si]
   mov si, Head
   mov dh, [si]
   xor dl, dl
   mov al, 0x01
   mov bx, 0xE000      ;0000) [0xF000:0xE000 | 0xFE000]Test location needs to be changed when the kernel is finished
   mov ah, 0x02
   int 0x13
   jc DiskError
    mov al, 0x01        ;0000) Returns one which indicates the  operationw as a success
    mov di, DskStatus
    stosb
   popa
   ret
DiskError:
   mov si, DSKERR
   call WriteString
   xor al, al
   mov al, ah
   call WriteHex
   mov si, LINEEND
   call WriteString
   mov di, DskStatus
   mov al, 0x00
   stosb
   popa
   ret


Am I just being incredibly stupid and the fault be in plain sight? Any help would be greatly appreciated


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Mon Oct 07, 2019 7:47 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3513
Location: Chichester, UK
You appear to be trying to write the sector to the BIOS ROM (()xFE000).


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Mon Oct 07, 2019 10:37 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
iansjack wrote:
You appear to be trying to write the sector to the BIOS ROM (()xFE000).


I have rectified the mistake but I am still getting the same outcome.


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Mon Oct 07, 2019 11:58 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3513
Location: Chichester, UK
Next you should check that your values for head, cylinder, and sector are reasonable. Running under a debugger with a breakpoint just before the interrupt will let you see what values are in the registers.


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 6:22 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
iansjack wrote:
Next you should check that your values for head, cylinder, and sector are reasonable. Running under a debugger with a breakpoint just before the interrupt will let you see what values are in the registers.


Right, so I think I found the issue but not sure. So I printed the registers used to read the disk to the screen and got these values:

AX - 0x0201 - 0x02 in AH for the reading of said disk and 0x01 in AL for the number of sectors to read, all good
BX - 0xE000 - the offset of the memory location to write to
ES - 0x0000 - the segment
DX - 0x0000 - 0x00 in DH which indicates which head to use on the disk, 0x00 in DL which indicates the boot drive
CX - 0x003A - This is where I think the issue is. This written in binary is 0000000000111010. The first ten bits are zero, which is the first cylinder and the last six is the actual sector number, which in this case converts to the 58th sector on the disk. This can't be correct. After doing some research I believe the last sector on a track is sector 28, or 27 in the register. Am assuming this is what the issue is. Am I correct?


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 6:50 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1662
Armature wrote:
0x00 in DL which indicates the boot drive

0x00 in DL indicates the first floppy disk drive. It may or may not be the boot drive.

Armature wrote:
CX - 0x003A - This is where I think the issue is. This written in binary is 0000000000111010. The first ten bits are zero, which is the first cylinder and the last six is the actual sector number, which in this case converts to the 58th sector on the disk. This can't be correct. After doing some research I believe the last sector on a track is sector 28, or 27 in the register. Am assuming this is what the issue is. Am I correct?

It depends on the geometry of your disk. A typical 1.44MB floppy disk has the geometry (80,2,18) which would mean there are 18 sectors on a track and the last sector is number 18. (Unlike LBA, cylinders, or heads, there is no sector 0.)


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 6:52 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3513
Location: Chichester, UK
It depends upon what type of disk you are using, but the maximum number of sectors per track for PC floppy disks is 36. So I think there must be an error in your routine for calculating these values. The actual value for sectors per track is stored in the boot sector.


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 7:21 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
Octocontrabass wrote:
Armature wrote:
0x00 in DL which indicates the boot drive

0x00 in DL indicates the first floppy disk drive. It may or may not be the boot drive.

Armature wrote:
CX - 0x003A - This is where I think the issue is. This written in binary is 0000000000111010. The first ten bits are zero, which is the first cylinder and the last six is the actual sector number, which in this case converts to the 58th sector on the disk. This can't be correct. After doing some research I believe the last sector on a track is sector 28, or 27 in the register. Am assuming this is what the issue is. Am I correct?

It depends on the geometry of your disk. A typical 1.44MB floppy disk has the geometry (80,2,18) which would mean there are 18 sectors on a track and the last sector is number 18. (Unlike LBA, cylinders, or heads, there is no sector 0.)


At this point in time I'm using a 1.44MB floppy image formatted with FAT12. im going to check to see what went wrong in my LBA to CHS calculation


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 7:36 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
iansjack wrote:
It depends upon what type of disk you are using, but the maximum number of sectors per track for PC floppy disks is 36. So I think there must be an error in your routine for calculating these values. The actual value for sectors per track is stored in the boot sector.


Right so I just checked the calculations and I don't think they're wrong, but once again I could be wrong However I did check the value I was getting from the Root Directory. I got a value of 0x1A00, which in decimal is cluster 6656. I think I should actually be getting a sector value of 0x001A which would be 26. Am I correct in this assumption? im assuming I've just forgotten about the whole little endian thing


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 7:42 am 
Offline

Joined: Wed Apr 25, 2018 2:44 pm
Posts: 21
Armature wrote:
iansjack wrote:
It depends upon what type of disk you are using, but the maximum number of sectors per track for PC floppy disks is 36. So I think there must be an error in your routine for calculating these values. The actual value for sectors per track is stored in the boot sector.


Right so I just checked the calculations and I don't think they're wrong, but once again I could be wrong However I did check the value I was getting from the Root Directory. I got a value of 0x1A00, which in decimal is cluster 6656. I think I should actually be getting a sector value of 0x001A which would be 26. Am I correct in this assumption? im assuming I've just forgotten about the whole little endian thing


Actually no, that didn't seem to fix anything. instead of sector 58 I get 32. which is better I guess


Top
 Profile  
 
 Post subject: Re: issue with int 0x13
PostPosted: Tue Oct 08, 2019 8:27 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3513
Location: Chichester, UK
This link: http://pcrepairclass.tripod.com/cgi-bin ... tochs.html gives you the formula for converting LBA to CHS. Try the conversion by hand, bearing in mind that your disk has 2 heads, 80 tracks and 18 sectors per track. Also remember that the clusters start from the beginning of the data area whereas the LBA starts from the beginning of the disk.

Alternatively, you could use LBA by calling int 13h with ah=42h (Extended read sectors from disk).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group