Author Topic: 6502 KIMATH, should I try and port it to Z80 or AVR mega?  (Read 16872 times)

0 Members and 1 Guest are viewing this topic.

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
6502 KIMATH, should I try and port it to Z80 or AVR mega?
« on: October 17, 2015, 09:36:15 pm »
Hi folks,

I'm having a tough time here trying to figure out my best next move forward. I want decimal floating point capability and I've got an old package by mos technology  from about 1977 which basically consists of a bunch of 6502 routines that you can string together and produce a potential 16 decimal(bcd) digits of mantissa(that's very powerful). If I build a 6502 system, then you are looking at about 10~15 chips, I have no compiler support for the 6502, other than an assembler. The total code consists of about 750 instructions and fits inside a 2krom.

I've got compiler support for the 8051, AVR and the Z80. I want this package in a single chip AVR/8051 real bad, do you think it's viable to try and translate the 6502 assembler to AVR assembler, literally coded instruction for instruction? Failing that, I could try and port it to Z80 assembler. :popcorn: So anyhow, what do you think I should do?

Problem with the AVR is that it is Harvard and so ram and rom space is split,  this isn't the case with the Z80. 
« Last Edit: October 17, 2015, 09:43:25 pm by commie »
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #1 on: October 17, 2015, 09:54:27 pm »
http://www.micromegacorp.com/ make this add on fpu for avrs and things. its interesting, uses i2c/spi to talk etc. 5v tolerant. may or may not be useful info.
-- Aussie living in the USA --
 

Offline John_ITIC

  • Frequent Contributor
  • **
  • Posts: 514
  • Country: us
  • ITIC Protocol Analyzers
    • International Test Instruments Corporation
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #2 on: October 17, 2015, 10:07:50 pm »
Problem with the AVR is that it is Harvard and so ram and rom space is split,  this isn't the case with the Z80.

Why is this  a problem? Surely, the linker/locator puts the code in ROM and data in RAM automatically? Split address spaces is an advantage for 8-bitters since it effectively doubles the address space.
Pocket-Sized USB 2.0 LS/FS/HS Protocol Analyzer Model 1480A with OTG decoding.
Pocket-sized PCI Express 1.1 Protocol Analyzer Model 2500A. 2.5 Gbps with x1, x2 and x4 lane widths.
https://www.internationaltestinstruments.com
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #3 on: October 17, 2015, 11:27:22 pm »
IIRC, there is a 6502 emulator that runs on AVR...
(Hmm.  Several, it seems.  http://sbc.rictor.org/avr65c02.html )
 

Offline codeboy2k

  • Super Contributor
  • ***
  • Posts: 1836
  • Country: ca
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #4 on: October 18, 2015, 12:15:02 am »
I don't know what you're doing, but here's a free 6502 C compiler that's actively being worked on.

code https://github.com/cc65/cc65
wiki https://github.com/cc65/wiki/wiki
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #5 on: October 18, 2015, 03:34:47 am »
I want this package in a single chip AVR/8051 real bad,
MCS BASIC-52 (http://home.arcor.de/h.boehling/80c32.htm) includes an 8 digit BCD floating point package, which might be easier to extend than porting 6502 code. 

Quote
Problem with the AVR is that it is Harvard and so ram and rom space is split,  this isn't the case with the Z80.
Shouldn't be a problem unless the 6502 code is self-modifying.

Quote
do you think it's viable to try and translate the 6502 assembler to AVR assembler, literally coded instruction for instruction?
Yes. You will have to take into account different side effects of the opcodes (what flags they set etc.) and how the program uses them, but a good macro assembler should be able to translate the actual instructions quite easily. Many years ago I wrote an 8051 assembler that used 6502 style mnemonics, because I hated the Intel ones!
 
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #6 on: October 18, 2015, 05:38:48 am »
I also don't see why a homebrew 6502 system should be "10-15 chips."   http://www.philpem.me.uk/elec/6502/ ?  "modernized" 6502 systems are all over the web (some taking pains to be backward compatible with original older designs...)
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #7 on: October 18, 2015, 10:09:20 am »
You may want to roll your own, specially if you can write it in C. You don't really need BCD if you use something like base 100 or 10000. Look for the unix command bc, the sources.
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #8 on: October 18, 2015, 10:23:21 am »
Why is this  a problem? Surely, the linker/locator puts the code in ROM and data in RAM automatically? Split address spaces is an advantage for 8-bitters since it effectively doubles the address space.

Because in the AVR assembler (Studio 4) you have code/data segments assembler directives, this might not be a problem though.
 
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #9 on: October 18, 2015, 10:29:53 am »
Have you tried searching for floating point routines for other processors? What is so special about the 6502 routines, other than the fact you found them. A Z80 isn't a single chip solution either. I advise leaving porting as a last resort if it is a rewrite effectively. Too much like reinventing the wheel.

I have tried looking for BCD floating point routines for other processors, I came close with the Z80, but unfortunately couldn't get it to work on my simulator.Out of all the processors available to me the 6502 is the only one which offers a 16 digit floating point package. Believe you me I have searched high and low for the AVR but nothing.
« Last Edit: October 18, 2015, 10:55:45 am by commie »
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #10 on: October 18, 2015, 10:42:29 am »
MCS BASIC-52  includes an 8 digit BCD floating point package, which might be easier to extend than porting 6502 code. 

I am aware of MCS BASIC-52, I also have Microsoft 6502 basic and Microsoft Z80 basics all sporting 9 digit resolution. , I'm foaming at the mouth for 16 digits.
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #11 on: October 18, 2015, 10:53:08 am »
"modernized" 6502 systems are all over the web (some taking pains to be backward compatible with original older designs...)

HI Westfw,

If I design a 6502 system, then I want to build it around the KIM 1 hardware, this will give me terminal  and other support.
« Last Edit: October 18, 2015, 12:16:34 pm by commie »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #12 on: October 18, 2015, 10:54:06 am »
Just use one of the numerous arbitrary precision math packages around.  The GNU 'bc' library has been ported to Arduino so you are good to go with an AVR.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #13 on: October 18, 2015, 02:38:32 pm »
Just use one of the numerous arbitrary precision math packages around.  The GNU 'bc' library has been ported to Arduino so you are good to go with an AVR.
And it looks that Nick Gammon has implemented a nice C++ wrapper, which allows using familiar algebraic notation without pain.
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12860
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #14 on: October 18, 2015, 03:08:42 pm »
I wouldn't build a 6502 system on a bet.   At least a 8051 has current cross-assemblers and cross-compilers available, and a Z80 system can run CPM if you provide enough RAM, bulk storage (e.g. CF card) and a UART for a terminal.

Porting a maths package without a deep knowledge of the original architecture and instruction set and preferable a working system with debugger or accurate emulator is going to be a royal PITA, and debuggong it will be even worse.  If the source processor has a DAA instruction and the target processor doesn't or visa-versa, all BCD maths routines will need a total rewrite.


However if you want a powerful home-build 'retro' SBC, why not use a Motorola 68008?  You get most of the benefit of a 16 bit CPU with only an 8 bit bus, with no nasty multiplexing to deal with.  You can cross-compile for it with GCC which means the word is your oyster for maths packages that will run on it.   Take a look at: http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/
« Last Edit: October 18, 2015, 04:49:50 pm by Ian.M »
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #15 on: October 18, 2015, 03:48:43 pm »
I also don't see why a homebrew 6502 system should be "10-15 chips."

Hi Westfw,

I must admit the chip count is a bit steep, however I was going to design it around the KIM 1 giving me microsoft basic and the well written KIM monitor (running 1MHz only) which might explain the high chip count.I have since decided to go another route giving me microsoft basic and 2 to 4MHz clk rate and at the same time halving the chip count.
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #16 on: October 18, 2015, 04:02:28 pm »
Porting a maths package without a deep knowledge of the original architecture and instruction set and preferable a working system with debugger or accurate emulator is going to be a royal PITA, and debuggong it will be even worse.  If the source processor has a DAA instruction and the target processor doesn't or visa-versa, all BCD maths routines will need a total rewrite.
Yep, I was just mulling over the AVR instruction set a little while back, has no DAA and no SED set decimal mode instructions, that's looking nasty as you say.
But I'm glad someone recognises how difficult the task is. I just want to point out something else as well, my AVR compiler supports IEEE 754 64-bit floats, but I can't use it because of the errors induced into the argument going from in to out and out to in and that's why calculators only use bcd.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #17 on: October 18, 2015, 04:34:11 pm »
Choosing a 6502 architecture just because you found a 6502 decimal library seems too harsh. I would keep searching for a more portable C/C++ package.

What kind of match operation do you want to have with decimal accuracy?

Also, remember that you don't have to use bcd to achieve decimal accuracy. You can use binary with decimal exponent or if you want actual decimal representation you can pack two digits in one byte (range 0-99) to make the decimal carry/adjustment easier.

A quick internet search brings these:

http://speleotrove.com/decimal/decarith.html   // specification

http://speleotrove.com/decimal/dnintro.html     // one implementation in C

Get a decent package and a modern, small, and cheap ARM MCU (they are cheap) and you will be set.

« Last Edit: October 18, 2015, 04:35:59 pm by zapta »
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #18 on: October 18, 2015, 08:07:05 pm »
I was just mulling over the AVR instruction set a little while back, has no DAA and no SED set decimal mode instructions
No DAA? Well I guess you will just have to give up on the AVR.

Or...
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #19 on: October 18, 2015, 08:51:49 pm »
However if you want a powerful home-build 'retro' SBC, why not use a Motorola 68008?  You get most of the benefit of a 16 bit CPU with only an 8 bit bus.

Quick run through Mouser reveals no 68k for sale, in fact they have never heard or seen it before. However, the 6502 and Z80 with support chips are still available for sale. I don't think corporate America liked the 68k for some reason? :-//
 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #20 on: October 18, 2015, 09:18:04 pm »
I don't understand this thread. Surely whatever is coded into this 6502 routine is derived from an algorithm that you can easily translate to whatever CPU you choose?

I do have a fondness for 6502 because when I was a kid I had a BBC Micro and having the best version of BBC BASIC on the planet that also had inline 6502 assembly (two pass, so labels too!) I would often drop into assembler. However as assembler goes it was definitely RISC (before that became a thing). Programming Z80 was much easier, well, except for the ZX Spectrum REM statements or my old SHARP MZ-80 that I actually hand coded in hex using the back of the reference manual (oh wow, I would actually calculate the JRNZ's by hand and type them in in hex - no mnemonics)

Seriously, why are you fixated on a math function from the 70's in 6502 to port to AVR when there are so many others you could use instead?

If it is just because you really want to then look at reverse engineering it (figuring out the higher level implementation) and then converting it if that floats ya boat!
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12860
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #21 on: October 18, 2015, 09:36:46 pm »
You'll need to pick one up NOS or refurb off ebay or similar e.g. http://www.ebay.ca/itm/1pcs-MC68008P8-MC68008-16-Bit-Microprocessor-With-8-Bit-Data-Bus-/261349278378 

If you don't need a DIP package, the PLCC version has two more bits of address bus giving a 4MB address range - which makes it possible to add more RAM for stuff like uClinux.
 

Offline wd5gnr

  • Regular Contributor
  • *
  • Posts: 179
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #22 on: October 18, 2015, 09:43:58 pm »
http://www.micromegacorp.com/ make this add on fpu for avrs and things. its interesting, uses i2c/spi to talk etc. 5v tolerant. may or may not be useful info.

And the venerable: http://www.awce.com/pak1.htm -- surprising what these have found their way in. If you prefer an "ASCII" calculator try http://awce.com/pak12.htm

 

Offline retrolefty

  • Super Contributor
  • ***
  • Posts: 1648
  • Country: us
  • measurement changes behavior
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #23 on: October 18, 2015, 09:46:47 pm »
However if you want a powerful home-build 'retro' SBC, why not use a Motorola 68008?  You get most of the benefit of a 16 bit CPU with only an 8 bit bus.

Quick run through Mouser reveals no 68k for sale, in fact they have never heard or seen it before. However, the 6502 and Z80 with support chips are still available for sale. I don't think corporate America liked the 68k for some reason? :-//

 Honeywell used 68K chips for a couple of decades with their TDC-3000 (and follow-up models) DCS process control systems. 68040 was the last chip I saw being used by them when I retired.

 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #24 on: October 18, 2015, 09:52:16 pm »
No DAA? Well I guess you will just have to give up on the AVR.
Or...

Well, I learned something today, hence the AVR has no BCD support instructions in it, I just can't believe it.. :scared:

Anyway thanks for posting those AVR routines, note I'm not trying to convert from binary to bcd or bcd to binary, instead I want to do bcd arithmetic.
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #25 on: October 18, 2015, 10:02:06 pm »
http://www.micromegacorp.com/ make this add on fpu for avrs and things. its interesting, uses i2c/spi to talk etc. 5v tolerant. may or may not be useful info.

And the venerable: http://www.awce.com/pak1.htm -- surprising what these have found their way in. If you prefer an "ASCII" calculator try http://awce.com/pak12.htm

Here we go again, you cannot use 32 or 64 bit IEEE 754 floating point for accurate calculations, the reason for this is that there is a error prone conversion process going from ascii to fp and from fp  back to ascii. The solution to this problem is to use BCD notation which requires no error going in/out of the processor.
 
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #26 on: October 18, 2015, 10:12:39 pm »
I don't understand this thread. Surely whatever is coded into this 6502 routine is derived from an algorithm that you can easily translate to whatever CPU you choose?

You must be joking :-DD, you think software comes equipped with a flow chart?

Seriously, why are you fixated on a math function from the 70's in 6502 to port to AVR when there are so many others you could use instead?

Because up to the present, there is nothing to replace it.Why did TI use an old '70's z80 for their range of graphing calculators?
 

Online IanB

  • Super Contributor
  • ***
  • Posts: 11885
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #27 on: October 18, 2015, 10:50:29 pm »
But I'm glad someone recognises how difficult the task is. I just want to point out something else as well, my AVR compiler supports IEEE 754 64-bit floats, but I can't use it because of the errors induced into the argument going from in to out and out to in and that's why calculators only use bcd.

Here we go again, you cannot use 32 or 64 bit IEEE 754 floating point for accurate calculations, the reason for this is that there is a error prone conversion process going from ascii to fp and from fp  back to ascii. The solution to this problem is to use BCD notation which requires no error going in/out of the processor.

This is not, in fact, true. You are creating difficulties for yourself by imagining a problem that is not there.

When used correctly, floating point arithmetic in any base is just as susceptible to precision errors as in any other base (whether decimal or binary). Where BCD is chosen (for example for financial calculations) it is fixed point, not floating point. Fixed point leads to a different set of issues, which in same applications may be easier to manage.

There is a reason scientific computing is done with binary floating point arithmetic on every computer in the world. Pocket calculators were designed differently not for reasons of precision or accuracy, but for convenience of design with a small chip count and low power consumption. Double precision 64-bit IEEE 754 is far more accurate than any pocket calculator I have compared it with.
« Last Edit: October 18, 2015, 11:33:47 pm by IanB »
 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #28 on: October 18, 2015, 10:55:51 pm »
commie, no flow chart - you just need to use something called a disassembler. Make your own from that.

Besides the only time I've ever encountered such (non floating) decimal point is in crappy ancient mainframe COBOL stuff that was riddled with Y2K bugs.

The principle is very simple - why not code your own from scratch?
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12860
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #29 on: October 18, 2015, 11:14:43 pm »
Writing high precision floating point applications for a legacy 8 bit CPU in assembler is pure masochism.  You either have or can obtain C compilers for all your potential targets except the 6502, and already have been pointed at an ANSI C IEE 754 decimal64/decimal128 compatible float library.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #30 on: October 18, 2015, 11:35:37 pm »
I am sure a 84MHz STM32F411 at $7 a chip, will run a 6502 emulator faster than a 1MHz 6502 :-), let alone with all the other alternative ways that people have suggested already.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #31 on: October 19, 2015, 01:56:48 am »
Quote
the AVR has no BCD support instructions in it
they were one of the first things to disappear in "RISC" instruction sets.

Quote
there is a error prone conversion process going from ascii to fp and from fp  back to ascii.
As Ian said, this is crap.   There is a deterministic and predictable imprecision in conversion of ascii decimal floating point numbers to binary representations.  If your program is constantly converting back and forth, it might need to pay attention to this.  (but, most programs don't.) (and... any floating point representation introduces errors that you need to pay attention to in high-precision calculations, just because there are always some values that can't be represented exactly.  They used to teach this, back when floats were only 32 to 36 bits.  It seems largely ignored now that they're 64 to 80 bits or more.)

Do you need actual floating point?   As several people have pointed out, there are a bunch of standard multi-precision libraries written in nice level languages with lots of documentation.    Some have been ported to small microcontrollers - for example the gnu "bc" library has been ported to Arduino: http://www.gammon.com.au/forum/?id=11519   Several languages support arbitrary precision math in addition to standard floating point formats...
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: de
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #33 on: October 19, 2015, 05:02:56 am »
Quote
There is a reason scientific computing is done with binary floating point arithmetic on every computer in the world. Pocket calculators were designed differently not for reasons of precision or accuracy, but for convenience of design with a small chip count and low power consumption. Double precision 64-bit IEEE 754 is far more accurate than any pocket calculator I have compared it with.

The reason: speed. No other reason. If decimal arithmetic were as fast as binary, binary would not be used. And anyways at least for chemistry, the constants used to describe the atoms are 7, 8, 9 digits accurate...
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #34 on: October 19, 2015, 05:22:40 pm »
note I'm not trying to convert from binary to bcd or bcd to binary, instead I want to do bcd arithmetic.
;**** A P P L I C A T I O N   N O T E   A V R 2 0 4 ************************
;*
;* Title:      BCD Arithmetics
;* Version:      1.1
;* Last updated:   97.07.04
;* Target:      AT90Sxxxx (All AVR Devices)
;*
;* Support E-mail:   avr@atmel.com
;*
;* DESCRIPTION
;* This Application Note lists subroutines for the following Binary Coded
;* Decimal arithmetic applications:
;*
;* Binary 16 to BCD Conversion (special considerations for AT90Sxx0x)
;* Binary 8 to BCD Conversion
;* BCD to Binary 16 Conversion
;* BCD to Binary 8 Conversion
;* 2-Digit BCD Addition
;* 2-Digit BCD Subtraction

 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #35 on: October 19, 2015, 07:35:06 pm »
note I'm not trying to convert from binary to bcd or bcd to binary, instead I want to do bcd arithmetic.
;**** A P P L I C A T I O N   N O T E   A V R 2 0 4 ************************
;*
;* Title:      BCD Arithmetics
;* Version:      1.1
;* Last updated:   97.07.04
;* Target:      AT90Sxxxx (All AVR Devices)
;*
;* Support E-mail:   avr@atmel.com
;*
;* DESCRIPTION
;* This Application Note lists subroutines for the following Binary Coded
;* Decimal arithmetic applications:
;*
;* Binary 16 to BCD Conversion (special considerations for AT90Sxx0x)
;* Binary 8 to BCD Conversion
;* BCD to Binary 16 Conversion
;* BCD to Binary 8 Conversion
;* 2-Digit BCD Addition
;* 2-Digit BCD Subtraction


Bruce, thank you for trying, I have seen this document and I can already do 2 digit bcd add/subtract. What I am looking for is 'at least' 16 digits bcd multiply and divide with auto exponents.

 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #36 on: October 19, 2015, 07:58:23 pm »
As Ian said, this is crap.   There is a deterministic and predictable imprecision in conversion of ascii decimal floating point numbers to binary representations.  If your program is constantly converting back and forth, it might need to pay attention to this.  (but, most programs don't.) (and... any floating point representation introduces errors that you need to pay attention to in high-precision calculations, just because there are always some values that can't be represented exactly.  They used to teach this, back when floats were only 32 to 36 bits.  It seems largely ignored now that they're 64 to 80 bits or more.)

Why is it crap?, Using IEEE754 32 bit floats requires two associated i/o routines for use which convert an ascii string(number) into 32 bit floating point format, this input routine introduces small errors.Some numbers have an exact fit but many don't and those that don't fit produce a small error. If you now send the same 32 bit float to the screen there is likely to be yet another small error introduced because of the conversion process of the output routine.
IEEE754 fp's are extremely byte efficient, at the expense of accuracy because IEEE754 require elaborate i/o routines to function correctly.
BCD floating point, on the other hand, don't need an i/o routine, they are completely transparent to binary/hex and decimal. Do you think the smart guys would include bcd floating point arithmetic in our compilers? and if they did, risk destroying the international calculator industry at large?

IEEE 754 is of course okay for use in the process/instrumentation industry because we only display the result to one or two fractional decimal digits where errors of IEEE754 don't show or are too small to be any significance.
 
« Last Edit: October 19, 2015, 08:17:10 pm by commie »
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #37 on: October 20, 2015, 08:19:57 am »
Bruce, thank you for trying, I have seen this document and I can already do 2 digit bcd add/subtract. What I am looking for is 'at least' 16 digits bcd multiply and divide with auto exponents.
The 6502 only two has instructions that use BCD - ADC and SBC. If you can emulate these on the AVR then porting the the rest of the code should be easy. AVR204 show you how to do it.

 



 
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #38 on: October 20, 2015, 11:01:32 am »
You can even use one byte for each digit, so you don't have to use the BCD-related instructions and you don't have to unpack and pack the digits when performing multiply and division, for instance. The exponent +/- 127 can be packed into one byte, it can be used as an ordinary signed integer, and it will not suffer from the rounding errors. One-byte-per-digit "wastes" some memory, but otherwise it will make your life easier. And, if the RAM space is really of concern, you can always unpack and pack the numbers before and after you operate on the numbers.
« Last Edit: October 20, 2015, 12:39:43 pm by Kalvin »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #39 on: October 20, 2015, 03:28:19 pm »
Ooohh.  There is now "Dense Packed Decimal."  3 digits in 10bits.  (though apparently you unpack it to use it...)
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #40 on: October 20, 2015, 03:37:59 pm »
Ooohh.  There is now "Dense Packed Decimal."  3 digits in 10bits.  (though apparently you unpack it to use it...)
Better yet, you can pack four digits in the 14bits! ;)
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #41 on: October 20, 2015, 06:50:21 pm »
You can even use one byte for each digit, so you don't have to use the BCD-related instructions and you don't have to unpack and pack the digits when performing multiply and division, for instance. The exponent +/- 127 can be packed into one byte, it can be used as an ordinary signed integer, and it will not suffer from the rounding errors. One-byte-per-digit "wastes" some memory, but otherwise it will make your life easier. And, if the RAM space is really of concern, you can always unpack and pack the numbers before and after you operate on the numbers.

The KImath routines use packed and unpacked bcd extensively,  their argument for doing this, is it makes bcd multiplication/division execution very quick and one website I have came across, goes so far as to say unpacked bcd is the only way to bcd multiplication/division.KImath was introduced for the Mos Technology 6502 KIM 1 sometime during 1976. I have two books, one for the 6502 the other for the Z80, these books were published during 1984, in both of them I have found a multi digit bcd multiplication/division/subtraction and addition routines.
I've keyed in the multiplication routine and sure enough it works, to increase the number of digits  is trivial. Nowhere in the text is there any hint or reference to packed/unpacked bcd?. The routine is about 200 bytes long and is complicated, I get lost trying to follow it but there you go.

The problem now is, how do I attach an exponent to a multi byte bcd number? The only viable way I can think of, is repeated division by 10 and counting the divisions until the number drops below 10 in value, the division count is then your exponent value.

If anyones interested, "Z80 ASSEMBLY LANGUAGE SUBROUTINES", by Lance A. Leventhal and Winthrop Saville 1983

 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #42 on: October 21, 2015, 07:07:35 am »
 :palm:
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #43 on: October 21, 2015, 09:30:18 am »
You still haven't said what's wrong with the existing multi-precision libraries.   The BC library that's been ported to Arduino is one digit per byte, so it shouldn't have any problem addressing your concerns about conversion accuracy...
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #44 on: October 21, 2015, 05:45:23 pm »
The problem now is, how do I attach an exponent to a multi byte bcd number? The only viable way I can think of, is repeated division by 10 and counting the divisions until the number drops below 10 in value, the division count is then your exponent value.
Do you mean how to convert a BCD integer or fixed point number (eg. 12345.6789) to floating point (eg. 1.23456789 e+4)? Just skip any leading zeros and count the number of digits before/after the decimal point.
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #45 on: October 21, 2015, 06:24:53 pm »
Do you mean how to convert a BCD integer or fixed point number (eg. 12345.6789) to floating point (eg. 1.23456789 e+4)? Just skip any leading zeros and count the number of digits before/after the decimal point.

Hi Bruce,

Yep, that's what I thought originally, but supposing you multiply two 12 digit fixed point numbers together and suppose the answer comes out with say arbitrary as 1234000056789, i.e., note the zero's are embedded in the result, so my zero detector comes along and detects a pair of zeros and my software thinks it has come to the end of the result when  in fact it all it has done is detected zero in the middle of the result, right?  :-//
« Last Edit: October 21, 2015, 06:46:11 pm by commie »
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #46 on: October 21, 2015, 06:38:04 pm »
You don't stop at zeros.. you have to count them all. Because each digit on the right of the first non-zero on the left if not significant because of limited number of digits give you the exponent when on the left of the decimal point.

I follow this from the start and I think you may be seeing this thing all wrong. Just write on paper how the number should look like and how you are going to store it. You may get a better picture. Your "floating point" number is a structure with three fields, the exponent is one of them, you store it either at the beginning or at the end it doesn't matter as long as you always treat the structure the same way...
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #47 on: October 21, 2015, 07:05:13 pm »
You don't stop at zeros.. you have to count them all. Because each digit on the right of the first non-zero on the left if not significant because of limited number of digits give you the exponent when on the left of the decimal point.

Your last post has given me new inspiration, I was counting from the wrong direction/end, thanks for that Bruce and ALE500. :D

I've got some work to do.
« Last Edit: October 21, 2015, 07:07:36 pm by commie »
 

Offline exmadscientist

  • Frequent Contributor
  • **
  • Posts: 342
  • Country: us
  • Technically A Professional
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #48 on: October 22, 2015, 04:37:33 am »
Here we go again, you cannot use 32 or 64 bit IEEE 754 floating point for accurate calculations, the reason for this is that there is a error prone conversion process going from ascii to fp and from fp  back to ascii. The solution to this problem is to use BCD notation which requires no error going in/out of the processor.

Do you think the smart guys would include bcd floating point arithmetic in our compilers? and if they did, risk destroying the international calculator industry at large?

IEEE 754 is of course okay for use in the process/instrumentation industry because we only display the result to one or two fractional decimal digits where errors of IEEE754 don't show or are too small to be any significance.

Bruce Dawson has what is, in my mind, the definitive response to this... concern....

His entire series of blog posts on IEEE-754 floating point is highly recommended reading for anyone who wants to really understand -- or thinks they already understand -- the guts and twisted dark corners of IEEE-754.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #49 on: October 22, 2015, 04:51:28 am »
Here is some working code in C for BCD fp mul:
I compiled it and tested in avr, arm and pic32 (mips). The given time is for mips. It encodes one BCD (base-10) per byte. I went for base 100 because you get the same speed for two times the number of digits.
Code: [Select]

#ifdef SMALL
    #define BCD_MAXDIGITS 8
    #define BCD_MAXWIDTH  13
    #define BCD_MAX_EXP 99
    #define BCD_MIN_EXP -99
    typedef int8_t exp_t;
#else
    #define BCD_MAXDIGITS 20 // we should safely get 16 decimal places
    #define BCD_MAXWIDTH  24
    #define BCD_MAX_EXP 999
    #define BCD_MIN_EXP -999
    typedef int16_t exp_t;
#endif

#define BCD_LASTDIGIT (BCD_MAXDIGITS-1)

typedef struct {
    uint8_t sign;
    exp_t dexp;
    uint8_t frac[BCD_MAXDIGITS];
} T_SBCDREAL;

_CNT uint8_t mullow[][16] = { { 0 },
                            { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 },
                            { 0, 2, 4, 6, 8, 0, 2, 4, 6, 8 },
                            { 0, 3, 6, 9, 2, 5, 8, 1, 4, 7 },
                            { 0, 4, 8, 2, 6, 0, 4, 8, 2, 6 },
                            { 0, 5, 0, 5, 0, 5, 0, 5, 0, 5 },
                            { 0, 6, 2, 8, 4, 0, 6, 2, 8, 4 },
                            { 0, 7, 4, 1, 8, 5, 2, 9, 6, 3 },
                            { 0, 8, 6, 4, 2, 0, 8, 6, 4, 2 },
                            { 0, 9, 8, 7, 6, 5, 4, 3, 2, 1 } };
_CNT uint8_t mulhigh[][16] = { { 0 },
                            { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
                            { 0, 0, 0, 0, 0, 1, 1, 1, 1, 1 },
                            { 0, 0, 0, 0, 1, 1, 1, 2, 2, 2 },
                            { 0, 0, 0, 1, 1, 2, 2, 2, 3, 3 },
                            { 0, 0, 1, 1, 2, 2, 3, 3, 4, 4 },
                            { 0, 0, 1, 1, 2, 3, 3, 4, 4, 5 },
                            { 0, 0, 1, 2, 2, 3, 4, 4, 5, 6 },
                            { 0, 0, 1, 2, 3, 4, 4, 5, 6, 7 },
                            { 0, 0, 1, 2, 3, 4, 5, 6, 7, 8 } };


/**
 * Multiplies 2 BCD numbers
 * it can use the same number as argument and result
 * 99.99999999*99.99999999 takes 1833*2 with -O3
 */

void t_bcd_mul(T_SBCDREAL *r, T_SBCDREAL *a, T_SBCDREAL *b)
{
    int8_t i, j, k, y, c;
    uint8_t frac[BCD_MAXDIGITS*2];
    uint8_t *xl, *xh;
    r->dexp = a->dexp + b->dexp;
    r->sign = a->sign ^ b->sign;
    for (i = 0; i < BCD_MAXDIGITS+BCD_MAXDIGITS; i++) frac[i] = 0;
    for (i = BCD_MAXDIGITS-1; i >= 0; i--)
    {
        j = b->frac[i];
        if (j) {
            xl = (uint8_t *)&mullow[j][0];
            xh = (uint8_t *)&mulhigh[j][0];
            k = BCD_MAXDIGITS + i;
            c = 0;
            for (j = BCD_MAXDIGITS-1; j >= 0; j--, k--) {
                y = *(xl+a->frac[j]) + c + frac[k];
                c = *(xh+a->frac[j]);
                if (y >= 10)
                {
                    c++;
                    y -= 10;
               
                }
                frac[k] = y;
            }
            frac[k] = c; // last carry
        }
    }
    if (c) {  // MSD is the carry
        for (i = 0; i < BCD_MAXDIGITS; i++)
            r->frac[i] = frac[i];
        r->dexp++;
        r->frac[0] = c;
    }
    else
        for (i = 0; i < BCD_MAXDIGITS; i++)
            r->frac[i] = frac[i+1];
}
« Last Edit: October 22, 2015, 04:54:37 am by ale500 »
 

Offline commieTopic starter

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: gb
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #50 on: October 22, 2015, 12:29:48 pm »
Hi ALE500,

I did a similar  thing with BASCOM AVR using base 10, however I lost interest in my code because it compiled down to a massive 1.5kbytes that's just for multiplying two 16 digit bcd(fixed point) numbers together.Although given AVR flavours come up to 256k bytes, that shouldn't be a problem.

 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: 6502 KIMATH, should I try and port it to Z80 or AVR mega?
« Reply #51 on: October 22, 2015, 03:10:48 pm »
On MIPS32 a base-100 version with similar code compiles to 312 bytes, not bad :).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf