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

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

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

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.

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.)

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

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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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.

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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

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

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?

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. )
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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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.

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.

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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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]

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