6502.org

Yep, reading the head post again, clearly the call is for an actual microprocessor.

If only we could all understand that our own preferences are not universal.

So, to recap :

• Comes from a self-taught C programming background and would prefer to use something that is supported by a C compiler (Whether it's the WDC tools or another compiler) RP6502 : Yes. C development environment (cc65) integrated into VSCode. If you've already used VSCode it is really straightforward to develop for the 6502.
• Does not like assembly and will try to avoid using it as much as possible RP6502 : see above
• Has a budget of $100 for the SBC and a simple display for it (looking at monochrome LCDs that are 96x64 or smaller, still exploring options, but will be using SPI or I2C) RP6502 : the discrete components come out at under 50Euros (including the RAM chip) but I already have 65C02 and 6522 in stock. The PCB made in china was about 10Euros for 3 or 5. You don't have to start with a terminal, you can use a host PC.
• Needs something made from off the shelf parts still in production as what I develop with this will be spun off into projects I'd like to make more than one of cheaply RP6502 : all available form Mouser (and probable others as well)
• Can solder if the the SBC is a kit that comes pre-assembled, but won't touch any grid array ICs unless a socket is used RP6502 : everything is through-hole and the PCB is very simple.
• Wants to get output to a SPI/I2C graphic display as quick as possible by direct CPU drawing (in terms of time spent getting it working, not the communication speed) RP6502 : no I2C or SPI included, but there is already the 6522 and there are quite a few contributed solutions on this forum for both interfaces using the 6522.
• Wants exposed address/data bus linesRP6502 : The signals are not exposed on pins, but it would be easy to make a header for the 65C02 to have easy access to all signals.

And just a reminder that the Rpi picos do not interfere with the 65C02 once it is running : they wait for system calls from the user code. The only 'string-pulling' done is that the Rpi is generating the system clock.

It doesn’t need much hardware to have a complete 6502 SBC and it can do graphic if you run it to 25mhz. I have a thread about “6502 as a VGA controller”; while the focus is on VGA graphics, the core hardware design is quite simple—6502, ram, CPLD, oscillator, and 74ls74 interfacing to CF disk, serial port, VGA and PS2. It is inexpensive to build. I have not worked on it for over a year, but I believe the CPLD can be replaced with ATF1504 (currently in stock) and eliminate the 74ls74 in the process. The VGA graphic generation is computational intensive, about 90% of throughput, but without graphic and using serial port as the console, it is a very fast 6502. Perhaps this is the kind of 6502 design you are interested in?
Bill

If it's practical, it wouldn't be a bad idea if those using CPLDs could offer them, pre-programmed, to others who are not yet at the level of programming their own but want to copy your project.  (I'm not suggesting any custom work of course, just programming more parts with your same code and sending them to whoever is willing to pay for the CPLD and the shipping.)  It might turn out to be a welcome addition to an OP's catalog of ideas he's considering.
The path desired can change as the topic develops, especially for one who has limited experience.  If the OP wants to pull things back to his original idea, he can.  However, it's similar to one of the reasons I liked paper catalogs when Mouser and Digi-Key were sending them out.  I'd start with a problem to solve, and look for the part I imagined would fit the bill, thumb through the pages, and find a pleasant surprise, "Ah!  Hey, that's neat!  That's much better than what I had in mind, and will simplify the job!"  When they went to online only, searches got better in some cases, but you had to know what you're searching for.  If you have only a foggy idea, it doesn't work as well.  Ed, please stop being so rigid.

Wants to learn to build a 6502 system. Wants to learn to program the 6502, but only in C. Wants to build and program a hand-held battery powered LCD game system. Not averse to using FPGAs or other programmable hardware but does not want a $30 low-power FPGA board with LCD and audio, etc., because $30 is too expensive and it is an overkill. Wants to learn to design video hardware. Wants to learn to layout the PC boards, and will design a PC board for the project. Does not yet know it, but will need to do quite a bit of system programming (apparently in C) to integrate the LCD, audio, battery management, and whatever else on the board. Wants to market said hand-held board as a product. In the immediate future, wants to maybe buy a $65 or maybe $100+ board as a learning tool.

Do I have it right?

My apologies for joining this thread. I don't know why I keep trying.

You're acting like a salesman for the Tang Nano and I am the type who reflexively pushes back against even perceived sales tactics. That's part of the reason I'm so averse to using it. Your salesman-like behavior is associated with it in my head now. I was just sticking to the technical reasons and my preference for using real 65XX silicon as the main processor to be polite.

Then you seem to get upset and start saying things like "I am betting on failure", "I don't even know why I try" or telling me why I'm self-sabotaging by not using it when it becomes clear that I'm not interested in using it. Your attempts to push the Tang Nano on me come off as "you should replace your entire project with this" as if not using one in my project is a personal insult to you.
I'm not against learning 65XX assembly if I'm going to start designing hardware to run my code. I just recognize that I'm going to struggle with it compared to learning C. I was talking to a friend who knows 65XX assembly (he used to make NES homebrew) and he suggested I could also use defines to map each opcode to a word that is more compatible with the way I read/write code, but it would come at the cost of being code no one else could read. (I could just run all my code I intend to share with others through a few "replace all" operations in Notepad before sharing the code so it's readable to people that aren't keeping track of those defines.)
Funnily enough, most of the early planning on that 65C816 handheld project was just me browsing Mouser during downtime at work or reading up on how 16-bit computer worked (spent a few days trying to find the right MPU on Mouser then trying to design out a system from there. It's what steered me in the direction of the 65C816 initially.) Then, when I got home, seeing if I could fit all the parts I think I wanted on a single PCB in EAGLE (but not wiring them up yet since who knows if they'd actually work together) and making Blender mockups of the shell to see how small I could make the device with scale models of all the parts in there. I was doing this a few months before I made my account here. Then I wanted to see if I could actually make something work with that project I was fooling around with, but wasn't serious about at the time. For now, the W65C816 device I want to make is on the backburner and I want to make a few simpler projects that focus on each of the major design hurdles of the main project to learn as I go. But I need to get the basics down before I can even approach any of those.

You are right, I do expect this project to change as I gain a better understanding of what I'm working with and finds things my initial research may have missed. There are certain aspects of the project I don't want to budge on or, in my mind, it's no longer worth pursuing. Things like using a real 65XX processor as the main processor is one of them.

With that said, it sounds like the W65C02SXB might not be a great option if it's one of those "it works, but no one knows why" confusing messes. I did see a post on Putnam Electronics from last year saying they found a box of unpopulated PE6502 PCBs so I could reach out and see if any are still available and buy the parts myself or see if they're still selling completed PE6502s.

On the related topic of learning assembly, and anticipated difficulties with mnemonics, I'd suggest that your best bet is to dive in. Trying to fit assembly into your C brain isn't going to be as satisfying as building an assembly brain, as it were. It'd be like trying to learn a foreign language by using a dictionary, and missing out on aspects of word order and idiom. There's a lot of idiom in 6502 programming.

The recent nearby topic
New to 6502-Got a book, but what next?
might be helpful - there I recommend the easy6502 tutorial.

See also an older topic
Best way to start learning 6502 Assembler
where you'll find a neat diagram by Bob Sander-Cederlof.

That is most amusing! And sad.

I've spent a lot of time and effort on your proposed project, explaining details, accounting for your skill level, the impossible budget, and the laws of physics. There is one flexible path that results in a 'trainer' immediately, and the specified device in days (or months at your skillset). The rest of the futures lead to, at best, a multi-year effort but much more likely, an abject failure (To use your analogy, folding a paper airplane and deciding you can build and fly -- and sell as a product -- a jet). That I do not wish for anyone.

It is absurd to suggest that I am selling the Tang Nano, or that you should reject a perfectly viable solution because you have a half-baked idea of how to do something you know nothing about.

My only reason was to suggest a practical way to accomplish what I though was your goal -- a hand-held, battery operated device, learning the ins and outs of the '02, hardware and firmware. But apparently I was wrong, and the goal is to occupy space and grasp for attention.

Discussion has became acrimonious, I don’t want to inject another approach that can be attacked. I’ll wait for another day.
Bill

Yes, from that base, a 6502 system that works with a C compiler which makes it straightforward to code assembly routines to be called from the C code can be a good way to get into assembly language, because you are only using the assembly language for one specific task at a time, and the rest of the scaffolding is in something you are more familiar with.

Under 80/20 Pareto conditions (80% of the time spent executing 20% of the code), that approach lets you get better performance than the C-alone approach even if only 10% or 20% of the code is in low level assembly routines.

(Now, since I used K&R C for a brute force maximum entropy estimator in my dissertation, C has always felt "like working" to me, so I tend to use it as little as possible for hobbyist programming, but that's about my project preferences, not somebody else's.)

As far as developing a non-traditional Assembly language syntax, the best rational for that I have seen is the Forth 6502 postfix assembler, which is compact enough that back in the day I would include it in most of my SuperForth64 dictionary images "just in case" I wanted to code a primitive ... but similar to other 1970's "maximum bang for the byte" solutions (eg, Woz's wonderfully spaghetti coded Sweet16 VM), it's at the expense of obscurity, and given enough dictionary space, I feel a nagging urge to work out an alternative which looks more like conventional 6502 assembly language.

One main thing when learning an assembly language is that using an obscure syntax makes it much harder to learn from existing examples of good code.
____________ Quite. IIRC, part of the reason this is 6502.org rather than 6501.org is that a court agreed with Motorola about the 6501 chip in the 6501-6505 range crossing over the borrowing/purloining line, so it was the 6502 that was on the market as "the least expensive Micro CPU" processor competing against the 6800 family and the 8080/Z80 family.

Same here. Kind of like Blockbuster refusing to buy Netflix for $50 million in '97. Had they purchased Netflix however, they would have destroyed it. Would there be a 6502 or anything like it had Motorola owned that tech? Probably not.

Yes, there's another "alternative history" that extends from that ... but I would be nervous that they would "IBM PCjr" their "budget" CPU offering, for fear of cannibalizing their higher margin version ... even though in the real world they ended up not being able to defend those high margins after all.

Just catching up with a few things....

If you go down the W65C02EDU route it's entirely possible you might be the only person in the world to actually own and use one. The 65C02SXB? There are a few out there, but do your research.... Might be an easy entry though.

Many years ago I made my own W65C02 SBC(s) (and '816 versions). It might fit your needs without a display, but they do use a GAL (could probably use a current in-production Atmel/Microchip version if I ever had a programmer for them). It can run assembly code (naturally) but I also wrote an operating system that would let me run some Acornsoft ROMs like BBC Basic, Comal, BCPL and so on. I also developed some libraries and support code to let me compile C programs using cc65 and run them on the board. There is no on-board graphics, but there is a high speed serial line.

This, for example is a C program running on the board displaying on a "smart" terminal on my Linux desktop (turn sound down - sorry)

https://www.youtube.com/watch?v=rPGCT0lah4Q

So while the 6502 isn't the best target for C, it's certainly possible and there are newer C compilers for it than cc65 if you want to dive deeper - there is an experimental LLVM and another called VBCC which may well be worth looking at. Expect to roll your own libraries and IO routines though.

Back you your requirements - a display - the easiest might be to use a VIA to give you a parallel interface. I do it that way for the character LCDs on my systems - not sure about a pixel display - 96x64 isn't one I'm familiar with but I did once interface a 128x64 display to a Raspberry Pi using the parallel interface - worked well. Just write the code to keep a local framebuffer in RAM then have an 'update' routine to copy RAM to the display and off you go. You could be clever and just update the regions that change, but that's more work.

SPI and I²C need more work - SPI is easy though, I²C requires changing the IO direction of the data pin to complete a transaction and being able to read the clock pin too if you want to interface to a device which implements clock stretching. You can bit-bang either though - at the expense of cpu cycles - dedicated hardware for either is possible which I think the W65C02EDU uses.

As for having access to the CPU bus - not hard to provide an edge connector, but at higher speeds things start to get interesting. Your old 1 and 2Mhz systems were relatively easy - 8Mhz should be possible with care, but I'd not like to take it faster. I opted for a more general purpose "peripheral bus" approach on my systems - basically the output of a VIA.

But I'm sorry to say that if you don't like assembly then you're going to find it hard - you will need to tailor some stuff to your system - or get someone else to do it for you - e.g. if I were to publish my designs then you'd be emailing me daily for software, patches, updates and so on and that's why I don't support open source any more.

Here's another idea - spend a little more and get an Apple II. (or a //e) It has everything you need including video output. There is even a target for cc65 for it and it has slots with the CPU, etc. bus for anything you need. You may need to recap the PSU but most are still working well and you get a system ready to go - even without disk drives they are usable if you can get a serial card for it.

Hope you get something going and do let us know how you're getting on.

-Gordon