Modern micro computer idea.

[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)