Talk:INT 13H

Years

It would be nice if someone could add the information when (in which year) the various extensions were developed or appeared... --80.134.8.119 08:37, 8 July 2007 (UTC)

Merger from BIOS interrupt call of INT13 Section Only

Just wanted to say I agree this article is a much better location for all those INT13 specific tables, etc. Let the merger proceed; pref. by someone who can smoothly integrate the material into this article; not just dump it here. Daniel B. Sedory 03:37, 3 December 2007 (UTC)

I agree, they pretty much describe the same thing. --Ramu50 (talk) 16:44, 1 June 2008 (UTC)

Move to INT 13h?

This is usually called int 13h, to make it clear it's a hexadecimal number. Should this page be moved to int 13h, or should we leave it as it is? System86 (talk) 15:22, 31 December 2007 (UTC)

I noticed as I was googling that the the spanish Wikipidia article seems to be named Int 13h, and it does seem to be a more appropriate name. -SamB (talk) 19:27, 20 July 2010 (UTC)

I would guess the "INT 13H" was based on the Intel assembler's syntax. Intel syntax assembly language uses an 'h' suffix to indicate a hexadecimal number. Meanwhile AT&T syntax assembly language uses a '0x' prefix (similar to C) to indicate hexadecimal numbers. Nearly all flavors of assembly language are case-insensitive. Nowadays, most pieces of assembly language you'll see today are lowercase, and assemblers using Intel syntax (notably as86) also support the '0x' prefix. I guess this would argue for renaming it "int 0x13".

As far as title goes though, I must note a larger issue. This is strictly for an IBM-PC. On other systems interrupt 0x13 may well be completely unrelated to disk I/O operations. For the most part non-IBM-PC x86 systems are rare, but they do exist, I've noted some higher-end NASes use Intel processors. Perhaps "PC-BIOS int 0x13" would be better? 75.101.123.180 (talk) 06:46, 8 April 2011 (UTC)

INT 13h (small h for hex.) is just the way how Intel x86 assembler programmers like me talk about opcode CD 13, because they hate confusions with INT 13 (hex. 0D). C-syntax as in 0x13 and supported by some assemblers is not how they talk about it, take RBIL as an example. Of course Intel x86 or similar is no Mac, other CPUs haver other rules, maybe they say SVC or DIAG or whatever instead of "interrupt", or have no concept of 256 interrupt vectors, nothing wrong with that: The INT 13H article is for x86 CPUs with a Phoenix or similar BIOS. It is not about Android, IBM mainframes, or Linux-portability. –89.204.153.128 (talk) 13:17, 31 July 2011 (UTC)

I wholeheartly agree, this (and similar) article(s) should be renamed into "INT 13h" or "PC BIOS INT 13h", that is, with a lowercased "h" to indicate "hex". An encyclopedia should not use programming language specific notations such as "0x" or assume "insider knowledge", but use the normal notation for hex-numbers, that is appending a "h" to the value. --Matthiaspaul (talk) 13:05, 13 September 2011 (UTC)

Separate section for extension

Wouldn't it be more logical if the information about the int 13h extension was placed in its own section? It would make the structure of the article friendlier and easier to refer to the extension in other articles. 17:23, 27 September 2010 (UTC) —Preceding unsigned comment added by Drakeneld (talk • contribs) 17:23, 27 September 2010 (UTC)

DOS functions 25h and 26h

Is there much additional information available on these anywhere? I'm just interested to find out if some variant on these are the reason why, with some sneaky repartitioning, I was able to use the full capacity of a 250GB hard disk under Windows 98...

(Two partitions, "125GB" each (~125,000,000,000 bytes, or 116 "real" gigabytes), with the start of the second partition therefore coming in under the "137GB" limit, and itself being smaller than that... Windows specs the start of the partition to be accessed within its own 32-bit addressing limit (...somehow? given that the 137 limit was based on 2^32 x 32KB clusters, not 2^37 x 512-byte sectors?), and then indexes to a particular cluster within that partition using 25h?)

I never did figure out how it worked, after accidentally discovering it (only the first of three 80-ish GB partitions could be created/accessed, a single 250 was impossible, and no other variant allowed creating one beyond "137gb" (128GiB), but 116+116 worked just fine), so it'd be nice to know the mechanism of it... plus, it might be useful to share the knowledge for old hardware tinkerers :D 193.63.174.211 (talk) 11:42, 1 August 2013 (UTC)

You won't find it here. Try [www.ctyme.com/intr/int.htm Ralf Brown's Interrupt List].124.171.80.71 (talk) —Preceding undated comment added 06:38, 2 August 2013 (UTC)

I'm 7 years late to this particular party, but never mind... First, take care of the confusion. Int25/26 are often billed as accessing 'absolute' sectors. This is false. It's LOGICAL sectors. It's better to use VWIN32_DIOC_DOS_DRIVEINFO to do what those do unless you need strict compatibility with the original W95 releaase and do not need FAT32, which is very unlikely. That aside, even the true absolute sector access given by INT 13h extensions might fail if the media is not supported by more than 28 bits for sector addressing, even though the START of the second slice is inside the 128 (137) boundary. If the drive is on USB or Firewire, attached or detected AFTER the OS loads, then ESDI_506 must also be patched for 48 bit LBA! 'Seeing' the data on the second slice does not mean that part of it, written beyond that boundary, hasn't just destroyed data near the start of the FIRST slice! This is another reason why it's critical not be confused by that misused term 'absolute sector access' for INT 25h/26h, because it's not absolute at all, and that makes them dangerous as well as best replaced with VWIN32_DIOC_DOS_DRIVEINFO if you want to access logical sectors directly. (And it's all moot in any OS other than Win9X anyway because other systems offer easier and better ways, like opening PhysicalDriveN with DeviceIOControl in NT kernel OS's.)

The short answer, which only makes sense with all that context included, is that if the LOGICAL drive has a size expressible within a 28 bit sector count (up to 128 GB), then it can ALL be accessed even if it extends beyond the absolute 128 GB boundary, but only if the underlying support doesn't convert to a true absolute sector count with only 28 bits to count with. So... it may LOOK safe, but it likely is not. It's only reliable if ALL possible subsystems have adequate sector addressing resolution. Some count with 32 bits (up to 2TB), others with 48, and some with 64. These confusions look set to continue well into the future as disks get bigger and new boundaries are reached. 81.187.19.110 (talk) 10:02, 4 December 2020 (UTC)

Make alignment details explicit?

In the article for INT 13h AH=42h: (read sector(s) from drive) it says this:

04h..07h 4 bytes segment:offset pointer to the memory buffer to which sectors will be transferred (note that x86 is little-endian: if declaring the segment and offset separately, the offset must be declared before the segment)

As a newcomer I interpreted this as allowing the offset and segment to be declared as two 2-byte chunks of the disk access packet, and broke my code. :) After testing to see whether the order of of separate declaration of offset and segment was in error, and finding it wasn't, but still failed, I tried breaking it down into bytes just to explore it, and the oddness that results was WAY beyond mere accidental reversals of word order. After rebooting to clear the system I found that a simple ASM 'dd' declaration for a DWORD made it work, so it seems that declaring a DWORD forces alignment as a DWORD.

The article ought to be amended to make this segment:offset detail explicit because the existing text is ambiguous unless it explicitly asserts that the word order MUST be in the context of a 4-byte value. If people are to be able to rely on the article as a source of learning, that ambiguity must be removed. 81.187.19.110 (talk) 02:28, 29 November 2020 (UTC)

INT 13h AH=15h, Drive type.

There is no description on the main page for INT 13h AH=15h, and as Wikipedia apparently despises 'original research' I won't be adding one. For what it's worth, my findings are that when an SD or CF card is connected by USB during a W98 session, it is not detected by the INT 13h extended calls unless the OS or another program has prompted the OS to allow it. All values for disk geometry including the 64 bit LBA field, are at zero! The normal INT 13h AH=08h call includes it in a hard disk count, and tools like PTedit, PartInfo, and Gdisk can all give an accurate capacity value. Once the OS allows it, any subsequent use of INT 13h AH=48h to read the LBA sector count is fine, as is the bytes-per-sector value, so we can calculate the disk capacity.

Which brings me to INT 13h AH=15h... If a disk on USB or Firewire is inserted AFTER the OS is loaded, the BIOS is not involved, and the correct sector count is given even if INT 13h AH=48h fails. This is true even for a 2TB disk so at least 32 bits are used to express that count. I'd hoped to find something like this because it was already clear that the three commercial tools I named had some way to get that information. Bytes-per-sector must be assumed to be 512 in this case, but I think it's safe to assume that it is, for any new SD or CF card.

I could not test a larger disk (I don't have one) but I suspect that even more than 2TB might be correctly gauged by the INT 13h AH=15h (drive type) call even though it's NOT an extended call, provided that the OS is patched for 48 bit LBA addressing (patched ESDI_506.PDR, as done by RLoew or Tihiy (details can be found on the MSFN Forums and perhaps elsewhere). I suspect that another patch is needed to go beyond 2TB so I assume that's it's a good upper limit to stay with in W98!

One other thing... If a disk is on USB or Firewire, and NOT bootable, but the BIOS could boot from it if it were, then on loading, the OS will give it TWO drive letters, and various degrees of unrest ensue with no doubt hilarious consequences, but I decided not to tempt fate once I saw the first BSOD. :) This is good GENERAL advice though, unless INTENDING to boot, do NOT plug in media the BIOS might recognise and cause conflicts with the OS's own methods, not least because INT 13h AH=15h will FAIL, limiting its reckoning of capacity to the largest that CHS could specify as standard (8GB). If this general caution is heeded, INT 13h AH=15h is VERY useful to gauge capacity of removable media correctly when other methods fail, even if it's completely blank. For this reason it likely deserves a complete writeup. I've given all the useful info I can here, but it IS my own research so it will need someone willing to find corroborating sources if they think it's worth adding to the main page. (it is).

One small but important detail is the memory address 0040h:0075h. Don't use it. It only counts disks detected by BIOS before the OS loads. Use INT 13h AH=08h to get a count of all disks added, before and since OS start. To get geometry correctly, test for INT 13h extensions on every disk number from 08h upwards until the number of supported disks matches the known count, because gaps may appear if disks are plugged and removed in random order! When the list is built, use INT 13h AH=48h to get sector count and sector size, then if sector count is zero, fall back on INT 13h AH=15h which will work, but leave sector size unknown. This makes the AH=15h call important because it's not just redundant info. It works even when the main method fails, and it's especially good at doing that when removable cards have been changed during a session. 81.187.19.110 (talk) 01:50, 5 December 2020 (UTC)