6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 10:30 am

All times are UTC




Post new topic Reply to topic  [ 84 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Tue Apr 13, 2021 8:09 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1392
Location: Scotland
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

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 13, 2021 8:45 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8412
Location: Southern California
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 13, 2021 12:55 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 13, 2021 11:16 pm 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 341
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:

Image

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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 14, 2021 7:41 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 15, 2021 8:08 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
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 seems 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. The 65C816's hardware vectors are seen only in bank $00. This characteristic is a byproduct of the need to maintain (mostly) backward compatibility with the 65C02.

  2. Program code. If the program counter (PC) wraps, the program bank (PB) will not increment. Therefore, program execution is confined to the bank defined by 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—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. This characteristic also applies to an absolute indirect long jump, e.g., JMP [$1234].

    On the other hand, an absolute indexed indirect jump, e.g., JMP ($1234,X), bounces off a vector located in the same bank in which the indexed indirect jump instruction is located. This characteristic also applies to an indexed indirect subroutine call, e.g., JSR ($1234,X) (a very useful instruction—it's like ON - GOSUB in BASIC).

  4. Stack. All stack accesses are directed to bank $00. This includes both stack-relative addressing modes. As the 65C816's stack pointer (SP) is a 16-bit register, the stack may be located anywhere in bank $00.

  5. Direct page. All direct page (aka page zero or zero page) accesses are directed to bank $00, including the indirect direct page addressing modes. As the 816's direct page pointer (DP) is a 16-bit register, direct page may be located anywhere in bank $00. In fact, DP may be pointed to a reserved area on the stack, a very useful feature!

  6. Data fetch/store. Unless one of the long addressing modes is used, data will be fetched and/or stored in the bank defined in the data bank register (DB). This characteristic allows most 65C02 code to run unchanged on the 65C816 if DB is set to whatever is in PB with a PHK - PLB instruction sequence.

  7. Block-copy instructions. Both MVN and MVP take a source and destination bank as operands and can copy intra- or inter-bank at high speed (seven clock cycles per byte copied). DB is changed by these instructions to point to the destination bank. It is customary to surround a block-copy instruction with PHB and PLB to preserve DB.

  8. Long addressing. The long absolute addressing modes, e.g., LDA $AB1234 or LDA $AB1234,X, implicitly specify the target bank and hence may be used to access data outside of the bank defined in DB. The indexed form of long absolute will span bank boundaries if the sum of the address plus .X causes a carry into bits 16-23.

    The long indirect addressing modes, [<dp>] and/or [<dp>],Y, where <dp> is a location on direct page of a 24-bit address (in three contiguous bytes), are completely bank-agnostic and when used with 16-bit index registers, facilitate fetch/store access to the 816's entire 16MB address space with succinct code that is easy to write. What this means is that from a data fetch/store perspective, memory accesses are completely linear.

Further to long indirect addressing, I have learned that in writing efficient 65C816 code, direct page pointers (also, long indirect jump vectors) are better handled as 32-bit quantities, even though the MPU is limited to 24-bit addresses. Programs so written tend to be more compact and also tend to run faster because the accumulator can be set to 16 bits and left that way as pointer arithmetic is carried out. Otherwise, it is necessary to repeatedly execute REP and SEP instructions to switch the accumulator size to handle the LSW or MSB of the 24-bit address being processed, at a cost of two bytes and three Ø2 cycles per REP or SEP.

Having written tens of thousands lines of 65C816 code, I will emphasize that manipulation of the bank registers is very uncommon. In the case of PB, the program bank register, there is no direct, programatic means by which it can be changed. In practice, DB (data bank register) hardly ever gets touched as well, a good thing, since doing so tends to be awkward. During initialization, my main-line programs will do a PHK followed by a PLB to set the default data bank to the program bank. Hence fetching static data that was assembled as part of the program can be conveniently accomplished with 16-bit addressing. In contrast, data that is being processed is handled with long indirect addressing, which means it can come from anywhere in memory and go to anywhere in memory.

In summary, while existing 65C02 algorithms can be made to run on the 65C816 (in either mode), that is a gross under-utilization of the MPU's capabilities. The key to developing for the '816 is to understand that it is a completely different critter in native mode than its eight-bit cousin (the 65C02) and thus programming it demands a totally different approach if the full power of the '816 is to be used. Once you come to that realization you will be amazed by what you can accomplish.

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


Last edited by BigDumbDinosaur on Wed Jun 02, 2021 6:21 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 15, 2021 3:12 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1918
Location: Sacramento, CA, USA
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)


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 15, 2021 6:44 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3328
Location: Ontario, Canada
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

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 15, 2021 9:47 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 15, 2021 9:48 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
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. :D

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 16, 2021 6:11 pm 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 341
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 17, 2021 3:22 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3328
Location: Ontario, Canada
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. :) )
Attachment:
5-1.png
5-1.png [ 7.73 KiB | Viewed 1879 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

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 17, 2021 7:25 pm 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 341
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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 17, 2021 7:58 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3328
Location: Ontario, Canada
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 18, 2021 12:22 am 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 341
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.
[/quote]

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 84 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: