I am building a Baby/SSEM using a Nexys2 but sadly the board is now end of life.... Dave

I think there are a several options for the degree of authenticity with FPGA re-implementations. At the simplest of levels my Baby Baby runs at the same speed as the full sized Baby, but it currently uses a 32 bit parallel logic in many places as I built a 32 bit wide store and it keeps much of the HDL "code" simple. I do intend to try a full serial machine at some point, but its low on my list. I have only really use the Xilinx ISE in anger, but I note it is possible to see the generated gates generated from the HDL or simulated HDL from a gate level diagram. I believe you can also mix and match gates and HDL (I have not tried, too many other things to do.) My next project is likely to be the Ferranti Pegasus which is several orders of magnitude more complex than the Baby and will need a proper plan. Dave

Actually the Pegasus "should" be relatively easy to implement in FPGA. It is all locked to 333Khz clock track derived from the drum. As all storage elements are delay lines which also run at the same speed as the drum, so you can transfer data between the two without using buffers almost everything is tightly coupled to the 333Khz clock. It was also one of the first machines to use standard replicable modules. According to Simon Lavington's book (which I don't trust 100%) there are 20 types of package in a basic Pegasus I, and you need 444 to build the machine. Out of these 314 are used to build the CPU but there are only 5 types of standard module. So in practice its built a bit like a large PDP/8S but with Valves. Charles Owen who Lavington credits with coming up with the Module Concept went to work for IBM in 1956 and was later made an IBM fellow. https://books.google.co.uk/books?id=Dhk9wHXfQMkC&pg=PA165&lpg=PA165… It has germanium diodes so few wired OR's as far as I know. Altas would be great fun. I suspect you could do it by using multiple independent clocks and complex handshaking... Thanks, Dave.

My work has been using structural models, at the gate level, in VHDL (Verilog would be fine, too, of course). Individual components (for example, a piece of an IBM SMS card, or in my existing case, gates made available to student engineers that were actually individual gates/chunks of DTL chips) get little behavioral models. As I mentioned, so far what I have done is reproduce and test a 12 bit computer designed in an electrical engineering course on logic/computer design. In August I plan on publishing my experience on a website. I would note that I also see value in the behavioral approach, which really would be considerably more detailed than what you get form SimH. The IBM 1410 cycle-level simulator I have written is closer to what one might get from a behavioral model, but even that is not quite so detailed. Using the structural / gate level techniques, one does run into some issues, most of which have (or will probably have) solutions: 1) R/S latches composed of gates in a combinatorial loop. The problems this causes are several, including the latch getting folded into the look up tables for gates which use the signal, and issues when one brings such a signal out to an I/O pin to feed to a logic analyzer, which can cause problems to appear and disappear. My experience is that one can add a D flip flop after the RS latch. This typically works because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate delays these old machines typically had. 2) One-shots. I haven't had to address this one yet, but I am sure that I will. I expect that one can simply use a counter to handle it - no big deal at all. 3) Flip flops which are clocked from combinatorial signals. These tend to cause timing/glitch issues. For example, in one case the combinatorial output was a zero-check on a counter. Since the counter flip flops did not all change at exactly the same time, that signal could glitch during the simulated machines master clock edge. They respond well to the same general solution as #1 - stick a D flip flop between the combinatorial output and the clock input. In the case I mentioned, that gave the signal an entire 50 Mhz clock period to settle down. And of course, getting the detailed information one needs to develop such a model can be a challenge. Fortunately for the older IBM machines, IBM produced ALDs - Automated Logic Diagrams - which I hope will generally have enough information. My experience on FPGA forums during the development of my 12 bit computer implementation was mixed. I got some helpful comments, but the majority of folks were not helpful, and instead preferred to bash me for not redoing the entire machine design using FPGA's the way these particular folks felt was "the only right way" to use them. Bah. JRJ On 7/14/2015 2:58 AM, Dave G4UGM wrote:

The reason I choose to use VHDL (or Verilog), both of which really *are* IEEE standards: future portability and broadness of access across multiple manufacturer's devices in the future, and compatibility with logic simulators. The 1130 is more modern than the machines I am interested in. While there are still several 1401's our there in the wild I am aware of no IBM 1410's anywhere, unless IBM has one squirreled away somewhere. JRJ On 7/14/2015 11:16 AM, ben wrote:

Sometimes it is fun to be a relative expert on an obscure branch of knowledge that few people are even aware of. I worked on one when I was a student, as an operator, programmer and systems programmer. Tweaked its FORTRAN compiler to spit out text error messages instead of just error codes. The FE trusted me to swap out Selectrics, including plugging their paddle cards into the SMS slot on the console. It was my first "real" job. If it were not for me with assistance from Paul Pierce, this tape (and a couple of others also on Paul's site) probably would not have been recovered, and the software for this machine would be lost to most folks: http://www.piercefuller.com/library/kpr155.html On 7/14/2015 6:30 PM, William Donzelli wrote:

I didn?t like what happened with flops built out of gates when doing my 6600 model. So I replaced those by behavioral models. The main reason was that the crossed-gate model would produce a mess with R and S both asserted, which that design would do at times, while the behavioral model was written to do something specific for that case. If you?re creating a model to run in simulation, you can just write a delay. But that?s not synthesizable, so if you really do need a delay then a counter, or a shift register, or something like that will be needed. This is the sort of thing that makes a 6600 design tricky (and may also apply to some other fast machines): there are places where propagation delays are used for correctness, and if the replacement hardware is ?too fast? it doesn?t work. That sounds like a bug in the original. If you have a set of flops clocked by some signal, and it matters that the outputs don?t all change at the same time, then the original wasn?t reliable either. paul

One possible answer is ?because I can?. As for whether it accurately reflects the details of the real thing, that depends. Not the peripherals, of course. If the peripherals are much more interesting than the CPU, I agree there isn?t much point. In the case of machines like the CDC 6600, the CPU is very interesting, the PPUs also, some of the peripheral controllers to some extent, but the peripheral devices themselves are not interesting at all. An FPGA model can reproduce the interesting parts. The accuracy of the FPGA depends on the approach. If it?s a structural (gate level) model, it is as accurate as the schematics you?re working from. And as I mentioned, that accuracy is quite good; it lets you see obscure details that are not documented and certainly not visible in a software simulator. The example I like to point to is the 6000 property that you can figure out a PPU 0 hard loop by doing a deadstart dump and looking for an unexpected zero in the instruction area: deadstart writes a zero where the P register points at that time. But you won?t find that documented or explained anywhere. The FPGA model derived from the schematics reproduces this behavior, and when you look at how it happens, the explanation becomes blindingly obvious. *This* is why I feel there?s a point in doing this sort of work. paul

Certainly, the physical aspects are completely different. And clock distribution, certainly. Not so much between chassis, interestingly enough, but throughout the logic within a chassis. And wire delays in chassis to chassis cabling are very significant. Wire delays within the chassis, in a few cases, but 99% of the wires are short enough that their delay is not a real consideration in comparison with the logic circuit stage delay. The example I gave, and others like it, are properties of the detailed logic design, they are not dependent on the details of the timing closure, or the physical design of the machine. paul

On 7/14/2015 11:17 AM, Chuck Guzis wrote: For the moment you can still get FPGA boards with expansion conectors. The $39 card the trend nowadays. Hard to get real I/O of any kind as we know. Since when was that new in electronics. Mind you New Electrostaic speakers and OLD Quad II's go well together. Don't look at me, I lost the bid some old IBM equipment years ago. You can still the old computer blinking lights movie props. Ben.

That's an interesting argument against using FPGAs in this sort of application; definitely food for thought. That said, from my (admittedly limited hobbyist and academic exposure) to FPGAs, I would expect the bulk of of whatever's being implemented would be fairly device-agnostic ... certainly you might have to go and recreate your "project" in the newer version of whatever toolchain you're using for design, and you might have to go and remap all your pads for pins in and out of the device but I'd expect you could just take the bulk of the VHDL or Verilog implementing the CPU and any emulated peripherals on-FPGA and basically copy and paste that right in, no? I could see some minor tweaks being required, but certainly nothing on the order of doing the original design. Best, Sean On Tue, Jul 14, 2015 at 1:17 PM, Chuck Guzis <cclist at sydex.com> wrote:

On 07/14/2015 11:14 AM, Alan Hightower wrote: You might start with a CDC STAR-100 and then graduate to the i7. Does a STAR-100 emulator (software, I'm not even going to broach the subject of hardware) even exist? --Chuck

On 07/14/2015 04:49 PM, Jay Jaeger wrote: There are plenty of machines that are impossible to find. And many that are gone that are quite novel. That IBM sold so many is something in their favor, but how about a working Saxpy box--which is quite a bit more recent than your 1410? Or the STAR-65, 1B or even -100. The only 65 was moved from Canada and scrapped. My department had the only two 1Bs and I saw those go under the sledgehammer and bolt cutters. I don't think that there are STAR-100s of any stripe (plain, -A, -B or -C) left--they were just too big. Are there any BSPs or ASC's kicking around? There are tons of lost non-IBM peripherals. But we do have documentation on many of these things, so at least we know "how" they worked. And I submit that in the long run, that's what matters. There's very little relevant to the state of the art today that really matters. (Boy, am I going to get flamed on that) Or dedicated simulators (non-SIMH). Often, all you have is the system documentation that talks about the instruction set and a few binary files. Reverse-engineering can be fun and valuable. Maybe, but I'd rather read the design documents than a pile of HDL of any stripe. But there were LOTS of those. Try something non-IBM and very obscure. A PDP-8 is a simple CPU, probably popular because of the lights and switches. I see evidence that these were eye candy--the DECStations are practically the same thing, but apparently not nearly as desirable. Seymour Cray should have used kinetic sculptures on his machines as part of eye candy, I guess. Or maybe more chrome... --Chuck

I think a lot of things drive the popularity of the PDP-8 from nostalgia to historicity to perhaps the relative simplicity of the CPU to understand as a design example in computer architecture ... IMO the machine is just a bit too limited to be much fun to program in assembly ... although maybe some are attracted to the "challenge" :O But certainly a PDP-8 or PDP-11 for that matter would have been much more common in the field; much more possible for someone to get their hands on in some kind of nominally working condition; much more affordable; easier to digest than a large mainframe or supercomputer. It's a shame more examples of these machines haven't been preserved but in many cases, there weren't many examples produced in the first place ... as well, I think a lot of the mainframe vendors took a "scorched earth" policy and tried to destroy as much of the older equipment as possible ... to keep it off the gray market. Many examples of blinkenlights eye candy throughout computer history but as far as supers go, I think the CM-5 ranks pretty close to the top for me :O Best, Sean On Tue, Jul 14, 2015 at 9:31 PM, Chuck Guzis <cclist at sydex.com> wrote:

On 07/14/2015 06:55 PM, Jay Jaeger wrote: Not by a long shot, it was followed by the 7000-series machines, namely the 7070 and 7080 (I have a soft spot for the 1620 myself) and ultimately variable length BCD was included in the S/360 and later series. Having programmed 1401s, I'll grant that the architecture was pretty different from what we're used to today, but typical for a small machine of the time. --Chuck

On 07/14/2015 09:16 PM, Jay Jaeger wrote: Well, how about a bit-addressable, variable field length machine that had not only your basic set of floating point operations, but also variable-length binary, binary modulo-256 and packed BCD to a length of 65535 bytes (131K BCD digits)? Circa 1969-1971: http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/cyber_200/602560… When you've got a few minutes to spare, try writing the VHDL for it. This was a Jim Thornton design, later taken over by Neil Lincoln. Later versions of the machine had drastically reduced instruction sets from the original, culminating finally in the liquid-nitrogen cooled ETA-10. But really, variable-word length machines, while they made efficient use of storage, were pretty much limited to a character-serial memory-to-memory 2-address organization. Quaint and perhaps interesting, but doomed from a performance standpoint. --Chuck

On 07/15/2015 10:48 AM, Jay Jaeger wrote: Sure, but that doesn't mean that they didn't exist. As a matter of fact, the machine I cited was *bit*-addressable. That doesn't imply that any datum was absolved of some sort of alignment. But yes, you could have bit fields overlapping word boundaries--let's see your 1410 do that... I really don't see much of a fundamental distinction between the 1401, 1410, 7080 or 1620 or any other variable word-length machine of the time. One really have to ask oneself "why variable word-length?" when it costs so much in terms of performance. I believe that it's mostly because memory was very expensive and it was viewed as a way of coping with that issue. FWIW, Dijkstra disliked the 1620 immensely. I don't recall his opinion of the 1401. --Chuck

Catalog of programs revealed the emulator you referred to: 1620-13.0.016 (also 160-13.0.018) 141 Data Processing System - An educational Computer for Instruction in Basic Programming. http://www.bitsavers.org/pdf/ibm/1620/GC20-1603-10_1620_Catalog_of_Programs… JRJ On 7/15/2015 1:17 PM, Fred Cisin wrote:

On 07/15/2015 11:29 AM, Jay Jaeger wrote: You mean, like the iA432?

On 07/15/2015 01:30 PM, ben wrote: Well, even in the late 70s, 64KB was still a goodly chunk of memory in the microprocessor world. Which reminds me... To bore you with another STAR tale--the machine had two page sizes--the "small" page, which was 512K 64-bit words and the "large page", which was 64K words. What some smart-alec discovered was that in a 512Kw system, it was possible (easily) to write an instruction that could never get started. You could have up to 6 addresses in a vector instruction (3 operands+3 control vectors). Storage was managed in 512 bit "super words". Start your large-page job, put two of the operands near the end of a page and bingo--you get 8 page references just to get the instruction started. Of course, the solution was to sell the customer more memory... --Chuck

That would certainly be closer than any of the other examples that have been thrown in the discussion. But it, of course, is much newer than the 1400 series. IIRC, the discussion started when someone suggested that there were quite a few machines that were similar to the 1400 series in terms of variable length. Again, while that was true from the perspective of variable length data fields, it wasn't from the perspective of variable length instructions. On 7/15/2015 2:42 PM, Chuck Guzis wrote:

On 7/15/2015 4:45 PM, Chuck Guzis wrote: Yes, it did kind of figure. ;) Or at least to be hoped. ;) Certainly it was a dead end. I suspect that the real 1401 (and its compatible follow-ons) lasted as long as it did mostly because small customers could afford the rent. There weren't enough 7090 customers to account for anywhere near the 1401 sales. Certainly a lot of 7090/7094 series installations did do that - the native printers, readers and punches for the 7090/7094 machines were simply *awful*. I've been amazed what people have worked into FPGAs. You just never know. As Gene Amdahl proved, with the right technology you didn't need all that water (or worse) running around in pipes in your computer room. :P Loved those MG sets. Our Amdahl's at WisDOT had them, and one could hear the 400 Hz in the computer room. In the basement of the U. Wisconsin CS building, I set up a 1410 that had been donated by Oscar Mayer Co. - twice - and Paul Pierce, I and another friend set up a 7094 II that had been at White Sands Missle Range (WSMR). The 7094 II took a hiatus when one of the bearings on the motor decided it had fallen in love with the shaft, and became "one" with it, resulting in the bearing's death, praying mantis style. ;) I came down to the CS building basement one Sunday evening to find quite a lot of smoke. With the "project" having essentially no budget, it was a while before the UW machine shop got around to taking the bearing off, and a new bearing found and placed on the shaft. After that, since we had absolutely NO I/O devices whatsoever (aside from the 1410 console), Paul adapted PUFFT (Purdue University Fast FORTRAN Translator) to do RS-232 bit serial I/O through a sense switch, and I wrote a spooling program that ran on a Datacraft 6024 located in the same room to do the card reading and printing. I suppose somewhere inside of it the DC 6024 was humiliated - I expect that it was much faster than the 7094 II. ;) http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/datacraft/ (Now there is another candidate for an FPGA. Just make sure you have the fix in so that DMA doesn't stop during a Divide Immediate instruction. ;) ). No software that I have seen for that one though. Liquid nitrogen would be the "or worse" part. ;) Worth/beauty/... are very much in the eye of the beholder. I suggest that anyone resurrecting anything like this as an FPGA or an emulator or a simulator is worth it for any number of reasons, even if it never sees the light of day. I applaud all of those efforts. The first one I became aware of was a PDP-10 FPGA implementation some years ago. Now there are many more. A (presumably partial) catalog exists (with quite a few broken links) at http://merlintec.com/swiki/hardware/31.html Indeed. That machine is also on my list, but I haven't seen logic diagrams for it. There is at least two emulators out their capable of running the MCP and ALGOL that I am aware of, and another that runs in Javascript of all things. The latter is available at https://github.com/pkimpel/retro-b5500 (These pages also refer to the first one I had seen, done in in C++, by Sid McHarg. I have a copy, which probably isn't the most recent. I am not sure if he released it widely, or not). Software is also available: http://www.piercefuller.com/library/magtape7.html (the "source"). Some of that is also available at: http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html

