Status lights don't seem to work when depositing command?

[kber...@gmail.com]

Hi All,

I am working thru and checking to see how the front panel is working when entering a simple Assembly Language Program.  When I enter the program codes it does not show the status light (box on right-side of panel) associated with the command during the programming, but does show the light when the program runs.  My program is:

Address 10(octal)

7001

2034

5011

5010

When I enter 2034 the light Isz does not light up, but does when I run the program.

When I enter 5011 and 5010, again the Jmp light does not light up when loading the command but it does when I run the program.

Any reason for that behavior?  I have seen on a video where the type of command is reflected when entering (i.e, Isz, Jmp, etc) the command.

Thanks, Kent.

[Steve Tockey]

Two reasons, I think. One is that there are multiple versions of the DEC PDP-8 and they operated differently in this respect. I owned a "classic" PDP-8 for many years and it had the behavior you are asking about. On the other hand, the -8/e I still own has never behaved like that.

Another reason is that there are multiple versions of the PiDP-8/i SIMH code. The behavior you are talking about from the video was in the very first version (i.e., 2015 or so) but has not been in any of the later versions (2016, 2018?, 2020-ish).

Essentially, while the PiDP-8/i has a front panel that looks like a scaled down PDP-8/i, the SIMH implementation it runs under the covers is actually more of a pdp-8/e.

-- steve

[Heinz-Bernd Eggenstein]

The real PDP-8i really didn't update those lights, see this video:  https://www.pdp8online.com/pdp8i/videos_f/pdp8i_boot.mp4

But just to make sure: What about pressing the examine key on the real PDP-8i? Are the IR lights updated or not? From block diagrams in the maintenance manuals I get the impression that the IR instruction register is only written to when data is READ from the core memory, not when it's written, so I can understand why those lights will not get updated when depositing data. But when examining data, it would have been both easy and perhaps also useful to implement an update of the IR lights, so I wonder whether PiDP-8 i is accurate here as well in not showing any updates?

HB

[kber...@gmail.com]

Thanks Steve, and HB. 

It has been quite a while since I loaded the software into the Pi.  So, I can remember which version that I used, and it looks like there are new version on the software page.  I am a real neub at computers and basically followed instructions and got it running.  So, since I entered the program successfully and it is running, I will take the win, and keep using it.  I mainly program form the terminal, which seems to be working fine.

At some point I want to learn how to do the thumb-drive disks, which I never got the hang before, but may take that challenge up again.

Thanks again for your help.  I had forgotten how much fun this machine is, but it has quite learning curve.  At least for me.

Kent.

[Steve Tockey]

Kent,

Regarding the thumb-drive disks, they are actually pretty easy to use. But also, you can have RK05, RX01, RX02, DecTapes, and paper tapes as simulated media NOT on thumb drives. I do lots of access to these extra devices without involving thumb drives, they aren't necessary. All you need to do is type CTRL/E to drop into SIMH. From there, issue the appropriate "attach" command, then type "go" to return to the PiDP-8/i.

For example, I added a new directory, /opt/pt. This is where I keep all of my simulated paper tape images. All I need to do from OS/8 on the PiDP-8/i is:

.<ctrl/e>

simh> attach ptr /opt/pt/mypt.txt

simh> go

.

You are now back on the PiDP-8/i in OS/8 with the pseudo-paper tape file /opt/pt/mypt.txt in the PiDP-8/i PTR: paper tape reader. Now you can:

.COPY MYPT.TX<PTR:

^

The ^ is the OS/8 prompt from the PTR: device handler that tells you to load the physical paper tape but it's already been loaded. Just hit any key to continue.

You can write a paper tape image from the PiDP-8/i and OS/8 as follows:

.<ctrl/e>

simh> attach ptp /opt/pt/mynewpt.txt

<if that file didn't already exist, you'll get a message that SIMH created it>

simh> go

.COPY PTP:<AFILE.TX

FILES COPIED:

AFILE.TX

.

The only gotcha is that now you have to CTRL/E back into SIMH and detach the image file:

.<ctrl/e>

simh> detach ptp

simh> go

.

If you don't explicitly detach the file, *nix won't recognize it. Once detached, /opt/pt/mynewpt.txt will contain the contents of OS/8 file DSK:AFILE.TX. Unfortunately, you won't be able to see those contents as if it were a real *nix .txt file (e.g., using the text editor). But you will be able to read it back in to OS/8 as a simulated paper tape by doing the attach ptr /opt/pt/mynewpt.txt command. And, if you make a regular .txt format file in Raspbian then read it in as a simulated paper tape image, OS/8 will have trouble with the end-of-line. It's an easily solvable problem if you want to know how to fix it later.

I also have a /opt/dt directory for DecTape images and /opt/rx for floppy disk images. So, for example, I can:

.<ctrl/e>

simh> attach dt0 /opt/dt/mydectape.dt

simh> go

.DIR DTA0:

My experience is that you don't need to explicitly detach disk and DecTape images, SIMH updated the *nix file as the PiDP-8/i does the writes.

Enjoy,

-- steve

[William Cattey]

Hi Steve,

As I was implementing the python expect-based driver for "build to order media" I discovered that sometimes YES you need to detach the media explicitly before quitting SIMH. Otherwise the buffered last write may not be  committed.  When I made sure the scripts cleanly detached every image after working with it, the number of mysteriously corrupt media went to zero.  :-)

-Bill

[Ian Schofield]

Dear All,

 1. Thanks HB for the link to the video. This is most useful in regard of the boot and keyboard idle loop for (in this specific case) the 4K DMS.

  2. I would agree with all of the comments in that the status lights during examine/deposit might not be correct. This is a specific to the Simh implementation and could be updated.

  3. There has been some old discussions about the light pattern stability as in flickering in the keyboard idle loop for example. This video clearly shows a steady light pattern (right at the end of the video).

  4. The next point is the brightness ration of the JMP and IOT lights during the keyboard loop. They are not the same. This is due to an IOT cycle lasting longer than a JMP instruction as an IOT cycle contains IOP 1/2/4 after TP3.

      Again, Simh is not correct in this context.

 To give an example fix for 3/4 above, here is a patch file against pdp8_cpu.c which you can try if you wish.

BW, Ian.

[Steve Tockey]

All,

If you are going after high realism, have you throttled SIMH? Unthrottled, the PiDP-8/I runs much faster than actual -8 hardware. How much faster depends on the specific model of Pi you are using. I'm running on a Pi 3B+ and it's in the neighborhood of 5x faster than a real -8/I. If you:

<ctrl/e>

sim> set throttle 360k

sim> g

then it will run about as fast as a real  -8, -8/I, -8/L. Setting throttle to 416k will run it at about the speed of a real -8/e, -8/m, -8/f. If I recall, setting throttle to 12k will run it at about the speed of a real -8/s.

You can also add the set throttle command to the boot script.

Cheers,

-- steve

[Heinz-Bernd Eggenstein]

When you install the pidp8i software from source code as described here:

https://tangentsoft.com/pidp8i/wiki?name=Home

you have the option to configure your own favorite throttling settings, which then will be conveniently written to *all* of the boot scripts that come preinstalled with the PiDP-8i software, details are here:

https://tangentsoft.com/pidp8i/file?name=README-throttle.md&ci=tip

As you can by the lengtht of this file, throttling in SIMH is a bit of a science ... or magic perhaps.

HB

[Steve Tockey]

HB,

Thanks for pointing that out. It looks like a nice, convenient addition for most users. On the other hand, I've never personally thought it was a big deal to just edit the boot scripts myself. I've done it many times already. As well, I am avoiding the 20210214 release because its MB behavior is completely wrong. For now I am happy staying with the previous release.

