Not much love for the poor 65816?

[drogon]

tokafondo wrote:

Well, you are right about all you say. ARM is just better, faster, and the manufacturers are embedding more and more things in the chips themselves.

Just for the record, I don't think it's always better, but it is cheaper and these days it really is a race to the bottom - hence the 1 cent microcontroller (See Dave EEE, Big Clive, etc. on youtube and other social media platforms talk about them).

One issue I have is the sheer complexity of these SoC devices - there is just too much on them, you need thousands of lines of code just to boot them, so more hardware to go wrong, more code to go wrong, yes this is deemed acceptable to many. The old (Unix) philosophy of "do one thing well" has gone out the window. Want to pilot a space craft? Use write a GUI in Python and run it on Linux and use a touchscreen.What could possibly go wrong...

-Gordon

[GARTHWILSON]

drogon wrote:

hence the 1-cent microcontroller

I can't see the point in that, since it costs us more than that for the assembly house to place it on the board.  It's kind of like in another great interest of mine, road bicycles, and people always thinking that the frame has to get lighter and lighter, when in reality the frame makes up less than 15% of the weight of a high-end bike, meaning that even if you could totally eliminate the weight of the frame (ie, make it weightless), it would not have a very great impact on the overall weight of the bike, let alone of the bike-and-rider combination.  Also, light weight is not at the top of the list of things that make a bike good.  I certainly agree with the rest of your post though.

[BigEd]

GARTHWILSON wrote:

Cheap 32-bit microcontrollers are not pushing out 8-bit ones though. See
11 Myths About 8-Bit Microcontrollers.

Thanks for the link Garth - an interesting article. So by value, as of 2015, the market for 8 bit and 32 bit microcontrollers was about even, and perhaps that means about 3x the volume for the 8 bit ones.

I have to agree that system cost is what's going to count: the cost of the microcontroller, and any interfacing, and of writing the code, and of testing the code.

To get back to an earlier point, it may be that the '265 is a good way to get an '816, but it still might be that in the field of microcontrollers generally, the '265 isn't a great bet. It will depend somewhat on WDC's pricing for volume, their support, and the arrangements for a custom ROM. It used to be said that the toy market was the big market for 6502 family, and it still might be so. It might be that in that market, a relatively small mask ROM is a good solution, compared to flash. Or indeed, more generally, it might be that WDC know that market well and the '265 has a very good mix of features for that market.

[tokafondo]

BigEd wrote:

To get back to an earlier point, it may be that the '265 is a good way to get an '816, but it still might be that in the field of microcontrollers generally, the '265 isn't a great bet. It will depend somewhat on WDC's pricing for volume, their support, and the arrangements for a custom ROM. It used to be said that the toy market was the big market for 6502 family, and it still might be so. It might be that in that market, a relatively small mask ROM is a good solution, compared to flash. Or indeed, more generally, it might be that WDC know that market well and the '265 has a very good mix of features for that market.

I think the perfect format for the '265 would be one like this one:



This is a Rockwell 6500/1EB chip. It's a complete computer in a chip, like the '265 is. But instead of a masked ROM, you have a socket that is wired to the address and data bus lines of the internal 65xx core, leaving the rest of the chip pins as "ports" and things like the clock, reset, power, NMI and others.

So you can write your code, burn it in an eeprom and plug it in the chip, that will run it as a ROM and its internal RAM. That way you can test your code, build prototypes and be sure that your design will be ready for mass production runs, using masked ROM. OR Use it like this in the productions runs, to be sure that the code could be fixed or updated later.

But again: the 65xx family are for me chips meant for MCUs, not computers. Yes, the '816 do have several optimizations as you experts say to be faster, but the way the memory is managed talks about the not need of having large chunks of code or data directly or linearly addressable like a computers CPU would need. Most of the programmers say that it's hard to get large amounts of code filling the memory so those 64K banks do perfectly fit the purpose of it.

