Linux on an 8-bit micro

Well, really, it's been done before. That is basically what an IBM 360 model 20 was. And, the performance was about the same, too. About the only use I ever saw for one was to read mag tapes and print them out on a line printer.

Jon

On a sunny day (Fri, 30 Mar 2012 14:20:03 -0500) it happened Jon Elson wrote in :

Yes, I once started programming a PIC emulator in C. That was when we were still hacking smart cards, and I wanted to run the binary dumps of the 16F84 so to analyze them better. Showed it to someone, and he said: "Hey you did a lot of work!" So why? Because it was there, like a mountain to climb. I was not essential to anything really... But it was fun to do and a learning experience. This reminded me of that in a way.

25? Well, the only "hardware" 360 was the model-75. All[*] of the rest were microcoded, many vertically. [*] The model-195 was hardware too, IIRC, but it really wasn't a "360" (came later).

No, there was also the /44, basically the floating point engine off a /50, and no microcode. It ran a reduced instruction set, none of the iterative instructions like translate and test. Those could be emulated by an interrupt handler.

360 microcode was actually pretty horizontal for 360, but much more vertical for 709x emulation. Models up to 360/50 had capacitive read-only storage on mylar punch cards - standard-size IBM punch cards, where the punched holes were zeroes, and the intact spots were the ones. These were sandwiched between boards with hair thin wires and square pads where the punch card holes were, to form the capacitors. There was a limit to how big this array could be due to stray capacitance. 360/65 and above used magnetic ROM with wires run through or bypassing cores to form the ones and zeroes. I think the mid-range machines (/40, /50) had only a couple K words of control store. The /65 had somewhat more control store. The /20 was really a 16-bit mini running a 360 emulator, not a typical microprogrammed machine, where the physical architecture is close to the emulated machine architecture and the control store is largely for instruction decoding. The lower 370 models were much more vertical. I read through the microcode of the 370/145 and I was astounded at how vertical it was. And, so, of course, the thing performed amazingly slowly, for all the ECL and fast control store in it. The CPU alone cost several hundred grand, and could support 8 TSO users! Ridiculous!

Jon

360/30. Named it "CCROS" (Card Capacitor Read-Only Storage)

Ed

And the 360/40 used TROS (transformer read only storage) where wires went through or around cores to indicate 1 or 0.

On a sunny day (Fri, 30 Mar 2012 05:48:41 -0700 (PDT)) it happened NT wrote in :

PDP10?

IIRC it was a PDP-11. Rather smaller machine than a DEC-10.

?-)

storage

punched

And Univac called the same technology rope core memory. Oh well.

?-)

The PDP-11/20. So 16 bit. I didnt see the /20 specs, but later models included 15MHz clock speed and 256k RAM. Linux console only versions need much more.

NT

...

The 11/20 didn't have a memory management unit.

Typical for an instituion running timesharing would be an 11/73 (or some model number around there) with a megabyte and a memory cache. I don't know the instruction timings, but probably about 10-15 megabytes per second bus bandwidth.

The first 32 bit port was the Interdata 8/32. And then the VAX took over.

We ran it on an 11/23 with 256k, which was a probably the smallest system that could do anything. (A second or third generation PDP-11 CPU with high integration MOS ICs for the CPU). About 4-6 megabytes per second memory bandwidth. Four users at 1200 baud.

Mark Zenier snipped-for-privacy@eskimo.com Googleproofaddress(account:mzenier provider:eskimo domain:com)

IIRC the 11/40 and 11/45 was the first UNIX with MMU handling, followed closely by the 11/34 (that port was done in Queensland, and I was one of the first users and hackers of it). These Australian versions had AUSAM - Australian Universities Shared Accounting Method - which was a share scheduler. It accrued cost per I/O and CPU tick against the *user* not the process, and scheduled each user's process against other users on that basis. Standard Unix had a scheduler that maintained a "nice" value per process, which was an integer approximation to an IIR filter over usage (not to be confused with the "nice" offset that was settable).

The Interdata port was done at the University of Melbourne in 1979, while I was studying there. A VAX 11/780 was used for compiling, using a port of the Ritchie C compiler (which I started to re-target to the Interdata 7/16 - one was operating a large digitally-controlled train set at UoM at the time).

The first text emitted on the console of the nascent 8/32 port was:

... then silence. Ten points if you can figure out why :).

We started with 96K on the 11/34, and it was possible to support several users on that. UQ was supporting up to 16 users with 256K - but they had to be patient! But this was version 7 Unix; earlier non-MMU versions used swapping so only one program was resident at a time.

The 11/4x and 11/34 were TTL.

Clifford Heath.

I'll bite: It was wrong-endian?

Jeroen Belleman

Big-endian for words, little-endian for dwords. (or vice versa)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

While I have not personally seen the circuit diagrams of the PDP-11/20 (but studied later models quite thoroughly), the claims of 128 kiW of core definitively requires a memory management unit with 64 byte (32 word) page size.

Pictures of PDP-11/20 show 18 address switches in the front panel, i.e. 128 kW = 256 KiB core capability.

Of course, any reference to clock frequencies are more or less useless, since the core memory speed was about 1 us in those days.

And most of these machines were microprogrammed. 150-300 nanosecond cycle time.

Digging a rough chronology out of a copy of _Computer Engineering: A DEC View of Hardware Systems Design_, Bell, Mudge, McNamara, 1978 Digital Press,

the Unibus was 18 bits from the start, but the 11/20 (circa 1970) only had 16 bit addressing.

The 11/45 (1972) went (up) to a 265kibyte two port memory with memory management and a separate 'Fastbus' for CPU-main memory, with access for DMA on the Unibus. The top of the line, at the time.

The 11/40 (1973) was cacheless 256k Unibus machine, and the 11/34 (1976) was a later technology/lower cost equivalent of the /40. (Probably the most common non-LSI model). The 11/34C (1978) added a cache.

The 11/70 (1975) went up to 2 megabytes, with cache and another high speed 'Massbus' for disk transfers. Another top end machine. About 10 times the performance of a /34.

History sure can make things look bigger with time. In one of the chapters, the author of that article claims that the line was such a success, as they had sold fifty thousand of them in 1970-1977.

Mark Zenier snipped-for-privacy@eskimo.com Googleproofaddress(account:mzenier provider:eskimo domain:com)

Really ?

As far as I remember, the PDP 11/70 could only use 1 MiB of (DEC) core memory due to memory bus cable length limitations, requiring 2-4 racks.

The first time the full 4 MiB PDP-11/70 physical memory capacity was available, when using Intel semiconductor memories, fitting into a single rack, thus a shorter memory bus was sufficient. Those Intel modules used nominally 16 kib DLL chips, with one part disabled due to defects (8 kib effectively).

using

the

train

Pretty much. It gets more complicated for doubles, and strings are twisted differently.

?-)

Right, except it was a problem in the way the (VAX-based) cross-compiler emitted strings. Obviously it was handling opcodes correctly, or it wouldn't have got to putchar()