Dwight K. Elvey wrote: ... ... Speaker of core memory, I used to work for a company that was still shipping core-based systems in 1985, when I first joined them right out of college. The machine was the "BTI 8000", made by BTI Computer Systems, based in Sunnyvale, CA. I worked there for only a year, but I have some recollection of the machine. It was a multiprocessor 32b super minicomputer with a really odd architecture (I wish I had kept the arch manual). BTI started in the late 60's at a timesharing service provider, became for a time phenominally successful reselling 16b HP 3000 machines bundled with auto dealership software, then got big for their britches and invested everything in developing the BTI 8000. When I joined in 1985, they were just bringing up the first DRAM based memory board when I joined. One of the jobs I did in my year there was to address some of the outstanding bugs in the core memory controller. It was a microcoded controller! Just about everything at BTI was microcoded. The cards were big -- probably 30" x 36". Warping was a big problem. Many of the cards were wirewrapped by machine, partly because at that time making PC boards that large with enough layers was not practical. Some cards were layed out as much as possible with a two layer board, then the rest was put on with wirewrap. Everything was TTL (mostly S and F) and no PALs as they were too slow (35ns) at that time. They had a "big system" mentality despite the volume not justifying it. For example, many cards had diagnostic processors. The CPU had a diagnostic Z80 that would run self test on the CPU before allowing it to "join" the bus. Same with the memory card. Same with the IO processor. One to eight or so processors could be in a system. Some systems had small backplanes (6 slots?), some had big (16 slots or so) backplanes. The CPU had no cache and a small register file. The CPUs were completely symmetric. At a time slice the few dozen registers would be saved off to a process state area and the next time another CPU was free, it would pick up the process state and continue on. You could power off the machine with the master power button, then flip it back on 30 seconds later and (most of the time) things kept running like nothing had happened. The instructions were 32b, but the address space per process was 20b IIRC. Those extra 12 bits were used for all kinds of strange addressing modes. For example, besides the usual pointer to memory, you could have a pointer to a register -- or a pointer to a field of a register! Yes, there were instructions like "increment bits [17:5] of R3". The emphasis was on density of encoding, not speed of decoding. The CPU was on the 5th generation by the time I got there, as the machine was originally designed in 1977 or so. The 5th gen CPU used eight 2910 bit slices. Earlier machines had used 74S181 slices. The bus was synchronous and ran at 15 MHz. There were low priority and high priority requests, but only those two levels. You could do a single read, a single write, double word read, or double word write. Reads were split and pipelined, but a given master could have only one transaction outstanding at a time. The system used a very clever distributed arbitration scheme (again, with two levels for low and high priority requests). The system software was almost all written in assembly language. They had their own made up language called "dragon". They had their own editor, own mail system, compilers (BASIC, Pascal, COBOL, RPG, but no C). Just about everything was written in-house. Some googling indicates the company still existed in some for up until at least 2002, still in sunnyvale. They seem to be out of business now.