[BigEd]

We don't seem to have mentioned Acorn's Communicator product in this thread: it was a 65816 based all-in-keyboard computer, with code and data freely placed over some 512k of RAM. It had some idea of multiple applications running, and shared libraries, and it allowed multiple invocations of an application, although I don't know if it shared the code in that case. (Having said all this, the Basic might have been limited to 64k of data.)

Two relevant threads on stardot: one, two.

(Unlike Apple's IIgs, the Communicator didn't have any backward compatibility concerns. But it too didn't push for any speed records: it ran at 2MHz.)

[BigDumbDinosaur]

This topic seems to be going in circles (along with some occasional OT commentary), as the same tired, old tropes are being repeated about the 65C816.  For instance, everyone and his pet monkey seem to be obsessed with banks and what a bad thing they are.  If you understand the following, you and the MPU’s banks will get along just fine.

1. Hardware vectors.  Absent suitable decoding hardware, the 65C816’s hardware vectors are seen only in bank $00, with native-mode vectors in the $00FFE0-$00FFEF range—emulation-mode vectors are in the $00FFF0-$00FFFF range, same as the 65C02.  This characteristic is a byproduct of the need to maintain (mostly) backward compatibility with the 65C02, and implies that ROM or something that appears to be ROM must be present at the top of bank $00 address space.
2. Program code.  If the program counter (PC) wraps, the program bank register (PB) will not increment.  Therefore, program execution is inherently confined to the bank defined in PB.  This simply means that relative branches, 16-bit jumps and 16-bit subroutine calls cannot cross bank boundaries.
   
   In practice, this limitation is very rarely an issue, as 65C816 code, like its 65C02 counterpart, can be quite compact if written by a skilled programmer.  If necessary, really large programs can be built in segments, loaded into several contiguous banks and long jumps (JML) and/or long subroutine calls (JSL, with RTL to return) used to handle cross-bank execution.
3. Absolute-indirect jumps.  An absolute indirect jump, e.g., JMP ($1234), “bounces” off a vector located in bank $00, regardless of the bank in which the instruction itself is being executed.  This characteristic also applies to an absolute indirect-long jump, e.g., JMP [$1234], which is the 24-bit equivalent of JMP ($1234).  In the context of native-mode execution, an absolute indirect jump tends to be less useful than an absolute-indexed indirect jump (discussed next) and is probably best suited for fixed system indirect vectors, such as those of an interrupt handler or operating system API.
   
   On the other hand, an absolute-indexed indirect jump, e.g., JMP ($1234,X), uses a vector table located in the same bank in which the instruction is executing, which makes this type of “computed jump” generally more useful in most applications.  The similar absolute-indexed indirect subroutine call instruction, e.g., JSR ($1234,X), which is unique to the 65C816, also refers to a vector table in the execution bank.  A JSR ($1234,X) instruction may be thought of as the equivalent of BASIC’s ON - GOSUB instruction.
   
   On a tangential note, the general nature of the 816’s native-mode behavior favors the use of software interrupts for calling operating system API services.  Accessing an API via a subroutine jump table may become unwieldy if there are many API entry points and the calling program is not in the same bank as the operating system kernel.  Also, if your 65C816 system implements memory protection, a direct access to kernel address space with JSR or JSL will likely run afoul of the protection hardware.  In my POC unit, I rewrote the BIOS API to use COP for calling services, resulting in more succinctness in applications, as well as no need to create a jump table that cannot be relocated without having to reassemble every program that makes API calls.
4. Stack.  Instructions that fetch from or store to the hardware stack are implicitly directed to bank $00.  Such instructions are register pushes and pulls (including the pushes and pulls associated with subroutine calls and interrupt processing), pushes caused by the PEA, PEI and PER instructions, and use of the stack-relative addressing mode, e.g., LDA $01,S or ORA $0A,S.
   
   Use of the stack-relative, indirect-indexed addressing mode, e.g., LDA ($01,S),Y or ORA ($0A,S),Y, causes the 65C816 to behave as though (<dp>),Y addressing is being used, although the 16-bit base address is on the stack at SP+<offset>.  The resulting fetch or store will occur in the bank defined in DB.
   
   As the 65C816’s native-mode stack pointer (SP) is a 16-bit register, it is a true pointer, unlike the 65C02’s stack pointer, which is an index.  Hence the 816’s native-mode stack may be defined at any convenient location in bank $00, and of a size limited only by other demands for bank $00 address space.
5. Direct page.  All direct page (aka page zero or zero page) accesses are directed to bank $00.  As the 816’s direct page (DP) register is a true pointer, direct page may be located anywhere in bank $00.  In fact, DP may be pointed to a reserved area on the stack, one of the 65C816’s most useful capabilities, as it allows subroutines to be given temporary zero-page space for local use, as well as facilitating stack content access by using direct-page addressing, including indirect and indirect long modes—in other words, treating stack content as pointers.  Note that if DP is not page-aligned, a one-cycle penalty will apply to each direct page access.
   
   Unlike the 65C02’s zero-page addressing, which is always confined to the range $00-$FF, the 65C816 can “touch” anywhere in bank $00 using zero-page addressing, i.e., zero-page addressing can span page boundaries, especially if using 16-bit indexing.  For example, if DP contains $00, all registers are set to 16-bits and the .X register is loaded with $8000, the instruction LDA $00,X will fetch from $008000 (LSB) and $008001 (MSB).  On the other hand, if the .X register is loaded with $FFFF, the instruction LDA $00,X will fetch from $00FFFF (LSB) and $000000 (MSB)—direct-page addressing is confined to bank $00 in all cases.
   
   As each running program may well have its own idea as to where direct page is located, your interrupt handlers should be careful to preserve DP and not make any assumptions about DP’s content.
6. Data fetch/store.  Data fetches and stores may be “bank-aware” or “bank-agnostic.”  Bank-aware fetches and stores use one of the 16-bit or 24-bit absolute addressing modes, or some form of 16-bit indirect addressing.  Bank-agnostic fetches and stores use 24-bit zero-page, indirect addressing.  Both methods have their place in most programs, but bank-agnostic is generally most useful in globally-accessed, subroutine libraries, and in accessing large data blocks that span multiple banks.  On the other hand, 16-bit, bank-aware addressing will be faster executing than other methods.
   
   1. If the fetch/store instruction’s operand is a 16-bit value (absolute addressing), the access will occur in the bank defined in the data bank register (DB)—DB sets bits 16-23 of the effective address.  Unlike direct page addressing, an absolute-addressing instruction can reach into the next bank.  For example, if DB contains $12, the accumulator is set to 16 bits and the instruction is LDA $FFFF, the fetch will occur from $12FFFF (LSB) and $130000 (MSB).  This also works with indexed addressing, especially 16-bit indexing, which allows data structures to span from a program’s execution bank into the next bank, without having to resort to use of 24-bit addressing.
      
      In order to assure that a program originally meant to run on the 65C02 will run on the 65C816 in native mode with as few alterations as possible (assuming the program doesn’t use the unsupported Rockwell extensions), a PHK - PLB instruction sequence should be executed at program startup, generally right after SP has been initialized to top-of-stack.  Doing so will cause the 816 to fetch and store in the execution bank, producing the same fetch-and-store behavior of the 65C02.  Your interrupt handlers should be careful to preserve DB and not make any assumptions about DB’s content.
   2. If the fetch/store instruction’s operand is a 24-bit value (absolute long addressing), DB is ignored, as the target bank is specified in the address operand.  As with 16-bit addressing, 24-bit addressing can span into the next bank, either due to use of a 16-bit access at a bank boundary, e.g., LDA $01FFFF when .A is set to 16 bits—the MSB will come from $020000, or by indexing into the next bank using the X-register.
      
      In practice, I have found absolute-long addressing to be of limited value.  Using it effectively hard-codes extended RAM usage (“extended” meaning RAM beyond $00FFFF) into, at most, two contiguous banks, making accesses to very large blocks of data inefficient.
   3. If the fetch/store instruction uses any of the zero-page, indirect addressing modes with a 16-bit pointer (referred to as a “near” pointer), the access will occur in the bank defined in DB.  This rule encompasses the (<dp>), (<dp>,X) and (<dp>),Y addressing modes, where <dp> is the direct-page address of the near pointer.  Due to the 816’s page-boundary spanning characteristic, it is possible for a pointer’s address to straddle the boundary between pages $00 and $01.  In other words, LDA ($FF) or LDA ($FF),Y is perfectly acceptable, and the 816 will get the target address from $0000FF and $000100.  This behavior also applies to (<dp>,X) addressing, with a twist!  If a pointer array starts at $F0, the index registers are set to eight bits, and the .X register is loaded with $12, LDA ($F0,X) would cause the MPU to get the target address from $000102 and $000103.
      
      As previously described at 4) above, stack-relative, indirect-indexed addressing, e.g., LDA ($01,S),Y, behaves exactly like zero-page, indirect-indexed addressing with a “near” pointer—the content in DB will determine the bank that will be accessed.
   4. If the fetch/store instruction uses zero-page, indirect addressing with a 24-bit pointer (referred to as a “far” pointer), DB is ignored, as the target bank is specified by the pointer.  A “far” pointer is arranged as LSB,MSB,BNK in little-endian fashion.  LSB,MSB is the same as with 16-bit zero-page, indirect addressing, while BNK is the target bank.  For example, LDA [$12] or LDA [$12],Y expects LSB,MSB,BNK to be located at $12,$13,$14, respectively.
      
      As a “far” pointer is readily manipulated during program execution, indirect long addressing is bank-agnostic, giving a program the ability to treat the 816’s address space as a linear array of bytes or words, using surprisingly-succinct code.  Indirect “far” is perhaps the 65C816’s most powerful addressing mode, due to the flexibility it affords and the ease at which access to the entire address space may be achieved.  I use indirect “far” extensively in my projects.
      
      Further to indirect-long addressing, I have learned that in writing efficient 65C816 code, “far” pointers are better handled as 32-bit (long word) quantities, even though the MPU treats them as 24-bit (extended word) pointers.  Programs so written ultimately tend to be more compact and somewhat faster because the accumulator can be set “wide” (16 bits) and left that way as sequences of pointer arithmetic are executed.  With extended-word pointers, it is necessary to repeatedly use REP and SEP instructions to switch the accumulator size to handle the LSW or MSB being processed, at a cost of two bytes and three Ø2 cycles per REP or SEP.  Furthermore, the constant need to switch the accumulator’s size may open the door to bugs if you manage to lose sight of the overall execution picture as you craft your code—been there, done that—the resulting crashes can be quite exciting. 
7. Block-copy instructions.  Both MVN and MVP instructions can copy data within a bank or between banks at high speed—seven clock cycles per byte copied, producing a theoretical throughput of 2 MB/second at 14 MHz, assuming no interrupts or hardware wait-states.   MVN and MVP take a source and destination bank as operands, which operands are determined at assembly-time, essentially forcing the use of self-modifying code in general-purpose functions that use these instructions.
   
   DB is changed by these instructions to point to the destination bank.  Hence it is customary to surround a block-copy instruction with PHB and PLB to preserve DB.

Having written tens of thousands lines of 65C816 code, I will emphasize that manipulation of the bank registers by a running application is uncommon.  In the case of PB, there is no means by which it can be directly changed—PHK (push PB) has no pull counterpart.  In practice, DB hardly ever gets touched as well, which is fortunate, since doing so tends to be awkward—it can only be accessed through the stack.  During initialization, my applications will execute a PHK - PLB sequence to set the data bank to the program bank so data that is loaded along with the program, e.g., text strings, data tables, etc., may be conveniently accessed using “near” addressing.  That is usually the only time an application explicitly loads DB with a run-time value.

In summary, while existing 65C02 algorithms can be made to run on the 65C816 (in either operating mode), doing so results in under-utilization of the 816’s capabilities.  The key to developing for the 816 is understanding that its native-mode “personality” is significantly different than that of its eight-bit cousin.  This difference means that writing code to best utilize the 816 requires a different sort of thinking, especially with regard to direct page and stack utilization.  Once you come to that realization you will be amazed at how easy it can be to write programs that do things that are difficult-to-impossible to accomplish with the 65C02.

————————————————————
I’ve updated this post to fix typos and make it more readable.

[barrym95838]

BDD, your depth of knowledge and understanding are admirable, as is your patient willingness to thoroughly and eloquently explain your point of view. In the end, though, you'll likely find it to be an uphill battle if your goal is to convince many (or any) of us VW bug drivers to switch to the VW bus, metaphorically speaking.

[Dr Jefyll]

BigDumbDinosaur wrote:

thus programming it demands a totally different approach.

Please reconsider your wording, BDD. Certainly the '816 allows a different approach, but it's outlandish to say a different approach is demanded. You're overlooking the fact that folks can enter at the shallow end of the pool, so to speak, where the climate is very 6502-ish indeed.

Quote:

you will be amazed by what you can accomplish.

Agree on this point. But now you're talking about the deep end of the pool, where progressively advanced users may eventually choose to swim. Or not.

My point is that curious 65xx-ophiles are allowed to enter at the shallow, 6502-ish end, and engage with new capabilities one by one and almost entirely at their leisure. It's NOT an "all or nothing" leap. Nothing forces you to relocate "zero page" or to switch to 16-bit registers (to name just two of many examples). The environment is a lot more welcoming and flexible than many may suppose.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

thus programming it demands a totally different approach.

Please reconsider your wording, BDD. Certainly the '816 allows a different approach, but it's outlandish to say a different approach is demanded. You're overlooking the fact that folks can enter at the shallow end of the pool, so to speak, where the climate is very 6502-ish indeed.

