I found this in the December 1984 issue of Byte Magazine, part of a large interview with Steve Wozniak:


Maybe this was at the stage where the timing issue affected the disk interface and Woz was aware of this. Interesting though that Apple very strongly wanted backward compatibility. The Macintosh was originally going to use the 6809, it would have been interesting if they had of considered the 65816 at the time.

This is probably overstating the speed difference a bit, but it's interesting to speculate on this. The Macintosh had 512x342 mono graphics, and 128k RAM. When the IIgs came out it had 640x200 color graphics and a lot more RAM, 256k to start, but expandable to over a megabyte. It's speed was somewhat artificially limited to 2.8 MHz and it still managed to run Macintosh like software at reasonable speeds. I've got an emulator that has an option to run at 8 MHz, at that speed the graphics performance is really quite good. The biggest difference was that the 68000 had a much better growth path for the future, but it's interesting to speculate if the 65816 came out a little sooner what would have happened.

One thing that has always put off people about the 65816 is the banked architecture. I found this in the Apple /// Business Basic source code:



32-bit registers and no need for banking is definitely appealing to a programmer, but on the other hand the 65816 was a very efficient processor. I've been doing a lot of thinking about how best to organise a 65816 system and I guess the learning curve was quite high, but now I think that it's quite a nice system to program. In the x86 world they had more 'nastiness' to deal with and that worked out fine.

That has been hashed out several times around here. It's old news.


I'm not aware of a general dislike of the '816 due to its banked architecture. It's actually a minor matter in the scheme of things, as the '816 has a flat address space when dealing with data. The bank boundaries affect the following items:

• Programs. A program cannot exceed 64KB because when PC wraps PB will not increment. In practice, this is not much of a limitation because 65xx programs that approach that size are rare.
  
  
• Direct page. Direct page accesses are hard-wired to bank $00. That is generally not an issue if careful memory management practices are observed by the operating environment.
  
  
• Stack. Stack accesses are hard-wired to bank $00. Again, that is not going to be an issue of the operating environment observes good memory management.
  
  
• Hardware vectors. Any interrupt will cause the '816 to load PB with $00 after PB, PC and SR have been pushed. Hence the front ends of interrupt service routines (ISR) must be in bank $00, although the bulk of the ISRs can be in another bank if the front ends do a long jump.

The above rules are simple to follow, so there is no particular reason to avoid the 65C816.

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

I do like the poem.

It's an interesting (and unanswerable) question, whether the warts of the 8088 make it more or less of a wrestling match than the warts of the 65816.

We do know that the 68000 was late, and slow, compared to initial expectations. We also know that Motorola, for a couple of years, held it away from small micro systems and targeted it at the mini-sized market. And we know that it was out of the running for IBM's PC project because Motorola had no second-source licensees.

Samuel Falvo, professional programmer, kc5tja here on the forum (but rarely checks in), used to say that the thing is to make the banking work for you rather than against you. The banking does make things more efficient (faster and more compact) as you said quoted below, since most addressing only needs two bytes that way, not three (and of course direct page, which can be moved around in bank 0, only needs single-byte addressing). The 816's bank system also allows a program to reside in any bank rather than being limited to a specific address.



I had heard many years ago that it was because it didn't have a built-in MMU; but I never verified. The Wikipedia article names six companies that second-sourced the 68000, but it doesn't give the dates (meaning the second-sourcing could have come too late for IBM's PC project).

I would say programs can span many banks—it's just that you need a JML or JSL to get from one bank to another, rather that seamlessly going through the XX:FFFF to XX+1:0000 boundary. 64K is a lot for one person to fill with a program though, especially since it doesn't have to share that space with data, since the data can go in one or more other banks.

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

That's a thought - most applications, IMHO, would be single tasks with modest code, so the multi-bank capability is all about large datasets. I think the 816 should do well here.

The next most common case, I'd think, is multi tasking with an OS. I would think the '816 is a bit less comfortable here, although clearly it can do the job.

Indirect long addressing is the key. With it, a program can touch the entire address space through a single 24 bit direct page pointer.


The kernel itself could be run from any bank, other than the front ends to the interrupt handlers, which must be in bank $00. I don't envision that as much of a problem.

The kernel's data structures (buffers, hashes, etc.) can also be stored anywhere, although it would help performance to have the most frequently used structures in the same bank as the kernel itself. Doing so would allow the use of 16 bit addresses vs. 24 bit addresses for accessing structures outside of the kernel's bank, saving a clock cycle per memory access.

The ability of the '816 to relocate direct page would be advantageous, since functions could have ephemeral direct pages that are actually located on reserved stack space.

The trickiness will come in keeping one process from stepping on another process' space.

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