Saul is indeed cited in the ACM article, http://dl.acm.org/citation.cfm?id=365671 I know that Purdue had some folks that did their own maintenance, and sure, by the late 1960's one could certain pick them up cheap - the gold scrappers were not quite the issue they became later. I know this because, besides the 7094 II that I did some work on (including replacing a germanium transistor with a modern silicon one at one point), the U. Wisconsin Chemistry department had a 7090 (oil core) on the 9th floor. Some folks from Purdue came up at one point and helped fix a problem with it. Around 1975 the IBM 1410 and the IBM 7094 II we played with at UW were sold to a company in Ohio - or at least pieces were. Paul Pierce and I went back to that same company in 1998 and recovered some of the IBM 1410 and IBM 709x tapes that he lists on his site - Paul has an amazing setup where he reads the tapes *analog* using a 7 track drive, and then post-processes the results to de-skew and recover the data. JRJ On 7/15/2015 7:12 PM, Chuck Guzis wrote:

On 07/16/2015 01:12 AM, Dave G4UGM wrote: Nice article. Many folks fail to appreciate the link between medicine and the history of computing. In particular, my first encounter with database technology came from a study of MEDLARS, the system still in existence today at the NIH. What I found particularly fascinating was the ability to automatically organize text documents and then subject them to English-language querying and getting results. (All done on tape, naturally) I'm reminded of this when I look over at my bookshelf and see Gerry Salton's magnum opus "Automatic Information Organization and Retrieval" sitting on a shelf. MEDLARS figures prominently in this book. Back then, it was pretty hot stuff. Of course, now we have Google... --Chuck

Correct: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD37.html I don?t know what he thought of the 1401. He did reject the 7040 when it was proposed to the university as its main computer. That analysis is in http://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs/NN041.html (in Dutch). When comparing with the machine they ended up with (Electrologica EL-X8) I have to concur with his judgment, not that the EL-X8 is flawless, but in key spots it gets things right that IBM gets wrong. paul

Oops, replace 1460 with 1420. 1460 did exist in reasonable numbers. -- Will

It is very poor design, and not something that I would do, but it certainly was done in production machines. With care you can determine the width of the glitch, and if it's small enough, ignore it. But there is a related problem with FPGAs. You learn in introductory digital electronic courses that there are 2 types of counter. The Asynchronous, or ripple, counter where each flip-flop toggles the next when it goes quite large glitches. Then there is the synchronous counter where all flip-flops are clocked together. Now to a good approximation (all the flip-flops have the same delay from clock to output), they do all change together. So if you now combine the outputs (say you AND some of the Q and Q/ outputs to decode a particular state) the glitches will be small. That's what is taught. That is what works with TTL, ECL, etc. Now try it in an FPGA (at least the Xilinx ones I've used). You will find glitches all over the place. The reason is that the 'wires' linking the outputs of the flip-flops to the gates are not wires at all. They are paths on the chip through logic multiplexers, buffers, etc that are set when the chip is configured. And they introduce delays. Delays that are enough to cause glitches that are wide enough to trigger other flip-flops. My experience of FPGAs is that if you design a circuit for an FPGA it will work. If you take an existing design feed it into a schematic capture program and compile it for an FPGA then it won't. -tony paul

You are, of course, absolutely correct... However, such designs are very few and far between. I will guess that if you took just about any of the discrete transistor or TTL-baased minis or desktops and fed the design straight into an FPGA compiler then it will not work. -tony

I would be very surprised if you took the schematics for an HP9830, PDP8/e, PDP11/45, Philip P850, PERQ etc put them into a schematic capture program and had a completely working FPGA version of the machine. If you mean 6 different clock sources (i.e. clocks delayed from each other, etc) then that is not typical of a 1970s minicomputer in my experience. -tony

IBM used this method as well on many of their machines. -- Will

On 7/14/2015 7:36 PM, Jon Elson wrote: I guessing ( no schematic handy) that they made the 360 register file easy to decode and build with latches. I have seen some 11/?? schematics on bitsavers that the alu uses AOI gates and includes a latch term. Ben.

The 12-bit computer that I "translated" originally had *independent* 1 micro-second clocks in each of four racks. The processor derived a 3 micro-second clock from that, but also a second clock that was out of phase with the CPU master clock, used to sync. signals coming in from the other racks (which had 10 foot cables in between). On 7/14/2015 7:04 PM, Eric Smith wrote:

On 7/14/2015 2:56 PM, tony duell wrote: It will work if you modify it by applying some simple rules, such as I have described, because I have done so. Of course, it is possible that I have more rules to uncover. ;)

