PDP-8/E Simulator 2.4 plays music

[Bernhard Baehr]

Based on an idea of Kyle Owen who added music capabilities to SimH (https://github.com/drovak/music) and inspired by the wonderful 50th anniversary clip by Volker Herrmann (https://www.youtube.com/watch?v=39ZCb65plIQ), the PDP-8/E Simulator now has a Music Player plug-in that makes audible the tunes played by the PDP-8 Music Playing Program (DECUS 8-804, http://www.pdp8online.com/miscdocs/DECUS/Decus%208-804_MUSIC-PlayingProgram.pdf).

The Music Player adds an other Switch Register option to MUSIC.SV: SR(1) switches from PDP-8 time sampling of the CAF instruction (for crystal clear sound) to real time sampling (resulting in more or less noise, depending on the timing precision setting of the simulator).

On the OS/8 System Disk of the simulator distribution you find MUSIC.SV and on the second partition the known music files.

For PDP-8 newbies, the quickstart for the simulator describes how to play music, see https://www.bernhard-baehr.de/pdp8e/quickstart20.html#music.

As always, adding new features helps finding old bugs. In this case, the simulator ran a little bit too fast on Macs with Apple silicon (caused by rounding errors converting Mach absolute time to nanoseconds), causing the audio buffer to overflow and the music to skip. And with the TC08, an UI update notification was posted too often when the PDP-8 executed CAF in high frequency, causing a lockdown of the UI. A half-dozen other minor bugs are eliminated, and some pixel alignments in the UI were optimised.

And thanks to Don Baccus (https://groups.google.com/g/alt.sys.pdp8/c/T4RbTxzmaBk/m/gc2KWqNBBwAJ), a thirty year old bug with the rarely used microprogrammed operate instructions 7264 (CLA CMA CML RAL), 7266 (CLA CMA CML RTL), 7270 (CLA CMA CML RAR) and 7272 (CLA CMA CML RTR) was fixed: until now they didn’t perform the CML.

Visit https://www.bernhard-baehr.de/pdp8e/pdp8e.html to download the new version.

Bernhard

[Don Baccus]

Sounds like fun!

[Don Baccus]

Well, I've been having fun building myself a tool to make it easy to move things back and forth between my
OS/X host environment and OS/8 device image files.

I prefer using my native editing tools I'm used to rather than relearning TECO (despite my being one of the
OMSI brats that typed up Russ Hamm's original PDP-8 TECO, interfaced it to PS/8 before it was officially
released thanks to an early tape from Richie Lary, sped it up by a factor of three, then gave it to DEC
where it became OS/8 TECO).

So I wrote this thing I've called os8pip. I've tested it on Mac, and Vincent Slyngstad has it compiled with
gcc on (I think?) a windows block and will try it out.

This lets one directly create a blank filesystem (.dsk, .rk06, .tu56), zero out an existing one, list directories,
delete files on the os8 device image file, and copy files to-from including wildcard support. It converts
text files both directions (i.e. adds/deletes <cr>s and mark bits). It checks to see if the device image
file is locked as is true if it is mounted by the PDP-8/e Mac simulator, at least.

I need to do some more thorough testing of corner cases but it seems to be working fine.

It can be found at https://github.com/dhogaza/os8pip.

If Bernhard is interested I'd love to have this included in the Mac PDP-8/e XCode project
once I (and others?) are convinced that it is robust and reliable.

[Johnny Billquist]

On 2022-03-29 20:03, Don Baccus wrote:
> Well, I've been having fun building myself a tool to make it easy to move things back and forth between my
> OS/X host environment and OS/8 device image files.
>
> I prefer using my native editing tools I'm used to rather than relearning TECO (despite my being one of the
> OMSI brats that typed up Russ Hamm's original PDP-8 TECO, interfaced it to PS/8 before it was officially
> released thanks to an early tape from Richie Lary, sped it up by a factor of three, then gave it to DEC
> where it became OS/8 TECO).
>
> So I wrote this thing I've called os8pip. I've tested it on Mac, and Vincent Slyngstad has it compiled with
> gcc on (I think?) a windows block and will try it out.
>
> This lets one directly create a blank filesystem (.dsk, .rk06, .tu56), zero out an existing one, list directories,
> delete files on the os8 device image file, and copy files to-from including wildcard support. It converts
> text files both directions (i.e. adds/deletes <cr>s and mark bits). It checks to see if the device image
> file is locked as is true if it is mounted by the PDP-8/e Mac simulator, at least.
>
> I need to do some more thorough testing of corner cases but it seems to be working fine.
>
> It can be found at https://github.com/dhogaza/os8pip.
>
> If Bernhard is interested I'd love to have this included in the Mac PDP-8/e XCode project
> once I (and others?) are convinced that it is robust and reliable.

Please make the MARK bit optional. Not all people are running ancient
versions of OS/8. :-)

(On the other hand, I still like TECO, and there is also VISTA (and I
even wrote an emacs-clone in TECO-8)...)

Johnny

[William Cattey]

For the pidp8 project, since we were operating under SIMH, we were able to produce some interesting
tools that would:

1. Execute in a Python expect environment to issue commands and deal with replies.
2. Manipulate device configuration in SIMH.
3. Boot into OS/8 and drive behavior with native OS/8 commands.

This approach evolved because I found it easier to run the commands than to decode the POSIX representation
of the virtual device images.

See: https://tangentsoft.com/pidp8i/file?name=doc/os8-cp.md&ci=tip

That doc mentions another tool for fiddling with rk05 images, the OS8View GUI by Ian Schofield that can be found at:
http://groups.google.com/forum/#!topic/pidp-8/1hojqAATum4

[Don Baccus]

I'm aware of os8-cp but wanted a tool I could use totally stand-alone without actually needing a running simulator, so would've done this even if the Mac PDP-8/e simulator had a similar API for inserting commands into a running
OS/8 environment. The image formats aren't difficult to deal with, and it was rather fun writing some C code to
deal with the OS/8 directory structures, which is the bulk of the code (well, other than command line handling and
a bunch of overly-anal error checking :) ).

I also ran across the GUI utility but wanted a CLI utility.

[Don Baccus]

Does the mark bit hurt anything? Even if some OS/8 code doesn't assume it is set, it
should never break anything in OS/8.

I handle it transparently when you use the utility to coptext files from OS/8 to the host and then back again. It's not just about the version of OS/8, it is about programs running under it. For instance, I don't know if OMSI Basic assumes it's set or not, but it wouldn't surprise me, as the project's age can be estimated by the fact that we referred to the OS as PS/8 :)

[Don Baccus]

On Wednesday, March 30, 2022 at 9:35:18 AM UTC-7, bill....@gmail.com wrote:

The Mac PDP-8/e simulator puts a file lock on device image files when you mount them, and my os8pip utility honors that lock. It really needs to because the device implementations don't appear to keep the disk synched.

Apparently SIMH does allow for synching with disk and doesn't lock the file? Or perhaps the OS8View utility just ignores the lock? I'll get around to playing with SIMH at some point. Meanwhile I still have one crash I want to track down in the pre-release version of OMSI Basic that I had on DECtape. And I'm getting busy with work stuff.

[David Armstrong]

This utility compiles nicely under Linux with "gcc os8pip.c -o os8pip" I haven't had a chance to see if it works properly.
p.s. A PDP8e user in1972,1973 and now working on a FPGA (ICE40) version of the PDP8e

[Don Baccus]

Cool. How much memory does your FPGA PDP-8/e have?

[Don Baccus]

BTW I just added code to make binary (.bn) files transfer properly. I used the FOCAL-8.bn file that comes with the OS/X PDP-8/e simulator to test, adding it to a faux DECTape, loading it, then running it and it comes up.

[Don Baccus]

Oh my and I had broken the --create option :) Fixed now.

[Bernhard Baehr]

What a useful tool! I am happy to add os8pip to the tools in the next PDP-8/E Simulator update. But that will take a while, I'm not working on the simulator at the moment.

Maybe I'll add some AppleScript support so you can mount and unmount the drives from the shell, something like

~ $ osascript -e 'tell application "PDP-8/E Simulator" to unmount drive 0 of RK8E'
~ $ osascript -e 'tell application "PDP-8/E Simulator" to mount file "/path/to/dectape.tu56" on drive 1 of TC08'

(The version 1.x of the simulator was completely AppleScript enabled, but nobody ever used that, so version 2.x has no AppleScript support at all.)

The files are locked to avoid mounting the same disk or tape on two drives simultaneously, but this also signals other programs not to modify them while they are cached by the simulator.

Bernhard

[Don Baccus]

I'm glad the simulator lock those files, it is so much less confusing when a program like os8pip
honors the lock and says "nope" until you unmount.

Applescript to mount/unmount might be interesting ... though honestly clicking unmount then mount (since the GUI remembers the last used directory) isn't bad.

I've got some more tweaking to do to this over the next week or so (very busy with other stuff at the moment).

[Johnny Billquist]

It's a potential mess if you actually have a terminal that uses Latin-1.
And you might actually have files that use Latin-1 for their text.
Nothing in OS/8 prevents you from doing that either. :-)

Older versions of OS/8 made implicit assumption on mark parity, but it
was all cleaned up at some point.

Johnny

[Don Baccus]

Which version of OS/8? Did DEC CUSPS quit jamming on the mark bit, then? I'd like to know which version so I can see what KMON and, say, TECO do.

[William Cattey]

I've built the "OS/8 V3D Combined Kit" which was the latest official DEC release of OS/8.

Details: https://tangentsoft.com/pidp8i/file?name=doc/os8-combined-kit.md&ci=tip

I do not see anything in there about character set changing from bit 8 stick parity to ignoring that 8th bit.

There are patches implemented as batch scripts that enable the keyboard monitor and OS/8 BASIC
to operate on lower case input, and pretend it is upper case.

There are some other follow-ons like OS/278 that might have, but I've not been inside that source.

-Bill

[Johnny Billquist]

I'm checking some sources now. TECO8 V7, edit 114. The code explicitly
strips the parity bit on all input, and is not adding any on output.
Exactly when that was done I don't know.

But atleast the KBM itself was/is still forcing mark parity on output. I
was pretty sure I had been running in general with a VT220 on OS/8, but
thinking about it, I suspect I mostly would have been running it in VT52
compatible mode, so maybe I slightly misremember some things.
But being Swedish, I was also fairly sure I was doing national
characters, and not by using ISO 646-SE...
I was/is usually running a version of CCL that was rather more capable
than the standard one, which might have also confused me.

But now I feel like I shouldn't trust my brain. Anyway, I still think
it's good if you have an option to not force mark parity on text files.

Johnny

[Don Baccus]

I may add whistles and bells like that in the future.

At the moment I'm trying to find time to do more thorough testing of corner cases of directory manipulation, i.e. adding new directory segments, shuffling things around to get rid of 0 length empty files, etc.

I don't think there's much you could do with swedish national characters in the keyboard monitor. They can't be part of a file or device name as these are encoded in sixbit. So not usable with commands like R, RUN, LOAD, GET, DELETE, COPY, etc. After all, OS/8, at least when I was using it, barfed even on lower case.

For text files obviously use of full 8-bit chars would make a lot more sense.

With OMSI Basic I thought we were doing well allowing full use of lower case :) When we first got PS/8 I was kinda excited that the native text file format was 3:2 packing of 7 bit ASCII. Most of computing back then (fall 1970) had a VERY UPPER CASE LOOK TO IT ...

[Johnny Billquist]

Oh, definitely. Nothing at that level would ever make use of such
characters. Mostly not even possible, as you note.

The KBM still barfs on lowercase. But CCL (at least the version I use)
works fine with lowercase.

> For text files obviously use of full 8-bit chars would make a lot more sense.

Yeah. And that was where I was coming from here.

> With OMSI Basic I thought we were doing well allowing full use of lower case :) When we first got PS/8 I was kinda excited that the native text file format was 3:2 packing of 7 bit ASCII. Most of computing back then (fall 1970) had a VERY UPPER CASE LOOK TO IT ...

The 3:2 packing is sortof nice. And if you don't worry about NULs, it
works with just one character per word as well.