PDP techniques?

prof_braino

Hi all

Anybody have experience with with PDP-11, etc? Specifically, writing applications in assembler code, and paging to tape. I don't want to do anything with the PDP or tape, per se, it just want to learn about the techniques folks used to be get by in that environment.

There have been many discussions of OS for the prop, these efforts seem to grow past the bounds of the stock prop hardware rather quickly. For this experiment, the first requirement is it applies to any stock prop.

The suggestion was, when considering an OS for the prop, look at what they did in for example a PDP environment.

To put this in context, we were talking about operating systems and code bloat slowing down every new processor that comes out; and how this affect is magnified on the prop. (Folks trained in the PC environment tend to add stuff till the processor chokes, or at least this is my tendency). But, the prop should have ample resources for many task, if we don't get crazy. So we want to get as close to the crazy line as possible without stepping over too many times. So we want to include as many of the most useful functions as possible, and leave off (for now) as many of the secondary functions as possible. So the question comes down to requirements, how to define useful "primary" functions and identify non-essential "secondary" functions.

Are there any of those wizards around that can share this wisdom?

Mike Green

The PDP-11 (and the PDP-8) had a simple memory mapping unit. The PDP-11 also had position independent code and a stack architecture. Tape was block addressable, so it was much like SD cards. OSs were pretty simple, strictly text-based, and command line oriented. Compilers and the like were usually multi-pass. All of these can be done with a Prop. Sphinx is a good model. We may need to abandon or modify the FAT file system compatibility, maybe have the file open / extend / close support be supported by overlays (which might require a modified Spin interpreter to handle properly). Normal file I/O would just refer to a sequence of blocks. Maybe there would be a requirement to have any video buffering be done in the I/O driver's cog memory. That would limit screen size unless external SRAM were used, but it would allow for maximal use of the limited hub memory. Perhaps a two Prop system would be the minimum if VGA or NTSC/PAL video were used for the console display.

Again, the heart of getting an OS to work on small hardware is to trim down its functionality, make resident only those features that are absolutely necessary to have around all the time, and sacrifice speed for space (overlays) for those features that are still necessary, but only occasionally.

kwinn

Although I worked with both PDP8 and PDP11 early on I didn't get as deep into the operating systems as I did with CPM and MPM. Writing a basic driver in assembler to interface an optical tape reader to a PDP8 in university was about the deepest I got.

What I recall was the similarity of many of the CPM commands to those of the PDP operating systems when I first started with CPM. As I recall Gary Kildall used his favorite commands from the PDP and various other operating systems at the time as the basis of the CPM commands. There were quite a few variations of CPM as well. I used QNX at one point and it allowed me to run up to 4 "terminal" windows, each running a CPM program. There was also MPM - a multi tasking version of CPM, and a semi-graphical version that put any .com file names on a specified drive into boxes on the terminal screen. A program was executed by using the arrow keys to select a box and pressing enter.

kwinn

@prof_braino

I would suggest looking at CPM rather than the PDP8/11 operating system for several reasons.

- All of the code is readily available.
- The operating system and program code can fit in a small memory space. ( I ran CPM and Magic Wand or Supercalc in 16K of ram.)
- It was written after and based on the best (in Gary Kildalls opinion) features of existing OSes including PDP8/11.
- It is already running on the prop so it's functions can be easily analyzed.
- There was both a Forth interpreter and a compiler available for CPM. (Not sure if either is still available)

I'm not suggesting that we use the 8080/z80 emulator and CPM for the operating system, only that we adapt the techniques used to get all that functionality in such a small memory space and low execution rate.

Christof Eb.

Hi,
i have thought about pdp11 or lsi 11 and the prop. Most interesting is the overlay feature, which should / could be adopted to the gnu c compiler. Memory was divided into overlay regions. Code was automaticly loaded into the predefined region from disc or virtual disc and then executed. There was 1mb of ram , but a program could be only 64kb, so we used the ram as virtual disc and loaded the overlays from it. I worked with fortran77 then. Overlay management was done through the linker. This is an interesting field, but as a matter of fact there are now processors, which can handle large memories. . . . Christof

Cluso99

I cut my teeth on a Friden/Singer/ICL System Ten and later the System 25. It was an assembler mini not unlike the propeller in many ways. I taught both hardware and software on this mini, and wrote an emulation on the 486 33MHz PC that ran 3x faster.

One of the oppositions to the System Ten was the PDP-11 and the DEC VAX.

Originally, the S10 was restricted to 10KB (a byte was actually 6 bit ASCII) and the common area was also 10KB but later expanded to 80KB. Total memory was 110KB max. Online live billing an accounting was done on these minis. Overlays were a big part of the programming techniques. It was a RISC machine with dual operands (10bytes = 60 bit instructions) and only 15 instructions. It could have 20 partitions (similar to cogs, but the hardware actually did the time slicing between one processor).

CPM (v2.2) was a good example of what could be done on a micro at the time. I have been looking to see what would be involved in using FAT16/32 for CPM (for ZiCog) because I could see some simple benefits here because we can switch in and out of ZiCog to use all the programs in CPM2.2 and stil have access to the files under prop. SO we could concurrently have the best of all worlds.

What I don't like is the baggage these days. It is just an overkill. Everything is redirected so many times that the processing power has been usurped to just control the indirection. We could have a simple GUI on the prop quite easily - Drac has done this.

So, to summarise, there are plenty of techniques available to us to make a nice prop OS. I have been working on one such os, based on others work where I can to save re-inventing the wheel. Unfortunately, there seems noone really wanting to pool resources to make this a reality. Everyone has their own agenda. Sphinx had some of the best basics I have seen thus far, and I have built upon these. I am not looking for an *nix look-alike because IMHO this is too complex for a prop. A more CPM like interface which we can build upon seems like a better way to approach this. All OS features are single small programs. So DIR, LS, etc are all small programs that use a hardware independant IO. Anyone can then easily add a feature to the OS without concern for whatever else is available. If it is a great feature, then people will use it.

And finally, I believe a dual prop is the way to go, where the processing is done with a fast SRAM prop and the I/O on another prop (or more). To this end I have just created a cost reduced RamBlade3R which will satisfy the processing prop and other props in the pipeline for the I/O prop (or whatever prop system you have).

kwinn

Cluso99 wrote: »

CPM (v2.2) was a good example of what could be done on a micro at the time. I have been looking to see what would be involved in using FAT16/32 for CPM (for ZiCog) because I could see some simple benefits here because we can switch in and out of ZiCog to use all the programs in CPM2.2 and stil have access to the files under prop. SO we could concurrently have the best of all worlds.

What I don't like is the baggage these days. It is just an overkill. Everything is redirected so many times that the processing power has been usurped to just control the indirection. We could have a simple GUI on the prop quite easily - Drac has done this.

So, to summarise, there are plenty of techniques available to us to make a nice prop OS. I have been working on one such os, based on others work where I can to save re-inventing the wheel. Unfortunately, there seems noone really wanting to pool resources to make this a reality. Everyone has their own agenda. Sphinx had some of the best basics I have seen thus far, and I have built upon these. I am not looking for an *nix look-alike because IMHO this is too complex for a prop. A more CPM like interface which we can build upon seems like a better way to approach this. All OS features are single small programs. So DIR, LS, etc are all small programs that use a hardware independant IO. Anyone can then easily add a feature to the OS without concern for whatever else is available. If it is a great feature, then people will use it.

And finally, I believe a dual prop is the way to go, where the processing is done with a fast SRAM prop and the I/O on another prop (or more). To this end I have just created a cost reduced RamBlade3R which will satisfy the processing prop and other props in the pipeline for the I/O prop (or whatever prop system you have).

This is pretty much what I had in mind when I made my earlier posts. A bare minimum number of the absolutely necessary built in functions and commands with small programs to do the rest. Speed wise this would be CPM on steroids since we would have much higher cpu and storage access speeds by using multiple cogs and SD for storage, DMA speed I/O by using cogs for that, and a choice of command line, menu based, or graphical interface by making the console program loaded an option.

Cluso99

kwinn: I think you should take a look on this thread...
http://forums.parallax.com/showthread.php?138251-A-Propeller-OS-that-can-run-on-multiple-hardware...

Last night I recompiled it using homespun because I can setup a bat file to compile all the program files at once.

Sapieha

Hi prof_braino.

On this site You can find latest SIMH emulator (SIMH (V3.9-0) updated 03-May-2012) that have PDP11 simulation.
http://simh.trailing-edge.com/

And on this site some Doc's on its usage.
http://simh.trailing-edge.com/pdf/all_docs.html

Maybe that can help You.

prof_braino wrote: »

Hi all

Anybody have experience with with PDP-11, etc? Specifically, writing applications in assembler code, and paging to tape. I don't want to do anything with the PDP or tape, per se, it just want to learn about the techniques folks used to be get by in that environment.

There have been many discussions of OS for the prop, these efforts seem to grow past the bounds of the stock prop hardware rather quickly. For this experiment, the first requirement is it applies to any stock prop.

The suggestion was, when considering an OS for the prop, look at what they did in for example a PDP environment.

To put this in context, we were talking about operating systems and code bloat slowing down every new processor that comes out; and how this affect is magnified on the prop. (Folks trained in the PC environment tend to add stuff till the processor chokes, or at least this is my tendency). But, the prop should have ample resources for many task, if we don't get crazy. So we want to get as close to the crazy line as possible without stepping over too many times. So we want to include as many of the most useful functions as possible, and leave off (for now) as many of the secondary functions as possible. So the question comes down to requirements, how to define useful "primary" functions and identify non-essential "secondary" functions.

Are there any of those wizards around that can share this wisdom?

Leon

Here is a PDP-11 that has been implemented in an FPGA:

http://opencores.org/project,w11