emulated 24K core unit for the PDP-12

[Peter Peterson]

Hi all,

We have been kicking around the idea of building an emulated 24Kword core unit for our PDP-12, since Warren was here. Our '12 has 8K (thanks to a core donation as one of ours had been "liberated" by an unknown person in the past). It therefore has, as I understand it, the expansion hardware to add up to 32K of core memory, which would be linked via an interface on our backplane that should already be wired up.

Julian here at UMD has been interested in taking on the project. The idea is that we would build some hardware that would use the original interface and "speak" the original signals, but would be supported by modern hardware (perhaps an FPGA, arduino, Raspberry Pi, etc.). He could likely do this supported by an undergraduate research grant from UMN.

However, before we embarked on the proposal for this (due 7/1), we thought we would ask the group if they a) knew of such a thing already existing (in which case we would probably build one and give Julian a different project), b) knew of any showstopping reasons why such a device would be impractical / expensive / dangerous, etc. or c) had any advice or thoughts about the best way to proceed on a project like this.

In other news, Julian and Matt got the carriage return working on the teletype! The linefeed still is not quite working right, but the whole thing needs lubrication and adjustment.

Thanks,

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

[Julian Nowaczek]

Hello everyone,

Just a quick addition, I've located a manual and schematics for Fabri-Tek Inc’s 24k expansion on Bitsavers:

http://www.bitsavers.org/pdf/fabritek/400-0226-00_24kCore_jan74.pdf

My basic idea at the moment is to use the block RAM of an FPGA to store the data, and handle all the multiplexing in the FPGA fabric. The main flaws I see with this plan are the expense of an FPGA, complexity of implementing HDL, and the “boot” time of the FPGA (I suppose it would be possible to just leave it on all the time). As Peter mentioned other routes could include just using a microcontroller, I haven’t examined the required timings to see if that’s reasonable yet.

Any advice (including other project ideas!) would be greatly appreciated!

Julian Nowaczek

[Michael Thompson]

There are some FPGAs that don't need to be loaded so they are functional as soon as they are powered on. I believe that the ones from Microsemi work like that. I used one of their SmartFusion ARM3/FPGA SOCs to emulate PDP-8 peripherals.

If the MM8-I memory expansion interface is simple enough, you may be able to just use some discrete ICs to implement the interface instead of using an FPGA. 

 

You could use a pair of 32kx8 low power static RAMs and a coin cell battery to keep the data alive when it is powered off.

That is what I have in my PDP-8/e. http://so-much-stuff.com/pdp8/32KOmnibus/32KOmnibus-.php

--
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

Michael Thompson

[CLASystems]

On Tue, Jun 18, 2019 at 4:16 PM Michael Thompson <michael.9...@gmail.com> wrote:

There are some FPGAs that don't need to be loaded so they are functional as soon as they are powered on. I believe that the ones from Microsemi work like that. I used one of their SmartFusion ARM3/FPGA SOCs to emulate PDP-8 peripherals.

If the MM8-I memory expansion interface is simple enough, you may be able to just use some discrete ICs to implement the interface instead of using an FPGA. 

 

You could use a pair of 32kx8 low power static RAMs and a coin cell battery to keep the data alive when it is powered off.

That is what I have in my PDP-8/e. http://so-much-stuff.com/pdp8/32KOmnibus/32KOmnibus-.php]]

You do not want to conflict with the 8K of core memory, so that would require a little deselection logic.

cjl 

--

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

[Maury Pepper]

I saw the Tweet that Julian got a grant to work on the 32K expansion. Congrats! This will be an interesting project, and I hope you keep this group in the loop as things progress.

In 1968 I developed a similar interface so that the LINC could address up to 32K. It used the same scheme as the LINC-8 and PDP-12 using upper and lower memory bank registers. It used from one to eight, 4K Fabri-Tek memory units. It was nicknamed the SuperLINC. As far as I know there were only two built -- one at Washington U. Computer Systems Lab, and one at Wake Forest U. Within a year, the Spear MicroLINC provided the same capability plus it was 8x faster and had buffered tape and TTY interfaces so the SuperLINC was not very special for very long.

One point that might help simplify your interface: we determined that it was best to by-pass the original internal core. It was much simpler to send a 15-bit address to the interface and not have to add logic to determine which way the address and data flow would go.

    -maury-

[Julian Nowaczek]

Thanks for your encouragement! My understanding of the project and its scope has improved a bit since June, so here’s a quick update:

The project scope was expanded slightly to include an examination of different methods for emulating the core memory rather than proceeding with one technology from the get go. Parameters of interest at the moment include material cost, design complexity, and flexibility of adding new functionality to the machine. I’m particularly interested in adding new functionality, but ultimately the goal is to build something that lets us run ADVENT, fancy features come second.

Maury’s comment about bypassing the internal 8K in the SuperLINC is especially interesting since having complete control over all the memory would allow for a wider variety of new functionality like an external debugger, memory state recording, alternative to serial for loading BIN/RIM programs, etc. Some of these I’m sure could be done with access to only 24K, like Vince Slyngstad’s bootstrap options on his OmniBus memory expansion. As far as I can tell our PDP-12 has the MC12 memory expansion control unit installed and so we have the option of using our 24K along side the internal 8K without designing all that logic, but I'll look into the possibility of bypassing the existing memory.

Other things I’ve been working on this summer include fixing (mostly) a bug in minicom that corrupted the “Send File” menu when displaying very long file names (like PDP-12 diagnostic tape images) and a sort-of-working PDP-12 cross-assembler. I hope to finish those up before classes start on Monday :)

Thanks so much for the work you all and everyone in the retro computing community have done to make a project like this possible!

Julian

[CLASystems]

This thread is moving too quickly for properly interspersed comments from my point of view, so I will respond to the top layer, and everyone else can sort it out.  What happens sometimes haste makes waste.

I have the benefit of being the best person here to answer certain aspects of this because I know what is needed, as opposed to what can be played with, which from my point of view is more of a solution seeking a problem.

A few salient points.

Reading the DEC manuals if you are not already a seasoned PDP-8 expert gives you the false impression there is a need for the RIM and BIN loader and related ate the top of the food chain.  Sorry, folks, this is not a machine merely a 4K CPU and an ASR-33 Teletype, which is the focus of all of that primitive stuff.  Many have cursed that wretched environment which is a TOTAL waste of time OTHER THAN in the case of large failure of the machine rendering it so broken that we HOPE that the BIN loader and the loading process for a relatively short program and the actual program logic do work while something contrivedly not a requirement of the moment can be not depended upon and hopefully diagnosed.

Of course there is the ongoing need to run diagnostic programs, but the FALLACY here is this:

Routine maintenance means the assumption that hopefully everything works.  As such, since this is a PDP-12 with built-in storage devices to run an operating system, the diagnostics are run from one of them and NOT paper-tape or anything trying to make it easier.  The right thing is to simply NOT DO SO and instead create a suite of easily run programs that are loaded much faster than any other way.

This is one of those cases where hardware people are too myopic and only someone like me with a "big picture" experience can give proper guidance.  There are plenty of nice ways to do this.  Thus, learn the software and do not play with hardware for that realm.

Now if the machine is really broken, you then have to resort to hand-toggling in very short programs for 'scope looping, etc. so the front panel is where all the action is [and hanging probes on the backplane and sleuthing from the prints].  That's pure hardware, no software to "help out" at all.

Thus, I would recommend moving in an entirely different direction and implement stuff really needed, etc.

There is an issue regarding what a memory expander should do here.  Nothing presented by others is in fact relevant, borrowing from other machines does't cut it.

The machine MUST function with any added hardware REMOVED.  It is that critical.  If you want to, figure out how to DISABLE the built in double 4K memories; this is best implemented by pulling key modules and having them on hand, preferably in an anti-static bag hanging inside of the machine!  That way, the replacement memory can be 32K trivially.  OR use the Fabritekapproach which was strictly an add-on, etc.  Either is fine, but the Fabritek approach obviates the need to pull modules, etc.

The Fabritek approach has a very important point:  PDP-8 diagnostics have to be resident in memory.  That means if the memory is failing, you can't debug it with the software until you can depend enough on where the program is stored.  By using the standard memory, you are much more likely to debug your design with the diagnostics which can defocus on the core fields and concentrate on the add-on ones.  This is standard in the programs because they knew all of this back then.  Don't disrespect your elders on this one.[Note:  They are my elders as well, just a whole lot less "elder" than most of you :-) ]

A very real scenario is that the 8K is perfectly fine to work the prevailing software to load the diagnostics RELIABLY to make it easy to then test the unreliable new work-in-progress that is being de-kinked and not yet trustworthy, etc.  This is predictable!

As to any hint of some ill-conceived notion of software helpout, this is the PDP-12 which already has built in FETCH/EXEC hardware, the best PDP-8 model of all on that point [I personally have a third-party add-in for the PDP-8/E that does that, but they are rare].  Anything that distracts from a person seriously using that fine front console is not useful despite the fact it sounds good.  Again, give in to the voice of experience.  Serving two masters at once means disobedience to both. [One is the stock PDP-12 console, the other is whatever might be foolishly conjured up.]

Other projects are easily suggested.  So here is some food for thought.

This project was suggested by Warren himself.  It has a LOT of applications for the LINC, the LINC-8, the PDP-12 and any "lab'-oriented machine:

Essentially a form of "scan converter" so that the input is the analog output from the machine triggered by the scope intensify circuit found in any of these situations.  The three machines have a built-in oscilloscope and on the PDP-12 the signals come out neatly from the large extension connector on the front [small panelette side].

This way, you can generate appropriate input to either the VGA analog or the digital input of a modern LCD display, which can be arbitrarily large these days and can help to demo the machine to an appropriate audience [read GRANT COORDINATOR HERE] as well as any other "visiting dignitaries" aka game players.

The output is predictable in that there are just so many output possibilities, so it needs to be a real-time x, y pair updater and creator of video output.  This suggests two-port memory or equivalent.  I leave it to those doing the work to fill in what Warren had in mind, etc.  Mr. John Wilson also has some input into the best hardware to use if you need someone very well versed in current technology [and Mike Thompson and I are all close friends etc.  This is a small world that overlaps a lot, etc.]

Because of the near worthlessness of paper-tape, instead create a baud-generator quick-switch project to hack into the system console (03/04) so a much faster terminal can be used.  Also, it can be justified to need several rates for some reasons I can elaborate on, but it is not obvious, etc. [A separate email subject if anyone is interested. but the point is the notion of one size fits all is patently false for this machine.]

A rational approach to a student project is that it adds real value to the machine beyond merely the short-term goal of just satisfying a student project.  I have the dubious misfortune over the years where I have heard of people wasting their time reinventing wheels or overly elaborate long-way around approaches that can simply be avoided by asking me, and I am glad to help.

These days, other than the notion of "having a real life" all of my "projects" [Note: My wife is NOT a project!] are all related to one of the following subjects:

1) Continuing development of what is today called P?S/8.  Some documentation I am working on will explain the somewhat quirky [to say the least] derivation.  The short version is we made it up and it is a joke only to a very small number of people, but it does have a "formal" derivation which is in part thumbing our collective noses at some less-than-stellar notions invented back in the day regarding PDP-8 marketing techniques of dubious worth both in absolute terms as well as economic ones.  That said, an unfortunate aspect of discussing much of this subject forces software people to have to parrot their silly names to explain what we are talking about.

To illustrate this point aimed at a PG audience, the original name of what eventually became known as OS/8 [and later still an out of control "family' of names] was originally expected to be implemented as a series of actual software projects, at least two; the first was ONLY meant to be a short-term demo].  The two accurate original names are as follows.

a) The implemented one meant to be a demo [but that is not what happened]: the First Upward Compatible Keyboard Editor and Monitor.

Note: Surviving OS/8 source code mentions this reduced to "the <bleep> monitor". 

 

b) The planned yet never implemented [due to management's arbitrary incredibly stupid code freeze] second one, the Second Upward Compatible Keyboard Editor and Monitor.

The real original name of the real original system [created before the implementors were interfered with my any form of manager when it was just an optional college group project] was the R-L Monitor System [which was also later known as Mass Storage for the PDP-8 or for short MS/8/  This also involves a level of humor.

Thus. the entire system name aspect of these operating systems is steeped in a "tradition" of pranks and other humor, yet the products are quite serious [at least in theory].

Currently, all P?S/8 SOFTWARE projects are on a SHORT hold.  See below.

b) Producing professional quality documentation for a) and c) below.  This is primarily word-processed documents and some techniques beyond normal word-processing to provide covers and other accouterments in the final document.  As they become available, they will be distributed on my website at:

https://www.ibiblio.org/pub/academic/computer-science/history/pdp-8

I generally do not release pre-final copies, but those interested and will not distribute them further I can provide upon request.  Additionally, I welcome any form of critique of structure, language, and of course typos that a spell-checker cannot find. [Note: I find myself doing a lot of over-riding on those things!] So, any volunteers please step up.  This is relevant software for your PDP-12 !

While this is not actually part of P?S/8, it was prepared USING P?S/8 and in particular, the P?S/8 PAL assembler which is the "global standard" for all PDP-8 and PDP-12 assemblers, essentially being  proper superset of PAL8 and also the DIAL-MS assembler with regard to a FULL implementation of LINC mode and PMODE completely.  Most notably, unlike DIAL, P?S/8 PAL supports literals [PAL8 also does, but DIAL's assembler does not!]

You don't even need a 12-bit machine to run P?S/8 as it runs from SIMH.

Note: A near-final/near release manual exists currently for the P?S/8 PAL assembler. thus re-read the above regarding all I mentioned regarding my documentation projects.

c) The PEPS for Windows project.

As distributed by GITHUB, etc.  The SIMH for PDP-8 binary is a fairly good machine and peripherals emulator.  It has a lot of small annoying "holes" in it that thwart some academically-oriented projects I have already spent some effort on.  Simply put, I depend on a DOCUMENTED feature that unfortunately no one ever completed,. and just cheap excuses such as "it's easily done" when in fact this is empty rhetoric that only serves to explain an acceptable end-result that doesn't actually exist.  I can provide further input as to specifics, but this requires someone expert at C++ matters. and certainly not me.  I do know that the person who started the project left; I have personally e-mailed him and he is disgusted with them because it is too sloppy.  But anyone skilled  enough can contribute.

Just a small amount of documentation on this sore point.

When emulating the paper-tape software [Rim and BIN loader world] there is a PARTIALLY successful implementation of a memory dump command.  But it cannot process an output file nor memory specifications.  An acceptable result would be something like:

dump foo.bin 0000-7777

The .bin format is well-defined and used in various SIMH packages including P?S/8 and OS/8.  It is also useful to transfer PDP-12 diagnostics to this environment to help develop good maintenance schemes, etc.

Essentially, they never did the core-locations parsing part and all I do know is that leaving out the output file gives an appropriate lesser error while using it correctly gets you another error, which I have been told is because no one ever wrote the rest for the PDP-8 version!

Finishing this would help many people.

This only affects the PEPS project for the purpose of teaching beginner students about the low-level fundamentals without having to tie up real machine resources.

While the SIMH project is for either various PC-based unix and the like OR for PCs with Windows, the PEPS project is ONLY for Windows because the unix version produces a toy compared to what I have already done.  Unix bigots need not apply, but be prepared to always be stuck with a poor pale substitute compared to what I have done.

Note; I have actually asked unix experts and they agree what I accomplish does not work under prevailing unix utilities such as wine, that PRESUME that what little they did is sufficient - in point of fact it is not even close!

PEPS stands for P?S Enhanced PDP-8 Simulator and is only for Windows, although I expect to be able to get it to work perhaps in REACTOS.  It takes advantage of the work of others in the public domain that are unique to Windows, etc.

As described above. here is a PDF file created using PEPS and a small number of other PD tools.  The file is well-known to many, but not quite available as in this particular form.

https://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/FOCL69%20Files/FOCAL69%20Initial%20Dialogue.pdf 

The PEPS project is extremely functional, and I have been using it as it has evolved as far back as 2015 in earnest [to work on various other 12-bit projects for both P?S/8 and OS/8.]

At this point, perhaps a few more functional frills, but the largest is making it more palatable to Windows 10, which is a PITA.  It is best used in either Windows XP or Windows 7, tolerable apparently in Windows 8 [I haven't quite tested it yet, but what was done for Windows 7 was written by others, I merely derive from their work a form consistent with the sensibilities of PEPS. but there will be at some point some formal testing.  It also works on Windows Vista without any of these issues, same as in XP.  However, some 64-bit issues were first discovered in Vista 64-bit now since corrected.

Unfortunately for me, documenting this takes some more effort, as there are now "serving suggestion" issues and some likely to want to know how to make their own pet changes.  The document does show some nice graphics of "serving suggestions" and sections will be added on how to make most of what users might want to change, etc.

Windows 7 requires one of at least two alternatives They  that. while they are possible on all past XP, few would want to unless forced to; Windows 10 does the forcing!  Both need testing and represent two poor substitutes, although one is good for committed users, etc.

But for reasons stated here [and other things] "final" documentation of PEPS is elusive, but it is close to what most savvy people need.

d) My Kermit-12 for the OS/8 family will be getting an upgrade to finish off some lingering weak points, Warren either did or nearly did cross the same issues, best served in the next release.  This is a widely used set of utilities very well known in the 12-bit world, etc.

e) A whole host of other programs including in support of some games and utilities for all operating systems mentioned.  P?S/8 even supports file conversion between P?S/8 and OS/8 and also P?S/8 and DIAL.  Thus, even makes it possible to go OS/8 from to DIAL as a two-step process.

I have a back-burner project of rescuing source files that were the victim of bad hardware transfer.  Until I finish there will not be useful final versions of some programs, etc.

f) Various other things that assume there is truth to the rumor that I actually have what others call "spare time' but this may only be a vicious rumor!

cjl

 

Virus-free. www.avast.com

--

To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.