Starting a SoC (FPGA + ARM) implementation for the PiDP-8

[Folke Will]

Hi all,

I received my PiDP-8 kit three weeks ago and immediately fell in love with it! I'm planning to use it as a tool to teach the basics and history of computing to young adults at the company I work at.

To better understand the system, I'm planning to do a SoC (FPGA + ARM CPU on a single chip) implementation of a PDP-8/I with this vision:

• drop-in replacement for the Raspberry Pi, not much tinkering required
• follow the maintenance manual as strictly as possible - if it mentions a sense register, then there shall be a sense register that works as specified
• fully operational console, i.e. including single stepping
• fast startup time - immediately ready after turn on
• ability to turn it off at anytime without SD corruption or something similar
• future: use a touch display to visualize and use peripherals, ideally in the same type of box stacked on top

The idea is that the FPGA implements the PDP-8/I while the peripherals are implemented in C++ on the ARM. These ARMs can run Linux quite well, but I will probably do a bare metal implementation or use FreeRTOS so that the whole system can run from RAM without any boot time. That way, only the tape and disk images need to be on the SD card so the system can also be safely turned off at any time. The boards also have USB and ethernet for more connectivity.

I'm an embedded C++ developer with a background in CS and not in EE so I decided to do a small proof-of-concept project to see if my skills are sufficient to do this project before reaching out to this group. I managed to get the following working in the last days:

• found two SoC boards (Xilinx Zynq, picture with both boards attached) that have a Raspberry Pi connector
• implemented a console multiplex driver in VHDL to operate the PiDP console
• implemented a basic PDP-8/I CPU (minus I/O) in VHDL
• implemented a C++ program that runs on the ARM and can access the PDP's memory and generate interrupts in the PDP to test communication between FPGA and ARM
• ran the system on the boards and it worked, ready in less than a second, startup time will not increase with complexity
• had to replace the 1k resistors with 220 Ohms due to difference in pullup resistors on the SoC, but the new resistors still work for the Pi
• was able to toggle in basic programs and single step through the CPU cycles or running it without pause
• apart from the resistors, no changes to the PiDP hardware and no adapter or anything else required, just a different board

Since all of these steps worked, I'm positive that the project could be successful. I will now start the real implementation that closely follows the maintenance manual and set up a project on GitHub for that. I've already added a basic readme with more details and the VHDL code for the console: https://github.com/fpw/SoCDP8

If you're interested in the proof-of-concept code, I could share that as well but it's rather hacky because I only wanted to see if it's possible to use a SoC for this job.

Hope that you find this interesting and maybe someone even wants to help - after all, this will be my first real VHDL project. I'll keep the group updated as I make progress.

Regards
Folke

[David Richards]

Greetings Folke,

I'm very interested in your project and shall follow it to see how it progresses. 

I imagine it will not be easy to get the best out of the Zynq board.

Funnily enough I only heard about these just a few days ago.

How do you find the toolchain, are the supplied examples easy to adapt?

btw, it the toolchain free for personal use?

Kind regards, David.

[Folke Will]

Hi David,

I'm very interested in your project and shall follow it to see how it progresses. 

thanks! I've already made some progress. Both the manual and the automated computer timing generators are implemented now, that's the hardest part of the system. I decided to go down the rabbit hole and study the engineering drawings instead of only using the maintenance manual. An example that explains my current workflow is attached: I printed and annotated the drawings (picture 1) while reading the maintenance manual that explains the operation. While doing that, I summarize parts of the drawings in my own words (screenshot 2) and finally implement each part of the drawing in VHDL (screenshot 3). The first image shows a NAND gate on the left that connects MFTP2 and the complemented KEY LA signal. The code that implements this is actually the code shown in screenshot 3. As you can see, I rephrased the logic a bit in order to make the code more understandable when I'm sure that my simplifications don't change the behavior. Also, I'm using synchronous state machines instead of the asynchronous level-based design of the real system, but that shouldn't make a difference in the observed behavior. My goal is to trace every gate of the drawings back to the code and vice-versa, that's what my annotations actually mean.

At the current state, I can operate the front panel of the PiDP-8 connected to my SoC, i.e. I can use the switches to read and write memory and to set and clear the run flip flop. If I didn't make any mistakes, the behavior of my implementation should now be exactly as in the real system down to the switch debounce delays.

 

How do you find the toolchain, are the supplied examples easy to adapt?

As a software guy, I don't like either of the Xilinx (Vivado) or Altera / Intel (Quartus) toolchains. They lack basic things like removing trailing spaces on save and don't integrate well with a VCS like git. And no advanced feature like signal renaming exists. There's a vendor-independent IDE called Sigasi that has all of that, but it's 70€ per month.

But there are lots of examples - some come with the toolchain and some come with every board. However, Xilinx is trying to force you into a vendor lock-in by making it rather tricky to use a mostly VHDL based design instead of creating and using pre-created IP blocks and connecting them graphically. But it's still very fun to see how your code turns into counters, registers and logic in the way you have imagined.

 

btw, it the toolchain free for personal use?

Yes, both Vivado and Quartus have a free version. At the price of forced telemetry that sends statistics about every generated design back to the vendor. Could be prevented with an /etc/hosts entry, though.

 

Regards
Folke

[David Richards]

Hi Folke,

The bare metal front panel work sound very good.

The PYNQ board seems very good value, I'll probably buy one to play with.

they seem to be less expensive from farnell then aliexpress, odd

I have a little experience of the Pidp2011 which uses a Cyclone IV with Quartus.

The free version of Quartus seems very slow, even on a half decent PC.

I wonder if the A9 would be capable of running simh as an alternative to the FPGA simulation.

One board to run either configuration sounds interesting.

The board seems very well documented, made for learning.

Ive just been watching an introduction video.

Kind regards, David.

[Folke Will]

The PYNQ board seems very good value, I'll probably buy one to play with.

they seem to be less expensive from farnell then aliexpress, odd

Make sure to get the Z2 version of the Pynq board, the other version doesn't have the Raspberry connector. If you want to want to dive into Zynqs in general, this is a really good board because it has to many GPIO pins. In fact, you could drive two PiDP-8 consoles or one PiDP-8 and a PiDP-11 at the same time. If you want to connect the PiDP-8 or -11 to that board, all you need is a male to female ribbon cable and replace the 1k row resistors with 220 Ohms. They still work with the Raspberry Pi after that modification.

I bought a 15 cm ribbon cable and connected that to the back of the PiDP-8 case, so now I can switch the boards without opening the case. 

 

The documentation of the board has a few mistakes in the description of the Raspberry connector. I worked out the real pins here: https://github.com/fpw/SoCDP8/blob/master/src/fpga/boards/pynq-z2_constraints.xdc

I wonder if the A9 would be capable of running simh as an alternative to the FPGA simulation.

One board to run either configuration sounds interesting.

Haven't tried that, the GPIO driver would have to be re-written. 

 

[David Richards]

here is my pidp2011 system using Cyclone IV

https://groups.google.com/d/msg/pidp-11/E-RMRVQ15NQ/5LE3oTg9CAAJ

I had a similar problem when using the Altera FPGA which needed the row resistor modification.

more info here:  https://github.com/DavidJRichards/pdp2011/wiki/A_ESTF

I had too make an adapter board to suit connectins to my FPGA, the PYNW-Z2 looks very neat.

I have also a unibone which can run a cpu simulation based on the pdp11-20 instruction set.

I have access to some broken DEC systems, I'm learning about their operation on these simulations.

David.

[Folke Will]

Small status update after the first milestone is reached:

• Fully implemented all non-EAE instructions
• Fully implemented the original I/O bus, i.e. IOP pulses are generated by IOT instructions and peripherals can assert signals like AC CLEAR, SKIP etc.
• Implemented an I/O controller on the bus that can talk to the ARM to implement actual I/O devices there
• Implemented a reader and punch on the ARM

The system can now load programs using the RIM loader while the teletype reader is simulated by a C++ program. For testing, I loaded MAINDEC 801-1 and ran it successfully, it printed 1 and ?@? on the teletype.

Also, I compared my implementation with the video that Bill Cattey took of a real PDP-8/I at the Rhode Island Computer Museum in 2015 and the system behaves exactly as it should including single stepping, state lamps etc.

TODO for the PDP-8/I:

• EAE
• Databreak
• Interrupts

For the ARM, I'm thinking about using MicroPython instead of C++ to control the system. That would probably make it easier to add new features or interact with the system.

[clasystems]

On Thursday, August 1, 2019 at 6:43:29 PM UTC-4, Folke Will wrote:

Small status update after the first milestone is reached:

• Fully implemented all non-EAE instructions
• Fully implemented the original I/O bus, i.e. IOP pulses are generated by IOT instructions and peripherals can assert signals like AC CLEAR, SKIP etc.
• Implemented an I/O controller on the bus that can talk to the ARM to implement actual I/O devices there
• Implemented a reader and punch on the ARM

The system can now load programs using the RIM loader while the teletype reader is simulated by a C++ program. For testing, I loaded MAINDEC 801-1 and ran it successfully, it printed 1 and ?@? on the teletype.

Also, I compared my implementation with the video that Bill Cattey took of a real PDP-8/I at the Rhode Island Computer Museum in 2015 and the system behaves exactly as it should including single stepping, state lamps etc.

Sounds like a really good start.   A few minor corrections and comments.

1) It was last year at the RICM.  Bill and I were there when he took the original camera shots of the 8/I.  I was demoing P?S/8 running on that machine, which is pretty bare-bones but enough to run P?S/8: a) 4K, b) TC01, c) TU55 drives, d) ASR-33 all working and some minor plans for expansion, but that is literally the minimum requirement for P?S/8 which was originally started as the R-L Monitor on a straight-8 with EAE and one TU55, otherwise the same configuration ; on that system the console might be an ASR-33 but more likely a KSR-35.  Paper-tape is a serious waste of time, but all you need is a storage device I can write a one-page system device handler in to make the difference.  In the works is a modification to Kyle Owen's erszatz "RK8E" support so that all you need beside the CPU etc. is a serial interface to a support PC running either Windows or linux.  If anyone wants to volunteer to make some modest changes to the C source code, please contact me; it is minor but crucial because of small differences between P?S/8 and OS/8, etc. [Note: I am the current maintainer of the OS/8 handlers for this as well.]

2) It is CRUCIAL that you provide a facility for certain IOT instructions to create a temporary slowdown of the emulated machine.  Existing software for various peripherals WILL FAIL unless this is accomplished.  It can be as simple as setting a count of how many simulated instructions are slowed down to approximate the original machine's design speed when any of them are encountered.  The net effect will be negligible but will not break software timing loops that were never expected to work on machines say double, triple or more that that over original machine speed.  For example, in OS/8 Kermit, which I also wrote, the TTY: output flag must either set or not set [so the software can set it!] after a reasonable time-out.  On an actual PDP-8/E this would be worst-case 5 seconds, somewhat longer on other models; this was not done with faster emulations in mind back in the day.  Once the flag comes up, the software speed is unimportant, thus once the last TSF executes and the flag either actually does come up or the associated software timing loops overflow and the software executes the TLS instruction with a nul value in the AC, all following instructions can be any speed possible without problems.  This was part of the original design to prevent a "splat" character on the ASR-33. etc.  There are similar considerations on the RX8E because on the real interface, it can take as long as FIVE seconds for the flag to raise.  Software timing out too fast gives a false error condition as others have found out trying to do roughly what your project entails.  This fixes all cases as long as the temporary speed is a vague approximation of original design speed; the software timing loops are generally quite forgiving with one notable exception: FOCAL, 1969 has defective timing that will often cause actual 8/I systems to be misidentified as PDP-8/L.  I have a fix for it, but this is bad software and the exception you shouldn't be trying to fix.  [Note: This doesn't come up on the PiDP-8 because it emulates a PDP-8/E not a PDP-8/I, and arguably that should be added as an option, involves changing a few instructions, etc.

[Folke Will]

Sounds like a really good start.   A few minor corrections and comments.

Thanks for your comments!

 

1) It was last year at the RICM. 

Right, sorry. For the record, this is the video I was talking about: https://www.dropbox.com/s/rwitfo8kceg62yx/RICM-pdp8i-480p - 1.mp4?dl=0

 

2) It is CRUCIAL that you provide a facility for certain IOT instructions to create a temporary slowdown of the emulated machine.

My plan is to let the system always run at the original speed, including the IOT instructions. The actual performance that the user can feel can still be changed by changing delays in the simulated peripherals, I think this is basically what you suggested but slowing down the peripherals instead of the IOT instructions.

Initially, I tried to generate interrupts in the ARM whenever an IOT instruction caused an IOP pulse so the ARM can react to that in real time and put the desired signals back on the bus. However, the interrupt delay in the Zynq is too high for that.

My current implementation for I/O works like this: There is a small I/O controller inside the FPGA part that sits on the bus of the PDP. It can be controlled and configured from the ARM. Each device gets a register, a flag and a few micro-coded instructions that can control what happens on IOT pulses and when to generate interrupts to ARM or the PDP. For example, to implement the TTY reader I configured the I/O controller to handle device 3 like this:

• IOP1: Set IO SKIP if device flag is set
• IOP2: Clear the device flag, put zero on the bus, generate an interrupt in the ARM (so it can write new data)
• IOP4: Put the register on bus
• PDP Interrupt: Set if flag is set
• On I/O memory write: Set flag

This micro program can be configured from software for each device. It decouples the I/O speed from the PDP speed and still allows the IOT instructions to run at original speed even if the ARM only updates the I/O data once a second or slower. That way, I hope to be able to simulate arbitrary peripherals without changing the FPGA design. I already noticed that if I don't implement any delays, even the RIM loader will fail because it executes KCC in one cycle (IOP2) and KRB (IOP2 + 4) in the next cycle and still expects the original data instead of the new one. But I was able to fix this by waiting a few ms in the ARM code before putting new data in the I/O memory.

Does this make sense? I've never used or even seen a real PDP-8, so I can't anticipate all peripheral requirements but hope this micro-programmed I/O solution will allow implementing all peripherals. I haven't tried Focal yet because I need to implement the EAE for that first, your comments sound like this will be interesting to observe.

[CLASystems]

On Sat, Aug 3, 2019 at 10:47 AM Folke Will <folke...@gmail.com> wrote:

Sounds like a really good start.   A few minor corrections and comments.

Thanks for your comments!

 

1) It was last year at the RICM. 

Right, sorry. For the record, this is the video I was talking about: https://www.dropbox.com/s/rwitfo8kceg62yx/RICM-pdp8i-480p - 1.mp4?dl=0

 

OK

 

2) It is CRUCIAL that you provide a facility for certain IOT instructions to create a temporary slowdown of the emulated machine.

My plan is to let the system always run at the original speed, including the IOT instructions. The actual performance that the user can feel can still be changed by changing delays in the simulated peripherals, I think this is basically what you suggested but slowing down the peripherals instead of the IOT instructions.

Not quite.  The slowing down of peripherals to true original speed is a nice frill, but not the issue.  There is a semblance of this in the SIMH settings used in both the PiDP-8 and in my implementation of SIMH for Windows specifically.  It makes P?S/8 booted to TC01/TC08 feel SLIGHTLY more realistic, but only barely an improvement.  a key point here is that when people see P?S/8 running on the TC01/TC08, they are often waiting for nothing!  P?S/8 has already come up and is waiting for them long before OS/8 would eventually get up on the same device!  This is because even the bootup procedure in P?S/8 is optimized and OS/8 is frankly sloppy throughout.  [I nearly worked on it back in the days; my friends wrote it but were largely unmotivated]

So, sure something that reveals the true overhead in realistic terms is welcome, perhaps something like a screen graphic when the tapes are searching.  I can advise exactly when to do what when you get further along, etc.

But the true issue is software timeout realism regardless of speed.  The PDP-8 software has to run on a 110 baud Teletype model ASR-33 or perhaps if the console is an ADM-3A glass teletype at 19,200 or all points in between such as a 9600 baud baud VT-52.  The software timing must not over-run the software timing loops while waiting for flag-based results to either happen or definitely NOT happen.  For any successful emulation, the achieved speed of the associated instructions that happen just after the affected IOTs must be maintained. the speed of all else doesn't matter to the software, etc.  There are known considerations in many devices; I've written a few of them myself, but the conventions are universal; I admit this is not very well documented, but it is completely true.  It only became an issue after all DEC machines including DECmates were in the past, etc.

Initially, I tried to generate interrupts in the ARM whenever an IOT instruction caused an IOP pulse so the ARM can react to that in real time and put the desired signals back on the bus. However, the interrupt delay in the Zynq is too high for that.

My current implementation for I/O works like this: There is a small I/O controller inside the FPGA part that sits on the bus of the PDP. It can be controlled and configured from the ARM. Each device gets a register, a flag and a few micro-coded instructions that can control what happens on IOT pulses and when to generate interrupts to ARM or the PDP. For example, to implement the TTY reader I configured the I/O controller to handle device 3 like this:

• IOP1: Set IO SKIP if device flag is set
• IOP2: Clear the device flag, put zero on the bus, generate an interrupt in the ARM (so it can write new data)
• IOP4: Put the register on bus
• PDP Interrupt: Set if flag is set
• On I/O memory write: Set flag

This micro program can be configured from software for each device. It decouples the I/O speed from the PDP speed and still allows the IOT instructions to run at original speed even if the ARM only updates the I/O data once a second or slower. That way, I hope to be able to simulate arbitrary peripherals without changing the FPGA design. I already noticed that if I don't implement any delays, even the RIM loader will fail because it executes KCC in one cycle (IOP2) and KRB (IOP2 + 4) in the next cycle and still expects the original data instead of the new one. But I was able to fix this by waiting a few ms in the ARM code before putting new data in the I/O memory.

Does this make sense? I've never used or even seen a real PDP-8, so I can't anticipate all peripheral requirements but hope this micro-programmed I/O solution will allow implementing all peripherals. I haven't tried Focal yet because I need to implement the EAE for that first, your comments sound like this will be interesting to observe.

Your description sounds essentially correct for output, but each IOT is quite unique to the device.

There is a "great divide" in the actual implementation of IOT instructions.  The PDP-8/E and newer generate 8 unique instructions while all earlier models have the IOP pulses as you describe.  On the PDP-8/E, devices such as the console mimic the limitation but also support other superset instructions that can help,but not in operating systems that have to be compatible with all systems.  For example, a common problem found for example in FOCAL is that if interrupts are on, it is impossible to stop the low-speed paper-tape reader.  The clearing of the interrupting keyboard flag sets reader run guaranteeing another character 1 tenth of a second later unless you manually disable the reader or it runs out of tape.  The instruction 6030 was added to ONLY clear the flag to remedy it, but it is not universally compatible.  User patches to FOCAL exist to incorporate this if applicable, etc.

In general, both P?S/8 and OS/8 are interrupts-disabled systems; programs run from either CAN handle their own interrupts, but are completely "on their own".  When the paper-tape reader on the ASR console is used this way, the tape can ONLY advance when the software is ready.  As such, users of P?S/8 use the built-in system line editor to create FOCAL programs from paper-tapes and then pass the storage-based P?S/8 text files to FOCAL after the fact, etc.

OS/8 has its own share of problems with the various interrupt-driven run-time systems of various languages; they occasionally need their own patches, etc.

hope that helps slightly,

cjl

recived this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/1Rdv-Syg9H4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/84952145-f74c-45c4-b784-a8e15fb7182e%40googlegroups.com.

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[David Richards]

Hi Folke,

There seem to be a few different version of Vivado available on the Xilinx web site, can yu tell me which I should be using. My PYNQ Z2 board should arrive soon, I'll start out by trying the inbuilt python generator but want to be able to compile VHDL too.

Kind regards, David.

[Folke Will]

Hi David,

 

There seem to be a few different version of Vivado available on the Xilinx web site, can yu tell me which I should be using.

the free version is called "WebPACK", use this link:

https://www.xilinx.com/member/forms/download/xef-vivado.html?filename=Xilinx_Vivado_SDK_Web_2019.1_0524_1430_Win64.exe 

Followed by this update:

https://www.xilinx.com/member/forms/download/xef-vivado.html?filename=Xilinx_Vivado_SDx_Update_2019.1.1_0629_0743.tar.gz

On a side note, I finished the interrupt implementation and all of the EAE commands except DVI. So maybe Focal69 will run later this week.

[David Richards]

Hi Folke,

Thanks for the links.

Glad to see you are making progress.

I'm going to need to get a bigger disk drive.

Kind regards, David.

[CLASystems]

FOCAL only need the basic PDP-5/PDP-8/S subset of the PDP-8 instruction set to run.  This bears a bit of explaining.

1) The PDP-8 instruction set ON PAPER came first.  This was never actually implemented if you want to be scrupulously accurate.

2) The PDP-5 was released hastily after some ill-advised bastardization occurred; that it was a dismal marketing failure attests to this:

While in the main, the PDP-5 was designed initially without compromise using pretty much the state of the art core memory at the time (which was quite expensive), the expected performance was never delivered because of a last-minute design decision to bastardize the design.  As such, the PDP-5 has the dubious distinction of being the only model lacking an actual program counter register!  This was seen [clearly ill-advisedly] as an "economy"
 measure.  Instead far more complicated gating logic and clearly time-consuming wasted additional states are added to store the intended contents of an actual program counter register in memory location 00000 and then ferry it across and back to the memory buffer setting the memory address register to 0, conduct the latest transaction, then write back to location 00000. then having that instruction in the memory buffer, perform the usual decode logic, etc.

Despite all of this silliness. it still winds up with an instruction cycle time of about 7.5 usecs, one fifth of the eventual PDP-8.

An important distinction between PDP-8 models centers on what combined operate instructions in group I are allowed or not.  When the PDP-5 design was implemented (and presumably the PDP-8 paper spec was available) this did NOT include combining certain instructions such as complements combined with rotates. etc.  Thus, since FOCAL is designed to run on this reduced instruction set, it doesn't require any of these instruction set extensions.

However, because of the incompatibility of the program counter issue as implemented in the PDP-5. interrupts do NOT store into location 0 as in all later models, instead the interrupted PC is stored into location 0001;instead of control passing to location 00001, it passed to 00002.  For software such as FOCAL, this means that all three locations are reserved for interrupts!

When FOCAL, 1969 starts up, once-only initialization code checks for this by storing the address-1 of a routine only for the PDP-5 into location 00000 while interrupts are still off.  If that special routine is entered. it is clear this is a PDP-5 and the interrupt vector is modified accordingly.

3) Eventually, the next model was the original "straight" PDP-8 [so named because there is no -anything after the name].  This model removes the program counter kludge and runs five times as fast using then-current premium speed memory to achieve a clean speed of 1.5 usecs.  Most models to follow are not all that different in speed, and thus, this establishes how software timing loops should be designed assuming this speed and a 110 baud ASR-33 Teletype console, etc. A generous safety factor is advised to account for various aberrations, but it is generally agreed to make the worst-case timing of waiting for the output flag to not actually raise within say 5 seconds at most on the straight PDP-8.

However, the straight -8 instruction set is a SUPERSET of the original paper-spec, and adds the ability to combine rotates and complements in the same instruction, complements and increment, but NOT rotates and increment.  Thus., while better, it is certainly not complete.

Most successful PDP-8 software assumes this as the base instruction set required.  It even has a folksy marketing term for it known as the "family of 8" which came about because of a somewhat demented marketing ploy involving pieces of eight and a pirate theme. but regardless the name stuck.  Family of 8 compatibility is a hard requirement of among other things TSS8, P?S/8, OS/8 and COS-300/310.  [Note: P?S/8 is an outgrowth of the former R-L Monitor System available from DECUS but it is severely limited in terms of literally many dozens of features added in P?S/8 development over the course of decades and currently.  Most important. R-L can only be run on a TC01/TC08 and a TU55 set to drive 0.  It does NOT support logical drives while P?S/8 supports all 8 drives on the TC01/08 but the minimum complement is the same as the R-L assuming the system device is the DECtape controller; that said. it is also available for most of the other storage devices OS/8 can run on, etc.  Most notably. it includes a system program based on FOCAL, 1969 with added system-specific file support such as adding nearly limitless input capabilities from the contents of files while completely eliminating paper-tape support which ironically takes up about the same amount of space internally!  If paper-tapes are required to be converted, this is handled separately by other P?S/8 facilities that support both the low-speed and the high-speed reader/punch. etc.  But once FOCAL is added to a storage-based operating system environment. paper-tape support is clearly a drawback and totally unnecessary, etc.

It is especially noteworthy that all of the above systems do NOT run on the PDP-5, and also do not run on the PDP-8/S [see below].

4) The PDP-8/S has the dubious distinction  of being the only model marketed that has a less capable instruction set than the predecessor straight-8.  Most are are aware that it is  by far the SLOWEST model due to implementation using serial logic. but more importantly. other than correcting the program counter kludge of the PDP-5. it fails to be compatible with the straight PDP-8; it otherwise has all of the operate instruction restrictions of the PDP-5!

As such. the entire "family of 8" software collection CANNOT run on a PDP-8/S. even if it has the expensive option of an added DF32 minidisk [which has to be slowed down to a DMA interleave of 4:1 to not over-run the bus!].. As such, only the 4K Disk Monitor System can be run on this dreadful slow machine!  Additional memory can be added and the only support is loading and saving the extra memory locations, etc.

It would seem the PDP-8/S design crew didn't get the message that the proper model to work with was the PDP-8., and not the PDP-5.  None the less, FOCAL 1969 can run on this model as well because it makes a special-case check for the PDP-8/S and upon proper model discovery, it changes the timeout values in the software timing loops/

In essence, FOCAL, 1969 is the "exception that proves the rule" since so little runs on this slow machine.  Many are unaware of these restrictions, but eventually hard reality always wins out.

5) Newer models add some features; the PDP-8/I and PDP-8/L are fairly similar and both support combining increment with the rotates.  However, the successful software cannot make use of this because it would break PDP-8 compatibility to do so [and not be family of -8!]  As such, using these instructions is heavily frowned on [with a lone exception, see below).  Moreover, these instructions were eliminated in even newer models due to their general uselessness other than for model identification.

6) The PDP-12 is compatible the PDP-8/I until the instruction 6141 is executed.  Then, instructions continue in the instruction set of the classic LINC. LINC-8 with some minor exceptions mostly improvements in resolution, superset features beyond the original LINCtape implementation, and no need for emulation.  In fact an emulator trap was added to obtain partial backward compatibility to allow alternate console support as an option, etc.

Since it is clear the CPU is lockstep otherwise identical to the PDP-8/I, device handlers for the PDP-12 are allowed to use these superset operate combinations. etc.

7) FOCAL, 1969 as released has compatibility issues discerning a PDP-8/I from a PDP-8/L/  In certain cases, the 8/L will be falsely detected.  This is due to one of the following reasons:

a) Software timing doesn't work because the machine's cycle time, nominally 1.5 microseconds has been"detuned" slightly to me closer to the nominal speed of the PDP-8/L   This was a common problem during the economic lifetime of these models and why both the PDP-8/L and PDP-12 were deliberately slowed to 1.6 usec to avoid excessive vendor product rejection.  In many cases. expedient field service slowed down the 8/I to get the machine functional  after component aging occurred. etc.

The problem is the kludged presumption that the teletype output flag can be used as a primitive "clock" trustworthy to come up in 1/10 of a second after successfully waiting for it to clear then outputting with a TLS instruction with a nul AC.  This avoids the "splat" on the console in case a previous character was in the process of printing.  [FOCAL does get the basics right on flag timing,]

However, if the machine is a bit too slow, the time-out might well indicate a PDP-8/L.

b) The actual console speed may be faster talking to a terminal emulator; these days it is not uncommon to find the baud rate generator card is replaced with a variable clock; 1200 baud seems to be common,etc.  Clearly, FOCAL will ALWAYS guess wrong.

Additionally, DEC sold a console upgrade for all three machines to add the LA-30P DECwriter I, which prints at nominally 30 CPS, further guaranteeing this is a poor method of detection.

There is a code to this portion:  During the initial development of P?S/8, we discovered there is a completely legitimate way to detect a PDP-8/L that works perfectly.

If a model detection routine is attempting to distinguish, place a non-zero value in the accumulator and execute the group III instruction 7601;  This is the third instruction to clear the AC [along with 7200 and 7600).  However, on the PDP-8/L, there is gating logic that disables ALL group III instructions. even the clear the accumulator instruction.  As such, on a PDP-8/I. the AC clears; on the PDP-8/L it stays set.

This can be incorporated into a better model identification routine, which I have done and is available on-line as WHATAMI.PAL.

https://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/Generic%20Programs/WHATAMI.PAL 

and the associated assembly-language listing file 

https://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/Generic%20Programs/WHATAMI.pdf  

This routine will be added into the next release of my Kermit-12 for the OS/8 family; it mostly updates model detection on DECmate-class machine to avoid confusing the SBC6120 from a DECmate.  [The SBC6120 is a PDP-8 based on the same chip, but it is not incompatible the way the DECmates are.  Kermit-12 runs on all of them, but it was unnecessarily difficult to configure for the Gizmo machine, etc.

P?S/8 FOCAL doesn't use a model detection routine and runs on all family of -8 machines.  Since P?S/8 itself runs only on family of 8 machines, certain internal modifications were made to FOCAL to fix known bugs that were only released by DEC for FOCAL-12 and FOCAL-8, which is NOT a replacement for FOCAL, 1969.  That subject would require a far longer post all by itself.  Short version, don't use it, use FOCAL,1969.  It is one minor step forward and 25 steps backward, and my modifications applied to FOCAL,1969 trade loss of ability to run on the PDP-5 or PDP-8/S with fixing a bug on the "FOR" command code released by DEC later in FOCAL-12 where compatibility isn't an issue.  NOTHING about FOCAL-8 is compatible with anything! [Note: FOCAL-8 includes malware!]

A patch can be made to the FOCAL INIT program to implement the correct I outline above. [Note: P?S/8 FOCAL does not use INIT and instead has a streamlined version internally implemented using command-line switch options to produce a superset result.]

8) FOCAL does not detect newer models at all, such as the PDP-8/E and the PDP-8/A.  These CPUs do not implement the combined rotates as in the PDP-8/I and PDP-8/L.  Instead, a new instruction is implemented to perform a six-bit byte swap, again something FOCAL doesn't use, etc.  But it is a part of the model identification routine as described above.

These two cpus are similar but there is a deliberate model quirk between them to aid in identification.

Note: The PiDP-8 is NOT a PDP-8/I at all!  The instruction set is the PDP-8/E and the model identification routine successfully discovers this.  This is also why the FOCAL model id routine is irrelevant to the PiDP-8; all newer models just are identified as generic PDP-8, assuming INIT is used, thus the 8/I versus 8/L problem does not apply.

It might be nice to see deliberate model implementation avoiding the superset instructions.  This aids in locating bad code misusing the instructions.  I personally have found several instances of instructions added by newbies to OS/8 programs that make them non-functional on certain models.  Most notably, the OS/8 version of the RK8E formatting program will hang the CPU if run on the straight-8 [a viable configuration is the use of the DW8E on the earlier machines.  In fact the PDP-8/I t the RICM is situated next to a PDP-12 with an RK8F and an RK05; the negative DW8E-N would be valid for the straight -8 but that program will hang unless patched. etc.]  Trapping unwanted instructions would be a great feature to find bad software.  [Newbies were never told that the CAF instruction is such that it is bad design  if you need it instead of proper initialization, and worse cannot work at all on the older models and can literally make the machine hang on the LINC-8 and PDP-8!]

As I locate these blunders in OS/8. I will send patches to Bill Cattey who maintains these things.  P?S/8 NEVER has this problem due to more careful implementation.

cjl

You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/1Rdv-Syg9H4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/92e0fa93-a17a-4e7b-bd80-387b60ebeed1%40googlegroups.com.

[Folke Will]

Hi Charles,

again, thanks a lot for all this insight! It's good to hear that most software should work on the 8/I and that Oscar chose the 8/I and not the 8/S. I already feared that I would have to implement the 8/E instruction set (like BSW and EAE B) as well for most software to run, but if I understand you correctly then most software should work even on the original 8/I instruction set since it is part of the family of 8.

All the other information in your posts will be very useful as I make further progress, I'm not far enough to understand everything yet. But I already assembled and ran your identification program on my SoC implementation and after doing a small fix in the OPR instruction, it now outputs:

THIS PROGRAM IS RUNNING ON A PDP-8/I.

:-)

Regards
Folke

[Folke Will]

Small status update: I finished the EAE implementation and the I/O system along with an ASR33 and PR8/I emulation. Loaded Focal69 from the 08-AJAE tape:

> CONGRATULATIONS!!

> YOU HAVE SUCCESSFULLY LOADED 'FOCAL,1969' ON A PDP-8/I COMPUTER.

So Focal69 is fully operational now and correctly identifies the system.  The ARM runs a small shell that can be operated via the UART, it can attach tape images from the SD card to the ASR33 or PR8 and fill the ASR33 buffer with a string input to interact with Focal. Also, the core memory can be saved to and restored from SD images. The system still boots in less than a second and can be shutdown at any time.

Next steps:

• FPGA: Memory extensions and data break
• ARM: GUI on HDMI instead of CLI on UART
• After reading about the Cadetwriter project on the PiDP-11 list, I bought an IBM Wheelwriter and will try to attach its bus to the SoC so I can use it as an ASR33 emulator

[David Richards]

Congratulations to you Folke, very impressive progress.

I too have just bought a wheelwriter to use as a terminal one day.

Do let me know when I will be able to give your project a try on my own Pynq-z2 board.

It is very early days learning my way around the pynq, quite steep compared to Quartus even.

I have Vivado installed now but it isnt easy to get started with vhld on the ZYNC.

All I have managed to get it to do so far is to copy someones overlay to drive a neopixel using Jupyter.

My office is in a mess at present most things except the pynq are packed away pending a re-arrangement.

I dont have too much time for this at present but it very exciting to see what can be done.

Are you thinking of bypassing the Cadetwriter Teensy to drive the Wheelwriter?

Kind regards, David.

[Folke Will]

Are you thinking of bypassing the Cadetwriter Teensy to drive the Wheelwriter?

I discovered another project that uses the Wheelwriter as a printer by directly connecting to its bus, the only electronics part required is a MOSFET: https://github.com/tofergregg/IBM-Wheelwriter-Hack

I'd like to try connecting directly to the bus as well, this should work for the output part. For the input, I hope that there is some bus command to disable automatic printing of the keyboard strokes. Someone uploaded a ROM dump of the Wheelwriter's firmware to that GitHub project, so with some reverse engineering I hope to find such a command. Then I could directly connect the Wheelwriter to the SoC without modifying the Wheelwriter hardware. 

For the SoC's GUI, I originally wanted to connect a touch screen to the HDMI and USB (for touch) ports. But I just discovered that the HDMI port is directly connected to the FPGA, so I'd have to create my own HDMI video card and talk to the display in VHDL, probably accessing the DDR memory via DMA. But that'd be a lot of work. And also, Xilinx' USB driver doesn't support host mode on bare metal, so I'd have to create my own USB driver for HID devices as well.

That sounds like a lot of work, so I thought about an alternative: The Pynq and ZynqBerry boards have an Ethernet port that's connected to the ARM instead of the FPGA and there is a bare metal TCP/IP stack, so maybe I'll implement the GUI in HTML and JavaScript instead. That way, users could use browsers on a tablet to interact with the system. Or a simple UDP interface and a custom Android app. Not sure yet.

 

It is very early days learning my way around the pynq, quite steep compared to Quartus even.

I have Vivado installed now but it isnt easy to get started with vhld on the ZYNC.

All I have managed to get it to do so far is to copy someones overlay to drive a neopixel using Jupyter.

I suggest to start with a VHDL-only design as a first project. Creating a custom overlay that can talk to Python is more complex. To create a normal VHDL design, here are a few notes:

• create your VHDL design as usual so that there is a top module that has a clock signal and some outputs
• create a block design, add the Zynq using the "Add IP" context menu
• add your VHDL top module to the block design using the "Add Module" context menu
• connect the Zynq's FCLK_CLK0 signal to your module's clock input and also to the Zynq's M_AXI_GP0_ACLK input
• for all the other signals of your design that should be connected to some component of the board, right click the pins and select "Make External". That will assign signal names that can be connected to FPGA pins using the contraints file
• create a VHDL wrapper for the block design by right clicking it in the project browser and selecting "Create HDL" wrapper
• set the generated VHDL wrapper as actual top module using the context menu
• the design should now be able to synthesize
• File -> Export Hardware followed by File -> Launch SDK
• create an empty hello world application in the SDK, it's required to setup the PLL etc.
• launch the application in the SDK and your design should function

Most of these steps are only required for the initial setup. The normal workflow that Xilinx wants you to use is using IP cores only and no custom VHDL code I believe. You can actually create IP components from your VHDL designs, but that's even more complicated.

This site explains the steps in more detail, they're using Verilog instead of VHDL but all the other steps are the same: https://numato.com/kb/styx-use-xilinx-zynq-ps-pll-clocks-fpga-fabric/

 

[Russell Senior]

>>>>> "Folke" == Folke Will <folke...@gmail.com> writes:

Folke> Are you thinking of bypassing the Cadetwriter Teensy to drive
Folke> the Wheelwriter?

Folke> I discovered another project that uses the Wheelwriter as a
Folke> printer by directly connecting to its bus, the only electronics
Folke> part required is a MOSFET:
Folke> https://github.com/tofergregg/IBM-Wheelwriter-Hack

Folke> I'd like to try connecting directly to the bus as well, this
Folke> should work for the output part. For the input, I hope that there
Folke> is some bus command to disable automatic printing of the keyboard
Folke> strokes. Someone uploaded a ROM dump of the Wheelwriter's
Folke> firmware to that GitHub project, so with some reverse engineering
Folke> I hope to find such a command. Then I could directly connect the
Folke> Wheelwriter to the SoC without modifying the Wheelwriter
Folke> hardware.

I've been working on a similar project for a while. I am using a Teensy
to talk 9-bit serial (8051 uart mode 2 compatible).

https://github.com/RussellSenior/ww5teletype

The WheelWriter has some advantages and disadvantages as a teletype. On
the plus side, the user is assumed to want to see what they just typed
so the printing mechanism helpfully gets out of the way (as contrasted
with, say, another daisywheel printer like a DEC LQP02, which I've also
worked with). On the downside, the character set (both printing and
keyboard) are typewriter centric and is missing characters that would be
useful in a modern context, like ~, |, { and }.


--
Russell Senior, President
rus...@personaltelco.net

[Folke Will]

I've been working on a similar project for a while. I am using a Teensy
to talk 9-bit serial (8051 uart mode 2 compatible).

  https://github.com/RussellSenior/ww5teletype

Thanks for the link, that's very useful information! 

[Folke Will]

Hi all,

a small status update: The EAE and external memory implementations are completed and the interrupt controller is working as expected. The system already passes the relevant maindec tapes:

• 8i-D01C: Instruction test 1
• 8i-D02B: Instruction test 2
• 8i-D0AA: EAE test 3a
• 8i-D0BA: EAE test 3b
• 8i-D1HA: Memory extension address test
• 8i-D1GD: Memory extension control test

It does however not pass 8i-D1GB which appears to be another revision of the memory extension control test D1GD. The system passes the first iteration and fails on the second iteration. I believe this is related to the punch flag which is generated due to ringing the TTY bell at completion of the first iteration and never cleared, thus runing the interrupt inhibition test. I hope that this is some kind of known bug on the 8/I where the flag can't be cleared properly and D1GD was released as a fix. But unfortunately I didn't find any information about this except that D1GD is listed in the maindec index while D1GB isn't. Since the flag problem doesn't exist on the 8/E, the tape passes in Simh.

The system is also integration tested in VHDL: I created a test bench that integrates all CPU modules, executes a few instructions and checks against an expected output (see https://github.com/fpw/SoCDP8/blob/master/src/fpga/test/cpu/integration_test.vhd#L208 as an example).

I also implemented a kind of console multiplexer on the FPGA that can switch between the PiDP console and a virtual console. This allows the ARM code to emulate a virtual console - for example, it can temporarily turn off the PiDP console and issue coded switch pressing, LED checking etc. It also works in the other direction, i.e. the ARM can read the PiDP switches and control the LEDs. This will be useful to implement a "smoke test" for freshly soldered PiDP boards. Also, this new feature allows the system to work without the PiDP console and only using the FPGA board.

My vision for this project changed a bit: Instead of emulating the peripheral devices on an HDMI screen, I want to run a web server on the ARM and create a JavaScript interface to interact with the system so the users can use a browser to work with the system. The idea is to implement a few tutorials - starting with simple tasks like reading octal LEDs and entering octal digits on the switches to teaching the instructions and simple programs. Since the code can access the system bus, it will be possible to see if the user operates the system correctly.

In the end, I want there to be a few "labs" where the user has to solve tasks using the PDP-8. Since the peripherals can be emulated with simple code on the ARM, it's also possible to simulate peripherals in JavaScript that are connected to the system bus via web sockets or so. That way, it will be possible to create small playgrounds with animations, for example a railroad crossing that has to be controlled by the PDP-8 using IOT instructions. The challenge will not only be to solve the actual task but also to keep the system cheap - using extensions like the EAE, memory etc. will subtract virtual points based on the 70s price of the peripherals.

But all of that is a vision so far. But since the base system is nearly done, I'll start with the visual part soon.

[Folke Will]

Another status update, this time a big one -- I'm done with the nearly all of the hardware:

• Data breaks fully implemented according to the real schematics
• KT8/I time sharing option implemented
  
• CPU options such as number of additional memory fields and EAE and KT8/I presence now configurable at runtime. If memory fields are absent, correctly generate invalid AC values when reading. Passes the PDP-8/I memory test in all field configurations.

Also, I implemented the following peripherals using a hybrid approach. The bus connection is implemented on the FPGA and the interaction such as tape loading is implemented in software. This allows an easy changing of tapes through the browser app.

• KW8/I: Real time clock. Simulates 60 Hz ticks for now, will later be configurable for 50 Hz (based on the line frequency in reality).
• DF32: Small harddisk. Only basic read and write, no maintenance instructions.
  
• RF08: Bigger harddisk. Only basic read and write, no maintenance instructions.
• TC08: DECtape. Only basic read and write, no formatting instructions.
• PT08: Additional serial lines. Browser shows each connection as a custom terminal. Will later be able to connect to real UARTs or telnet.
• AS33 and TC08: Basic teletype and high speed punch / reader

The system can now run lots of software that I found. OS/8 runs smoothly and can run the adventure game in Fortran. I tried various things that are possible in OS/8, for example building the system from papertape on an empty harddisk or using it without harddisk by booting and running from DECtape, it's all working fine.

I also got TSS/8 to run which I think is a huge step forward. Getting it to run properly was a little hard: All the binaries I found online were compiled for a PDP-8/A or PDP-8/E. These systems have a different real time clock and use the BSW or KIE instructions, so wouldn't run on my PDP-8/I. However, the system does support the PDP-8/I. I was able to change the CPU variable in the TSS/8 source code and compile it for a PDP-8/I. And that version runs perfectly as it only uses PDP-8/I instruction and interfaces the KW8/I when compiled in that manner. I believe that TSS/8 was shipped by DEC in binary form and was tailored for the exact system of the customer.

The whole peripheral configuration such as the disk type are also configured in the source code, that's why I think so. I will probably create a mock Digital website where users can "order" a custom TSS/8 papertape set that's compiled for whatever configuration they want as an instant download. All I'm missing is the PUTR papertape. I was able to extract PUTR.SAV from the disk image using an old DOS tool called PUTR.COM, but I haven't figured out how to convert the SAV file to a BIN papertape.

Focal and BASIC are also functional in TSS/8.

Next, I will finalize the visuals and then the first release is almost ready.

[David Richards]

Next, I will finalize the visuals and then the first release is almost ready.

Gretings Folke 

Is it possible to build a  PDP-8/I  Z2 Pynq image from your Git repository yet?

Looking forward to being able to try this, I have a board and toolchain system waiting to try it.

Kind regards, David.

[Folke Will]

Hi David,

 

Is it possible to build a  PDP-8/I  Z2 Pynq image from your Git repository yet? 

Unfortunately, I haven't figured out how to integrate a Vivado project into a git repository yet. The project files contain absolute paths everywhere and a lot of temporary files are cluttered among the project directory. This is actually the main reason why I haven't done a proper release yet. The official suggested workflow is to export the whole project into a single TCL script that can be executed by Vivado to re-create the project structure, but that would also pack all the VHDL files into the TCL-ball and that kind of ridicules the point of using git.

However, all the sources are there so for now it might be an option to just re-create the project yourself. I will try to document the process on the Github page this week.

If you just want to try it - here's an SD card image: http://folko.solhost.org/socdp8/socdp8-image-pynq-z2.wic

The image can be written onto a micro SD card in the same way as the Raspberry image, e.g. using dd on Linux or some SD creation tool on Windows. Insert that into the Pynq-Z2 board, power up and the PiDP-8 console should immediately be ready. After about a minute, the web server is also ready. The first boot takes so long because SSH keys are being generated, etc. To use the web frontend, the board should be connected via LAN to a DHCP-enabled network prior to powerup. As soon as it's ready, you can access it via HTTP on port 8000 on the IP address assigned through DHCP.

Here's how the code in the repository is structured:

* src/fpga: Contains the VHDL and test code for the actual CPU and timing-critical parts of the peripherals. The CPU implementation is complete - including interrupts, data break, external buses etc. The register multiplexer hasn't been reviewed against the schematics yet, so there might be some small deviations. However, I haven't found any problems running various maindec diagnostics, OS/8, TSS/8, Adventure, Focal, BASIC, and other programs. Also, all switches and LEDs on the front panels should behave exactly as on a real PDP-8/I.

* src/server: Contains TypeScript code for NodeJS that implements the software part of the system, for example managing I/O of the peripherals, configuring the machine and things like that. This runs as a daemon on the ARM processor and communicates with the FPGA through memory-mapped I/O. It also offers a websocket API to connect with a frontend program.

* src/client: Contains TypeScript code to implement an app that can run in the browser. This app talks to the websocket API of the server so that the browser can basically communicate with the whole system, including the FPGA. Currently, the web app is rather basic. It misses the ability to configure the system at runtime, right now the peripherals are selected in the code. But the hardware is ready to be reconfigured at runtime. For example, how many core fields to enable, whether an EAE is present and things like that. It just needs to be integrated into the frontend.

* src/yocto: Contains layers for Yocto to build a custom Linux distribution for the whole system from scratch. It depends on the artifacts generated by the three parts above and creates a Linux environment containing all the programs at the proper locations etc. Its output is the SD card image linked above.

Note that the browser is completely optional, but it allows to use the system without the PiDP-8 panel and can also be used to load papertape, DECtape images etc. into the peripherals. The hardware buttons will be disabled as soon as you use the browser to toggle buttons.

Since the Pynq board has lots of free I/O, it's also possible to connect a teletype and a high-speed puncher / reader to the Arduino header on the board. Here's a video showinng my modified IBM Wheelwriter connected to the system running Focal: http://folko.solhost.org/socdp8/pdp8-focal.mp4

I'll really try to get the repository ready for release this week!

Regards

Folke

[David Richards]

Hi Folke,

Thank for sharing the image, I have it loaded and its running on the web interface just fine.

Very excited now - mainly about the birth of my new Grandaughter Sophia this afternoon though  :-)

I'll connect the Z2 board to my Pidp8i when I have figured how to use it.

I wish my wheelwriter could be interfaced witha single transistor but I think its the wrong model.

I'm experimenting with a Cadetwriter type interface for it from time to time.

Kind regards, David.

[Folke Will]

Hi David,

thanks for the feedback, glad that it's working out of the box!

 

Very excited now - mainly about the birth of my new Grandaughter Sophia this afternoon though  :-)

Congratulations! :-)

 

I'll connect the Z2 board to my Pidp8i when I have figured how to use it.

The PiDP-8 can be connected directly to the board through its Raspberry Pi header, it's pin-compatible with the original connector. Look at the Pynq datasheet to see the orientation of the connector (e.g. based on the GND pins). You can either connect it directly or use a cable like this: https://www.rasppishop.de/media/image/product/389692/lg/gpio-flachbandkabel-150mm.jpg

 

I wish my wheelwriter could be interfaced witha single transistor but I think its the wrong model.

I've got an IBM Wheelwriter 6781-2. I looked at the Cadetwriter and some other projects, but they required too many additional parts for my taste. I came up with a solution that only uses an Arduino Mega2560 board. It has a 5V controller and enough pins to directly connect it between the Wheelwriter's keyboard and its mainboard which also has a 5V logic.

This allowed me to interface the Wheelwriter to the board and to a UART from there with only two additional parts: The connectors for the keyboard cable. I basically removed the cables from the mainboard and connected them to the Mega2560 and connected additional wires from there to the mainboard and that's it. That approach should work for all Wheelwriter models.

 

Regards

Folke

[David Richards]

Hi  Folke,

Tonight I have been trying to get something working on the and have had some small success.

First I tried keying in a serial test program, is worked on the html console

from: http://dustyoldcomputers.com/pdp8/pdp8i/testprogs/ttysr.html

         0000 7200 cla          / clear accumulator
         0001 6046 tls          / dummy write (to clear flag)
loop,    0002 6041 tsf          / skip if flag set
         0003 5002 jmp   loop   / loop waiting for flag to clear
         0004 7604 las          / get character from SR into AC
         0005 6046 tls          / write character to TTY
         0006 5002 jmp   loop   / loop for next character

 I'd like to test the serial output from the Z2 but have no details yet.

Next I got my test tape image files from the PiDP8i.

I loaded the binloader and hello world using the HS loader

This worked , but I have not managed to run my Focal tape yet.

The procedure I used is shown below:

1) Stop processor if it is running, optionally clear core 

2) Store RIM HS loader

3) set arddress to 7756 and run

4) attach tape 'binloader.pt' to PC04

5) wait for lights to stop flashing

6) attach tape 'hello-pal.pt' to PC04

7) (not needed) press 'cont'

8) wait for flashing to stop

9) enter address 0200 and start

10) html console shows 'HELLO, WORLD!'

I'd like to output to the serial port, how can I do that?

I think Ive got a basic tape image somewhere too, perhaps on the Pi, and the source for the hello world.

It is a while since I used the PiDP8i

Kind regards, David.

[David Richards]

A little progress today,

I gave up using the binloader version of Focal and tried a rim loader version, this works.

Also I had made a mistake in the serial wiring and Focal now runs into a minicom terminal at 300 7E1

In fact Focal69 doesnt work properly at the html console as I get ?03.28 responses.

This doesnt occur in the serial console and there I can input commands, the responses are shown properly on both serial and html consoles.

Perhaps I can run an OS next ...

Kind regards, David.

[Folke Will]

Hi David,

glad that you were able to figure out the serial connection before I had time to reply! Meanwhile, I'm working on the web frontend to allow changing the machine configuration, the peripherals etc.

It will be possible to store different machine configurations, each configuration will have its own directory where the state (core memory, disk contents etc.) is saved so that one can quickly switch between different machines.

Also, I finally found a way to export the Vivado project in a way that it can be imported by others. I will document this and will let you know when the documentation is there.

Now, to the problems you mentioned:

• Web console: Since this is an emulation of an ASR-33, it only supports uppercase letters and control sequences. For that reason, I decided to use the shift key as a ctrl key. That way, the console can be used on mobile phones and tables without a ctrl key as well. So if you press 'a', it will actually send 'A'. And if you press shift+a, it will actually send ctrl+a. I hope this is the reason why Focal wasn't working using this console. Also, the 8th bit is automatically cleared on receive and set on send like on a real ASR-33. All these conversions are not done on the hardware serial port.
  
• Loading Focal: After loading the binloader using the rimloader the machine stops. You then need to set the switch register to 7777 (the address of the binloader), press Load Addr and then flip the first switch up again (to 3777) to indicate that you want to to load from the PC04 and not the ASR-33. Then press Start and wait until it stops, then press cont again until the lights no longer flash. This is to load multiple sections of a tape in case you are using Focal + Init.

[David Richards]

Thanks for the help, everything working properly now.

Here is a step-by-step instruction to load Focal69:

1) stop cpu

2) Store RIM HS loader

4) attach tape 'binloader.pt' to PC04

3) set arddress to 7756 and start 

5) wait for lights to stop flashing ( 3seconds)

6) stop cpu

6) attachh tape 'focal69.pt' to PC04

7) set address to 7777, load address

8) set address to 3777, start

9) wait for lights to stop flashing (25 seconds)

10) cpu should be stopped (check Run led)

11) set address to 7777, load address

12) set address to 3777, start

13) stop cpu

14) set address to 0200, load address

15) start cpu, dot prompt appears.

notes:

rim loader address 7756 to 7776

bootloader address 7612 to 7755

Over the weekend I unpacked my laser to make this protective cover using a design I found on Thingiverse.

here: https://www.thingiverse.com/thing:3972924

Its a bit difficult to see as the top part is transparent. I made a small modification to fill in most of the shield hole.

Looking forward to being able to try a disk based system, I have managed to load os-8 from mag tape now.

I just need the correct adapter to arrive to connect to the pidp8i, everything I have mirrors the pins incorrectly.

KInd regards, David.

[Steve Tockey]

Dave,

Technically, you should add step 10a) Check that the Accumulator is 0000. Any AC value other than 0000 means the checksum calculation failed so there must have been a tape read error. Also, Step 13) should not be "stop cpu". The CPU should stop itself when Binary Loader hits the second checksum on the Focal tape. It should be step 13) cpu should be stopped (check Run led) followed by 13a) Check that the Accumulator is 0000. Any AC value other than 0000 means the checksum calculation failed so there must have been a tape read error.

[David Richards]

Hi

Moving on from running os/8 from tape I'm now trying to build a system disk.

I'm using dec tape images from here for the source media

https://www.pdp8online.com/images/images/misc_dectapes.shtml

DEC-S8-OSYSB-A-UC1.tu56	1/18/74 M OS/8 VIII SYSTEM DECTAPE #1 TAPE 1 OF 2
DEC-S8-OSYSB-A-UC2.tu56	1/18/74 M OS/8 VIII SYSTEM DECTAPE #2 TAPE 2 OF 2

and building an image onto the RF08 disk.

I'm beginning to make progress but never having run the build process befor its a bit fraut.

I have managed to make a bootable disk but the only good file on it is build.sv

I think I doing something wrong with the pip commands, at first I didnt use the /I switch and the sizes came out at 1 block,

then I retried and the sizes are now all 5 blocks, I dont think either is correct.

When I try to run the programs from disk I get an error " BAD CORE IMAGE"

Perhaps /B is needed, I'll try again shortly.

transcript below (cleaned up a bit to remove deletions and mistakes)

Any advice gratefully received, thank you.

.DATE

SATURDAY APRIL 18, 1970

.R BUILD

$IN TC DTA0-1

$IN PT8E,PTP,PTR

$IN LPSV ,LPT

$IN KL8E,TTY

$IN RF08,SYS

$SYS RF08

$QLIST

DTA0 DTA1 RF08:SYS TTY PTP PTR LPT 

$PRINT

TC08:  SYS  

TC  : *DTA0 *DTA1  DTA2  DTA3 

TD8E:  SYS   DTA0  DTA1 

ROM :  SYS   DTA0  DTA1 

TD8A:  DTA0  DTA1 

TD8B:  DTA2  DTA3 

RK8E:  SYS   RKB0 

RK05:  RKA0  RKB0  RKA1  RKB1 

RK8 :  SYS   RKA1 

RK01:  RKA0  RKA1 

LINC:  SYS  

LNC :  LTA0  LTA1  LTA2  LTA3 

RF08: *SYS  

KL8E: *TTY  

KS33:  PTP   PTR  

PT8E: *PTP  *PTR  

LPSV: *LPT  

TA8A:  CSA0  CSA1 

VR12:  TV   

$BOOT

WRITE ZERO DIRECT?Y

SYS BUILT

.SAVE SYS BUILD

.

.RU DTA0 DIRECT

*

          

BUILD .SV  33 18-APR-70

 935 FREE BLOCKS

*^C

flush the disk and reboot into disk os/8

.

.RU DTA0 PIP

*SYS:CCL.SV<DTA0:CCL.SV

**SYS\SYS*\

*SYS:*<DTA0:*

ILLEGAL SYNTAX

*SYS:DIRECT.SV<DTA0:DIRECT.SV

*SYS:PIP.SV<DTA0:PIP.SV

*SYS:RESORC.SV<DTA0:RESORC.SV

*^C

.R DIRECT

BAD CORE IMAGE

.RU DIRECT

DIRECT NOT AVAILABLE

.RU DTA0 DIRECT

*

          

BUILD .SV  33 18-APR-70

CCL   .SV   1

DIRECT.SV   1

PIP   .SV   1

RESORC.SV   1

 931 FREE BLOCKS

*RU DTA0 PIP

The disk does boot and give a . prompt

I then try to copy some more files and it all goes wrong

After a reboot it gets corrupted and then back to rebuiling it again - I think that is because of the dodgy CCL.SV pperhaps.

All good clean fun, at least I got out on my push bike earlier. David.

[William Cattey]

I recommend:

al-4711c-ba-os8-v3d-1.1978.tu56

al-4712c-ba-os8-v3d-2.1978.tu56

You can find then via google search.

V3D has a lot more bug fixing and functionality.

Yes, you need to use /I to touch core images.

With v3d you have FOTP, the File Oriented Transfer Program.

(But I don't know if RF08 support was dropped from V3D.)

-Bill

[David Richards]

Hi Bill,

reading last night I realised I should be using fopt instead of pip.

I think ive found the reccomended tapes, regardless I now have a working disk image.

it says OS/8 V3Q when it starts. the files have a 1985 timestamp

I set the date on my system to 1992 because the days math this yeas days.

I needed to load the rf08 and pt8e handlers into the build.

Then I uses FOTP to copy the tape to the disk.

second time around I didnt overwrite BUILD.SV, doh.

Thanks for you help, David.

[David Richards]

I got some additional external files onto the disk by mounting a dectape image taken from simh.

I now have kermit.sv and e8all.pa on the disk.

I had wanted to create a new dectape image in simh but I'm having difficulty in formatting it. I get a setup? error for some reason.

I gaveup and copied the files onto the local.tu56 file instead.

The next problem to overcome is why does kermit and e8 both lock the simulation. I think this could be serial port related.

Kermit start but then the simulation freezes, similary E8 sends a clearscreen then freezes. 

In both cases I have to restart the pynq to continue.

I'll try some other programs instead, I see chess is on the tape.

Chess runs ok . David.

[Folke Will]

Thanks for your tests! I'm now finalizing the GUI for the release. This took a bit longer than expected because I also added a terminal emulation, but this now allows running the new E8 editor - see the attached screenshots. Also, the papertape reader / puncher is more visual now by showing the tape as it moves through the device.

The new version also allows managing multiple system configurations so that one can switch between an OS/8 or TSS/8 installation with a single click. 

[David Richards]

Very nice Folke,

The improvements will make operation very much easier.

I was thinking it would be useful to have an indication of when the dec tapes were being accesed.

Hopefully the system will work with real paper tape too, do you think it would?

I have a 2400 bps tape drive here which needs adjustment and testing.

Kind regards, David.

[Folke Will]

I was thinking it would be useful to have an indication of when the dec tapes were being accesed.

I'm in the process of adding the TC08 indicator panel for the DECtape controller and the indicator panels for the hard disks.  

 

Hopefully the system will work with real paper tape too, do you think it would?

 

Yes, in fact it already did in the last version. Just make sure to also connect the reader-run signal, it needs to go to the RTS pin of the reader. I've tested it with a GNT 4604 at 4800 baud, that's the implementation's default baud rate and can't be changed in the last version. But the next version will allow changing the baud rate. I'll also test it with a GNT 28 and an OP-80A. That's a reproduction of a classic DIY tape reader: http://jmprecision.co.uk/shopping/pgm-more_information.php?id=148&=SID

[David Richards]

Hi Folke,

The reader/punch I have here is a Data Speciaities NC-2400

I have made some progress repairing the tape punch today, it is back together and reading but there is one bit punch not yet behaving, so I shall have to dismantle it again.

At least I now know how to put it together, I was struggling with that before having to pack it away last year.

I also have one of those OP-80A tape readers, will your implementation work directly with it on its parallel bus? that would be nice.
Kind regards, David.

[Folke Will]

Hi all,

here's the first release candidate: http://folko.solhost.org/socdp8/socdp8-image-pynq-z2.wic

Note that there is no update function yet, so just overwrite the SD card for now.

Systems cans now be changed at runtime and multiple systems can be managed and their individual states can be saved. 

The default system now runs an installation of OS/8 V3, so just toggle in 7600 after booting and run OS/8!

Other changes:

 * the hardware UARTs are now on PMODB so that RS232 PMODs can be connected

 * the baud rates of the the serial port and PC04 can be changed at runtime

 * GNT28 and GNT4604 paper tape reader / punch stations tested and supported

 * default browser serial line now uses a terminal (xtermjs) that supports key input including ALT, CTRL and ESC keys right in the browser

 * can pop out individual peripherals to separate browser windows

TODO before release:

 * add a way to shutdown the underlying Linux system

 * document security implications when exposing the system to the net (comes with a default socdp8 / socdp8 account that has sudo permissions, so change the password)

Regarding the OP-80A: I haven't received mine yet, I'll see what I can do once it arrives.

[David Richards]

Marvelous Folke, Looks really impressive.
I was attempting to create a project using you .TCL script today but floundered wondering what directory to source it in or supply on the comman line.
I'll try this image with my tape reader. It's fully working now after fixing the missing punch hole this morning.
Kind regards, David.

[Folke Will]

I was attempting to create a project using you .TCL script today but floundered wondering what directory to source it in or supply on the comman line.

The TCL script must be run inside Vivado while no other project is loaded. Tools -> Run TCL script or something like that. The project script will create the project. After that, the block design can be imported in the same way by running that script. 

I think origin_dir in line 77 of the project script must be set to the parent directory of the directory that contains the git tree.

I haven't tested that process much and it still requires some manual steps after importing - creating a HDL wrapper for the block design and setting that as top module. 

Now that the release is almost done, I'll get this process tested and documented so that others can start hacking.

 

[David Richards]

Hi Folke, making a bit of progress with the new image now.

Below are some comments,

DECTAPE is working very nicely, I listed and loaded a file from the taped I made earlier without problem.

I have two serial ports connected and am able to use the console and send to the tape.

I havnt managed to read from the tape port yet, only write to it.

It appears as if the serial line parameters on the console and tape ports are always 7E1 is that correct and intentional?

Unfortunately my tape device is unable to work with parity set, it is 8 bit only with baud rates from 110 to 2400.

When I send a text file to the tape then the serial port shows the characters as sent, however the tape simulation window and created tape file have the high bit always set on, it this a system thing - something to do with PIP or what I wonder?

I have been using OS/8 command like these for my tests:

.R PIP

*TEST.TX<PTR:

^ (press esc now?)

^C

.TYPE TEST.TX

.R PIP

*PTP:<TEST.TX

The output below was captured during the transfer, at the same time the minicom connected to the PTP output showed ascii data at 2400:7E1

When I saved the tape file from the GUI  all the bytes have the high bit set on. If I mask the file to 7 bits then I can read the original contents.

Are there any requirements or capabilities on the RTS/CTS lines?

Is flow control implemented?

Great work, David.

On Sunday, 26 April 2020 19:54:23 UTC+1, Folke Will wrote:

I was attempting to create a project using you .TCL script today but floundered wondering what directory to source it in or supply on the comman line.

The TCL script must be run inside Vivado while no other project is loaded. Tools -> Run TCL script or something like that. The project script will create the project. After that, the block design can be imported in the same way by running that script. 

I think origin_dir in line 77 of the project script must be set to the parent directory of the directory that contains the git tree.

I thought it could be but wasnt sure and didnt try it. 

[Folke Will]

Hi David,

thanks for trying the new version!

It appears as if the serial line parameters on the console and tape ports are always 7E1 is that correct and intentional?

No, they are always 8N2 since all my old hardware uses that and it's basically compatible to 8N1 since the second stop bit can also be interpreted as idle and vice-versa. If 8N1 is explicitly needed, I could add that as well.

 

Unfortunately my tape device is unable to work with parity set, it is 8 bit only with baud rates from 110 to 2400.

That should work, I've tested all baud rates from 110 to 9600 with both of my readers.

 

When I send a text file to the tape then the serial port shows the characters as sent, however the tape simulation window and created tape file have the high bit always set on, it this a system thing - something to do with PIP or what I wonder?

OS/8 ASCII always has the 8th bit set to 1, at least in the versions I've tested. It is however also accepting terminal input where the 8th bit is not set. The option in the browser only applies to the browser terminal's output and is for less tolerant programs that require the 8th bit to be set. The browser terminal always discards the 8th bit on input.

 

.R PIP

*TEST.TX<PTR:

^ (press esc now?)

I always press enter, never tested if ESC works as well. The screenshot and your minicom experience can be explained with the information above. I could add an option to drop the 8th bit on the hardware UART if needed. Maybe using 7N2 in minicom does the trick as well - since the last bit is always high, it's the same as an early stop bit. Maybe that explains your success with 7E1?

 

Are there any requirements or capabilities on the RTS/CTS lines?

Is flow control implemented?

Yes, implemented and a good idea to at least connect CTS since the UART does not have any kind of buffer except for one register (just like on the real machine). CTS is actually the 'reader run' signal, it's also required to get the feature of a stopping reader when loading multi-segment bin tapes like Focal + Init. This is the main reason why I decided to implement a hardware UART instead of using USB converters - in my experience their internal buffers make them hard to use with RTS / CTS.

If RTS is not used, the PMOD pin should be left floating so that the pull down resistor pulls the the line to a state where sending is always allowed.

I'm using two of these adapters: https://reference.digilentinc.com/reference/pmod/pmodrs232/reference-manual

They are great because they have the RTS / CTS signals and the jumpers can also be used to short RTS to CTS.

[David Richards]

Hi Folke, thanks for the explanations. It looks as if should be able to use my tape punch after all then.

I have some similar handshake enabled RS23 convertors although I'm testing with USB adaptors at present.

I'll try again tomorrow, David.

[David Richards]

Hi Folke,

On Sunday, 26 April 2020 23:04:57 UTC+1, Folke Will wrote:

Hi David,

thanks for trying the new version!

A few notes about the latest version

1) This and previous versions get one of two MAC addresses when rebooted, a bit of a nusience with reserved IP address asignmment.

2) I cannot find a way to flush the RF08 disk, files get lost after a crash.

3) the latest (V9) version of the E8 editor crashes the simulation somehow and it becomes unresponsive. reactivation will restore it but the disk changes are lost.I'm using the disk image I made for the previous version of the soc. E8 V9 is very nice on the Pidp8 now.

4) The serial output has parity on my system, I know you say it is 7N2 but my soc has parity on output, input parity is ignored, screen output is garbled unless parity is enabled whatever format I choose, 7/8bit 1/2stop i ned to have even parity set. . I shall try again with windows realterm but got sidetracked with the black tape issue below.

5) I now have another paper tape problem. The punch is ok, but reading black tapes is problematic, white tapes are much better. The playback stops, I think the feed holes are not being seen. A bit of tension on the tape helps. I'm going to have to look inside and see if there are any adjustments possible. My camera can see all the light sources in the reader. nobody seems to have a manual for the DSI NC-2400

Sorry if this all sounds a bit negative, the system is fantastic actually.

I appreciate the opportunity to try the early releases.

Kind regards, David.

[Folke Will]

Thanks for your feedback!

1) This and previous versions get one of two MAC addresses when rebooted, a bit of a nusience with reserved IP address asignmment.

I've noticed that as well. The MAC address is stored in an I2C EEPROM on the Pynq board and I think the read times out on first boot. Will try to fix it.

 

2) I cannot find a way to flush the RF08 disk, files get lost after a crash.

There is a "Save State" button below the front panel. It saves all disks and the core memory to the SD card.  

 

3) the latest (V9) version of the E8 editor crashes the simulation somehow and it becomes unresponsive. reactivation will restore it but the disk changes are lost.I'm using the disk image I made for the previous version of the soc. E8 V9 is very nice on the Pidp8 now.

The system can't really crash since it's mostly hardware and not software. I can imagine that one of the software-implemented peripherals like the terminal emulation can hang. But in that case, pressing stop on the front panel and restarting from 7600 should do the trick. I'll try to reproduce this to see what's wrong. I tested E8 v7 successfully a few days ago.

 

4) The serial output has parity on my system.

That sounds very strange. It's definitely 8N2. The output is supposed to be garbage on a modern terminal because the 8th bit is always set, but that's due to the way how OS/8 deals with ASCII and not related to the hardware.

 

Sorry if this all sounds a bit negative, the system is fantastic actually.

Thanks! 

[Jack Rubin]

I've been running the new image for an hour or so and find it really impressive. The ability to run multiple screens is a very useful feature, as is the ability to configure and save a variety of machine configurations. I'm looking forward to the TC08 front panel, perhaps followed by a VC8/I implementation with joysticks attached to an A/D Pmod.

The shutdown feature would be handy as a button on the main menu panel that runs a background bash script. For now, I'm just using ssh to shutdown from the command line.

How will the serial port pinouts be arranged on the Pmod connector? Hopefully set up "over and under" so two ports can be wired into the one connector, allowing for terminal and punch/reader.

Having an true instruction-correct 8/I emulation is a really valuable addition to the simh 8/E-ish emulator.

Thanks!

Jack

*************************************

And a few more hours later, some wish-list items -

- labels for DECtape reels that indicate what tape is loaded

- ability to log terminal output to a file

- scalable browser windows 

- ability to save full emulation state (i.e. peripherals with loaded tapes, etc.) as well as CPU state

The more I use it, the better it looks!

[David Richards]

Hi Folke,

You are quite right and I was mistaking top bit set for party interpretation. There is something odd happening with Minico thouugh but Realterm shows the bytes and I can see what is happening now.

On a related matter, If I punch a tape with text am I expected to punch the top bit on every byte set it it normal to only punch 7 bits (I would assume this is the case but I have no text tapes to check on). Binary tapes obviously use all 8 bits anyway. There is no option in the tape machine to choose 7 bits though so any text tapes I create with the simulator will have to have top bit on. I guess playback will then ignore the extra bit and everyting will be ok. Seems wasteful of holes though!.

Over the coming days I shall try and get a reliable tape read working.

How does your tape device do things with 7/8 bit text?

My interest in thes devices stems from trying to get real vintage devices working. I have had access to terminals and teletypes working connected to PCs, but the real object is to get them working with actual vintace processors.

I would like to know how a teletype responds, does it accept 8 bit data and interpret it as 7 bit? Are typed characters presented withthe top bit set? I'm going to have to find out when the time comes to interface real devices to a real PDP8, if and when I get it working.

Kind regards, David.

[David Richards]

Some answers to my own questions found here:

http://homepage.cs.uiowa.edu/~jones/pdp8/faqs/

and here:

http://homepage.cs.uiowa.edu/~jones/pdp8/refcard/65.html

you live and learn ...

[Steve Tockey]

David and all,

Just as a FYI: Teletypes (e.g., ASR-33, KSR-35, etc) were not actually originally intended to be computer peripherals. They were later adapted into that role from their original intended use in the TELEX network (see, for example, https://en.wikipedia.org/wiki/Telex). In AT&T's "Teletypewriter Exchange Service" (TWX) version of TELEX, the signal carrier was contemporary unconditioned phone lines. In that noisy environment, the parity bit was important to help the hardware figure out if characters were garbled by line noise or not.

As a computer peripheral, the connection between the terminal and the computer is usually so noise free that the parity bit becomes unnecessary, freeing it for other use. Some connections--like phone modem-based remote connections--continue(d) to use the parity bit as originally intended, but to everyone else it became an otherwise unused bit so people started finding uses for it.

IIRC, setting an ASR-33/-35 or KSR-33/-35 Teletype to Even, Odd, No, or Mark parity is a hardware setting inside the TTY. I would have to find my old ASR-33 manuals to verify (I think I kept a set of manuals, but unfortunately tossed the ASR-33s 22 years ago--sigh).

So if you have a real ASR-33/-35 or real KSR-33/-35, it may have been configured for Even, Odd, No, or Mark parity depending on if it was built for computer peripheral use or for use in the TELEX network.

That said, OS/8 and code developed for PDP-8 terminal I/O is usually designed to ignore the parity bit by either masking it off (forcing No Parity), or forcing it set (forcing Mark Parity) irrespective of what the physically connected terminal sends in the high bit. The big exception to this, however, is RIM and BIN Loader format paper tapes where that top bit is used for leader/trailer code. BIN Loader also encodes Change Field settings by setting both the top and second-to-top bits with the field number in the three next less significant bits.

When you connect to a terminal without any paper tape reader-punch capability (real or simulated), you can safely use either 7B or 8B, it really shouldn't matter with most appropriately-written PDP-8 software. On the other hand, if you are connecting with the expectation of using paper tape (e.g., PTR:, PTP:, or to an ASR-33 or -35 as opposed to a KSR-33 or -35) on that channel then you do need full 8B and without hardware-driven parity, otherwise RIM and BIN Loader won't work.

In case you didn't know, the "ASR" in ASR-33 and ASR-35 meant "Automatic Send Receive" while "KSR" meant "Keyboard Send Receive". The KSR version does not have the tape reader / punch, the ASR version does.

[richard...@gmail.com]

Greetings,

I see low cost 7010 boards available on AliExpress, some information here:

https://github.com/xjtuecho/EBAZ4205

Interesting to see if one would be suitable for SOC-DP8 or anything else really, at around £12 delivered its tempting to try.

Kind regards, David.

[folke...@gmail.com]

Hi David,

 

Interesting to see if one would be suitable for SOC-DP8 or anything else really, at around £12 delivered its tempting to try.

interesting little board! The project does run on a Zynq 7010, I already tried it on a Zynqberry which is a 7010 board in the Raspberry Pi's form factor.  However, I'm not sure if you could connect the PiDP-8 console to the EBAZ board. 

I worked quite closely with Charles on the SoCDP8, he was a kind of mentor for me since I didn't have any PDP-8 exposure prior to this project. After his passing, I took a step back from the project. But I'm sure I'll continue working on it next year.

Regards

Folke

 

[richard...@gmail.com]

Hi Folke,

I saw there was a project for 7010 so I took the plunge and ordered a board anyway. I'll have a count up of the available i/o.

I'm not too bothered about that though as most of the time I use the PC GUI, its very good.

A simplified console would be an alternative, a bit like on an 11/20 with some 7 segment leds and a keypad.

I tried something like that on my unibone using iic / spi breakout boards.

The community lost of lot when Charles died.

Kind regards, David.

[atreu...@gmail.com]

I am having a wrasseling match with getting SOCDP8 to compile in Vivado.  There is no asr33.vhd, so I had to comment things out to get import to run.  Got thru creating an HDL wrapper.  But there seems to be issues in io_controller.vhd.  Some things are not defined.

Synth 8-2398] near string "000011" ; 6 visible types match here ["/home/atreubig/pynq-z2/pynq-z2.srcs/sources_1/imports/fpga/rtl/io/io_controller.vhd":161]

[Synth 8-944] 0 definitions of operator "+" match here ["/home/atreubig/pynq-z2/pynq-z2.srcs/sources_1/imports/fpga/rtl/io/io_controller.vhd":193]

[Synth 8-2396] near character '1' ; 3 visible types match here ["/home/atreubig/pynq-z2/pynq-z2.srcs/sources_1/imports/fpga/rtl/io/io_controller.vhd":213]

[Common 17-69] Command failed: Synthesis failed - please see the console or run log file for details

Aug

[atreu...@gmail.com]

Progress.  The errors were traced to tc08.vhd being missing from tcl import script.  Now to figure out importing pin assignments.  

Which I think is my next error mess.   

Aug

[atreu...@gmail.com]

All now working.  Driver/reader error.  Missed setting top module.

Aug

[atreu...@gmail.com]

My board finally came today.  I loaded the image and after some head banging, I got focal.pt to load. Thanks for the shortcuts.  Also the OS/8.  Now to put a better OS/8 on it.  Eventually the front panel.  

Aug

[William Cattey]

The trunk release on tangentsoft.com has the latest OS/8 V3d Combined Kit built from source, and all sensible patches applied.

When the build is done, you opt into ock.rk05

[atreu...@gmail.com]

I am not having much luck with an RK8 boot.  A snippet for the boot would be helpful.  I found where the image goes and the correct name.  

Aug

[William Cattey]

The top level README page documents the "--use-ock" configuration option.

If you build with that option enabled then all the startup scripts (including the helpful, 'make run' command line you can use from the build root) will use ock.rk05 instead of v3d.rk05.

Alternatively, you can tell simh to detach the default v3d.rk05 and boot ock.rk05 as follows:

make run

^e  (to get to simh)

detach rk0

attach rk0 bin/ock.rk05

boot rk0

Have I understood your question, and been helpful?

[William Cattey]

Oh wait. Re-reading the thread, and your question, I see that I have missed the point.

I do not know how you connect the ock.rk05 image up to your emulated RK05 device.  But if you've got an RK8e emulator, and you've got the image in place, the RK8e bootstrap comes from page 1-27 of the 1974 OS/8 handbook:

0030     6743

0031     5031

When you start the machine at location 30, it executes the "Disk address load and go" RK8e instruction and loop until the drive overwrites what's in location 0031 with the boot block, and vroom! You're booted into OS/8.

-Bill

[folke...@gmail.com]

I am not having much luck with an RK8 boot.  A snippet for the boot would be helpful.  I found where the image goes and the correct name.  

Did you use a pre-built RK05 image? That won't work: The SoC implements an RK8 [1] controller, not an RK8E. The PDP-8/I doesn't have an omnibus, so it's not compatible with the RK8E. And the RK8 doesn't support RK05 disks, it uses RK01 disks. I'm not sure if there is a way to connect a RK05 to a real PDP-8/I. If there is, I didn't implement it. I know that RK05 is the most common format to exchange disk images, but since I implemented the actual circuit of the PDP-8/I, I would still need a compatible controller that doesn't use features that only exist on Omnibus, most commonly the IOT instruction with zero op bits set.

 

To use OS/8 with an RK8, you could load OS/8 from DECtape or paper tape and then use the BOOT command to initialize the RK8. After that, the OS/8 files can be copied to the disk. I could show all the commands for this if desired.

[1]: http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/disc/DEC-00-HRKB-D_RK8_Disk_System_Maintenance_Manual_Oct71.pdf

[Michael Thompson]

> On Jan 16, 2021, at 7:55 AM, folke...@gmail.com <folke...@gmail.com> wrote:
>
> Did you use a pre-built RK05 image? That won't work: The SoC implements an RK8 [1] controller, not an RK8E. The PDP-8/I doesn't have an omnibus, so it's not compatible with the RK8E. And the RK8 doesn't support RK05 disks, it uses RK01 disks. I'm not sure if there is a way to connect a RK05 to a real PDP-8/I.

You can install a DW8E chassis in a PDP-8/I to add an Omnibus. It is invisible to the software. You can then install a RK8F controller and then RK05 disk drives. You can also install an RX8E controller with RX01 or RX02 diskette drives with the DW8E. OS/8 works fine with this configuration.

[August Treubig]

Yes, I am trying to use the image Bill Cattey is referring to from the Pidp8 build.  So I guess I will figure out how to copy it to the correct format in simh first.  

A boot snippet for the RK8 would be nice.  Also am trying to follow your node js build.  Am having to learn TypeScript/node.js.   

Aug

Sent from my iPad

On Jan 16, 2021, at 6:55 AM, folke...@gmail.com <folke...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/acddfff8-021e-4d99-8007-20520eb72b8fn%40googlegroups.com.

[William Cattey]

Aug,

Note that the image I built is configured for an RK8e controller.  I expect that one needs to run BUILD and create a wholly different system image with the RK8 driver (if the later OS/8 actually kept it available.)

[Rick Murphy]

You can't convert a bootable RK05 OS/8 image into a bootable RK01 disk. The system handler is quite different as the IOTs are different.
SIMH doesn't support the RK08. so you can't use that to build an image.

As suggested earlier, you'll need to use a bootable OS/8 DECtape and build a system for the RK08/RK01.

Booting the RK08, stolen from the rk08sy.pa file:

/THE BOOTSTRAP FOR THE RK8 IS AS FOLLOWS: (UNIT 0)
/       LOCATION        CONTENTS
/       30              6733
/       31              5031
/LOAD ADDRESS 30 AND START

/THE BOOTSTRAP FOR OTHER UNITS IS AS FOLLOWS:
/       26      7604
/       27      6732
/       30      6733
/       31      5031
/LOAD ADDRESS 26, PUT UNIT NUMBER IN SWITCH REGISTER BITS 9-10,
/CLEAR, CONTINUE

    -Rick

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CD87AB89-DCCE-40ED-8DC0-C3F9643A8428%40gmail.com.

--

Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA

[folke...@gmail.com]

You can install a DW8E chassis in a PDP-8/I to add an Omnibus. 

Thanks for the hint! I was aware that the converter exists, but I thought it was mainly an electrical converter without support for 6xx0 instructions. But after reading its manual and the RK8F manual, I now understand how it's possible to add an RK05 to an 8/I. I will probably implement this when I get back to working on the project.

 > A boot snippet for the RK8 would be nice

Will post one later. The basic steps are:

• load OS/8 from DECtape
• use the BOOT command
• load the RK8 driver from the 2nd tape (depending on the OS/8 version)
• configure according to the machine, i.e. adding the RK8 driver to the system
• also, use the proper ASR33 driver, not the 8E terminal 
• when done, BOOT will write the system to disk
• after that, use PIP or so to copy all files from tape 1 to disk
• boot using the RK8 loader (snippet present in the snippets menu)

[August Treubig]

Yes,

The RK8E would make things much easier and more folks would be interested.  I will work on building from dectapes.  There are examples of that out there.

What size should the disk be made for the rk01, or will it magically be made?

Aug

Sent from my iPad

On Jan 16, 2021, at 12:01 PM, folke...@gmail.com <folke...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/ad3b662d-22f6-4cc8-b0ed-53cc9ccd5c0bn%40googlegroups.com.

[folke...@gmail.com]

  Here are the instructions to load OS/8 on a new RK8 drive in SoCDP8:

• configure a machine with an RK8, PT08, PC04 and TC08 (see screenshot)
• load DEC-S8-OSYSB-A-UC1 in tape drive 1 and DEC-S8-OSYSB-A-UC2 in tape drive 2
• use the snippets menu to load the TC08 loader into core while the system is stopped
• load 7613 and run, after a while you should see the "." prompt of OS/8
• run: RU SYS BUILD
• the prompt should change to $

Now:

$ INS RK8 SYS

$ INS TC:DTA0,DTA1

$ INS PT8E:PTP,PTR

$ LOAD DTA1:ASR33

$ INS AS33:TTY

$ CORE 7

$ DSK=SYS

$ QLIST

> DTA0 DTA1 RK8:SYS PTP PTR TTY 

> CORE= 7

$ BOOT

> WRITE ZERO DIRECT?

Y

> SYS BUILT

Now the disk is initialized, but empty. First, save the still loaded BUILD program into BUILD2. Then copy all files from tape to disk (this will write the original BUILD from tape without our changes). Finally, copy BUILD2 to BUILD and delete BUILD2:

.SAVE SYS BUILD2

.RU DTA0 FOTP

*SYS:<DTA0:/L

^C

.GET SYS BUILD2

.SAVE SYS BUILD

.DEL BUILD2.SV

The system is now ready. I suggest to click "Save State", this writes the core memory and disk images to the SD card so you can always resume from this state by executing 7600.

[atreu...@gmail.com]

I was able to follow your instructions.  And have a running RK8 system.

But will be looking forward to the RK8E one someday.

Thanks

Aug