OSDev.org https://forum.osdev.org/ |
|
issue with int 0x13 https://forum.osdev.org/viewtopic.php?f=13&t=35180 |
Page 1 of 2 |
Author: | Armature [ Mon Oct 07, 2019 7:30 am ] |
Post subject: | issue with int 0x13 |
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 |
Author: | iansjack [ Mon Oct 07, 2019 7:47 am ] |
Post subject: | Re: issue with int 0x13 |
You appear to be trying to write the sector to the BIOS ROM (()xFE000). |
Author: | Armature [ Mon Oct 07, 2019 10:37 am ] |
Post subject: | Re: issue with int 0x13 |
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. |
Author: | iansjack [ Mon Oct 07, 2019 11:58 am ] |
Post subject: | Re: issue with int 0x13 |
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. |
Author: | Armature [ Tue Oct 08, 2019 6:22 am ] |
Post subject: | Re: issue with int 0x13 |
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? |
Author: | Octocontrabass [ Tue Oct 08, 2019 6:50 am ] |
Post subject: | Re: issue with int 0x13 |
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.) |
Author: | iansjack [ Tue Oct 08, 2019 6:52 am ] |
Post subject: | Re: issue with int 0x13 |
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. |
Author: | Armature [ Tue Oct 08, 2019 7:21 am ] |
Post subject: | Re: issue with int 0x13 |
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 |
Author: | Armature [ Tue Oct 08, 2019 7:36 am ] |
Post subject: | Re: issue with int 0x13 |
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 |
Author: | Armature [ Tue Oct 08, 2019 7:42 am ] |
Post subject: | Re: issue with int 0x13 |
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 |
Author: | iansjack [ Tue Oct 08, 2019 8:27 am ] |
Post subject: | Re: issue with int 0x13 |
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). |
Author: | Armature [ Fri Nov 08, 2019 6:21 pm ] |
Post subject: | Re: issue with int 0x13 |
Right, its been a while, university work sort of piled up quickly. I've had a few moments to breathe so I thought id get back to this. I've re-written the code for the LBA to CHS conversion but its still not working. I've narrowed it down to two possible issues. The first being the code that converts the LBA and the second being an incorrect value from reading the RootDirectory or FAT. I'm hoping its the conversion that's wrong. This is the code I'm using right now: Code: pusha ;0050)Preserve all the registers by moving them to the stack mov si, NxtSect ;0051)Set the source index to the memory location of the next LBA mov ax, FIHPT ;0052) mov bx, FISPT ;0053) mul bx ;0054) mov bx, ax ;0055) lodsw ;0056) div bx ;0057) mov di, CylinderTMP ;0058) stosw ;0059) the lower ten bits of AX is the cylinder the data is stored on mov ax, dx ;0060) take the remainder from the divide operation and store it in ax mov bx, FISPT ;0061) div bx ;0062) mov di, Head ;0062) stosb ;00064)AL should be the head of the disk. inc dx mov ax, dx mov di, SectorTMP mov si, CylinderTMP xor ax, ax xor bx, bx lodsw mov word ax, [si] shr ax, 6 mov di, SectorTMP mov bx, ax lodsw shr ax, 10 shl ax, 10 or ax, bx mov si, CylinderSector stosw popa ret Yes I know its incredible in-efficient, but I wanna get the actual code working before I start optimising. The values being used, such as FISPT are: Code: ;1.44MB Floppy Information 3.5-=-=-=-=-= FIBPS equ 0x0200 ;0000) The number of bytes in each sector FISPC equ 0x01 ;0000) The number of sectors that exists with in a cluster FIRE equ 0x00E0 ;0000) The total number of root director ientries FIMT equ 0xF0 ;0000) The type of media being read FISPF equ 0x0009 ;0000) The number of sectors that makes up the FAT FISPT equ 0x0012 ;0000) The number of sectors on each track FIHPT equ 0x0002 ;0000) The number of heads on the disk Is there anything obliviously wrong that I'm missing. I've gone through ti several times even noting it down with pen and paper and yet it still doesn't work. After the conversion I. get the values: AX = 0x0201 BX = 0xE000 CX = 0x0000 DX = 0x3900 ES = 0x0000 The disk I'm using is a 1.44mb floppy disk formatted with FAT12. Any help would be great because this is driving me crazy. |
Author: | BenLunt [ Fri Nov 08, 2019 7:00 pm ] |
Post subject: | Re: issue with int 0x13 |
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 Just real quick, the problem may not be with the LBA to CHS conversion, nor the actual read routine. It probably is with the original source location. For example, on a 1.44Meg disk with 80 cylinders, 2 heads, and 18 sectors per track, you can't have more than 2880 sectors. Therefore, how do you calculate a cluster of 6656? With a 1:1 ratio of clusters to sectors, you cannot have a cluster number above 2882. Have a look at your code to calculate where the root directory is. I think the 6656 is the indication of where the error might be. With this in mind, on a FAT12 floppy, you don't have a cluster number for the root. You have to figure it out yourself. There are so many sectors for the boot (normally 1, but indicated in the BPB), one or more FAT's, each of a size specified in the BPB, and the the root following that. Here is a common layout: Code: Sectors Item 1 Boot Code 9 First FAT 9 Second FAT 14 Root 2847 Data sectors/clusters FAT32 file systems give you a cluster number for the root, not FAT12 or FAT16 file systems. Ben - http://www.fysnet.net/osdesign_book_series.htm |
Author: | Armature [ Fri Nov 08, 2019 7:19 pm ] |
Post subject: | Re: issue with int 0x13 |
BenLunt wrote: 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 Just real quick, the problem may not be with the LBA to CHS conversion, nor the actual read routine. It probably is with the original source location. For example, on a 1.44Meg disk with 80 cylinders, 2 heads, and 18 sectors per track, you can't have more than 2880 sectors. Therefore, how do you calculate a cluster of 6656? With a 1:1 ratio of clusters to sectors, you cannot have a cluster number above 2882. Have a look at your code to calculate where the root directory is. I think the 6656 is the indication of where the error might be. With this in mind, on a FAT12 floppy, you don't have a cluster number for the root. You have to figure it out yourself. There are so many sectors for the boot (normally 1, but indicated in the BPB), one or more FAT's, each of a size specified in the BPB, and the the root following that. Here is a common layout: Code: Sectors Item 1 Boot Code 9 First FAT 9 Second FAT 14 Root 2847 Data sectors/clusters FAT32 file systems give you a cluster number for the root, not FAT12 or FAT16 file systems. Ben - http://www.fysnet.net/osdesign_book_series.htm I've already loaded both the FAT and root Directory into a memory location. I'm not searching for that. I'm searching for a file that's on the disk. As for the value I was getting from the root directory, I said I think I'm getting the wrong one. I think its meant to be 0x001A which would be sector 26 |
Author: | Octocontrabass [ Sat Nov 09, 2019 2:32 am ] |
Post subject: | Re: issue with int 0x13 |
Armature wrote: Is there anything obliviously wrong that I'm missing. Yes. When you use the DIV instruction with a 16-bit operand for the divisor, the implied operand for the dividend is a 32-bit value, with the low bits in AX and the high bits in DX. Since you want to use a 16-bit dividend, you need to zero-extend the value to 32 bits by setting DX to 0 before division. Similarly, the MUL instruction with a 16-bit operand places the 32-bit product in DX:AX. Some clever optimizations are possible if you know the product will always be a value that sets DX to zero. And since I don't see it in any of the code you've posted so far, make sure you've cleared (or set) the direction flag before you use string instructions. It's not safe to assume the BIOS will always clear it for you. |
Page 1 of 2 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |