6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Sep 25, 2024 1:11 pm

All times are UTC




Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Wed May 31, 2023 7:04 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
Alarm Siren wrote:
Thus the same applies to the 65816 - it's largest native data size is 16-bit, therefore it is a 16-bit architecture. The fact it can also work on 8-bit data is besides the point.

Actually, the 816’s only native data size is 16 bits when operating in native mode. The changeable register widths do not affect the ALU, which always processes 16 bits at a time. That is one of the reasons that, for example, a branch across a page boundary in native mode does not consume any more Ø2 cycles than a branch that stays within a page boundary. It is also why register-to-register copies, e.g., TXA, take two Ø2 cycles, regardless of the register sizes.

As for the 816 not having the simplicity of the 65C02, there’s no surprise in that. The 816 is a significant advancement over the 65C02, just as the 80286 was an advancement over the 8086. When the 286 came on the scene, a whole new programming paradigm arrived with the introduction of protected mode. Rather than grouse about how the “simplicity” of the 8086 had been lost, programmers learned how to use protected mode and other new features, resulting in programs that could do more and at a faster rate.

Something like that is progress, pure and simple.

Incidentally, getting the most out of the 65C816 does demand treating it as a different beast than the 65C02. When I first started writing native-mode 816 code, I often found myself using a stone axe when I had a chainsaw available. :D It wasn't long until I realized many 6502-type algorithms are either inefficient on or downright wrong for the 816. Once I got over that and learned, among other things, to use the stack as ephemeral workspace and not just a place to park the registers, I found myself writing smaller code that was getting a lot more done.

cjs wrote:
In particular, you couldn't really mix 8- and 16-bit work smoothly because you had to explicitly switch between 8- and 16-bit modes using another instruction. In some ways, supporting mixed 8- and 16-bit operations is even worse than a full 16-bit processor such as the 68000. For example, it's not possible (though correct me if I'm wrong here) to add (with correctly calculated carry) an 8-bit value to a full register width (16-bit on 65816) value; you have to convert the 8-bit value to a 16-bit value first.

There is a learning curve to it and some planning is required to minimize register size switching (register sizes, by the way, aren’t “modes”—changing a register’s size has no effect whatsoever on how instructions behave). In many of my programs, I store numerics as 16- or 32-bits, even if a particular numeric will never exceed 255. In many algorithms, the slight additional execution time needed to fetch or store a word instead of a byte is effaced by the elimination of frequent REP and SEP instructions. This becomes especially true with pointer arithmetic—I use 32-bit pointers for “long” accesses, even though only 24 bits are needed. That waste here and there of a byte in this fashion is inconsequential when one considers that pointer arithmetic can be carried out without having to monkey with the accumulator’s size to manipulate the most significant word.

Is the 65C816 perfect? Not at all. Having different opcodes determine the data size being manipulated, instead of selecting register widths via a distinct instruction, would make for more streamlined code and reduce the opportunity to add gnarly bugs to one’s programs. Some aspects of the banking scheme can be annoying as well—I wish execution could span banks, since that would make it possible to load a program anywhere convenient. However, the 816 retains the efficiency of the 65C02, as well as the excellent interrupt performance. Plus the stack acrobatics that can be done with the 816 have no analogue with the 65C02. That’s good enough for me. :D

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 7:09 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
wayfarer wrote:
I would think of this Stack RAM as separate from the normal ram addressing, and accessed internally via the Stack register. because it is only 8 bit addressing, when using the stack, it can be accessed, and externally, it would need a few extra operations to interact with...

Sounds like a totally useless feature to me. The things that can be done with the 65C816’s stack would be difficult to impossible with what you propose, especially considering that the 816 has a 16-bit stack pointer.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 8:01 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
GARTHWILSON wrote:
I have no experience with the 6809; but according to this post and this one, the 6809 had really no execution speed advantage over the 6502—and that's at a given clock rate; but the '02 went to much, much faster clock rates.

If you read slightly further down that first thread, you'll notice that the issue in the post you reference was ported 6800 code not using the auto-increment addressing mode. The second one comes right out and says, "The results show that 6809 at 1.78 MHz matches 6502 at 2 MHz. The second accumulator gives a big advantage to 6809." And that's for math-heavy code that does not play to the 6809's strengths.

I considered bringing up that the 6502s were eventually clocked much higher than the 6809, but it seemed to be getting a bit off-topic. But what you need to consider there is that they clocked much higher because the 6809 was effectively abandoned much earlier than the 6502 was (if the 6502 can even be considered "abandoned" now.) By the early '80s Motorola (and Hitachi) really had no reason to continue 6809 development when they already had the 6811 for the low-end and the 68000 for the high end.

Quote:
Quote:
The "who can do more with fewer chips?" battle is not one you want to get into with Motorola, because they will win.
The only single-chip 65xx solutions you'll find today are in ASICs, in automotive, industrial, toy, appliance, and even life-support equipment, and since they're custom ICs with everything onboard and the processor at their heart being licensed by WDC, they won't be marked with anything you'd recognize, like having any "65" in the name.  However, Mike Naberezny de-capped the controller IC in the control panel of his VW Jetta, in his project to make kind of an information center, and found that the processor in it was a 65c02.  https://wdc65xx.com/about-WDC/ says: "WDC and its licensees have shipped over eight billion CMOS processors; more than 1 per person on planet earth!  This number is growing by hundreds of millions of units each year."

Sure, but 8 billion units over four decades is not a lot, for the microcontroller market. The total number of MCUs shipped in 2021 alone was over 30 billion. I can't find stats for the 6811 (and the 6808, which I think it would be fair to include), and they may be impossible to get given that many different companies (Motorola, Hitachi, Maxim, Freescale, NXP, ...) have been shipping these, but given that the 6502 basically missed the automotive market, I'd be surprised if they'd shipped anywhere near the quantities that 6800, 6808 and 6811 cores have, which have been huge that market from the start. (Yes, I'm aware that WDC lists one automotive application on that page, a dashboard controller. But consider that your average car these days has 35 microcontrollers in it.)

