On Wednesday, July 14, 2021 at 7:29:10 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Tuesday, July 13, 2021 at 2:18:19 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Tuesday, July 13, 2021 at 1:42:42 PM UTC-4, Wayne Hortensius wrote:
> > > > Wayne
> > > >
> > > > I do have another question -
> > > >
> > > > If I do
> > > > SMUL -10 * -3 I get result 30, status 2
> > > >
> > > > and
> > > >
> > > > SMUL 10 * -3, result -30, status 66
> > > >
> > > > does the real chip do this? or is the status corrected for signed
> > > > multiply? It is easy to adjust for, but the chip documentation is
> > > > unclear...
> > > >
> > > > Thanks in advance,
> > > >
> > > > FredW
> > > I get:
> > >
> > > SMUL: -10 * -3 = 30 status = 0
> > > SMUL: 10 * -3 = -30 status = 64
> > >
> > > No overflow error code in either case.
> > >
> > > Regards,
> > > Wayne
> > Wayne
> >
> > Thanks a bunch! I am correcting the emulator then. This means that multiply is sign corrected.
> > Also, that the documentation is wrong! But.. I suspected
> >
> > FredW
> All Righty Then!
>
> am9511 update with correction for SMUL/SMUU/DMUL/DMUU sign is on my github.
> This just takes the abs of the args, multiplies and puts the result sign on.
>
> Test cases added for SMUL/SMUU. One test case for DMUL/DMUU (need to split test cases
> again for size on CP/M).
>
> Enjoy!
> FredW
Wayne

I have a strange question about the AM9511A

If we do:

PUSH 0
PUSH 0
COMMAND 1D (FLTS)
STATUS -> ZERO
POP -> a
POP -> b
POP -> c
POP -> d

What are the values for a, b, c and d?

This may be preventing operation of z88dk with --am9511 code generation.

Thanks in Advance
Fred Weigel

Hi Fred

Reading slightly between the lines, you're looking for confirmation of
the 9511's representation of a floating point 0, correct?

The following code:

am_wait();
n = 0;
am_push(n);
am_push(n >> 8);
am_command(AM_FLTS);
s = am_wait();
v[3] = am_pop();
v[2] = am_pop();
v[1] = am_pop();
v[0] = am_pop();
am_fp(v);
fp_na(&x);
printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
n, x, v[3], v[2], v[1], v[0], s);

produces:

FLTS: 0 = 0 [00][00][00][00] status = 32

Regards,
Wayne

On Friday, July 16, 2021 at 6:13:59 PM UTC-4, Wayne Hortensius wrote:
> Hi Fred
>
> Reading slightly between the lines, you're looking for confirmation of
> the 9511's representation of a floating point 0, correct?
>
> The following code:
>
> am_wait();
> n = 0;
> am_push(n);
> am_push(n >> 8);
> am_command(AM_FLTS);
> s = am_wait();
> v[3] = am_pop();
> v[2] = am_pop();
> v[1] = am_pop();
> v[0] = am_pop();
> am_fp(v);
> fp_na(&x);
> printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
> n, x, v[3], v[2], v[1], v[0], s);
>
> produces:
>
> FLTS: 0 = 0 [00][00][00][00] status = 32
>
>
> Regards,
> Wayne
Wayne

Yes, I was - and it (zero) IS 00 00 00 00

I am using a program planetsa.com to do some validation. It was failing on the Zxcc emulator!
And I was trying to figure out why... Turns out, Zxcc is being problematic with in/out (probably I
am interfacing wrong). RunCPM is doing much better, and I am able to actually run planeta.com!

With maybe a problem with the exp() function...

Thanks for doing that! I think am9511 is pretty close to a "first release".

Fred Weigel

On Saturday, July 17, 2021 at 2:03:33 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Friday, July 16, 2021 at 6:13:59 PM UTC-4, Wayne Hortensius wrote:
> > Hi Fred
> >
> > Reading slightly between the lines, you're looking for confirmation of
> > the 9511's representation of a floating point 0, correct?
> >
> > The following code:
> >
> > am_wait();
> > n = 0;
> > am_push(n);
> > am_push(n >> 8);
> > am_command(AM_FLTS);
> > s = am_wait();
> > v[3] = am_pop();
> > v[2] = am_pop();
> > v[1] = am_pop();
> > v[0] = am_pop();
> > am_fp(v);
> > fp_na(&x);
> > printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
> > n, x, v[3], v[2], v[1], v[0], s);
> >
> > produces:
> >
> > FLTS: 0 = 0 [00][00][00][00] status = 32
> >
> >
> > Regards,
> > Wayne
> Wayne
>
> Yes, I was - and it (zero) IS 00 00 00 00
>
> I am using a program planetsa.com to do some validation. It was failing on the Zxcc emulator!
> And I was trying to figure out why... Turns out, Zxcc is being problematic with in/out (probably I
> am interfacing wrong). RunCPM is doing much better, and I am able to actually run planeta.com!
>
> With maybe a problem with the exp() function...
>
> Thanks for doing that! I think am9511 is pretty close to a "first release".
>
> Fred Weigel

Wayne

Thanks for the confirmation. The error was in FLTS - I was not handling negative integers correctly,
they were being converted to positive; that, in turn, caused the EXP function to overflow, and caused
the z88dk AM9511 runtime library to mess up. flts() is fixed.

Fred Weigel

On Saturday, July 17, 2021 at 7:03:02 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Saturday, July 17, 2021 at 2:03:33 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Friday, July 16, 2021 at 6:13:59 PM UTC-4, Wayne Hortensius wrote:
> > > Hi Fred
> > >
> > > Reading slightly between the lines, you're looking for confirmation of
> > > the 9511's representation of a floating point 0, correct?
> > >
> > > The following code:
> > >
> > > am_wait();
> > > n = 0;
> > > am_push(n);
> > > am_push(n >> 8);
> > > am_command(AM_FLTS);
> > > s = am_wait();
> > > v[3] = am_pop();
> > > v[2] = am_pop();
> > > v[1] = am_pop();
> > > v[0] = am_pop();
> > > am_fp(v);
> > > fp_na(&x);
> > > printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
> > > n, x, v[3], v[2], v[1], v[0], s);
> > >
> > > produces:
> > >
> > > FLTS: 0 = 0 [00][00][00][00] status = 32
> > >
> > >
> > > Regards,
> > > Wayne
> > Wayne
> >
> > Yes, I was - and it (zero) IS 00 00 00 00
> >
> > I am using a program planetsa.com to do some validation. It was failing on the Zxcc emulator!
> > And I was trying to figure out why... Turns out, Zxcc is being problematic with in/out (probably I
> > am interfacing wrong). RunCPM is doing much better, and I am able to actually run planeta.com!
> >
> > With maybe a problem with the exp() function...
> >
> > Thanks for doing that! I think am9511 is pretty close to a "first release".
> >
> > Fred Weigel
> Wayne
>
> Thanks for the confirmation. The error was in FLTS - I was not handling negative integers correctly,
> they were being converted to positive; that, in turn, caused the EXP function to overflow, and caused
> the z88dk AM9511 runtime library to mess up. flts() is fixed.
>
> Fred Weigel
Wayne (and others)

I think am9511 is now usable. howto.txt has instructions for integrating the emulator into Zxcc and RunCPM.
(Zxcc may need some bug fixes -- instructions in the howto.txt). A sample application (planeta.com) is
provided. I have compiled am9511 under the Altair-Duino "sketch" as well, but have not yet programmed
my Altair-Duino (I am a bit shy about altering the "factory load" -- this will be my first foray into Arduino
programming. I just have to "do it"). But, all appears ok on RunCPM -- give that a shake-out and test.
If all works well for a week or so, and I can get the Altair-Duino running with am9511, I will declare the
first release of am9511! And then see about getting it into the regular Altair-Duino firmware and into
z80pack.

https://github.com/ratboy666/am9511

Put bug reports into the Issues at github (or here, even). Hopefully, all will be stable, and this can
be released (I will actively support am9511 as long as there is interest in it).

Thanks to

Wayne Hortensius
Alan Cox
Phillip Stevens

For their interest and support!

Fred Weigel

On Monday, July 19, 2021 at 1:46:04 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Saturday, July 17, 2021 at 7:03:02 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Saturday, July 17, 2021 at 2:03:33 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > > On Friday, July 16, 2021 at 6:13:59 PM UTC-4, Wayne Hortensius wrote:
> > > > Hi Fred
> > > >
> > > > Reading slightly between the lines, you're looking for confirmation of
> > > > the 9511's representation of a floating point 0, correct?
> > > >
> > > > The following code:
> > > >
> > > > am_wait();
> > > > n = 0;
> > > > am_push(n);
> > > > am_push(n >> 8);
> > > > am_command(AM_FLTS);
> > > > s = am_wait();
> > > > v[3] = am_pop();
> > > > v[2] = am_pop();
> > > > v[1] = am_pop();
> > > > v[0] = am_pop();
> > > > am_fp(v);
> > > > fp_na(&x);
> > > > printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
> > > > n, x, v[3], v[2], v[1], v[0], s);
> > > >
> > > > produces:
> > > >
> > > > FLTS: 0 = 0 [00][00][00][00] status = 32
> > > >
> > > >
> > > > Regards,
> > > > Wayne
> > > Wayne
> > >
> > > Yes, I was - and it (zero) IS 00 00 00 00
> > >
> > > I am using a program planetsa.com to do some validation. It was failing on the Zxcc emulator!
> > > And I was trying to figure out why... Turns out, Zxcc is being problematic with in/out (probably I
> > > am interfacing wrong). RunCPM is doing much better, and I am able to actually run planeta.com!
> > >
> > > With maybe a problem with the exp() function...
> > >
> > > Thanks for doing that! I think am9511 is pretty close to a "first release".
> > >
> > > Fred Weigel
> > Wayne
> >
> > Thanks for the confirmation. The error was in FLTS - I was not handling negative integers correctly,
> > they were being converted to positive; that, in turn, caused the EXP function to overflow, and caused
> > the z88dk AM9511 runtime library to mess up. flts() is fixed.
> >
> > Fred Weigel
> Wayne (and others)
>
> I think am9511 is now usable. howto.txt has instructions for integrating the emulator into Zxcc and RunCPM.
> (Zxcc may need some bug fixes -- instructions in the howto.txt). A sample application (planeta.com) is
> provided. I have compiled am9511 under the Altair-Duino "sketch" as well, but have not yet programmed
> my Altair-Duino (I am a bit shy about altering the "factory load" -- this will be my first foray into Arduino
> programming. I just have to "do it"). But, all appears ok on RunCPM -- give that a shake-out and test.
> If all works well for a week or so, and I can get the Altair-Duino running with am9511, I will declare the
> first release of am9511! And then see about getting it into the regular Altair-Duino firmware and into
> z80pack.
>
> https://github.com/ratboy666/am9511
>
> Put bug reports into the Issues at github (or here, even). Hopefully, all will be stable, and this can
> be released (I will actively support am9511 as long as there is interest in it).
>
> Thanks to
>
> Wayne Hortensius
> Alan Cox
> Phillip Stevens
>
> For their interest and support!
>
> Fred Weigel
Wayne (and others)

Now that I have a usable am9511 emulation (Alan Cox hooked it into RC2014 emulator, and I have
it hooked into Zxcc and RunCPM -- per the howto.txt instructions). I could get back to my original
goal, which was using AM911 with FORTRAN-80. Since nobody appears to have that code anymore,
I wrote my own.. Find it at

https://github.com/ratboy666/apu

Notes:

This accelerates INTEGER and INTEGER*4 multiply and divide. ADD and SUBTRACT INTEGER
are not touched.

REAL + - * / ** REAL are accelerated.

"Mixed Mode" needs conversion and is not "full speed" yet.

INTRINSIC functions are not accelerated.

But, appears usable. MicroSoft M80, LIB-80, used to build the APU.REL library. Can support
any chip location. Interesting that it can ALSO be used to accelerate BASCOM compiled
stuff.

Needs testing -- Wayne -- I assume you have MicroSoft M80/F80/BASCOM. This stuff
has been run against am9511 emulator, but *not* against the real deal chip yet.

Still at the "needs tender loving care stage"
Have Fun! May the AM9511 live forever! When this all works, I think I will treat myself to
a RC2014 with AM9511A chip!

Fred Weigel

On Friday, July 23, 2021 at 4:35:19 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, July 19, 2021 at 1:46:04 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Saturday, July 17, 2021 at 7:03:02 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > > On Saturday, July 17, 2021 at 2:03:33 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > > > On Friday, July 16, 2021 at 6:13:59 PM UTC-4, Wayne Hortensius wrote:
> > > > > Hi Fred
> > > > >
> > > > > Reading slightly between the lines, you're looking for confirmation of
> > > > > the 9511's representation of a floating point 0, correct?
> > > > >
> > > > > The following code:
> > > > >
> > > > > am_wait();
> > > > > n = 0;
> > > > > am_push(n);
> > > > > am_push(n >> 8);
> > > > > am_command(AM_FLTS);
> > > > > s = am_wait();
> > > > > v[3] = am_pop();
> > > > > v[2] = am_pop();
> > > > > v[1] = am_pop();
> > > > > v[0] = am_pop();
> > > > > am_fp(v);
> > > > > fp_na(&x);
> > > > > printf("FLTS: %d = %g [%02X][%02X][%02X][%02X] status = %d\n",
> > > > > n, x, v[3], v[2], v[1], v[0], s);
> > > > >
> > > > > produces:
> > > > >
> > > > > FLTS: 0 = 0 [00][00][00][00] status = 32
> > > > >
> > > > >
> > > > > Regards,
> > > > > Wayne
> > > > Wayne
> > > >
> > > > Yes, I was - and it (zero) IS 00 00 00 00
> > > >
> > > > I am using a program planetsa.com to do some validation. It was failing on the Zxcc emulator!
> > > > And I was trying to figure out why... Turns out, Zxcc is being problematic with in/out (probably I
> > > > am interfacing wrong). RunCPM is doing much better, and I am able to actually run planeta.com!
> > > >
> > > > With maybe a problem with the exp() function...
> > > >
> > > > Thanks for doing that! I think am9511 is pretty close to a "first release".
> > > >
> > > > Fred Weigel
> > > Wayne
> > >
> > > Thanks for the confirmation. The error was in FLTS - I was not handling negative integers correctly,
> > > they were being converted to positive; that, in turn, caused the EXP function to overflow, and caused
> > > the z88dk AM9511 runtime library to mess up. flts() is fixed.
> > >
> > > Fred Weigel
> > Wayne (and others)
> >
> > I think am9511 is now usable. howto.txt has instructions for integrating the emulator into Zxcc and RunCPM.
> > (Zxcc may need some bug fixes -- instructions in the howto.txt). A sample application (planeta.com) is
> > provided. I have compiled am9511 under the Altair-Duino "sketch" as well, but have not yet programmed
> > my Altair-Duino (I am a bit shy about altering the "factory load" -- this will be my first foray into Arduino
> > programming. I just have to "do it"). But, all appears ok on RunCPM -- give that a shake-out and test.
> > If all works well for a week or so, and I can get the Altair-Duino running with am9511, I will declare the
> > first release of am9511! And then see about getting it into the regular Altair-Duino firmware and into
> > z80pack.
> >
> > https://github.com/ratboy666/am9511
> >
> > Put bug reports into the Issues at github (or here, even). Hopefully, all will be stable, and this can
> > be released (I will actively support am9511 as long as there is interest in it).
> >
> > Thanks to
> >
> > Wayne Hortensius
> > Alan Cox
> > Phillip Stevens
> >
> > For their interest and support!
> >
> > Fred Weigel
> Wayne (and others)
>
> Now that I have a usable am9511 emulation (Alan Cox hooked it into RC2014 emulator, and I have
> it hooked into Zxcc and RunCPM -- per the howto.txt instructions). I could get back to my original
> goal, which was using AM911 with FORTRAN-80. Since nobody appears to have that code anymore,
> I wrote my own.. Find it at
>
> https://github.com/ratboy666/apu
>
> Notes:
>
> This accelerates INTEGER and INTEGER*4 multiply and divide. ADD and SUBTRACT INTEGER
> are not touched.
>
> REAL + - * / ** REAL are accelerated.
>
> "Mixed Mode" needs conversion and is not "full speed" yet.
>
> INTRINSIC functions are not accelerated.
>
> But, appears usable. MicroSoft M80, LIB-80, used to build the APU.REL library. Can support
> any chip location. Interesting that it can ALSO be used to accelerate BASCOM compiled
> stuff.
>
> Needs testing -- Wayne -- I assume you have MicroSoft M80/F80/BASCOM. This stuff
> has been run against am9511 emulator, but *not* against the real deal chip yet.
>
> Still at the "needs tender loving care stage"
>
> Have Fun! May the AM9511 live forever! When this all works, I think I will treat myself to
> a RC2014 with AM9511A chip!
>
> Fred Weigel
APU.REL is now complete. Includes integer, integer*4, real and intrinsic.
Maybe some bugs, but all packed into about 900 bytes.

