6502.org

Hello,


Now i'm retired, I want to continue to build my small autonomous robots.
In the robot club, all the users/builders are using very fast and complex microprocessors boards.

We are all older guys, and no new (younger) members are interested in building robot stuff.

So as one of these older guys and as a challenge,
I want to build a new robot which is fully controlled with 6502 CPU (I found in my 'mans cave' a 4MHz clock version).
For that, I need a lot of trigonometry functions (Cos, Sin, Tan, Sqr, ...)
and single FP values (32 bits) for these functions.

For the functions I was looking for using FP lookup table, but this takes a lot of ROM spaces ...

I like a compiler (as I think) an interpreter is slower ??


I'm working on PC with win 10 as OS.

Q) Is there a good ASM, BASIC editor/compiler for PC ?
- Tiny basic / Ehbasic ?

To compile ASM, BASIC, and create machine code so I can program it in a
or > EPROM 27C256 (32KB)
or > EEPROM 28C256 (32KB)
or > FLASH 29F256 (32KB)

Or, I was looking for a multiplex hardware version,
so I can use one ROM for every function in a larger lookup table ...


I think I gone a need lots of good advice here ...
Thanks,
marc

I don't know if you seen Garth Wilson's 16bit Math Tables. Very useful for trig calculations and it has a 6502 based SIN example.

The downside is just the SIN table is 128KB which is going to need a bigger ROM than any you've listed. An SST39SF040 is still available as a DIP and will give you 512KB of space; enough for the tables you need I think. Decoding and bank switching all that ROM is going to be a bit of as task but Garth has a couple of ideas listed on his website above.

The other option, if you're having to order in bigger ROMs anyway is to try a 65C816 instead of a 6502. It's also still available as a DIP but the 24bit address space and 16bit arithmetic will make trig calculations much quicker.

Hi,

It's easy to use a modern board - you get lots of ROM, Flash, IO (in the form of SD card, USB, Wi-Fi) and so on. You can program them in high level languages, C, Python and more. So you can see why people are attracted to them.
Once upon a time (40+ years ago) I did some work on a Unimate (Unimation?) Puma 6 DoF robot arm. From what I gathered each joint had it's own 6502 with a 'master' PDP11 working as an overall controller... Interesting stuff... I was also part of a team designing various robots for factory automation - I used 6502s mostly there too. They are quite capable, depending on what you're doing.

For simple line-following robots you don't really need any trig. You will need trig for 3 DoF arms but it's not hard to work out and once you have square root and sine you can get the rest.
So what else are you going to use the ROM for?

There are solutions involving 'paged' or 'banked' ROMs full of data - I'm sure Garth will pop along soon with links to his stuff.... Or use the '816 CPU - not as an '816 CPU but in 65C02 emulation mode with just enough native code to fetch data from it's extended (24-bit) address space - which you can pre-program with data for various functions. I did that as an experiment and filled 2 x 64K RAM banks in a 512KB system with the result of every 8x8 multiply to give me a very very fast 32-bit multiply routine (in the end I decided I didn't care for wasting that much RAM, but it was a good test of what was possible).
For development I use the cc65 suite. It gives me the same working environment I've used for C and ASM for about the past 40 years - separate editor (with Makefiles), compiler, assembler and linkers. I use Linux but it does work under Windows too.

For Basic - TinyBasic is very slow (and I know, as I've written one), there are small tokenizing basics which might be marginally better. EhBasic is also rubbish (IMO) as it's essentially Microsoft Basic with a few tweaks. However it is/should be easy to port and get going. If you want a good, FAST Basic with modern features like named procedures, recursion, local variables, etc. then you want to look at BBC Basic. It's the fastest interpreted Basic that you can easily get for the 6502 (and 65C02) BBC Basic has 32-bit integers which are very fast also 40-bit floating point which is also very fast - you could do worse than to grab its sources and take out the floating point stuff. It's more than double the speed of EhBASIC for the most part, on the same hardware (I've benchmarked both)

Or ... Stick with the minimal stuff - I recently built a system with 4K ROM and 4K RAM with some LEDs and enough digital IO to make e.g. a line-following robot.

Making a paged ROM is not hard - you just need a latch to control the upper N bits of the address space (or however you want to carve it up). Eg. the BBC Micro has RAM from $0000 through $7FFF then the 16K area from $8000 through $BFFF is selectable from one of 16 different images, then there is the OS ROM from $C000 through $FFFF with a small 'hole' for hardware IO use.

My tiny system has a 32KB EEPROM which is divided up into 8 x 4KB banks - only one is active at any time - the down-side is that code to switch banks here must be copied into RAM while on the BBC Micro the code is in the upper 16KB of ROM
The problem with asking for advice is that you get opinions. And there are many of them. Also many places to ask - e.g. Facebook has some very active 6502 pages if you like that sort of thing.

The key is to enjoy what you're doing and not let it feel like a chore - specially now you're retired...

-Gordon

Hi AndrewP and drogon,


Thanks for the info,
I gone look around, and then designing my new robot.
I have some time now, so, ...

I was thinking to write my one asm/basic compiler for the 6502/68HC11/68000
as these are the 3 CPU I worked the most with in the past.

If you have a Sin() table, and extend it with 90 deg,
you can with an offset use it for Cos() also.



@Gordon

For a contest in the robot club, we need to collect 5 cola cans,
and bring them to the base station.

So, I'm building a robot arm, with a pneumatic gripper for that,
yes I know, it is much to complex for that task, but it is fun to do, and I learn a lot of robot arm control.
Like you say, its the path to the goal who is the fun ...

Also for the Inverse Kinematics I need lots FP calculations ...
I'm thinking using a Teensy 4.1 for this, this MicroController have a hardware FP core in it.

I will take a look to the BBC basic ...


Thanks,
marc

Makes me wonder if having a Am9511/Am9512 would be worth while.

By "FP," I assume you mean "floating-point," although you never spell that out.  I really doubt that you need floating-point arithmetic for this.  Please see the section of my website on large look-up tables for 16-bit scaled-integer math, mentioned already by the others above.  Having the tables makes these functions very fast, like having a coprocessor, in the extreme case even hundreds of times as fast as having to actually calculate the answer; and all answers are there, pre-calculated, not requiring any interpolation at all.  For division, since there's no realistic way to do it by table, you can use the table of inverses to invert the divisor and then multiply, and there's a way to use the table of squares to dramatically speed up the multiplication too.  The table of inverses has 32-bit outputs (it's a 256KB table), so you can get full precision across the entire 16-bit range.  You may not need to use all four bytes of every answer.

The front page of that part of the website describes how you can use scaled-integer and why you probably don't need floating-point.  It is common for people to make the mistake of equating it to fixed-point, which is a limited subset of scaled-integer math.  Scaled-integer is more powerful than fixed-point.  With 16-bit scaled-integer numbers, the resolution you get in angles is .0054932°, or 0.32959 arc-minutes, or 19.775 arc-seconds.  If you had a 16-bit A/D converter with a 4.096V reference, the resolution would be 62.5µV.

Linked on that page also are the many table files, their descriptions and how to use them, how they were formed, rational-number approximations (for example that to multiply a 16-bit number by pi, you can multiply by 355, using a higher precision 32-bit intermediate result, and divide that by 113, which is accurate to eight digits even though you're not using floating-point), and how Intel Hex files work (Intel Hex being the format the tables are provided in so you can program them into EPROM or load them into RAM).  The front page of that section also tells how you can interface the large memory even to a 6502 which has only a 16-bit address bus.  EPROM is available up to one megabyte in a 32-pin IC.

Sounds like an interesting project!

There are a couple of kinds of approaches, I think: one is to make it easy on yourself, which leads to using high level languages and a modern microcontroller, and another is to be really efficient with resources, which means using a 6502, and any adequately high precision with adequately high performance. And of course there's a whole range of stopping off points in between.

BBC Basic's five byte floats and fast accurate trig is almost certainly fast enough. But you might enjoy the engineering exercise of seeing if (say) three byte fixed point is accurate enough, and if some home-grown trig routines are fast enough. Big tables will be fast, there will be tradeoffs around accuracy, and of course with huge tables you need banked memory so your hardware project is more complex.

At one time there was a lot of interest here in EhBasic, which is a derivative of MS Basic. For myself, I prefer BBC Basic. But people here have also written their own languages, so choose whatever suits you - for interest, and for progress.

Thanks for the posts,


But, I need some help,

- For my robot arm, if segment2 (150.0 mm) and segment3 (120.0 mm) are in linear position,
the max. distance from the robot arm base, will be 150.0 mm + 120.0 mm = 270.0 mm

- If I want a resolution in the motion of the Zaxis rotation (top view)
that will give me a circumference of (2*pi*radius) = 2 * 3.14159 * 270.0 = 1696.460033 mm

- my steps will be, at a resolution of 0.1 deg
360.0 deg/rev / 0.1 deg/step = 3600 steps/rev

- The resolution on the max robot arm distance will be,
circumference / steps/rev = 1696.460033 mm/rev / 3600 steps/rev = 0.4712 mm/step

- for my data of cos()/sin()
Q) can I use a resolution of 0.10000 deg/step with a 16 bits floating point data


I don't know that I'm in the good direction with my calculations ??
And its all new for me, a floating point calculation with a 8 bits CPU.


I just love it, is a new challenge, so ...
Controlling all with one 6502 CPU at 4 MHz and a 6522 VIA.

PS: I found some older EPROMS 27C2001 (256 KB) and 27C4001 (512 KB)


Thanks,
marc

Sorry for the picture, it's all in dutch,

gegevens = data
grijper = gripper
segment 2 = old data = 149.0 mm, now = 150.0 mm

As a quick reaction, it sounds to me like you need 16 bits of precision.

You might be able to do without floating point, but if you do use it, you've moved some difficulty into the building of the floating point package, and removed some difficulty from the user-side calculations.

So, three-byte floats might be enough. MS Basic can be built with either 4 or 5 byte floats, so probably either of those would do. Just possibly that existing build-time flexibility could be used to make a 3 byte version, or possibly it's not something you'd like to do.

Another language option is FORTH.
It is useful if you want to be "close to the computer hardware".
It is compiled. It can be self-hosting.

Here is a console log of some scaled-integer trig stuff worked using FORTH.
It also includes disassembly listings of all of the words (subroutines) defined.

Some FORTH implementations:
For 65c02 there is https://github.com/scotws/TaliForth2
For 6502 NMOS with ROR, I have a hacked fork at https://github.com/leepivonka/TaliForth2 (also has some floating-point)
For 65816 I've got an option

I like your robot arm.

I have built several robots. The languages include C, C++, Forth, and assembly. In C/C++ I use the float data type and associated C-RTL trig functions. But these can really bog down a microcontroller because there's a lot going on in the C RTL.

When I use Forth or assembly, I only use 16-bit scaled integer arithmetic. I've done inverse kinematics for a robot arm using Forth. I tried CORDIC for trig functions but concluded lookup tables are faster and EEPROM space is plentiful.

For my latest robot arm I built a serial relay on the microcontroller that lets the host PC send commands directly to each arm joint. The host PC can do the heavy lifting at that point.