The Apple Set Top box uses flash SIMM/DIMMs for it's boot code. At least the one I have does. It's a 68pin SIMM with 8 Intel E28F020 flash memory chips (256k x 8). -- Home of the TRS-80 Model 2000 FAQ File http://www.cchaven.com http://www.geocities.com/siliconvalley/lakes/6757

I think that's just in the earlier prototypes. What you have is probably like this: <http://www.applefritter.com/prototypes/tvbox/box1/flash.jpg> Later prototypes used a Mask ROM: <http://www.applefritter.com/prototypes/tvbox/box2/flash.jpg> He means 'a never-released device that plugged into a TV', also known as the "Interactive Television Box". It's based on the LC 475. Info at <http://www.applefritter.com/prototypes/tvbox/>. I'd be very curious if anybody's managed to get one of these to boot. Tom Applefritter www.applefritter.com

I think so. I don't have mine with me, but as I recall, the motherboards are virtually identical, if not 100% identical. Here's a comparison of two: <http://www.applefritter.com/prototypes/tvbox/box1/inside.jpg> <http://www.applefritter.com/prototypes/tvbox/box2/inside.jpg> They look identical to me. In fact, they look so identical I'm almost worried I took two pictures of the same unit. Tom Applefritter www.applefritter.com

No, I didn't get any boxes with mine. One fellow I've talked with an original STB has a HD in his. He can't get his to boot, either, but putting the HD in another Mac he found a bunch of "Oracle Media Objects". Apparently they rely on some of the STB's hardware to work, though. Tom Applefritter www.applefritter.com

Doing a web search on "flash DIMM" shows that HP, Xerox, and Lexmark printers use something called Flash DIMM in 2M, 4M, and 8M sizes. Prices are about $100 per meg. Something called "flash DIMM" shows up on eBay for under $100. Question is, how do you program it, and will it plug into a PC mainboard and do what you'd expect it to? (no, making smoke is not what I meant). -- Jonathan Engdahl???????????????? Rockwell Automation Principal Research Engineer????? 24800 Tungsten Road Advanced Technology????????????? Euclid, OH 44117, USA Euclid Labs????????????????????? engdahl(a)cle.ab.com 216-266-6409

Very good point. I was thinking that it would be nice to have a machine that was a PDP-11 as soon as you flipped on the power, but probably not worth the cost and hassle of the flash. Didn't some of the VAXen boot their microcode Also, that way you could have one microcode floppy for each classic architecture. I think that my emulator idea can be made to work under Win32. It appears there are facilities allowing an application program to catch access violations. -- Jonathan Engdahl???????????????? Rockwell Automation Principal Research Engineer????? 24800 Tungsten Road Advanced Technology????????????? Euclid, OH 44117, USA Euclid Labs????????????????????? engdahl(a)cle.ab.com 216-266-6409

Actually much of the 11/780 microcode is in rom. The stuff loaded from RX01 is mostly bug fixes to the rom code. The patches went into the Writeable Control Store board. The 11/785 went to completely RAM loaded microcode. The 11/780 did have an optional second User Writeable Control Store board. -Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! bpechter@shell.monmouth.com|pechter@pechter.dyndns.org

I believe the 11/730 and 11/725 was all WCS and that was why the 11/730 had dual TU58s... one drive for console and one for WCS. Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! bpechter@shell.monmouth.com|pechter@pechter.dyndns.org

On 18 Sep, Chuck McManis wrote: But only a part of it. I know the person that desined the data path unit of the VAX11/780 CPU. He told me that most (3/4?) of the microcode is in ROM, with only one RAM bit per micro code word. That is the "patch bit". If this bit is set, the sequencer jumes to the RAM microcode. With this technic you can get patchable / loadable microcode without the need of a 100% (fast and therefore expensive) RAM microcode memory. An other option would be a Symbolics. (The old lisp machines.) Last week a friend and I brought 5 Symbolics 3640 / 3670 back to live. It seams to me that the CPUs of this odd machines are huge bit slice processors. I think it would be possible to turn such a machine into nearly everything with the right microcode. Unfortunately a Symbolics machine is much more rare then a PDP11. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

Jonathan Engdahl wrote: And, what I forgot to write is that the flash is slower anyway, so you copy the software from flash to *RAM anyway. yes works only if you have the OS on the floppy too. Sorry, I missed that. What is so special about your idea ? (No offense, just missed you posting I guess ;-)) Sure. But it is easier to check this yourself. cheers

Jonathan Engdahl wrote: OK. But, this microcode has to have an OS around. because: - how to use the MMU ? - you need access to serial ports ? - disks - tapes - ethernet - etc. Or do you like to program this stuff all by yourself ? Still, definitely not a Windoze, but somekind of ukernel. Anyway, start with it, and we see one day ;-) cheers & have fun, emanuel

Does anyone on this thread even understand microprogramming? Apparently not. Pentium CPU's can't be microprogrammed, unless your Intel. Even microcode updates cannot replace the basic instruction set. If you write a program in Pentium assembly code to run PDP-11 instructions, you have just written an 'emulator', even if it does not run under windows. But an writing such an emulator is not 'microprogramming'. Jonathan Engdahl wrote:

Jonathan Engdahl wrote: <snip> An assembly-level program running on a Pentium, technically speaking, is not microcode. An emulator does not require an operating system. An emulator is simply a program that emulates another machine, however its implemented. By definition, a microprogram runs directly at the hardware level. A Pentium is a microprogramed processor, so an assembly level program running on a microprogrammed machine cannot really be called a microprogram. Exactly these are terms with fairly well defined meanings! I understand the concept, its called emulation. My only issue here is the terminology, not the merit of the concept.

Hi Tony, Tony Duell wrote: I understand your confusion here, but in this case there already is something defined as microcode. Simply adding another layer of complexity does not change the underlaying microcode that runs directly on the hardware, its still the microcode of the engine. This underlaying microcode still implements the instruction set of the physical CPU hardware. In the (odd) case you describe above, your still running an assembly-level program on an already microcoded machine. Such a strange application does not redefine the existing microcode into 'nanocode'. The code in the ROM is still made of instructions which are interpreted by existing microcode. The difference is very very clear at the hardware level. The 'hardware level' means that the micro-operations are executed by physical gates and devices. These gates and devices will (must actually) form state machines, like the AM2910 microprogram sequencer. So the presence of state machines (you can't run microcode without them!) is not an issue here. Hence the term 'assembly level program'. It this discussion about computers, or terminology? Some machines do have a programmable layer below the microcode, but its very rare. Some machines (Interdata?) have nanocode. This is used for very basic functions like controling main memory addressing modes, etc. Other machines (like the VAX series, and later Pentiums) have more than one microcoded engine in the CPU, one for data processing, and another for program flow control. Basically, if a machine is already microcoded, the term is already taken. Here's an example of why its completely wrong to use the term microcode for an assembly language program... I have a HP 2114A computer. Its not microcoded, it uses state and phase counters, and a huge array of gates to decode the state, phase, and instruction register contents into the control strobes that actually run the hardware. I can run small programs on the 2114, and then take that exact same binary-level code and enter it into a HP2113E, a true microcoded machine. Now this same binary, machine language program will run identically (well, much faster, but logically the same). But I still cannot call this binary program 'microcode' on the 2114 simply because the 2114 is not microprogrammed. Does this same binary code suddenly become 'microcode' when it runs on the 2114, but transform into an assembly language program when run on a 2113? Of course not. The only microcode here is sitting in chips on the 2113 CPU. (note, the early 2100 series machines describe 'microprogramming' as holding more than one op-code in an assembly-level instruction, but this is NOT the accepted usage of the term today) No, instructions may run directly on the hardware, using the conventional state and phase counter approach to designing a NON-MICROPROGRAMED processor, like the HP2114, or your ARM chip. VHDL is clearly software. The FPGA itself is hardware. The configuration data generated by the VHDL is also software that is processed by the FPGA hardware. This is really back and white. Where is the silicon? Thats the hardware! I totally disagree. Your M792 board is hardware, but the data stored on that board is software. But that software simply does not have a license agreement. A EPROM is hardware, but the data held in it is software, and may very well need a license. A license is not what makes something software Tony, its simply the fact that its built out of bits rather than silicon. The line between them is very clear.

Tony Duell wrote: <snip> Ok, so normally code running on a microprocessor is 'not normally' described as microcode. Lets start from here.... <snip> Ok, so now we have code running on an ARM microprocessor, a non-microcoded architecture. So now why would it be correct to call the program running on a non-microcoded microprocessor, "microcode"? Clearly on a non-microprogrammed machine, there is no microcode. So does choosing a different name suddenly turn the ARM inso a microcoded architecture? Very clearly it does not. So simply choosing to use terms to describe totaly different levels of hardware abstraction is not such a good idea. This is called emulation, not microcode. Otherwise your application gets to define a processor as microcoded or not. I think the problem here is that your describing an assembly level program which performs a similar function to the actual microcode in say, a PDP 11/45. But performing the same function on a different machine already has a term, its emulation. Emulation is simply not microcode, and its not correct to describe it as such. Try bending terminology like this on your resume some time, and see how the industry reacts. Back up for a moment, and look at the application your suggesting here. An assembly level program, running on a microcoded machine, emulatating another processor. So now you replace the microcoded processor with a non-microcoded one, and still claim there is microcode present? Not at all! Processors that use this design method are quite common. Usually there are state and cycle counters. Combinatorial logic is used to decode the instruction register, state and cycle counters to drive the control signals for the CPU logic. This is NOT microcode. This is a non-microprogrammed machine. An example of this is the good old 8080. Contrast this to the design of the Pentium or other microprogrammed design. The presence of a control store eliminates all that combinatorial logic. I reccomend you get a copy of Mick and Brick, Bit Slice Microprocessor Design. An excellent book, it even has plans for a PDP-11 emulation with 2901's. <snip> <snip> Understood. But look at the complexity of altering the actual combinatorial logic and the firmware. Clearly the firmware is much more practical to alter, and this is why microprocessors are so popular. But this, as you say, it still Z80 machine code. Inside that Z80 there are huge areas of combinatorial logic that decode the instruction register, cycle and state counters to drive the control signals for the CPU logic. (the Z80 is not microcoded either) If you replaced all that combinatorial logic with a ROM, the contents of that ROM (no the physical ROM itself) would become microcode. So its not the gates, its the logical expressions they encode, and its a full layer of complexity below Z80 machine code. <snip> See above. Correct. And the contents of the PROMs is the microcode, not the PROMs themselves, as described above. <snip> Because its basically the same thing that other manufactuers call microcode, and being its Intel's processor, they get to make these choices. You can choose to redefine all the terms you like, but that does not make your usage correct, or more correct than the acutal manufactuers terms. Not odd at all, the manufactuer is using terminology in a standard way so that it is clearly understood by the industry. <snip> Ok, so then running a PDP-11 emulation on an ARM would be... A, Emulation. B, Emulation. C, Emulation, or D, Microcode, because I feel like calling it that. <snip> Its all about how its implemented. If the machine level instruction set of a processor is implemented with fixed, combinatorial logic as opposed to a stored 'microprogram', its not a microprogrammed design. If you then use the machine code for that machine to emulate another processor, you are writing an emulator. The machine code may, or may not be microprogrammed, it makes no difference in this case. If you alter or create the microprogram of a microcoded processor to emulate another processor, you are writing microcode, and an emulator at once, your actually writing the emulator in microcode. But this is not what was proposed at all. What was proposed was writing an emulator in machine code, on an already microprogrammed processor, and calling the result 'microcode'. This appears to be totally unambiguous, unless I missed something.

Bob Shannon wrote: Well, I understand microprogramming. I though we were speaking figuratively. The "microprogramming" we were talking about was treating the Pentium as a very complicated micro engine.... Which IMHO it really is. Using your definition every machine that has writeable microcode is "emulating" something else... I recall that MIT built a native LISP machine using 2901 bit slice processors. Wasn't this the basis of the Symbolics machines??? Does anyone recall the name of the 2901 based machine that could be transformed into 8080,Z80,6800,68000, etc. I believe that it came out in the 1980's. Emulator or not I still think that it is a cool idea.... A kind of VMware fro PDP-11. On a 1.4Ghz processor it should really haul. Mike -- =============================================================================== Michael L. Drew Drew Technologies, Inc. 41 Enterprise Drive Ann Arbor, MI 48103 Phone: (734) 623-8080 Fax: (734) 623-8082 ===============================================================================

I got an advertisement from a shop that does short-run injection molding, etc, which I haven't read thoroughly, but as this was a recent topic, I'll forward it to anyone interested. I'm not going simply to forward it to the list for reasons of saving bandwidth. Anyone interested in reading this ad, please email me and I'll make a list and forward it to that list in a day or so. Dick

A source for the PDP 11 red, purple, and white ones would be useful. --tom At 09:52 AM 9/19/01 -0700, you wrote:

But nothing within two orders of magnitude on the performance/price curve. -- Jonathan Engdahl???????????????? Rockwell Automation Principal Research Engineer????? 24800 Tungsten Road Advanced Technology????????????? Euclid, OH 44117, USA Euclid Labs????????????????????? engdahl(a)cle.ab.com 216-266-6409

A non-text attachment was scrubbed... Name: not available Type: text Size: 976 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010922/4541e321/at…

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

It was thus said that the Great Bob Shannon once stated: But the PERQ with the POS microcode is emulating a POS machine! And an Apple ][ with the POS environment is emulation a POS machine! One is in hardware, one in software. The only difference is one of speed really. The Tandy Color Computer has three one bit ports for serial I/O. One for carrier detect, one for transmission and one for receiving. To send one byte using 8n1 at 300 baud, you have to send the start bit for .003 of a second, then send out each bit to the one bit port and hold the line steady for .003 of a second, then the stop bit for .003 of a second. On the IBM PC (and compatibles) you have access to a UART (an 8250 or 8250 compatible device) and all you have to do is set the chip to send 8n1, set the bps, and then once that is set, you check the status to see if it can send, and once it's clear to send, you write the byte to a register. Software. Hardware. One is slower, but more flexible (I can do 9e3 at 472 bps if I need to) while the other one is faster but less flexible (I can't do 9e3 at 472). And what you can do in software, you can do in hardware, and vice-versa. -spc (It's interpreters all the way down!)

On Wed, 19 Sep 2001, Tony Duell wrote: Good point. I agree. The boundary between the levels is totally in the eyes of the beholder. What physical format would this project assume? I can think of several right off hand: * A card that emulates CPU/memory and plugs into the (Uni|Q)bus of existing machines. * A box that sits inside a PDP-11 cabinet and replaces the entire bus and all of the cards. * A hand-held, battery-powered unit similar to a Game Boy. It's the third idea that seems the coolest to me. Build it low-power enough to run on a few batteries. Give it a front panel with switches and LEDs for the processor and emulated peripherals. Add a serial link (or maybe even a Zip disk) for transferring files to/from another computer. It would be the ultimate toy. Just think of all the flavors it could be made in. I'd love to take one of those to class with me. The other CS majors, with their PalmPilots and their MP3 playaers and their TI-92s, would be absolutely blown away. -- Jeffrey S. Sharp jss(a)subatomix.com

There is a port of an older version of simh to Windows CE. It runs on my Jornada 430, but I have not yet been able to boot the RT-11 floppy image. Look for pdpCE, I think. There's a link to it from somewhere in my web pages. -- Jonathan Engdahl???????????????? Rockwell Automation Principal Research Engineer????? 24800 Tungsten Road Advanced Technology????????????? Euclid, OH 44117, USA Euclid Labs????????????????????? engdahl(a)cle.ab.com 216-266-6409 http://users.safeaccess.com/engdahl/pdp-11.htm

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

Tony Duell wrote: <snip> Yes, the distinction is unclear in some cases, but not at the levels your trying to fit these terms into. Micro-instruction technically speaking. The PERQ takes several microinstructions to read main memory, while an assembly level instruction may perform several memory cycles per instruction. There is an huge, and very clear difference here. <snip> The point here is, your running assembly-level instructions that are implemented with true microcode already. So you clearly are not writing microcode, your writing assembly level code for a Pentium. This is totally clear in your first sentance above! No, its not microcode. Its an assembly-level program that emulates a PDP11. Why not? Because there already is microcode running, or your Pentium cannot run your assembly level program. Whats unclear here? If you want to run microcode, fire up a PERQ. If you write assembly-level programs for a Pentium, your writing an assembly level program, not CPU microcode. Once again, these terms have definitions already. Learn them, and use them correctly, please. <snip> I have no idea Tony. But I've written microcode, and also assembly level code. There is a vast difference between them. <snip> Sorry, I don't seem to be able to help here. All I can say is that your useage of the terms is totally incorrect as they are used by people who write both assembly-level and microprograms. There is a full order of magnitude of difference in the degree of hardware abstraction between these two very different forms of programming. It appears to me that your trying to defend the incorrect usage of a cool-sounding term, you clearly have some emotional attachment to. As this list is about computers and their technology, I wanted to step forward and correct this misuse of terms to prevent others from learning a highly incorrect usage that can only sow more confusion.

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

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

Chris Kennedy wrote: Not at all. I'm not even attempting to define 'microcode' specifically. The application in question was an emaulation of a PDP-11 running on a Pentium processor, in Pentium assembly level code. This is unquestionably emulation, and is a full layer of abstraction away from the Pentium's physical microcode. To describe this application as 'microcode' is indefensibly wrong. <snip> Not a bad definition. Now apply this to the concept of emulating a PDP-11 on a Pentium please. I disagree with your interpretation of IBM's definition. Firmware is clearly program-addressable! <snip> First off, I strongly doubt that the majority of list members have ever written true microcode. Its just not commonly done. Secondly the use of a non-microprogrammed machine has nothing to do with the definition of emulation, nor microcode. Lastly, I'm not familiar with the K6 microarchitecture, so I cannot comment on its operation. But lets remind ourselves of the actual issue here. Running an assembly-level program on a Pentium which emulates the instruction set of a PDP-11. This was described as microcode. Its clearly an assembly-language emulation. Once again, whats unclear here? <snip> Really? An assembly level program, running on an already microcoded processor is still microcode? Do you put this sort of experiance on your resume? Um, emulators can be written in microcode. Perhaps this is how the K6 works? <snip> But firmware IS program-addressable, now isn't it? I don't agree that my concept of 'microcode' is at odds with IBM's.

On Sun, 23 Sep 2001, Chuck McManis wrote: I've seen this statement paraphrased in sig blocks before, but in those cases it was an attempt at ironic humor... <ducks quickly> :-D -- Jeffrey S. Sharp jss(a)subatomix.com

A non-text attachment was scrubbed... Name: not available Type: text Size: 3503 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010923/59bce165/at…

Tony Duell wrote: <snip> Ok Tony, Its unconventional, I agree. All I was saying is that your not using the term microcode in the 'correct' way, which is to say using the conventional meaning of the term. So incorrect is not wrong then. I give up.