You can touch it. See it. Marvel at the hugeness of something doing so little (compared to modern stuff).

That has appeal to some - including myself. That's why I have a real 65816 (and real VIA, RAM) in my Ruby system, even though it's fronted by an ATmega 1280p doing the filing system and serial and that's fronted by a few 1000 lines of C using the SDL libraries to display a nice high resolution colour display with USB keyboard and mouse on my Linux desktop.

Here are 2 examples:

some nice circles - program written in C compiled with cc65: (turn sound off - it's buzzing - sorry)

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

Calculate Pi and run 12 clocks - demonstrate multi-tasking all in BCPL:

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

In both these instances, the code is running directly on a real 6502/65816.

Could I do that with a pure 6502/65816 system? Yes, but it would be hugely complex to include the video hardware. For me, it's more about the code on the CPU than the actual hardware.

But I appreciate that for some it's all about the hardware and that's fine.

-Gordon

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

(FYI, it's an RP2040 microcontroller, more like a Pico, if anything, and not in any way a Pi, but that's not crucially important. It's a very interesting chip and very well documented.)

The RP2040 is (most probably) acting as a bunch of peripherals and memory on the bus. In particular, it isn't driving the address bus.

Even logically, a real 65C02 driving a bus is going to differ from almost all emulations and other implementations, in that the cycle by cycle activity will probably differ from a real one. And electrically, it's the real deal, so it has 65C02-like setup and hold constraints, and clock-to-Q times. The behaviour of RDY and BE is going to be precisely C02-like because it is a C02.

So in various ways, a real C02 is more authentic, more accurate, than an alternative. There's plenty of scope for alternatives - there are many such implementations, from TTL to CPLD to FPGA and in emulation on various microcontrollers. But this isn't an alternative project, it's the project which it is. And it will appeal to certain people precisely because it's compact, it's packaged, it's tested, it's affordable, and it has a real C02 on it.

If we don't have one already, a new thread on what the differences are between different kinds of projects would be - or could be - a valuable resource, rather than ping-ponging in a thread which concerns a particular project. I'm fairly sure I've previously expressed the opinion that an exposed 6502 bus is a particular kind of feature which distinguishes projects which have it from those which don't.

Well, that's a somewhat different way of going at it, though, and rather more attractive to me. In particular:


Using an MCU as essentially a video peripheral (with maybe a couple of other peripherals thrown in) isn't very different at all from what was done on systems in the '80s that used custom chips to do video.


Sorry, yes; I was talking too quickly and using shorthand. I should have said "MCU."


Well, and supplying the clock and, in particular, doing the address decoding. Moving the address decoding into something like that can make it quite difficult to add new devices to the system, though perhaps this particular one reserves some address space for that, and has some free select lines that it generates when that address space is selected. And that's my biggest complaint about systems like this.

I'd be interested in hearing the details of how the exposed system bus connector can be used in this system.


I thought we had fairly accurate emulations at this point. But perhaps not.

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

Fairly accurate, yes. (I feel we're splitting hairs at this point!)

There is a project showing that the RP2040 is actually capable of generating a DVI/HDMI video signal, at VGA and even HD (after raising core voltage) output resolutions, with a bunch of resources remaining free (including one of the two cores being completely free), albeit after overclocking it by ~2x.

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

It is really an interesting board. $30 is hard to beat but RP2040 overclocked to 200MHz+ to interface to 16MHz 65C02 seems a rather brute force approach. A more relaxed approach may be a 25MHz 65C02 SBC in 3"x4" format with text VGA, PS2 keyboard, UEXT (UART, I2C, SPI), CF disk and RC6502 expansion bus and run DOS/65. Instead of 200MHz RP2040, this may be possible with a modest 5V CPLD and a dual port RAM. $30 is probably not achievable since W65C02 by itself is already $10.
Bill

I'm not clear which which direction you're trying to go here. Are you trying to reduce costs, in which case the $0.70 RP2040 is the way to go? Or are you trying to use a much less powerful CPLD instead, in which case you replace the RP2040 with, say, a $10 XC9572XL plus a few dollars more for the RAM?

It's a good point that the W65C02, at $10, is by far the largest chunk of the BOM. Drop that and just emulate it on the RP2040 and you should be down to $5 or so, a substantial chunk of which is just having a PCB big enough to bring out the system bus and the I/O connectors. (An RP2040 board with 2 MB flash that just brings 40 pins out to pads on .1" centres runs about $2 on AliExpress).

I personally find the fully emulated version (assuming we can get reasonably accurate emulation of it) rather attractive because, though it removes a substantial chunk of the retrocomputing element, it maintains a little bit of it and it's so damn cheap. For less than $10, why not have an extra little toy, especially when it can also be emulating 6800, 6809 and Z80? In fact, it ought to be able to emulate at least a few actual systems, such as the Apple II, Sinclair ZX81, and so on.

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

I think I may be right in saying that no-one has yet put a cycle accurate and accurately paced 6502 emulator on a microcontroller. Understandably there's more emphasis on high performance than on accurate pacing, and more emphasis on accurate behaviour than on cycle accuracy. Getting the behaviour right for the accidental reads in the intermediate cycles would be much work for so little benefit, and I'm not aware of any test suite for those either (other than correctly running some very convoluted copy protection schemes). And yet, a real 65C02 shows you those reads, as they happen, and even allow you to demonstrate some useful or annoying side-effects. A real 'C02 allows you to experiment with RDY and ABORT.

Anyhow this thread might be of interest and contain useful pointers:
6502 emulation: looking for microcontroller recommendations

Edit: by the way, in the Olimex product (prototype) the RP2040 controls the 'C02's clock, which allows for the possibility of speed switching - for example, up to 16MHz for performance or down to 1MHz (or something precisely different from that) to match some historical system. It also allows for the possibility of single-cycle or single-instruction operation, although I don't know if that would be planned. I do expect the eventual RP2040 firmware for this project to be open source and therefore open to extension and enhancement. Exciting!

Edit: not everyone here on this forum is fully familiar with the differences between the programmer's model of the 02 family, the specified reads and writes caused by the instruction-by-instruction behaviour, the cycle-by-cycle behaviour of the bus, the nanosecond-by-nanosecond interplay of inputs, clocks, and outputs, and the internal mechanisms which give rise to that behaviour. A possible starting point is this thread and the pointers within:
Help in understanding what happens each cycle

Retro processors are accurately simulated in modern workstation with freely downloaded software; for a few dollars Pi can also simulated many processors; for a few more dollars, FPGA can emulated many major retro processors, but if we really want to work with physical processors of previous century and explore design approaches of those days then cost rises, performance drops and design efforts increases. In the ‘80 and ‘90, PLD was the cost saving solution to TTL glue logic of ‘70 era. Thus processor+CPLD represents the first phase of cost-saving evolution of retro processors. That is the era of retro computers I grew up professionally and most interested in revisiting. Possibly I’m also influenced by the piles of programmable logic devices and old processors that I’ve salvaged from e-waste or purchased in large lots from auctions. For me “retro computers” are really “salvaged computers”; the challenge is designing and building new computers from recycled components of unknown provenance. The new off-the-shelf W65C02 is an exception but an interesting exception because it is so much faster, it really stretches the design approaches of retro computer era.
Bill

Quite so - for me, running an in-browser emulation on a chromebook is wonderful and effectively free. Very nearly cycle accurate too. And quite a few home computers of the 80s are accessible this way.

But.

I think "accurately" is where it hinges, for me. (For most cases, I'm sure, the main point of the Olimex will be $30 for a 6502 computer, and for some, the point will be $30 for a real-6502 computer, and for a few, the point will be $30 for a 6502 computer with a 6502 expansion bus.)

But for me, "accurately" includes the sequence of reads and writes, the nanosecond level of clock-to-Q timings, the nanosecond level of setup times for RDY and ABORT.

Even without nanosecond considerations, even in cycle-by-cycle considerations, a 'C02 that you can single-cycle and understand interrupts and vector fetches, where you can see exactly what an indexed indirect instruction or an indexed read modify write instruction does, that's something which could be interesting and is much much much more accessible when someone else builds the hardware for you.

There's accurate, and then there's accurate!

(It's quite possible the eventual price will not be $30!)

I just noticed we have a thread here about the MCL65+, a 6502 emulator running on a Teensy 4.1 (ARM Cortex-M7 at 600 MHz). It's accurate enough to a real 6502 to replace the CPU in a VIC-20. So it sounds to me as if emulating the 6502 as well as the rest of the system is not really such a problem.

I'm not sure why RDY and BE would be any harder to emulate than any of the other parts of the 65C02.

And many of the comments seem to have focused on it being cheap relative to other boards (which is a perfectly fair design goal); emulating the 6502 instead of using a real one would probably reduce the BOM price by more than half. I think you could then sell it profitably for $15 to $20.

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

It feels to me like I keep saying "there is value in this project and it has some interesting aspects" and you keep saying "this project should be this other thing." I'm really not finding that to be an enjoyable discussion.

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

I see Mouser will carry Neo6502. It has 4 Neo6502 on order for $32.63 each.
Bill