My favourite is. "The Elements of Computing Systems". Building a Modern Computer from First Principles.
It's an oldie but a goodie. It is still available, you can download the course and software complete with the Hack assembler and VM emulator. It's free.
For those considering building this on a FPGA, the book is value for money, well worth reading.
Looks like one can still obtain AMD2903 ALUs chips. Or beautiful Russian clones, white ceramic packages and gold plated pins. Might be fun to put 8 of them on a board and make an ALU with registers at least.
It seems to me that it would be easier to make a simple 32 bit CPU than a 4 or 8 bit one. With a simple 32 bit CPU you can at least fetch an entire instruction with a single memory read. 4 or 8 bit CPUs are likely to require multiple memory reads for at least some instructions.
I think that is true. From a understandability perspective. A RISC V is pretty simple to think about for example
Problem is, if you are building it from chips you need a lot of them. And that is a lot of connections to make if you want to be old school and bread board it, wire wire wrap it etc.
The RISC V project I linked to above will need 186 sixteen bit latches just for the registers! (I'd probably want to use static RAM chips for the registers in that case).
Then there is the ALU. Traditionally people used the 74181 four bit ALU chip.
There's a guy who is trying to build a RISC V out of discrete parts. I believe he's making it all out of DIMMs. The registers alone are costing him hundreds of dollars. I don't know if he planned it all out at first, but I saw a video of the register cards here:
He wants all the registers to have LEDs, all 32 of them! That means 30% of his 16 bit register chips are just for driving LEDS.
I'm sure using eight 8 bit static RAMs would be a far cheaper way to build a register set with the dual output ports. And would shrink his 32 register PCB's to just one.
Hmm...now I remember I have a tube of such RAMs here somewhere....
Oops. But I think we're in agreement about the approach. On top of that why not just go for the RV32E and only support 16 registers?
Luke Valenty @TinyFPGA was working on a microcoded RISC V which he called a tiny RV32I core, but he might have put it on the back burner due to his work on the USB boot loader. Last I heard "Logic usage isn't too bad either. It's not quite half the size of an equally configured picorv32 in this particular picosoc setup. But there may be an issue with how I'm coding my register file and microcode store that's preventing Yosys from using BRAMs for those." Maybe his approach could be translated into an AMD2900 approach.
I also wondered why not the RV32E. I guess size is not a constraint, it's going to be huge anyway. And he's decided the extra dollars is worth the "wow" factor.
There is something appealing about the idea of trying to build the modern RISC V architecture out of AMD2900 chips. They were kind of part of of the RISC ideas fermenting at the time.
It's amazing to find what famous machines they were used in: Apollo workstations, Data General Nova, Some DEC PDP-11, Xerox Star, Ferranti Argus, UCSD Pascal P-machine, some Atari games machines.
Not to mention the Marconi Locus 16 that I worked on a software project for in 1980 something.
4x AMD 2901 bit-slicers were used for the ALU in the Norsk Data ND-100 minicomputers as well. I have a number of 30ns CY7C9101 chips laying around, one of them "replaces four 2901s with carry lookahead logic", as it says in the datasheet.
I think that is true. From a understandability perspective. A RISC V is pretty simple to think about for example
Problem is, if you are building it from chips you need a lot of them. And that is a lot of connections to make if you want to be old school and bread board it, wire wire wrap it etc.
The RISC V project I linked to above will need 186 sixteen bit latches just for the registers! (I'd probably want to use static RAM chips for the registers in that case).
Then there is the ALU. Traditionally people used the 74181 four bit ALU chip.
Yes, it's certainly true that a CPU built from chips will have lots more chips with a 32 bit design. For an FPGA implementation it won't matter much though.
Right now I'm only dabbling with two. My 8085 with a prom and ram and a 8 bit logic gate CPU. Simple only has MAR, ALU, A, B, instruction register, PC, etc.
I think I've decided that this project also needs a virtual emulator or maybe simulator....
This means making a virtual version of the Newhaven 2x16 LCD module.
That means extracting the ROM font from the datasheet.
Think I have it though, see attached.
BTW: I think it might be fun to have a virtual 2x16 character LCD module program for PC.
Sure, you could use PST, but this might be interesting too...
AMD 2900. Have not heard that in decades. Went to a conference in Santa Clara with some of my Navy data systems instructors in the early '80s. Still have the Mick and Brick book from that trip. If i recall, it contained all the hardware schematics and microcode to emulate the 8080 or Z80 to illustrate the books theory. Perfect excuse for the less than authorized day trip, the An/UYK-20 was a bit slice design emulating a Sperry computer. The processor emulator part of the course was affectionately referred to as the personnel eliminator. And you could step through the micro instructions as well as the macro instructions.
Sorry to be a diversion to the 4 bit CPU conversation.
It's interesting to find that the original ARM was built with 25000 transistors. Which compares to the 29,000 transistors of the Intel 8088 of the original IBM PC.
Which implies that if the Intel guys knew what they were doing back in 1979 we could have had 32 bit computing on our desks almost 20 years before we actually did!
At the time guys building proper computers, Apollo, DEC, Data General, etc, used the AMD 2900 chips.
Back to the 4 bitter idea...
It might be fun to get hold of a 4 bit Am2901 slice and see what one can do with it.
Or one could build a bit slice Propeller with 64 Am2901 chips !
Sorry to be a diversion to the 4 bit CPU conversation.
It's interesting to find that the original ARM was built with 25000 transistors. Which compares to the 29,000 transistors of the Intel 8088 of the original IBM PC.
Which implies that if the Intel guys knew what they were doing back in 1979 we could have had 32 bit computing on our desks almost 20 years before we actually did!
At the time guys building proper computers, Apollo, DEC, Data General, etc, used the AMD 2900 chips.
Back to the 4 bitter idea...
It might be fun to get hold of a 4 bit Am2901 slice and see what one can do with it.
Or one could build a bit slice Propeller with 64 Am2901 chips !
The Z80 had 8,500 transistors. While the 8086 and 8088 were more advanced than the 8080 or Z80, it seems that Intel put a lot of Smile in the 8086/8088 chips, and we are still paying for that Smile today
Interesting facts...
8086 used 3um and 33mm2
68000 had 68,000 transistors 4um 44mm2
Pentium II 7,500,000 transistors 350nm 195mm2
P8X32A 360nm? ? Transistors ?mm2
Poor old Intel did try to get of the 8080 treadmill, many times.
When the 8088/86 was launched they had already spent a couple of years designing the 32 bit i432. That design ended up so huge, complex and slow that it got canned and the 8080 upgrade to 8088/86 was thrown together in a matter of weeks to keep up with the market. I once had an advance data book for the i432, I could not fathom how anyone would ever program it!
Then in 1989 Intel tried to get us off the 8080/88/86 architecture the the 32 bit i860. A kind of RISC machine. That thing turned out to be impossible to program as well. As a result real world performance sucked and it was canned. I attended a presentation on i860 programming at it's launch show in London. The Intel guy had to admit that Intel itself could not figure out how to extract the maximum possible FLOPS in an FFT (Another company had managed it though)
Intel kept tying though. In 2000 they came with the Itanium. Well, you know... yet another impossible to program machine.
It was down to AMD to continue the 8080 tradition into the 64 bit world.
Itanium was actually fine. We had an Itanium server here at work. Fastest box in the house at the time. Nice machine. Good compilers. But AMD with its 64-bit x86 extension killed Itanium. Of course Intel was focusing too much on the high-cost server market and didn't realise the desktop potential until too late, and when the AMD extension was in the wild there was no going back.
Speaking of home brew CPU's.... here is a computer built from TTL chips that is faster and smaller than the famous old 8 bit CPUs or even the first IBM PC.
SGI adapted their Mips Pro compiler to Itanium. Or at least took the same approach that squeezed a ton of performance out of Mips.
Back in the Irix days, for a time, say 6.5.10, q it was free to use, but contained nag screens in the debug output. -O3 and -O4 made big, but damn fast code. On a side bar, back then GCC couldn't reach the same performance peaks, but was otherwise quite respectable. Free too. I wonder what the GCC of today would look like in comparison?
Some of those gains were really significant.
I once compiled X Mame on an Indy R5k, and was stunned at the difference between highly optimized mode and ordinary mode. Build times were nearly double, but the results were noticeable. Like double digit gains.
The kind of gain that made the difference between many programs stuttering sound and graphics, to running smooth, with CPU to spare.
I never got to take those toys for test drive on itanium, but I'll bet SGI got that chip, and I'll bet it flew.
Yes, the Mipspro compiler was really good. Back when I was running seti@home I got a special Mipspro-compiled version for SGI, and that was the main reason I was in the top ten list of early seti@home users in the early days. An SGI with a Mipspro-compiled version could process seti@home chunks several times faster than the "standard" gcc-compiled version.
I think I still have an unused license for MIPSPro somewhere.
The 8088 and 8086 were very forward-looking chips for their time. They really weren't economically viable; they were slow despite running at a higher clock rate than most 8-bit chips, the instruction set encouraged program bloat, and they were expensive. But when IBM came along what they had going for them was they weren't Z80, as in the TRS-80, and they weren't 6502, as in Apple ][. And once IBM adopted them they had the advantage of being IBM, which made them economically viable in those early years. And while they weren't object-code compatible with the 8080, they were "source code compatible," meaning it as made as easy as possible to make a few minor changes to your 8080 assembly language program and port it to x86. This did allow a fairly large body of ex-CP/M software to quickly become available once there was a platform to justify it.
The miracle that x86 then pulled off -- and if you don't remember, it WAS a miracle -- was true object-code compatibility between generations. Every other computer line forced you to get new versions of all your software when you upgraded. But for the most part x86 would run your old software on your new computer. Nobody in consumerland had ever seen that before, and it changed the industry. It created the clone market, and the idea today that if you have software it runs on one of only a few platforms would have seemed crazy in 1980, when you had several incompatible flavors of TRS-80, Apple ][, Atari, Sinclair, Commodore, soon Coleco ADAM and kindasorta CP/M Amstrad and various business systems none of which was compatible with any of the others.
Yes that compatibility introduced cruft and complexity, particularly in the 386 and beyond, but it's easy to forget how valuable that compatibility was compared to the chaos that had reigned before.
SGI made contributions to Linux to support their hardware and carve a path without IRIX, which was basically married and very highly optimized for MIPS.
The kernel should handle a basic system. For big NUMA, last I knew there were patches. One would have to ask nicely for those.
Dang! SGI appears to have supported the Intel compilers.
I could swear there were patches for this too, but I can't seem to find a reference. Last big conference I went to, doing that for Linux and dev tools was the go forward plan.
Comments
It's an oldie but a goodie. It is still available, you can download the course and software complete with the Hack assembler and VM emulator. It's free.
For those considering building this on a FPGA, the book is value for money, well worth reading.
I just found this collection of AMD2900 family databook: http://www.decadecounter.com/vta/pdf/1979_AMD_2900family.pdf
Looks like one can still obtain AMD2903 ALUs chips. Or beautiful Russian clones, white ceramic packages and gold plated pins. Might be fun to put 8 of them on a board and make an ALU with registers at least.
Problem is, if you are building it from chips you need a lot of them. And that is a lot of connections to make if you want to be old school and bread board it, wire wire wrap it etc.
The RISC V project I linked to above will need 186 sixteen bit latches just for the registers! (I'd probably want to use static RAM chips for the registers in that case).
Then there is the ALU. Traditionally people used the 74181 four bit ALU chip.
https://www.youtube.com/channel/UCBcljXmuXPok9kT_VGA3adg
He wants all the registers to have LEDs, all 32 of them! That means 30% of his 16 bit register chips are just for driving LEDS.
I'm sure using eight 8 bit static RAMs would be a far cheaper way to build a register set with the dual output ports. And would shrink his 32 register PCB's to just one.
Hmm...now I remember I have a tube of such RAMs here somewhere....
Oops. But I think we're in agreement about the approach. On top of that why not just go for the RV32E and only support 16 registers?
Luke Valenty @TinyFPGA was working on a microcoded RISC V which he called a tiny RV32I core, but he might have put it on the back burner due to his work on the USB boot loader. Last I heard "Logic usage isn't too bad either. It's not quite half the size of an equally configured picorv32 in this particular picosoc setup. But there may be an issue with how I'm coding my register file and microcode store that's preventing Yosys from using BRAMs for those." Maybe his approach could be translated into an AMD2900 approach.
There is something appealing about the idea of trying to build the modern RISC V architecture out of AMD2900 chips. They were kind of part of of the RISC ideas fermenting at the time.
It's amazing to find what famous machines they were used in: Apollo workstations, Data General Nova, Some DEC PDP-11, Xerox Star, Ferranti Argus, UCSD Pascal P-machine, some Atari games machines.
Not to mention the Marconi Locus 16 that I worked on a software project for in 1980 something.
Not sure I'm man enough for it though.
I did find your posts on anycpu.org http://anycpu.org/forum/viewtopic.php?f=22&t=327
and your picture of the board they were on. It's an impressive monster.
Well, not my RISC V. It's Clifford Wolf's picorv32.
Ended up getting my head stuck in AMD's "Build A Microcomputer" and "The Am2900 Family Data Book" instead.
This means making a virtual version of the Newhaven 2x16 LCD module.
That means extracting the ROM font from the datasheet.
Think I have it though, see attached.
BTW: I think it might be fun to have a virtual 2x16 character LCD module program for PC.
Sure, you could use PST, but this might be interesting too...
It's interesting to find that the original ARM was built with 25000 transistors. Which compares to the 29,000 transistors of the Intel 8088 of the original IBM PC.
Which implies that if the Intel guys knew what they were doing back in 1979 we could have had 32 bit computing on our desks almost 20 years before we actually did!
At the time guys building proper computers, Apollo, DEC, Data General, etc, used the AMD 2900 chips.
Back to the 4 bitter idea...
It might be fun to get hold of a 4 bit Am2901 slice and see what one can do with it.
Or one could build a bit slice Propeller with 64 Am2901 chips !
The Z80 had 8,500 transistors. While the 8086 and 8088 were more advanced than the 8080 or Z80, it seems that Intel put a lot of Smile in the 8086/8088 chips, and we are still paying for that Smile today
Interesting facts...
8086 used 3um and 33mm2
68000 had 68,000 transistors 4um 44mm2
Pentium II 7,500,000 transistors 350nm 195mm2
P8X32A 360nm? ? Transistors ?mm2
Poor old Intel did try to get of the 8080 treadmill, many times.
When the 8088/86 was launched they had already spent a couple of years designing the 32 bit i432. That design ended up so huge, complex and slow that it got canned and the 8080 upgrade to 8088/86 was thrown together in a matter of weeks to keep up with the market. I once had an advance data book for the i432, I could not fathom how anyone would ever program it!
Then in 1989 Intel tried to get us off the 8080/88/86 architecture the the 32 bit i860. A kind of RISC machine. That thing turned out to be impossible to program as well. As a result real world performance sucked and it was canned. I attended a presentation on i860 programming at it's launch show in London. The Intel guy had to admit that Intel itself could not figure out how to extract the maximum possible FLOPS in an FFT (Another company had managed it though)
Intel kept tying though. In 2000 they came with the Itanium. Well, you know... yet another impossible to program machine.
It was down to AMD to continue the 8080 tradition into the 64 bit world.
https://hackaday.io/project/20781-gigatron-ttl-microcomputer
Imaging that. They needn't have bothered with using microprocessors at all in the late 1979's early 80's !!
Back in the Irix days, for a time, say 6.5.10, q it was free to use, but contained nag screens in the debug output. -O3 and -O4 made big, but damn fast code. On a side bar, back then GCC couldn't reach the same performance peaks, but was otherwise quite respectable. Free too. I wonder what the GCC of today would look like in comparison?
Some of those gains were really significant.
I once compiled X Mame on an Indy R5k, and was stunned at the difference between highly optimized mode and ordinary mode. Build times were nearly double, but the results were noticeable. Like double digit gains.
The kind of gain that made the difference between many programs stuttering sound and graphics, to running smooth, with CPU to spare.
I never got to take those toys for test drive on itanium, but I'll bet SGI got that chip, and I'll bet it flew.
I think I still have an unused license for MIPSPro somewhere.
For example this SGI Altix 350 Server for 50 dollars:
https://www.ebay.com/itm/SGI-Altix-350-RAck-Server-CMN026-Dual-Itanium-2-8GB-RAM-No-HDD/292452832368?epid=1604845005&hash=item44178c1470:g:0G0AAOSwcN1aX5CH
But how would I know it worked? Where would I get an OS from?
The miracle that x86 then pulled off -- and if you don't remember, it WAS a miracle -- was true object-code compatibility between generations. Every other computer line forced you to get new versions of all your software when you upgraded. But for the most part x86 would run your old software on your new computer. Nobody in consumerland had ever seen that before, and it changed the industry. It created the clone market, and the idea today that if you have software it runs on one of only a few platforms would have seemed crazy in 1980, when you had several incompatible flavors of TRS-80, Apple ][, Atari, Sinclair, Commodore, soon Coleco ADAM and kindasorta CP/M Amstrad and various business systems none of which was compatible with any of the others.
Yes that compatibility introduced cruft and complexity, particularly in the 386 and beyond, but it's easy to forget how valuable that compatibility was compared to the chaos that had reigned before.
SGI made contributions to Linux to support their hardware and carve a path without IRIX, which was basically married and very highly optimized for MIPS.
The kernel should handle a basic system. For big NUMA, last I knew there were patches. One would have to ask nicely for those.
Dang! SGI appears to have supported the Intel compilers.
https://wiki.ncsa.illinois.edu/display/ITS/Programming+Environment+on+NCSA+SGI+Altix+UV+System
I could swear there were patches for this too, but I can't seem to find a reference. Last big conference I went to, doing that for Linux and dev tools was the go forward plan.