Talk:INT 13H

message: 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)
thread_title:  Years 

message: 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)
thread_title:  Merger from [[BIOS interrupt call]] of INT13 Section Only 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Move to INT 13h? 

message: 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)
thread_title:  Separate section for extension 

message: 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)
thread_title:  Make alignment details explicit? 

message: 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)
thread_title:  INT 13h AH=15h, Drive type.