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?

in hex:

9b 0f 49 40

or

9a 0f 49 40

Just wondering if anyone knew, or can find out (do a PUPI instruction on the chip, and read out the four bytes would do).

output 00011010 (1A) to the chip (command port), then read four bytes
from the data port

I would imagine something like:

10 rem compupro system support 1, with am9511
20 c = &h59 : rem am9511 command port
30 d = &h58 : rem am9511 data port
40 out c,&h1a : rem output pupi command
50 for i=1 to 4
60 v = inp(d)
70 print hex$(v)
80 next i

would do nicely -- if you have that hardware...

Thanks in advance!
FredW

FredW

On Thursday, June 3, 2021 at 4:35:36 PM UTC-4, fred_...@hotmail.com wrote:
> 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?
>
> in hex:
>
> 9b 0f 49 40
>
> or
>
> 9a 0f 49 40
>
> Just wondering if anyone knew, or can find out (do a PUPI instruction on the chip, and read out the four bytes would do).

I don't have an answer, from hardware or from documents.

Nevertheless, neither of the hex values you suggest are the
closest possible to pi.

9b 0f 49 40 = mantissa 4788123, exponent 2^1 = 3.14157748222
9a 0f 49 40 = mantissa 4788122, exponent 2^1 = 3.1415772438

da 0f 49 40 = mantissa 4788186, exponent 2^1 = 3.14159250259
db 0f 49 40 = mantissa 4788187, exponent 2^1 = 3.14159274101

So I would guess it would be da or db as the LSB, not 9a or 9b.
Unless this chip didn't really comply with IEEE-754?
https://www.h-schmidt.net/FloatConverter/IEEE754.html

On Thursday, June 3, 2021 at 6:15:09 PM UTC-4, rpre...@gmail.com wrote:
> On Thursday, June 3, 2021 at 4:35:36 PM UTC-4, fred_...@hotmail.com wrote:
> > 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?
> >
> > in hex:
> >
> > 9b 0f 49 40
> >
> > or
> >
> > 9a 0f 49 40
> >
> > Just wondering if anyone knew, or can find out (do a PUPI instruction on the chip, and read out the four bytes would do).
> I don't have an answer, from hardware or from documents.
>
> Nevertheless, neither of the hex values you suggest are the
> closest possible to pi.
>
> 9b 0f 49 40 = mantissa 4788123, exponent 2^1 = 3.14157748222
> 9a 0f 49 40 = mantissa 4788122, exponent 2^1 = 3.1415772438
>
> da 0f 49 40 = mantissa 4788186, exponent 2^1 = 3.14159250259
> db 0f 49 40 = mantissa 4788187, exponent 2^1 = 3.14159274101
>
> So I would guess it would be da or db as the LSB, not 9a or 9b.
> Unless this chip didn't really comply with IEEE-754?
> https://www.h-schmidt.net/FloatConverter/IEEE754.html

You are correct, I mis-typed! I am using da 0f 49 40 for pi. But, the last bit is important for
the extra functions. One bit! Thanks for your correction!

and, no, the chip isn't ieee-754. The leading 1 isn't suppressed, and the exponent is 2's complement
7 bit. very strange. The am9512 was somewhat more 754 compliant, as far as I can tell.

Not that strange.
From wikipedia : The IEEE Standard for Floating-Point Arithmetic (IEEE 754) is a technical standard for floating-point arithmetic established in 1985 by the Institute of Electrical and Electronics Engineers (IEEE)
The 9511 is from the late '70s.

> 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

> Many thanks! I was looking for an am9511 emulator and then support
> library for am9511 and microsoft fortran-80. But... found neither.

I didn't find anything back in the day either. Back then, I made a
TM2 MathLib replacement that used the 9511 to speed up a planetarium
type program I was interested in. It made it seem like I had a 14MHz
Z80 in my Ampro... at the time, that seemed pretty impressive! :)

Regards,
Wayne

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

> 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

On Saturday, June 5, 2021 at 5:23:44 PM UTC-4, fred_...@hotmail.com wrote:
> 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

Reviewing instructions against "Am9511 Algorithm Details" -- I have the following
question about the real hardware:

if you do SSUB or DSUB of 0 - 1, is the carry/borrow SET in the status register.
It would be convenient as an API if it were set... because: overflow is indicted
by error code (note the SSUB description "if the subtraction generates a borrow
it is reported in the carry status bit")

Also 0x8000 - (anything) SSUB should give overflow.

0x7fff + 0x7fff (SADD) should give NO CARRY, NO ZERO, NEGATIVE and
error code xx01 (overflow) in the status register.

Wayne -- if you could validate this, I would be very grateful!

I have written the floating side of am9511 emulator -- I am working on the fixed side -- getting
status bits correct to published documentation (carry, borrow, overflow).

FredW

> if you do SSUB or DSUB of 0 - 1, is the carry/borrow SET in the
> status register. It would be convenient as an API if it were set...
> because: overflow is indicted by error code (note the SSUB
> description "if the subtraction generates a borrow it is reported in
> the carry status bit")

SSUB(0,1) = 0xFFFF status 0x41 (sign, carry)

> Also 0x8000 - (anything) SSUB should give overflow.

SSUB(0x8000,1) = 0x7FFF status 0x02 (overflow)

> 0x7fff + 0x7fff (SADD) should give NO CARRY, NO ZERO, NEGATIVE and
> error code xx01 (overflow) in the status register.

SADD(0x7fff,0x7fff) = 0xFFFE status 0x42 (sign, overflow)

Regards,
Wayne

On Monday, June 7, 2021 at 3:28:37 PM UTC-4, Wayne Hortensius wrote:
> > if you do SSUB or DSUB of 0 - 1, is the carry/borrow SET in the
> > status register. It would be convenient as an API if it were set...
> > because: overflow is indicted by error code (note the SSUB
> > description "if the subtraction generates a borrow it is reported in
> > the carry status bit")
> SSUB(0,1) = 0xFFFF status 0x41 (sign, carry)
> > Also 0x8000 - (anything) SSUB should give overflow.
> SSUB(0x8000,1) = 0x7FFF status 0x02 (overflow
> > 0x7fff + 0x7fff (SADD) should give NO CARRY, NO ZERO, NEGATIVE and
> > error code xx01 (overflow) in the status register.
> SADD(0x7fff,0x7fff) = 0xFFFE status 0x42 (sign, overflow)
>
> Regards,
> Wayne

Wayne

That matches my expectations. That means my C code to do SADD,DADD, SSUB
and DSUB is ok... expect that SSUB(0x8000,1) giving 0x7FFF was a touch .... surprising.
I was expecting 0x8000 and overflow. Need to fix that...

I am working on SMUL and SMULU -- based on 8x8 to 16 multiply. Done, and being
tested. I may have question based on the test suite... Floating point to native is
done -- just validating each instruction. Leaving SDIV and DDIV.

I want to be able to link in port driver (given data/command ports) or native z80
emulation. This would allow us to check the basics of emulation against the
actual chip. After that, I will publish to github (adding to files there), send to
Udo Monk and David Hansel for incorporation into the basic emulators.

Thank you for all your support on this project! Without your help, this would be
a dreadful slog.

FredW

On Monday, June 7, 2021 at 3:55:03 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, June 7, 2021 at 3:28:37 PM UTC-4, Wayne Hortensius wrote:
> > > if you do SSUB or DSUB of 0 - 1, is the carry/borrow SET in the
> > > status register. It would be convenient as an API if it were set...
> > > because: overflow is indicted by error code (note the SSUB
> > > description "if the subtraction generates a borrow it is reported in
> > > the carry status bit")
> > SSUB(0,1) = 0xFFFF status 0x41 (sign, carry)
> > > Also 0x8000 - (anything) SSUB should give overflow.
> > SSUB(0x8000,1) = 0x7FFF status 0x02 (overflow
> > > 0x7fff + 0x7fff (SADD) should give NO CARRY, NO ZERO, NEGATIVE and
> > > error code xx01 (overflow) in the status register.
> > SADD(0x7fff,0x7fff) = 0xFFFE status 0x42 (sign, overflow)
> >
> > Regards,
> > Wayne
> Wayne
>
> That matches my expectations. That means my C code to do SADD,DADD, SSUB
> and DSUB is ok... expect that SSUB(0x8000,1) giving 0x7FFF was a touch .... surprising.
> I was expecting 0x8000 and overflow. Need to fix that...
>
> I am working on SMUL and SMULU -- based on 8x8 to 16 multiply. Done, and being
> tested. I may have question based on the test suite... Floating point to native is
> done -- just validating each instruction. Leaving SDIV and DDIV.
>
> I want to be able to link in port driver (given data/command ports) or native z80
> emulation. This would allow us to check the basics of emulation against the
> actual chip. After that, I will publish to github (adding to files there), send to
> Udo Monk and David Hansel for incorporation into the basic emulators.
>
> Thank you for all your support on this project! Without your help, this would be
> a dreadful slog.
>
> FredW
Wayne

Hope you catch this. I have checked in a lot to https://github.com/ratboy666/am9511

I am wondering -- do you have AM9511 on an 8080 or a Z80? If it is a Z80, can you try testhw.com
on your system. If an 8080, I will rebuild with Whitesmiths 2.1

The syntax is testhw -d port -s port where both ports are in decimal. -d is data port, -s is status port.
test.com is the *same* test, but linked with the emulator.

Thanks in advance!
FredW

> Wayne
>
> Hope you catch this. I have checked in a lot to
> https://github.com/ratboy666/am9511
>
> I am wondering -- do you have AM9511 on an 8080 or a Z80?

At the moment, neither. I pulled it out of an ancient Z180 board and
hooked it up to an Arduino Nano for testing, figuring it would be
easier than gathering up the necessary bits and pieces to make a
complete system around the Z180 board again.

And it is... up to a point. I've melded your test program with the I/O
stuff I wrote for the Nano and got it up and running today. I still have
to put together the bits for a software serial connection (I used the
Nano's hardware Rx/Tx lines in the data bus connection to the 9511 -
that was the only full 8 bit port exposed on the Nano). The little I2C
OLED display I was using was fine for simple tests but now I definitely
need something bigger.

But even at this stage I have found one thing for you to work on.
CHSS/CHSD/CHSF do not all share the same 5 bit opcode. Both CHSS and
CHSD are xxx10100, but CHSF is 00010101 <- watch that lsb.
Interestingly, 00010100 does do something, it changed 3.2 (02 CC CC CD)
to (FD 33 33 33). 2s complemented it as a 32 bit integer at first
glance.

The biggest headslapper at the moment is that I forgot that the sprintf
on the Atmega328 Arduinos doesn't do floats. There's an easy way around
that on the ARM processors, but it's a wee bit of cut/hack/file to fit
on the 328s. Not a showstopper, just slowing me down.

Oh, and the Nano displayed pi as 3.141593 rather than 3.142592. But
that's pretty meaningless for your purposes. I'll stick the converted
value into a quickie Hitech C program tonight and see what it prints
as.

Regards,
Wayne

> Oh, and the Nano displayed pi as 3.141593 rather than 3.142592. But
> that's pretty meaningless for your purposes. I'll stick the converted
> value into a quickie Hitech C program tonight and see what it prints
> as.

For Hitech C, your code converted the 9511's 02 C9 0F DA to 42 C9 0F
DA, which Hitech C displayed as 3.141592, which is what you were
expecting I think.

Regards,
Wayne

Fred,

I got everything together. With the change to send 0x15 rather than
0x14 for CHSF, here's the output I'm seeing:

test am9511
am_test1
NOP: am9511 status = 0
PUPI: am9511 status = 0
PUPI: 3.14159 (should be 3.141592)
CHSS 2 status = 64 (64)
result -> -2
CHSS 0 status = 0 (32)
result -> 0
CHSS -30 status = 0 (0)
result -> 30
CHSS 32767 status = 0 (64)
result -> 32767
CHSS -32768 status = 66 (66)
result -> -32768
CHSD 2 status = 64 (64)
result -> -2
CHSD 0 status = 32 (32)
result -> 0
CHSD -30 status = 0 (0)
result -> 30
am_test2
CHSD 2147483647 status = 64 (64)
result -> -2147483647
CHSD -2147483648 status = 66 (66)
result -> -2147483648
CHSF 3.2 status = 64 (64)
result -> -3.2
CHSF 0 status = 32 (32)
result -> 0
am_test3

Regards,
Wayne

On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> Fred,
>
> I got everything together. With the change to send 0x15 rather than
> 0x14 for CHSF, here's the output I'm seeing:
>
> test am9511
> am_test1
> NOP: am9511 status = 0
> PUPI: am9511 status = 0
> PUPI: 3.14159 (should be 3.141592)
> CHSS 2 status = 64 (64)
> result -> -2
> CHSS 0 status = 0 (32)
> result -> 0
> CHSS -30 status = 0 (0)
> result -> 30
> CHSS 32767 status = 0 (64)
> result -> 32767
> CHSS -32768 status = 66 (66)
> result -> -32768
> CHSD 2 status = 64 (64)
> result -> -2
> CHSD 0 status = 32 (32)
> result -> 0
> CHSD -30 status = 0 (0)
> result -> 30
> am_test2
> CHSD 2147483647 status = 64 (64)
> result -> -2147483647
> CHSD -2147483648 status = 66 (66)
> result -> -2147483648
> CHSF 3.2 status = 64 (64)
> result -> -3.2
> CHSF 0 status = 32 (32)
> result -> 0
> am_test3
>
>
> Regards,
> Wayne
Wayne

Beautiful! That is exactly as expected -- and the emulator is the same.
I fixed the CHSF thing -- thanks for the report. An idiot blind oversight
on my part. Now, I wonder what op 0x1b is? puzzled. The behaviour
of 00010100 matches the chip as well.

During this project, I have found two serious bugs in HI-TECH C 3.09:

long = (unsigned char);
long = (long << 8) | (unsigned char);
long = (long << 8) | (unsigned char);
long = (long << 8) | (unsigned char);

is borked: Work around is

int = (unsigned char)
long = int

int = (unsigned char)
long = long << 8
long = long | int

int = (unsigned char)
long = long << 8
long = long | int

int = (unsigned char)
long = long << 8
long = long | int

The OTHER bug I haven't completely isolated/fixed -- and it is a doozy.

It shows up in test6() -- crash under HI-TECH C, works fine under GCC

The testhw14.com (test1 through test4) and testhw58.com should work
on-chip, and test most features (no advanced functions). I have grated
the am9511 into zxcc (see howto.com) and put am9511.bas on as a test
in MBASIC that can use chip, or emulator. Due to the Hi-TECH iissue,
test58.com doesn't work (it works when compiled with gcc and run)

Thank you for rescuing your AM9511 chip! Your help on this project is
very appreciated. My plan is to continue use MBASIC to create a test harness
that can run on chip or on emulator. I have tied emulator into zxcc
(the emulator that allow HI-TECH C to be used on linux). I will tie
am9511 into RunCPM next. I want to also run down that HI-TECH bug,
and get a work-around (so far, not optimizer related, but the optimizer
causes a DIFFERENT crash, and, putting in printf() makes it go away!
This needs DDT). My direct email is fred(underscore)weigel(at)hotmail(dot)com

Fred Weigel

On Monday, June 28, 2021 at 7:00:55 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> > Fred,
> >
> > I got everything together. With the change to send 0x15 rather than
> > 0x14 for CHSF, here's the output I'm seeing:
> >
> > test am9511
> > am_test1
> > NOP: am9511 status = 0
> > PUPI: am9511 status = 0
> > PUPI: 3.14159 (should be 3.141592)
> > CHSS 2 status = 64 (64)
> > result -> -2
> > CHSS 0 status = 0 (32)
> > result -> 0
> > CHSS -30 status = 0 (0)
> > result -> 30
> > CHSS 32767 status = 0 (64)
> > result -> 32767
> > CHSS -32768 status = 66 (66)
> > result -> -32768
> > CHSD 2 status = 64 (64)
> > result -> -2
> > CHSD 0 status = 32 (32)
> > result -> 0
> > CHSD -30 status = 0 (0)
> > result -> 30
> > am_test2
> > CHSD 2147483647 status = 64 (64)
> > result -> -2147483647
> > CHSD -2147483648 status = 66 (66)
> > result -> -2147483648
> > CHSF 3.2 status = 64 (64)
> > result -> -3.2
> > CHSF 0 status = 32 (32)
> > result -> 0
> > am_test3
> >
> >
> > Regards,
> > Wayne
> Wayne
>
> Beautiful! That is exactly as expected -- and the emulator is the same.
> I fixed the CHSF thing -- thanks for the report. An idiot blind oversight
> on my part. Now, I wonder what op 0x1b is? puzzled. The behaviour
> of 00010100 matches the chip as well.
>
> During this project, I have found two serious bugs in HI-TECH C 3.09:
>
> long = (unsigned char);
> long = (long << 8) | (unsigned char);
> long = (long << 8) | (unsigned char);
> long = (long << 8) | (unsigned char);
>
> is borked: Work around is
>
> int = (unsigned char)
> long = int
>
> int = (unsigned char)
> long = long << 8
> long = long | int
>
> int = (unsigned char)
> long = long << 8
> long = long | int
>
> int = (unsigned char)
> long = long << 8
> long = long | int
>
> The OTHER bug I haven't completely isolated/fixed -- and it is a doozy.
>
> It shows up in test6() -- crash under HI-TECH C, works fine under GCC
>
> The testhw14.com (test1 through test4) and testhw58.com should work
> on-chip, and test most features (no advanced functions). I have grated
> the am9511 into zxcc (see howto.com) and put am9511.bas on as a test
> in MBASIC that can use chip, or emulator. Due to the Hi-TECH iissue,
> test58.com doesn't work (it works when compiled with gcc and run)
>
> Thank you for rescuing your AM9511 chip! Your help on this project is
> very appreciated. My plan is to continue use MBASIC to create a test harness
> that can run on chip or on emulator. I have tied emulator into zxcc
> (the emulator that allow HI-TECH C to be used on linux). I will tie
> am9511 into RunCPM next. I want to also run down that HI-TECH bug,
> and get a work-around (so far, not optimizer related, but the optimizer
> causes a DIFFERENT crash, and, putting in printf() makes it go away!
> This needs DDT). My direct email is fred(underscore)weigel(at)hotmail(dot)com
>
> Fred Weigel

Wayne (and lurkers)

Sorry for the check-in "flurry". Everything that needed immediate attention is
now done -- hardware linkage works with HI-TECH C and the MBASIC
code works. Integration with Zxcc and RunCPM -- others are possible,
but left "as an exercise for the reader".

I am now going to deliberately "slow down" now. The focus is on finding that
HI-TECH C bug (using DSD-80) - and adding to the MBASIC test harness
(running parallel MBASIC single precision float and AM9511 float --
which actually uses the host floating point for now).

I will fix any NASTY bugs, but hope to only have a release next weekend,
and the following weekend.

So -- post (or email) any reports -- but don't expect new code drop till next
Saturday/Sunday.

Thanks! Happy upcoming Canada Day (and Fourth of July for my American friends).

Fred Weigel

On Monday, June 28, 2021 at 4:04:36 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, June 28, 2021 at 7:00:55 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> > > Fred,
> > >
> > > I got everything together. With the change to send 0x15 rather than
> > > 0x14 for CHSF, here's the output I'm seeing:
> > >
> > > test am9511
> > > am_test1
> > > NOP: am9511 status = 0
> > > PUPI: am9511 status = 0
> > > PUPI: 3.14159 (should be 3.141592)
> > > CHSS 2 status = 64 (64)
> > > result -> -2
> > > CHSS 0 status = 0 (32)
> > > result -> 0
> > > CHSS -30 status = 0 (0)
> > > result -> 30
> > > CHSS 32767 status = 0 (64)
> > > result -> 32767
> > > CHSS -32768 status = 66 (66)
> > > result -> -32768
> > > CHSD 2 status = 64 (64)
> > > result -> -2
> > > CHSD 0 status = 32 (32)
> > > result -> 0
> > > CHSD -30 status = 0 (0)
> > > result -> 30
> > > am_test2
> > > CHSD 2147483647 status = 64 (64)
> > > result -> -2147483647
> > > CHSD -2147483648 status = 66 (66)
> > > result -> -2147483648
> > > CHSF 3.2 status = 64 (64)
> > > result -> -3.2
> > > CHSF 0 status = 32 (32)
> > > result -> 0
> > > am_test3
> > >
> > >
> > > Regards,
> > > Wayne
> > Wayne
> >
> > Beautiful! That is exactly as expected -- and the emulator is the same.
> > I fixed the CHSF thing -- thanks for the report. An idiot blind oversight
> > on my part. Now, I wonder what op 0x1b is? puzzled. The behaviour
> > of 00010100 matches the chip as well.
> >
> > During this project, I have found two serious bugs in HI-TECH C 3.09:
> >
> > long = (unsigned char);
> > long = (long << 8) | (unsigned char);
> > long = (long << 8) | (unsigned char);
> > long = (long << 8) | (unsigned char);
> >
> > is borked: Work around is
> >
> > int = (unsigned char)
> > long = int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > The OTHER bug I haven't completely isolated/fixed -- and it is a doozy.
> >
> > It shows up in test6() -- crash under HI-TECH C, works fine under GCC
> >
> > The testhw14.com (test1 through test4) and testhw58.com should work
> > on-chip, and test most features (no advanced functions). I have grated
> > the am9511 into zxcc (see howto.com) and put am9511.bas on as a test
> > in MBASIC that can use chip, or emulator. Due to the Hi-TECH iissue,
> > test58.com doesn't work (it works when compiled with gcc and run)
> >
> > Thank you for rescuing your AM9511 chip! Your help on this project is
> > very appreciated. My plan is to continue use MBASIC to create a test harness
> > that can run on chip or on emulator. I have tied emulator into zxcc
> > (the emulator that allow HI-TECH C to be used on linux). I will tie
> > am9511 into RunCPM next. I want to also run down that HI-TECH bug,
> > and get a work-around (so far, not optimizer related, but the optimizer
> > causes a DIFFERENT crash, and, putting in printf() makes it go away!
> > This needs DDT). My direct email is fred(underscore)weigel(at)hotmail(dot)com
> >
> > Fred Weigel
> Wayne (and lurkers)
>
> Sorry for the check-in "flurry". Everything that needed immediate attention is
> now done -- hardware linkage works with HI-TECH C and the MBASIC
> code works. Integration with Zxcc and RunCPM -- others are possible,
> but left "as an exercise for the reader".
>
> I am now going to deliberately "slow down" now. The focus is on finding that
> HI-TECH C bug (using DSD-80) - and adding to the MBASIC test harness
> (running parallel MBASIC single precision float and AM9511 float --
> which actually uses the host floating point for now).
>
> I will fix any NASTY bugs, but hope to only have a release next weekend,
> and the following weekend.
>
> So -- post (or email) any reports -- but don't expect new code drop till next
> Saturday/Sunday.
>
> Thanks! Happy upcoming Canada Day (and Fourth of July for my American friends).
>
> Fred Weigel
Wayne

I received a note from Alan Cox, about integrating am9511 into his emulator. Alan wanted
to support multiple AM9511 chips. I have update am9511 to allow that -- this took care
of the ugly HI-TECH C bug as well! (shrug).

void *am9511 = am_create(status, data); to create a new chip, then pass am9511 as the
first parameter to push/pop/status/command. This allow multiple devices to exist.

FredW

On Monday, June 28, 2021 at 4:04:36 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, June 28, 2021 at 7:00:55 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> > > Fred,
> > >
> > > I got everything together. With the change to send 0x15 rather than
> > > 0x14 for CHSF, here's the output I'm seeing:
> > >
> > > test am9511
> > > am_test1
> > > NOP: am9511 status = 0
> > > PUPI: am9511 status = 0
> > > PUPI: 3.14159 (should be 3.141592)
> > > CHSS 2 status = 64 (64)
> > > result -> -2
> > > CHSS 0 status = 0 (32)
> > > result -> 0
> > > CHSS -30 status = 0 (0)
> > > result -> 30
> > > CHSS 32767 status = 0 (64)
> > > result -> 32767
> > > CHSS -32768 status = 66 (66)
> > > result -> -32768
> > > CHSD 2 status = 64 (64)
> > > result -> -2
> > > CHSD 0 status = 32 (32)
> > > result -> 0
> > > CHSD -30 status = 0 (0)
> > > result -> 30
> > > am_test2
> > > CHSD 2147483647 status = 64 (64)
> > > result -> -2147483647
> > > CHSD -2147483648 status = 66 (66)
> > > result -> -2147483648
> > > CHSF 3.2 status = 64 (64)
> > > result -> -3.2
> > > CHSF 0 status = 32 (32)
> > > result -> 0
> > > am_test3
> > >
> > >
> > > Regards,
> > > Wayne
> > Wayne
> >
> > Beautiful! That is exactly as expected -- and the emulator is the same.
> > I fixed the CHSF thing -- thanks for the report. An idiot blind oversight
> > on my part. Now, I wonder what op 0x1b is? puzzled. The behaviour
> > of 00010100 matches the chip as well.
> >
> > During this project, I have found two serious bugs in HI-TECH C 3.09:
> >
> > long = (unsigned char);
> > long = (long << 8) | (unsigned char);
> > long = (long << 8) | (unsigned char);
> > long = (long << 8) | (unsigned char);
> >
> > is borked: Work around is
> >
> > int = (unsigned char)
> > long = int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > int = (unsigned char)
> > long = long << 8
> > long = long | int
> >
> > The OTHER bug I haven't completely isolated/fixed -- and it is a doozy.
> >
> > It shows up in test6() -- crash under HI-TECH C, works fine under GCC
> >
> > The testhw14.com (test1 through test4) and testhw58.com should work
> > on-chip, and test most features (no advanced functions). I have grated
> > the am9511 into zxcc (see howto.com) and put am9511.bas on as a test
> > in MBASIC that can use chip, or emulator. Due to the Hi-TECH iissue,
> > test58.com doesn't work (it works when compiled with gcc and run)
> >
> > Thank you for rescuing your AM9511 chip! Your help on this project is
> > very appreciated. My plan is to continue use MBASIC to create a test harness
> > that can run on chip or on emulator. I have tied emulator into zxcc
> > (the emulator that allow HI-TECH C to be used on linux). I will tie
> > am9511 into RunCPM next. I want to also run down that HI-TECH bug,
> > and get a work-around (so far, not optimizer related, but the optimizer
> > causes a DIFFERENT crash, and, putting in printf() makes it go away!
> > This needs DDT). My direct email is fred(underscore)weigel(at)hotmail(dot)com
> >
> > Fred Weigel
> Wayne (and lurkers)
>
> Sorry for the check-in "flurry". Everything that needed immediate attention is
> now done -- hardware linkage works with HI-TECH C and the MBASIC
> code works. Integration with Zxcc and RunCPM -- others are possible,
> but left "as an exercise for the reader".
>
> I am now going to deliberately "slow down" now. The focus is on finding that
> HI-TECH C bug (using DSD-80) - and adding to the MBASIC test harness
> (running parallel MBASIC single precision float and AM9511 float --
> which actually uses the host floating point for now).
>
> I will fix any NASTY bugs, but hope to only have a release next weekend,
> and the following weekend.
>
> So -- post (or email) any reports -- but don't expect new code drop till next
> Saturday/Sunday.
>
> Thanks! Happy upcoming Canada Day (and Fourth of July for my American friends).
>
> Fred Weigel

And, work on the test harness continues -- I am using CHAIN MERGE to bring in code into
the tester, and executing against the chip, and the code brought in. Slow, but very
flexible.

FredW

On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> Fred,
>
> I got everything together. With the change to send 0x15 rather than
> 0x14 for CHSF, here's the output I'm seeing:
>
> test am9511
> am_test1
> NOP: am9511 status = 0
> PUPI: am9511 status = 0
> PUPI: 3.14159 (should be 3.141592)
> CHSS 2 status = 64 (64)
> result -> -2
> CHSS 0 status = 0 (32)
> result -> 0
> CHSS -30 status = 0 (0)
> result -> 30
> CHSS 32767 status = 0 (64)
> result -> 32767
> CHSS -32768 status = 66 (66)
> result -> -32768
> CHSD 2 status = 64 (64)
> result -> -2
> CHSD 0 status = 32 (32)
> result -> 0
> CHSD -30 status = 0 (0)
> result -> 30
> am_test2
> CHSD 2147483647 status = 64 (64)
> result -> -2147483647
> CHSD -2147483648 status = 66 (66)
> result -> -2147483648
> CHSF 3.2 status = 64 (64)
> result -> -3.2
> CHSF 0 status = 32 (32)
> result -> 0
> am_test3
>
>
> Regards,
> Wayne
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

On Tuesday, July 13, 2021 at 10:12:28 AM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Monday, June 28, 2021 at 2:48:52 AM UTC-4, Wayne Hortensius wrote:
> > Fred,
> >
> > I got everything together. With the change to send 0x15 rather than
> > 0x14 for CHSF, here's the output I'm seeing:
> >
> > test am9511
> > am_test1
> > NOP: am9511 status = 0
> > PUPI: am9511 status = 0
> > PUPI: 3.14159 (should be 3.141592)
> > CHSS 2 status = 64 (64)
> > result -> -2
> > CHSS 0 status = 0 (32)
> > result -> 0
> > CHSS -30 status = 0 (0)
> > result -> 30
> > CHSS 32767 status = 0 (64)
> > result -> 32767
> > CHSS -32768 status = 66 (66)
> > result -> -32768
> > CHSD 2 status = 64 (64)
> > result -> -2
> > CHSD 0 status = 32 (32)
> > result -> 0
> > CHSD -30 status = 0 (0)
> > result -> 30
> > am_test2
> > CHSD 2147483647 status = 64 (64)
> > result -> -2147483647
> > CHSD -2147483648 status = 66 (66)
> > result -> -2147483648
> > CHSF 3.2 status = 64 (64)
> > result -> -3.2
> > CHSF 0 status = 32 (32)
> > result -> 0
> > am_test3
> >
> >
> > Regards,
> > Wayne
> 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
The code currently in ova.c is from a strict reading of the AM9511 specification.

However, the fact that the chip reports overflow on 0x8000 * <anything> would seem
to indicate that the multiply function is/should be doing sign correction. Then:

a * b should be abs(a) * abs(b). and the sign applied to the result.

which is easy enough... but... what about the upper? As it is, signed multiply is
ok, but overflow is wrong --unless-- interpreted as unsigned multiply!

I just don't know how the chip does it -- thus the question SMUL 3 * 10, SMUL -3 * 10, and
SMUL -3 * -10 will tell us (status result). Also SMUU of the same 3 cases (status and result)
would be helpful. I will just build out a "test7" test of it.

Thanks in advance. The result of the emulator I am reasonably happy with now. Will be
doing testing against some known trig results.

FredW

> 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

> I just don't know how the chip does it -- thus the question SMUL 3 *
> 10, SMUL -3 * 10, and SMUL -3 * -10 will tell us (status result).
> Also SMUU of the same 3 cases (status and result) would be helpful. I
> will just build out a "test7" test of it.

SMUL: 10 * 3 = 30 status 0
SMUU: 10 * 3 = 0 status 32
SMUL: -10 * -3 = 30 status 0
SMUU: -10 * -3 = 0 status 32
SMUL: 10 * -3 = -30 status 64
SMUU: 10 * -3 = -1 status 64

Regards,
Wayne

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

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