That is not 'taking an existing design and feeding it into a schematic capture program'. It's modifying the design (adding the D-types to synchronise signals and removed glitches). I do not dispute you can do that. -tony

On 7/14/2015 11:27 AM, Paul Koning wrote: The approach I have used is a compromise between the two - it isolates the problems building flip flops out of gates, while still preserving the original design. That said, when I come across a flip flop on an SMS card, I will probably build it its own behavioral model. I am creating one to be sythesizable. That is just it - the combinatorial inputs were used FOR the clock on some gates. Right - not a good idea even back in 1972, though it depends a little on what the rejection time / intertial delay of the inputs are, but yes - certainly a design that would be prone to failure (remember that this was a bunch of students trying to put together a working 12 bit computer in about a month - ours included a cross assembler and cross-interpreter, so we had real software running our machine for its demo - including hangman played with the TTY keyboard and an oscilloscope hooked to a pair of D/A converters for a display).

On 7/13/2015 10:02 AM, Paul Koning wrote: The big assumption here, is the software will NOT change the logic model and the details are vender specific. Altera software is BAD for doing this. Ben.

On 7/14/2015 10:29 AM, Paul Koning wrote: It is more the case, of what you don't know can't hurt you. This is a back end of the compiler problem. With FPGA logic changing every 6 months, you have less standard logic blocks. With AHDL I know what is generated, if I can't figure out verlog or VHDL's logic I refuse to write in it. Why do we not have a good logic language (RTL?) for hardware? ( I consider them to be COBOL of the digital world). I have FPGA board here, so I use Crash and burn testing.

