ElEctric_EyE wrote:
I'm definitely interested in your tables Garth. Is hex straight binary?
Intel Hex is a method of representing the binary data in a text file which has some error-detection built in. The method is described at
http://wilsonminesco.com/16bitMathTables/IntelHex.html which is one of the pages in the group. It is commonly used by EPROM programmers, although there are other ones they use also, Motorola S-record probably competing with it for top spot. Although EPROM programmers will generally handle multiple file types, you can also convert from one type to another with a software called SRecord. I put this blurb in my main page on the files:
Since my Needham's EPROM programmer software seems to have a bug in it for large files (and Needham's is out of business), I went on a quick search and found SRecord 1.60. Initially I just wanted to confirm that my Intel Hex files were valid and error-free as far as Intel Hex goes; but this software also lets you transform EPROM file types, concatenate, split, etc.. Version 1.52 is in the Ubuntu (Linux) software center for one-click download and installation. Enter "EPROM" for a search term and it comes right up. SRecord is command-line-only, which initially made it confusing because I didn't see any new icons and couldn't find it under "Applications". The voluminous .pdf manual could stand to have better command-line examples, but you'll figure it out. Much of the manual is spent on telling about multitudes of file types you will never use, so there's not really that much that you have to read.
Quote:
I was thinking of using them, maybe the SIN table, for doing circles in my graphics plotting routines using the 16-bit 65Org16.
and of course you can use the SIN table to get COS & TAN too. For COS, you just add 90° to the input first, and for TAN, take both the SIN & the COS as a rational number. (Info like that, plus much more complete, is in the "math table files' descriptions" clickable link at the top.)
Quote:
What's nice about it is that is (mostly) universal, and can be used on other processors. The idea of a serial, universal "co-processor" is novel too. I was thinking it might be useful in the robotics area, where a simple controller could leverage these functions for work perhaps with an arm or some other higher order math.
Actually it's good for virtually
any kind of machine control or automation. Although it's good for graphics, it might shine most in non-human I/O applications.
Quote:
But then it came to mind a question of whether they need 16 bits of resolution or not. I simply don't know; perhaps a 8-bit resolution is adequate for most tasks of that nature.
In that case you might read only the high 8 bits and not the low 8 bits of a cell, although it's there for other times when you want the whole thing. Graphics on a low-res display might be a good application for only using the top 8 bits.
Quote:
But extending the concept, not simply to trig functions, but to any function -- memoizing [memorizing?] the entire domain, that's also interesting.
If someone offers a way for others who don't have my setup to calculate their own tables and make the hex files, I would like to link to it in my articles. Hopefully it would be a non-intimidating way.
Quote:
Again from a robotics standpoint, much of the physics can be pre-calculated with properly bracketed data, combined with the serial access piece, the most simple and slowest of controllers can make use of specialized, sophisticated maths.
True. I didn't really think of that. For a lot fewer parts and less board space there's the floating-point serial coprocessor available at
http://www.awce.com/pak1.htm (although their very first paragraph shows they are not acquainted with how to do scaled-integer math). However, they say their worst-case add time takes 55µs and worst-case divide instruction takes 190µs; so how much longer must one of the more-complex functions take?! The serial method I show with the look-up tables takes under 36µs for
any 16-bit function, even the most complex, on a 10MHz 6502 making the serial connection through a 6522; and that's not quite optimized since I used an empty JSR-RTS for some delays to give time for bytes to shift in & out, which gave a little more delay than I needed. The fastest method I give with the memory directly on a 65816's bus takes 3.5µs at 10MHz, again even for the most complex 16-bit function. It's not quite an apples-to-apples comparison, but it's clear that you gain a big performance advantage when you avoid the overhead of floating-point and also go with the tables.