Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.comp.bios > #5

Re: How to use BIOS int 13h ah=48h ?

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.

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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