Seconded. Excellent book. I picked up a copy from a used book seller maybe a year ago and to my surprise, my copy is stamped "XEROX PARC RESEARCH LIBRARY" :O Double cool :O Best, Sean On Mon, Jul 13, 2015 at 9:35 AM, Toby Thain <toby at telegraphics.com.au> wrote:

The PDP-11/45 had split I/D capabilities. It was not all that much later than the 11/20 (2 years according to Wikipedia anyway). On 7/13/2015 2:16 PM, Rich Alderson wrote:

On 2015-07-13 8:52 PM, Johnny Billquist wrote: I think we ALL do, for any reason! ;-)) --Toby

On 2015-07-14 16:09, Paul Koning wrote: Yeah. Segment is something I usually associate with the solution done in the 8086 family, where you essentially have a segment register which gives the base, and then you work from there. Essentially all memory is one chunk. The 8086 have both an instruction and a data segment, which just means that some instructions refer to data, and that uses the data segment register, while instructions (obviously) are addressed through the instruction segment register. I never worked with the 8086, but don't it actually also have a third segment register? Not that I can remember what it was used for... Oh, and all references are relative to the segment register (should be obvious, but I figured I should point it out.) Yes, the fact that pages on a PDP-11 do not have to be the full 8K is a bit special. Or, was. Machines nowadays are actually more reminding me of the PDP-11 than other contemporary systems. Today we are once more at really large page sizes, and actually variable length pages. I don't remember if page physical address needs to be on a multiple of the page size on todays machines, but since page sizes can vary I don't think so. So very much like the PDP-11... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2015-07-15 01:02, Sean Conner wrote: Thanks. That was way more than I actually ever wanted to know. :-) (Ok, I did ask...) It should be obvious to anyone that this is very different from the MMU of a PDP-11... (Or at least I hope it is obvious - otherwise people are free to write some OS for each system and then come back with a report...) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 7/14/15 9:22 PM, Fred Cisin wrote: It's actually described in the Intel SDM (Software Developer's Manual). ;-) The start of the instruction is actually the segment override (one of the things that makes decoding x86 instructions hard). Since the REP XXX instructions are interruptible, the IP does not move to the next instruction until after it completes (and the state of the REP XXX instruction is kept in various registers that are updated on each iteration). So, when an interrupt occurs, the execution is stopped (after the current iteration completes) and is restarted when the interrupt returns. TTFN - Guy

On 7/14/15 9:53 PM, Fred Cisin wrote: Haven't. The SDM covers Pentium forward (and even then it attempts to document the differences between the different models). I think anything prior to that has been relegated to "incompatible" prior products if their behavior is different from what is described. The 8086/8088 were done in a similar vein to the 8080 and 8008. Not too much attention was paid to forward looking architectural decisions. The 80386 and follow on CPUs *tried* to look forward a bit but it wasn't really serious until the Pentium when features such as the TSC and APIC were introduced. TTFN - Guy

On 7/14/2015 10:22 PM, Fred Cisin wrote: Halt and catch fire ... No that's 6800's.

On 7/13/15 9:54 PM, Paul Anderson wrote: this is the source for the wikipedia entry on the PDP-3 http://www.decconnection.org/announcements.htm **************** February 14, 2007 ******************************* *Anyone seen a PDP-3 lately?* I'm trying to discover what became of the PDP-3. It was originally built at the Scientific Engineering Institute (SEI) in Waltham, MA, and later transferred to someone at MIT. Gordon Bell wrote in 1978 that it was running at an unspecified location in Oregon, but yesterday he told me that he doesn't remember where that was. I am working on a book on the history of stealth and the Lockheed Blackbird. The PDP-3 was used at SEI to process radar data for the A-12 Blackbird. Thanks very much, Paul Suhler (949) 856-1450 or Paul.Suhler at quantum.com

Thanks Al On Tue, Jul 14, 2015 at 12:00 AM, Al Kossow <aek at bitsavers.org> wrote: