Re: [Simh] The Missing PDP-8s
On 13/08/19 18:18, Bob Supnik wrote: ith Rich Cornwell's recent work, it's clear that the DECtape controllers should have been abstracted to a library ten years ago, but doing so would be a major PITA, now that there are six (at least) distinct implementations (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10). fully agree on PITA. I tried to patch the DECTAPE emulation into being actually writeable on DECsys 4 and 7 aaand.. failed. on the "missing PDP", summing all up, I guess that is basically suggesting to extend pdp8 into a pdp12b, that is, encompassing all 12 bit PDP (plus the LINC variants) both (rationalising the DECTAPE emulation and adding the other 12b PDPs) are definitively "long term" projects, and AFAICT SIMH 4.0 is still beta. my suggestion should be working on both those project for the next major 4.x SIMH release. Best regards from Italy, dott. Piergiorgio. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
Well, no. It's a PDP-8/A as initially released and documented in the late 1976 PDP-8/A manuals and schematics. That machine was limited to 32KW. So was the initial, 1976 version of the FPP8-A. The KT8-A was released in mid 1978. It expanded memory capability to 128KW and added a number of other interesting features. It wouldn't be that hard to add it. The 8/A was not the end of the line, of course. The Intersil 6100 and Harris 6120 took the PDP8 into VLSI and added additional features. I'm not sure where I'd draw the line between static and dynamic compilation of models. Different simulators have taken different approaches: - The PDP11 allows the model to be set dynamically, except for the UC15. - The VAX requires the model to be compiled statically (every VAX model is a different simulator). - The PDP10 requires the model to be compiled statically, but the type of memory management can be selected dynamically on the KS10. - The 18b PDPs require different models to be compiled statically, but the type of memory management can be selected dynamically on the PDP9 and PDP15. I don't think it's impossible to make a dynamic 'all-in-one' PDP8 CPU. You'd have to identify how the earlier machines handled 'unpredictable' results, e.g., RTL!RTR, but working examples of every PDP8 (not the PDP5, though) are still extant if questions need to be answered. IO is uglier. The PDP5 and classic PDP8 used peripherals similar to the PDP4 and PDP7, like the type 552 magtape and type 555 DECtape controllers. Starting with the 8/I, we see the "modern" form of storage controllers. However, the 8/I still uses the older type 645 line printer controller instead of the newer LP8E/LP8A. The serial drums from the classic 8 made it to the 8/I but were superseded by the DF32 and then the RF08. Real-time clock programming is very different from the old models to the new ones. Etc, etc, and so forth. On 8/13/2019 3:51 PM, Warren Young wrote: It's a mongrel. SIMH's FPP (floating point processor) peripheral emulates the version for the 8/a, but memory is limited to 32 kWords as in all models before the 8/a, which added a mode to allow 128 kWords of core or semiconductor RAM. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
> The reason there are two DECtape controllers in the current PDP-8 > simulator is that one is block-by-block (TC) and the other is line-by-line > (TD), where "line" is 3 bits! That means there is a device driver in > TD-aware PDP-8 software that has to assemble incoming data 3 bits at a time! > > The TD8E is dumb but not THAT dumb. It do reassemble 12 bit words for the processor to deal with. http://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/ Mxxx/M868/M868Hsch.pdf There are three four bit 8271 shift registers that handles it. Both for reading and writing. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
On Tue, Aug 13, 2019 at 10:18 AM Bob Supnik wrote: > As was pointed out, the existing PDP-8 CPU is basically a PDP-8/E or > -8/A. It's a mongrel. SIMH's FPP (floating point processor) peripheral emulates the version for the 8/a, but memory is limited to 32 kWords as in all models before the 8/a, which added a mode to allow 128 kWords of core or semiconductor RAM. The 32 kWord limit is hard-coded in pdp8_defs.h as MAXMEMSIZE. I'd expect at least that limit to be lifted if you're going to call the SIMH simulator a PDP-8/a simulator. I think it'd be a lot of work to give the current CPU emulator model-specific modes down to a level necessary to get full branch coverage in software that probes for model quirks and changes behavior accordingly. I'm personally aware of multiple pieces of commonly-available PDP-8 software that does this, and there was doubtless a lot more that I'm not aware of, because the economic lifetime of the PDP-8 was roughly 2 decades long! Closer to a quarter century, if you count the PDP-5. it's clear that the DECtape controllers should > have been abstracted to a library ten years ago, but doing so would be a > major PITA, now that there are six (at least) distinct implementations > (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10). I think it'd be more work than it's worth to make a single abstraction layer; I think you'd want at least two versions. The reason there are two DECtape controllers in the current PDP-8 simulator is that one is block-by-block (TC) and the other is line-by-line (TD), where "line" is 3 bits! That means there is a device driver in TD-aware PDP-8 software that has to assemble incoming data 3 bits at a time! We have a mode in the PiDP-8/I software that lets us build the OS/8 disk packs in a way that works with either driver. The OS/8 TD8K driver for the TD8E DECtape is so-named because it requires an 8 kWord PDP-8 because the code complexity in the driver requires that it be split over two "fields" (4 kWords) of core, which is unusual for an OS/8 device driver. We have this mode so you can use the PiDP-8/I software stack to build disk images for real hardware, where switching modes is much more consequential than simply changing a "C" to a "D" in a SIMH boot script. This feature of the PiDP-8/I software is scriptable, so that for any question OS/8's "BUILD" program can ask, you can script an answer to it to get a new custom OS/8 medium build: https://tangentsoft.com/pidp8i/doc/trunk/doc/os8-run.md ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
> On Aug 13, 2019, at 12:25 PM, Richard Cornwell wrote: > > Hi Bob, > > >> ... >> I looked at a PDP-12 implementation. It's not hard, but I really >> didn't want to do Yet Another DECtape Simulator for Linctape. With >> Rich Cornwell's recent work, it's clear that the DECtape controllers >> should have been abstracted to a library ten years ago, but doing so >> would be a major PITA, now that there are six (at least) distinct >> implementations (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10). > > I am more then willing to switch to a generic library. What would be > nice to see is something that just gave you the actual tape frames. > This would also allow you to format the tape. If you write it I will > gladly switch to it. Most of KA10 code is from your other simulators. That would be neat. The formatter program would be one good testcase. Another one, a rather tricky one, would be RT11 FILEX reading PDP-10 DECtapes. That one is strange because it doesn't used read-all as you would expect; instead it does a regular read and picks up the upper 2 bits from one of the CSRs as the words fly by. So for that to work you'd actually have to emulate the behavior of the word by word data transfer during DMA. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
Hi Bob, > As was pointed out, the existing PDP-8 CPU is basically a PDP-8/E or > -8/A. It doesn't have the model-specific capabilities of the current > PDP-11 CPU simulator. > > Making the PDP-8 "model specific" is a bit more difficult than just > putting in model tests at various points in the CPU. The peripherals, > and the peripheral instruction sets, evolved too. The PDP-8's DECtape > controller is quite different from the TC08; the magtape controller > is different as well. With the 8/E, the original IOP 1,2,4 scheme was > replaced with the OmniBus, allowing peripherals to decode as many as > 8 instructions per device code, instead of 3 or 4. > > As for the PDP-5... it probably has different major peripherals too. > So it's not just the PC = location 0 problem. > > I looked at a PDP-12 implementation. It's not hard, but I really > didn't want to do Yet Another DECtape Simulator for Linctape. With > Rich Cornwell's recent work, it's clear that the DECtape controllers > should have been abstracted to a library ten years ago, but doing so > would be a major PITA, now that there are six (at least) distinct > implementations (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10). I am more then willing to switch to a generic library. What would be nice to see is something that just gave you the actual tape frames. This would also allow you to format the tape. If you write it I will gladly switch to it. Most of KA10 code is from your other simulators. Rich -- == Richard Cornwell r...@sky-visions.com http://sky-visions.com LinkedIn: https://www.linkedin.com/in/richard-cornwell-991076107 == ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Missing PDP-8s
As was pointed out, the existing PDP-8 CPU is basically a PDP-8/E or -8/A. It doesn't have the model-specific capabilities of the current PDP-11 CPU simulator. Making the PDP-8 "model specific" is a bit more difficult than just putting in model tests at various points in the CPU. The peripherals, and the peripheral instruction sets, evolved too. The PDP-8's DECtape controller is quite different from the TC08; the magtape controller is different as well. With the 8/E, the original IOP 1,2,4 scheme was replaced with the OmniBus, allowing peripherals to decode as many as 8 instructions per device code, instead of 3 or 4. As for the PDP-5... it probably has different major peripherals too. So it's not just the PC = location 0 problem. I looked at a PDP-12 implementation. It's not hard, but I really didn't want to do Yet Another DECtape Simulator for Linctape. With Rich Cornwell's recent work, it's clear that the DECtape controllers should have been abstracted to a library ten years ago, but doing so would be a major PITA, now that there are six (at least) distinct implementations (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10). /Bob On 8/13/2019 5:19 AM, simh-requ...@trailing-edge.com wrote: Has any ever thought of writing simulators for the two missing systems, the PDP-5 and the PDP-12? ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
