Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Newsgroups | alt.comp.bios, alt.os.development |
| Subject | Re: How to use BIOS int 13h ah=48h ? |
| Date | 2016-04-06 00:10 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20160406001011.196bfc80@_> (permalink) |
| References | <ndqsef$9r8$1@dont-email.me> <20160403173650.55074eb8@_> <ne0b78$m2g$1@dont-email.me> |
Cross-posted to 2 groups.
On Tue, 5 Apr 2016 05:34:50 -0700 bilsch <king621@comcast.net> wrote: > First, good news: I revised the program (see listing below), and for > the first time ah=0x48 returns CF=0 (success) and ah=0. Congratulations! Did you find out the issue with the earlier code? ... > But the number of sectors doesn't work out right. > It says EAB025420000FFFF. Ben made a comment on your print routines being backwards. I'm assuming that this value is word correct, but the QWORD word order is reversed, because things seem to work out below ... Technically, then, assuming EAB025420000FFFF is word correct but the QWORD word order is reversed, then the byte order is B0 EA 42 25 00 00 FF FF. So, the QWORD value is FFFF00002542EAB0. > Backwards EAB02542 is 24520BAE is 609356718 decimal, > times 512 is 311,990,639,616 bytes. But that doesn't > take little endian into account. GPARTED says > 320,071,700,616 bytes. "24520BAE" is "incorrectly" reversed from EAB02542. 24520BAE is EAB02542 reversed by nybbles (4-bits). 4225B0EA is EAB02542 reversed by bytes (8-bits). 2542EAB0 is EAB02542 reversed by words (16-bits). I think you want the last value since your code gets AX. 2542EAB0 is 625142448 in decimal which times 512 gives 320,072,933,376. That is only slightly more than the 320,071,700,616 which GPARTED reported. Some programs use 1000 instead of 1024 for a KB (kilobyte). This is especially true for programs which report disk capacity since manufacturers do that. It would seem that GPARTED is using 500 here instead of 512. I.e., the value 311,990,639,616 from GPARTED divided by 625,142,448 (2542EAB0 in hex) gives 499 ... I'll let you track down the off-by-one discrepancy between 499 and 500, which should be around 7.5GB to 8GB on a 300GB to 320GB drive. If using GPARTED, i.e., Linux etc., maybe check 'fdisk -l' for the reported device capacity. > [snip] > > mov bx,i2xt > xor cx,cx ;cx counts to 1 > pop ax > lup1: ;here ax is data from ah=0x41 > rol ax,4 ;put hi hex digit on right > push ax ;rol'd version > and al,0x0f ;digit in al, is index into i2xt > xlat ;table result in al, bx already > points i2xt mov ah,0xe > int 0x10 ;write > pop ax > cmp cx,1 > je api ;cx=1 then done w/ah > inc cx > jmp lup1 You rolled your own hex routine. That's a good start. Is it your first? There is usually a virtual round of applause for your first one on x86! (clap! clap!) There are many other ways to do hex for x86, including some which are faster (larger) and some that are much shorter. E.g., some simply add a value to a nybble, IIRC 0x30, then compare and add seven for the upper hex digits 'A' to 'F'. This eliminates the need for the 'xlat' table. It might be a few bytes shorter. IIRC, some routines use one of the BCD instructions (AAA, AAD, AAM, AAS, DAA, DAS) to unpack nybbles. It might be the AAA instruction ... Rod Pemberton
Back to alt.comp.bios | Previous | Next — Previous in thread | Next in thread | Find similar
How to use BIOS int 13h ah=48h ? bilsch <king621@comcast.net> - 2016-04-03 03:52 -0700
Re: How to use BIOS int 13h ah=48h ? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-03 17:36 -0400
Re: How to use BIOS int 13h ah=48h ? bilsch <king621@comcast.net> - 2016-04-05 05:34 -0700
Re: How to use BIOS int 13h ah=48h ? "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-04-05 12:53 -0700
Re: How to use BIOS int 13h ah=48h ? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-06 00:10 -0400
THANKS FOR INFO & SUGGESTIONS bilsch <king621@comcast.net> - 2016-04-08 07:49 -0700
csiph-web