Still have the Mick & Brick book

frank freedman

Spring rearrangement time in the hobby room, this book did not go to Half-Price Books.......

Buck Rogers

My copy took a walk.... Then Amazon found me a replacement.

But even though I tracked down a <BLEEP!> load of AM29 parts, the big problem is now finding the software to properly assemble the microcode. Always wanted to assemble from bit-slice processor parts something with the intelligence to run Linux......

Heater.

If you build yourself a RISC processor using those AM29 bit slices you won't need any microcode. You just need to figure out how to set the ALU control bits for each instruction's operation. Which should be simple enough to figure out from the 2901 manual. No worse than setting up bits in many other devices. One could write a simple little program in Python or something to help a bit.

As far as I can see having the ALU and registers (the bit slices) is only a small part of the problem. There is still a ton of other circuitry to wrap around it to make a processor. A huge undertaking.

Linux...oh boy, that's huge. Now you need a memory management unit as well... The biggest problem would be getting Linux compiled for your creation. To to that end it might be an idea to build a processor design for which there is GCC support, MIPS, OpenRISC, RISC V etc.

frank freedman

There are 2 designs at the end of the book, one the HEX-29 appears to have memory management capability, the other, Super-16 does not have quite the complexity of the former. But yep, the challenge would be getting the micro-code programmed into the system. There is code in the book, but not sure how much luck one will have finding both a system to run and a copy of AMDASM. But learning the contents of the book would not be a waste as I believe the concepts still are valid. No experience with it, but seems VLSI / standard cells = Bit Slice design.........

Heater.

It's fascinating stuff. Last week or so I was absorbed by AMDs "Build a Microcomputer" book. All AMD29 series chips.

What puts me off ever attempting such a thing is the lack of a C compiler for the finished machine. But if we could make a RISC V design with 2901's all the tools are available. And no microcode needed!

kwinn

Heater. wrote: »

It's fascinating stuff. Last week or so I was absorbed by AMDs "Build a Microcomputer" book. All AMD29 series chips.

What puts me off ever attempting such a thing is the lack of a C compiler for the finished machine. But if we could make a RISC V design with 2901's all the tools are available. And no microcode needed!

You need a lot more than the 2901 chips to make a complete microcomputer. It only provides the registers and arithmetic/logic unit. To get a working system you need circuitry to read/write memory, an address counter, and quite a few control signals. That's what the other 12 chips in the 2900 family are for, although 7400 series chips could also be used for that.

Heater.

True enough. It crossed my mind to cheat. Lash up 8 AMD 2901's as the register file and ALU. Then put all that program counter, muxes, decoder and control path and memory into an FPGA.

Kind of pointless, just for the fun of seeing some 2901's working.

rod1963

AMDASM seems to have fallen into oblivion.

Still you can find microprogram assemblers written by others. Like MetalAsm. There is another microprogram assembler written in Forth as well.

You can also put together a microprogrammed cpu out of 7400 series logic. The Forth people did it with the WISC (Stack Computers by Koopman).

Here's another:
http://www.aholme.co.uk/Mk1/Architecture.htm

https://www.bigmessowires.com/nibbler/

Not as cool and trendy as RISC-V but you can learn how it used to be done. Bit sliced systems powered the space shuttle and a multitude of military aircraft and still do.

Hope this helps.

Yanomani

During several years AM2901 and its extensions were second-sourced by many other companies, like Cypress, Fairchild, IDT, Motorola, National, only to name a few.

I believe InnovASIC (after WSI (WaferScale Integration)) (IA59032 => 8 x 2901 - year 2008) was the last one to join the party, perhaps they still have it available/in production.

innovasic.com/upload/productdocuments/IA59032_Data_Sheet.pdf

IDT, a known source of dual-ported async/synchronous ram memories, also seems to had flirted (~1999) with some RISC-alike design, based on bit-slicers and dual-ported memories.

https://idt.com/document/apn/09-dual-port-srams-yield-bit-slice-designs

Cypress also sponsored some efforts(~2010), intended to grab more traction, towards other uses bit-slicers could have.

cypress.com/file/102956/download

Heater.

rod1963,

Not as cool and trendy as RISC-V but you can learn how it used to be done.

Quite so.

I've been having these fantasies of a RISC V built out of AM2901's and a bunch of TTL, ROMS and static RAMS. New RISC done old skool.

frank freedman

Heaters got it. The amd2901s are a small part of it. There were multiple chips in the set to handle microcode sequences and a whole lot more. If your gonna put all that into an FPGA, may as well put the alu in as well. Maybe someone already has a great standard "part" for that as well.

Buck Rogers

According to the logic book that AMD published on both the AM29 stuff, they also included the AM25 series of logic. Plus assorted accomplishments that were attachable to others.

But one specific grouping in the AM29 series stands out, they were designed especially for DEC for their systems which were designed around the AM2901.

Several PDP-11 designs used them, as did the LSI-11. But sadly not all.

I'd give anything to find a working H-11 system and that one is a Heathkit designed clone of the LSI-11 series.

I'd have to take a good look at their book again. And of course see for myself what is in it.

Heater, look up the LCC compiler. That there is the clue to the whole problem.

kwinn

Heater. wrote: »

True enough. It crossed my mind to cheat. Lash up 8 AMD 2901's as the register file and ALU. Then put all that program counter, muxes, decoder and control path and memory into an FPGA.

Kind of pointless, just for the fun of seeing some 2901's working.

Not really pointless if it's done for the satisfaction of seeing if one can do it. I don't see that creating the microcode would be any more difficult than building the hardware. If necessary it could be done by hand using pencil and paper or with a spreadsheet. I used 2708 chips to convert individual digit and control signals to ascii data that was output as both parallel and serial data. The bit patterns were produced with pencil and paper, converted to hexadecimal, and entered to the eprom programmer by hand. Same thing could be done for the microcode.

frank freedman

@kwinn, seems a lot of the projects here are for the purpose of learning something or just seeing "if it can be done". Well, except maybe jonnymac and the parallax peeps who actually get to do the above for a living! (Pay no attention to the slightly green shade behind this post!)

Heater.

Frank,

If your gonna put all that into an FPGA, may as well put the alu in as well

Very true. Driving 2901's from an FPGA would be a useless exercise. Except for the fun of getting those old chips working. Which is an itch for me as I was totally fascinated by them back in 1980 when working with a team that had built their own mini-computer using them.

Anyway, if I were putting the register file and ALU into FPGA I would not bother emulating the 2901. I did my register file like this:

class RegFile extends Component {
  val io = new Bundle {
    val instruction = in UInt(32 bits)
    val wd = in SInt(32 bits)
    val en = in Bool
    val rs1 = out SInt(32 bits)
    val rs2 = out SInt(32 bits)
  }
  val rs1Address = io.instruction(19 downto 15)
  val rs2Address = io.instruction(24 downto 20)
  val regFile = Mem(UInt(32.bits), 32) init Seq(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
  io.rs1 := S(regFile.readAsync(address = rs1Address))
  io.rs2 := S(regFile.readAsync(address = rs2Address))

  val wa = io.instruction(11 downto 7)
  val rfWen = True
  regFile.write(wa, U(io.wd), io.en)
}

And the ALU like this:

class Alu extends Component {
  val io = new Bundle {
    val op1 = in SInt(32 bits)
    val op2 = in SInt(32 bits)
    val aluFun = in Bits(4 bits)
    val alu = out SInt(32 bits)
  }
  switch(io.aluFun) {
    is (ALU.ADD.asBits) {
      io.alu := io.op1 + io.op2
    }
    is (ALU.SUB.asBits) {
      io.alu := io.op1 - io.op2
    }
    is (ALU.SLL.asBits) {
      io.alu := io.op1 |<< U(io.op2)
    }
    is (ALU.SLT.asBits) {
      when(io.op1 < io.op2) {
        io.alu := 1
      }.otherwise {
        io.alu := 0
      }
    }
    is (ALU.SLTU.asBits) {
      when(U(io.op1) < U(io.op2)) {
        io.alu := 1
      }.otherwise {
        io.alu := 0
      }
    }
    is (ALU.XOR.asBits) {
      io.alu := io.op1 ^ io.op2
    }
    is (ALU.SRL.asBits) {
      io.alu := io.op1 |>> U(io.op2)
    }
    is (ALU.SRA.asBits) {
      io.alu := io.op1 >> U(io.op2)
    }
    is (ALU.OR.asBits) {
      io.alu := io.op1 | io.op2
    }
    is (ALU.AND.asBits) {
      io.alu := io.op1 & io.op2
    }
    default {
      io.alu := io.op1
    }
  }
}

To easy

Heater.

@Buck Rogers,

Heater, look up the LCC compiler. That there is the clue to the whole problem.

I know about the LCC compiler. That would be an interesting way to go if you come up with your own instruction set.

It's just that I'm not attracted to the idea of tweaking with a compiler's code generator when working RISC V tools are available.

But that is just me.

@kwinn,

I don't see that creating the microcode would be any more difficult than building the hardware.

I'm not sure.

When I see "microcode" I think "microcode engine", as described in the AMD 2900 docs. Looks pretty complicated, has it's own sequence counter, subroutine call/return, a stack, etc. You have to build a lot of hardware to do that.

Where as, decoding something like the RISC V instruction set can be done with some simple logic, perhaps PROM lookup to set the control signals. No micro-code stepping.

kwinn

Heater. wrote: »

@Buck Rogers,

Heater, look up the LCC compiler. That there is the clue to the whole problem.

I know about the LCC compiler. That would be an interesting way to go if you come up with your own instruction set.

It's just that I'm not attracted to the idea of tweaking with a compiler's code generator when working RISC V tools are available.

But that is just me.

@kwinn,

I don't see that creating the microcode would be any more difficult than building the hardware.

I'm not sure.

When I see "microcode" I think "microcode engine", as described in the AMD 2900 docs. Looks pretty complicated, has it's own sequence counter, subroutine call/return, a stack, etc. You have to build a lot of hardware to do that.

Where as, decoding something like the RISC V instruction set can be done with some simple logic, perhaps PROM lookup to set the control signals. No micro-code stepping.

A "microcode engine" can be complicated or as simple as a counter that can be loaded with a starting address and incremented from there, along with a prom (and possibly some decoding logic) to generate the control signals.
Another option would be to use a Propeller to generate the control signals. It would not be fast enough to make it a practical system but it would certainly simplify the hardware and make the microcode much simpler to create.

frank freedman

My acquisition of the Mick & Brick book came while assigned to USN data systems school. @Heater, if you liked the CP-642B, you would have enjoyed phase 3. That was based on the AN/UYK-20. It was a bit slice designed emulation of a Sperry computer already in existence at the time. Week three was processor emulator, affectionately known as "personnel eliminator" due to the complexity and drop rate on that part. You could not only step through the macro instructions, you could also step through the micro instructions as well for diagnostic purposes.

Three instructors and I decided to take a road trip from Mare Island (Vallejo) to Santa Clara for a presentation AMD was doing on bit slice. It was related to the course, right? One of the gimme's for the seminar was a copy of the Mick and Brick book. Caught total 7734 for going being a lowly student and bypassing usual channels for permission to go, but was worth it. Never got around to building up a super-16. Time I could afford it, IBM pcs were out, everybody and their brother was coming up with a clone. Super-16 seemed not so worth building up.

Heater.

Back in 1980 something I was a newbie engineer in the Marconi Radar Systems labs in Chelmsford. The team there had built the Locus 16 embedded computer for the companies radar systems. The new version of which had just moved from TTL to AMD bit slice at the time. So I got totally absorbed in the 2900 data books and whatever I could find.

Moving on a couple of years, I'm working elsewhere and the PC is overtaking everything. So I put aside thoughts of the 29K stuff.

A couple of years later I was back at Marconi. After a years development of 10 guys on a new project I was testing the code on the real Locus 16 hardware. It did not work. With the help of a logic analyser I figured out that this multi-processor system failed when trying to use some kind of lock-exchange instruction.

"Oh", the processor designers said, "The lock-exchange is not implemented in the microcode of the Locus 16 version you are using"

It was soon fixed. I moved on again. All thoughts of the 29K went out of my mind. As did the whole puzzle of actually building a processor out of anything. I mean, why would anyone do that? The world is full of them.

Decades later, old and grey, I'm getting back into the idea. There is a puzzle there I did not see through to the end....

Buck Rogers

In my case I originally obtained the book and most of the parts because I had a plan along the lines of what was described here: Home Brew CPU for example look at Bill's bibliography for everything.

FYI: he's the brother to the fine individual who launched the open source router project that we call Open WRT.

Anyway fast forward to this year, and I'm no closer, but I certainly have more ideas.