Over on CLAX the 6502 was mentioned in this thread:
https://groups.google.com/forum/#!topic ... VtSmnc2ddw

Do any of you 6502 enthusiasts have any comment regarding to my post? Here is what I said:

On Tuesday, November 8, 2016 at 4:03:07 PM UTC-7, hughag...@nospicedham.gmail.com wrote:
> ... let me say that the Mostek 6502 (it was 1975 not 1972) was far superior to the Motorola 6800 and Intel 8080 (both 1974). To a large extent, the 6502 kick-started the microprocessor age! It is debatable if the 65c02 was superior to the Zilog Z80 (I liked the 65c02, for whatever my opinion is worth) --- we could debate on this until our hair turns gray, and never get a resolution, so lets not go there...
>
> But I will also say that the 65c02 had design flaws (above I said that it is "superior" not "perfect"). If I could go back in a time-machine and offer some suggestions, these would certainly change the course of computer history dramatically:
>
> 1.) Get rid of the indirect-X addressing mode --- it was a waste of chip-space --- nobody ever used it for anything.
>
> 2.) Change the jump-indirect to use the Y register rather than the X register (the X register is needed for use as the Forth data-stack pointer) --- token-threaded code will be needed for many languages (Apple Pascal, Promal, etc.) --- this saves a lot of memory, and memory was expensive in the 1970s.
>
> 3.) Fix the return-address so it is a valid address (on the 6502 it is off by one, which is a bug not a feature). Also, provide LDS and STS instructions for loading and saving the S register to zero-page --- and fix the S register so that it is a valid address (when saved to zero-page as a low-byte, given 1 as the high-byte, you get a valid zero-page pointer).
>
> 4.) Support 128KB (64KB for code and 64KB for data) by having a 17-bit address bus and switching the high bit back and forth as needed during instruction execution (get rid of that set-overflow pin that was never used) --- memory will become less expensive in the 1980s, and people will want bigger programs that work with more data.
>
> Note that #2 above would have made high-level languages realistic in the 1970s when memory was still super-expensive --- this would have made computers useful at a time when (in the actual history) they were just toys --- this is, I think, what George Neuner was saying in his post.
>
> Note that the #3 bug-fixes above open a lot of doors. LDS and STS would have allowed a local-frame pointer in zero-page (pointing into the return-stack) allowing both Forth or C to have local variables, which would have made reentrant code possible, which would have made a multi-tasking OS realistic. We could have also had efficient direct-threaded-code in Forth (every colon word starts with a JSR to DOCOLON, and the DOCOLON pulls the return address from the S stack and stores it in IP which is a zero-page pointer).
>
> Note that #4 above would have made the 6502 competitive for business use with the 8088 (the only reason the 8088 was used, was that it allowed for more memory; it was much slower than the 65c02 for games and other programs requiring little memory) --- CP/M would have expired quickly and without lamentation, and MS-DOS would have never come into existence --- we would have instead gotten a future involving a better OS built on a better processor.

Actually, (ZP,X) is used constantly in Forth. This is discussed in the topic "(zp,X), high-level languages, and processor design."


I don't think it was a bug, nor was it touted as a feature AFAIK; but I suspect it was done the way it was because interrupts worked differently from subroutines, and it took less silicon real estate the way they did it. But yeah, it would be nice if JSR left the address of the first byte of the following instruction, instead of the last byte of its own operand. For LDS and STS, TSX and TXS do the job, although involving X. It would be nice to keep X out of it; but having several LDS and STS addressing modes would have taken up valuable op-code table space that was later needed for the 65816.


I've never used the SO\ pin, but a few hardware devices like the C64's disc drive did, to get faster input. Jeff makes use of it for ultra fast I/O at http://wilsonminesco.com/6502primer/potpourri.html#Jeff, using 65c02 illegal op codes to accomplish bit output and input simultaneously, in a single cycle (twice as fast as the normal 6502 minimum instruction time), for following it immediately with BVC or BVS.


I tell how to do local variables and environments on the '02 in the Local variables & environments section of the stacks treatise, and how to do recursion on the '02 in the Recursion section. Jonathan Halliday is working on a GUI with preemptive multitasking on a 6502 8-bit Atari. He's not finished, but he has very impressive stuff working which he demonstrates in videos. See http://wilsonminesco.com/stacks/potpourri.html#Gek .

Bruce Clark (a forum member here) shows how to do a single-instruction, 6-cycle NEXT in DTC Forth on the 65816 at viewtopic.php?t=586 , and how to do a two-instruction NEXT in ITC Forth on the 65816 at viewtopic.php?t=584 .

The '816 opens up a lot of avenues where the '02 was either clumsy or incapable. It adds stack-relative addressing modes plus a 16-bit stack pointer, so local variables work a lot better and recursion won't risk running you out of stack space. You can also set its direct page (like zero page, but it can be moved around) to overlap the top of the stack, affording DP addressing modes in the stack space. It gives 16MB address space, and is much more suited to multitasking, multithreading, relocatable code, and lots of other things. The price difference is minimal. I find the '816 to be actually easier to program, in situations where you're constantly dealing with 16-bit quantities.

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

Indirect-X is only used in C@ and C! --- it is not used in @ and ! --- in C@ and C! it has minimal value (a very few clocks faster) compared to using indirect-Y like @ and ! use.

I think indirect-X was a waste of chip-space --- it is only useful for a table of pointers to 8-bit data, but typically your pointers are to multi-byte structs.


Maybe "bug" wasn't the correct word --- a bug is inadvertant --- the weird return-stack in the 6502 was a convenience to the hardware designers, and they hoped that the software guys wouldn't notice, but we did.

I'm only suggesting here that LDS and STS work with zero-page direct addressing --- the only purpose is to support having zero-page pointers into the return-stack --- this is an addition of only two opcodes, which would have been reasonable in the 1970s (especially after the many indirect-X opcodes have been removed).


Well, I think everybody in the 1980s wanted 128KB of memory --- everybody hated bank-switching --- this one isn't very controversial...


I know that it is possible to just use a zero-page pointer as the local-frame pointer, and have your locals stack distinct from the return-stack --- most likely this is what you are suggesting (I didn't read your thread) --- I also know, however, that having locals on the return-stack is fast because PHA can be used for pushing the parameters in preparation for calling the sub-function in C (or at the entrance to the sub-function in Forth).


I agree that the 65c816 is much better than the 65c02 --- but in this thread I'm saying what I would suggest given a time-machine to the early 1970s --- the 65c816 was not feasible then; any different version of the 6502 would have to be pretty close to the actual 6502 to be feasible.

I actually think the 6502 was a huge step up from the MC6800 and i8080 that came out one year previously --- I'm just saying that it wasn't perfect --- it could have been better at little or no cost, and this would have changed the course of history.

Well, no, Mostek produced Z80 CPUs and the like, IIRC. MOS Technology, which is not Mostek, created the 6502. But you're not the first one mixing up Mostek and MOS..

Cool idea. And I agree it needn't require a large number of opcodes.

Perhaps there are some Forths for which that is true. But, for the record, FIG Forth -- an early and widely-used 6502 Forth -- does use (z-pg,X) mode, both for @ and ! (as well as C@ and C!). I haven't tried coding @ and ! without using (z-pg,X) mode, so I can't say whether the advantage is large or small.

-- Jeff

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

My '02 Forth has it 33 times. In every case, it's for accessing memory whose address is on the data stack, where X is the stack pointer. My '816 Forth has it 25 times in just the main file, not including the ones that might be in the INCLude files (which I did not count). Many of these (DP,X) occurrences are in fairly heavily used words:
People writing kernels often write many of these as secondaries instead of primitives; but with the 816's ability to handle 16 bits at a time, making them primitives not only made a dramatic improvement in the performance, but even shortened the code in many cases. It was not worth doing them all as primitives on the 6502.

Fetch becomes just:
having only 4 bytes and no JSRs or their overhead.




I show how to deal with them on the hardware stack, so yes, you can use PHA & friends.


We have a lot of members here who think highly of it.

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

I consider the split stack to be much more efficient than the packed stack --- only one INX rather than two needed for DROP, and only one DEX rather than two needed for making room for a new datum --- in this context, indirect-X is only barely more efficient than indirect-Y for C@ C! etc..

If indirect-X is really dear to your heart though, then it could be provided for LDA and STA only --- this gives you everything you want reasonably efficiently --- this still opens up a lot of chip-space for my suggestions, which I think are a lot more useful.


Indirect-X is much more useful when you have 16-bit registers such as on the 65c816, rather than 8-bit registers such as on the 65c02 --- for one thing, the data-stack is 16 bits wide, plus quite a lot of data is 16-bit in size --- as I said though, it is not very useful to have a table of pointers to bytes, because most structs are bigger than one byte.

Also, as I said, I'm talking about what suggestions I would make if I had a time-machine back to the early 1970s when the 6502 was being designed --- the 65c816 was not realistic at that time; anything hypothetically done would have to be pretty close to what was done --- I think that it is great that you have a 65c816 Forth, but that is not the topic of this thread.

This may be pedanic, but I think it needs to be pointed out that the 65c02 and 6502 are distinct. And, that the 65c02 and its JMP indirect with X instruction were not available in the 1970s when RAM was expensive.

I'd like to ask a topical question if I may:

Other then price, what advantage did the 6502 have over:

6800
Z80

For the sake of argument, the hardware platform is a typical micro of the day. Or; would the BBC have been a better or worse micro if it was fitted with either of those MPUs?

Reading Garth's comments on the 65816 makes me ask the question of what the 6502 had going for it over its contemporaries?

_________________
8 bit fun and games: https://www.aslak.net/

I think interrupt latency is probably the next biggest win. Price is certainly the biggest. I'm not sure if bus and peripheral interfacing are any easier with 6502 than with the others. Single-rail supply and no need for a clock driver chip were advantages, although maybe not against the two micros you offer. I think the 6502 maybe did better with small RAMs? (One should be looking at the cost of a minimal working system, because a larger system has more headroom for a more costly CPU.)

I think the Amstrad CPC shows that a Z80 based micro can be pretty good - no reason why Acorn couldn't have used that, if history had been completely different. As it was, Sophie had already gone a long way down the 6502 road.

On the interrupt latency, Acorn did choose to do quite a bit with interrupts, including byte-by-byte interrupts from the disk controller. On a micro without this advantage, you'd need DMA, which is extra effort and cost.

For high level programming with memory structures, (zp,x),y addressing would have been amazing.

Aslak3: The 6502 takes far fewer clock cycles per instruction than Z80 (I'm unfamiliar with 6800). While the Z80 tended to clock faster than the 6502 back in the day, only fast fills & memory copies tended to be reliably faster than the '02 in home computers.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Processors like the 6800, 6809, 8080 and Z80 have 16-bit stack pointers and index registers which makes compiling languages like C, Pascal and Modula-2 a lot easier. All of these devices had a standard disk operating system (e.g. FLEX, CP/M, FLEX2 OS/9) that allowed the development of portable software between machines with a common architecture.

The specialised nature of chunks of the 6502's memory space and 8-bit registers seems to have encouraged 6502 based systems to have propriety architectures and operating/disk operating systems with the result that there are far fewer common software packages.

WhiteFlame: 6800 instruction cycle times are similar to the 6502. They lose some opportunities to pipeline by using big-endian addresses and there is some strange behaviour in store instructions which change the NZ flags. Interrupts automatically save registers which can increase the latency for really simple handlers.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I think the reason why the 6502 lacked an indirect JMP is just because the designers forgot to consider the possibility of token-threaded languages --- they likely weren't considering the possibility of compilers at all --- they expected only assembly-language to be used because memory was so expensive that compiled languages were unrealistic even with token-threading used to save memory.

Then when the 65c02 came out with an indirect JMP it was completely screwed up by using X rather than Y --- X is needed for the data-stack --- that was just a blunder.

The Motorola 6800 had only one index register, which made programming it horribly over-complicated and inefficient.

I remember one old programmer who had worked on the MC6800. He said that to copy a memory-block, he would save SP in a global variable, then use IX and SP as the source and destination pointers. If going up, then SP would be the source and PLA would be used, but if going down then SP would be the destination and PHA would be used. Of course, interrupts would have to be turned off --- I don't know if the MC6800 had a nonmaskable interrupt like the 6502, which would make this technique unusable --- either way though, the MC6800 was a nightmare to program (and the 6805 was too).

The 8080 was much better than the 6800 --- this is why CP/M was written for the 8080 rather than the 6800 --- the 6800 was pretty much obsolete from day one; it never got used much for anything.

The 6502 was certainly superior to the 8080. Whether the 6502 was superior to the Z80 or not, is debateable --- a lot of emotional energy was spent on this debate in the 1980s --- given the improvements that I described above however, the 6502 would have been superior to the Z80 and the history of computers would have been much different.

You are right --- I had that bit of history wrong.