We'll probably never know for sure, given that as you point out ASICs using a particular core are hard to see, and soft cores are virtually invisible. But given that the 6502 started from far behind and is poorly suited for C code compared even to the 68HC11, much less more modern 8-bit CPU designs such as AVR, I think it's a pretty safe guess that it never caught up.

Note that this says nothing about the 6502's design, which was brilliant for the time, and in virtually all ways better than the original 6800. The main reasons Motorola came out so far ahead in the MCU market were being there first and, probably even more importantly, having the marketing and history within the automotive industry to sell it into that market. (Around the early '80s it may have helped a bit that Motorola's architecture allowed them to easily and compatibly fix some of their largest technical problems, such as by adding the Y register, but probably not all that much.)

Quote:
I had mentioned stack-relative addressing earlier, for stack frames, but this is also a good point which I was forgetting, regarding finding inlined data as well, and adjusting the return address to skip over the data....

Yup, that's another good example; there are probably various other techniques like that that I've forgotten to mention, too.

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 9:27 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1467
Location: Scotland
BigDumbDinosaur wrote:
The Commodore 64’s BASIC interpreter has the self-modifying CHRGET function on zero page. CHRGET reads BASIC program text a byte at a time and determines whether what was read is a BASIC token, PETSCII, or something else. Each time CHRGET is called, it first increments the text pointer, which is actually part of the code.


This code is common over all 6502 versions of MSBASIC.

I do recall an article in (I think) CALL APPLE where they optimised it for Applesoft at one point - saved one cycle which wasn't really significant but probably a good exercise at the time...

When I started my bytecode VM for the '816 BCPL, I started that way too - but the overhead of the JSR/RTS was more than I wanted so moved to a Plan B ... (the 'fetch next byte' code is in-lined with every instruction decoded - RAM is cheap now)

The generic code from the source reconstruction project is:

https://www.pagetable.com/?p=46

Code:
.segment "CHRGET"
RAMSTART1:
GENERIC_CHRGET:
        inc     TXTPTR
        bne     GENERIC_CHRGOT
        inc     TXTPTR+1
GENERIC_CHRGOT:
GENERIC_TXTPTR = GENERIC_CHRGOT + 1
        lda     $EA60
.ifdef KBD
        jsr     LF430
.endif
        cmp     #$3A
        bcs     L4058
GENERIC_CHRGOT2:
        cmp     #$20
        beq     GENERIC_CHRGET
        sec
        sbc     #$30
        sec
        sbc     #$D0
L4058:
        rts


-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 3:26 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 852
Location: Potsdam, DE
cjs wrote:
(And to this day we're still using 68HC11 MCUs.)


Indeed, the ECU in my Fiat Coupe - thirty years old - uses a 6811 of some flavour as the controller. Still works fine; I just had the car dragged out of storage and it fired first turn of the key. Though I worry about the longevity of the EEPROM (which was originally a PROM but was changed out about fifteen years ago for some more enthusiastic maps)..

Neil


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 4:18 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
drogon wrote:
BigDumbDinosaur wrote:
The Commodore 64’s BASIC interpreter has the self-modifying CHRGET function on zero page. CHRGET reads BASIC program text a byte at a time and determines whether what was read is a BASIC token, PETSCII, or something else. Each time CHRGET is called, it first increments the text pointer, which is actually part of the code.

This code is common over all 6502 versions of MSBASIC.

Yep, but I used the C-64 as an example because it was the most ubiquitous of the eight-bit machines to use Micro$oft BASIC.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 4:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
I’ve been more-or-less following this topic, but I am not really seeing much here that is of interest. Being 6502.org’s unofficial curmudgeon, and at the possible risk of exciting someone’s ire, I will say I mostly view these “Chuck Peddle should have done this and Bill Mensch should have done that” topics as a waste of forum server storage capacity and bandwidth. :shock: That they are often started and stoked by individuals with little-to-no practical experience with the 6502 and its assembly language comes as no surprise.

Monday-morning quarterbacking has yet to win a game or alter the course of history. Everyone, it seems, thinks they could have done better than MOS Technology. The problem with that line of thought is that it is grounded in what we know today, not in what was known a half-century ago. It’s no challenge in conjuring improvements to a design that was spawned during the microprocessor Stone Age.

The 6502’s design was shaped by some very specific goals, foremost among them being the desire to undercut Intel and Motorola, while still offering good performance and flexibility. Given the countless number of 6502-family devices produced, the wide range of 6502-based designs that followed the MPU’s release and the overwhelming success of home computers such as the Commodore 64, I’d say Peddle, Mensch et al exceeded their goals by a wide margin.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 4:39 pm 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 362
BigDumbDinosaur wrote:
I’ve been more-or-less following this topic, but I am not really seeing much here that is of interest. Being 6502.org’s unofficial curmudgeon, and at the possible risk of exciting someone’s ire, I will say I mostly view these “Chuck Peddle should have done this and Bill Mensch should have done that” topics as a waste of forum server storage capacity and bandwidth. :shock: That they are often started and stoked by individuals with little-to-no practical experience with the 6502 and its assembly language comes as no surprise.

Monday-morning quarterbacking has yet to win a game or alter the course of history. Everyone, it seems, thinks they could have done better than MOS Technology. The problem with that line of thought is that it is grounded in what we know today, not in what was known a half-century ago. It’s no challenge in conjuring improvements to a design that was spawned during the microprocessor Stone Age.

The 6502’s design was shaped by some very specific goals, foremost among them being the desire to undercut Intel and Motorola, while still offering good performance and flexibility. Given the countless number of 6502-family devices produced, the wide range of 6502-based designs that followed the MPU’s release and the overwhelming success of home computers such as the Commodore 64, I’d say Peddle, Mensch et al exceeded their goals by a wide margin.


I agree with everything that you said, except that I don't think these sorts of topics serve no purpose. They allow people to discuss and speculate on what "could have been", engage in a topic they are passionate about, and have some fun social interaction with other members of this community. If you see no value in it, just don't look at the thread: there are many threads I do not read because they do not interest me, but I wouldn't go into that thread to tell the people talking there that their discussion is a waste of server storage space.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 4:59 pm 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
BigDumbDinosaur wrote:
Everyone, it seems, thinks they could have done better than MOS Technology.

Well, I don't.

Quote:
The problem with that line of thought is that it is grounded in what we know today, not in what was known a half-century ago. It’s no challenge in conjuring improvements to a design that was spawned during the microprocessor Stone Age.

I disagree with this, though perhaps I'm taking a slightly more literal approach to the question than you are. The more I learn about the 6502, the more impressed I am with its design, and I see very little that could be done unarguably better if you look at all the conditions under which they were working, including things like considering the effect of die size on yield and so on.

The classic example is people suggesting the addition of BRA, which has been discussed fairly extensively already; I think that most people suggesting this have no real idea of (or just don't care about) the knock-on effects of adding a ninth branch instruction. A few decisions like this and you end up with a significantly larger processor: it's not just the switch to CMOS that makes the 65C02 have more than 2.5 times the number of transistors than the NMOS 6502 (11,500 vs. 4,500, with the latter including the depletion mode pull-ups, according to Wikipedia).

And it's discussions like these that are (at least partially) responsible for me learning such things. So they've been quite valuable to me.

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 5:19 pm 
Offline
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 746
Location: Germany
Alarm Siren wrote:
They allow people to discuss and speculate on what "could have been", engage in a topic they are passionate about, and have some fun social interaction with other members of this community.

plus there's the off chance someone gets inspired by these kinds of threads and creates a simulator, FPGA core, or other projects based on the discussed ideas.
which is always neat :D


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 6:06 pm 
Offline
User avatar

Joined: Fri Sep 08, 2017 9:41 pm
Posts: 43
Location: UK Expat living in Washington State, US
BigDumbDinosaur wrote:
[color=#000000]I’ve been more-or-less following this topic, but I am not really seeing much here that is of interest. Being 6502.org’s unofficial curmudgeon, and at the possible risk of exciting someone’s ire, I will say I mostly view these “Chuck Peddle should have done this and Bill Mensch should have done that” topics as a waste of forum server storage capacity and bandwidth. :shock: That they are often started and stoked by individuals with little-to-no practical experience with the 6502 and its assembly language comes as no surprise.


Well, I'll bite as I started the topic. And mea culpa I have never been paid for z80 or 6502 programming. I work in the Med Device wearables space, and I can assure, no one is using 6502 derivative processors.

Quote:
Monday-morning quarterbacking has yet to win a game or alter the course of history. Everyone, it seems, thinks they could have done better than MOS Technology. The problem with that line of thought is that it is grounded in what we know today, not in what was known a half-century ago. It’s no challenge in conjuring improvements to a design that was spawned during the microprocessor Stone Age.[


Ok, so why are we all here - What is this forum's purpose? If we take this line of reasoning further then the whole forum is a waste of bandwidth.
If the forum is not "what if's" with the benefit of hindsight (and cool retro projects), then we are left with place for information memorialization e.g. 6502 signed 32 bit divide that shaves a cycle, where probably a wiki is more appropriate.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 7:19 pm 
Offline
Site Admin
User avatar

Joined: Fri Aug 30, 2002 1:08 am
Posts: 281
Location: Northern California
VinCBR900 wrote:
Ok, so why are we all here - What is this forum's purpose? If we take this line of reasoning further then the whole forum is a waste of bandwidth.

The original purpose of the website was to collect information such as datasheets for the 6502 and related chips, which at the time (1999) were difficult to find online. The original purpose of the forum was to provide a place for people to ask questions related to the 6502. I was trying to build an SBC at the time (again, 1999) and there weren't many good places to do that.

It's no longer necessary to collect and host datasheets, as a Google search will usually find any needed datasheet. The website archive.org is also available to store datasheets, and I've uploaded all of our files there as well. In 2023, there are also a huge number of different forums and places on social networks where people can discuss these topics. There are YouTube channels to watch, kits to buy, blog posts, other websites, and all sorts of other help that didn't exist in 1999.

With all that being said, I'm not completely sure what the purpose of the website and forum is anymore. There some people who have been checking the forum every day for years, so I suppose my answer is that the purpose of the forum these days is mainly to continue to exist for the people who seem to get something out of it. If some users want to engage in some "what if"-type discussions, or any other type of 6502-relevant and friendly discussion, I'm hoping that all users will respect that. If anyone finds a topic uninteresting, I hope they can just ignore it.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org


Top
 Profile  
Reply with quote  
PostPosted: Wed May 31, 2023 10:42 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
Although I haven’t contributed anything meaningful to the forum regarding my 6502-related activities in quite some time, I check the site frequently. Often learn something that I can apply in my day job; that is a concrete benefit to me and others here.

I hope to continue this learning process, and hope to see the site maintained for this purpose into foreseeable future.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 01, 2023 1:16 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
Alarm Siren wrote:
I agree with everything that you said, except that I don't think these sorts of topics serve no purpose.

I was expressing an opinion and at the same time, intentionally being provocative to somewhat shift the flow of conversation. :D

Quote:
They allow people to discuss and speculate on what "could have been", engage in a topic they are passionate about, and have some fun social interaction with other members of this community.

I agree. However, this particular topic seems to have been dominated by one individual who.

Quote:
If you see no value in it, just don't look at the thread: there are many threads I do not read because they do not interest me, but I wouldn't go into that thread to tell the people talking there that their discussion is a waste of server storage space.

That’s the beauty of the principle of “freedom of expression.” You can make statements that are not necessarily in step with what others think.

Mike Naberezny wrote:
...With all that being said, I'm not completely sure what the purpose of the website and forum is anymore.

6502.org remains, in my opinion, the best site on the Web to get extensive technical knowledge about the 6502 family. Youtube videos have their place, but they are ephemeral and often don’t offer the full picture (plus some are sources of nonsense). In one particular case that we know of, Youtube videos seem to have increased 6502.org membership.

It’s true that access to 6502-related data sheets and other publications can be gotten most anywhere on the Internet. However, very few sites have the wealth of data that is to be found here. Type “6502” into your favorite search engine and you’ll see lots of references to 6502.org. That alone, I think, defines the website's purpose.

However, what separates 6502.org from the others is the constant flow of information about projects being built, from a small computer on a breadboard to an ambitious one with high-quality video, etc. If I were interested in building a 65C02 or 65C816 machine and had never done so, I would come here to find out what I need to know. That’s exactly what I did when I started on my POC series (I was a lurker for a few years before signing up).

Quote:
There some people who have been checking the forum every day for years, so I suppose my answer is that the purpose of the forum these days is mainly to continue to exist for the people who seem to get something out of it.

I would think most anyone who regularly visits here will get something from it. For example, I've been following the topic about random number generation, not because I have a specific requirement for a PRNG, but because I’m always on the lookup for useful algorithms.

Quote:
If some users want to engage in some "what if"-type discussions, or any other type of 6502-relevant and friendly discussion, I'm hoping that all users will respect that. If anyone finds a topic uninteresting, I hope they can just ignore it.

I don’t find all topics here to be of interest, but I do read just about everything that is posted, even stuff about Forth. :D There is always a possibility that I will read something that will be useful to me at some point.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 01, 2023 2:02 am 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
I get a lot out of different discussions, as someone who knows almost nothing about 6502 assembly, I learned that the stack works entirely differently than expected and if it performs as you seem to say it does the relocatable stack on the 65816 is terribly powerful for data transfer.

this is a great topic to better understand why the 6502 is what it is.


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 34 guests


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: