I happened to be poking around the 'net looking up info about an old friend, the 6502. I have read most of the 6502-related stuff and find it interesting that, depending on your age, everyone has a different perspective on this.

I got involved in the Apple II in HS (1978). I didn't touch assembler programming until I got in college. I wrote my own assembler for the 6502-chip by writing a full-screen editor (with move subroutines in native machine code - page x'0300') for speed. Then I wrote a BASIC program that would assemble (produce object code).

Eventually, after I got the bugs worked out (it took about 5 compiles with each running about 1/2 hour - slow disk times) and then used this assembler (assembled with the BASIC assembler) as my new assembler. Once you get a limited-function assembler, you can then grow your functionality. Kind of incestuous but still pretty neat.

After writing this, I moved some important storage to zero page and what a HUGE difference the 2 machine cyles per access made! Being a Wozniak-phile, I brutalized the code so it was as fast as could be made. It taught me a lot about bit manipulation (which is the final step in becoming a very good assembler coder).

Eventually, I used the RWTS Apple II subroutine to write my own disk directory search and disk read routines (to read a standard ASCII file without the DOS services.

I LOVED the 6502 design; the addressing modes, the accumulator, carry flags, SED, etc. Interestingly, if you ever get a chance to view Wozniak's original monitor, there is a routine called NXTA2 that cryptically sets multiple condition codes while incrementing a 2-byte pointer. What a tour-de-force. Or check out his BASCALC routine for driving the video storage base addresses.

Thanks for listening to this rambling.

Jim Lewandowski

I first poked around inside of a VIC-20 (using a typed-in BASIC ML monitor) and learned about how microprocessors worked. It was awesome. Then I kept playing around until I created a LOT more software, using a couple different assemblers that ran the C-64/128.

Years later, when I took my first C programming course, the instructor got up to explain how pointers worked. I followed right along, understanding every point perfectly, because I already knew what indirect addressing was all about. I had been using "pointers" for years and didn't even know what they were! Some other students got a dumbfounded look on their face and spent a lot of time trying to unravel the "mysteries" of pointers in C. Play around with a 6502 for a while, and it's obvious! (heheh)

- Ted D.

I first poked around inside of a VIC-20 (using a typed-in BASIC ML monitor) and learned about how microprocessors worked. It was awesome. Then I kept playing around until I created a LOT more software, using a couple different assemblers that ran the C-64/128.

Years later, when I took my first C programming course, the instructor got up to explain how pointers worked. I followed right along, understanding every point perfectly, because I already knew what indirect addressing was all about. I had been using "pointers" for years and didn't even know what they were! Some other students got a dumbfounded look on their face and spent a lot of time trying to unravel the "mysteries" of pointers in C. Play around with a 6502 for a while, and it's obvious! (heheh)

- Ted D.

I regularly program both 65C02 applications and PICs as well in my work. Microchip claims their PIC microcontrollers are so screaming fast and efficient. But in my experience of developing several products, I have to say that the nice things about the PICs are that they have a nice set of I/O options, good on-board uP support, free macro assembler and simulator, the PICs are available in a lot of versions from many different stocking distributors, and they can easily be programmed at the workbench.

However, I can also tell you from experience that the processor core in a PIC microcontroller is miserably primitive compared to the 65c02. Even though both are available in 20MHz, the PIC will generally take twice as many cycles to do a job, and it's only suitable for very small jobs.

If you have an iterrupt where W (the working register, like 65c02's accumulator) and status register must be saved, you're looking at 30 clocks to do what the 65c02 does in 11.

Implementing look-up tables with the PIC are mickey-mouse at best, and if you end up having to cross page boundaries, a simple indexed look-up that takes one instruction and 4 or 5 clocks on the 65c02 may take 9 instructions and a subroutine level in the return stack on the PIC, and a very long 48 clocks!

PICs' lack of stack access and shallow stack depth are very limiting. Page- and bank-switching time waste memory and execution time, and make the code more unreadable. Some basic operations, like rotating, cannot be done in PICs' working register. If you want to test a processor status flag and conditionally branch, the 65c02 will use one instruction and 2-3 clocks, while the PIC takes two instructions and 8-12 clocks (2 or 3 "cycles", at 4 clocks per cycle).

I could make a dissertation out of this (with plenty of proofs), but my point is that the 65c02 is not some obsolete thing that should have been thrown away years ago. It has a very high power-to-complexity ratio, and Microchip would do well to scrap their decrepid RISC core and replace it with a 65c02 core for their microcontrollers. As we all know however, what's sensible is not what drives a market.

Garth Wilson

_________________
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?

I haven't worked with the PIC, but I do know how popular it is, because of all the things you've just listed.

I think it is sad that there isn't a 65xx alternative to it, because from an architecture point of view, the 65xx still has a lot to offer.

- Ted