Also, later on the Throttling page it says, "I'm not aware of a way to make SIMH slow the other I/O operations, such as disk access speeds, in order to emulate the speed of the actual hardware" in the I/O Matters section. I'm pretty sure there's no way to do it at the SIMH/boot script/user level. But, if you're willing to edit the PDP-8 emulator source code it is possible. SIMH uses function sim_activate() to schedule processor events with the second parameter being the delay until that simulated event happens. You just need to work out what new value to use. Using 1387 for PTR: runs it at 300 characters per second and using 8320 for PTP: runs it at 30 characters per second. This is the speed of real PT8E hardware. It makes for really nice blinkenlights in the AC when simulating read-write on PTR: and PTP:--smile.

Cheers,

-- steve

[folke...@gmail.com]

Hi all,

as was pointed out, SIMH simulates a PDP-8/E while the PiDP-8 has the front panel of a PDP-8/I - and that machine actually behaved differently.

For that reason, I decided to take a different approach than a Raspberry Pi with SIMH. Instead, I attached a Zynq SoC (FPGA / ARM on a single chip) to the PiDP-8 and implemented all the original schematics of the PDP-8/I in VHDL. So instead of observing and re-implementing the behavior of the machine in software, I implemented the original schematics in hardware. That way, the behavior should match the original PDP-8/I very closely in terms of speed and behavior.

Since CJL passed away, the project is somewhat paused - but it was actually almost done and can run Focal, OS/8, TSS/8, pass all the PDP-8/I MAINDEC tapes, load DECtapes, etc.

If you just want to see how the lamps originally behaved, you can try all of that in my implementation. You can reconfigure the hardware options at runtime, e.g. configure if and how much additional core memory you want. Then you can see how the DF and IF lamps react and what happens if you load something even though there is no core memory attached and things like that.

I suppose you don't have a Zynq SoC board there for testing, but the project is actually network-enabled and has a web frontend that allows you to watch and control the system from your browser. I've booted up my board now and exposed its port to the web in the hope that you find it useful:

http://fb.solhost.org:8000

Note that everything you see ends up in actual hardware, so only one person can really use it at a time. There is no mutual-exclusive access system since it's supposed to be used on a LAN only, so please make sure that you're the only operator before interacting with the system. Maybe use the STOP / RUN switches to indicate if you're currently using the system.

Also note that other connected users can see the same state, so if you decide to play with the OS/8 system that's currently running there, other connected users can see what you're doing on the terminal. And it's also shown on my connected PiDP-8 board. I turned off the paper tape punch and reader, though, so that only happens in the emulated browser peripherals :-) But it's already possible to connect real terminals, paper tape punches and things.

I'll leave the board running for a few days.

Hope that helps,

Folke

[William Cattey]

That's really cool! I'd very much like to have a "real" PDP-8/i in my PiDP-8/i.

Is there documentation somewhere on how folks like myself might build such a board?

How do you get software onto the system?  I'd be very much interested to know if the virtual packs I've created work on something other than Emulated in SIMH.

-Bill

[folke...@gmail.com]

That's really cool! I'd very much like to have a "real" PDP-8/i in my PiDP-8/i.

Thanks! That's exactly the feeling that made me come up with this idea.

 

Is there documentation somewhere on how folks like myself might build such a board?

The project's page is basically this: https://github.com/fpw/SoCDP8

Currently, there are two supported boards, the Pynq-Z2 and the Zynqberry. But a user on this list also ported it to the $5 EBAZ4205 board, I just didn't integrate his port yet.

 

How do you get software onto the system?

For now, you can use the papertape reader or the DECtape by uploading images through the web interface. The formats are the same as for SIMH.

The system also uses harddisk images in the background, but not compatible to any format used by SIMH, that's why there is no option to upload or download harddisk images yet.

[timr...@gmail.com]

Yes, that is quite fascinating.  I'd like to hear more.

[HB Eggenstein]

But I guess even this gate-exact emulation will not generate the RFI necessary to reproduce playing music on the PDP-8? Perhaps if one knew which signal lines need to be exposed to external GPIOs and putting some extra "antenna-wire" on them?

Some music playing software is curated here: https://tangentsoft.com/pidp8i/dir?ci=tip&name=src/music

Somehow etting this to work would be the ultimate PDP-8 emulation stunt IMHO.

HBE

[William Cattey]

In December 2020, Warren and I were chatting with Kyle Owen who had cooked up a fork of SIMH that could play music.

The discussion was tracked in the tangentsoft forum at: https://tangentsoft.com/pidp8i/forumpost/beadb05101

The effort stalled, I think, when we couldn't agree on an approach that could be upstreamed back to stock SIMH.

-Bill

[Mike Katz]

Andy Geppert at www.core64.io is making a small interactive core memory kit.  Myabe we can connect that to the Pi via I2C for the core memory music generation.

--
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/17c708ee-0912-4f64-a42e-4502baa3f527n%40googlegroups.com.

[William Cattey]

The RFI wasn't from core memory. It was from the CPU/Bus.  The traditional instruction to "beep" was CAF, which sends a big reset to the bus.

[Mike Katz]

I honestly thought it was the turning on and off of the magnetic fields in core memory. 

You're never too old to learn something new.  🙄

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/8d63d377-e3b4-4483-b06d-0dfabebaa1aan%40googlegroups.com.

[timr...@gmail.com]

I thought that too.  Well, dangit.  I learned something new today.

[folke...@gmail.com]

But I guess even this gate-exact emulation will not generate the RFI necessary to reproduce playing music on the PDP-8? Perhaps if one knew which signal lines need to be exposed to external GPIOs and putting some extra "antenna-wire" on them?

That's a great idea, I'll try that. I think by connecting the correct internal signal to a GPIO and connecting a wire to it, it could work. I think it was the INITIALIZE signal that's generated by the CAF instruction. That signal resets several flipflops at once and thus generates lots of noise. Unfortunately, the 8/I does not have this instruction. But I'll research what the 8/I circuit actually does when 6007 is issued, maybe a simple AND gate on the internal IOB network will do the trick to get a signal that's raised with CAF.

I hope the music program doesn't use any other 8/E-only instruction like BSW. These would not be as easy to implement in an 8/I since the register network doesn't have the required transfers, and I wanted to keep the circuit as original as possible.

I think I would prefer the approach of using a new "music player" implementation for the 8/I that uses a different method to generate the interference using methods that would also work on a real 8/I, but I'll see what I can do.

 

[Rick Murphy]

The MUSIC program has a single instruction that generates the noise. As noted, that's a CAF which is 8/E and 8/A only. The location of that is documented and can be easily patched.

At one point, I ginned up a simple interface that toggled a flip-flop whenever a particular IOT was used, patched MUSIC to use that, and output that flop to an audio amp.

Really didn't sound all that much better than the radio near the 8/E. :)

    -Rick

--

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/d86949b3-02f1-4757-aef8-9a17c5319b1dn%40googlegroups.com.

--

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

[William Cattey]

Yes. The source code in MUSIC.PA says:

IFNDEF NOISE <NOISE=CAF>

        /FILL IN THE SINGLE CYCLE INSTRUCTION WHICH IS

        /TO BE USED TO CREATE NOISE.  FOR 8/E OR 8/A WITHOUT

        /AN RX01, TRY CAF.  FOR OTHER SYSTEMS, TRY IOF.

        /DO NOT USE AN INSTRUCTION WHICH TAKES LONGER

        /THAN 1.5 MICROSECONDS.

So the noise instruction on an 8i is probably IOF.

You can find the source to MUSIC.PA that's integrated into the tangentsoft release at:

https://tangentsoft.com/pidp8i/dir?ci=tip&name=src/music

-Bill