This might be a good time to point out that the presence of PROMs doesn't automatically imply the presence of "microcode" since PROMs were often used for instruction decoding and other simple logic functions. Microcode implies the presence of a low-level processor, and I saw little of that up to the point at which bit-slice, e.g. AM2900-series or Intel 3000-series, became popular, though PROMs did appear from time to time in functions other than simple microcode. I've built CPU's using standard TTL MSI/SSI devices, without any sort of microcode, and, since that was in the days before PALs, bipolar PROMs were the only handy programmable device that allowed simple localized decoding and steering without discarding resources. The fact they can easily provide a preset to a cycle counter, based on their inputs even though there might be a "sparse" lookup table for that function, saved both time and real estate, often rendered PROMs the vehicle of choice. Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Tuesday, April 09, 2002 12:34 PM Subject: Re: TTL computing

Tony, you're wandering into the semantic quagmire of distinction between hardware and firmware and software. The difference between microcode and other firmware, used, for example, to define a state machine, is that the "microcode" is executed by a processor of some sort that is an entity unto itself. Microcode is used in two-layered designs, wherein the microengine executes the microcode which, in effect, fully defines the system of which it is a component. In some cases, changing the microcode will completely redefine the instruction set, register set, cache configuration, etc. In some cases, it can even redefine the word width. That's certainly seldom the case with state machines. RISC machines were an outgrowth of work on developing code for microengines in their native mode in hopes of capitalizing on their (then) high speed relative to conventional processors. Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Tuesday, April 09, 2002 4:12 PM Subject: Re: TTL computing used implies

I think you may be mistaken there, Tony. If you wire up a set of gates to generate the outputs otherwise generated by a PROM, it's hardware, not firmware, since it's hard-wired and not programmable. Likewise, if you configure a CPLD to contain what (a logic function) would otherwise have been generated with discrete LSI/MSI/SSI logic, it's still firmware. From what I have gathered over the years. If it can't be removed hardware or firmware. If it's possible to remove it and leave the device/system of which it's a component intact, having simply removed that one function it's probably firmware. If it is copied from one medium to another before it becomes part of the system, it's probably software, particularly if it resides in a locus capable of being routinely modified, it's probably software. (notice the need for "wiggle-room")/ I don't know where this leaves things like CDROMs, FLASH memory, FPGA's (which are configurable in their internal RAM from an external ROM or whatever) since they seem to blur those boundaries. However, you'll play hell trying to modify the contents of Wozniak's state-machine PROMs, so that's probably firmware or hardware, though it relies heavily on what's probably software to help it work properly, while you'll have trouble convincing anyone that the stuff on a floppy diskette is anything other than software, even though it might be the microcode that makes your '370 run. Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Tuesday, April 09, 2002 6:21 PM Subject: Re: TTL computing of changing width.

----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Wednesday, April 10, 2002 3:09 PM Subject: Re: TTL computing A ROM chip doesn' have firmware, since it's hard-wired at the factory. A PROM/EPROM/EEPROM, PAL/GAL, CPLD, FPGA or whatever, that you can program to suit your own definition, falls in a different class. A RAM, which doesn't retain that definition between power-on cycles, falls into a different category. removed I said it was a quagmire, didn't I? It happens that some folks differentiate between hardware and firmware based on whether you can touch it or not. You can't touch firmware, at least not in a practical sense, just as you can't touch software. It happens that both firmware and software can live in hardware. If you can touch it, however, it's hardware. Have you ever touched software? I suppose you could touch firmware in the form of a bipolar PROM in a ceramic package that got too hot, exposing the device, including its fuse array, and you could even read it, which you certainly can't do with software on a diskette without external equipment. Of course you can read software on a paper tape as well ... The distinction between hardware and firmware is in that you can't tell from looking at the part as you buy it, what it's going to be. If you buy a 7474, you know it's going to be a 'D' flipflop with positive-going clock and negative-going direct set and direct clear inputs, and true and complement outputs. It doesn't go without saying that you won't use it as an R/S flipflop, but its definition as a 7474 does define what its capabilities are. That's true in a much more general sense of PALs, FPGA's, and EPROMS, too, but not so much, and the distinction lies in the gray area somewhere. The fact is that some devices, devices being hardware, were intended to hold firmware. That's their function. They are hardware, but they hold firmware. Firmware is like software, except that it's not so easy to change, and, though it stays on the hard or floppy disk, it doesn't stay in the memory into which it's loaded when the power goes down. If it does, it's firmware. Now that brings up the matter of battery-backed RAMs ... If you take out the hard disk, you've removed the piece of hardware whereon the software resides. If a piece of code has to be loaded into a memory from which it executed by the CPU each time it's required, i.e. when the power is turned on, it's probably software. Now, the contents of an FPGA have to be loaded from an EPROM or EEPROM of some sort, either directly or indirectly via a processor or other means. I don't want to say that's not firmware, since it's stored in a device normally used for firmware, but it seems that it's stored in RAM, lost when power is lost, so I can't argue with someone who wants to say that what's in an FPGA is software. I can't disagree that it's firmware either, however. one another Nope ... if you can touch it, it's hardware. You can't touch firmware, and you can't touch software, though you can touch listings of them. As I said before, it's a semantic quagmire, simply because evolution of the technology has blurred the boundaries. In general, however, people seem to agree that if it is something you can touch, it's hardware. If it's something that's "there" when you turn on the power, it's firmware, and if it llives on a mass storage medium and goes away along with the power, then it's probably software. if

On Fri, 12 Apr 2002, Tony Duell wrote: Or 1/2 as an inverter for an xtal oscillator and 1/2 for div/2 (had to do that one to avoid using 1 more package) Peter Wallace

ground /reset /set is input Q is out Peter Wallace Mesa Electronics

Hello! I ve this nice question for all of you... what are the best ways to cure boxes that were out exposed to the weather for an unknown amount of time. Last week I managed to get my hands on 2 vaxstations 4000/60, a Cisco MGS, a HP Apollo 700 workstation, Sun Sparcstation 20 (WOW), a VAX 4000-300 and a Panasonic 7330. All have varying degree of dampness 8-((. At the moment I have them in house dry and warm... should I stuff them in the oven at low temperature and force a drying or best let them settle for some time. Please give me your advice. TIA e. ======================================================================== Enrico Badella email: enrico.badella(a)softstar.it Soft*Star srl eb(a)vax.cnuce.cnr.it InterNetworking Specialists tel: +39-011-746092 Via Camburzano 9 fax: +39-011-746487 10143 Torino, Italy Wanted, for hobbyist use, any type of PDP and microVAX hardware,software, manuals,schematics,etc. and DEC-10 docs or manuals ==========================================================================

On Mon, 15 Apr 2002, Enrico Badella wrote: <flamebait> Disassemble them and stick all the boards in the dishwasher! </flamebait> Seriously, I think opening them up and removing drives, adapter boards and anything that might trap water would be the first step. With that many machines, it might be well to label parts as you go.... After everything is dried, you can see what else you may need to do. It's an excellent find, in any case! Doc

On Mon, 15 Apr 2002, Jochen Kunz wrote: Never, ever, under any circumstances let bare metal air dry. It *will* corrode. This includes any chassis parts, screws, connectors, etc. It is still best to dry painted metals too, since moisture always finds tiny holes and cracks and gets under the paint. A few towels and careful use of a hair dryer will save you much grief later. The worst mistake folks down here in Houston made after the floods we had was to let gear dry out slowly on its own before cleaning it. It isn't much fun spending hours polishing out corroded computer chassis, and dried boards are much more difficult to clean. -Toth

On Tue, 16 Apr 2002, Sipke de Wal wrote: If it has methanol in it, it doesn't need anything added to make it undrinkable. Methanol causes blindness, ulcerated stomach, then death. Peace... Sridhar

Rumor has it that there is an expression "tapping the torps", which was a result of sailors drinking the alcohol fuel for torpedoes. To solve the problem, some compound was added that would make one pee bright orange. Fact or fiction, I dunno. But I've heard that from several different sources, and considering that submarine duty is considered high-stress, I wouldn't doubt that it was tried. --John

On Wed, 17 Apr 2002, Tony Duell wrote: Yeah? What about the Sterno dudes? I have with my own eyes seen people strain Sterno and drink it. Those fools *know* it's gonna do them a lot of harm. They just also have a jones on. Instant coma. Doc

A non-text attachment was scrubbed... Name: not available Type: text Size: 710 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020417/fe56543c/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 3449 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020412/fbb75669/at…

A fanatic is somebody who can't change his mind, and won't change the subject. - Winston Churchill

A non-text attachment was scrubbed... Name: not available Type: text Size: 3399 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020413/48e5440f/at…

I should add that this appears to be new. The shrinkwrap has been torn, but it doesn't appear to have been opened. Marvin Johnston wrote:

So, how's the weather over there? My Mom took a trip to the northern reaches and Isles a few years ago and IIRC, none of her pictures had blue sky or shadows in them. She and my second-cousin, who lives in Munich, wanted to do that again, since the springtime was apparently of interest to them. see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Friday, April 12, 2002 7:43 PM Subject: Re: TTL computing any It really doesn't matter which part of the core memory subsystem fails, does it? BTW, I've never had a memory failure on a PC. I've had numerous ones in varous older commercial systems, but never a hard failure in a PC memory subsystem that I can recall. I've had rotating memory troubles on occasion, but not on machines that are kept running. Considering that any one of my PC's has more RAM in it than all the core-based machines I've seen in my 30+ years in the field combined, I'd say that's a decent outcome. compute Actually, I think they still used core memories when they dropped the 16C2. The 16C2 is optimized for decoding, though, isn't it? do Nevertheless, while they have a fixed OR matrix, they have a very flexibly programmable AND array, which allows you to express any logic function of the number of inputs you have in SOP form. Keep in mind that you can use multiple macrocells to create ridiculously complex functions. I've not run into a function I couldn't express in a 42VA12. Product term depletion is quite well avoided there. If I were to find one, I'd try an ICT 7024. Those are both 24-pin devices You're running down an unimplementable path again, Tony. You can't implement all those functions in a comparable ROM either. For starters, though, let's postulate that you've got, at most, 22 inputs. (a 24-pin device with Vcc and Gnd). Each pin you use as output, of course, has feedback, but it's not an input. Nevertheless, that means 44 signals to the AND array, since each input is in true and complement form. Quite obviously, you can AND whatever combination of these that you want, and use up to 8 of these sum terms in, say, a 22V10. Since a ROM doesn't share inputs and outputs, you'd be dealing with a larger package, but, since you've only got 8, 10, or maybe even 12 outputs, there's a limit on what you can derive from that number of inputs. PALs have the same technological restrictions as PROMs, so whatever size of fuse array you can generate in a PAL, you can also have in a PROM, and vice-versa. Now, I won't say it's impossible to run out of product terms in a PAL, I've never run out when I was willing to use another macrocell's SOP, thereby sacrificing the output pin. Truth tables are an unwieldy way to create/analyze PALs, though they were once popular. When you do use a truth table, you don't need to include all the inputs. You only need the ones involved in your particular logic function. Boolean equations are an easier way to deal with the SOP formatted logic functions. That way, you can easily apply Quine-McLuskey or Karnaugh map techniques to reduce your logic. The software tools are what makes these devices so handy. They do the reductions, and configuration for you quite painlessly. Remember you've got 8 or 10, or even 12 outputs on a small PLD. The really small PALs have only 8 product terms per sum, and, in fact, the 20RA10 has only four per register, with the others used for control of the register and output buffer. Of course if you run out, you can sacrifice an output in order to use its SOP in your required logic function. In a somewhat larger PAL, say a 42VA12, (sadly, no longer in production) you still have 22 possible inputs, in addition to which you have the outputs of 12 registers, which can be buried, (two always are, as there are only 10 output pins) and all the inputs to the AND array are available in either true or complement form. The AOI gate has 64 product terms, and the macrocell has a register, an output enable, a product term clock (each FF can be operated asynchronously if you like), a direct set, a direct reset, a polarity term, and an output enable. You can, of course, bypass the register altogether and simply use the buffered SOP output. You can, if you choose, selectively tristate an output under some conditions, using the feedback path as an input I've never even seen a PROM that allows you bitwise control of the output enable, let alone one that allows you to use output bits, bitwise depending on conditions as inputs. As a consequence your range of inputs is smaller with a PROM of a given size than with a PAL. the possible fuse arrays are about the same size, regardless of whether you have a PROM or a PAL. How they're implemented differs somewhat, in how they're applied, however. Because the OR array is fixed, fewer bits are programmable, but then, if you use a PROM to generate random logic, there are lots of redundant bits. The PAL, with its fixed OR array, won't let you generate a lookup table. If you need a lookup table, you'd use a PROM. OTOH, if you need a decoder, that's straightforward enough using a single output. Well, you've picked a long-obsolete device type, Tony, but if you consider what it was intended to do, I think you'll find it can detect and signal any unique combination of the 16 inputs. The 'C' means it's a comparator. Have a look at a more general-purpose device, e.g. a 22V10. It has some macrocells where you might run out of product terms, but that's seldom a problem when you consider what sorts of things you might want to do with the device. The two innermost macrocells have 16 product terms, while the two on the outside have only 8. The ones in between fall in between, with 10, 12, and 14. ( I think that's right. I haven't looked at a sheet in about a decade.) This means you might have to arrange your outputs so they correspond with macrocells having the appropriate number of product terms. nowadays, Yes, except that the last two are really not germane to the topic which was semantic. I don't disagree with you except in the sense that you continue to mix theoretical concepts with "real-world" ones. I use 'em if (a) I've got 'em, (b) there's room for 'em, (c) they're adequate to the task, (d) they can still be gotten readily for a repair. In part, that's why I take apart old computers that have socketed DIP's in 'em. Sometimes I use a torch and remove parts I know I may want. Well, I seldom have a "1-off" application that has a PCB laid out for a '163, since a PAL can contain more logic at less cost. That wasn't always the case, but 22V10's take up less space than two 16-pin DIP's, yet can provide precisely the same logic as two '163's, and, in fact, improve on them in that it can provide a synchronous carry. 74161, A ripple counter's an ASYNCRHONOUS state machine, methinks, though those are considered bad form, but all the counters above are synchronous. The '161 and '193, like the '163, have ripple-carry, though the '193 gates the carry with the low phase of the clock. That makes the thing capable of dividing by 1, which the others can't reasonably do. The 4017 is a Johnson counter, which is synchronous also, though this one's decoded.

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.ukTo: &lt;classiccmp(a)classiccmp.orgSent: Saturday, April 13, 2002 5:51 PM Subject: Re: TTL computing would some does I don't think it's the parts, but, rather, the way in which they're used. I have noted that 2114's seem to have a problem. I also wonder at the relative freedom from memory problems in the PC environment. I did occasionally have memory problems back in the CP/M days, mostly due to poorly timed DRAM circuits. can viewing its inputs in terms of the fact that PALs generally have 8 or more outputs, and in view of the fact that those separate outputs may not want to share product terms, there are limitations on the common small PALs. However, if you choose a device comparable to the PROM, they'll do it. > > > > > Sorry, but absolute rubbish (well, I'll qualifiy that. Given a large > > > enough OR matrix, it's possible, but all real PALs have a very restricted > > > OR matrix). > > > > Nevertheless, while they have a fixed OR matrix, they have a very flexibly > > programmable AND array, which allows you to express any logic function of the multiple > No it doesn't! > Any real PAL has a limited number of OR terms for each output. (typically > around 8 or so). What this suggests is that you've chosen the wrong device. You can't do the same things with ANY device. Take a look at the spec for the 16V8 and compare it with the 42VA12. Clearly, they have different size "fuse" arrays, and, if you want to program the device such that it produces functions of a size that consumes the entire "fuse" array, then you'll end up with a single output, but you can implement that function. With the 42VA12 you have 64 product terms, each of which can have any combination of the 42 inputs. On the 16V8 you have less flexibility. MANY functions will fit in a small device like the 16V8. It has a relatively small fuse array, in general, smaller than what's in a PROM, though it's larger than 32x8. > So I take my function. I write it in SOP notation. I combine terms that > differ by one containing a particular variable and the other containing > its inverse when all other variables are the same (like > A.B/.C.D/.E + A.B/.C/.D/.E -> A.B/.D/.E). You can let the software deal with optimizing that process, and in assigning the polarity of your outputs so the fewest product terms are used. This one is a single product (OR) term. > I then end up with more than 8 (or however many OR terms I've got) terms > ORed together in my equation. I can't minimise any more. And I can't put > it into the PAL. ALL that tells you is that you've picked too small a device, or one with the wrong architecture. All PLD's don't have to be small ones, just like ROMs. > I've not worked out what the maximum number of terms I might need for > any <n> input function is, but I'll bet that when I do, you need as many > bits to specify them as you have in an 2^n bit PROM. You do have to choose the right device, but, in general, you have lots of inputs, of which you can use any combination of AND's, and the number of OR's that the device architecture provides. Some parts, e.g. 20X10, 20RA10, etc, have relatively few product terms, though they can use all the inputs in various combinations in the AND array. Part of choosing the right device, is figuring out whether you're after a function easily expressed as SOP, or whether you really do want a PROM. There are also devices that have both the AND array and the OR array programmable. That allows sharing of product terms, among other things. A lot depends on what your objective is. If you want to produce the logic required for block 2G on that diagram I wrote about a day or two back, you may want to approach the problem differently than if you want to include several blocks and use a larger device. The difference between the result that you get with a PROM versus a PAL, is that the PAL allows you to put the registers in the device along with the logic, and to use the resulting outputs as inputs, which lends itself nicely to generating clean Moore and Mealy machines. If you think you want to secure your design, you certainly can do more to that end with a PAL than with a ROM and external registers and logic. The timing benefits from keeping the devices self-contained, as does power and PCB routing. Layout errors are also easily fixed with PALs, while that's not as easy on discrete logic. > Otherwise, I'll propose the following lossless compression system : > 1) Read <2^n> bits from a file. > 2) Regard them as the 'truth table' for an arbitrary <n> input, one output, > logic function (this step is OK) > 3) Turn that function into the equivalent 'PAL fuse map' (which you claim is > always possible, moreover, it takes fewer (than 2^n) bits to specify this). > 4) I now write out this smaller number of bits to the output file. > If step (3) is always possible, then we have a compression system that > reduces the size of all possible input files. Which is clearly impossible! > > > > that too, but the PAL does it with fewer fuses. > > > And that should tell you something is 'wrong'. Not exactly, since the PROM requires you to represent all the states of the inputs, while the PAL allows you to use only the ones that are relevant. > > > > Let's consider a single-output combinatorial function of <n> inputs. > > > There are 2^(2^n) possible functions (including ones that ignore some or > > > all of the inputs). > > > > You're running down an unimplementable path again, Tony. You can't implement let's > Of course I can!. I can implement any of the 2^(2^n) functions in a 2^n > bit ROM (which has n address inputs). There are _exactly_ that many > possible programming patterns of the PROM, each one corresponding to a > different function. SO you use a PAL with a fuse array of comparable size. > > postulate that you've got, at most, 22 inputs. (a 24-pin device with Vcc and an input and share you've a > > PAL, you can also have in a PROM, and vice-versa. Now, I won't say it's > All you seem to be saying here is that both PROMs and PALs have finite > size. Which is not something I disagree with. > What I am saying is that (say) a 16 input _PROM_ takes 65536 bits to > program it. A 16 input PAL (like a 16C2) takes many fewer bits. So there > have to be logic functions you can fit into the PROM that you can't fit > into the PAL. Not all PALs are alike. The 16C2 is a decoder. It tells you when the desired address appears at the inputs. A 26CV12 is quite a different device. > Of course you can make a PAL (defined as a programable AND array followed > by a fixed OR array) that can implement any cominatiorial function of the > <n> inputs just like a PROM can. This is related to the fact that you can > write any function in SOP or POS notation I think. But the resulting PAL > will be as complex as the PROM. Nobody said the device is simpler than the PROM. The job of concocting the PAL is made easier by the rather well-developed tools that we have, though. Generating the fuse map for the PROM when you have 22 inputs is a big job and requires a big PROM, even though the functions are mostly simple. consider what happens if you have 16 inputs, 6 outputs, of which four are inverters with tristate outputs and the other two are strobes decoded from the addresses, with totem pole outputs that remain enabled. That would be a problem in a PROM in any event. > The reason PALs are useful is that many functions used in the real world > will fit into them. But not all.... > > > This is easy to see. Think of writing out the complete truth table of the 1. > > > > Truth tables are an unwieldy way to create/analyze PALs, though they were once > Oh for %detiy's sake. Have you actually read what I have written? > I am not proposing that you use truth tables to actually design the data > for a PAL. > What I am saying is that every combinatorial function has a truth table. > And that it's possible to count how many possible combinatorial functions > there are by consdiering these truth tables. It seemed that you were headed there because you have to do that to create the equivalent PROM, and folks used to generate truth tables and reduce them. > Let me give you an example. > Suppose, for some reason, you want to know how many 2-input (let's call > the inputs A and B) logic functions you could make (including things like > 'always 0',. 'always 1', 'A', 'NOT(B)', etc). > You could start by saying 'Well, there's 'A', and 'NOT(A)', and 'B', and > 'NOT(B)', and '0'. and '1', amd 'A AND B', and 'A OR B' and 'A XOR B' and > 'NOT(A) XOR NOT(B)' -- Ooops, we've just counted that one twice, as it's > the same as 'A XOR B'' and so on. And you'll either count one function > twice or you'll miss one. > Or you could do it more systematically by saying ' Every 2 input > combinatorial function has a 4 line truth table (the 4 lines > corresponding to inputs (A=0, B=0), (A=1, B=0), (A=0, B=1), (A=1, B=1)). > For each line in the truth table I have to pick the state of the output, > either 0 or 1, So I have 2 choices for each line, so 2^4 choices for the > entire table. Aha, there must be 16 ways to fill in the truth table, so > 16 possible 2 input functions'. > And that's _all_ I am saying here. I want to count the total number of <n> input functions (so as to see if there are enough different ways to > program a PAL to cover all of them), so I consider a truth table. I am > not suggesting using the truth table as a way to actually design the PAL. > > the possible fuse arrays are about the same size, regardless of whether you > The 'fuse array' _is_ the programmable section. And the PALs I've used > have needed many fewer bits to program them than PROMs with the same > number of inputs (normlly called 'address lines' :-)) > > have a PROM or a PAL. How they're implemented differs somewhat, in how > > they're applied, however. Because the OR array is fixed, fewer bits are > > programmable, but then, if you use a PROM to generate random logic, there are > > lots of redundant bits. The PAL, with its fixed OR array, won't let you > No there are not. There may be many redundant bits for many useful > functions (this is _why_ PALs are actually useful -- because many > real-world functions will fit into them), but that can't be the case in > general. > > generate a lookup table. If you need a lookup table, you'd use a PROM. OTOH, > A lookup table is just a combinatorial function. > > if you need a decoder, that's straightforward enough using a single output. > Most decoders have the property that if you write the equation in SOP > form, it's got only a few product terms (maybe only one). And that will > fit into a PAL. sure. > > > > > So I say again. Consider the 16C2. It has 16 inputs and 1 output (yes, 2 > > > output _pins_, but one is always the inverse of the other). Does it have > > > 65536 programming fuses? No! It has many fewer. Therefore there are 16 > > > input functions you can't fit into a 16C2. > > > > Well, you've picked a long-obsolete device type, Tony, but if you consider > > what it was intended to do, I think you'll find it can detect and signal any Have > Actaully, the 'C' means Complimentary, refering to the fact that the 2 > outputs are always inverses of each other. I can't find a databook old enough to have this part in it, but I do remember seeing them once upon a time. Their purpose was to generate a programmable decoder with a minimum of resources, apparently for cost reasons. The true/compliment output was probably more to cover the potential requirement for one polarity or the other, by giving you both, but that doesn't matter. WHy not look at a more conventional sort of device that's survived, like the 16L8. It has seven product terms plus one for the output enable. That means you can take all the inputs and create any combination of those in a single product term. If the seven PT's aren't enough, you have to sacrifice the output associated with one group of seven and pass it back as feedback into the product term array via feedback, which one of the macrocells hasn't got. That's the one, probably, to which you'd pass the feedback from another macrocell. If you need a really complex function it can generate it, but you have to use enough resources to do that. In this case, you have 64*32 = 2048 fuses. 1/8 of those are allocated to output enable product terms, so you have only 1792 fuses with which to combine the 16 inputs into 8 outputs. This gives you a flexibility you don't have with a ROM, i.e. enabling only one or more of the outputs independently. Further, if you leave out the feedback, which a PROM won't allow you to have unless you feed the outputs back to address lines, which wil reduce the number of independent inputs you have, you essentially have only 8 inputs and 8 outputs. That's 256 bytes, and that's 2048 bits, which is more or less what the 16L8 has. I'd submit that you can, with a similarly sized PAL create pretty much the same range of combinatorial logic that a ROM with the same number of storage bits has. Remember, if you need ANY function of the 16 inputs, then you need a 64Kbit fuse array for each bit of output. There are PLD's that are that large, but they're not commonly used because the requirement for ANY combination of the 16 inputs is seldom encountered. There are such things, however. > And I am not disputing you can program a PAL to implement any function > consisting of one product term (which is what 'any unique combination of > the inputs' would be. You seem to be ignoring the fact that you can use as many of the available product terms as you like, however. That's why 16V8's, for example, are so popular. > > > The parts _you_ choose to design with [PALs, GALs, PLDs] > > > The parts others choose to design with (for whatever reasons) [Just about enough OR programming > > > bits as a PROM] > > > Theoretical concepts [PDAs, Turing machines] > > > > Yes, except that the last two are really not germane to the topic which was to > Actually, the 4th item on the list _could_ be a real world part (there is > nothing to stop you making a PAL-like structure with enough inputs to the > fixed OR matrix), and it's what you're claiming exists if you believe > that there are PALs that can implement any combinatorial function of > their <n> inputs. > Go back to that 22V10 for a moment. I don't have the data sheet in front > of me, so I can't remember exactly how you can use the pins as inputs and > outputs, but I think I can program it so I have 1 output, 21 inputs, and > don't use any form of 'registers' or feedback terms. OK, I am not using > all the PAL in that case. Just to refresh your memory, the 22 is the maximum number of inputs, the V indicates the "versatile" macrocell, and the 10 is for the number of outputs. A 16R4 has 16 possible inputs to the AND array, which are available both true and compliment, and there are 8 outputs, of which 4 are registered. You get the idea. In the case you cite, you are discarding most of the resources associated with control, i.e. product terms for output enable, global reset, set, etc. aside the feedback terms, you have only 12 external inputs. You presumably would choose the oututs that have 16 product terms, though. It wouldn't be advisable to do exactly what you suggest, simply because you can leave the outputs you don't use disabled and use their associated pins for input via the feedback paths. If you do that, you do have 21 inputs. > Now you claim I can use that to make any 21 input, one output, function. > I believe it takes fewer than 2 megabits to program it, in which case I > claim that your claim is plain wrong. Because there really are 2^(2^21) > possible 21-input combinatioral functions. There's a wide range of input combinations that you can implement in a 22V10, but none with more than 16 product terms. If you need more complex functions, there are some more complex devices you'd have to look at. Keep in mind, however, that if you want to cover the entire range associated with 21 bits of input, which is a 2 M word x 1 array, you'd need a pretty big PROM also. If you get a part big enough to hold that amount of memory, you wont\'t fit it on a 24-pin skinnydip leadframe owing to the die size. Now you're into a 44-pin or so package. If you specify the logic equation you want to implement, I suspect we can find a PLD large enough to implement it. What's made the PALs popular is that most of the logic that one normally wants in a single device is quite limited by comparison with what you've been addressing. True, it's conceivable that one might, at least once in one's carreer, need a terribly complex logic function that needs nearly a couple of dozen product terms. It doesn't come up often, which is why the devices that support such functions aren't so prominent.

Tony Duell wrote: ... I had a 2114 go bad in my UK101. I swapped it into the video RAM, which made the stuck "1" bit visible as a dud character in the middle of the screen. Scrolling made it "smear" all the way up to the top. More recently, I've managed to obtain a supply of 2114s to (hopefully) keep the UK101 going. -- John Honniball coredump(a)gifford.co.uk

A non-text attachment was scrubbed... Name: not available Type: text Size: 2379 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020416/217adff3/at…

This argument is still over the same things about which we always end up arguing, namely how things SHOULD or COULD be, vs. how they are. What's possible clearly isn't as important in the world in which I live as what's REAL. I live and die on what's real. Engineers don't get paid for coming up with things that SHOULD be. The things that exist only in the subjunctive don't pay my bills. see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.ukTo: &lt;classiccmp(a)classiccmp.orgSent: Sunday, April 14, 2002 2:46 PM Subject: Re: TTL computing I relative have Verly likely, but not something I've run into, myself. prom to However, It is MUCH simpler in its application. Most of the time, though a PAL has, say, 16 inputs, you use three or four of them for a given output, and you use a couple of the outputs in feedback. You use the internal registers because that way you don't have to wire the feedback externally, nor do you have to surrender PROM address inputs in order to use them, since they're already connected. The reason they "get by" with a relatively small fuse array, is because you generally want a couple or three inputs in various combinations, which become your product terms, and you want the feedback applied to those inputs as well, so you may end up with as many as 5 or 6 product terms per sum, but seldom the entire 8 or more that are avaialble. If you do need more, there are devices that provide them, and you use one of those devices. In a PROM, regardless of how many imputs you want, you have to program them all, and there's no software that does it for you. That in itself is already less simple, since you now have to come up with a bitmap for the prom size you're using. It's not difficult with a small prom, but with a bigger one it quickly becomes a burden, so you write an application to do the bitmap generation. Once you've done that for every size of memory that you intend to use, you're done. I don't know where you'll get a PROM with 16 address lines and address-access times on the order of what a PAL delivers, but that's another issue. The fact is that what people wanted when PALs were being developed as a product concept was a small, self-contained unit that could be defined and programmed separately from its PCB environment and externally modified, if requires, just as a bipolar prom would be. The business of utilizing them fully was easy to handle because each output was programmable as an entity unto itself even though the final device was integrated together with several unrelated functions. All that's quite straightforward to work out in either a PAL or a PROM. You need a "fuse" to each product term in the entire array, and whether the "fuse" is open or closed, each one has to be dealt with. SO, if you have 7 product terms per sum term, and have 8 sum terms, and 16 inputs, then you have to support a fuse array of 32 x 56 for the logic and 32 x 8 for the control terms, if that's what it takes, as in a 16L8. (typically the NO, what I'm saying is that there's a device to fit whatever your application. If a PROM will do it, perhaps that's the right choice, but it's going to be a bigger prom and it may require extra devices to finish the job. The PAL makes it simpler because you can design your PCB knowing that your logic can be designed as a separate task with complete confidence, since you do know what your inputs and outputs will be and that your functions can be fit in that device footprint. Now, I've used, say, an ICT 7024 to correct a layout error, e.g. where the layout of the part was upside down, with inputs where the outputs go, and vice-versa. The 7024 has outputs on all the pins except the corner pins, and they aren't outputs on a 22V10. compare if that but terms, have You can program both the AND and OR arrays, Tony, so the functions you would want to create are quite a bit more flexible. If you need all combinations of the 42 inputs, you do, indeed need a PROM. If, however, you consider REAL WORLD problems and their solution I've got some difficulty conceiving of a logic function that would consume the entire resources of a 42VA12, in real terms. I know, you could want to detect an access to a particular location within a large address space, which would, of course, require a pretty large gate. That's a single function of the input range, though, and it would take only one product term. I'm having some difficult getting my hands aroung what you're suggesting about the apparent lack of ability of the PAL device type, Tony. Could you provide an example of a logic function that couldn't be specified in a 42VA12? I'm sure they exist, but, speaking in real-world terms, I don't see a need for them. That's why the 42VA12 is no longer offered, having be replaced with another device of a more flexible, yet efficient, architecture. If there's a unique logic function, as you've said, a single product term should handle it, and if there is some strange logic function that requires a multi-Tb PROM, I'd be interested in just exactly how you're planning to specify it. 16V8. assigning Partly, the fact it's simple to do enters into the discussion, while what you propose with a really large PROM requires devices that don't, AFAIK, exist, nor is it likely they will, and a huge effort in programming the software tool to create the bitmap you want. Now entering a bitmap manually for a 2^(42) word PROM, even if such a device did exist, seems a mite extreme. How many lifetimes would that take? A computer could do it, but you still would have to generate the map and enter the equations. What makes the PALs so useful is that they can exploit the programmable link technology without the designer having to account for all the obvious "don't care" terms, of which there are usually plenty. one I do love the software, since it does what would take me a very long time in just seconds. What's more, it's been tried and optimized for years, so it's quite close to bug-free, which I'm not, even though I've been trying for a longer time than it has. If you read the fine print in the 16V8 spec, you'll see that you can feed the outputs from one OR gate to the poduct term array, thereby allowing you to incorporate that as a single product term into another sum. If you're using the entire fuse array, you have nearly the equivalent of a 256x8 PROM, which is what you should use if that's what you need. Of course, you get none of the benefits of a PAL architecture. The guys who built PALs also built PROMs and they certainly didn't intend to obsolete PROMs with their PALs. Ultimately, they did, however, since field-programmable nonvolatile memories are slower than the electronically reprogrammable logic devices they sell nowadays, and the conventional usage of such devices has, over the years defined devices that better suit some of the problems that were, in fact too large to tackle with the old, small PALs. Of course it's always been a combination of problems, with device resources at one end and the ability of the designer to use the resources effectively at the other. I can assure you, though, that if you can/will write the boolean expression, the software can fit it in a device that has adequate resources to implement it. Current generation software even will select a range of devices for you. There once was a company not far from here that provided a programe called MINC that would do that from a range of parts that you specified, trading off the costs, performance, etc, against others that would do the job. XILINX bought them in order to keep people from beneifitting from that multivendor approach. ISTR you could even add standard TTL devices to the mix and have it trade off the costs/performance with them included. That way you could trade off a design using PALs against one using registers and a PROM. AFAIK, it was the only such program that allowed the use of multiple vendor-specific devices in a design. It was expensive software, but I miss knowing it's out there. the ROMs. output, claim is this). impossible! the You can implement functions that don't do what you want. I'd be surprised if you haven't done that. Actually, I haven't given this example a moment's thought. > > > > > Of course I can!. I can implement any of the 2^(2^n) functions in a 2^n > > > bit ROM (which has n address inputs). There are _exactly_ that many > > > possible programming patterns of the PROM, each one corresponding to a > > > different function. > > ... and what would that function be? It must be pretty unusual. What sort of PROM would you use (be specific) if you need a function that complex in the time that a PAL offers? (or doesn't because it can't, as you say) How long would it take you to enter the logic equations for a function that had a 2^42 long array of ANDs on a 2^42 long array of ORs? I'd say the example is, once again, restricted by the limits of reality. The guys who invented PALs didn't want to replace PROMs. They just wanted to enable folks to replace PROM+registers+logic with a single programmable device. > > SO you use a PAL with a fuse array of comparable size. > I have aggreed many times that if the fuse arrays are comparable then > both devices can generate the same functions. You were the one who > claimed the PAL was necessarily simpler. > > > What I am saying is that (say) a 16 input _PROM_ takes 65536 bits to > > > program it. A 16 input PAL (like a 16C2) takes many fewer bits. So there > > > have to be logic functions you can fit into the PROM that you can't fit > > > into the PAL. > > > > Not all PALs are alike. The 16C2 is a decoder. It tells you when the desired > > address appears at the inputs. A 26CV12 is quite a different device. > Actually, a 16C2 is not a decoder necessarily. It's just the simplest of > the original classic PALs. I remember it being described as a programmable decoder. ... > > > > > Of course you can make a PAL (defined as a programable AND array followed the can > > > write any function in SOP or POS notation I think. But the resulting PAL > > > will be as complex as the PROM. > > > > Nobody said the device is simpler than the PROM. The job of concocting the > You did! I am thinking in terms of what it takes to implement the device. If you can specify the logic to fit in a given device, it's certainly simpler to use than if it's in three devices, particularly if you subsequently need to change something. > > PAL is made easier by the rather well-developed tools that we have, though. > And you sriously believe that similar tools cannot be written (and in > fact do not already exist [1]) to turn logic equations (or truth tables, > or state diagrams or...) into the bitmap for a PROM. Software does exist to do more or less that very thing. First of all, FPGA's are just RAMs with feedback. > [1] Considering that the FPGAs I used about 5 years ago used 32 bit RAMs > to implement all the combinatorial logic, there must be tools that turn > logic equations into the 'bitmap' for such RAMs. And I have no reason to > believe that such tools can only exist for 32 bit RAMs. Yep! Sounds like the 3000-series Xilinx devices. They had more than a 32-bit RAM, but that's what you saw. Believe me, their software won't support your 32-bit RAM. It only supports their unique architecture. > > Generating the fuse map for the PROM when you have 22 inputs is a big job and consider > > what happens if you have 16 inputs, 6 outputs, of which four are inverters > > with tristate outputs and the other two are strobes decoded from the > > addresses, with totem pole outputs that remain enabled. That would be a > > problem in a PROM in any event. > True. But why do you insist of overcomplicating things. We are > considering only the combinatorial part of the circuit at the moment. Why? One of the benefits of PALs is that they allow you to build two or three functions into a single device. You don't always want a PROM. If you do, you should use one. > [16C2] > > > Actaully, the 'C' means Complimentary, refering to the fact that the 2 > > > outputs are always inverses of each other. I found an old-enough databook to have that device ... it's actually a 16C1, unless there was also a 16C2, which certainly isn't in this book. It appears that it has 512 bits in its fuse array. > > > > I can't find a databook old enough to have this part in it, but I do remember <snipmeans > The reason I picked the 16C2 was to avoid having any features that are > irrelevant to the argument. OK, you want to pick the 16L8. It makes no > difference. You might as well ignore the output control lines _because > they make no difference to the combinatorial functions you can > implement). And the feedback terms are almost irrelevant -- just add 6 > more pins to the package (IIRC only 6 of the outputs have feedback) and > seperatate the feedback signal from the output. You can wire them back > together if you want to. OK, but Why? What's relevant is the question of what's realistically implementable. I know of no PROM with performance comparable with PALs, and I certainly know of no large field-programmable PROMs that are physically small enough to fit where a PAL goes. What will fit in a given package is of some interest. Now there are PLD's that have a really large AND array, since they can share them. There's no reason why a PROM of a given size can't exist, BTW, but there's probably a reason why they don't. > The result is an imaginary device that would be more versatile than > the real 16L8. So if we can show this has restrictions (which we clearly > can), then the real 16L8 must have at least as many restrictions. Yes, but the reason such a device doesn't exist is because there's too little market for it. The PAL is extremely simple to use for the purpose for which it was intended. The PROM, likewise is pretty easy to use for what it's intended to do. It's a lookup table. It can function as a multiplication table as you've pointed out, and it can do lots of other things. It does require squandering resources on functions not required in order to provide the functions of comparably sized/priced devices. > > you can take all the inputs and create any combination of those in a single into got. you 2048 have > > only 1792 fuses with which to combine the 16 inputs into 8 outputs. This > OK. And considering it takes 65536 bits (or fuses) to specify an > arbitrary _single output_ function of 16 inputs you must now see the PAL > cannout generate all possible functions... > > gives you a flexibility you don't have with a ROM, i.e. enabling only one or feedback, have, you that's > Actually it's 10 inputs and 8 outputs IIRC (same as a 10L8, which has no > feedback terms). That would be 1024 bytes or 8192 bits. > > 2048 bits, which is more or less what the 16L8 has. I'd submit that you can, combinatorial you > I think I said this about 3 messages ago. And yes, it's clearly the case... > > need ANY function of the 16 inputs, then you need a 64Kbit fuse array for each commonly seldom > > encountered. There are such things, however. > Again, agreed. PALs are restricted in what they can do, but the > restrictions don't matter for many real-world applications. Perhaps you > want to make an address decoder. Typically you need perhaps 2 or 3 (at > most) product terms of some of the address lines. That fits easily into a > PAL. They offer flexibility beyond the capability of any PROM, but they don't replace what a PROM was intended to do. A lot of the special-purpose devices have gone by the wayside, e.g. the XOR PALs once popular for counters and the like, and the 'L' and 'R' types in favor of the 'V' types. That suggests that the PAL family, truly the simplest of the programmable logic devices, has been refined considerably. Unfortunately > > > > > And I am not disputing you can program a PAL to implement any function > > > consisting of one product term (which is what 'any unique combination of > > > the inputs' would be. > > I'm not convinced that you or anyone else can find a use for a logic function that requires more than 64 product terms of 42 inputs. I once had a very senior engineer-turned-manager tell me he had never encountered a function that wouldn't fit in a 22V10. I'm inclined to believe that, though there must have been some if the Signetics guys cooked up that 42VA12. That was one slick device, though. It could operate in part as a 22V10 superset, in part as a 20RA10 superset, and in part as a 32VX10 superset, by which I mean that you could use a few outputs as though they were from a 22V10, but with the 64PT sum, others as an async PAL macrocell with a product term clock, and others with the XOR term that the 'X' implies, which makes expressing counters much simpler (... weak example, but I've never used a 32VX10, so I don't remember anything about it, and haven't got the relevant databook in front of me). Normaly, the 42VA12 came in handy for me for fixes of previously 20RA10 and 22V10 logic that either didn't fit or needed an async element it couldn't have. The buried registers with feedback were a nice option. > > You seem to be ignoring the fact that you can use as many of the available > > product terms as you like, however. That's why 16V8's, for example, are so > > popular. > No I am not. You seem to think there are always enough product terms. I > dispute this. > > > Go back to that 22V10 for a moment. I don't have the data sheet in front > > > of me, so I can't remember exactly how you can use the pins as inputs and > > > outputs, but I think I can program it so I have 1 output, 21 inputs, and > > > don't use any form of 'registers' or feedback terms. OK, I am not using > > > all the PAL in that case. > > > > Just to refresh your memory, the 22 is the maximum number of inputs, the V > > indicates the "versatile" macrocell, and the 10 is for the number of outputs. > Yes, but you don't have enough pins on the package to have 22 inputs and > 10 outputs simultaneously. IIRC some of the inputs are reallty feedback > terms from the outputs (yes, I know you can disable the output and use > that as a true input, but if you disable all the outputs the device is > not a lot of use). Yes, the marketing department left its footprint here. The pins are I/O's, so you can use a pin as an input when its output is disabled, which meets the test. What I meant, I think, was that you have as many as M inputs and N outputs in a PAL designated MTN with the macrocell type specified by the T. With the parts that have product term output enables, it's not quite that simple, since you can use a device pin as both input and output. > Hence my comment. IIRC this is a 24 pin package (with 2 pins used for > Vcc and ground). If I disable all the outputs but one, I can use the > remaining 21 pins as inputs, right? So I can make a 21 input function > with one output in this PAL. > So far, so good. I now claim that I can't make _any_ 21 input function in > that 22V10. There are some that won't fit. > > A 16R4 has 16 possible inputs to the AND array, which are available both true get > > the idea. > Indeed I do. I have used PALs and GALs. I have read (and understood) the > MMI databook (amongst others). > > > In the case you cite, you are discarding most of the resources associated with aside > Correct. These extra resources have nothing to do with implementing a > combinatorial function. Well, apart from the fact that they take up > programming bits, so there are fewer bits left to actually determine the > function. This was done with an eye to the fact that, using a PROM, one often programmed bits that were redundant, since one didn't need every in put for every function, and one didn't need every output in every application. Today, the 16R4, R6, or R8, is replaced by the V8, as is the 'L8. I've never been plagued by product term depletion, though that was occasionally a problem. The cases where I encountered too few product terms it simply required I rearrange the output assignments on the device pinout. My main complaint has always been there were too few outputs, not too few inputs or product terms. Building a sort-of 74F269 replacement (subset) in a 20-pin package wasn't possible until the 16V10 became available. It always troubled me that they wanted two enables, yet didn't care to make a synchronous carry flag available on the smaller synchronous devices (74x162/3). This allows one to get around that.

Yes, and they save on space and not only because of their size. You don't have to route unused inputs to Vcc or Gnd, and you don't have to accomodate the device pinout so much, since YOU get to decide what the order of the outputs and inputs will be, which facilitates layout. Dick ----- Original Message ----- From: "Ben Franchuk" &lt;bfranchuk(a)jetnet.ab.ca&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Monday, April 15, 2002 9:05 AM Subject: Re: TTL computing a devices the that been

Just WHAT have you been smoking? They haven't made bipolar PALs in ages, since the CMOS parts are not only easier on power/heat, but are more reliable, cheaper, and reprogrammable as well. If the makers of the low-cost devices we all use had intended that you repair them when they break, they would have provided documentation. In a few years, when you buy a computer it will have a circuit board with a splatter of epoxy in the middle, the way the cheapo game cartridges were made a few years back, and that's all that there'll be on the board. Of course there'll be no place for expansion boards, so the box may be welded shut. You're certainly free to be happy about whatever you like. It's true that PALs (SPLD's) are an obsolete technology, seeing an occasional application among hobbyists the way TTL devices did a decade ago. Dick ----- Original Message ----- From: &lt;jpero(a)sympatico.ca&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Monday, April 15, 2002 3:28 PM Subject: Re: TTL computing accomodate

This item is getting to be rather large... see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Monday, April 15, 2002 7:39 PM Subject: Re: TTL computing I'm curious in what way doing this sort of thing in discrete logic has over doing it in programmable hardware. (Take a look at the field-programmable analog hardware offered at Lattice, for example.) As for the technique itself, I remember reading that Siemens had some hardware that did this sort of thing about 20 years ago, so there's plenty been written about it. with don't It doesn't imply that at all. It does suggest, however, that if you're trying to exploit new thinking, you shouldn't be weighed down with archaic implementation techniques. If you have a concept you want to explore, you ought to be able to convince yourself of its validity by thinking it through, the verify that validity with extensive simulation (which you clearly don't believe useful, in spite of the fact the rest of the world has accepted it, then implement it in a programmable hardware testbed because that doesn't require you to buy an specific hardware, and then stress it in various ways to determine its sensitivities. Building just one example of a circuit would not really prove that the design is sound. It only proves that you can make it work ... once. has, use because to is combinations, those devices. them already ... and just exactly WHAT does this do? (BTW, it's a mite confusing keeping the I's straight, and figuring out what, exactly, your ellispsis represents, but, overall, it still looks like a single product term will do it. That's not the sort of function that you said you'd need a PROM to implement. Simpler, is a pretty nebulous concept, but I'm here to say that simpler means you use the tools that are freely available to do the "dirty-work" including translation from source, reduction, and production of the JEDEC file and/or fuse map. You can also use the same tool to do the functional simulation, just to verify that you've kept the poliarity straight in all cases. (saves on fusible-link devices) It means you don't have to write your own tools, and it means that you can, for the most part, rely on the resulting output. The machine on which you accomplish these things is just a tool, like a wrench. It's not a deity, and doesn't need special consideration. Like a hammer, when it fails to meet my needs, I repair/replace the offending component, or chuck the whole thing and replace it, just as I would with a screwdriver that no long works well. If I can't afford a new tool I need, I consider a 2nd hand one, even if I can't afford one that doesn't have a broken handle or the like. it I'm not so sure of that. Further, I'd be interested to know how long it takes under RT-11, to which you frequently refer. intend to lines I'd just recommend a bit more focus on what you CAN do in the real world rather than focusing on what you can't in the theoretical world and using that as an excuse not to take advantage of the technology. You're a free person and are allowed to do pretty much whatever you want, but, IF you consider your mental processes to be of any value at all, aside from your own amusement, and IF you think you can come up with something that's of use, WHY would you encumber yourself with 1970's tools? It's fun to play with those old-timers, and they do, after all, still compute just as they always did, but, since you've mentioned that your resources are limited, why don't you consider that those old-timers consume kilowatts of power and leave you technologically isolated from the convenient-if-not-perfect technology available today, that consumes much less power and runs so much faster, aside from being able to utilize the no-cost/low-cost resources the lack of which seems to stand in your way? You could recover the cost of a 2nd-hand Pentium-based PC-type in just a few months in power savings. When you buy one 2nd hand, it normally has an OS installed, and most people put a copy of the installation files on the HDD, it it doesn't happen automatically when the system's installed I assume, of course, that power isn't free in the U.K. My own average power bill has gone down by some $22 per month (though the overall rates have increased) since I quit using those old full-sized 5-1/4" disk drives and leaving them spun up all the time. A 3-1/2" 18GB drive only cost me $82 including freight and a spare (ain't eBay great?!). It does't make nearly the noise, heat, and power bills of the dozen or so "old" drives. do programmable application. be a makes What? Are you suggesting that you'd design a PCB without knowing what logic functions you need? You've already said that it's not a given that such a ROM even exists. I'm still curious what sort of a logic function you think you might encounter that you couldn't implement, including latches, etc, in a 42VA12 or something on that order. Remember, it has both arrays programmable, and it has 64 product terms per sum term. (look in the "Signetics Programmable Logic Devices" Data Handbook, from Philips, 1990) I recognize that problem. I've seen boards full of FPGA's that still had wires on them once the FPGA's were changed simply because the redesign had to change either the timing or the pinout and timing changes weren't tolerable. That sort of thing doesn't happen as readily with current devices, but you're certainly right. map this, would combinations of I'm getting really curious what sort of function one could NEED that requires a set of more than 64 products of those 42 inputs, though you can certainly use more than that by combining sums if you do need. Generally one doesn't have to decode the entire real and virtual address bus. Generally, one can use fewer than ALL the inputs in combinations of 42 taken 64 at a time, but there's certainly more than that available to you in the little 24-pin skinnydip that's the 42VA12. Even if you consider only one output, that's available to you in that part. There are, of course, more sizeable parts, but I didn't have the sense that you needed more size. Further, if it's a state-machine, how many states do you think you might need? How many do you think you can manage to design with inside a realistic time? What sorts of resources would that require? real location How many ROMs of what size would it take to do what you're suggesting? The fixed XOR's weren't popular for long, once larger numbers of product terms became available. How about looking at the real device in a real application? If you want something really large in scale, you'd probably want to put the multiplier inside the device. Just for drill, take a look at the biggest of the XILINX devices. You'll have no trouble fitting whatever you want in there, and the performance is pretty good too. that of relevant. if I'm saying that if you design a function that doesn't work, that doesn't mean you can't implement that function. You shouldn't expect a compression scheme that doesn't work to work in programmable logic. No... only because you're looking for things that fit PROMs with external registers, while you're not considering what sorts of functions it is that you can't implement in a PAL. All you've said is that it is conceivable that one might invent a function that doesn't work in a PAL. You've not come up with one yet. It's true, though, that if you want a function that requires more product terms than you can combine in a given device, Have you got a part number for a 1 Mbit x1 PROM? I'm not sure where this is supposed to lead. Normally one starts with a required logic function and then decides what sort of hardware is required to implement that. Keep in mind that the 20L8 is a 24-pin part, so a more complex PLD on a 24-pin footprint isn't ruled out if you only use one output. You're putting too much emphasis on the fuse map, which nobody sees, and not on the relationship between the inputs and output, though one certainly exists. And what, exactly does that prove? there fit support three you 2 16C1, appears and I little which That's the reason programmable logic exists. Devices are needed, but don't exist, so we look at how to make 'em. If there's a very limited market, like, I'm the only one who wants such a thing, then a programmable devices is more likely find its way into my application than a mass-produced one. I think that's why this argument has persisted for so long. With programmable devices, I can build what I want. With TTL SSI/MSI/LSI you can build what you want. We could switch roles, but the fact remains, each approach has advantages. I just believe that the advantages of the SSI/MSI/LSI approach are diminshing, while the programmable logic approach continues to expand. As far as the theoretical capabilities of PROMs versus PAL-architecture devices, I've never suggested you were wrong in your assertion that it was POSSIBLE to conjure up a function that could be implemented in a PROM that couldn't be implemented in a particular PLD. I've emphasised, I hope, that there's a link missing between your argument and the practical realities of (a) needing such a function and defining it, and (b) implementing such a function in REAL hardware, whether programmable logic or PROM, for several reasons, ranging from the size of the task to the size of the device. With one output, you could generate only one state of a state machine, so I imagine it would take several of the hypothetical devices to which you refer to do anything useful. I find it difficult to imagine working with a finite state machine with as many inputs as you suggest. That suggests a pretty wide state register, and separate outputs, perhaps, and quite a few additional inputs. With more than 8 product terms you'd have to share product terms between adjacent macrocells until you have enoug of them. When you're done, you could end up with all but 8 of the sum terms involved in some way, since 8 are used for the output enable at each input. If you were ever to want to investigate, thoroughly, at least as thoroughly as you could by building such a thing, a system that required such a complicated logic function, with as many as 56 ORs of products with 1..20 ANDed inputs, you would likely start with a simulator and not with hardware. You'd then write a top-level functinoal simulation program and then test it with a sample program. After that, you'd descend, step-by-step in to the bowels of each module, simulating it as you think you'd implement it, substituting thousands, or tens of thousands of ANDs and ORs, etc, for what was a bunch of registers or adders, or whatever, refining your work as you progress to ever lower levels until you've arrived at a simulation, at the gate-level, of what you eventually plan to build. At every step of the way, you can test the simulation. If you've written your simulator well, when you're done, you can construct the device at the gate-level or at the SSI/MSI/LSI level. Your result should quite well match the simulation. In my estimation, all this is much simpler, because the tools already exist, and easier because there's help available, if it's done with the modern hardware and accompanying tools. With the free tools from Xilinx, for example, you have Verilog an VHDL, schematic entry, graphical FSM entry, and lower-level PAL-style (ABEL) tools, all of which can be used together. You can design in the large or at the SPLD level. You can design a system and verify its logic without ever soldering a wire, and get representative simulations of your work via the simulator that they provide. Further, you can specify your design at behavioral, structural, and register-transfer level and migrate from one to the other as needed in order to specify more precisely what you want. You can even specify the design using your own TTL library with timing and all as specified for the type of logic you intend to use rather than using XILINX programmable logic, though I don't know that for certain. You might have to do this last step in someone else's freeware HDL. Doesn't this seem less spainful than (a) finding a set of bare wire-wrap boards, (b) installing sockets, (c) working out a large schematic design, (d) acquiring the long list of parts, only some of which you'll already have,(e) integrating the various modules you fabricate and test separately, (f) finding the problems and going on only when there don't appear to be any more (else go to (C)...) (g) and then, finally, going to the step at which you'd have arrived without ever fiddling with any hardware with the former approach? You don't really EVER have to implement anything in programmable logic unless you want to, but you can use all the tools to support a development in SSI/MSI/LSI.

Just to keep things straight ... the PLC42VA12 that I mentioned is a device that plugs in where a 22V10 fits. It has vastly greater resources than a 22V10, but it's NOT a CPLD. It's got 42 inputs because you can "bury" the register associated with a particular pin, isolating it from the pin's feedback path, and from the output pin, thereby leaving the pin as input only. The output from the register, however, has, as it always had, a separate feedback path so the 10 output pins have 20 feedback paths associated with their macrocells, one from the register, and one from the pin. There are also two macrocells that have no associated output pins, so they're always buried. This is a considerable enhancement over what a 22V10 offers, aside from the fact that it has many more product terms than the 22V10. A CPLD would have several banks of these, at least three or four, but probably more than forty, with a product term matrix common to all the banks, as well as a product term matrix for each block. more below. Dick ----- Original Message ----- From: "Ben Franchuk" &lt;bfranchuk(a)jetnet.ab.caTo: &lt;classiccmp(a)classiccmp.orgSent: Tuesday, April 16, 2002 3:52 PM Subject: CPLD computing requires certainly I'm not sure I buy that ... the carry is a single product term, isn't it? That's why fast carry terms work faster than their respective sum terms, in physical adders. In lookup tables, it doesn't matter. FPGA makers take lots of trouble to ensure that you have fast carry logic available. > > I think that's why this argument has persisted for so long. With programmable you approach > > are diminshing, while the programmable logic approach continues to expand. > But the programmable logic setup is still a mess. I have yet find a > CLEAN hardware description language that is portable, simple and free. > > If you were ever to want to investigate, thoroughly, at least as thoroughly as complicated inputs, > > you would likely start with a simulator and not with hardware. > I tend to work bottom up. I start with REAL hardware and build up. That works OK if you're building stuff you know will work the way you predict because people have built it for years. If you're trying something new, the simulator saves lots of money for hardware you may not ever need. > > You'd then > > write a top-level functional simulation program and then test it with a sample program. . Testing is good. How ever it still needs to fit in the hardware. SInce the hardware hasn't been started at this point, it's virtually infinite, since its only virtual. Once you're convinced it's going to work as you wish, you can progress toward an implementation. Testing, in fact, exhaustive testing of every feature in every combination and range of permutation you can generate is essential. Nothing should ever be comitted to hardware until you're sure of how it works under all conditions. > > Doesn't this seem less spainful than (a) finding a set of bare wire-wrap > > boards, (b) installing sockets, (c) working out a large schematic design, (d) have,(e) finding (else go You you > > want to, but you can use all the tools to support a development in > > SSI/MSI/LSI. > But debuging TTL is visible. You put a logic probe on the output and > test data in. I favor switches and lights.It is not that I don't like > modern software , I as design should be able to have the final say in > exactly how things are connected even if this means shooting myself in > the foot now and then. Yes, and it's so slow, even a cheap oscilloscope can show you real features of what's going on. Unfortunately, they don't make oscilloscopes fast enough any more, that you can see what's really going on with an event that happens every ten seconds or so and has a 130 ps duration. The simulator can show you where to look, however, if you've got a simulator and appropriate models for the TTL. You can't stick your 'scope or LA into the programmable logic, so you have to do what you can with the simulator. > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html

A non-text attachment was scrubbed... Name: not available Type: text Size: 17085 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020417/346f5364/at…

At 01:34 AM 4/17/2002 -0600, Richard Erlacher wrote: Let me guess - you're going overboard with excess quoting just to keep the flame war going? - John

Richard Erlacher wrote: Core memory had it's day. However it had the advantage of non-volitile that is hard to duplicate in modern memory. The read/write memory cycle was well used by computer architecture of the 1960's. Did not the early PAL's burn on PROM programers? (512x8 fuse prom) Sadly this not true today. And marketing droids sit on the design 'Go ahead' for months and then want it yesterday. I use TTL because 1) I don't have programer ( got any schematic for one that does not use PAL's and easy to find TTL) 2) Pals never are the right size to replace simple but messy logic -- say a D-F/F followed by a 4/1 multiplexer followed a xor gate and another D-F/F. Old sailing ships used a lot of man-power. While OIL is cheap wind powered modern ships will not be developed. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

A non-text attachment was scrubbed... Name: not available Type: text Size: 1389 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020414/4a2ff8d2/at…

Yes, they're getting ridiculous. but $500 isn't so bad when you consider that it will program EPROMS, EEPROMS, varous MCU's, it will test logic, it will test RAMs ... If you buy a moderately cheap CPLD, e.g. the XILINX 95108, in a PLCC84, it costs about $20-30 U.S. at DigiKey. Combine that with a socket, ($4 tops) and a few wirewrap socket pins, ($.10 each) that's another $8.40. Now find a cheap wirewrap board to which you can solder ... and then use the free software and build the ~$5 ISP adapter. For the same money, you can use a Xilinx SPARTAN-series FPGA which you can also program using the ISP programmer, though you'll have to do it every time. Then you can design pretty much whatever small computer (only because of pin-count limitations) you want. These devices even allow you to put in some RAM. I've heard it said, "Where there's a will, there's mourners." Dick ----- Original Message ----- From: "Ben Franchuk" &lt;bfranchuk(a)jetnet.ab.ca&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, April 13, 2002 9:40 PM Subject: Re: TTL computing

On Sun, 14 Apr 2002 09:00:50 -0600, Ben wrote: Before you give up on wire-wrap, PLCC sockets (through hole, not surface mount sockets) have their pins on a .1 inch grid. I have often used strips of N x 1 wirewrap socket pins, cut to length, and made up ww sockets to match the underside of a PLCC socket. Such as these: http://www.mill-max.com/images/products/PDF/049.pdf ================= Philip Freidin philip(a)fliptronics.com

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, April 13, 2002 5:01 PM Subject: Re: TTL computing PROMs, Yes, they did, "burn" in programming circuits similar to what was used to program bipolar PROMs. These were simple circuits pretty completely specified in the datasheets. The process of specifying which fuse was to be programmed how was less well specified, but with enough attention, you could figure it out. Once MMI was no longer a player, and Signetics was sold to Philips, the programming circuits and logic quickly disappeared from the scene. Both Signetics and MMI had published circuits that could be used to program bipolar proms. The same strategies and similar circuits were used to program the small bipolar PALs. The details on how to address the various fuses was less clearly specified as time wore on, ultimately disappearing completely. The circuits that did the work were based on multiple voltage regulators and a few switches to set addresses. When the address switches were set, the bits to be programmed to '1' (I think, but maybe to 0) were, one at a time, connected to ground through momentary switches. This served to program them. Bipolar parts were always a mite fragile in the "verify" process, since some people thought it had to be done with the supply voltage elevated. With PALs, you couldn't use a current source to a negative supply as you might with some PROMs, because of the feedback circuitry. it? Not for serious work, though. TTL's too slow, uses WAY too much power, and requires too much board space. While some advances in ship design have come anything worthwhile to the electronics industry will come from taking old technology like the techniques once popular with TTL and then using them and the old TTL devices to build on a dozen boards, what one could build in a single FPGA. It could happen, I guess, but nothing new is likely to spring He's says It is a mental masturbation project, though. There's no hope that it will produce anything other than amusement. He's got enough money, so he doesn't need any more of that, and he's being more or less retired more of the time. Just the same, he's not sure he's going to finish the job, since he found on his last voyage, that he really doesn't like shipboard life that well. Without belaboring that issue too much, I'd say that lots of people think bicycles are no longer practical. I think they're wrong, and I'm not alone. I don't think anybody expects anything but amusement from wiring up TTL, though. True, but those guys don't have much influence on the nomenclature, and they certainly don't do that under the guise of doing useful work.

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.ukTo: &lt;classiccmp(a)classiccmp.orgSent: Sunday, April 14, 2002 12:27 PM Subject: Re: TTL computing bipolar programming specified Back in the '70's, one used a Data I/O Model 29 (?) which was very expensive, and for which the software updates cost quite a bit. There were, however, programming circuits/application-notes published by the manufacturers, e.g. MMI and Signetics, that went into considerable detail about how to program the parts in question. They emphasized building the circuit in such a way that you wouldn't damage their part and didn't put as much emphasis on how to program the part correctly, i.e. how to address the particular fuse you wanted to program, laving that somewhat murky, but it was there if you wanted it. Well, if I had a PROM-only programmer, I'd interpret the designation of PROM-ONLY as meaning it was a waste of time to try to program a PAL with it. However, the technique of selecting the fuse was the only real difference, electrically between the two device types, and that was described in the early app-notes. Unfortunately, the 1986 databook I have at my feet is not early enough to include that information. I have a few earlier data books, and perhaps one of them will go into sufficient detail. The basic strategy was, however, the same as with a bipolar PROM. Select the fuse word by applying the appropriate signalling sequence to the device, then sink current through the appropriate output pin of the device being programmed, with the Vcc supply elevated to the specified level. IIRC, those voltages weren't much above 5 volts, and were, indeed, below the 7-volt absolute maximum. If you built a device capable of handling the bipolar devices, you had the basic hardware to do the PAL job already in place. The driver software had to be built, however, as did the code for translating the JEDEC file that the software, e.g. ABEL, PALASM, or CUPL, into the fuse selection/programming algorithm that would be executed by your programming hardware. Over the years, the makers of these devices have gotten tight-lipped about the programming algorithms because the home-built devices, even those built by knowledgable engineers, caused them such a service headache. If your local sales rep. saw that you were a serious user of their devices, you could gain access to that information. It just happened that in about '85 or so, I was working where I had ready access to a device programmer that did the job. Later, I had a job that absolutely mandated I have a "universal" programmer of my own, so I bought one, and later a second, and this stuff hasn't been an issue for me since then. doesn't and I'll do that when you quit suggesting that the entire industry and its nomenclature are wrong just because it doesn't suit the dabblers in obsolete hardware. Things change over time because they are adapted to the needs of those who use them, and that includes the nomenclature. That applies to the majority who work in the industry, of which, you, Tony, are clearly not one. You, and everyone else, certainly have the right to call things whatever you want. but you should have noticed, by now, that this occasionally leads to semantic difficulties. come That's only a small part of the acceleration. The use of multiple piplelines accounts for much of the performance increase along with increased datapath width, and other little features. The gradual increase in interest in parallelism is also going to help quite a bit, so we'll be seeing even more pipelines in the future. And just exactly HOW would they extract more performance from it? A new architecture would require new software, both in development tools and in OS and as applications. Just verifying that their innovation would take several hundred lifetimes, and the generation of a full set of software would take that one individual working alone, until well after the next big-bang. It's highly unlikely, simply because it's WAY too much work to twiddle the hard-wiring and WAY too slow to use TTL, and uses WAY too much power so folks doing serious development, even at the amateur level, use simulators to evaluate performance of new architectures, and programmable hardware to verify their findings. That's not to say a person's WRONG in fiddling with discrete logic. It's just not terribly likely to be of much use. Like masturbation, it's unlikely to hurt anyone and produces momentary amusement. > > > > One of my friends is building a sailboat in one of his vacant buildings. He > > says > > > > he wants to sail it around the world. I hope he makes it. > > > > It is a mental masturbation project, though. There's no hope that it will > And that's _exactly_ what building TTL circuits is for some of us. Now > will you please try to understand this! I've got no problem with that. I do, however, disagree that the industry nomenclature is misapplied because it COULD or even SHOULD have been used differently. I do things that accomplish little more than amuse me for a few weekend afternoons. I don't pretend that they're going to produce anything, though. My interest in S-100-based microcomputers certainly hasn't done anything useful since the day I started using PC's. I haven't simply chucked the S-100 hardware on account of that, however.

Programmers have been a problem for us, the users, as well as for the PLD vendors. That's why they'r so much behind the in-situ-programming features, and that's why they support it so happily. If you use THEIR hardware to program their device, there's never a problem. (or that's what they say) I bought a universal programmer in the late '80's that, according to the vendor, programmed the devices I wanted to use. After I had it, I found that it didn't program the parts, damaging them instead, and they were not cheap parts. I found that it was necessary to have adapters for many of the devices I wanted to program. I found that, while I'd bought a small, fit-in-the-briefcase programmer, I needed a sample case full of adapters, which were both costly and fragile. Some of the vendors of programmable logic do publish the algorithms for their ISP programming tools, which you can then implement in your own hardware/software combination. Unfortunately, I've seen no spec's on how to develop the configuration of the hardware. more below ... Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.ukTo: &lt;classiccmp(a)classiccmp.orgSent: Monday, April 15, 2002 6:23 PM Subject: Re: TTL computing expensive, it. EPROMS, for some reason, didn't have these limitations. Programming was simple and the spec's were in many of the databooks. There were several vendors, including both TI and Mitsubishi, who made parts that worked that way. I see what you mean. However, most microcontroller makers provided simple means for you to program their field-programmable parts. Motorola had a number of devices that, if you applied the right signals at reset, would go into a bootloader that programmed the internal EPROM from the serial port. Others required you wire up a programming circuits with a source EPROM that their circuit downloaded to the internal program store. early early Which book would that be? Does it surprise you that the access mode to the fuse array is different? It's a totally different device type. The means for "blowing" a fuse is the same, but the means of addressing the fuses is different, and changes with different device types. It's hardly worth considering, since you won't find many bipolar PALs any more. They've been replaced by GALs. Oddly enough, back in '84-'85, when these devices were new, the programming methods were documented. Now that there are many more varieties of these parts, the documentation's disappeared from their databooks. > > Over the years, the makers of these devices have gotten tight-lipped about the local > I have never understood this... > The process of programming a fuse in a bipolar PROM and in a PAL is much > the same. Similary the process of programming a flash cell in a > microcontroller, a flash PROM and a GAL are also much the same as each > other. And yet most (but not all, agreed) microcontroller, flash PROM and > EPROM manufacturers do document their programming algorithms, but few, if > any, of the PLD manufacturers do. Why are PLDs the only devices that > cause support problems. Believe me, I've got no idea, but that business of "support headaches" comes up every time I broach the subject with the factory applications guys. They probably feel they've got to protect their technology. One of the "universal" programmers I have had a programming language, which I obtained. The purpose of this thing was to allow one to write programs to implement new algorithms for new devices. It also allows one to add SSI/MSI and memory devices to the test library. Unfortunately, about the time I got that software, the mfg's became really difficult to deal with as far as their device programming algorithms were concerned. <sigh> > > Will you please forget the 'serious work'. Will you please accept that > > > there are people who design and build electronic circuits for fun. This > > > appears to be an alien concept for you. > > I'll do that when you quit suggesting that the entire industry and its > > nomenclature are wrong just because it doesn't suit the dabblers in obsolete > Well, considering your beloved 'industry' can't agree on what these terms > mean (hint : I've seen manufacturers call something 'microcode' that > anyone else would call machine code for a microprocessor), I am not sure > anyone can be that arogant as to what the terms mean. > And to claim that microcode is not a special case of a state machine is > plain wrong! They'll listen to you when you become part of a market that uses 100K pieces per week of their various parts. In the meantime, you're just a hobbyist and not even a customer of theirs. You, and most other hobbyists, get your parts surplus out what they don't need. The industry doesn't care, even, that hobbyists exist. You're a retailer's customer. > > > The current advances in processor speed have come largely from just > > > increasing the clock rate. There haven't been any major changes in CPU > > > design to use those clock cylces more efficiently.... > > > > That's only a small part of the acceleration. The use of multiple piplelines datapath more > > pipelines in the future. > > > > > But somebody stuck with old, slow, TTL, just might hit on some way to get > > > more performance out of it (because it's all they've got, and they need > > > the performnce). The trick they discover just might also be useful to > > > speed up ASICs (or FPGAs, or ...) > > > > And just exactly HOW would they extract more performance from it? A new > I've read some moronic statements on this list, but this is one of the > best (or worst)! > Are you incapable of believing that the multiple pipelines you just > mentioned could not have been built in TTL. Of course they could. OK, > they'd not be as fast as an FPGA or ASIC implementation, but so what. > They would be faster than a traditional processor built in TTL. And that > would be enough to prove that the design worked, and that this was a way > of speeding up other processors. They WERE built in TTL, back when TTL was the relevant technology and they had no better options. Even back then, it was more sensible to simulate the new architecture to see whether it really offered the enhancement it seemed to offer. If that worked out, hardware was built. Today, that hardware is built in a programmable hardware scheme of one sort or another. > > architecture would require new software, both in development tools and in OS several > > hundred lifetimes, and the generation of a full set of software would take > > that one individual working alone, until well after the next big-bang. > Never underestimate what hobbyists can do. FWIW, plenty of hobbyists have > designed their own processors and produced at least a monitor program for > them. And it doesn't take that long. So what? Every EE student has had to do that in order to get his sheepskin. It's part of a required course. Building his own processor and coming up with something useful are quite different. > > > That's a lot of 'maybes', sure. And I don't think it's likely. But I also > > > don't think it's impossible... > > > > It's highly unlikely, simply because it's WAY too much work to twiddle the > > hard-wiring and WAY too slow to use TTL, and uses WAY too much power so folks > As I mentioned above (although you seem to be incapable of seeing it), > the actual speed doesn't matter. Just that it shows a significant speedup > over another architecture built with the same technology. > Also the power consumption is hardly a problem either. My old 11/45 has a > 250W PSU for the CPU boards (only). Many PC power supplies can now exceed > that. 2 or 3 PSUs taken from old PCs will power any TTL-based processor > you're likely to build. a 9-volt battery is probably capable of powering any CPU I'd be likely to build. > > doing serious development, even at the amateur level, use simulators to > I will use a simulator when somebody makes one that I can trust. Meaning > that it passes all of my little test circuits. Since that's not happened > yet, I don't feel I can trust the results of the simulator. Well, the industry has relied on them since back when I was in college. If you don't trust someone else's work, proven over two or three decades of constant use by hundreds of thousands of engineers, write one that's better. > Even then, there's no reason to believe the traces from the simulator > have any relation to reality unless you've actually verified them against > a logic analyser. So do that! I do it from time to time. > > evaluate performance of new architectures, and programmable hardware to verify > > their findings. > Some do, others don't. Period. > > > > That's not to say a person's WRONG in fiddling with discrete logic. It's just > Well, I'm glad I'm not 'wrong' in your eyes. That would have really > worried me -- NOT! > Incidentally, a board I am designing at the moment contains a > microcontroller, an 8 bit latch, a 3 to 8 decoder (for which a '138 is > _perfect_ with just the right enables), a 2 input AND, a 2 input NAND and > an inverter. Will you please tell me why a PLD is superior to a single > 74x00 for those last 3 gates? It probably isn't, but you could, of course, reduce the entire combinatorial circuit to a small PLD, but I don't know the details. > > not terribly likely to be of much use. Like masturbation, it's unlikely to > > hurt anyone and produces momentary amusement. > It (TTL design) has kept me amused most of my life... > > > And that's _exactly_ what building TTL circuits is for some of us. Now > > > will you please try to understand this! > > > > I've got no problem with that. I do, however, disagree that the industry > > nomenclature is misapplied because it COULD or even SHOULD have been used > > differently. > As I said above, even the industry can't agree on what some of these > terms mean... > HP refer to the machine code for the NUT processor in the HP41 as > 'microcode' sometimes. In a sense it is, on the ground that the NUT + > this machine code forms an emulated processor that runs HP41 bytecodes. > But it's somewhat streching the definition. > The PERQ hard disk controller (and ethernet interface for that matter) > consists of a 2910 sequencing a PROM (I think it's 24 bits wide, but I > doesn't really matter). The outputs of that PROM control various bits of > the data path for the disk controller (or ethernet interface). The > bitpatterns in that PROM are called 'microcode' in some documentation and > 'state machine' in other documentation. Which is correct? (IMHO both!). Microcode was a term cooked up to distinguish between the code executed by the "micrologic" as it emulated the target system. It was a term essential to the concept on which some computers were built. A small, very fast, by comparison with the target, computer executes a program that implements the target architecture. Certainly not a ridiculous construct. This gave rise to questions about how one might implement a fast processor to execute the target task without a full implementatation of a target architecture separate from the microengine. Voila! ... now you have the RISC. > DEC used to use the term 'microprocessor' to mean any simple processor > (often built from TTL, and very specialised in purpose, like a comms > controller) that ran microcode. This one I think is plain wrong, but... Nomenclature is dated. Before the widespread acceptance of monolithic microprocessors, those made from microelectronics, TTL, for example were referred to in some environments, not just DEC, as microprocessors. If you had what was essentially a computer, CPU, ROM, RAM, etc, implementing a CPU, you had to have a term, microcode, for the code it executed. You had to have a well-defined language for such a beast, and software to manipulate it. The product of that software was the microcode. If you used AMD's tools, (AMDASM) you certainly had a development system you could use, if you chose to do so, and that gave you a means for producing microcode for your system. Of course, it was just the code used to implement the CPU you designed, and you had to produce tools for your target architecture yourself.

I bought a Xeltek UniPro back in '89. It was a nightmare, and when XELTEK came out with their SuperPro, they sent me one gratis for all the debugging I'd done for them on the UniPro. Now, they've discontinued the SUperPro II, but all the algorithms that work on that model seem to work fine on the orignal. I think the only difference is that the "II" uses the parallel port rather than a dedicated card. Likewise, I have another similar fit-in-the-briefcase type that uses a card in the PC. It also was maintained at no charge for over a decade. The software now avaiable, still free, doesn't support this model any longer. <sigh> It's a good thing ISP parts are taking over the market. more below ... Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Tuesday, April 16, 2002 6:54 PM Subject: Re: TTL computing their to in and if comes They "universal" want... pieces had new have for sheepskin. I didn't say a hobbyis couldn't make any advances. I did say a hobbyist wasn't likely to make any advances using TTL. a exceed Power is a concern. If it's possible to do something with 50 mW, it should be criminalized to do the same thing with 5 kW. to If better. Well, if you think it's easier to build a circuit with 800-1000 components on the off-chance that you've done everything right, then I congratulate you. I prefer to use the belt-and-suspenders approach and verify with all the tools at my disposal. against That should be no problem for you, since you don't use those devices, as they require software you decline to use. and combinatorial One could probably use a Xilinx 9536 to replace all the logic, including the latch. In fact, you could just roll the microcontroller into the programmable logic, but not with a $5 CPLD. Cygnal is pushing a line of 805x types that live as hard logic in an FPGA. ATMEL is doing similar stuff as are several other vendors. Most of these run fast enough to be interesting.

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, April 13, 2002 4:35 PM Subject: Re: TTL computing can do The stuff was published, but that didn't mean just anyone would even want to tackle the problem. Today, publishing the programming algorithms would produce a service headache for them, so they don't do it. Programmers for EPROMS, EEPROMS, bipolar PROMS, and Small Programmable Logic Devices (SPLD) are pretty cheap, and, quite common nowadays. The software is free, and today's small devices are reprogrammable so they can be incrementally developed and programmed. Larger devices are programmalbe in-situ, and the software to do that, as well as to develop the logic is also free, at least with some manufacturers, (Altera, Xilinx, Lattice, Atmel, among others) The only real problem I've encountered myself is dealing with the packages. The cheaper packages are all surface mounted, and adapters from those packages to more conventional and easily handled packages are quite expensive (on the order of $1k) Prototyping boards are available, but they're ridiculously costly as well. If you don't sell 'em anything, you can't be held responsible for what they do with it. If they buy a few parts from somewhere and abuse them, it's not on you. If you specifically tell them they're not allowed to build your circuit, as you retain the rights to it, but choose to share the information contained in it anyway, you certainly can't be held responsible if they build it. Just wait until someone sues you because you used parts in your design that cost more than some other combination of parts, thereby causing their costs to go up. That'll get you to stop that sort of stuff.

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Sunday, April 14, 2002 12:36 PM Subject: Re: TTL computing program which to I don't think it's bogus. There's a big difference between telling the user, in the datasheet, how to program his device and in fielding a phone-call regarding that matter. The mfg's know how many phone calls they have to deal with in connection with that sort of question and it didn't take them long to figure it out. Intel published the spec's on how to program their programmable devices including MCU's. The didn't however, publish the programming specs for their PLD's. This would cost 'em millions, and they save those millions simply by ignoring anybody too cheap to buy a programmer. Those parties aren't likely to help their sales numbers much anyway. HP is not an IC vendor. Their practices have always been what I've considered unfriendly, so I've endeavored to avoid their products. Printers, notably, are an exception to this policy. is Tony, YOU've made the choice to avoid the software and hardware that make things easy. Don't presume to criticize the device vendors for failing to support YOUR hobby. you nobody chips. they do again! on information If you don't want the associated headaches, don't publish the circuits. That is the choice that the programmable logic vendors decided to make. build design I don't think that's a choice either of us is qualified to make. You're putting your fate in someone else's hands, Tony. I'd rethink that option.

Tony Duell wrote: I may go back to TTL ( but not sure yet ) because too the only programing platform is windows ver ??? and 5 years down the road when I want to do a upgrade, the software to program my computer is 1) not around 2) will not run on my machine 3) require 1253 meg of crap to run, 4) will need a new license. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

Richard Erlacher wrote: I was refering to CPLD's software. Hmm maybie I better just order thousands of diodes and transistors today and start making flip/chips instead. :) -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

A non-text attachment was scrubbed... Name: not available Type: text Size: 823 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020417/1f601fdb/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 8994 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020417/0b9638f0/at…

On Wed, Apr 10, 2002 at 01:21:30AM +0100, Tony Duell wrote: [...] Here we have a fine example of what happens when computer-science meets electro-engineering... Mathematically there is no difference between a state-machine and microcode. Both are just different methods to describe a finite state machine. On a high level design view it's called state-machine if you draw a graph and "microcoded" if you write a program. On hardware-level you use a ROM for outputs and some logic to compute the next state for a microcoded design. In a state-machine-design both the outputs and the next state are computed by a single logic block. State Machine: ---->|------|---> IN ---->|State |---> OUT ---->|Mach. |---> | | |-->|______|--| next state | | --[StateReg]<-| Microcoded Machine: ---->|---|---> IN ---->| R |---> ---->| O |---> |--[Counter] | M |----| | |-->|___| \MUX/<--- IN | | |-[StateReg]<-- The MUX selects if next state is the next ROM-Address (counter) or an Address supplied in the ROM. The first design is smaller and faster and the second can be changed more easily... bye Thilo

Richard Erlacher wrote: Yuck!!!! more bloated programs! -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

Well, my recollection may be different from that of others simply because of when it was formed, but back in the '70's, when bit-slice was becoming quite popular as a means for creating a computer from hardware of various sorts, the notion of microcode was used to describe the code for the particular bit-slice family, often the AMD 2900 series, that was used to create a specific design. Each instruction in the set attributed to the final target system was implemented in some number of more simple instructions for the bit-slice engine. ----- Original Message ----- From: "Thilo Schmidt" &lt;thilo.schmidt(a)unix-ag.uni-siegen.deTo: &lt;classiccmp(a)classiccmp.orgSent: Wednesday, April 10, 2002 1:02 PM Subject: Re: TTL computing and or Well, that's how it's being envisioned for the next generation of development software, preliminary bits and pieces of which are being tried out on the EDA community. You write a program/description for a task, and the software generates the program for the combination of programmable logic and software that accomplishes the task. It's not defined in advance which functions will be implemented in hardware/firmware and which will be accomplished strictly in software, and, in fact, the hardware configuration may change on the fly in order to facilitate the task. You're right, of course, in that it will take a while. I remember when the first efforts on VHDL were being touted in the US defense industry. It took a decade before a useable for m of VHDL was available and even the versions available today have many quirks not forseen in the early phases of its development. Of course the FPGA vendors didn't have their fingers in the pie back then. A quick look at the details associated with the AMD2900 series will clear up whatever gaps there are in your understanding. The tools were not that primitive, and the instructions, though simple and quick when compared with single-chip CPU's of the time, were quite effective. The 2900 series was far and away the most widely used microcoded component series, IIRC. <snip> While I agree that today no one does such a design by foot but the principle > is still the same. Even in modern^H^H^H^H^H^H currently marketed CPUs > like the Pentium4 there are microcoded Areas where you can load updates > to correct bugs. Intel has learned it's Pentium-Bug-Lesson. > > The "next-generation" tools will take a program in a high-level language and goes > > on the hard disk. > Hardware-Software-Co-Design is a very interesting research area but > IMHO it will still take a while till the results hit the market. > bye > Thilo > -- > The most exciting phrase to hear in science, the one that heralds new > discoveries, is not "Eureka!" (I found it!) but "That's funny ..." > -- Isaac Asimov

A non-text attachment was scrubbed... Name: not available Type: text Size: 2469 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020412/4a384d34/at…

software tools determine the optimal hardware configuration, hardware/software interface, and then compile your application, including all the optimal hardware characteristics and configure your hardware to assume that configuration. I don't know what that does to multitasting. Dick ----- Original Message ----- From: "Thilo Schmidt" &lt;Thilo.Schmidt(a)unix-ag.org&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Friday, April 12, 2002 5:13 AM Subject: Re: TTL computing

We should be careful here, lest we be accused of inferring that if a computer has a nand gate, then a nand gate is a computer. A computer is likely to have several state machines. Defining the computer as being a state machine is like saying a '747 is a light bulb. more below ... Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Wednesday, April 10, 2002 3:50 PM Subject: Re: TTL computing machine. Actually, there's a mathematical difference between them, since the microcode is just to ROM or fuse array content, while the state machine is the combination of that with the combo-logic and registers that comprise the state machine. If it's microcoded, there's a complete execution unit the purpose of which is to execute content of the microcode ROMs. If it's a hand-wired set of transitors and diodes, or whatever, functioning as a state machine, it's not microcoded, since there's no distinct microcode. Now if you want to redefine the logic design as being microcode, that's up to you, but it reduces the number of folks who'll understand what you mean, not that there won't be quite a few who're confused no matter what your nomenclature is. I did say it was a semantic quagmire ...

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.uk&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Thursday, April 11, 2002 6:43 PM Subject: Re: TTL computing computer as I've argued that in the context of exhaustive system testing. Any computer, and, in fact, the worldwide computer resources, viewed as a system is still bounded, though very large, and could, in theory, be viewed as a finite state machine. I challenge you, however, to come up with a way to validate such a system, whatever the size, using a computer, such that every possible combination of bits in mass storage, in semiconductor memory, and in inputs and outputs, is exercised and the system behavior rigorously characterized. How do you create an infinite stack? I'd submit that if it has an infinite anything, it isn't a Finite State Machine. meets microcode state is In the context of "microcoded" system it is a small fast computer used to implement, physically, the behavior and resources of a larger more complex, and somewhat slower, system. not redefine The applications I've seen use a multi-component chipset that allows considerable flexibility in configuration of the "target" hardware/software system and executes primitive microinstructions to implement the target instruction set and implement the target resources. It's essentially a simulator, consisting of both hardware and firmware, that functions as a computer that, in effect doesn't really exist. That's what makes 'em so flexible. That's also why they're ultimately implemented in hardware with considerable reduction in cost and increase in performance.

see below, plz. Dick ----- Original Message ----- From: "Tony Duell" &lt;ard(a)p850ug1.demon.co.ukTo: &lt;classiccmp(a)classiccmp.orgSent: Friday, April 12, 2002 12:56 PM Subject: Re: TTL computing I must have slept through that class, since I've never been introduced to anything physical that's infinite, and I've never seen a computer that's not physical. I've seen machines that were virtual running on machines that are physical, and that's what a microcoded machine is. computer, still state a inputs characterized. The 64K DRAMs I had only had 2^16 bits, each of which had two states. My old 6502 would test his RAM, static though it was, but still 64K of it, in the time it took me to consume a couple of beers, and I didn't get this gut from sipping 'em. infinite Yes, but that's because there's no way of making an infinite counter. As for the business of counting, if you can have an infinitely long string of characters and an infinitely deep stack, then you can have an infinitely long counter, a state-machine in itself, and that can deal with your problem. Well, they don't build stacks that don't have counters in them, and those are FSM's. Until you can come up with a physical stack that's infinitely deep, this point is moot. The detail that's been omitted is that you can't build a physical stack without a FSM, in the form of an up/down counter, since you otherwise haven't any means for manipulating the stack pointer. You can't have a infinite stack because you don't have an infinitely large memory, though some of the ones they sell nowadays, and what you're going to have to have for the next release of Windows, may seem that large. You can put terabytes of RAM in a box and address it as though it were a mass storage device, or as though it were a stack. It's up to you, but it's still finite, even if you have hundreds of exabytes. the above... I see a major implementation problem, in that you throw around the word infinite quite freely. It's possible to build counters of 2^64 bits, and it's possible to hook up 64TB memory arrays, but it's still nowhere as large as infinite. Until you have an infinitely fast computer, it wouldn't make sense to have an infinite memory, since you wouldn't be able to test/verify whether/that your infinite stacks, or whatever, work properly. If you can't do that, it's not useable.

A non-text attachment was scrubbed... Name: not available Type: text Size: 5176 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020413/d9ead19e/at…

Richard Erlacher wrote: (computer science stuff) I really don't care what it was called. Shift register stacks do have the advantage of being fast. Did not the 8008 or the 4004 use a 8 level stack for subroutine calls. A calculator chip at that time only needed 4 functions. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

Richard Erlacher wrote: Wow - can's that is REAL old and expensive logic. Late 1970's. While more functions are useful, Most low end calculators ($3?) just do the 4 functions. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

On 12-Apr-2002 Tony Duell wrote: [excursion to theoretical computer science] Yes, because if you put everything on the second stack what you took from the first stack you can simulate a tape... :-) Not necessary, AFAIK everything said above was correct. To get the hierarchy ("<=>" means equivalent): FSMs <=> regular languages <=> primitive recursive functions PDAs <=> context free languages <=> partial recursive functions Turing Machines <=> context sensitive languages <=> computable functions But this is getting heavily OT, so everyone further interested should read the book about automata theory by Hopcroft and Ullman. (I hope I got the names right, I've got the book but can't find it right now) bye Thilo -- I am professionally trained in computer science, which is to say (in all seriousness) that I am extremely poorly educated. -- Joseph Weizenbaum, "Computer Power and Human Reason"

On Wed, Apr 10, 2002 at 10:50:56PM +0100, Tony Duell wrote: No, as you pointed out below it is possible to implement a microcoded design as a state-machine. You have to seperate the design and the actual hardware implementation. A microcoded machine is always a state machine but not every state machine is a microcoded machine. see below... No, now you don't have a seperate ROM (or PROM or any other kind of linear addressable memory) any more. The main reason to use a microcoded machine instead of a "pure" state machine is that you can change it quite easily by putting another "program" in the ROM. If you put all the functionality into a single block and probably minimize it you wouldn't be able to change it without messing with the hardware (your beloved soldering iron ;-)). If you want to tell me now that a ROM cannot be changed: That's right, but it's only a ROM for the microcoded machine. In reality it's most likely an EEPROM, a FlashROM or a SRAM. If you implemented the thing in discrete logic it's probably possible to change it by soldering wires all over the board, but if you made an ASIC you would have to change the masks and physically replace all chips made... Of course if you use a FPGA it really makes no difference... bye Thilo

A non-text attachment was scrubbed... Name: not available Type: text Size: 2345 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020412/b33dd506/at…

Richard Erlacher wrote: How ever the ROM does contain ALL the possible states compared to PAL's or discrete logic. BTW B.G micro does sell 74LS170's, and AM2901's. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

see below, plz. Dick ----- Original Message ----- From: "Ben Franchuk" &lt;bfranchuk(a)jetnet.ab.ca&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Friday, April 12, 2002 8:39 AM Subject: Re: TTL computing costly a than It doesn't help having all the unused states represented in your ROM. Discrete implementations and programmable devices both cover all the REQUIRED states, and having other states supported is certainly unnecessary, as well as potentially hazardous. I've not needed a '170 in over two decades. I do have a supply of '670's, which are the tristate version of the same device, and I just this week finished an application using a couple of them in a display application. They're pretty handy when you have no synchronization between the inputs and outputs, and, as was the case in this 7-segment display device, when your inputs are byte-wide, and outputs are nybble-wide.

I'm afraid that the Nixies are too large for this handheld application. Dick ----- Original Message ----- From: "Ben Franchuk" &lt;bfranchuk(a)jetnet.ab.ca&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Friday, April 12, 2002 10:46 AM Subject: Re: TTL computing REQUIRED well as and

On 12-Apr-2002 Tony Duell wrote: And I've been trying to say that microcoded machines are just another way to describe finite state machines and what can be gained through this description... In fact the first thing I wrote was that they are mathematically equivalent. This whole discussion seems to have gotten slightly out of control... ;-) bye Thilo

A non-text attachment was scrubbed... Name: not available Type: text Size: 1607 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020413/9dfebd43/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 5172 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020414/0cf39394/at…

On Fri, Apr 12, 2002 at 01:48:12AM +0100, Tony Duell wrote: I meant it it's always possible to transform a microcoded state machine in a not microcoded state machine. So you can design a microcoded control unit and decide later if you implement it microcoded or not. Your're right, but the ROM would become _large_ indeed. If your function requires 16 external inputs and 4 inputs for the current state you already need a 1MBit ROM. Now you need 4 outputs for the next state and lets say 4 other outputs. So you would need a 1MByte ROM to implement your machine... I'm not sure what you mean by "feedback ROM", if you mean an additional ROM between the outputs an the state latch you have and microcoded state machine again... ;-) bye Thilo

The P856 and P857 are TTL based, microcoded designs. Both used 4 74181's ( No 2901's) in their ALU and have around 200 TTL on a single PCB... Jos

A non-text attachment was scrubbed... Name: not available Type: text Size: 3297 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20020410/6364fb54/at…

Tony Duell wrote: Until I got over 95% of logic filled in my Altera FPGA, most compiles were under 15 minutes.( BTW -- Since I have 100% of the FPGA used it is time to stop upgrading the design :)). I live in the middle of (looks around) snow thus getting stuff mail order is the only way to get parts often from the USA but some even from Australia. TTL is still better for production. (grin). Ok SSI and MSI parts. Compared to millions of transistors in a cpu, all TTL parts are small. BTW altera has a fairly nice macro library for their FPGA's. I want A+~B,~A+B,A+B,A^B,A|B,A*B alu functions. The 181 can't give me that. More like a 74xx00. The Tiny chips are sure popular today, who would of thought single gate chips would sell. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

Well regardless of how you count them, the chip has no free macro cells left, and routing is very full with only a few free I/O pins. Lets not forget everything in BGA pin format too. That is the other reason why it so full, I can't move to a larger FPGA and still stay in a 84 pin PLCC package. Nope just luck and trial and error ... does feature X fit ... nope , how about Y ... then feature Z.. $%#! packages all 8 bits wide, how the **** do you find 4 bit wide memory for all the 12 bit cpu's out there. Other than inverting a chip select, I really can't see why such glue is needed. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html

Richard Erlacher wrote: True about manufacturing, but I wish one had more choice with computer hardware/software for the PC user.I think DEC sold the PDP-8 until about 1990. Since I can't find a 12/24 bit CPU that I like I am building my own. A 12/24 bit cpu chip could have came out around 1980 with the 8086/6800. Part of the challenge in the cpu design I am doing in FPGA is to have it emulate (for the most part) a fictional 12/24 bit cpu in a 40 pin dip.The last thing I added was a 8 bit refresh counter for dynamic memory and a single channel DMA for a floppy. Running at 4.9152 Mhz ( 800 ns memory access, 512Kb of ram ) I hope the Squash the XT market in 1983!. :) -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html