EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: aiq25 on July 24, 2020, 09:39:45 pm
-
Hi. I want to learn about 8 and 16 bit microprocessors but all of the ones I can find seem to be programmed using assembly language.
Are there any microprocessors that can be programmed using C (embedded) programming language?
Edit (some clarifications): I would like to build a retro computer using modern IC’s that’s why I’m looking for a 8 or 16 bit MPU specifically. I would like an MPU that can run program code from the external memory.
This project is for fun. I would like to get back into more embedded projects and programming. I like C programming. I never enjoyed assembly language.
-
Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler. Many MCU families have more than one C compiler to choose from.
You must be doing something wrong in your search or simply giving up when you see mention of an assembly language instruction set.
Edit: I misread the O.P's question. However everything above is equally applicable to MPUs.
-
Can you name a few that you were looking at? I would really struggle to find something without C support. Some are more limited than the others, but even 3 cent Padauk MCUs have some sort of C-like high level language (although arguably they don't really need it).
-
Thanks for the responses. I don’t think I was clear in my original post.
I’m not looking for an microcontroller but rather microprocessors (like Z80) with external RAM/ROM.
I have used Microchip PIC16, PIC18 and NXP S12G but they don’t have external RAM or ROM.
One of the reason I’m looking for an MPU is I want to build a retro computer but using a modern IC with C language support.
-
There are a lot of devices that have more embedded Flash/SRAM than any small computers ever had on the board.
But even if you take most Cortex-M7 devices, they would have interface to external memories that typically can support NOR flash and SRAM. SDRAM is also often supported.
Some less powerful devices will have external memory interface too.
There is not anything like Z80 though. Those devices would make no sense in a modern world. So you would have to adapt to what is available.
Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.
-
Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.
-
The 68000 and derivatives were one of the initial targets of gcc. And the Intel x86 chips.
Z80, 6502, and 6809 all have C compilers.
I'm afraid I haven't kept track of which 8/16 bit pure "microprocessors" have survived. You can find microcontrollers that support external memory buses... (be careful whether they can execute code from the external memory. For example, the larger AVRs can have external data memory, but can't run code from data memory. Most 8051 derivatives can support both external data and external program memory. Usually at significant performance penalty...
-
There are a lot of devices that have more embedded Flash/SRAM than any small computers ever had on the board.
But even if you take most Cortex-M7 devices, they would have interface to external memories that typically can support NOR flash and SRAM. SDRAM is also often supported.
Some less powerful devices will have external memory interface too.
There is not anything like Z80 though. Those devices would make no sense in a modern world. So you would have to adapt to what is available.
Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.
I have looked at 32-bit devices but wanted to use an 8 or 16 bit device.
This is only for fun and for me to get back into doing more embedded projects and programming.
-
Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.
I would like to use external program memory, easy to test out new codes.
-
You'd really have to look at some family that's totally obsolete or really exotic to find something that doesn't support C. Heck, even the Novix NC4016 native FORTH MPU (https://en.wikichip.org/wiki/novix/nc4016) had a C compiler.
Therefore it comes down to finding a MPU, or a MCU that can execute code from external RAM, that's preferably still in production, or at least cheap and readily available as N.O.S, has an affordable toolchain, is in a package you can work with as a hobbyist without too much hassle and doesn't need too much support hardware for a minimal system. There's also the possibility of running a soft-core implementation of a popular MPU in a FPGA. The problem isn't finding one, as there are more than most people can hope to master in their lifetime, its finding one you like!
Incidentally, the Z80 has evolved into the Zilog eZ80 (https://www.zilog.com/index.php?option=com_product&task=product&businessLine=1&id=77&parent_id=77&Itemid=57) family which is still Z80 instruction set compatible, and is still in active production.
-
I would like to use external program memory, easy to test out new codes.
These days In System Programming is faster than taking an EEPROM out, flashing it, and putting it back.
-
Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.
I would like to use external program memory, easy to test out new codes.
I don't understand why you say or think that. Why do you think so?
Insisting on supporting external ROM and SRAM -- let alone DRAM -- is far more expensive and lower performance than SRAM internal to the chip, at least for the 64 KB possible on an 8/16 bit CPU with 16 bit addresses, because of the large number of package pins needed (24 plus some control).
There are C compilers available for everything, although on older 8 bit designs such as the PIC, 8051, 6502, or Z80 compiled code is necessarily much bigger and slower than hand-written code. Also compilers for those funky ISAs are so different from anything modern that they can't be supported (or well supported) in gcc or llvm so their compilers tend to be much less sophisticated. On the other hand the AVR is a good target for C, as of course are 6809, 8086, 68000, msp430
-
This is only for fun and for me to get back into doing more embedded projects and programming.
I would argue that it is more fun to work with 32-bit devices. You are intentionally creating friction and all sorts of possible issues that are not related to actually programming things.
And yes, the argument that is is easier with external memory is completely invalid. It is much harder to work with external memories.
I feel like you are not up to speed on modern MCUs. Get some chap STM board and play with the existing board to see how it all works before building your own.
-
You can build one of these: https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer(or it's predecessor, or the followon V20-based board.)
It's runs near-standard CP/M, supports native BASIC, Pascal, Assembler, and Modula2, and has available SDCC and other languages) via cross-compilation. There was LOTS of CP/M software that should run on this, and much of it is still online (thanks to the US Army!)
-
For any kind of retro computing without something concrete in mind it's hard to give some decent advice.
Recently I had a peek at the book
"STM32_Beginning_Developing_with_FreeRTOS_libopencm3_and_GCC.pdf"
And sure, it's Arm Cortex M3, but it's C (or C++ if you like).
The smaller 8-bitters tend to have a very limited amount of RAM, and can not execute code from it. While this thing can run code from RAM. But I have a better reason for mentioning this book. It has a whole section devoted to "overlays". Which is a technique to load functions from external storage into RAM to execute them. This used to be popular in the old days when RAM in PC's was very limited.
An 8-bitter that can rode from RAM, and has a C compiler is the Cypress CY7C68013A. It is used in all the cheap Sigrok/Pulseview Logic Analyzers, and you can use the "FX2LAFW" firmware as a starting point for your own experiments.
On hackaday a lot of articles have been written about retro computing. Lots of Z80 boards, but the 68000 also seems to be popular.
But what aspect of "retro computing" attracts you so?
For me it mostly equals lots of separate chips, which translate to lots of soldering and big expensive PCB's. Also lots of opportunity to make hardware errors.
Apparently you do not know yet which processor you want to use. I also find it strange that you can only "find assembly". C compilers have been available for nearly any platform since the 80's.
-
Programming the Z80 in C is pretty straightforward. First you build up a development machine running the CP/M operating system and then you install BDS C. The output would be native code.
https://www.bdsoft.com/resources/bdsc.html (https://www.bdsoft.com/resources/bdsc.html)
I have a couple of these systems (I see there is an Arcade blog):
https://rc2014.co.uk/ (https://rc2014.co.uk/)
Based on the number of kits they sell, they must have a source for real Z80 chips. There are thousands of 40 pin PDIP devices in stock at DigiKey. Apparently, Zilog is still making them.
I also have a Zilog EZ80 development board running CP/M and all its friends at 50 MHz - that system just screams! I built a daughter card to provide the Compact Flash disk system and UART->USB serial ports.
Those are 8 bit solutions running all 8 bit software.
When I wanted to build PacMan, I used an FPGA board to run the T80 (Z80 workalike) core from OpenCores.org and I found the ROM images in the MAME CDs. I used the Digilent Nexys 2 board (now obsolete) and built an add-on card to deal with breaking out the audio, video and controls. Search around for things like 'arcade' 'retro arcade' 'fpga arcade' and so on.
-
Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler. Many MCU families have more than one C compiler to choose from.
Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.
Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.
I'd be curious to hear about other examples.
-
Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler. Many MCU families have more than one C compiler to choose from.
Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.
Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.
I'd be curious to hear about other examples.
It's interesting to think (as a compiler writer) what would prevent something from running C reasonably efficiently.
Severe lack of RAM, but it has to be really severe. You can write C programs on a 512 byte ATTiny85 no problems, or even its smaller sisters the 45 and 25, to the extent that you can write anything on them at all.
You need a way to load literals. You need bitwise boolean operations. NAND or NOR would be enough. You need addition. (Synthesizing from bitwise is too slow because you have to ripple carries). You need conditional branch based on zero / not zero. You need a right shift. You need at least 16 bit arithmetic (the preceding is sufficient to synthesize it from smaller units)
On a von Neumann architecture (which I'll define as one where you can run code from RAM) you can cover up many of the following sins with self-modifying code, at reduced but still reasonable efficiency. By definition a Turing machine (which is effectively a restricted form of a Harvard architecture, as the FSM is fixed) can compute anything, but it can be extremely inefficient.
You need pointers to arbitrary RAM addressees, and to add integers to pointers and subtract pointers, and to be able to load and store via these pointers.
You need to be able to call subroutines, and return from them. You need to have arbitrary (or at least large) return stack depth, or be able to access the return address easily and manipulate it as data. You need to be able to call subroutines via pointer, though not arbitrary pointer. Note on a Harvard architecture these can be a different kind of pointer than data pointers.
-
Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)
You might have a hard time finding c compiler that support romable code for some of the old 8bit chips. A cp/m compiler would usually assume run-from-Ram.
-
You might have a hard time finding c compiler that support romable code for some of the old 8bit chips. A cp/m compiler would usually assume run-from-Ram.
A given compiler might or might not support it, but I don't think there's any obstacle or performance hit for 8080/z80 or 6502. There might be for older chips.
If I was to write a compiler for those things now I'd generate very different (and more efficient) code than was done at the time. Especially if I could use gcc or llvm and run the compiler on a modern host. But even with a simple non-optimizing compiler running on the target itself the code could be much better now.
-
Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)
OTOH Hi-Tech PICC and its successor Microchip XC8 quite happily support programming the PIC10F200 in C, and that chip has similar limitations, with only 16 bytes of general purpose registers. That pretty much points the finger at it either being a GCC issue, or just lack of interest by the AVR-GCC developers in targeting minimal ATtinys due to the poor return for the effort involved.
-
Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.
Hear, hear !!!
-
Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)
OTOH Hi-Tech PICC and its successor Microchip XC8 quite happily support programming the PIC10F200 in C, and that chip has similar limitations, with only 16 bytes of general purpose registers. That pretty much points the finger at it either being a GCC issue, or just lack of interest by the AVR-GCC developers in targeting minimal ATtinys due to the poor return for the effort involved.
16 bytes of registers/memory, 256 instructions (er .. I think? 384 bytes and I think 12 bit opcodes?), 2 level subroutine return stack. Any programs will certainly be small!
-
I have programmed the PIC10F202 in C,and it certainly works.As there are no interrupts CCP or anything like that just for fun I wrote a PWM generator using the one and only timer(the duty cycle and frequency were hardcoded ofcourse).
This took around a third of its resources if memory serves me correctly :)
-
You can build one of these: https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer(or (https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer(or) it's predecessor, or the followon V20-based board.)
It's runs near-standard CP/M, supports native BASIC, Pascal, Assembler, and Modula2, and has available SDCC and other languages) via cross-compilation. There was LOTS of CP/M software that should run on this, and much of it is still online (thanks to the US Army!)
Thanks. I think I will start with something like this.
Programming the Z80 in C is pretty straightforward. First you build up a development machine running the CP/M operating system and then you install BDS C. The output would be native code.
https://www.bdsoft.com/resources/bdsc.html (https://www.bdsoft.com/resources/bdsc.html)
I have a couple of these systems (I see there is an Arcade blog):
https://rc2014.co.uk/ (https://rc2014.co.uk/)
Based on the number of kits they sell, they must have a source for real Z80 chips. There are thousands of 40 pin PDIP devices in stock at DigiKey. Apparently, Zilog is still making them.
I also have a Zilog EZ80 development board running CP/M and all its friends at 50 MHz - that system just screams! I built a daughter card to provide the Compact Flash disk system and UART->USB serial ports.
Those are 8 bit solutions running all 8 bit software.
When I wanted to build PacMan, I used an FPGA board to run the T80 (Z80 workalike) core from OpenCores.org and I found the ROM images in the MAME CDs. I used the Digilent Nexys 2 board (now obsolete) and built an add-on card to deal with breaking out the audio, video and controls. Search around for things like 'arcade' 'retro arcade' 'fpga arcade' and so on.
Thanks. Will look into this as an option.
Also thank you for all the others who have commented on this thread. Although I understand the limitations of 8-bit and 16-bit MCU's, these are the MCU's I started programming in. I would like to get back into programming by using something that I am familiar with. I know 32-bit dev boards now a days are very cheap and available from various sources. Someday I will move onto 32-bit MCU's but for now I think I will stick with 8 and 16 bit devices. The limitations of these devices is what should make it fun to work with. Also, I want to build a "modern" retro computer and I feel like using a 32-bit MCU will take away from that.
-
The limitations of these devices is what should make it fun to work with.
It isn't fun, when all you have is three 8 bit registers and 256 bytes of stack. You're a masochist :-)
-
For any kind of retro computing without something concrete in mind it's hard to give some decent advice.
Recently I had a peek at the book
"STM32_Beginning_Developing_with_FreeRTOS_libopencm3_and_GCC.pdf"
And sure, it's Arm Cortex M3, but it's C (or C++ if you like).
The smaller 8-bitters tend to have a very limited amount of RAM, and can not execute code from it. While this thing can run code from RAM. But I have a better reason for mentioning this book. It has a whole section devoted to "overlays". Which is a technique to load functions from external storage into RAM to execute them. This used to be popular in the old days when RAM in PC's was very limited.
An 8-bitter that can rode from RAM, and has a C compiler is the Cypress CY7C68013A. It is used in all the cheap Sigrok/Pulseview Logic Analyzers, and you can use the "FX2LAFW" firmware as a starting point for your own experiments.
On hackaday a lot of articles have been written about retro computing. Lots of Z80 boards, but the 68000 also seems to be popular.
But what aspect of "retro computing" attracts you so?
For me it mostly equals lots of separate chips, which translate to lots of soldering and big expensive PCB's. Also lots of opportunity to make hardware errors.
Thanks for the suggestion. I will definitely look into this as well. I do like visually seeing all of the separate IC's for different functions and I also like assembling big PCB's (it feels relaxing) but I wanted to start with something that would be easier to work with. The best part of retro computing that attracts me is seeing all the cool projects and SW you can write using such limited HW. Also I just like to work with retro technology in general. I was born in the '90's so I never got to experience true retro 8-bit computers and in general would just like to build something on my own. It's been a while since I programmed an 8-bit MCU from scratch (excluding Arduino because now a days with all the example code and the Arduino IDE it's very easy to program something).
Apparently you do not know yet which processor you want to use. I also find it strange that you can only "find assembly". C compilers have been available for nearly any platform since the 80's.
I was wrong in my initial statement. What I meant was I saw a lot of articles on how assembly language was much more efficient than C compilers for MPU's like the Z80. That's why I was more so looking for an MPU that was as efficient using a C compiler.
-
Hi. I want to learn about 8 and 16 bit microprocessors but all of the ones I can find seem to be programmed using assembly language.
Are there any microprocessors that can be programmed using C (embedded) programming language?
Edit (some clarifications): I would like to build a retro computer using modern IC’s that’s why I’m looking for a 8 or 16 bit MPU specifically. I would like an MPU that can run program code from the external memory.
This project is for fun. I would like to get back into more embedded projects and programming. I like C programming. I never enjoyed assembly language.
If not already mentioned, consider the AVR Mega2560.
You can configure it to have, 32K of external address/data bus space, because it has so many pins, available.
It is 8 bit, and has an instruction set, somewhat similar, to early 8 bit processors.
It can go fairly fast, if you want, I'd have to look it up, but something like 16 MHz. (Compared to early 8 bit cpus, which only ran at 1 MHz, originally, 6502).
It is a modern and very available chip.
It has lots of built in peripheral I/O devices, a lot more than the usual arduino offerings.
Is a fully fledged arduino member, with the information sources and ready built boards/hardware availability.
But you can buy just the chip.
Quite a bit of onboard flash.
But another choice is the modern day 6502 versions, which can run at 14 MHz (instead of the usual 1 MHz), can optionally use an improved instruction set (old 6502 instruction set, still available, I think its boot options).
E.g. https://en.wikipedia.org/wiki/WDC_65C02
N.B. Different versions available, you choose.
At least one even in DIP 40 pin package, if you want.
Full external buses. Can't remember if multiplexed bus, probably is, if in 40 pin package, or some versions are multiplexed, I suspect.
List of cpus (WDC) here: https://en.wikipedia.org/wiki/Western_Design_Center
WDC65C816, is optionally switchable between being an 8 bit cpu, and a 16 bit one. Yet it is 6502 based, but much faster and more capable, if you want.
https://en.wikipedia.org/wiki/WDC_65C816
Or go old school, and get a 20 MHz capable, old style Z80 cpu. (I.e. instead of the old 4 MHz ones, they later came out at up to 20 MHz). If that is not fast enough, there are the Z180's (later still EZ80's already mentioned in thread).
-
Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler. Many MCU families have more than one C compiler to choose from.
Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.
Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.
I'd be curious to hear about other examples.
It's interesting to think (as a compiler writer) what would prevent something from running C reasonably efficiently.
Well, define "efficiently" ;)
I guess it's mostly in terms of how much machine code would be needed for a given C construct. If the number of registers and arithmetic operations is very limited, both execution time and code size could be a major problem, especially if on top of it the amount of data and code memory are also very limited.
One thing that would be a severe problem for a C compiler if missing (I guess it would even make it impossible) is indirect addressing. Right now, I can't think of/remember a CPU that doesn't have indirect addressing, but I guess that may exist. Even if indirect addressing is supported, some CPUs may not support indirect calls, which would also make some C features very inefficient, or impossible to implement.
Beyond technical feasibility, there may be other reasons why a C compiler wouldn't be available for some CPU. The CPU architecture could be so odd that writing a full C compiler for it, or a back-end for an existing one, could be a very tough endeavor that the vendor is not ready/able to take - and if on top of it, said CPU has limited performance and memory, the vendor may decide that just providing an assembler instead would be much easier and make more sense.
Taking the Padauk example again, I haven't worked with them, but for those who have, what is, in your opinion, the main reason why they didn't provide a complete C compiler, but some kind of simplified C instead?
-
Dave made the Padauk popular, and then some conglomerate of smart guys ported SDCC to it. Though I'm not sure how those 2 are inter connected with all things.
The Propeller chip has long been exempt from a C compiler, because it's such a weird chip. It was only programmable in a language called "spin". I'm not sure if there is a C compiler for it now. I lost interest in the thing.
For some niche applications some 4-bit uC's have been made for a long time, and there is probably no C compiler for those. Last time I checked though, even my toothbrush has an MPS430.
-
Apparently you do not know yet which processor you want to use. I also find it strange that you can only "find assembly". C compilers have been available for nearly any platform since the 80's.
I was wrong in my initial statement. What I meant was I saw a lot of articles on how assembly language was much more efficient than C compilers for MPU's like the Z80. That's why I was more so looking for an MPU that was as efficient using a C compiler.
Ok. "C is not possible" and "C is not as efficient as assembly language" are very different things. Most 8 bit microprocessors are very difficult to write an efficient C compiler for, including Z80 and 6502.
The first microprocessors which were ok for C (or Pascal) are the M6809 and the Intel 8088. Although one is described as an 8 bit processor and one as a 16 bit their capabilities are actually extremely similar. They both still suffer from a lack of registers. The 8088 comes out slightly ahead because of the availability of a version with a 16 bit data bus, and a hack to let it use between 64 KB and 1 MB of memory with somewhat awkward programming. The M6809 is limited to 64 KB without external bank-switching hardware (which admittedly makes it not much worse than the 8088 to actually program).
The first microprocessors which were really C-friendly were the M68000, ARM, and MIPS (all of which are also, coincidentally, 32 bit).
-
The first microprocessors which were really C-friendly were the M68000, ARM, and MIPS (all of which are also, coincidentally, 32 bit).
You're forgetting the LSI-11 though that wasn't a single chip.
Also around the same era as the 68k was the Z8000 which ran a port or workalike of Unix. IIRC the architecture was decent.
-
Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler. Many MCU families have more than one C compiler to choose from.
Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.
Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.
I'd be curious to hear about other examples.
It's interesting to think (as a compiler writer) what would prevent something from running C reasonably efficiently.
Well, define "efficiently" ;)
I'd generally say that any missing feature should be able to be simulated with fewer than maybe 10 instructions of straight-line code. And preferably missing features should be things that are not required toooo frequently in practice.
Overall performance of compiled code should be within about a factor of two or three of the best hand-written assembly language, not 10x or 100x.
I guess it's mostly in terms of how much machine code would be needed for a given C construct. If the number of registers and arithmetic operations is very limited, both execution time and code size could be a major problem, especially if on top of it the amount of data and code memory are also very limited.
Code size expansion can always be limited by calling subroutines (relatively small execution speed penalty) or bytecode (indirect threading) or direct threading. The bytecode interpreter in Apple (UCSD) Pascal was reasonably usable for a full environment with editor and compiler on a 1 MHz 6502, despite the bytecodes being generic and not at all tuned to the 6502. Woz's "SWEET16" provided much more efficient bytecode execution that could be interleaved with native 6502 code and still look near optimal today. Woz claimed a 10x slowdown for bytecode.
I've got a compilation scheme for 6502 that allows using all 256 bytes of Zero Page as "registers" to hold C local variables and function arguments and globals, with 16 bit and 32 bit operations such as "Rn = Rm" or "Rn += Rm" or "Rn *= Rm" coded in at most 7 bytes (fewer if the previous operation used the same Rn or Rm, so quite often 5 bytes). 16 bit add or subtract take about 2x as long as inlined code (which needs 13 bytes). 32 bit add and subtract only take 1.5x as long as the 25 bytes of code needed if done inline.
I think this is a pretty good compromise with very similar code size to UCSD P-system or Java JVM bytecode, but many times faster in execution speed.
I may have to find time to implement it one day :-)
One thing that would be a severe problem for a C compiler if missing (I guess it would even make it impossible) is indirect addressing. Right now, I can't think of/remember a CPU that doesn't have indirect addressing, but I guess that may exist. Even if indirect addressing is supported, some CPUs may not support indirect calls, which would also make some C features very inefficient, or impossible to implement.
I mention both of those explicitly in the message you replied to. (pointers and calls through pointers)
Beyond technical feasibility, there may be other reasons why a C compiler wouldn't be available for some CPU. The CPU architecture could be so odd that writing a full C compiler for it, or a back-end for an existing one, could be a very tough endeavor that the vendor is not ready/able to take - and if on top of it, said CPU has limited performance and memory, the vendor may decide that just providing an assembler instead would be much easier and make more sense.
My message was about *what* would make an architecture odd. I think I covered most of it.
One thing I didn't mention is the architectures based around a "current page" such as PIC and PDP8. That's annoying but can be worked around provided you can put fully general pointers in the current page and indirect via them.
Taking the Padauk example again, I haven't worked with them, but for those who have, what is, in your opinion, the main reason why they didn't provide a complete C compiler, but some kind of simplified C instead?
It's a while since I looked at the Paduak documentation, but I seem to recall it was very similar in design to 8 bit PIC.
-
The first microprocessors which were really C-friendly were the M68000, ARM, and MIPS (all of which are also, coincidentally, 32 bit).
You're forgetting the LSI-11 though that wasn't a single chip.
Also around the same era as the 68k was the Z8000 which ran a port or workalike of Unix. IIRC the architecture was decent.
I don't forget it at all.
I used (and maintained and helped develop compilers for) the PDP 11/34 and 11/70 but I've never in my life seen an LSI-11 machine. I bet most people haven't. It came out about the same time as the 68k but was both less capable and much more expensive.
The PDP-11/LSI-11 is just slightly better than the M6809 or 8088 in that all 8 registers are 16 bit. Except it's more like 7 registers because the PC is a general register. The addressing modes are very similar. 68k and z8000 (which I also helped write a compiler for) have 16 registers, similar to VAX and ARM (and AMD64, 25 years later).
-
The LSI 11 came out in 1975 and predated my exposure to Unix. I programmed for RT-11 on it. So it was already around when the 6809 came out.
NS also made a 32000 processor but that has disappeared into history.
-
The LSI 11 came out in 1975 and predated my exposure to Unix. I programmed for RT-11 on it. So it was already around when the 6809 came out.
NS also made a 32000 processor but that has disappeared into history.
I used an Unix emulator (Eunice) on VAX/VMS but my first real Unix was on a Zilog System 8000 (with Z8000 chip). Which is why I was part of a team writing a Modula-2 compiler for it and the VAX.
We also evaluated the NS 32016 at the same time, but it was less capable. As I recall the promised 32032 looked much better but was late.
-
I'm quite fond of the Motorola 68K architecture, and specifically the 68008, which while being a full 16/32 bit 68000 internally, is externally a cut-down 8 bit bus variant, that's no harder to implement than any other 8 bit CPU, and is easier than many. The only fly in the ointment is its limited address space - the DIP package 68008 can only access one megabyte because its only got 20 address lines. Its PLCC package brings out two additional lines for a four megabyte address space.
Here's a 68008 on a breadboard running uCLinux: http://www.bigmessowires.com/68-katy/ (http://www.bigmessowires.com/68-katy/)
Although the Motorola 68008 is no longer in production, PDIP package 'pulls' or N.O.S. are still fairly easy to obtain at a reasonable price.
-
I'm quite fond of the Motorola 68K architecture, and specifically the 68008, which while being a full 16/32 bit 68000 internally, is externally a cut-down 8 bit bus variant, that's no harder to implement than any other 8 bit CPU, and is easier than many. The only fly in the ointment is its limited address space - the DIP package 68008 can only access one megabyte because its only got 20 address lines. Its PLCC package brings out two additional lines for a four megabyte address space.
Here's a 68008 on a breadboard running uCLinux: http://www.bigmessowires.com/68-katy/ (http://www.bigmessowires.com/68-katy/)
Although the Motorola 68008 is no longer in production, PDIP package 'pulls' or N.O.S. are still fairly easy to obtain at a reasonable price.
If I understand it correctly, this ColdFire processor sells for $16 one-off, runs at 250 MHz, has 64 KB of internal RAM and an external bus for ROM + SDRAM with 32 address lines and 8 data lines. https://www.nxp.com/docs/en/data-sheet/MCF54418.pdf (https://www.nxp.com/docs/en/data-sheet/MCF54418.pdf)
The instruction set differences between 68008 and ColdFire are pretty minimal -- some missing instructions and addressing modes, but I think ColdFire programs would run on 68008?
There are no PDIP packages, but you can get cheap breakout boards to convert LQFP to DIP.
-
Except it's more like 7 registers because the PC is a general register.
Only in the sense that the same addressing modes apply to R7 but turn out to be something relevant to PC operations. You couldn't use another register as the PC. For example load immediate was actually load indirect r7 with postincrement, skipping the constant. As you know there was no dedicated SP, but usually R6 was used. In the context of Unix R0 and R1 were usually used for intermediate and function results and R5 was usually the frame pointer so that left 3 registers for locals. You would know about the now ignored register keyword in C. But the indirect with offset modes were perfectly suited to C stack variables. Also I have always wondered if the PDP-11 architecture inspired the increment and decrement operators.
R&T estimated that using C for Unix incurred an overhead of about 20% code size compared to assembler. That's why I regard the PDP-11 as an excellent target. The as manual in V7 Unix was subtitled The ultimate dead language. To this day, my approach is C first if available, throwing in a bit more memory and speed if necessary, and the crucial or unavoidable parts in assembler.
As for Padauk's C compiler they probably didn't expect the typical customer to write anything complicated. The IDE supplies blocks of prefabricated code you can paste in. But of course the OSS Padauk developers have bigger plans for it.
-
Except it's more like 7 registers because the PC is a general register.
Only in the sense that the same addressing modes apply to R7 but turn out to be something relevant to PC operations. You couldn't use another register as the PC. For example load immediate was actually load indirect r7 with postincrement, skipping the constant.
My point is that you have r0..r7 but r7 isn't a useful register because you can't store some random variable into it -- doing so would jump to that address.
In contrast even r6 is usable as a temporary variable inside a function, as long as you restore the old contents before anything that tries to access the stack.
As you know there was no dedicated SP, but usually R6 was used. In the context of Unix R0 and R1 were usually used for intermediate and function results and R5 was usually the frame pointer so that left 3 registers for locals.
Not quite right. Certain instructions *did* assume r6 was the stack pointer, in particular JSR and RTS. You could save the subroutine return address in any register, but its old value was pushed on the r6 stack (and popped by RTS)
R&T estimated that using C for Unix incurred an overhead of about 20% code size compared to assembler. That's why I regard the PDP-11 as an excellent target.
It's not that I don't consider the PDP-11 to be an excellent target for C (relative to assembly language) -- it's that I don't consider the LSI-11 to be a microprocessor in the way the 68k is. The LSI-11 used 4 chips and cost $3000 (in the form of a PDP-11/03 with zero RAM and peripherals). The J-11 was the first proper PDP-11 microprocessor, in around 1980, by which time it had serious competition at much lower prices.
-
it's that I don't consider the LSI-11 to be a microprocessor in the way the 68k is.
Ok, fair enough. But there are lots of places where lines can be drawn: one chip, affordable to some class of user, affordable for some application areas, etc.
-
The first microprocessors which were really C-friendly were the M68000, ARM, and MIPS
Sparc and PPC, too...
I've never in my life seen an LSI-11 machine. I bet most people haven't. It came out about the same time as the 68k but was both less capable and much more expensive.
You're probably thinking about the DEC T-11 (https://en.wikipedia.org/wiki/DEC_T-11), which was a single-chip implementation of the PDP11. and came out in ~1982. The LSI-11 itself came out much earlier (originally a 4 to 5 chip set.)The T11 was apparently aimed at embedded use - wp says it was used in disk controllers and similar. It was cute; one of the first chips with 'clever" support for DRAM by using a multiplexed address bus that did even/odd bits rather than high/low.
The HeathKit H-11 personal computer used an LSI-11 (NOT the T11), and wasn't horrendously expensive.The DEC Pro-3xx series of personal computer was based on the F-11 and J-11 single-package (multi-chip, though) LSI implementation.
DEC, alas, didn't know how to sell either chips or personal computers, and the H11 quickly more expensive when you had to add any reasonable peripherals (QBus!), so none of those caught on.
-
The Propeller chip has long been exempt from a C compiler, because it's such a weird chip. It was only programmable in a language called "spin". I'm not sure if there is a C compiler for it now. I lost interest in the thing.
There has been a C compiler for the Propeller for about 10 years. I think SPIN, assembly and C can all be used together.
-
The first microprocessors which were really C-friendly were the M68000, ARM, and MIPS
Sparc and PPC, too...
And PA-RISC and ... yup. Though PPC was 10 to 15 years after the others (POWER earlier of course).
I've never in my life seen an LSI-11 machine. I bet most people haven't. It came out about the same time as the 68k but was both less capable and much more expensive.
You're probably thinking about the DEC T-11 (https://en.wikipedia.org/wiki/DEC_T-11), which was a single-chip implementation of the PDP11. and came out in ~1982. The LSI-11 itself came out much earlier (originally a 4 to 5 chip set.)
I guess it's kind of interleaved. LSI-11 in 1975, 8086 in 1978, M68k in 1989, the J-11, F-11, T-11 from 1980 on.
By the time they came out, PDP-11 just wasn't *interesting* unless you had legacy software to run.
The HeathKit H-11 personal computer used an LSI-11 (NOT the T11), and wasn't horrendously expensive.
Good point. Do you know the price.
There was a time when I was *gagging* to buy a personal PDP-11 at a reasonable price. But then the PC/AT and Mac/Amiga/ST came out and it was ... whyyyyy?
-
You're probably thinking about the DEC T-11 (https://en.wikipedia.org/wiki/DEC_T-11), which was a single-chip implementation of the PDP11. and came out in ~1982.
Or, maybe, about 1801VMx (https://en.wikipedia.org/wiki/1801_series_CPU) CPUs. ;)
-
Math is improving very fast, and the whole computer science is a subset of math; thus I am afraid it will be *RARE* in 2030 to find CPUs and MPUs still in production that are supported by a C compiler.
I *strongly* disagree.
While more and more things are being done using vector/matrix processors and GPUs those are additions to the scalar C world, not replacements for it.
Every parallel task is mixed in with scalar work. As Gene Amdahl famously observed, if you have a task that is 99% parallelizable and 1% scalar then the maximum speedup you can get with an infinitely parallel machine is 100x. If you want more than that then you need to make the scalar part go faster. And you have to minimize the overhead of the scalar and parallel parts talking to each other (this is one place GPUs really fall down).
Also see Tony Hoare in 1982: “I don't know what the language of the year 2000 will look like, but I know it will be called Fortran.”
Unusual for C.A.R. Hoare to be short-sighted. And since C got "restrict" (and C++ template containers and algorithms) there is no advantage to FORTRAN over C/C++. But he's essentially right. (and people do still use FORTRAN on supercomputers a lot)
-
By the way. Has anyone mentioned an 8OD (http://tech.mattmillman.com/projects/8od/), 8086 based and CPLD assisted SBC yet? And retroshields (http://www.8bitforce.com/projects/retroshield/) for Arduino Mega.
-
Math is improving very fast,
Really? In what respect?
-
As Gene Amdahl famously observed, if you have a task that is 99% parallelizable
You haven't got the point.
CPUs are going with multiple cores with a lot of built-in vector processing, but in order to use them efficiently, we need "something" to distributes processes across them, and this is actually one of the more difficult things in writing concurrent applications because it is not enough to just spread things into many processes, you actually have to make sure that these processes actually run concurrently, which means rethinking your algorithms, and can be difficult (sometimes very very difficult, practically impossible) with the current state of art of programming languages like C.
Now, since most programmers don't derives any gratification from their own pain or humiliation, "rethinking algorithms" points into the direction of "functional programming", and not because "researching new things is so damn cool" but rather because it has already demonstrated by facts that it can simplify by several order of magnitude the programming of things that actually run concurrently.
Less or equal effort, better results!
I'm a big fan of functional programming, and have been ever since I read FORTRAN inventor John Backus' 1977 Turing Award lecture "Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs". Which I read in, like, 1981 or something. I read Guy Steele's 1976-1979 series of papers "Lambda: The Ultimate Imperative", "Lambda: The Ultimate Declarative", "Lambda: The Ultimate GOTO", "Lambda: The Ultimate Opcode" soon after. And have re-read them a number of times since.
Saying that people will switch to using functional languages by 2030 (which I've been hearing since the early 80s) is possible (though dubious) but is not at all the same thing as your claim that their machines will not have or not be capable of having C compilers.
People have been designing specialized computers optimized for Lisp, Smalltalk, Prolog and others since ... again ... the 1980s. What has happened every single time (so far)? It turns out that their functional language actually runs faster on a "general purpose" machine built for C and FORTRAN. Why? Partly because people implementing functional languages on standard hardware have been pretty ingenious. But mostly because there is so much competition and money spent on standard computers that they improve in performance faster.
-
your claim that their machines will not have or not be capable of having C compilers.
I wrote that C will be very inefficient for future machines, therefore likely not used simply because it would not likely be a commercial success.
You wrote the very straightforward and plain words "I am afraid it will be *RARE* in 2030 to find CPUs and MPUs still in production that are supported by a C compiler".
Which, I contend, is simply implausible given the history of the last 75 years of computing.
I also disagree with your later claim that C will be inefficient on future machines (because, by Amdahl's law, this will make them slow on real world parallel tasks), but let's be clear that is a different and much weaker claim in the first place.
The new research processors is on enough high-level parallelism where you can suspend the threads that are waiting for data from memory and fill your execution units with instructions from others, which is very efficient and flexible enough even for tensor processing ... just the problem with such designs is that C programs tend to have few busy threads.
You are now switching from a speed argument to a throughput argument.
There are machines designed to run C programs that do exactly this already. Intel hyperthreading, obviously, in a small way, or xCORE microcontrollers.
Anyway, we are far from the topic of this thread. You've given your opinion, I've given mine, we're just boring everyone else. I'm out.
-
Just thought my opinion was interesting. Wasn't it? Ok. I'm out too.
You seem to have rather strong opinions, and ideas of the way, computers are going to be, in the future. Which would appear (at a quick glance), to be in contradiction. To what I believe, many other people would think.
You might be right, but you seem to be able to very rapidly jump to conclusions, about the future of computing, on rather odd, ideas about computer things.
E.g. Someone might see an interesting new development, in AI projects, which flashes some leds, in an interesting and cool manor. All by itself, without any human help, to give it some interesting patterns.
They shouldn't really, after watching it flash for 45 seconds, pronounce that all of mathematics is going to very rapidly, and dramatically change. All computers, by 2030, will have to use this new processing algorithm. Hence the C language will almost totally disappear, and not even run on almost any processor or computer, by 2030.
Etc etc.
This someone can say that, but it doesn't mean it is correct, or likely to happen, or even possible, if you properly analyse the evidence/situation.
I.e. The AI flashing the leds, is nice and fun. But those 45 seconds they spent watching it, usually doesn't change the future of mathematics, computer science, processor design, etc. Within the next 10 years.
There are exceptions, such as the day (various dates), when Transistors, Integrated Circuits, Microprocessors, etc etc. Were invented. Those did change things, to an extent, over a fairly long period of time.
-
If not already mentioned, consider the AVR Mega2560.
You can configure it to have, 32K of external address/data bus space, because it has so many pins, available.
It is 8 bit, and has an instruction set, somewhat similar, to early 8 bit processors.
It can go fairly fast, if you want, I'd have to look it up, but something like 16 MHz. (Compared to early 8 bit cpus, which only ran at 1 MHz, originally, 6502).
It is a modern and very available chip.
It has lots of built in peripheral I/O devices, a lot more than the usual arduino offerings.
Is a fully fledged arduino member, with the information sources and ready built boards/hardware availability.
But you can buy just the chip.
Quite a bit of onboard flash.
I did consider this but the ATXMEGA384C3 seems to be cheaper that's why I was considering it. But the additional I/O pins of the 2560 is attractive. 2560 Arduino is easy to find and might be a good starting point, so I think I will have to reconsider this.
-
If not already mentioned, consider the AVR Mega2560.
You can configure it to have, 32K of external address/data bus space, because it has so many pins, available.
Ohhh .. I hadn't realized that! And I own a few of them. Really should read the datasheet :-)
How it works:
- you can actually add a 64K external SRAM, of which 56832 bytes (55.5K) can actually be used. The external SRAM starts at address 8704 (0x2200), immediately after the 8K of internal SRAM.
- of course it's not necessarily SRAM, it could be ROM, device registers, or whatever you want to add.
- accessing external SRAM takes 1 clock cycle per byte more than internal (plus any needed wait states). If you put the stack there then subroutine and interrupt calls and returns take 3 cycles longer (for 3 PC bytes).
- pins AD0..AD7 (Arduino pins 22..29) are multiplexed as both the data bus and the low 8 bits of the external address. Need an external latch such as 74HC573 (74AHC573 above 8 MHz) to demultiplex the bus
- pins A8..A15 (Arduino pins 30..37 but in reverse order) are the high bits of the address. If not all are needed for the amount of SRAM you can configure the unneeded bits as normal I/O by setting the low three bits of XMCRB (0x75) to a nonzero value e.g. setting it to 1 will release PC7 as a normal I/O pin, setting it to 6 will release PC2, PC3, PC4, PC5, PC6, PC7 as normal I/O pins etc.
- the address presented on the external bus is the actual address used by the program, so addresses in the first 8.5K of address space are never presented externally. This means the first 8.5K of a 64K SRAM is inaccessable (unless you use one weird trick involving manipulating the port bits manually -- taking more instructions and time and programming complexity -- see below). If a 32K SRAM is used then the first 8.5K can be accessed at addresses from 32K to 40.5K because the CPU knows it's an external address but the 15 bit address will wrap back to the start of the SRAM. And so on for smaller SRAMs: as long as the SRAM size is a power of 2 the whole SRAM can be used and you'll get a contiguous RAM address space (starting at 0x200) but the usage inside the SRAM will wrap (for SRAMs larger than 0.5K).
- the data bus and lower 8 bits of the address bus use port A. The upper 8 bits of the address use port C
- if you use XMCRB to disable some high bits of A8..A15 (at least 2) then you can set the remaining bits of port C manually (as normal I/O bits) to the high bits of the desired address in the actual SRAM, and only the low bits of the address in the program's pointer will be output. Thus you can access the entire SRAM, but only in a selected 256 byte to 16K window at a time. Ugh.
But, you can get up to 55.5 KB of contiguous RAM that uses completely normal compiler-generated code and C pointers!
-
If not already mentioned, consider the AVR Mega2560.
You can configure it to have, 32K of external address/data bus space, because it has so many pins, available.
Ohhh .. I hadn't realized that! And I own a few of them. Really should read the datasheet :-)
A very nice post. I hope you don't mind me adding to it, a bit.
The Arduino's 2K of ram, 8K on the Mega2560 (I know there are later Arduino's with considerably more, e.g. Arm, but those are not 'original' Arduino's as such).
So, the original Arduino's, have a rather tiny amount of ram. But, your project might have started out on it, with good intentions, and you thought it would easily fit, and at first it diid.
Then feature creep or expansion of what you want to do, can easily exceed such small amounts of ram (especially the 2K).
So, there use to be a 32K ram expansion board, that you could buy. But I heard they stopped selling it.
Not sure if the following link is the same or a different version:
https://hackaday.io/project/21561-arduino-mega-2560-32kb-ram-shield (https://hackaday.io/project/21561-arduino-mega-2560-32kb-ram-shield)
But anyway, you can still buy, relatively blank, I/O shields for the Arduino Mega2560's, for not much money (a few dollars, if I remember correctly), from China. Which should allow you to build up your own 32K (or partial 64K, see nice post about it above this one) board on it.
Which can then have whatever you want to do with the available address space. E.g. EPROMS, more sram, etc etc.
Don't get too hanged up about the extra memory cycle (or more if wait states are used). Because if you were concerned about speed, you wouldn't be using an 8 bit AVR 16 MHz.
It would probably be a hundreds of megahertz 32 bit arm, or > GHz Raspberry PI 4, etc.
The cool feature of the 8 bit AVR 16 MHz, is that it is genuinely slow enough to just about count as a vintage (like), old school cpu, combined with an 8 bit instruction set, which wouldn't look too out of place, if it came from the 1970s or 1980s.
All the built in I/O blocks and functions, allows for a relatively compact, not too many ICs, neat retro, vintage like machine. Which is ready, to add low cost (Chinese) I/O boards, for experiments and fun.
E.g. Fairly affordably, you can buy Chinese complete electronics kits, with the Mega2560, and an eye-wateringly big array, of fun, pre-built gadgets, to play with it. N.B. They sometimes get big sale discounts, and other buying mediums, can sell stuff like that cheaper.
E.g. https://www.amazon.co.uk/ELEGOO-Mega2560-Complete-Ultimate-controller/dp/B01IUZK3JO (https://www.amazon.co.uk/ELEGOO-Mega2560-Complete-Ultimate-controller/dp/B01IUZK3JO)
https://www.amazon.co.uk/ELEGOO-Upgraded-Tutorial-Compatible-MEGA2560/dp/B01M3TOXZN (https://www.amazon.co.uk/ELEGOO-Upgraded-Tutorial-Compatible-MEGA2560/dp/B01M3TOXZN)
-
You can configure [atmega2560] to have, 32K of external address/data bus space
Not for storing instructions, though/
https://www.rugged-circuits.com/new-products/quadram (https://www.rugged-circuits.com/new-products/quadram)
XMEGA chips support up to 16MB of external RAM (as well as it can be supported by an 8bit architecture with "natively 16bit" addresses. Bank registers. Eww!) The ATXMEGAA1U Xplained Pro Eval board (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/ATXMEGAA1U-XPRO) has an Xmega with 512k bytes of external RAM...
There are some harsh facts, though:
- These chips, by themselves, are more expensive that newer, faster, ARM or PIC32 chips with much more internal RAM (and the ability to execute from RAM.)
- Using them with external RAM is outside of "normal." You will need to reconfigure the linker scripts and possibly the compiler, and the amount of help and example code you can expect to find "on the web" is small.
I always figured that when I need to start messing with banking registers, it's time for a different (probably 32bit) architecture.
-
So, there use to be a 32K ram expansion board, that you could buy. But I heard they stopped selling it.
Not sure if the following link is the same or a different version:
https://hackaday.io/project/21561-arduino-mega-2560-32kb-ram-shield (https://hackaday.io/project/21561-arduino-mega-2560-32kb-ram-shield)
Yup. And there are exactly two active components on that board: the actual SRAM, and a SN74AHC373.
Weirdly, their examples address the SRAM as 0x8000 to 0xFFFF. Sure, that works, but it means you have to modify your programs to use it explicitly instead of using it as contiguous with the built in RAM, as 0x2200 to 0xA1FF. It's all the same to the board, as 0x2200 to 0x7FFF is the same bytes in the SRAM as 0xA200 to 0xFFFF.
But anyway, you can still buy, relatively blank, I/O shields for the Arduino Mega2560's, for not much money (a few dollars, if I remember correctly), from China. Which should allow you to build up your own 32K (or partial 64K, see nice post about it above this one) board on it.
Sure. I use nice Australian-made (or at least designed) ones: https://www.freetronics.com.au/products/protoshield-mega (https://www.freetronics.com.au/products/protoshield-mega)
Last time I got some they were available off the shelf in Jaycar here in NZ (and I assume in Aussie).
The cool feature of the 8 bit AVR 16 MHz, is that it is genuinely slow enough to just about count as a vintage (like), old school cpu, combined with an 8 bit instruction set, which wouldn't look too out of place, if it came from the 1970s or 1980s.
I think it's probably fast enough to *emulate* a 1 MHz 6502. It must be very close. I might try it.
With this, you could add enough memory to actually emulate a 32K Apple ][.
-
There are some harsh facts, though:
- These chips, by themselves, are more expensive that newer, faster, ARM or PIC32 chips with much more internal RAM (and the ability to execute from RAM.)
- Using them with external RAM is outside of "normal." You will need to reconfigure the linker scripts and possibly the compiler, and the amount of help and example code you can expect to find "on the web" is small.
I always figured that when I need to start messing with banking registers, it's time for a different (probably 32bit) architecture.
Well, yes.
A Teensy 4.0 has a 600 MHz dual-issue 32 bit CPU (around 900 MIPS), 2048K of flash, and 1024K of RAM, 40 digital pins (31 PWM), 14 analog inputs, all for $20.
Even Chinese Arduino Mega2560s cost $16 (I have ELEGOO). Genuine ones are $38. For 256K of flash and 8K of RAM.
-
You can configure [atmega2560] to have, 32K of external address/data bus space
Not for storing instructions, though/
https://www.rugged-circuits.com/new-products/quadram (https://www.rugged-circuits.com/new-products/quadram)
XMEGA chips support up to 16MB of external RAM (as well as it can be supported by an 8bit architecture with "natively 16bit" addresses. Bank registers. Eww!) The ATXMEGAA1U Xplained Pro Eval board (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/ATXMEGAA1U-XPRO) has an Xmega with 512k bytes of external RAM...
There are some harsh facts, though:
- These chips, by themselves, are more expensive that newer, faster, ARM or PIC32 chips with much more internal RAM (and the ability to execute from RAM.)
- Using them with external RAM is outside of "normal." You will need to reconfigure the linker scripts and possibly the compiler, and the amount of help and example code you can expect to find "on the web" is small.
I always figured that when I need to start messing with banking registers, it's time for a different (probably 32bit) architecture.
In a sense, or technically speaker, you are RIGHT!
But my viewpoint, is as follows.
You use a modern, powerful Arm processor, with its potentially, highly complicated peripheral set. Amazingly powerful peripherals, yes. But they can have 2,000 page manuals, which make for very heavy reading.
If you are doing something commercially, and being paid well to do it, and are part of a team, it can work out, reasonably well, or better.
There are also, various levels of library options, with their own pros and cons, which I won't go into here.
But for a quick hobby project, on your own, with limited time to do it, that is not such a good option.
You could go full vintage-retro build, and try to get the (now) somewhat rare peripheral chips, which went with that processor (Z80, 6502, etc), but e.g. ebay, is reportedly full of cheap, Chinese potential fakes, (poor) clones, used/poorly-unsoldered unknown if working/wrecked chips, etc.
If it is available from a western supplier, it still may have originated from suspect Chinese sources, also reputable suppliers, can charge quite a lot for the chips.
So, 10 such chips from a reliable supplier (genuine, new old stock), may cost £50 .. £150+, which is a lot.
So, it gives one, a way of having a genuine (non-emulated), fairly modern, Mega2560 peripheral set (fairly old school, 8 bit, quick/easy implementation, using your own code), with bigger external (Data only, not instructions, I think you are right, I'd forgotten, as I needed/wanted bigger dataspace, over the usual 2K/8K available).
You are right, such an 8 bit solution, is potentially more expensive than some of the 32 bit, considerably faster solutions. E.g. ST32 'clone' mini development boards, are only around £1.60+ each (delivered, if you shop around and buy a pack of 10 in one go).
Not that much more, if you only buy one at a a time, perhaps £1.75 + £1.10 = £3.
Not trying to offend you, but the speed thing is not especially relevant (if aiming for old retro vintage, slow type of computer). The idea is to make something, broadly similar to a 1MHz 6502 or 4 MHz Z80 system, so the (mostly) single cycle instruction execution time at 16 MHz, is actually something like 30x faster, than those old/original processors, and has many more registers.
If you want speed, then use a modern Raspberry PI 4, or fast PC, etc.
Analogy:
For a fun build, you splash out and buy an unbuilt, (probably way too expensive, rare and may not of been part of their range), complete Heathkit, classic Valve/Tube amplifier.
You then build it, and have great fun making it, testing it and using it.
Someone then comes and says, you just spent $1,000 (there seem to be ones you can buy these days, with 'modern' valves, which are fairly cheap, e.g. $10 .. $100) for a headphone (or speaker, if valve based) amplifier, when a $0.05 OP-AMP (headphone only, without extra stuff or power amp versions), would have done it. Much lower noise, massive bandwidth boost and better overall, and only needs 1 milliamp, at 3.3V, to operate. As opposed to 240V AC, 50 Watts.
I'd have to politely say to them, they are missing the point. (Fun with building old tube amplifiers etc).
There are of course, millions of other possible solutions. E.g. PICs. I have just covered one of them.
-
Really? In what respect?
Since Quantum Mechanics, the math is having more interests for Differential Algebraic, Tensor Algebra and etc.
Things used by the modern physic to describe new ideas, and the computer science reflects a part of his "new hype" with the deep learning AI.
For example, the Google Tensor processor uses rather modern math, both for training operators and so called "autonomous" machines; universities have new courses, and laboratories propose new challenges.
Just 20 years ago, if you had made a thesis on AI, you would have discusses a "lisp-based machine".
Ok, how does this preclude the use of C on the majority of applications that don't require such heavy maths?
-
Really? In what respect?
Since Quantum Mechanics, the math is having more interests for Differential Algebraic, Tensor Algebra and etc.
Things used by the modern physic to describe new ideas, and the computer science reflects a part of his "new hype" with the deep learning AI.
For example, the Google Tensor processor uses rather modern math, both for training operators and so called "autonomous" machines; universities have new courses, and laboratories propose new challenges.
Just 20 years ago, if you had made a thesis on AI, you would have discusses a "lisp-based machine".
Ok, how does this preclude the use of C on the majority of applications that don't require such heavy maths?
I dunno what that was all supposed to really mean.
Tensors are nothing new. And I don't see what would prevent you from using C to implement tensor algebra.
Actually there's a large number of recent C++ tensor libraries out there. Whereas C++ here is usually used to take advantage of templates and operator overloading, nothing prevents you from implementing the same in pure C. Maybe it'll look a bit less elegant. But the basics of tensor algebra, as far as numerical computation is involved, still uses pretty basic maths operators. This may all look pretty cool and fancy in a PhD thesis, because that may be kind of advanced from the theoretical POV, but from a computational POV there's nothing much to write home about IMHO.
If you're targetting a general-purpose CPU, there won't be much difference here, except style.
Now of course if you're targetting some kind of specialized CPU/coprocessor, then you ideally either need a language that natively supports that efficiently, or some kind of library (possibly less elegant and maybe a bit less efficient.)
But claiming you can't use C or another existing programming language to implement all those supposedly fancy very modern maths, that's kind of bullshit IMO. Now if the question is finding a language that will express that better and yield to better performance, why not (that's already different from saying it's impossible with C or whatever else), but then I'd be glad to see real-world examples with real figures to see if that really holds.
Now there's still the very general matter of parallelism, which is still not well supported by most programming languages out there. And yes, whereas some "modern maths" can benefit from parallelism, that's a very general issue in itself.
-
Isn't CUDA a sort of dialect of C?
-
Not trying to offend you, but the speed thing is not especially relevant (if aiming for old retro vintage, slow type of computer). The idea is to make something, broadly similar to a 1MHz 6502 or 4 MHz Z80 system, so the (mostly) single cycle instruction execution time at 16 MHz, is actually something like 30x faster, than those old/original processors, and has many more registers.
32x faster running NOP. Or INX, LDA # etc. But the average 6502 instruction execution time is probably at least 3 cycles -- the time to load / store / add / compare etc something from Zero Page. With roughly equal numbers of 4+ cycle instructions and 2 cycle instruction mixed in. So that makes 50x a better estimate. But also you need more instructions on 6502, even when dealing with 8 bit variables. If you've got more than 3 variables in a function and do A = B + C then you're looking at 2 instructions and 2 clock cycles on AVR (whether 8 bit or 16 bit) but 4 instructions and 11 clock cycles on 6502 for 8 bit and 7 instructions and 20 clock cycles for 16 bit. So you can easily start to see 5 to 10 times more clock cycles on 6502 than AVR before even taking the 16 MHz vs 1 MHz into account.
I reckon 100x would be a good estimate of the speed ratio for skillful hand-written assembly language, 200x for compiled C.
-
Isn't CUDA a sort of dialect of C?
No.
At least no more than JavaScript is, and I'd say less. They all use {} around blocks and = for assignment and similar operators and operator precedence but that's just the syntax level. The *meaning* is very different.
CUDA embeds functions that run on the GPU inside C programs, but those functions (marked by __global__) have very different rules and semantics to C, most obviously access to "variables" such as blockIdx, blockDim, and threadIdx that have not been declared anywhere in the program or header files. There are also many things that you can't do that you can do in normal C in the rest of the program.
-
Oh, sorry, I meant OpenCL not CUDA:
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html
-
Not trying to offend you, but the speed thing is not especially relevant (if aiming for old retro vintage, slow type of computer). The idea is to make something, broadly similar to a 1MHz 6502 or 4 MHz Z80 system, so the (mostly) single cycle instruction execution time at 16 MHz, is actually something like 30x faster, than those old/original processors, and has many more registers.
32x faster running NOP. Or INX, LDA # etc. But the average 6502 instruction execution time is probably at least 3 cycles -- the time to load / store / add / compare etc something from Zero Page. With roughly equal numbers of 4+ cycle instructions and 2 cycle instruction mixed in. So that makes 50x a better estimate. But also you need more instructions on 6502, even when dealing with 8 bit variables. If you've got more than 3 variables in a function and do A = B + C then you're looking at 2 instructions and 2 clock cycles on AVR (whether 8 bit or 16 bit) but 4 instructions and 11 clock cycles on 6502 for 8 bit and 7 instructions and 20 clock cycles for 16 bit. So you can easily start to see 5 to 10 times more clock cycles on 6502 than AVR before even taking the 16 MHz vs 1 MHz into account.
I reckon 100x would be a good estimate of the speed ratio for skillful hand-written assembly language, 200x for compiled C.
Attempting to use 'standard' units and independent from us, measurements. That would be the 'MIP' then. Because they are both 8 bit, the data size ambiguity, doesn't matter so much.
6502 = 0.430 MIPS at 1.000 MHz, source: https://en.wikipedia.org/wiki/Instructions_per_second
Mega2560 = up to 1 MIPS per MHz, i.e. an 8 MHz processor can achieve up to 8 MIPS = 16 MIPS (@ 16 MHz)
Source: https://en.wikipedia.org/wiki/AVR_microcontrollers
So that gives 16 / 0.430 = x37.21 times faster.
We could argue all day long, about how relevant/accurate, MIPS are today, we could also argue/adjust those figures I just supplied.
My x30, was only a very, very rough, ball park figure. x37.21, is not that different, from what I estimated.
There isn't really an answer as such. Because it varies so much, with what exactly you are trying to do (the program), how well (efficiently) it is implemented, and how good (if not assembler), the compilers are. There could be other factors as well, such as exactly how you measure it (e.g. what the test data is, some data patterns may favour one cpu, over the other, etc).
-
It isn't only the MIPS, it's that you've got only three (true) registers in the 6502 (ignore zero-page), and they're only 8 bits each, that's quite a handicap that makes simple things unnecessarily complicated, and too often turns one liners into a multi line register load-store-swap ugly mess.
-
Oh, sorry, I meant OpenCL not CUDA:
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html
Uh, yeah, I've been on a team at Samsung that wrote an OpenCL (and Vulkan) compiler for GPUs. I've heard of it :-) I didn't mention it because it's very little different in principle to CUDA. It's also much more restrictive than C despite, again, sharing the superficial syntax. As just one example, there are only string constants, not string variables. Recursion is not allowed. In fact it's normal for OpenCL compilers to inline all function calls into the parent kernel function so no actual function calls exist in the compiled code. Only strictly structured control flow is allowed (you can use "goto" to express it, but it must be "reducable" to fully structured flow).
-
Not trying to offend you, but the speed thing is not especially relevant (if aiming for old retro vintage, slow type of computer). The idea is to make something, broadly similar to a 1MHz 6502 or 4 MHz Z80 system, so the (mostly) single cycle instruction execution time at 16 MHz, is actually something like 30x faster, than those old/original processors, and has many more registers.
32x faster running NOP. Or INX, LDA # etc. But the average 6502 instruction execution time is probably at least 3 cycles -- the time to load / store / add / compare etc something from Zero Page. With roughly equal numbers of 4+ cycle instructions and 2 cycle instruction mixed in. So that makes 50x a better estimate. But also you need more instructions on 6502, even when dealing with 8 bit variables. If you've got more than 3 variables in a function and do A = B + C then you're looking at 2 instructions and 2 clock cycles on AVR (whether 8 bit or 16 bit) but 4 instructions and 11 clock cycles on 6502 for 8 bit and 7 instructions and 20 clock cycles for 16 bit. So you can easily start to see 5 to 10 times more clock cycles on 6502 than AVR before even taking the 16 MHz vs 1 MHz into account.
I reckon 100x would be a good estimate of the speed ratio for skillful hand-written assembly language, 200x for compiled C.
Attempting to use 'standard' units and independent from us, measurements. That would be the 'MIP' then. Because they are both 8 bit, the data size ambiguity, doesn't matter so much.
6502 = 0.430 MIPS at 1.000 MHz, source: https://en.wikipedia.org/wiki/Instructions_per_second (https://en.wikipedia.org/wiki/Instructions_per_second)
Mega2560 = up to 1 MIPS per MHz, i.e. an 8 MHz processor can achieve up to 8 MIPS = 16 MIPS (@ 16 MHz)
Source: https://en.wikipedia.org/wiki/AVR_microcontrollers (https://en.wikipedia.org/wiki/AVR_microcontrollers)
First off, MIPS is completely meaningless across CPU ISAs because instructions do vastly different amounts of actual useful work. As I already noted, what takes 1 or 2 instructions on AVR takes 4 instructions on 6502 even in 8 bit land.
The only thing that makes sense is the running time of benchmarks, preferably real programs that do work you actually want to do.
Note that the wikipedia page you points to is (mostly) not actually Millions of Instructions per Second, but relative speeds running the rather bogus but at least it's trying Dhrystone benchmark, in which the DEC VAX 11/780 is defined as 1.000. Some of the entries are actual MIPS not Dhrystone MIPS, which is completely ridiculous as they are not comparable.
I found this page: http://www.ecrostech.com/Other/Resources/Dhrystone.htm (http://www.ecrostech.com/Other/Resources/Dhrystone.htm)
An ATmega64 (64k flash, 4k SRAM) did 0.328 Dhrystone 2.1 MIPS/MHz, which would be 5.248 at 16 MHz.
According this this page: http://www.homebrewcpu.com/new_stuff.htm (http://www.homebrewcpu.com/new_stuff.htm)
A 1.023 MHz Apple ][ does 37 Dhrystones/second which is 0.021 DMIPS.
I've found other pages with similar figures e.g. https://news.ycombinator.com/item?id=11705631. (https://news.ycombinator.com/item?id=11705631.) I think it's probably about right for compiled C code.
0.328/0.021 = 16 MHz AVR 250 times faster than 1 MHz 6502.
That's on the Dhrystone benchmark, which is a pretty rubbish benchmark, but better than nothing. Coremark would be a lot better Dhrystone does a few different things, but a disproportionate amount of the score comes from a single (repeated) call to strcmp() where the first difference occurs after (IIRC) 18 bytes.
So that gives 16 / 0.430 = x37.21 times faster.
That's reasonably close to my estimate of 48x for the number of instructions per second, or indeed to your 30x. However it's not allowing for the different amount of useful work done by each instruction on very different instruction sets.
There isn't really an answer as such. Because it varies so much, with what exactly you are trying to do (the program), how well (efficiently) it is implemented, and how good (if not assembler), the compilers are. There could be other factors as well, such as exactly how you measure it (e.g. what the test data is, some data patterns may favour one cpu, over the other, etc).
I completely agree, but you should at least *try* to measure it using some more or less realistic or useful task, using typical programming languages, compilers, libraries etc.
As I said before, and I stand by it, 100x for carefully hand-written code, and 200x for compiled C code. (Dhrystone shows 250x)
-
It isn't only the MIPS, it's that you've got only three (true) registers in the 6502 (ignore zero-page), and they're only 8 bits each, that's quite a handicap that makes simple things unnecessarily complicated, and too often turns one liners into a multi line register load-store-swap ugly mess.
Exactly.
I think my saying the 6502 needs twice as many instructions as AVR, as well as three times more clock cycles per instruction, as well as 16x lower clock speed (i.e. 96x slower) is if anything being generous to my beloved old 6502.
-
As I said before, and I stand by it, 100x for carefully hand-written code, and 200x for compiled C code. (Dhrystone shows 250x)
In real life though, the 6502 can be, let's say x25 faster than the Mega2560, as regards hobby projects.
Assumptions:
The 6502 has hardware acceleration (video/sound), and is hand crafted machine code.
The Mega2560, no hardware enhancements, and all code runs via a poorly written Basic Interpreter, someone found, on the internet, for the Mega2560. Which is especially slow. (Not to be confused with cheating, to make a POINT on a forum, :P :P :P).
Here are a few examples:
You use a (old-era 6502, Based Home computer) Commodore 64 or Atari 800 (6502), or possibly other similar computer, available at the same time.
The hobby project, uses a simple, self-designed, memory-mapped video card, interfaced to the Mega2560.
But the old-era home computer, has hardware sprite chips, and sound chips, potentially, greatly speeding up games, from that era.
But the Mega2560, doesn't.
Also, you compare a 6502, era (time) correct Chess program, written by expert(s), in hand crafted machine code. With the hobbyists, Mega2560, Basic Interpreter's, version of a Chess program.
Again, the 6502, may have a x25 speed advantage.
Why 6502 x25 faster than Mega2560 ?
Consider an empty loop.
6502 1MHz, could do something like 200,000 (DEX, BNE = 2 + 3 cycles = 1E6/5=200,00) empty loops per second (hand crafted machine/assembly code).
https://www.masswerk.at/6502/6502_instruction_set.html#BNE (https://www.masswerk.at/6502/6502_instruction_set.html#BNE)
The Mega2560, in a not too well written, Basic Interpreter, might do 8,000 empty (For/Next) loops, per second.
Both, are MY estimates (e.g. the 8,000), and are extremely rough.
So, 200,000 / 8,000 = x25 advantage of 6502 over the Mega2560
tl;dr
Although the examples I just gave, are theoretically 'correct', maybe. I guess the point I'm trying to make, is that these things can end up being "How long is a piece of string", types of questions.
Arguably, the 6502 is not really suited for C compilers, so your x200, is really just a way of saying its architecture, is not well suited to C compilers. Whereas the Mega2560 (e.g. rich number of registers, and at least, a somewhat orthogonal instruction set), make it well suited to C compilers.
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
-
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
"runs at about one-tenth the speed of the equivalent native 6502 code", see?
It was removed very soon, with the AUTOSTART ROM, in 1978 (79?) IIRC. Not that anybody was using it anyways. The big loss if you ask me was the mini-assembler (F666G), also gone with that ROM "upgrade".
-
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
"runs at about one-tenth the speed of the equivalent native 6502 code", see?
It was removed very soon, with the AUTOSTART ROM, in 1978 (79?) IIRC. Not that anybody was using it anyways. The big loss if you ask me was the mini-assembler (F666G), also gone with that ROM "upgrade".
These days, processors are usually so fast, that a speed loss of /10 (or even /100), is not necessarily a big show stopper. Hence the popularity of relatively inefficient, scripting/interpreted languages, these days, such as Python.
But the 6502, was somewhat relatively slow and a bit weak, that such a speed loss (/10), would be quite devastating. Especially if it was on top of a Basic Interpreter, which already slows things down by a factor of x100 or even hundreds, compared to hand crafted, well optimised machine code (assembly language),
The thing that "speeded up", the 6502, was the fact that, because of the lack of hardware floating point (home computers, in general, at that time). Floating point took so long (on a typical 6502 1 MHz, or equivalent cpu, e.g. Z80), that the relative slowness of a Basic Interpreter, didn't really matter that much.
I.e If you were using floating point extensively/exclusively, anyway. Even a fast compiler will struggle, because the floating point bits, will still be relatively slow, on those old generation cpus.
-
In the beginning there was no floating point in the Apple ][, it came with the monitor, a 6502 mini-assembler, and Woz's Integer Basic. FP came later ("Applesoft") with the II Plus.
-
There was no floating point at all in the Apple ][, it came with the monitor, a 6502 mini-assembler, and Woz's Integer Basic. FP came years later ("Applesoft") with the II Plus.
I think, Apple was popular, and there were many of them, in the US, in that era. But, the UK, did not have many Apples, and they were not particularly popular, here (UK).
Checking up, here is a source:
The Apple II became one of several recognizable and successful computers during the 1980s and early 1990s, although this was mainly limited to the USA
https://en.wikipedia.org/wiki/Apple_II_series (https://en.wikipedia.org/wiki/Apple_II_series)
In the UK, most of the popular computers (and hence their basics), had floating point (software), as standard.
The original ZX81 (ZX80), didn't. So, then the (cheap at the time), £99.99 Sinclair ZX81, had floating point.
If I remember correctly, it was unbelievably fast. If you kept the screen on (display OFF, is considerably faster, but switches the vdu off, while you are doing calculations, as the Z80, was the VDU), it could do, something like 4 (maybe slightly more), empty For/Next loops (but which print out the For loop counter on the screen, that probably takes a while, as well), per second.
https://en.wikipedia.org/wiki/ZX81 (https://en.wikipedia.org/wiki/ZX81)
*****I DON'T BELIEVE THAT....
>>Try it for yourself, here:
http://www.zx81stuff.org.uk/zx81/jtyone.html (http://www.zx81stuff.org.uk/zx81/jtyone.html)
-
As I said before, and I stand by it, 100x for carefully hand-written code, and 200x for compiled C code. (Dhrystone shows 250x)
In real life though, the 6502 can be, let's say x25 faster than the Mega2560, as regards hobby projects.
Assumptions:
The 6502 has hardware acceleration (video/sound), and is hand crafted machine code.
The Mega2560, no hardware enhancements, and all code runs via a poorly written Basic Interpreter, someone found, on the internet, for the Mega2560. Which is especially slow. (Not to be confused with cheating, to make a POINT on a forum, :P :P :P).
Here are a few examples:
You use a (old-era 6502, Based Home computer) Commodore 64 or Atari 800 (6502), or possibly other similar computer, available at the same time.
The hobby project, uses a simple, self-designed, memory-mapped video card, interfaced to the Mega2560.
But the old-era home computer, has hardware sprite chips, and sound chips, potentially, greatly speeding up games, from that era.
But the Mega2560, doesn't.
You're getting very far from "the 6502 is faster here". You're at "a particular well equipped 6502 computer is faster than a particular poorly-equipped AVR computer".
In the real world of course all the AVR n00bs are using the Arduino IDE with C compiled optimized by the very good gcc compiler.
Also, you compare a 6502, era (time) correct Chess program, written by expert(s), in hand crafted machine code. With the hobbyists, Mega2560, Basic Interpreter's, version of a Chess program.
Again, the 6502, may have a x25 speed advantage.
I'm pretty sure I can write a 6502 emulator for the AVR which will run faster than a real 6502. Using that external SRAM interface.
Writing emulators, JITs and compilers is my job and specialty.
Arguably, the 6502 is not really suited for C compilers, so your x200, is really just a way of saying its architecture, is not well suited to C compilers. Whereas the Mega2560 (e.g. rich number of registers, and at least, a somewhat orthogonal instruction set), make it well suited to C compilers.
The 6502 is indeed not suited to any language that requires 16 or 32 bit variables. Or functions that are required to work if called recursively.
From memory, cc65 produces code that is 3 or 4 times slower than native code, and is huge as well. I have developed a compilation scheme for 6502 that results in near native speed for 8 bit code and 2x slower than native for 16 bit variables, and 1.5x slower than native for 32 bit variables, with 16 bit and 32 bit 2-operand operations (e.g. x = y; x += y, x == y etc) needing a maximum of 7 bytes of code and often 5.
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
I know SWEET16 very very well. I could just about rewrite it from memory, and certainly know its internals well. It's very close to being the absolute best possible you can do on the 6502 for very compact and yet quite fast code for 16 bit operations. It provides for 14 16 bit "registers" (after r0 the accumulator and r15 the PC are removed) in Zero Page memory. If A, and B are 16 bit variables in those registers then A += B needs 3 bytes of code and runs around 10x slower than native code.
The native code for the same 16 bit variables in Zero Page is 13 bytes of code and runs in 20 clock cycles.
SWEET16 is 3 bytes and around 200 clock cycles (I haven't checked exactly just now but it's around that)
My code generation scheme is 7 bytes and runs in 44 clock cycles. (ldx #REGA; ldy #REGB; jsr ADD16). X and Y are not modified by ADD16 so if the previous or next operations use A or B then those registers don't need to be reloaded.
The AVR code (ADD A_LO,B_LO; ADC A_HI, B_HI) takes 4 bytes and 2 clock cycles.
It's all trade-offs.
-
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
"runs at about one-tenth the speed of the equivalent native 6502 code", see?
It was removed very soon, with the AUTOSTART ROM, in 1978 (79?) IIRC. Not that anybody was using it anyways. The big loss if you ask me was the mini-assembler (F666G), also gone with that ROM "upgrade".
I liked and used SWEET16 and included a copy in my own programs. It was just over 300 bytes of code.
-
These days, processors are usually so fast, that a speed loss of /10 (or even /100), is not necessarily a big show stopper. Hence the popularity of relatively inefficient, scripting/interpreted languages, these days, such as Python.
Yes, Python and other similar languages are very very slow.
Javascript has become so important and critical that multiple organizations have invested huge money in analyzing and compiling it.
But the 6502, was somewhat relatively slow and a bit weak, that such a speed loss (/10), would be quite devastating. Especially if it was on top of a Basic Interpreter, which already slows things down by a factor of x100 or even hundreds, compared to hand crafted, well optimised machine code (assembly language),
I don't know how you'd get a speed loss of 10x ON TOP OF the speed loss of BASIC. I mean .. ok .. you could write a bytecode interpreter in BASIC.
SWEET16 is 10x slower than machine code, but it's probably at least 10x faster than Integer BASIC, which was itself several times faster than AppleSoft.
SWEET16 is also several times faster than the UCSD P-system bytecode interpreter (Apple Pascal), which was actually quite a usable system. It also made it much more natural and easy to write critical functions in assembly language and call them from Pascal.
The thing that "speeded up", the 6502, was the fact that, because of the lack of hardware floating point (home computers, in general, at that time). Floating point took so long (on a typical 6502 1 MHz, or equivalent cpu, e.g. Z80), that the relative slowness of a Basic Interpreter, didn't really matter that much.
True.
I think a floating point add probably took around 200 clock cycles.
Software floating point add, subtract, and multiply on the AVR take around 80 clock cycles each.
-
Which is partly why Sweet16, a semi-bytecode like 16 bit ALU, was created in/for the Apple, by Steve Wozniak. Which somewhat overcomes, the 6502's limitations.
https://en.wikipedia.org/wiki/SWEET16 (https://en.wikipedia.org/wiki/SWEET16)
"runs at about one-tenth the speed of the equivalent native 6502 code", see?
It was removed very soon, with the AUTOSTART ROM, in 1978 (79?) IIRC. Not that anybody was using it anyways. The big loss if you ask me was the mini-assembler (F666G), also gone with that ROM "upgrade".
I liked and used SWEET16 and included a copy in my own programs. It was just over 300 bytes of code.
More or less, what year was that?
At the time I didn't even know what it was for :-) (*) and shortly after the mini-assembler was gone, I had to buy me another one and got Mike Westerfield's ORCA/M, and learned to do lots of things with macros then.
(*) The red book had a listing, but in 1978 it was still too soon for me to understand what was the point.
-
You're getting very far from "the 6502 is faster here". You're at "a particular well equipped 6502 computer is faster than a particular poorly-equipped AVR computer".
Very true. I was being, ? something, factious, or whatever the right word(s), were/are.
In short, I was showing that if you contrive the situation enough, you can show any 'nonsense' (fake news), you want. I heard, statistics, is a good tool for doing it.
I'm pretty sure I can write a 6502 emulator for the AVR which will run faster than a real 6502. Using that external SRAM interface.
Writing emulators, JITs and compilers is my job and specialty.
I bet you could as well. Arguably, with some improvement (which was probably possible at the time). The odd extra register, here and there. Making some of the 8 bit registers, part/full time 16 bit, and making the instruction set more orthogonal. Would improve it, no end.
Accumulators A and B, 8 bit, A and B usable in one piece, as a 16 bit entity. X and Y index registers, but make them (and stack), full 16 bits. Maybe a C & D, 8/16 bit register set, as well.
More/better addressing modes. I guess I'm turning the 6502, into another 6809.
The 6502 is indeed not suited to any language that requires 16 or 32 bit variables. Or functions that are required to work if called recursively.
I consider it weak, even with 8 bit only values. Because the 256 byte range limit (in one go), as the index registers were only 8 bits, is a real pain, when you code in 6502, a lot.
My code generation scheme is 7 bytes and runs in 44 clock cycles. (ldx #REGA; ldy #REGB; jsr ADD16). X and Y are not modified by ADD16 so if the previous or next operations use A or B then those registers don't need to be reloaded.
That sounds very impressive, and clever.
By using the X/Y register pair, as 'pretend' accumulators A and B (the 6502's single accumulator, limits/hinders its assembly language). That is a neat trick.
-
I liked and used SWEET16 and included a copy in my own programs. It was just over 300 bytes of code.
More or less, what year was that?
While I was at university: 1981-1984.
At the time I didn't even know what it was for :-) (*) and shortly after the mini-assembler was gone, I had to buy me another one and got Mike Westerfield's ORCA/M, and learned to do lots of things with macros then.
(*) The red book had a listing, but in 1978 it was still too soon for me to understand what was the point.
The Apple ][ I had access to was a EuroPlus with AppleSoft ROMs. And had a green manual (which I still have). But the university library had the November 1977 BYTE magazine with the SWEET16 source code.
Early in my 2nd year we were studying 6502 machine code using an assembler on the VAX and Rockwell AIM65 kits in a lab. The lab was only available a few hours a day. One evening, frustrated at not being able to test my 6502 code, I wrote a 6502 emulator in VAX Pascal. Before I went home at 3 AM or so I sent an email about it to several friends so they could try it out. I came in the next afternoon to find about 50 people using it! Within a few days the lecturer said output from my emulator was acceptable for people's assignment submissions. There was only one bug: I'd got the sense of the carry flag reversed for the SBC instruction.
I also wrote a (very partial) VAX emulator for the Apple ][ (in assembly language) during the summer holidays. Don't even ask the execution speed :-) :-)
-
My code generation scheme is 7 bytes and runs in 44 clock cycles. (ldx #REGA; ldy #REGB; jsr ADD16). X and Y are not modified by ADD16 so if the previous or next operations use A or B then those registers don't need to be reloaded.
That sounds very impressive, and clever.
By using the X/Y register pair, as 'pretend' accumulators A and B (the 6502's single accumulator, limits/hinders its assembly language). That is a neat trick.
In this scheme, X and Y are not accumulators, but pointers to the accumulators, which are groups of 2 or 4 bytes located anywhere in Zero Page.
ADD16:
clc
lda $0000,y
adc $00,x
sta $00,x
lda $0001,y
adc $01,x
sta $01,x
rts
If variable A is in locations $05 and $06 and B is in locations $87 and $88 then you do A += B with:
ldx #$05
ldy #$87
jsr ADD16
You can have up to 128 such 16 bit variables or 64 32 bit variables.
ADD32:
clc
lda $0000,y
adc $00,x
sta $00,x
lda $0001,y
adc $01,x
sta $01,x
lda $0002,y
adc $02,x
sta $02,x
lda $0003,y
adc $03,x
sta $03,x
rts
-
But the 6502, was somewhat relatively slow and a bit weak, that such a speed loss (/10), would be quite devastating. Especially if it was on top of a Basic Interpreter, which already slows things down by a factor of x100 or even hundreds, compared to hand crafted, well optimised machine code (assembly language),
I don't know how you'd get a speed loss of 10x ON TOP OF the speed loss of BASIC. I mean .. ok .. you could write a bytecode interpreter in BASIC.
Well, let me give you an actual example. I can't remember the exact details, so take it as an example, but similar things really happened in practice.
A well selling calculator, gets released, quite some time ago, from a major manufacturer. It is a popular, very powerful, Programmable/Scientific calculator, with a huge number of built in functions, and lots of programs are written for it.
Some time later, the cpu becomes unavailable, much better ones are around. Then the calculator manufacturer, releases an updated version of the calculator, which really (semi-secretly), runs an emulator, on a modern chip, which then pretends to be the old/obsolete mpu/mcu.
Then even later (I'm not sure how many iterations, this has gone on for in practice ?), an even newer release of the calculator comes out, with a somewhat fast, modern Arm core on it. Which emulates the previous cpu, which itself then again, emulates an even older (original) cpu. In order to be the calculator.
Under absolutely no circumstances will I reveal the name(s), of those calculator manufacturer's (ok, it was HP and I think Casio, maybe TI as well).
So the big inefficiencies of these (possibly multiply piled up, I'm not sure off-hand), emulators, shows how excessively fast, these modern Arm cores, are these days.
I guess, if you have a big, complicated calculator program (firmware), and it takes years (and lots of rare/expensive software engineering), to create. Also, it has most or all of its bugs discovered/removed, hopefully, by now. I can understand why they would go that route.
-
I also wrote a (very partial) VAX emulator for the Apple ][ (in assembly language) during the summer holidays. Don't even ask the execution speed :-) :-)
The question almost ask itself:
Did you try your 6502 emulator on the VAX emulator?
Sounds a bit as my master degree dissertation:
Prof: Make a dissertation on Transputers, occam and graphics.
Me: Wonderful! Do we have any HW in the lab?
Prof: Nope.
Me: Ok, can we get some?
Prof: Nope.
Me: Ok, I'm going to write an occam compiler and emulator, with distributed processing on the LAN.
Prof: Go ahead!
Many years after, I learned the emulator had been used in many schools for a long time from a co-worker who just matched my name with his high-school memories of CS classes.
-
That sounds very impressive, and clever.
By using the X/Y register pair, as 'pretend' accumulators A and B (the 6502's single accumulator, limits/hinders its assembly language). That is a neat trick.
In this scheme, X and Y are not accumulators, but pointers to the accumulators, which are groups of 2 or 4 bytes located anywhere in Zero Page.
ADD16:
clc
lda $0000,y
adc $00,x
sta $00,x
lda $0001,y
adc $01,x
sta $01,x
rts
If variable A is in locations $05 and $06 and B is in locations $87 and $88 then you do A += B with:
ldx #$05
ldy #$87
jsr ADD16
You can have up to 128 such 16 bit variables or 64 32 bit variables.
ADD32:
clc
lda $0000,y
adc $00,x
sta $00,x
lda $0001,y
adc $01,x
sta $01,x
lda $0002,y
adc $02,x
sta $02,x
lda $0003,y
adc $03,x
sta $03,x
rts
Sorry, I'd got mixed up there. :-[
(Unrelated, somewhat NOT why I got mixed up) Because 8 bit cpu, index registers, are usually 16 bit (the 6502 is an exception), I think some schemes do use the X (and if available Y) index registers, as accumulators, temporarily. Just to get a speedup of a few cycles. Because of the limitations of the 8 bit accumulators, and the fiddling about, to perform 16 bit operations.
E.g. INCX, would then be a 16 bit INCA 'like' instruction (NOT on 6502, as index registers are 8 bit). LDX/STX would be as if you had a 16 bit accumulator for memory transfers, etc etc.
In defence of the 6502, the Zero Page mechanism, was a neat trick, which to a (slow, limited) extent. Was as if it had 256 extra 8 bit accumulators or 128, 16 bit index registers, etc.
In some respects the 6502, was an early RISC processor. Even though technically speaking it was a CISC one.
tl;dr
If there had been modern, 500 MHz 6502's. They would probably be somewhat powerful and fast, in a kind of quirky way. In some respects, the modern arm cores, came from an upcoming, upgraded 6502 processor. Which apparently, Arm/Acorn knew about, visited where it was being designed and discussed. Before inventing the new arm chips.
-
Then even later (I'm not sure how many iterations, this has gone on for in practice ?), an even newer release of the calculator comes out, with a somewhat fast, modern Arm core on it. Which emulates the previous cpu, which itself then again, emulates an even older (original) cpu. In order to be the calculator.
Well, yes, sure, you can nest emulators.
It's quite ok to do this because the original machine was so much slower than the new ones, but the program was carefully written to run satisfactorily on it.
I may or may not have run "][ in a Mac", on "Basilisk II" (compiled for PowerPC), on the built in "Rosetta" PowerPC emulator on an Intel Mac. Because I could.
And that's fine if you have all those accumulated over the years.
At some point it becomes easier just to write a 6502 emulator for that Intel machine and skip the intermediate 68000 and PowerPC emulations.
Apple's new ARM Macs will have an Intel emulator, but that emulator won't run Rosetta inside it -- Rosetta hasn't been supported for many years already. So I'd need to find or write my own PowerPC emulator. It's *definitely* much easier to write a 6502 emulator than a PowerPC emulator.
-
I also wrote a (very partial) VAX emulator for the Apple ][ (in assembly language) during the summer holidays. Don't even ask the execution speed :-) :-)
The question almost ask itself:
Did you try your 6502 emulator on the VAX emulator?
No. I hadn't implemented enough of the VAX instruction set to run it.
However the VAX partial-emulator ran fine on the 6502 emulator on the VAX.
Many years after, I learned the emulator had been used in many schools for a long time from a co-worker who just matched my name with his high-school memories of CS classes.
Nice!
-
In some respects the 6502, was an early RISC processor. Even though technically speaking it was a CISC one.
It's neither. It's more of a minimal instruction set computer (I can find a video of Sophie Wilson saying so), much like the PIC, 8051, DEC PDP8, Data General Nova and other of the earliest microcomputers and minicomputers.
[That didn't really happen the same way with mainframes (aka "computers" from 1940 to 1965) because the early ones were build by or for "money is no object!" government organizations modelling atomic explosions or whatever. It was only in the early minicomputer and microcomputer eras that "any computer is better than no computer" was the rule. And some IBM machines such as the 1130 or the bottom end System/360 too I guess]
-
Then even later (I'm not sure how many iterations, this has gone on for in practice ?), an even newer release of the calculator comes out, with a somewhat fast, modern Arm core on it. Which emulates the previous cpu, which itself then again, emulates an even older (original) cpu. In order to be the calculator.
Well, yes, sure, you can nest emulators.
It's quite ok to do this because the original machine was so much slower than the new ones, but the program was carefully written to run satisfactorily on it.
I may or may not have run "][ in a Mac", on "Basilisk II" (compiled for PowerPC), on the built in "Rosetta" PowerPC emulator on an Intel Mac. Because I could.
And that's fine if you have all those accumulated over the years.
At some point it becomes easier just to write a 6502 emulator for that Intel machine and skip the intermediate 68000 and PowerPC emulations.
Apple's new ARM Macs will have an Intel emulator, but that emulator won't run Rosetta inside it -- Rosetta hasn't been supported for many years already. So I'd need to find or write my own PowerPC emulator. It's *definitely* much easier to write a 6502 emulator than a PowerPC emulator.
Opinions may vary. But arguably, Intel (and AMD), have actually run an x86 processor 'Emulator' on their x86 processors, for a very long time.
I.e. The instruction decoders, accept x86 code, then, on the fly, 'translate' it into tiny micro-ops, which then runs on risc like cpu(s).
In some ways (analogy wise), the out of order instruction execution (and maybe some other speedup mechanisms), are a bit like having a real-time compiler optimiser (step), inside the cpu as well.
What could get fun/interesting, is if you had that 'cascade' of nested emulators, you just described. Then rarely/occasionally, it would produce, weird/bugged result(s). Now find where the fault lies ?
Is it the hardware, original program (bug), or one of the later emulators at fault ?
To make it harder, the 'instruction' which sets off that series of issues, that results in a bug. Might have been run, many thousands (or more) of instructions, in the past . E.g. Because a floating point value, in one of the emulators, did the rounding bit, ever so slightly wrong (and ultra rarely).
Then, some hundreds of thousands of instructions later, the bug emerges, because the slightly incorrect floating point value, has finally been loaded back from memory, is being used, and has caused some kind of floating point exception or something. Overflow, divide by zero, Nan etc.
Or even, just a subtle value change, big enough to be a bug, but small enough, to be a pain to detect.
Example: The original Pentium Divide bug. (Although that was a hardware, rather than a software type of bug. On the other hand, it was a ROM lookup-table (kind of software like) in the Pentiums FPU, which had the wrong values in it, which caused the bug, in the first place).
-
In some respects the 6502, was an early RISC processor. Even though technically speaking it was a CISC one.
It's neither. It's more of a minimal instruction set computer (I can find a video of Sophie Wilson saying so), much like the PIC, 8051, DEC PDP8, Data General Nova and other of the earliest microcomputers and minicomputers.
[That didn't really happen the same way with mainframes (aka "computers" from 1940 to 1965) because the early ones were build by or for "money is no object!" government organizations modelling atomic explosions or whatever. It was only in the early minicomputer and microcomputer eras that "any computer is better than no computer" was the rule. And some IBM machines such as the 1130 or the bottom end System/360 too I guess]
You're right, although the original Motorola 6800 (I think Chuck Peddle, was significantly involved), was where the 6502 came from. It was a sort of, "cut costs to the minimum, but try and maintain speed and functionality".
So, Chuck Peddle left Motorola, who had rejected, his dramatically lower selling priced '6502', so he (and others), left and created a new company. The rest is history.
There were some similar microprocessors, similar era, which might have, at least in some cost optimisation senses, beaten it, there. E.g. The Z80, having a half-sized 4 bit ALU, which, because of its relatively large number of clock cycles, could fit that in, time wise.
Also, Motorola, did the extreme cost reduced (yet 8 bit to the outside world), 1 bit internally (i.e. bit serial), MC6804P2, which Hitachi and maybe others, second sourced.
Amazingly, I think it had a built in self-test capability. Presumably, to cleverly reduce costs, by eliminating, reducing the time to do it, by speeding up the time to test the cpu, on the production line.
I've heard the testing can and is, the most expensive part of making the IC. Because it is time consuming (on a busy production line), needs expensive personnel and very expensive equipment. Potentially even, very expensive, custom test hardware/jigs.
tl;dr
Chuck Peddle, realised, that a rather cheap, 6502, would sell like hot cakes, and be designed into all sorts of new products. He was right!
But didn't seem to be in a position, to maintain that market dominance. If he/they had, I guess I'd be typing this in on a 6 GHz x6502, with floating point, and full 64 bit (6502) improved instruction set.
-
There were some similar microprocessors, similar era, which might have, at least in some cost optimisation senses, beaten it, there. E.g. The Z80, having a half-sized 4 bit ALU, which, because of its relatively large number of clock cycles, could fit that in, time wise.
Also, Motorola, did the extreme cost reduced (yet 8 bit to the outside world), 1 bit internally (i.e. bit serial), MC6804P2, which Hitachi and maybe others, second sourced.
I knew about the Z80 4 bit ALU. I didn't know about the MC6804P2.
The smallest FPGA implementation of RISC-V, Olof Kindgren's "SERV", is bit serial. Of course this makes it very slow, with most instructions taking 32 clock cycles (except jumps, load/store, SLT, shifts) but it seems to be popular. It runs at 50 MHz in an ICE40 and 220 MHz on Artix-7 so that's still around 1 to 7 32-bit MIPS https://github.com/olofk/serv
-
I knew about the Z80 4 bit ALU. I didn't know about the MC6804P2.
The smallest FPGA implementation of RISC-V, Olof Kindgren's "SERV", is bit serial. Of course this makes it very slow, with most instructions taking 32 clock cycles (except jumps, load/store, SLT, shifts) but it seems to be popular. It runs at 50 MHz in an ICE40 and 220 MHz on Artix-7 so that's still around 1 to 7 32-bit MIPS https://github.com/olofk/serv
Thanks.
That is quite amazing (I enjoyed the Video about it, from the designer), a RISC-V soft core, bit-serial cpu, in around 250 LE's (FPGA type and options dependent).
A MIP or so, is fast enough for many applications, e.g. Sensing. Where the FPGA performs the bulk processing, and the slow cpu, only needs to do some diagnostics, accept some commands from outside, and send back, slower sensor data (very fast sensor processing/communications via cpu, would need another solution).
The slowest 1 MIP one, is like having a small memory/disk version of a (previously) massive/expensive VAX 11/780, for each sensor/task/section of the FPGA. In its day, the VAX 11/780 could keep a large number of users, reasonably happy, as regards their computing requirements.
-
(I enjoyed the Video about it, from the designer)
Olof is a funny guy. And smart. And funny.
-
You use a modern, powerful Arm processor, with its potentially, highly complicated peripheral set. Amazingly powerful peripherals, yes. But they can have 2,000 page manuals, which make for very heavy reading.
If what you're after is the equivalent of an 80's 8bit micro, you can ignore most of those 2000 pages, and still have the benefit of more memory and cheaper boards... (plus, you know, several "beginner environments" to fall back on, should you want to do a printf() without having to read that section on the UART (which requires understanding the clock system and the power managers and ...)
-
You use a modern, powerful Arm processor, with its potentially, highly complicated peripheral set. Amazingly powerful peripherals, yes. But they can have 2,000 page manuals, which make for very heavy reading.
If what you're after is the equivalent of an 80's 8bit micro, you can ignore most of those 2000 pages, and still have the benefit of more memory and cheaper boards... (plus, you know, several "beginner environments" to fall back on, should you want to do a printf() without having to read that section on the UART (which requires understanding the clock system and the power managers and ...)
Yes, that can be the case. It depends on what you are trying to achieve, with any retro/vintage computer interests, one may have.
Some people are happy with emulators, or running modern stuff at full, or greatly reduced clock speeds. Some insist on the real thing, from the past. While others again, are happy to build a 'modern' retro/vintage computer, out of whatever parts are available.
E.g. With foundness, one remembers some BBC Micro computer, games, they use to play, such as Elite. Maybe if you have an old/original dusty one in the attack, or want to splash out around £200 (very approx), on a used ebay one. Spending the odd weekend here and there, cleaning it, recapping it and possibly repairing its ageing power supply.
Or just click here:
http://bbcmicro.co.uk//jsbeeb/play.php?autoboot&disc=http://bbcmicro.co.uk//gameimg/discs/366/Disc021-EliteD.ssd&noseek (http://bbcmicro.co.uk//jsbeeb/play.php?autoboot&disc=http://bbcmicro.co.uk//gameimg/discs/366/Disc021-EliteD.ssd&noseek)
http://bbcmicro.co.uk/game.php?id=366 (http://bbcmicro.co.uk/game.php?id=366)
Or here, for a massive list of A .. Z, online playable (even downloadable) games..
http://bbcmicro.co.uk/index.php (http://bbcmicro.co.uk/index.php)
Other (similar sites available as well) E.g.
https://bbc.godbolt.org/ (https://bbc.godbolt.org/)
-
Being able to do full system full speed emulation of old machines in freaking JAVASCRIPT is I think one of the most ridiculous aspects of current PCs (and phones).
-
Being able to do full system full speed emulation of old machines in freaking JAVASCRIPT is I think one of the most ridiculous aspects of current PCs (and phones).
It is somewhat crazy!
Maybe in the future, you can request ones home 3D all items, printer. To make a genuine (clone/copy) vintage computer. Play with it over the weekend. Get fed up with it. Then put it into the all recycling things chute, and move on to ones next activity.
A bit like you can print a colour, A4/A3 sheet of any photograph today, fairly rapidly. Or a 3D model of something, in some kind of plastic (meltable or UV curing), for your next custom widget pencil holder, that fits EXACTLY under your specific model of monitor, that you use.
Some people have done FPGA patterns (Verilog/VHDL) of entire, ancient mainframe computers (some are detailed or mentioned, on this Forum), such as Cray Supercomputers. In some cases, they are even freely downloadable.
So we are getting there, bit by bit.
I suppose you could take a suitable (e.g. CP/M) hackerspace PCB plan + BOM, send it to a Chinese PCB + Assembly service, and receive the completed CP/M clone computer board, a few weeks later. If you can afford it, and don't want to make it yourself.
-
I also wrote a (very partial) VAX emulator for the Apple ][ (in assembly language) during the summer holidays. Don't even ask the execution speed :-) :-)
Compared to the VAX-11/780 I bet it was fast. That thing was a pig! ::)
(Yeah, okay, maybe it was 20x as fast as a 6502, which was pretty pathetic for the amount of iron.)