Re: 64 ROM F.P. question

From: Brian Ketterling (
Date: 2003-10-28 01:18:28

>From: Willi Kusche <>
>On 25-Oct-03, Brian wrote:
>->According to "Machine Language 302" by Rick Nash, in Loadstar's "Compleat
>->Programmer" collection:
>->"$BC9B converts floating point to four byte integer.  JSR with floating
>->point number stored in FAC1.  Result will be stored in locations 
>     I quite certain that the conversion is to a two byte integer.  $62 and 
>must be zeros.

No, I checked and it works.  "Mapping the 64" adds that it's a signed 
integer, and sure enough it reserves bit 31 for a negative flag.  The 
integer is stored in high-endian fashion, so e.g. 2^30 looks like this:

01000000  00000000  00000000  00000000
($62)         ($63)       ($64)         ($65)

and -1 looks like this:

10000000  00000000  00000000  00000001

>From: john/lori <>
>you might have a look at this:
>(B391 right after the FRE function which is at B37D, the closest
>link I could find)
>(I have no idea what it does, but it sounds right ;)

Dang, no, that's one of the standard int->fac1 routines.  That one converts 
a 16-bit integer in .A/.Y to a floating point #.  Good detective work 
though.  I didn't know about that searchable disassembly -- thanks!

Well, if there really isn't a routine to convert a 4-byte integer to a 
floating point number, I guess I could do a workaround, like convert the 1st 
two bytes, multiply by 65536, then convert the next two bytes and add.  I 
wonder why that 4-byte routine exists, though? -- especially if there's no 
routine to convert back.

-- Brian

Fretting that your Hotmail account may expire because you forgot to sign in 
enough? Get Hotmail Extra Storage today!

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.