# Re: 64 ROM F.P. question

From: Brian Ketterling (tweel8502_at_hotmail.com)
Date: 2003-10-28 01:18:28

```>From: Willi Kusche <willi@allvantage.com>
>
>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
>\$62-\$65."
>
>     I quite certain that the conversion is to a two byte integer.  \$62 and
>\$63
>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

>
>you might have a look at this:
>
>http://www.hut.fi/Misc/cbm/docs/c64-diss.html#B37D
>
>(B391 right after the FRE function which is at B37D, the closest
>
>(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

_________________________________________________________________