3

I need to access SSD drive with NASM 16-bit code. When accessing regular hard drive, need to set registers AX, DX, CX to choose Cylinder/Track/Sector/Number of sectors (AH - to choose read sector function, DL - to choose drive number, CH - to choose cylinder, DH - to choose side on disk, CL - to choose sector on track, AL - to choose number of sectors).

However, I suppose SSD disk has some other structure, so how to access them correctly?

stackoverflower
  • 545
  • 1
  • 5
  • 21
  • 4
    Whether you have an SSD or HDD does not make a difference. Even on HDDs, the CHS structure is just emulated because modern hard disks have way more than 63 sectors per track. – fuz Dec 14 '19 at 14:37

1 Answers1

6

Assuming translation of fake geometry into LBA (the most likely case), "int 0x13, ah=0x02" can only handle a maximum of 16515072 sectors. At 512 bytes per sector (also the most likely case) that works out to 8064 MiB or about 7.8 GiB. Hard drives (including SSDs) have been larger than this for about 2 decades; so "int 0x13, ah=0x02" isn't a sane option.

Instead, for hard drives (including SSD) you want to use "int 0x13, ah=0x42" (see http://www.ctyme.com/intr/rb-0708.htm ). This function uses LBA addresses and doesn't use CHS; and (with 64-bit LBA address and the same 512 bytes per sector) it can handle (up to) 8589934592 TiB drives.

Brendan
  • 35,656
  • 2
  • 39
  • 66
  • Interesting, that after I changed **AH** to 0x42 I got an error status code **01h** which according to this table http://www.ctyme.com/intr/rb-0606.htm means "invalid function in AH or invalid parameter", and with **AH=0x02** some data was actually read from disk (using code from here https://stackoverflow.com/questions/59338886/nasm-disk-read-timeout). Is it because of 16-bit code? – stackoverflower Dec 15 '19 at 15:14
  • @stackoverflower Given that this interface is only available in real (16 bit) mode, it is not because of 16 bit mode. Please post a new question with that. – fuz Dec 15 '19 at 19:41
  • 1
    @stackoverflower: For "int 0x13, ah=0x42" returning "invalid function"; I'd suspect that the drive number (in `dl`) didn't correspond to a valid hard disk/SSD. For example, if DL=0 (first floppy disk) you'd expect "int 0x13, ah=0x02" to work and "int 0x13, ah=0x42" to not be supported. – Brendan Dec 15 '19 at 20:41
  • I checked it with qemu, I thought qemu see bootloaders code as a separate drive or something like this.. – stackoverflower Dec 16 '19 at 00:48