Your post made me realized I didn't complete that sentence as I intended (my steadily worsening vision is making it difficult for me at times to see errors and omissions). I edited my post.

[BigDumbDinosaur]

barrym95838 wrote:

BDD, your depth of knowledge and understanding are admirable, as is your patient willingness to thoroughly and eloquently explain your point of view. In the end, though, you'll likely find it to be an uphill battle if your goal is to convince many (or any) of us VW bug drivers to switch to the VW bus, metaphorically speaking.

VW bus? If the 65C02 is a VW then the 65C816 is a Porsche.

[tokafondo]

Thanks for such a long and detailed explanation.

What about the hardware part of this? In its original form, having the chip work at its full data and address buses handling capabilities require the use of an external 'chipset'.

If you want to design a SBC that would act as a microcontroller, like many people do, having the chip short of external circuitry woukd be enough. But if you want to design a full 'user friendly' computer with sound and graphics and such fancy things, then you would have to look for vintage chips, go the FPGA way, look for chips that would work with the 816 as it is or again, design a chipset to handle the full 24 bit address bus and a 16 bit bus that isn't designed but can be implemented.

Can any of this affect the popularity of the 816?

[Dr Jefyll]

tokafondo wrote:

What about the hardware part of this?

Usually the hardware varies from pretty darn simple to mildly challenging. But you mentioned an un-usual goal, and I'll briefly deal with that before addressing commonplace scenarios.

A 16-bit data bus is an unusual goal, and in this post I show how a couple of latches and tristate buffers can implement that, for purposes such as connecting to that S1D13506 chip of yours. And your thread here deals with much the same subject. Sadly, 16-bit transfers don't double the speed of everything. That's because the '816 itself can only move one byte at a time over its 8-bit bus. But there is a significant speedup from having less code to execute. Specifically, there are fewer instruction bytes to fetch when only a single, 16-bit transfer is coded, as compared to coding two 8-bit transfers.

Moving to a more commonplace setting, most of us have seen the simple recipe below, taken from the '816 datasheet. (BTW I think the weird little diamond symbol merely denotes that that part of the bus is bi-directional. )

5-1.png (7.73 KiB) Viewed 3759 times

This is not a complicated circuit, nor does it involve a lot of chips. And it'll "play nice" with the rest of the system. Data Bus D0-D7 is very happy go lucky (ie, undriven 50% of the time, and thus extremely tolerant in regard to contention issues), and the '573 makes all the Bank Address bits available just as if the '816 had had 8 extra pins added. IMO this simple circuit results in a setup that's just as friendly as a 6502 or 'C02. Highly recommended. Just follow the recipe!

It's possible to deviate from the recipe and get an even simpler setup. The '573 can be omitted if you only want 64K and thus have no use for the Bank Address bits. And some forumites report success with bypassing (ie, omitting) the '245... which means memory and peripherals will "see" the BA bits on their data pins during Phi2-low (instead of the bus floating at this time). I'm not surprised by those folks' success but IMO bypassing the '245 may lead to trouble for beginners, whom I encourage to stick with the recipe.

-- Jeff

[tokafondo]

Thanks for your explanations.

I brought the data and address buses subject because of this: it seems that for most applications and I said it before, the 6502 is more than enough. As I've understood from what experts say, having a 16 bit bus addressing 64K of RAM and a byte of data covers a lot if what's expected to do with the 65xx architecture. The hardware examples I've seen are mostly around a 6502, going the '816 as a proof of concept instead of a real necessity.

Who actually need the 24 and 16 bit stuff in a design? Almost no one it seems to me. People that want a 65xx machine communicating with the rest of the world tend to map the chips i/o into first 64k of RAM and having a serial chip there, interfacing with SPI or whatever else through it.

"Filling 64k or even 8k just with code is not that easy", I've read. And for the data, just having the minimum needed and reading the rest from storage or another source is also the trend.

What I'm trying to say is that maybe there is no real advantage in using the '816 over the 6502. Yes, software wise there are improvements but those are not that useful in real world cases.

Another different thing is if the '816 would have had a physical implementation and hardware improvements that would had made a difference.

[Dr Jefyll]

tokafondo wrote:

if the '816 would have had a physical implementation and hardware improvements that would had made a difference.

I and many others agree. It'd be better if the chip simply had 8 extra pins for the Bank Address. Then the "recipe" -- the '573 and '245 -- would be unnecessary.

Quote:

maybe there is no real advantage in using the '816 over the 6502.

Agree again -- there indeed may be no advantage. But it will depend on each individual use case. In some situations (especially for hobbyists) the 816's extra capabilities may be highly valued for the open ceiling on one's learning experience and for the kick in the pants regarding performance. In contrast, someone more oriented toward a specific application (solving one specific problem) may prefer a 65C02 if that's all the situation requires. And there's absolutely nothing wrong with that.

(Indeed the 65C02 offers a few obscure features not shared by the '816, and there's a certain small proportion of users who spin these features to their advantage. I'm referring to the 32 instructions for bit manipulation, the /SO input pin, and the undefined opcodes.)

-- Jeff

[tokafondo]

Dr Jefyll wrote:

I and many others agree. It'd be better if the chip simply had 8 extra pins for the Bank Address.

Well, the '265 does have them. I'm not sure what's the real difference software wise between a real '816 and a '265, though.

Quote:

In some situations (especially for hobbyists) the 816's extra capabilities may be highly valued for the open ceiling on one's learning experience and for the kick in the pants regarding performance.

Having a 16 bit data path would be highly valued for sure.