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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)