old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: "Peter "Firefly" Lund" on 5 Jan 2007 08:07 On Fri, 4 Jan 2007, Eric Smith wrote: > Microcode listings for the System/360 and System/370 seem to be really > hard to find. Someone does have a 360/30 microcode listing, but > unfortunately is not willing to make it publicly available. :( > DCJ11 chip set (two chips on a ceramic hybrid) > > VAX: VAX-11/780 > MicroVAX II > CVAX > Rigel > Mariah > Raven > NVAX I have these, except for VAX-11/780. > of the MICROM chips, but there are also two PLAs in the control > chip that can't be easily extracted and affect microinstruction > sequencing, so the MICROM contents alone would be nearly worthless. PLAs should not be too hard to extract, as long as there's no storage involved. Oh, you mean they are embedded inside some other circuitry? > The best approach to extracting the PLAs is probably to photomicrograph > the die. I don't currently know of anywhere that I can get a high- > resolution photomicrograph on a hobby (<$500) budget. I think a cheap microscope and a camera is good enough. Perhaps just a camera with a "macro" setting or a camera + a magnifying glass. -Peter
From: ChrisQuayle on 5 Jan 2007 09:25 Peter "Firefly" Lund wrote: > > Timing and race conditions are easy. Come on, race conditions, I mean, > really. Races are not hard, okay? It may be easy for half a dozen ttl devices, but by the time you have hundreds of devices, you will need to be a very competent designer to make it work reliably over component spreads and temperature. Building a vax in ssi ttl would be herculean task, but even the 11/05 was a two board hex width unibus set with hundreds of ssi ttl devices. It may be better to start with a gate array, where you might have some chance of simulating the design. If ttl, how will you wire it all up ?. Hint: I still use wire wrap for quick "what if" style prototyping, ancient as it is, because it's fast, easy to make changes and allows good control over component placement, wire length etc. Prestripped wires and an electric ww tool make it a snap. You will also need a logic analyser and scope. Nothing too expensive, 100Mhx or better Tek *analogue* scope and 50 Mhz hp analyser should be enough spec to get started. If you can find a cheap digital pattern generator as well, so much the better. >> Here we differ - compared to other architectures, x86 was hard work at >> both hardware design and assembler level. The cleanest from Intel was >> the pre x86 8080, > > > What?!?! How many different voltages did you need to supply to it? And > in what order did they have to turned on and off? And you are telling > me that it was easier to interface to it than the 8086/8088? I think we are slightly at cross purposes - the comparison was between x86 and 68k, both the same sort of timeframe. Care to recomment ?. > I don't know enough about TMS9900 and TMS99000 to have an opinion other > than its design led to good interrupt response times and must have/would > have become a pain when CPUs got faster faster than RAM chips did > (almost all "registers" were really just a small workspace in RAM > pointed to by a real register). Actual memory use, such as array > indexing, was a bit slow, wasn't it? And 16-bits only? > Have never used them, but the ti series minis and later micros were quite elegant in concept. The large registers set (128, iirc) was off cpu in main memory with just an on cpu register pointer. The main advantage being fast real time context switching by just changing the register pointer to point to a different area of memory. Thus no multiple register saves. The obvious disadvantage is that you have to go out to main memory for every register access, but at the time, instruction cycle time was probably comparable to memory access time, so perhaps a reasonable compromise in terms of overall system performance. I think the last of the series put ram on chip to speed register access, but by then, it was probably too late, except for some specialised markets like aerospace, where the micro version was, I think one of the first micros to be rad hard approved. > >> compilers. To me, elegant, clean design starts at the foundations and >> is not something that can be glued on later at higher levels... > > > Really? > > Can't say I really agree. I think there is much to be said for the > incremental approach. Sometimes it produces something elegant, > sometimes it doesn't, but usually, it produces something that's useful. > > -Peter Ok, but are we talking here about architectural elegance, or something that sells ?. The two are often not synonymous, though mutually exclusive might be a better choice of words :-)... Chris
From: "Peter "Firefly" Lund" on 5 Jan 2007 09:50 On Fri, 5 Jan 2007, ChrisQuayle wrote: >> Timing and race conditions are easy. Come on, race conditions, I mean, >> really. Races are not hard, okay? > > It may be easy for half a dozen ttl devices, but by the time you have > hundreds of devices, you will need to be a very competent designer to make it > work reliably over component spreads and temperature. Building a vax in ssi I think the trick is to make the signal flow simple. Like so many other things, it is mostly about complexity management. My microarchitecture is pipelined and has very few cycles in it where signals flow "backwards". I fully /expect/ to get in trouble, but only with the analog side of things. > ttl would be herculean task, but even the 11/05 was a two board hex width > unibus set with hundreds of ssi ttl devices. I expect 5-7 PCBs for the VAX, one per pipeline stage. I expect the ALU stage to use about 40 chips for a 32-bit wide data path. Yes, shifts and floating-point will be slow. I don't care. I am not going to implement a proper cache at first and I am not going to implement my memory with old, small chips. Instead, I'm going to interface to an old SIMM or DIMM PC memory stick. The pipeline will still have to stall when the memory isn't ready so I should be able to later implement a real cache with a memory slowed down to speeds that were realistic in 1984. > It may be better to start with a > gate array, where you might have some chance of simulating the design. Actually, I should be able to simulate it just fine with either verilog or SimSYS or both. I should even be able to statically verify parts of it (as in: with proofs). > If ttl, how will you wire it all up ?. Hint: I still use wire wrap for quick > "what if" style prototyping, ancient as it is, because it's fast, easy to > make changes and allows good control over component placement, wire length > etc. Prestripped wires and an electric ww tool make it a snap. I expect to etch photo sensitive cobber plates and then solder components (or sockets) in. As far as I can tell it is faster and much less error prone than wire-wrapping. Btw: I thought only Americans were afraid of soldering? > You will also need a logic analyser and scope. Nothing too expensive, > 100Mhx or better Tek *analogue* scope and 50 Mhz hp analyser should be I bought a nice Tektronix 502 for the purpose. It's an old analog thing with tubes from the late fifties with dual beams and sensitivity down to the microvolt range. It only claims a bandwidth of 1MHz but presumably it will go higher if I don't need too fine a sensitivity. It cost 300 DKr (slightly less than 40 Euro). As for the logic analyzer, well, I don't intend to jump straight to the VAX pipeline, anyway, so one of the training projects is a small 8-channel "logic analyzer" that samples at 40 MHz to a RAM chip which can later be read out. It will require an 8051, a TTL counter chip, and a couple of RAM chips to do interleaved writing to. I expect it to be at most 5cm x 10cm in size. It would be a good way to learn more about signal integrity issues before I can make too big mistakes. > enough spec to get started. If you can find a cheap digital pattern > generator as well, so much the better. Shouldn't be necessary with an 8051 and some TTL ;) -Peter
From: "Peter "Firefly" Lund" on 5 Jan 2007 10:11 On Fri, 5 Jan 2007, ChrisQuayle wrote: > I think we are slightly at cross purposes - the comparison was between x86 > and 68k, both the same sort of timeframe. Care to recomment ?. Sure. First of all, they weren't /really/ in same time frame. The 8086/8088 got there years before the 68K. That tends to matter. Secondly, the 8088 could easily use existing peripheral chips designed for the 8080/8085/Z80. That also tends to matter. As far as I can tell, the 8086/8088 was also easier to interface with than the 68000/68008. I'm referring both to how you hook up memory and I/O devices, how interrupts are handled, and how the initial bootup is handled. That also tends to matter ;) -- but since I'm not nearly as sure about this point I won't belabor it. I might be wrong here. As for the programming model, I much prefer the 68000 over the 8086/8088, if we ignore compatibility issues (which tend to matter). Even if the 68000 had those annoying alignment issues (which tend to matter). Notice I wrote "68000" and "8086/8088". You could consider the partitioning of registers into address registers and data registers a mistake (I won't but some do). By the time of the 386, the "stiffness" in the allowed register use was almost entirely gone (at a decoding cost). I consider this a case of adding stuff to gain elegance ;) When you introduce MMUs and floating-point, I think the x86 wins. Yes, I think the 286 was mostly a mistake but by the 386 those mistakes were mostly fixed and the clumsy segmentation model could be mostly ignored. I also think the later models of the x86 handled self-modifying code better than the later models of the 68K. That's actually important, sometimes. Some of the 68K models used different exception stack frame formats than others, without having a compatibility flag. The x86 didn't make that mistake. I think I could dig up both more points like these and more details but I think I'll stop here :) >> I don't know enough about TMS9900 and TMS99000 to have an opinion other >> than its design led to good interrupt response times and must have/would >> have become a pain when CPUs got faster faster than RAM chips did (almost >> all "registers" were really just a small workspace in RAM pointed to by a >> real register). Actual memory use, such as array indexing, was a bit >> slow, wasn't it? And 16-bits only? >> > > Have never used them, but the ti series minis and later micros were quite > elegant in concept. The large registers set (128, iirc) was off cpu in main I think it was only 16 for the TMS 9900. > memory with just an on cpu register pointer. The main advantage being fast > real time context switching by just changing the register pointer to point to > a different area of memory. Thus no multiple register saves. The obvious > disadvantage is that you have to go out to main memory for every register > access, but at the time, instruction cycle time was probably comparable to > memory access time, so perhaps a reasonable compromise in terms of overall > system performance. I do think it was a good idea at the time. > Ok, but are we talking here about architectural elegance, or something that > sells ?. The two are often not synonymous, though mutually exclusive might be > a better choice of words :-)... I think something that sells almost always has what could be called "elegance" but only if the entire system is considered. What is usually called "elegant" is only elegant if one only considers a small part of the whole. One might consider the ARM's approach to constants elegant (emit instructions to generate them) but when one has to define an object file format and linkers/loaders/assemblers/compilers to handle that, the perceived elegance tends to diminish ;) -Peter
From: drhowarddrfine on 5 Jan 2007 10:11
Peter "Firefly" Lund wrote: > On Thu, 4 Jan 2007, Del Cecchi wrote: > >> You are going to build a VAX out of LSTTL just like back in the day? > > Yes. > > -Peter I've threatened to do something similar for many years. Cool. Good luck to you. |