-
Retro-uC - An open source microcontroller with retro instruction sets
Posted by Fatsie on 07 Feb, 2018 20:54 -
In the retrocomputing devroom on FOSDEM of last weekend I presented my project to make an open source microcontroller: Retro-uC - An open source microcontroller with retro instruction sets. It's a microcontroller with a Z80, MOS6502 and Motorola 68000 core. You can find the details in the video of the talk. The project also has a page on hackaday.io.
A more technical presentation was on the tool chain for implementing the chip in the CAD and Open Hardware devroom: The open source EDA tool chain for the Chips4Makers project - Is an ASIC made with fully open source tool chain possible ? Is it affordable ?. This talk goes into more tool chain on what flow one needs to follow and what the status of the available open source software is.
This Retro-uC project is actually a pilot-project for a bigger Chips4Makers project where I am trying to make open-silicon possible at moderate cost. Some more info can be found on the related blog.
Of course all feedback is appreciated but especially if you have links to subdicing or packaging services with low-startup costs and this targeting low-volume production (=a few hundred) I am all ears.
PS: I suppose a link to the Crowdsupply landing page may also be handy: https://www.crowdsupply.com/chips4makers/retro-uc -
I think this is an interesting idea. As I am sure you know, there is a very inverse relation between price and demand. I guess people will pay a small premium for Open Source, not sure that it extends to $90 for an 8 bit CPU.
I'v seen a few technical articles suggesting custom ASIC is accessible for typical companies. I'd like to know more about how the costs work out. -
There is http://efabless.com/ which advertises $5000 to first silicon in a 180nm process.
-
I watched the FOSDEM presentation and I understand quite a bit more now.
I like the idea of putting 3 cores into one package, and also limiting to one (larger) package. Makers will always say they prefer QFP over QFN, but they will always choose the cheaper option...
As for the PCBs, I would drop the proto-plus and offer a breadboardable DIP module and possibly the Retrino. I would make module ready to go with onboard crystal so it could be used standalone. In practice, there does not seem to be much demand for Mega format boards, so for a "Arduino" like board the Uno format might be better if that makes it cheaper.
If possible, I would try to make a module that could be used directly in a retro computer. For that, it really needs 16KB RAM (or more), but necessarily onboard. I realise there is a big trade-off between on board RAM and providing EBI instead. Not sure what the best answer there is apart from "keep it simple".
I have some questions about how these boards are programmed, and the application tool chain. I helped create the stm32duino package for Arduino IDE, I think it would be useful to have an Arduino core package even if basic functionality. -
As for the PCBs, I would drop the proto-plus and offer a breadboardable DIP module and possibly the Retrino. I would make module ready to go with onboard crystal so it could be used standalone. In practice, there does not seem to be much demand for Mega format boards, so for a "Arduino" like board the Uno format might be better if that makes it cheaper.
The startup costs for PCB manufacturing and assembly are relatively low so leaving out a board won't decrease the funding goal or reduce cost of some other options.
Actually reducing the number of pins will not decrease the cost much either for the chip; this is the reason I did not keep the smaller chip. Reducing the MEGA to Uno size is just some PCB area and a few headers also not much in cost difference.If possible, I would try to make a module that could be used directly in a retro computer. For that, it really needs 16KB RAM (or more), but necessarily onboard. I realise there is a big trade-off between on board RAM and providing EBI instead. Not sure what the best answer there is apart from "keep it simple".
In live one has to make choices and for the project I have chosen to go for a micro-controller with I/O as I think it would make more makers interested. Trying to combine both on one chip in this first project I do find too risky. But I will keep in my mind for future projects.
The current size of the chip is on a sweet spot of not much cost reduction anymore when making it smaller. Making it bigger though would increase cost almost linearly with the area so 16KB would cost considerably more. What may be a possibility is that if the campaign is really successful I could go for a smaller technology which can provide more RAM in the same area. But I'll look at this further when the campaign is launched.
Of course people could go crazy and make a setup where bank switching is implemented loading data into the on-chip RAM through the JTAG interface. Not very fast but doable.I have some questions about how these boards are programmed, and the application tool chain. I helped create the stm32duino package for Arduino IDE, I think it would be useful to have an Arduino core package even if basic functionality.
For bare chip and also the breadboardable and prototyping board the chips could be booted from I2C flash where then the proper programmer can be used. Or it can be booted through the JTAG interface. I am using a Bus Pirate now with openocd program to do that but any supported openocd programmer should do and I don't think other JTAG programmers with other support programs would be difficult to support.
For the Retrino I do plan to start from the BlackIce (II) support programs. But the tools will likely be very basic and mainly focused on assembly programming. But as everything is open source I do hope the community will build on that and improve things.
Not much work has already been done on that yet but that is planned to happen in between the tape-out of the chip and the PCB ready (a few months).
-
Ok, thanks for your response. I suspect that a micro-controller with IO will have a very niche appeal, but I hope that there is sufficient interest to make it viable. However, I think you are right to focus on retro-computing segment. My first "PC" was an Acorn Atom, I wrote code in BASIC and 6502 assembly. Stupidly I binned my early hardware years ago.
I think a dev board with builtin program/debug via USB would greatly increase the appeal to general makers, since only hard core hackers like me have JTAG programmers.
I've been looking into compiler support, there are some C compilers for these cores, perhaps obviously I could find no free C++ compilers. -
I've been looking into compiler support, there are some C compilers for these cores, perhaps obviously I could find no free C++ compilers.
Yes, I also found C compilers but if you integrate that in the Arduino IDE the only difference with a normal Arduino is that you are using a retro instruction set under the hood.
-
I've been looking into compiler support, there are some C compilers for these cores, perhaps obviously I could find no free C++ compilers.
Yes, I also found C compilers but if you integrate that in the Arduino IDE the only difference with a normal Arduino is that you are using a retro instruction set under the hood.
So you want to distinguish your product by making it harder to use... m'kay.
It seems you have a quite fixed idea about your project so I won't comment further. It doesn't seem like I can help in any way. Good luck! -
Some of the older microprocessor ISAs are very limited in terms of things like stacks and so even if you were to use a C compiler, most code written in C would not work. Hell, even getting things to run under 8088 DOS with Turbo C was painful.
-
Some of the older microprocessor ISAs are very limited in terms of things like stacks and so even if you were to use a C compiler, most code written in C would not work.
No, that's nonsense. Even C++ is effective on 8-bit AVR, which is not much more advanced. For 68k, C is ideal. -
Quote
It's a microcontroller with a Z80, MOS6502 and Motorola 68000 core.
We're talking about 8-bit micros, here. You can't even use a simple function like getc() since it requires a 16 bit register to hold the return value. -
So you want to distinguish your product by making it harder to use... m'kay.
Sorry, I did not want to imply I don't want any help. Actually in a previous post I said this:Quote from: FatsieBut as everything is open source I do hope the community will build on that and improve things.
So I assumed this made it clear that I am open for contributions. Seems I was wrong...
What I do want to avoid is that people expect certain things that in the end won't be delivered; so I try to be clear on what they can expect. Of course if I in the end can deliver more I think nobody will complain. Also I try to avoid feature creep so that in the end the needed work is increasing and big delay in completion of project or even worse that the chip won't and people receive an expensive door step.
-
Quote
It's a microcontroller with a Z80, MOS6502 and Motorola 68000 core.
We're talking about 8-bit micros, here. You can't even use a simple function like getc() since it requires a 16 bit register to hold the return value.
ROFL
Maybe sometime you could run that past someone familiar with 8-bit C compilers. Or just pick a compiler at random and check the spec:
http://sdcc.sourceforge.net/Quotea full range of data types: char (8 bits, 1 byte), short (16 bits, 2 bytes), int (16 bits, 2 bytes), long (32 bit, 4 bytes), long long (64 bit, 8 bytes), float (4 byte IEEE) and _Bool/bool
-
And https://github.com/cc65/cc65 of course
-
Quote
It's a microcontroller with a Z80, MOS6502 and Motorola 68000 core.
We're talking about 8-bit micros, here. You can't even use a simple function like getc() since it requires a 16 bit register to hold the return value.
Nope. You are clearly completely and utterly clueless.
Come on, are you trolling? You'll have to do better than that. Everyone has heard of Arduino.
-
So I assumed this made it clear that I am open for contributions. Seems I was wrong...
Well, I was thinking of offering to help with HLL support, but you said "don't bother, not required", so...
I am a professional embedded software engineer, and also have done a lot of stuff in the maker scene. I think I have a pretty good idea. No-one is coding in assembler. If anything it's going the other way, MicroPython is getting popular. I'm less familiar with the retro computing, there it seems to be more about implementing old ROMs rather than writing new code, so RAM size is important.
Perhaps you could outline some specific software tasks that you think would be useful.
I think your problem is that you are finely balanced on the demand/price curve. At the moment, you are not offering something that appeals to makers or retro-computing guys - obviously that is my opinion. The people who would back your project are likely to be open source aficionados who just want to see the project funded, and don't expect to use it in any useful applications. I don't think that amounts to more than a $5000 or so. Maybe that is enough? -
Well, I was thinking of offering to help with HLL support, but you said "don't bother, not required", so...
Thank you very much for the offer and if I said that it was not my intention to say that...
I am a professional embedded software engineer, and also have done a lot of stuff in the maker scene. I think I have a pretty good idea. No-one is coding in assembler. If anything it's going the other way, MicroPython is getting popular. I'm less familiar with the retro computing, there it seems to be more about implementing old ROMs rather than writing new code, so RAM size is important.
Perhaps you could outline some specific software tasks that you think would be useful.
I do think that MicroPython would be nice, I was also thinking about getting contiki going on the board. For the latter with a UART one could get a terminal and with an ethernet shield maybe even networking. But I do realize the amount of RAM will limit things a lot.
But if you like to work on getting the board support in the Arduino IDE I would also support you in that.
Actually I am working now to get the Retro-uC going on FPGA boards so actually software development could happen before the real hardware is available. I'll PM you when I get something working on FPGA. Maybe best wait until crowdfunding has been launched and enough money has been raised to reach the goal ?I think your problem is that you are finely balanced on the demand/price curve. At the moment, you are not offering something that appeals to makers or retro-computing guys - obviously that is my opinion. The people who would back your project are likely to be open source aficionados who just want to see the project funded, and don't expect to use it in any useful applications. I don't think that amounts to more than a $5000 or so. Maybe that is enough?
I know this is a niche product in a niche but I do need more than $5000. The nice thing about crowdfunding is you can test the market without having to invest upfront. Only wasted time but as I enjoy doing this development that's not a problem either.
-
Some of the older microprocessor ISAs are very limited in terms of things like stacks and so even if you were to use a C compiler, most code written in C would not work.
cc65 works pretty well at building C code that runs on the 6502. The 256-byte stack in page 1 isn't the only place you can put data before calling a function. On the Apple II at least, it was fairly common to pass parameters in the space right after a function call. Just tweak the return location on the stack before the return so that the parameters are skipped. -
I know this is a niche product in a niche
... and a rather narrow niche, I'm afraid. Between CPU emulators (running on a PC in a comfortable development environment) and using real old-stock CPUs (running in either old authentic hardware or new homebrew systems), how much room is there for a "fake" CPU?
And, not to forget, there are open-source FPGA cores for these CPUs, and an FPGA experimenter's board can be had for $30 or so. That's less than what you would need to ask for a custom IC, I assume?
Not convinced, sorry.
-
Also not convinced for the same reasons.
The *ONLY* advantage a custom chip would have over a FPGA soft core would be it could have true 5V I/Os for better compatibility with legacy 8 bit era system busses. However a 3.3V FPGA with 5V tolerant inputs is directly compatible with 74HCT logic running at 5V so that advantage is marginal.
Historically there was a lot of rabid partisanship and strong brand loyalties in the home computer scene of that era, so the proportion of the target market that is likely to want to use all the cores is very limited. Also all the proposed cores (Z80, MOS6502 and Motorola 68000) still have instruction set compatible microcontrollers commercially available: Zilog eZ80 family, WDC W65C134S, and NXP's ColdFire MC68xxx range.
-
IMHO.... I think the time for this sort of stuff is now-ish but it is in the form of a generalised FPGA platform and opencores for the vintage processors of interest rather than dedicated silicon.
In particular the Terasic DE10-Nano (not perfect due to lack of SRAM but solveable with a small expansion board) and Mister https://github.com/MiSTer-devel/Main_MiSTer/wiki project are the way to go. Lots of fun stuff happening there.
The 3v3 volt-ness of these devices is a problem but modern emulations can be done in the 3v3 domain... fixing, by replacing custom logic, on older 5v boards remains challenging (and will just become harder over time).