Not much love for the poor 65816?

[litwr]

IMHO Bill Mensch quite clearly stated why he refused to make the ARM - the ARM could run good OS. IMHO the 65816 was made a bit awkwardly to prevent using good OS with it. I have written about this in https://litwr.livejournal.com/2509.html

Quote:

one of the main developers of the 6502, Bill Mensch, was the first who was given an opportunity to make the ARM electronics. But, he immediately realized that the ARM was a competitor to the best developments of large companies and decided not to get involved, perhaps fearing that otherwise his company WDC would face the fate of MOS Technology.

[BigDumbDinosaur]

litwr wrote:

IMHO Bill Mensch quite clearly stated why he refused to make the ARM - the ARM could run good OS. IMHO the 65816 was made a bit awkwardly to prevent using good OS with it. I have written about this in https://litwr.livejournal.com/2509.html

Quote:

one of the main developers of the 6502, Bill Mensch, was the first who was given an opportunity to make the ARM electronics. But, he immediately realized that the ARM was a competitor to the best developments of large companies and decided not to get involved, perhaps fearing that otherwise his company WDC would face the fate of MOS Technology.

Just because you wrote it doesn't make it fact. Can you cite an unimpeachable source for Bill Mensch's "quite clear" statement?

[cjs]

BigDumbDinosaur wrote:

Can you cite an unimpeachable source for Bill Mensch's "quite clear" statement?

Or any source whatsoever, for that matter? The whole article seems full of not-so-plausible stuff and there are no references for any of it. That does kind of give the impression that much of this may just be misremembered, at best.

I'm fine if you've interpreted a source differently from the way others might, but one can't really even determine how much credence to give your claims if we can't tell whence you got the information.

[litwr]

BigDumbDinosaur wrote:

Just because you wrote it doesn't make it fact. Can you cite an unimpeachable source for Bill Mensch's "quite clear" statement?

Check his recent interview on VCF East. Indeed, he used "diplomatic" phrases but the sense is quite clear.

cjs wrote:

Or any source whatsoever, for that matter? The whole article seems full of not-so-plausible stuff and there are no references for any of it. That does kind of give the impression that much of this may just be misremembered, at best.

I'm fine if you've interpreted a source differently from the way others might, but one can't really even determine how much credence to give your claims if we can't tell whence you got the information.

I am not seeking a scientific degree for this blog entries. I have written this just to help rare individuals to find some interesting information about some first processors history. It is not about "politics" or science, it is about entertainment. If you have some doubts about any point in the article, you still have an opportunity to ask its author. I also seek ways to find more interesting information about those CPUs, so your questions and doubts may help me to improve the article.

[cjs]

litwr wrote:

Check his recent interview on VCF East. Indeed, he used "diplomatic" phrases but the sense is quite clear.

Vague references to interviews or other "sources" are a classic form of argumentation where you simply try to load so much work on your counterparties that they eventually give up trying to fact-check you. (I don't know if you're trying to do that here, but if you are, it is working in this case.) But it's not a good way to find the truth of a matter.

Since you presumably have listened to or read this interview, you presumably know where it can be found (or at least was once able to be found), and know where in the interview he said what you're interpreting. So what's the point of not just giving that information?

Quote:

I am not seeking a scientific degree for this blog entries. :) I have written this just to help rare individuals to find some interesting information about some first processors history. It is not about "politics" or science, it is about entertainment. :)

Well, it might be worth posting an explicit notice at the top of your entries that they are merely for entertainment, and not a serious study. Keep in mind that on the Internet many of us (including me) are coming to your writings without much context, so it's not possible to tell that you're not attempting to write a real historical study here, along the lines of blogs such as The Digital Antiquarian.

Keep in mind that history is a real academic discipline, one plenty as rigorous as, say, computing science, and so you can expect to annoy people when you do something that looks like it's trying to pass for history but isn't, just as you could expect to annoy people if you wrote a blog entry claiming that it's possible to have an O(sqrt(n)) sort (i.e., one that runs exponentially faster as the size of the data increases).

Quote:

I also seek ways to find more interesting information about those CPUs....

Well, so do I. It sounds like mutual co-operation might be beneficial to both of us. But why would you expect others to point you to sources when you're not willing to share the sources you've found?

[litwr]

Hi cjs!
You haven't pointed any error in my material. If I wrote an entertainment material it doesn't mean that I have written wrong materials. In addition I can repeat if you need more clarifications for some points in my materials just try to ask about them.

[BigEd]

(I think what we have here is a specification problem. If the writing were intended as an encyclopedia entry, it would attract a different kind of criticism than if it were intended as a personal take on the story. I'm quite sure it's the latter, and that it's not fruitful to read it as if it were the former. I would, still, agree that some footnotes and links would be nice)

[GARTHWILSON]

scotws wrote:

I also wonder if I would have reacted differently if the 8-to-16 bit parts were not based on modes, but part of the opcode-set (say, sta.b for 8 bit and sta.w for 16 bit or something).

That would take a much bigger op-code table, or using an extra byte after each op code involving A, X, Y, or memory, to tell if it's 8- or 16-bit.  This of course would make programs longer and slower.  The 816's 256-byte op-code table is completely full as it is; so adding op codes to avoid the extra byte is not possible.  There is one exception, but it's no better.  Mensch did leave one op code, WDM, for future expansion (which never happened), and that one op code ($42) would be a window into another 256-byte table; so you're still reading two bytes of op code before getting to the first operand byte.

[BigEd]

Several micros use a prefix byte: one way in which it works well is when the prefixed instructions are rare or slow. So, a 16 bit instruction which might take a little longer to execute can perhaps suffer the penalty of fetching a prefix. Especially if you compare the prefix+16 bit instruction with the alternative 8 bit implementation: it will usually save both time and space. There are 6502 variants which have a prefix byte, but not for this purpose.

[Dr Jefyll]

BigEd wrote:

There are 6502 variants which have a prefix byte, but not for this purpose.

Not exactly a variant -- it's a hand-built one-off! -- but my 1988 KK Computer defines opcodes $43, $83 and $C3 as prefix bytes.

KK is a 'C02 superset that has long addressing (24-bit) baked into the instruction set. The penalty for using 24-bit addressing (as compared to 16-bit) varies from slight to none, making KK comparable to the '816 in that respect. I'll explain the prefix bytes.

As a point of reference, recall that the '816 uses...

• register PBR to supply 8 bits that're prepended to addresses for code accesses
• register DBR to supply 8 bits that're prepended to addresses for data accesses

The KK Computer uses...

• register K0 to supply 8 bits that're prepended to addresses for code accesses
• register K1 to supply 8 bits that're prepended to addresses for data accesses
• register K2 to supply 8 bits that're prepended to addresses for data accesses
• register K3 to supply 8 bits that're prepended to addresses for data accesses

... and that's the purpose for KK's prefixes. They are one of the two ways to engage K1, K2 and K3. $83 is a one-byte, one-cycle prefix which causes the following instruction (example: LDA CMP ADC ASL etc) to apply K1 during its final cycle (the data access). Similarly, prefix $43 will engage K3 and prefix $C3 will engage K2. (The default for data accesses is K0.)

BigEd wrote:

one way in which it works well is when the prefixed instructions are rare or slow.

Yes, exactly -- there are two tiers implied. And the non-prefixed tier, while faster, constrains you to the limited number of opcodes which are not already defined.

The tradeoff I selected for KK devotes six of the precious, non-prefixed opcodes as follows. Simple inter-bank peeks and pokes are allowed to proceed without the one-byte, one-cycle prefix penalty.

• LDA using absolute mode and with 8 bits prepended from K2
• STA using absolute mode and with 8 bits prepended from K1
• LDA using (X,ind) mode and with 8 bits prepended from K2
• STA using (X,ind) mode and with 8 bits prepended from K1
• LDA using (ind),Y mode and with 8 bits prepended from K2
• STA using (ind),Y mode and with 8 bits prepended from K1

A list of all 44 new instructions is here. And I'm slightly OT, so if you care to comment please consider doing so here: 6502 Forth with hardware accelerator.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

As a point of reference, recall that the '816 uses...

• register PBR to supply 8 bits that're prepended to addresses for code accesses
• register DBR to supply 8 bits that're prepended to addresses for data accesses

Minor clarification. DB is relevant only when a data fetch/store address is expressed as 16 bits. Use of a 24-bit absolute address or a long indirect addressing mode ([<dp>] and [<dp>],Y) does not involve DB, since the addressing mode being used specifies the bank. Ditto for any direct page or stack access, which has an implied $00 bank address.

In practice, there isn't much need to tinker with DB, a good thing, since it's not particularly convenient to do so. About the only places where I touch DB are in interrupt handler pre- and postambles, and in functions in which the MVN and/or MVP instructions are used.

The address of any opcode or operand fetch is always prepended with PB.

[tokafondo]

My thoughts about this, based in my knowledge and experience, way lower than many here.

• The 65xx architecture was designed mostly for small applications that needed to run fast. The fact that it was used for complete computers meant for the users world was an extra. That's why I think there were many missing features that a CPU designed with a computer in mind could had had.
• Bill Mensch have said several times that there are not more formats and chips available because the market didn't asked for them, in the form of a generic chip. But there are a lot of custom designs with a 6502 core inside. This is the microcontrollers world way of doing things.
• There exists a microcontroller that features a '816 core inside, with the full 24 bit address bus exposed that many people ask for: the W65C265s. Nothing stops anybody to use it and keep away from the mess that is decoding the address and data buses. It can be considered a demo product, because if asked, the internal ROM can be replaced when built for order with custom code instead of the monitor usually available. It's oriented, again, to the microcontroller world.

[drogon]

On the '265s:

tokafondo wrote:

It's oriented, again, to the microcontroller world.

Have you seen todays "microcontroller world"?

At the bottom end (and it really is a race to the bottom here - cost is everything!) you have the 1 cent, 6 or 8 pin devices from China that they use in everything from capacitive dropper PSUs to simple LED flashers. After that, well, PIC/AVR but their days are numbered because... ARM. Today you can get a 32-bit ARM device with on-board Wi-Fi/bluetooth, "AI acceleration technology" and who knows what else for under $10. It will have on-board flash and some RAM plus GPIO and it'll run off a battery for years. You can program them in Python without all that messy C or ASM nonsense...

RISC-V is making inroads but again if you look then you'll find SoCs with everything on-board plus the kitchen sink for less than a 65c256 setup.

So with that in-mind, why would anyone in their right mind buy an '816 based system.

Today we use the '816 purely for fun or to do the retro "what if"... I would be extremely surprised if there is a new commercial project based on it simply because it's not viable from a performance or cost point of view.

It might be fun to hack though...

-Gordon

[tokafondo]

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.

But for some reason Bill Mensch is still in business. I mean... what happened to the 68k, z80 and other cpus that came later? They evolved and many of them eventually disappeared as obsolete.

So the fact that the chips are still in production should mean something, and it's that they are there for very specific applications for which the ARM maybe is too much.

[GARTHWILSON]

Cheap 32-bit microcontrollers are not pushing out 8-bit ones though.  See https://www.electronicdesign.com/techno ... ontrollers .