Modern micro computer idea.

[Doctorandus_P]

There has been an idea bouncing in my head for quite some time for a general purpose micro computer, and I'm wondering if others have similar idea's and/or interest.
It is a sort of equivalent of an '80-ies home computer, but then built around a microcontroller.

First some background from where this idea came from:

• 've played around with Micropython a bit, and well, it's python, (which I don't particularly like).
  I do like the idea of the REPL, it reminds me of a command line interface of an OS.
  uPython even has the ability to make a "batch" file, or a program that gets started when the system boots.
• There are a lot of (semi) active "retro computing" communities reliving the old days with <10MHz 8-bitters, and there are applications for which a system with such performance could still be useful.
• It would be nice to have a small & cheap computer that can load user routines as the brains for a test / measurement setup.

I

For the basis, I'm thinking along the lines of:

• Main system is a single uC, Maybe some STM32 or a Teensy4
• It must have semi-permanent "disk" storage. using uSD is the logical choice.
• It must have some "bios" interface for programs. It seems logical to have FreeRTOS running, and then applications can be loaded as a task.
• Keyboard input and LCD output...
• Some kind of standardized bus system for extensions. Parallel seems old fashioned, SPI can transfer 50Mbit/s and
• Loadable "device drivers" Ethernet, USB, Keyboard,
• How to load a "progam". compile them as a separate module and load them as an "overlay"?

It's tempting to make the specifications too "big", but when the price point of the hardware gets near the cost of such a credit card sized Linux computer, viability drops rapidly. It can be quite low power, so it can for example be used as a battery powered datalogger, or an extensible benchtop DMM.

At the moment I'm just curios what others think of this idea. Maybe it's just a silly brainfart, maybe it's better then sliced bread. Maybe it already exists. (Anyone aware of that?)

[iMo]

From 2009/10 I participated on a project called "RetroBSD". There was an active forum, today closed already. The chip used was 80MHz pic32MX795 with 128kB of internal sram (the biggest at that time) and 512kB of flash. The chip had none MMU, but there was a workaround for it. We ran modded 2.11BSD Unix on it and it worked nice.

The minimal system consisted of the pic32MX and an SDcard, and a serial for the connection to a terminal. There was/is perhaps 20-30 low cost boards capable running it straight. Later on there was networking introduced as well (especially with the 200MHz pic32MZ with 4.4BSD and 200-300kB user space in around 2015/16).

The filesystem was on an SDcard, also the swap file was on the same SDcard. I moved the swap file to an external sram afterwards (basically a 4MB ramdisk made of an xilinx cpld). You could run several (like up to 10-12 based on the swap size) programs/binaries in "parallel" (the scheduler was switching/swapping the tasks in a round robin mode taking the user tasks into/from the swap file), one task had to be less than 100kB* afaik (the user space), about 10x faster than pdp11/VAX or similar vintage gear (especially the "disk access r/w speed" was something like 5-6MB/sec - 20-30x faster).

PS:
* To be more precise here - with the pic32MX the user space was 96kB, your task/app had to fit into those 96kB all inclusive. There was a C compiler made (called SmallerC, something like 50-60kB large, around 2014/15) such you was able to compile your apps directly on the chip under OS. Afaik the SmallerC was able to rebuild the complete system on-chip.
The 128kB-96kB of sram was used by the kernel. The kernel itself was placed in the mcu's flash. The dev env was under linux (MIPS GCC).

[nctnico]

ESP32-S3 does most what you want out of the box. Has bluetooth, wifi and Wiznet 5500 drivers out of the box. Lots of flash storage too if you choose a device with internal flash.

I have been toying with a similar idea to have some programmable I/O that is easely modified by using scripting. Biggest problem with this kind of project is to get the cost versus features just right.

[SiliconWizard]

Yeah, this is a huge rabbit hole which is very likely to end up as a dead project once you have invested too much time in it and realize it's too much work for what it's worth.

If you need something like this, I would suggest looking at Mecrisp Forth, or CircuitPython for something higher-level, and a supported MCU.

[brucehoult]

Main system is a single uC, Maybe some STM32 or a Teensy4 [/li][/list]

Ooofff. Teensy4 is $20! (more now, I think) Nice fast dual-issue CPU, 600 MHz standard, can be easily overclocked to 960 MHz. But only 1 MB RAM.

Great board when it came out in 2019. But times have moved on.

Now for $6 you can get a Pine64 Ox64.

- 480 MHz C906 64 bit  RISC-V CPU with full MMU, FPU, 128 bit vector unit. Runs Linux.

- two slower 32 bit RISC-V CPUs for real-time tasks.

- 728 KB SRAM plus 64 MB PSRAM

- 2 MB SPI flash

- SD card

For $2 more ($8) you can get it with 16 MB flash instead.

It's a bit slower than a Teensy4, but 64 MB RAM vs 1 MB! With 64 MB RAM you could run full unmodified Ubuntu server with plenty of RAM left over to run real Python, emacs, gcc. (The supported OS is Buildroot)

https://pine64.com/product-category/ox64/


Sipeed have a board "M1s Dock" using the same chip for $10.80 which is a bit more convenient to use because it mounts on a PC as a USB drive and you can flash it just by dragging and dropping an ELF file.

https://www.aliexpress.us/item/1005004970779483.html


Those have both been out for a while now.

The new thing is the $9 Milk-V Duo, which uses the same C906 CPU core and also has 64 MB PSRAM but uses a different SoC and runs at 1 GHz.

https://milkv.io/duo


When you can run full Linux (or the RTOS of your choice) with 64 MB RAM at these prices, there seems little point in 1 MB or less microcontroller boards.

[themadhippy]

If you want that 80's home computer vibe hows about basic on a pi pico w
https://geoffg.net/webmite.html

[iMo]

Except RetroBSD I did with MecrispForth a lot (stm32 and fpga), as well as with Amforth, FlashForth etc. Also Lua on stm32 and pic32, and of course MMBasic on pic32. Basically I was always looking for something OP is describing above - something where you can create and load/save interactively your "apps" without needing any PC dev env. A standalone solution so to speak..
If you want speed of execution and low power on a small MCU then Forth would be your choice, then the Basic/Lua in between and when you want a comfort of a large OS w/ full fledged compiler in it go with linux. The big issue here is the Forth is not for everyone, and its user base is rather minuscule.

PS: I did with FreeRTOS (atmega, stm32) and ChibiOS (stm32) - but those are not the environments offering you what you are looking for - you have to create your "OS" above it..

[westfw]

There is software to turn various microcontroller boards into "full computers" (add monitor and keyboard, or serial port), supporting a relatively large set of languages: BASIC, Forth, C, Python, and Lua, as well as a bunch of xxx-like languages.  Pick one and go for it!
(although you quickly run into the whole "why aren't I using a full linux system on a a Raspberry Pi or similar?  The cost difference is pretty minimal.")

[Kjelt]

I am seeing the usual pitfall engineers make, and I also made a lot:

You start with the hardware and software.

You should start with: what problem of a user would I like to solve?
What would be its purpose?

[SpacedCowboy]

I've had an on-again/off-again project (currently on-again) for quite some time now to bring the Atari XL/XE into the world of today. The goal was to hang a modern MCU off the back of the parallel bus (or extended cartridge port in the case of XE) and do a few things:

• Replace the internal memory accesses and fulfil all RAM from the new device, which allows DMA "into" the host computer memory from the MCU. Provide lots of RAM, and allow mapping in/out on a page-by-page basis using control blocks.
• Interpret the writes to video RAM (all maximum 8K of it!) and morph into the MCU's LCD peripheral's format, then onto an HDMI chip to output to modern devices. Something like an SII9022.
• Create a 'hard disk' that's really an SD card / FATFS
• Provide ethernet
• Provide "slots" to plug stuff into - the plan is to have both UART and SPI to each slot, and let that be enough bandwidth
• Provide USB (host and device ports) so I can (a) plug in a mouse, and (b) plug the box into a PC/Mac and have "software" peripherals.
• Create it as a module with an FPGA doing the interfacing (there's a ~40ns signal-turnaround requirement for the XL/XE interface!) to the host, and in turn relaying to/from the MCU.

For that last, there'd be a small interface board (XL/XE bus on the one side, and a mini-SAS connector on the other, giving me plenty of bus-lines to send data to the FPGA (signals would be suitably level-translated). That gets rid of any "peripheral wobble" on the host bus by decoupling with a cable, and gives me 4 sides of the actual box to put ports, rather than one being up against the back of the computer.

My MCU of choice for this is the i.MXRT1176. It's got a fast (1GHz) core for the main processing and video work, and a "slow" 400MHz core for the interfacing, which share their memory map. That means the fast core isn't being interrupted 2 million times per second to do grunt work, and there's no real latency for getting the data (from all that grunt work) into a place that's useful to the fast core.

I want a very fast boot, one of the "things" of old computers was "switch it on and its ready to go"... so running it under Linux isn't really an option - the 400MHz CM4 core can just boot from QSPI quickly, and then be up and running. The CM7 can either be QSPI or maybe ultra-speed SD.

Since it's an Atari, and there's open source GEM replacements, I figure ultimately building a software-compatible replacement for GEM on the MCU would be fun, especially since a lot of the hard work for getting an OS up and running is already there with the built-in FreeRTOS or AzureRTOS implementations on the chip. That gets you GEMDOS, then you need the VDI and AES calls, which I'd probably implement as a shared library - I have a thought for how to get shared libraries working in FreeRTOS, so you'd be able to load and run programs on the MCU from the SD card...

Anyway... to bring this kicking and screaming back on topic, it also occurred to me that if you take away the requirement to interface to old computers (the FPGA gets you compatibility across a range of computers, assuming a similar bus architecture), then you have an "old style computer" just by plugging it into an HDMI TV. You get the "instant on", it can boot directly into an interpreter (BASIC, or Python) or GEM-style desktop shell, and you have access to internet and USB devices for ease of use. Once the graphics VDI is available, it wouldn't be that hard to get nanoX up and running as well - so you have an X client... All pipe dreams for now though.

So in my case, it's really about "how to make this old computer from my youth work better in the world today" - and it's a fun project devoid of commercial application (which is great, no deadlines!) but I could see it being useful for creating an old computer vibe with a (reasonably) fast MCU...

[dietert1]

We have an old Keithley 3706 with a strong embedded Windows machine inside with LUA scripting and a web server for remote control. It supports being a GPIB controller, so it can host other instruments in the lab. This works via LAN, too. It supports permanent script and data storage. Is this what the OP wants?
To be honest, it isn't very easy to use, with thick manuals to study.
I'd guess that python solutions will turn into a standard - hopefully with less learning and less hand crafted lab software.

Regards, Dieter

[radiolistener]

such computer already exists: Raspberry Pi 400

https://www.aliexpress.com/item/1005001949851787.html

[WillTurner]

Hey Dr P!
  This is a great idea! I see lots of support for Linux capable microcontrollers, so let me suggest the Raspberry Pi Pico, and instead of trying to go really, really fast ... well, we go after other things 
  Have a look at Geoff Graham's ASCII video terminal, published in 2014 Silicon Chip magazine (from Australia), or at Geoff's website.

 /https://geoffg.net
 /https://https://www.siliconchip.com.au/

  The AVT (ASCII Video Terminal) uses a higher end PIC microcontroller, and generates VGA video. Rescue a PS/2 keyboard, and display from the back store room, and you have a minimalist VT100 style terminal (with some caveats that I may disclose later), capable of talking at logic levels with the modern microcontroller you propose.
  I mentioned the Pico above. If you downclock the Pico to 48MHz, it draws only around 10mA. The AVT itself draws about 50mA. So if we stay in this kind of territory, we can afford to run lots of Pico's. In fact, you will really be constrained by the laborious task of connecting them together. (The answer lies down the automated PCB assembly route.) 
  But, you can afford to allocate a serially connected pico (that you can talk to) to each one of your precision instruments.

  So, what kind of software are we talking about, with Pico? I had a crack at RP2040 assembly language, and in an evolutionary sense, it is way beyond 1980's 8-bit CPU's. If you remember DEC and the 16 bit PDP-11 (nostalgia buffs encouraged to contribute!), then go forward unto the VAX, well that's what this sucker looks like to me. Mostly 16bit instructions, some 32bit. Finite, but capable register set. No MMU (memory management unit). Did I mention two cores?
  Wait .. did he say no MMU? Well, this device is capable of emulating any of your 8bit CPU's of the 80's. But no MMU means that swapping processes is problematic. Linux isn't going to run here. There is Fuzix, but that is another story.
  In any event, if you choose this path, you will have to be humble, and try (again Geoff and Peter) MMBasic

https://mmbasic.com/

  What you get is a self-hosting system like environment, similar to the language of 80's heritage, but far more modern. Self-hosting means, that using your AVT, you can develop live. On the fly. Debug your instrument ... whatever. At least, start with MMBasic and debug your hardware interfaces.  For minimal outlay you get a development environment that has a small filesystem on chip for storing Basic code, and configuration data, can edit via  the minimal AVT, but in microcontroller territory. This is what the purist low-level hardware guys are having trouble with. The Pico is a software innovation.

  When you start looking for a language to get down to the bare metal, you are talking C. May I suggest PShell

https://github.com/lurk101/pshell

  PShell has a minimal filesystem, simple shell, Vi editor, and an ARM C89 compiler with caveats. So using your AVT, you can in theory, write, compile and execute code in place ... self-hosting. I'm not there yet ... Did I mention the AVT is not a full VT100 implementation? In particular, it seems to not be able to read back it's cursor location. Which is of historical interest (and again, some vintage historian feel free) because I think the vi editor requires this?

  Let me also mention that I am already running one Pico as a terminal (and power) switch, and can switch sessions between the AVT, and three host Pico's. They of course need names, so I chose Larry, Curly, and Moe. "Power" switch means I can turn the AVT, or any of the Pico's off from a front panel key.

  Good luck in your endeavor. This kind of hardware can eventually provide an 80's style user interface to a modern design precision front end.
 
Edit: typos. This was written by a human being.
Edit: Bit about switching power on and off. Also, software bloat vs minimalist software that you can understand.
Edit: BTW, if your terminal is a laptop, may I suggest to use some form of isolation, like an opto-coupler setup, somewhere where it makes sense.
Edit: BTW#2, I can run micropython within the architecture I have described, however I haven't solved the "editor" issue there. If I write code and upload it via Thonny, I can do everything short of editing code. The MMBasic editor is a gem, and works flawlessly over my simple serial links. Also in favour of MMBasic - the on-chip filesystem is littlefs, but the SD-card filesystem interface is VFat. I can get files off of the machine. Fuzix is beautiful work, but targeted across 8-bit architectures, with its own unixy filesystem. No C compiler yet. If they are listening, squeezing the PShell AMaCC C compiler into the Fuzix distro would work. The caveat for PShell's CC is no C preprocessor.  Flat code, everything in the one file.

[iMo]

.. If you remember DEC and the 16 bit PDP-11 (nostalgia buffs encouraged to contribute!), then go forward unto the VAX, well that's what this sucker looks like to me. ..

I've been running the almost fully configured PDP11/70 (20MHz, 4MB ram, 64bit FPU, MMU, various FSes/Disks on an SDcard, project includes a terminal core to interface to a VGA screen and PS2 keyboard, etc. etc.) on an oldish cycloneII fpga board ("PDP2011" project). Works great with latest patched 2.11BSD (and around 4 other DEC OSes)!
C, Fortran, Basic etc compilers inside the ready to run 2.11BSD FS image you may download.. 

[brucehoult]

.. If you remember DEC and the 16 bit PDP-11 (nostalgia buffs encouraged to contribute!), then go forward unto the VAX, well that's what this sucker looks like to me. ..

I've been running the almost fully configured PDP11/70 (20MHz, 4MB ram, 64bit FPU, MMU, various FSes/Disks on an SDcard, project includes a terminal core to interface to a VGA screen and PS2 keyboard, etc. etc.) on an oldish cycloneII fpga board ("PDP2011" project). Works great with latest patched 2.11BSD (and around 4 other DEC OSes)!
C, Fortran, Basic etc compilers inside the ready to run 2.11BSD FS image you may download.. 

I loved the university's PDP 11/70 in 1981/2. Beast. If your program fit, then it probably ran faster than on the VAX that appeared next to it in late 82.

It was totally slaughtered in every way except disk I/O by the 128k Mac in early 1984.

The Mac's 68000 very similar to program to the PDP-11 too -- much more so than ARM. You lost full memory-to-memory operations (except MOV), having only memory-to-register, but you got twice the registers, and 32 bit arithmetic and addressing.

Today you can run full Linux on a board that costs less than $10 and has 500x the CPU power and 500x the RAM too.

Or xv6, a modern reimplemention of PDP-11 Sixth Edition Unix, if you want.

[Doctorandus_P]

Although I do have a soft spot for those old machines and keepig their history alive, I did start this thread with the word "modern" in the title...

I do agree with Kjelt here:

I am seeing the usual pitfall engineers make, and I also made a lot:

You start with the hardware and software.

You should start with: what problem of a user would I like to solve?
What would be its purpose?

It is a bit of a wondering brain branching into a wish for a solution still looking for a problem that has to be solved...

I am (loosly) thinking into the direction of test and measurement equipment. I've already got a RS485 based network running in between a bunch of microcontrollers, and the first application I think about is having those networked modules have a "default" program, that is then extensible by loading extra software modules.

This can (sort of) be realized by implementing a bootloader that works over that RS485 network, but that has the disadvantage that it has to re-program the Flash each time.

With "modern" I also mean I have no interest in soldering hundredths connections together for something that easily fits into a single microcontroller. microcontrollers have now become much more powerful then the old 80486DX used to be, but as the are generally still used as uC's, they usually just run a single program stored in their internal memory.

The Pine64 Ox64 mentioned by BurceHoult looks like the closest thing yet.

[Doctorandus_P]

Yesterday I found Chibios SB (= Sand Box) and that is pretty close to what I wanted.

Quote:

A sandbox is a full C/C++ application with its own startup file, main() function and its own copy of C runtime library. The API module provides means of communication between the sandbox application and the privileged application (acting as a standalone OS), in addition, a basic Posix-like API is provided to the sandbox application for console I/O. The privileged application can define its own extensions to the sandbox API.

Source:
http://www.chibios.org/dokuwiki/doku.php?id=chibios:products:sb:start

Another option would be to just use a bootloader, and replace the whole program.

But everything put together it's probably not worth it. Complete SBC's are so cheap, and on top of that have many interfaces (uSD, TFT, etc) that applications for this would be quite a small niche.

[rstofer]

.. If you remember DEC and the 16 bit PDP-11 (nostalgia buffs encouraged to contribute!), then go forward unto the VAX, well that's what this sucker looks like to me. ..

I've been running the almost fully configured PDP11/70 (20MHz, 4MB ram, 64bit FPU, MMU, various FSes/Disks on an SDcard, project includes a terminal core to interface to a VGA screen and PS2 keyboard, etc. etc.) on an oldish cycloneII fpga board ("PDP2011" project). Works great with latest patched 2.11BSD (and around 4 other DEC OSes)!
C, Fortran, Basic etc compilers inside the ready to run 2.11BSD FS image you may download.. 

I loved the university's PDP 11/70 in 1981/2. Beast. If your program fit, then it probably ran faster than on the VAX that appeared next to it in late 82.

It was totally slaughtered in every way except disk I/O by the 128k Mac in early 1984.

The Mac's 68000 very similar to program to the PDP-11 too -- much more so than ARM. You lost full memory-to-memory operations (except MOV), having only memory-to-register, but you got twice the registers, and 32 bit arithmetic and addressing.

Today you can run full Linux on a board that costs less than $10 and has 500x the CPU power and 500x the RAM too.

Or xv6, a modern reimplemention of PDP-11 Sixth Edition Unix, if you want.

Here's a PDP-11/70 clone based on the Raspberry Pi and a few flavors for the OS
https://obsolescence.wixsite.com/obsolescence/pidp-11

For the Z80 and CP/M crowd:
https://rc2014.co.uk/

Build a daughter card with a couple of USB serial ports (FTDI) and a Compact Flash for CP/M and watch a 48 MHz Z80 rip through the PL/I compiler:
https://www.digikey.com/en/products/detail/zilog/EZ80L925148MODG/4733085

[Doctorandus_P]

Those suggestions are quite far off from the direction I'm thinking in.

I have no interest in simulating an old PDP11.
I don't like all the soldering work of old Z80 bus with loads of parallel buses. or even a 16-bitter with an even bigger wiring jumble.

But I am interested in the bus Idea such as with the RC2014, but then with a serial based bus. Maybe uart, SPI or even quad SPI based, but it must support multiple channels. (I have not worked out the details yet). The goal is that each extension card is just a microcontroller as a "smart peripheral", and the backbone provides power and data exchange. Main goal is test and measurement, but also tinkering and experimentation. Therefore it's also going to get a single cable interface to a uC on a breadboard.

But I'm drifting a bit here. The main task of this thread is how to get user loadable software on such a microcontroller based design.

[dietert1]

We did it many years ago splitting the firmware for a MSP430 based medical device into system and application. Maybe two or three months of work. The firmware had a UART interface with a packet protocol (as in Kermit) with "ports" (as in IP). There are ports for boot messages, for application load and many free ports for application communication. This became part of the system, with a new call interface. The system can run multiple applications if they are well behaved. There is no scheduler, so everything needs to be implemented in interrupts and their coroutines.
The tricky part was the flash programming routines as they had to run from RAM memory and all applications need to stop before flash programming. That MSP430 has a special flash check mode to support refresh of flash memory content before it fails. Once more a bit tricky to perform the refresh on system flash blocks. Meanwhile we can even load an application that does a system update. And there is encryption for application firmware, so we can hand out application firmware for updates.
The MSP430 has a built-in boot loader "BSL" but that requires a special boot sequence (extra hardware). Don't know whether one can extend the STM32 boot loader into a practical OS.

Regards, Dieter

[iMo]

Years back on the "old stm32duino" forum I had a long thread with my experience with running user binaries off the external sram. I have stm32F103 and stm32F407 boards (xxxxpills) with an on-board 512kB of sram (just soldered in the $1 sram chip, the pads were already there), accessible to the mcu as a part of its memory space (via the FSMC interface). I wrote a small "loader" which read the binary off an sdcard (like "load myprog1.bin"), it loaded .bin into the external sram and ran it from there as a normal user program.
It worked.
Of course, the running a binary off an external sram is slower compared to running it off the internal flash or off the internal sram.

Those various new flash-less mcu chips are loading the binary from the external flash into the internal sram (and executing the binary from there) the same way, imho.

[brucehoult]

Those various new flash-less mcu chips are loading the binary from the external flash into the internal sram (and executing the binary from there) the same way, imho.

It's usually a 16 KB or 64 KB or so internal instruction cache, not copying the whole program, certainly for the ones with megabytes of external flash.

[SiliconWizard]

Those various new flash-less mcu chips are loading the binary from the external flash into the internal sram (and executing the binary from there) the same way, imho.

It's usually a 16 KB or 64 KB or so internal instruction cache, not copying the whole program, certainly for the ones with megabytes of external flash.

Yep. There are some MCUs which copy the code from Flash to RAM before executing it, but these are the exception. These days, cache-based systems are more the norm.

[DiTBho]

From 2009/10 I participated on a project called "RetroBSD". There was an active forum, today closed already.

Is there anything left of the community, or just some wiki pages?

The chip used was 80MHz pic32MX795 with 128kB of internal sram (the biggest at that time) and 512kB of flash. The chip had none MMU, but there was a workaround for it. We ran modded 2.11BSD Unix on it and it worked nice.

no MMU, which workaround? PIC? (position independent code(1))?

The filesystem was on an SDcard, also the swap file was on the same SDcard.

FAT16/32 or something more sophisticated?

I moved the swap file to an external sram afterwards (basically a 4MB ramdisk made of an xilinx cpld).

do you mean, made of static parallel ram chips, the CPLD used to /CS each of them from a given address?

There was a C compiler made (called SmallerC, something like 50-60kB large, around 2014/15) such you was able to compile your apps directly on the chip under OS. Afaik the SmallerC was able to rebuild the complete system on-chip.
The 128kB-96kB of sram was used by the kernel. The kernel itself was placed in the mcu's flash. The dev env was under linux (MIPS GCC).

is it this one? 

Smaller C is a simple and small single-pass C compiler, currently supporting most of the C language common between C89/ANSI C and C99 (minus some C89 and plus some C99 features).

The compiler self-hosts on DOS, Windows, Linux and Mac OS X meaning it can compile under and for all four OSes and it may additionally be used to write bootloaders and other parts OS running in Real Mode, Virtual 8086 Mode, Unreal Mode and 32-bit Protected Mode.

With some work you may even be able to run Smaller C in your OS (e.g. you need to port NASM/YASM or FASM (FASM is probably easier) to your OS and make appropriate changes in the Smaller C standard library to use your OS system calls instead of those for DOS, Windows, Linux or Mac OS X).

The core compiler comes with a preprocessor, a linker and a compiler driver (the driver invokes the preproccessor, the core compiler, the assembler, and the linker and supports options similar to those of GCC). The linker (smlrl) can produce the following executable formats: COM, MZ, PE, ELF, MACH-O, A.out and flat executables. Btw, COM and MZ may be booted directly with BootProg.

The standard C library is work-in-progress and it's close to completion.

Fun fact: Smaller C runs on RetroBSD on a MIPS microcontroller and fits into the 96KB of user memory

( from here, wiki dot osdev )


(1) code that can execute regardless of its absolute address, if you can force relative addressing you can allow your code to be located anywhere in memory.

[DiTBho]

But no MMU means that swapping processes is problematic. Linux isn't going to run here

24 years ago, "uc-Linux" was an experimental attempt to "adapt" the Linux-{ v2.2, v2.4 } kernel to CPUs without MMUs. It worked with several hacks to force gcc to output PIC code and a few other patches to the kernel source.

It was cute at the time, quite elegant. Unfortunately it's been abandoned for 10 years.

[iMo]

1. Is there anything left of the community, or just some wiki pages?

2. no MMU, which workaround? PIC? (position independent code)?
FAT16/32 or something more sophisticated?

3. do you mean, made of static parallel ram chips, the CPLD used to /CS each of them from a given address?

4. is it this one? 

1. Yep, I hope all the key participants are well and in a good mood
2. See below a presentation made on BSD Day 2011 by a participant
3. See the module later offered to the arduino community as well
https://forum.arduino.cc/t/8mb-ramdisk-external-ram-for-arduino/215093
4. Yes.

[DiTBho]

3. See the module later offered to the arduino community as well

so, it's not open source, what is it? kind of commercial kit with support?
I cannot see the HDL side, anyway I got how it works.

[DiTBho]

2. See below a presentation made on BSD Day 2011 by a participant

It was a key question: is it possible to implement process switching without MMU?

Kernel stack is a part of U area, it should remain at fixed address, to be used by interrupt handlers. But it must be replaced when switched to a new process. If occured, that there is a single place, where it could be implemented:

• longjmp() routine. In 4.3BSD it is called resume(). It acts much like the standard
• longjmp() jumping to previously saved thread context, but before it a U area is "remapped", resulting in a process switch

Remapping
"Remapping" is performed by exchanging a contents of U area. Actually, there are two areas: U and U0, allocated as static arrays at fixed addresses (in a linker script). We explore the feature, that a process switch could happen only from user program to swapper (process 0), or from swapper to a user program.
When a user process is running, a U area contains it's struct user and a kernel stack. At this time, U0 area contains a copy of U data for swapper. When we switch to swapper, the contents of U and U0 is exchanged. Next we switch from swapper to another user process, and they are exchanged again.
When a swapper wants to change a process, it saves the user code, data and U0 area to disk, reads another process' data from disk and calls longjmp().

So, these are the tricks 

[iMo]

The sram ramdisk kit was not open source. There is a bga psram, with an XC9572 on the bottom side of the 2 layer pcb.
The cpld does the protocol described in the picture in the link above and it interfaces the 48pin bga psram to 11 i/o signals (8data and 3 control sigs).
It was intended for usage as a file system (you load the starting address and then read or write byte by byte with the address autoincrement/autodecrement done by the cpld). We had unix driver for the module, still available in the repo, afaik.
With the swapdisk and a filesystem disk on the module the system was many times faster than with the sdcard.
We made also experiments with drams, mrams, but this one worked the best.
The module is rather obsolete today (you may get QSPI rams afaik), but otherwise a weekend exercise for talented makers here

[RoGeorge]

Mobile phones and tablets are ready made fully working computers. 
It's a pity they end up as EE waste after only a few years of use. 

Most phones are still fully functional when replaced.  Maybe it should be a law to open source both the HW and the SW of discontinued models, or at least a law for the manufacturer to provide unlock procedure and an alternative FOSS OS after some 5 years or so, in case they want to retain their software IP closed.

[DiTBho]

The sram ramdisk kit was not open source. There is a bga psram, with an XC9572 on the bottom side of the 2 layer pcb.

years ago, I made a SDRAM interface to the classic asynchronous static ram.
I used a CPLD to refresh cells and to handle both the read, write and delay cycles.
It worked, but it was a bad idea as it required too many wires for the address (16Mbyte unit, 24 lines).
Indeed it used a 40pin connector to connect the "RAM board" to the "mother board".

I will re-design it with that trick to multiplex the address on the data lines.

PRAM is also interesting.

[DiTBho]

The Mac's 68000 very similar to program to the PDP-11 too -- much more so than ARM. You lost full memory-to-memory operations (except MOV), having only memory-to-register, but you got twice the registers, and 32 bit arithmetic and addressing.

I'm still designing my architecture so things are not final and there is still the possibility to change even some ISA details, but I think "memory to memory" is nowadays a bad idea as it requires two EA phases and this makes both the CPU design and the ICE interface more complex, and as a vintage programmer, I don't actually even use "memory to memory" too much.

I am never sure about these details 

[brucehoult]

The Mac's 68000 very similar to program to the PDP-11 too -- much more so than ARM. You lost full memory-to-memory operations (except MOV), having only memory-to-register, but you got twice the registers, and 32 bit arithmetic and addressing.

I'm still designing my architecture so things are not final and there is still the possibility to change even some ISA details, but I think "memory to memory" is nowadays a bad idea as it requires two EA phases and this makes both the CPU design and the ICE interface more complex, and as a vintage programmer, I don't actually even use "memory to memory" too much.

Absolutely.

One of the reasons the "CISC" x86 was able to win was it wa only CISC that had neither memory-to-memory instructions (except the string instructions, which no one actually tried to make go fast until very recently) nor indirect addressing.

Original 68000 was about the same, but MOV is used a lot more heavily than x86's string instructions. 68020 added indirect addressing, which is yuk.

[dare]

It was a key question: is it possible to implement process switching without MMU?
...

So, these are the tricks 

Interestingly, all these issues were tackled decades before in MINI-UNIX for the PDP-11.  Around 1974, a guy at Bell Labs took version 6 UNIX and modified it to run on PDP-11 systems without an MMU and with very modest amounts of memory.  The primary target was the PDP-11/05, which maxes out at 56KiB of core.  The kernel occupies roughly the lower half of memory, while user space applications are linked to run at address 060000.  Only one process could be running at a time, so multi-programming happened entirely through swapping.  The entire system (including kernel source) fits on a 1.5MiB disk (RK05) with blocks to spare, and includes a C compiler, a FORTRAN compiler and a BASIC interpreter.

And for a gratuitous self-plug (sorry for the hijack , here is my 11/05 at VCF West running MINI-UNIX and an application I wrote to drive an addressable LED matrix:

[DiTBho]

VCF West

Well done!
Sooner or later I will parte to the CVF West, with a P-1000 MIPS (1985) running XINU 

[iMo]

The sram ramdisk kit was not open source. There is a bga psram, with an XC9572 on the bottom side of the 2 layer pcb.

years ago, I made a SDRAM interface to the classic asynchronous static ram.
I used a CPLD to refresh cells and to handle both the read, write and delay cycles.
It worked, but it was a bad idea as it required too many wires for the address (16Mbyte unit, 24 lines).
Indeed it used a 40pin connector to connect the "RAM board" to the "mother board".

I will re-design it with that trick to multiplex the address on the data lines.

PRAM is also interesting.

Yep, there is a trade off between the number of wires spent (provided there is a suitable mcu interface, like FSMC with stm32), and the performance/speed. Also the "8parallel_bits_serial" as I call it, is a pretty bad performer for a random access, of course. It works nice when always accessing say 1kB+ large sectors (or larger continuous mem spaces), as the overhead is just 3-4 writes (the address) and then you read or write the 1kB with the internal auto-increment, thus it is only 3:1024. For the random byte access it will be 3:1, what is pretty large overhead, imho

PS: the 8MB ramdisk module does not multiplex the address lines, the mcu writes the starting address via the 8bit bus into the 24bit internal address counter inside the cpld (say 3 writes), and then the mcu reads/writes byte by byte off the 8bit bus while the internal cpld address counter increments itself after each r/w. So toggling the r/w increments internal cpld address counter. The internal cpld address counter addresses the psram wired to the cpld (via the 24 address lines, for example). The interface mcu<->cpld is 8+3 wires, the interface cpld<->psram is many wires as usual..

[iMo]

• Some kind of standardized bus system for extensions. Parallel seems old fashioned, SPI can transfer 50Mbit/s and

That could be the key decision and a point of trouble as well. You have to create a "bus" which guarantee data integrity with longer wiring, and also you would need the other components hanging on the bus are addressable and comply to a certain protocol (the comm protocol you have to develop as well). Not an easy task, imho.
HW-wise some buffers for the SPI/address wires, some impedance matching (ie the bus termination, etc).
You have to have the "devices" addresses lines as well - for example 5 address wires for max "32 devices" attached. Addressing devices inside the SPI data would be pretty difficult. Thus the bus may have 10 wires with this example (Vcc, Gnd, 3xSPI, 5xAddresses) and you may use the 10pin flat cable connectors for the interconnect.

[DiTBho]

Original 68000 was about the same, but MOV is used a lot more heavily than x86's string instructions. 68020 added indirect addressing, which is yuk.

Yup, and that's why it was removed in Coldfire and "68080" (aka Natami/Vampire)