BDD: Thanks for the clarification about BRL.
Garth: I enjoyed reading your treatise, you are a very skilled and thorough writer.

This is probably getting even more off-topic, but I've found that a separate data stack definitely makes life easier. My current, sub-optimal strategy is to use ZP for variables and indirection, main memory for one (or more) data stacks, and leave the processor stack alone.

A data stack works out great when the word size exceeds the accumulator width. And it's easy to set up parallel stacks for the low/high bytes and index into them with the same "stack pointer". (The X register works out good for this, since i think Y is needed for ZP indirection.)

I'm the guilty party who stated some time ago that the 65816 is "yucky" (more or less). What I intended to express was simply a preference for one processor architecture over another -- not to actively malign the 65816. I apologize for my semantic incontinence.

First, I will readily admit that while I have studied the 65816s general architecture, I have never programmed one in assembly. I have however done a lot of assembly language programming over the years (starting with the 6502) including 8, 16, and 32-bit processors. So I have developed an appreciation for the significance of the different design goals and tradeoffs that have gone into the various architectures out there in terms of their effect on system performance.

As has been pointed out, the 65816 had among its design goals the following:

• Backwards compatibility with the 6502 (itself designed for efficient I/O)
• Expanded address space
• 8-bit data path

The result was no doubt a significant improvement over the 6502. However, compare this with some of the design goals of the 68000:

• Clean slate design (no attempt at compatibility with anything)
• 16-bit data path (8-bit for the 68008)
• 32-bit internal architecture
• Architecture well suited for compiled languages

At least from the point of view of the constraints that were placed on the two designs, the 68000 had big advantages from the start.

Now if you ask me which processor is better suited to handling I/O, I've no doubt the 65816 is a better choice due to the lower interrupt latency. But if you were developing a System V Unix with 1980s C compiler technology, I suspect the 68000 would be the better choice. In fact, there were many manufacturers of 68000-based System V Unix machines during that era (Apollo, Callan, Sun), but I'm not aware of a single instance of one based on the 65816. Neither CPU had an MMU on-board and that had to be added with external logic in either case.

Also, it should be noted that the 68000 preceded the 65816 by 5 years (68000 was released in 1979, compared to 1984 for the 65816). I think someone else pointed out that the 68020 was released around the same time as the 65816, though it was a much more expensive CPU. Perhaps it would be more fair then to compare the 68010 to the 65816, as the former was released in 1982 and was not nearly as expensive as the 68020.

Also, you may point out that the fastest 65816 will run at least at 14 MHz. The fastest 68000 processors I know of were clocked up to 25 MHz which goes a long way towards making up for some of its other inefficiencies when compared to the 65816. Both the 68000 and the 68008 were available in DIP form as well. In the case of the former, a large DIP64 package, and in the case of the latter, a more reasonably-sized DIP48 package.

As you say, the 816 was designed for compatibility, and encouraged if not enabled by Apple's intent to use it, as eventually they did, in the IIGS. It must be worth noting that the 816 was much smaller and cheaper, and in a much cheaper package too. Motorola designed a much bigger, more expensive, more complex chip - which was indeed much more capable and eventually also higher performance. But the 68k did take some time to get traction, and the 68008 with an 8-bit bus had rather poor performance.

I'm not sure if there's any particular reason to compare these two micros and try to claim a winner. We all have favourites, and pretty much all micros have both advantages and disadvantages. On this forum, the 6502 compatibility of the 816 is a notable advantage.

That's a good point that should always be kept in mind.

This is a website devoted to the 65xx architecture, and that includes the 65C816. Whether in native or emulation mode, the '816 has 6502 DNA in its blood. That was a big influence on the 65C816's genesis, which means that direct comparisons to the MC68000 are of questionable value. Motorola started with a blank sheet of paper with the 68K and had a generous budget with which to support the MPU's development. Bill Mensch, on the other hand, had to maintain backward compatibility to the 65C02 when he designed the '816, and had a comparatively miniscule budget at his disposal.

As I've noted several times in the past, I participate in this site because of its narrow focus on the 65xx family. Hence I prefer to see content that is 65xx-focused and not diluted with PIC, Arduino, Raspberry PI, etc., content that isn't at least tangentially related to the 65xx family.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

We shouldn't be too strict about what discussions are allowed here: the forum is not terribly busy and has never looked to me to be losing the primary focus on 6502 topics. We'd lose more than we'd gain if we didn't allow ourselves latitude to discuss other CPU ideas and systems. I think we have more posts which are truly off-topic, and that helps us relate to one another, and is no bad thing. Both types of off-topic are in fact positives.

I've never started a thread on this forum about anything not directly 6502-related, although I have contributed to going off on tangents which are not always expressly 6502-related. I'd like to think that casual discussions of processors which were contemporary to the 6502 is within the scope of acceptable topics, but if there is a consensus otherwise then I'm happy to abstain.

It should go without saying that the primary reason I'm on this forum is because I'm a big fan of the 6502.

We can take detours here - we always have. Both Garth and BDD have done it, as have I and indeed most of us. I do suggest that new threads which are off-topic should have subjects with OT to help people skip them without visiting. I also suggest that new directions within a thread are better tackled as new threads. Once two or three related replies have been posted it's less satisfactory to branch off. For extra points, post a link to the new discussion in the old thread and one in the new thread back to the old discussion.

Discussion of the Motorola MPUs within the context of the 65xx family can interesting, as the 6502 itself has Motorola DNA (the 65C816 even more so). In this respect, comparison of the two families' instruction sets is worthwhile, especially in the fine art of synthesizing 68000 instructions on the 65C816. The 68K's BSR and TRAP instructions are particularly useful and I have written macros to synthesize both on the '816.

Where I think things get off-topic are fanboy arguments about why the XYZ processor is better than the ABC processor. As Ed has noted, there are strengths and weaknesses in all MPUs, and zealously promoting one's like for a particular MPU is generally non-productive.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

While I agree with your assessment that zealously promoting one CPU over another is non-productive, it was never my intent to do so. Instead, I expressed a personal preference for one CPU over another in passing in an earlier thread. From there a discussion ensued and I had hoped it would lead to a comparison of the strengths and weaknesses of two different CPUs from the same approximate era for different applications. I never intended to ruffle any feathers and I apologize if I ruffled yours. After all, most of us are here in our spare time for the purpose of the pleasure our hobby brings us.

The 816's similarity to the '02 should definitely be an attraction to anyone who's already experienced with the '02. For someone who is just getting started in microprocessors, I would be very hesitant to recommend the '816, for a few reasons, not all of which are technical. The '02 is always a good starting point, but not the only one. However, my experience says that for situations where you're always dealing with 16-bit quantities, the '816 is much easier to program than the '02.

I understand that the 68000 has a very nice programmer's model, but the '816 compares favorably with the 68000 in the Sieve of Eratosthenes benchmark and absolutely blows the 68000 away in interrupt performance, not just in number of cycles required but in time required. I have no doubt however that the 68K is more suitable for a C compiler. I do kind of wish the '816 did not have the constraints of having to be able to run 6502 code; but the fact that it is essentially a very extended '02 is what got me into it.


Yes, some discussion on matters that are not specifically about 65-family processors is fine, but should be limited to things we can learn from to apply to the 65's, or construction methods, I/O ICs, data-storage methods for home-made computers, etc.. Since this is somewhat of a community, showing concern for others' personal health or traumatic life experiences is definitely appropriate and welcome, even though it's not remotely 6502-related, like the topic "Age = Illness" at viewtopic.php?f=1&t=2076 .

Garth, moderator

_________________
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 must say I find everyone's comments very reasonable and agreeable.

No matter which CPU you favor, if you are programming it in assembly language you are one of an elite few. That's true whether you were writing 6502 assembly in the 1980s or AMD64 assembly today. However, it seems to me that since the late 1980s, with the shift towards RISC processors, assembly language has catered more and more towards compiler writers and less and less towards programmers. As a result, I find assembly programming in the older processors far more rewarding than anything made since the rise of RISCs.

Some processors, like the 680x0 (and the 300 MHz Coldfire processors derived from that architecture) have enjoyed the benefits of continued development and the application of the latest architectures to enhance their performance (caches, Harvard memory architecture, pipelining, superscalar, speculative branching, etc.). Much of this technology is detailed in exquisite detail in Hennessy and Patterson's excellent book, _Computer Architecture_. For the HDL programmers here, there is the opportunity (for those of you with the time and inclination) to try your hand at imagining what the 6502 could have been and then making it happen on an FPGA. I don't know if he was first, but BigEd made an impressive start in this direction with the 65Org16 and I'm sure there is other good work out there as well.

I guess further discussion on this tangent should probably go in the Programmable Logic section so I'll stop now.

Thanks for the mention! (I was by no means the first to make a variant 6502, and even less was I the first to think about such a thing, but I might have been the first to make a minimally-different 6502 on FPGA: I aimed to make the fewest possible changes to an existing core, to have a chance of actually finishing. As a tactic, it worked! It was useful to have started with Arlet's 6502 core, which was already the smallest.)

Because the ARM was invented by 6502 experts, it has quite a 6502-ish feel to it, even though it has a big flat memory model and a fair-sized register set - it's a good C target. Also it has, like the 6809, a fast interrupt which swaps fewer registers and is therefore quicker than it might be. (Unlike most 8-bit micros, but arguably a little like the Z80, the ARM maps in some spare registers for interrupts, which means interrupts may often not do any save/restore. But they can if they need to.)

There are some bare-metal ARM projects on github, and my own effort at a 6502 emulator in ARM assembly.

Which is to say, if you like computer architecture but have a fondness for 6502, the ARM is as good a direction to go in as any. I noticed recently a breadboardable 28-pin DIP ARM with a builtin serial bootloader.

It's interesting to compare the original ARM interrupt handling to the newer Cortex. On the original ARM, no registers were pushed on the stack, but instead the original PC and PSW were copied to banked registers. For the fast interrupt, also a few general purpose registers were banked so you could use them right away without corrupting anything. This was really fast, but it didn't allow interrupt nesting, and it required the user to push their own registers for regular interrupts, as well as perform interrupt decoding in software.

On the Cortex, there are no shadow registers. Instead, the current state (including 4 general purpose registers) are pushed on the stack. At the same time, the interrupt is decoded, the vector is fetched, and the new PC set to the start of the proper interrupt handler (bigger chips allow 100+ different interrupt vectors and priorities). The Cortex method allows interrupt nesting, and because all the caller-saved registers are already pushed on the stack, it allows the interrupt handler to be written as a standard C/C++ function. Because the vector dispatch happens at the same time as the register push, it is quite efficient. It requires a few more cycles than on the 6502, but in return you get hardware interrupt vectors, and you can already use 4 registers right away. In most cases, that will save cycles in the end.

Interesting! ARM has evolved quite a bit, and in several different directions, since the original. Optimising useful memory bandwidth was a key element at the invention of ARM, whereas the Cortex line is all about saving power and using less silicon. Even Cortex spans quite a range of different instruction set subsets. (We shouldn't forget, either, that comparing cycle counts doesn't always make sense when the frequencies are very different.)
I found this PDF on Cortex.

Overall the Cortex is a fine architecture, but if you prefer programming in assembler, I'd recommend an older ARM7. The instruction used to be much more simple and regular. An experienced 6502 assembly programmer can probably pick up ARM assembly in a few days.

The modern Cortex has traded simplicity and regularity for performance, and it's best programmed in a higher language, except in very rare cases.