I'm wondering:
What sort of internal peripherals are planned to be on these microcontrollers? I would be interested in TTL serial and SPI, beyond the obvious parallel I/O.
How will they be programmed?
Also, will it be one chip for all three cores? Or will it be a distinct chip for each? I ask because the use of the term ASIC suggests to me that there will be one core in each type of chip, but the comments here look like they're heading in the direction of one chip for all three cores(That, to me, seems to be closer to an FPGA with peripherals built in).

A lot of interesting questions indeed and some of the things are on list of to be investigated.
What I currently have in mind:

• In general I have lot's of ideas but I need to keep the scope of the first project in control. Several crowdfunding projects have failed in the past because they tried to do too many things in one go.
• I use tested cores only to avoid problems in the chip. The three cores are all tested in FPGA projects emulating old computer and thus carefully tested. I don't plan to change them anymore with risk of introducing bugs.
• I currenlty plan to have only one core active at a time; otherwise bus arbitration between and the on-chip RAM needs to be implemented which increases the risk of chip not working.
• the peripheral I will be investigating are the simpler serial ones: UART, I2C, SPI, PWM, ...; if first project is successful there is likely room in the future for test chips include USB, Ethernet or even analog like ADC, DAC, opamps, ...
• One of the stretch goals in the project will likely be for on-chip NVM so that the uC will boot from that; if not it will boot from external I2C or SPI FLASH. Likely external FLASH contents will be copied in on-chip RAM at reset.
• The number of IOs, on-chip RAM and eventually on-chip NVRAM is still under investigation; please watch hackaday site.
• The robotics is future possible market. After this project in future I can look at higher voltage IO to 12V or 24V; other possible use case is maybe audio etc. Again to keep scope manageable I focus now on microcontroller with 5V IO only.

Thanks for providing some more info about the project.

;---

My point is:

_If_ the chip would contain "a reasonable amount" of "programmable logic",
you won't have to worry about designing the peripherals (plus the related bugs),
and you also won't have to worry about bus arbitration etc.

Because then those things could be implemented _after_ the chip is completed.

IMHO this would speed up the development process for the chip a little bit
while reducing the risk of introducing bugs.

// Of course, exactly defining what a "reasonable amount" is would be going to be difficult...

@ ORConf one of the ideas that popped up there (with yours truly part of the inspiration) was a fully open source FPGA. The myStorm guys seem to be interested. This is currently a separate project, but I will support it where possible. If successful this will become part of the open source portfolio people will be able to use on their custom chips.

Unfortunately not, including some programmable logic is easier said than done. And it's not the amount that is the problem it's the base programmable cell and especially the programmable interconnect in between them.

In many ways a microcontroller is the opposite of an ASIC - it's not application specific, instead it has a range of peripherals and some configurable choices of how the I/Os are routed to the peripherals, such that a single standard part can be a suitable solution for many different problems. That costs some silicon area but has become a normal thing to do. No-one worries too much about the timer/counters or UARTs which they didn't need, concentrating on the bits they did need. They get a good price because the volume is correspondingly higher. It's hard to overestimate the effect of volume in electronics and microelectronics!

For this particular project, if the design is pad-limited then it makes good sense to include all three cores, and allow any one of them to be the one that's running. It might make good sense even if it isn't pad-limited, because it makes the part appeal to more people and so can sell in a higher volume.

The real difficulty is in the spec: everyone will have an opinion as to what's attractive to include! The secret, I think, is to listen to what people are asking for, but don't in any way attempt to please everyone. Possibly even use your own judgement and please no-one. The people who speak up may not be representative.

The selected cores are relatively small, the area will be filled up by on-chip RAM so the number of IO will determine the amount of on-chip RAM and the cost. Originally I planned to have a separate chip for each core but it would make almost no difference in price per chip and the logistics become more difficult as you have to sort the dies or packaged chips or pay setup costs for each of the chips...

What package are you thinking of offering?

The support of 5V should be a big help in the retro community. And being a "real chip" as opposed to an FPGA will also help, as there are some people out there who have some sense of authenticity which isn't satisfied by FPGA.

Likely a poor men's package, e.g. direct-on-board (die is put on PCB and wire-bonded directly to PCB). The prices I have now make setup costs for packaging higher than direct-on-board for low volumes.
I plan to have different PCB layouts on which I will likely ask the community feed back in a later stage. One will certainly be a DIL compatible one and most likely also an Arduino compatible one. An advantage is also that I can put the JTAG interface not in the DIL pins.
If demand is unexpectedly high I can go for 'real' packages.

I take the peripherals available on the AVR uCs used for the Arduino boards as reference except the ADC. Problem is finding tested cores with the right license.

I would think a DIL-compatible board would be good for retro people.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That's what these are: https://www.xilinx.com/products/silicon ... -7000.html

An ARM Core combined with some FPGA.

There's a board out there using this: https://www.crowdsupply.com/krtkl/snickerdoodle

To quote Scotty from StarTreck:
"The trick is to build what they need, not what they want."

;---

But seriously:
IIRC there wasn't a "standard" for 6502 or 68k computers back then,
just compare the memory map of PET, VIC20 and C64.

This calls for having sort of "programmable logic" for address decoding etc.

Back in 1999, I had toyed with the Lattice ispLSI1016 CPLD,
and for implementing the glue logic and address decoder logic of a 68020 computer
that CPLD already was bigger than it needed to be.

It felt like having 16 GALs or such, with some of their inputs and outputs
tied together with a "switch matrix".

Hey, GAL22V10 is well known, there are GAL assemblers for it,
and I think there might be documentation about which Bit goes where in the *.JED file.
"Stitching" the inputs and outputs of some GAL22V10 together with "crosspoint switches"
probably would do for address decoding and glue logic...
maybe it's worth a try.

;---

I just remembered the PIC microcontrollers which seem to come with a myriard
of different peripherals... but if the project requires thinking outside the box,
it's not easy to find a chip where the mix of peripherals on the chip really fits.

After >19 years of tinkering with microcontrollers for a living I could make some suggestions,
but of course those suggestions would be "outside the box" and _untested_.

;---

Anyhow, I'd highly recommend that you are testing the _concept_ for your chip
(and the acceptance of the "end users") by implementing the design in a FPGA first
before trying to actually design the chip.

OK, I have been busy mainly with budgeting and trying to get technical production things worked out. I now made a blog post summary of the options I plan for the Retro-uC. All comments are welcome here or on the hackaday.io log.

I do plan to include peripherals in the uC but that part is not fixed yet and should be documented in the future. Peripherals I would like to include are UART, SPI, I2C, PWM.