Needs test programs in FORTRAN-80 AND BASIC-80.

Fred Weigel

On Friday, June 4, 2021 at 2:37:17 AM UTC-4, Wayne Hortensius wrote:
> > What is the value of PI on the chip?
> >
> > in hex:
> >
> > 9b 0f 49 40
> >
> > or
> >
> > 9a 0f 49 40
> After waking my 9511 from its decades long slumber and asking it to
> PUPI, it reported this:
>
> 02 C9 0F DA
>
> which looks reasonable (the MSB comes off the stack first). The
> mantissa is C9 0F DA, and the exponent is 2. C9 0F DA works out to
> 0.7853981, multiply by 4 and you end up with 3.141592.
>
> And I'd forgotten just how hot the 9511 runs.
>
> Regards,
> Wayne
Wayne

Many thanks! I was looking for an am9511 emulator and then support library for am9511 and microsoft fortran-80.
But... found neither. So, try my am9511 project.

https://github.com/ratboy666/am9511

The first thing is a support library (gcc, tcc and hi-tech c) to convert microsoft, ieee, hi-tech and am9511 floats back and forth.
The value of pi you supplied is in the test vector.

I am now implementing the guts of a Am9511A emulator.

FredW

On Saturday, June 5, 2021 at 8:28:09 AM UTC-4, Martin wrote:
> Am 06/03/2021 10:35 PM, fred_...@hotmail.com schrieb:
> > I have been working on DSD-80 debugger, and the AM9511 chip
> > (using DSD-80 to debug code for the AM9511).
> >
> > I do not have an AM9511A, and am curious about it (working on
> > an emulator for the chip.
> >
> > What is the value of PI on the chip?
> >
> [...]
>
> >
> > Thanks in advance!
> > FredW
> >
>
> There is an old emulator from "Bill Haygood"
>
> The internet archive has it!
>
> <http://web.archive.org/web/20050421093649/http://www.z80a.org/>
>
> <http://web.archive.org/web/20050421131207id_/http://www.z80a.org/z80.tbz2>
>
>
> This emulator passes the test programs from "Frank Cringle".
>
> AND it contains emulations of the AM9511 APU and the AM9512 FPP!
>
> By the way, in apu.c, you find:
> #define PI 0x02c90fdb
>
>
> Hmmm, after ~20 years, we have found a bug :-)
>
>
> Martin
Actually, on quick look -- more than one -- the range check is completely wrong.

Wayne Hortensius -- if you are reading this... (or anyone else with the real
chip) Can you confirm that on the REAL AM9511A,
(low to high): the smallest and largest numbers are:

2.71051e-20 00 00 80 40
9.22337e+18 ff ff ff 3f

FredW

On Saturday, June 5, 2021 at 4:22:18 PM UTC-4, Wayne Hortensius wrote:
> > Wayne Hortensius -- if you are reading this... (or anyone else with
> > the real chip) Can you confirm that on the REAL AM9511A,
> > (low to high): the smallest and largest numbers are:
> >
> > 2.71051e-20 00 00 80 40
> > 9.22337e+18 ff ff ff 3f
> Adding 00 00 80 28 to FE FF FF 3F results in FF FF FF 3F.
> Adding 00 00 80 28 to FF FF FF 3F sets the overflow flag.
>
> Dividing 00 00 80 41 by 00 00 80 02 (2) results in 00 00 80 40.
> Dividing 00 00 80 40 by 00 00 80 02 (2) sets the underflow flag.
>
> Regards,
> Wayne

Wayne

Many thanks! That is what I expected! Putting in the limits in the emulation...

Will publish soon! (conversion is there, but not the emulation)

FredW