The Sorbus concept looks simple. A 6502 CPU, a RP2040 controlling it and a backplane.
It delivers a 6502 system running at a clock speed of about 1 MHz.
On the software side there is much happening. Here some notes written by SvOlli
Meta mode
Pressing CTRL ] brings up the socalled meta mode.
Notes On Implementation in RP2040 Multicore Architecture
Core 0 runs the console and handles user interaction. Core 1 drives the bus for the CPU implementing the system. To have a rather efficient (fast as in ~1MHz) system, core 1 really has to come up with some tricks. So, every “event” aspect, such as timers, watchdog and other things will be run by an event queue. This means on every clock cycle there is a check if something was scheduled for this specific clock cycle. Again due to performance, only one event will happen during that clock cycle. If two events are scheduled for the same clock cycle, the second one scheduled will be delay by one clock cycle (and again until there is a free slot). The size of the queue is 32 event. This should be sufficiant, as there are not much things that could add to the event queue, and in most cases, a new event from the same source replaces the old one.
However: again due to performance the queue is not thread safe! So only core 1 is allowed to interact with it.
Core 0 on the other hand is allowed to do two things on the hardware side:
pull the RDY line low (to stop the CPU) and back high (to let the CPU continue)
pull the RESET line to low (but not back to high again), this may be only done if the RDY line is high, or immediately pulled high after the reset line was pulled low (immediately = in the next code line!)
If core 1 should want to use the RDY line for some reason, this should be implemented using “queue_uart_write” with characters > 0xFF. For performance/latency reasons it also does pull RDY low itself as well.
CPU Detection Routine
The Sorbus Computer can run any kind of 6502 variant that shares the same pinout. The small test and learn environment “Monitor Command Prompt” or MCP for short (pun very intended) can be used to learn all the details about each CPU up to a certain degree. (Not all pins are connected due to a limit amount of 30 GPIO pins of the RP2040.)
However, it is interesting to know which CPU the system is running on. The “Native Core” is the one with the most features, but does uses opcodes and features that are not available or buggy on an (old) NMOS 6502. This means that a 65C02 or any other CMOS variant is required. So, it should be a good idea to detect that CPU and print an error message that the system won’t work with one installed.
Also, there is another point where a CPU detection is very handy. If you search for cheap 65C02 processors, you typically find offerings on ebay or AliExpress for WDC W65C02S processors. However, none of those are original ones, but all of those are pulled out of machines, and then get relabeled. (At least the ones I’ve seen so far.) For this project using those would not be that bad, if they would not throw in NMOS 6502s in the mix as well. Those, as explained above, don’t fit the requirements.
Heree the source of the routine.
Read the rest of the notes on SvOlii’s github page.
