Hi. I am new to this forum. My background spans over 50 yrs in 8 bit microprocessor (and then microcontroller) system design and programming. Yes I am old and retired but I have never lost my boyhood love of computers and computing. The bulk of my formative years through the 70s was on Motorola 8 bit processors but maintained interest in the spin off product 6502. I had an AIM 65 kit which I transformed to a sailing club handicapping system (both race day and back office functionality). It was written in the on board Basic interpeter which required EPROM extension for the source. Also added an I/O board that provided start/stop control of the cassette recorder using transistor and relays.
NB As I speak a fully functioning 6800 MEKD2 kit sits on my workbench for interfacing to serial memory, SPL, prom programming, USB, Arduino serial data, dual processor arbitration. I mention this as all these can be implemented for 6502.
Most of my system software development is based on 6809. The 6800 / 6502 processor is limited in real time multi tasking OS and compiler development due to: single stack ptr, no stack based address mode, single index register. Never the less I have always argued that the 6800 & 6502 were never fully exhausted in their application before the following processors they spawned.
I look forward to helping where I can and learning from others.

Hi Mark,

Welcome on-board.

You may wish to check recent (ish) developments in C compilers - cc65, vbcc, Calypsi, llvm and who knows what else. Yes, the 6502 may not be "optimised" for C but that isn't stopping some of us using C on it to very good effect.

And the usual argument about index pointers, the 6502 having (Arguably) 128 of them in zero page...

As for multi-tasking OSs - there are a few there too. I wrote my own in BCPL although it runs on the '816 rather than the 6502. And real-time just means predictable not necessarily fast - that's achievable on the 6502 ... although why anyone would want to do that today when there are better alternatives is anyones guess, but I did a lot of work with them in the early 80's in an industrial control setting... So I know it's all possible. Just remember it's getting on for 50 years old now!

But you're right - plenty of life left in it and things to discover - just look at the latest Apple II, Commander X16, C64 games and so on...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Welcome.


I've done realtime multitasking on the 65c02, and even with PIC16's, but not with an OS.  (See http://wilsonminesco.com/multitask/ .)  Take a look at others' impressive 6502 multitasking OSs, including GUIs (particularly Jonathan Halliday's), at http://wilsonminesco.com/stacks/potpourri.html#Gek in the treatise on 6502 stacks (stacks plural, not just the page-1 hardware stack).  (The 6502 does have two index registers though.)  Take a look also at the 65816 which has nearly everything the 6809 has, plus a lot more.


So true; and I keep straining to widen the horizons of 6502 and 65816 assembly language, to make it more efficient, powerful, maintainable, etc., and to demonstrate what can be done with simpler hardware.  Further, even with the same architecture, power has increased dramatically with higher clock speeds, improved memory densities and prices, and maybe other supporting hardware as well.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks very much Gordon for tips and links. There is much for me to "get into" in 6502. After all (as you rightly say)..its only been about 50 years!
Cheers Mark (Australia)

I think it would be more accurate to say that the 6502 has two offset registers; for any use of these in indexing, the actual address value has to come from elsewhere and these registers simply add a small value to it.

And it's arguably fair to say that these offset registers are what enable the zero page to be considered "128 index registers." So long as you're reading 256 bytes or less, you can read through memory via an index faster than a 6800 can with its 16-bit index register (though admittedly the 6800 slows itself down for no good reason here by making you specify and add an 8-bit offset when you LDAA n,X). And, of course, copies are even faster yet because you don't need to save and reload an index register between bytes.

_________________
Curt J. Sampson - github.com/0cjs

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As assembly programmers we are always working around the limitations of the instruction set and its addressing modes. Depending on the application requirements (memory size, speed, re-usability and readability etc) some options are preferable to others and others are eliminated as unsuitable.
One (extreme?) option is to add virtual registers including accumulators, index registers, stack registers, 16bit ops etc. This allows the more basic processor (e.g. 6800) run under the instruction sets and address modes of a more capable processor (e.g. 6809). You write the assembler using pseudo ops to spit out 6800 binary from standard 6809 assembler source. Of course from a system point of view you would have to have a very special reason for not just using 6809 as the target processor!
I remember running low on available program ROM for a National 8 bit processor running an automated crane control system for hot steel cooling yards, under "C". Circumstances dictated some ugly software choices (hacks) to avoid a complete board upgrade! FYI the system ran flawlessly for many years. Just as well they were 50 ton bars at 600c! Given the interest I may continue this thread in its own category.

Well, when talking about arrays yes, the "index" is usually thought of as the offset (in elements, not machine words!) into an array. Note that even in this case on the 6502, the X is not necessarily holding an index as described above: for arrays of 2-byte values X will hold twice the index.

But when talking about index registers these are mostly thought of as registers that can hold a "complete" address pointing to anywhere in the address space (or current segment, on machines with segmented addressing). X and Y clearly cannot do that.

As I mentioned, the 6800 has the same "16 bit pointer plus 8 bit offset" system that the 6502 does, with the difference that the register and memory relationships are reversed: when you LDAA 3,X the 16-bit augend comes from the index register X instead of memory, and the 8-bit addend (called an "offset") 3 comes from memory (the byte immediately after the LDA opcode).


Sure, but consider that if you're going to talk about X as holding the "index," (which already has the "X is an offset in bytes, which is not the array index when the elements are something other than bytes" problem I described above), you're now running into indices being duplicated when your array is longer than 256 bytes. If you want to read an array of 512 bytes and send each value to an output port, and you're using the X register, you're going to be using the "index" 3 twice, referring to two different elements in that array.

_________________
Curt J. Sampson - github.com/0cjs

Not sure how extreme it might be considered but the Sweet16 VM was present in the Apple II ROMs from day 1. It was effectively a little 16-bit "RISC" system with 16 registers and enough opcodes to make it usable. Not much code was written in it though - I recall some Integer Basic additions though and I made use of it at one point as part of another VM I was writing - I wrote a "malloc" style memory allocator in it for which it was quite handy.

Most 6502 assemblers can recognise and assemble sw16 opcodes too.

A more modern version might be the Acheron 16-bit VM which is implemented as assembler macros rather than a sort of bytecode. See: https://github.com/AcheronVM/acheronvm

My BCPL system has a 32-bit bytecode VM to interpret/execute the code produced by the compiler.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/