VR14 CRT emulation web app: need for testers

[Frederic RIBLE]

I have just finalized the first public release for this project: a VR14
CRT emulator running in a web browser.
Below, a picture showing my PiDP8/I running Spacewar!, on top of my
Win10 PC with Chrome executing the VR14 emulator.

You can find a docker image to be installed on your RPi at:
https://hub.docker.com/r/f1oat/pidp8i-vr14

Please, let me know if you have problem with the installation.
I have tried to describe everything step by step, but may be something
remains unclear.

I have tested with tangetsoft.com firmware, but that should work with
any other firmware.

This web app should run with any keyboard layout with zero
configuration: let me know if you experience some issue with your own
keyboard.

This work is inspired from https://www.masswerk.at/spacewar/
A big thank you to Norbert Landsteiner for the help on the project
definition + algorithms, and to David Gesswein for the original VR14
picture.

Frederic
http://blog.f1oat.org

[AndyB]

Hi Frederic- that is a great project - would love to have a go at this.

I did have an "odd" question.  Any thoughts about feasibility to run this over serial back to a Raspberry Pi running Chrome? is it just a question of changing the port from 2222 to to serial?

cheers!

Andy

[Frederic RIBLE]

Hi Andy,

The current implementation is using websockify to convert tcp port 2222 to a websocket.
For your setup, you will need a websocket to serial gateway.
May be https://github.com/tekartik/serial_wss will do the job.
But there is some integration work, and some docker image modifications to be done.

Frederic.
http://blog.f1oat.org

[Obsolescence]

Frederic,

It works here! Great idea to use Norbert Landsteiner's CRT emulation.

I tested your recipe on my PiDP with a Pi Zero, my old software version and the most recent Raspbian.

I found that the latest Docker will crash on older Pi's due to some bug (https://github.com/docker/for-linux/issues/149)

but

         sudo apt-get install docker-ce=18.06.1~ce~3-0~raspbian
got me the latest working version. The other steps of your recipe then worked as described.

Thanks!

Kind regards,

Oscar.

[Frederic RIBLE]

Oscar, thank you for the feedback.
I will update the recipe accordingly.

On SIMH side, the Spacewar! code is using TTY peripheral for pixels transmission, which is not fully realistic with VR14.
So, I am now considering SIMH update to emulate the VC8E 605x IOT instructions (http://homepage.divms.uiowa.edu/~jones/pdp8/man/vc8e.html).
After this modification, we should be able to run original graphical applications with full binary compatibility.

Best regards.

Frederic
http://blog.f1oat.org

--
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 post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/a6a688c9-c0be-450a-bb8f-ac584ca3da23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Schofield]

Dear Frederic,

 This has already been done and is sitting in Mark Pizzolato's list of things to do sometime (he manages Simh).  It is part of a rather extensive graphics update. This update is used in the current PiDP11 project so that the Pi can run a VT11 emulation to play Lunar Lander etc. If Warren would consider this being included in the current PiDP8I build, not a problem.

 If you would like a copy of Simh with the VC8 emulation in the pdp8 module, please let me know. However, this is not a PiDP8I build, just plain old simh. NB to run this, you absolutely need a Pi3 in your PiDP8I. And, a monitor on the HDMI port or, VNC.

Regards, Ian.

On Saturday, March 23, 2019 at 9:36:26 AM UTC, Frederic Rible wrote:

Oscar, thank you for the feedback.
I will update the recipe accordingly.

On SIMH side, the Spacewar! code is using TTY peripheral for pixels transmission, which is not fully realistic with VR14.
So, I am now considering SIMH update to emulate the VC8E 605x IOT instructions (http://homepage.divms.uiowa.edu/~jones/pdp8/man/vc8e.html).
After this modification, we should be able to run original graphical applications with full binary compatibility.

Best regards.

Frederic
http://blog.f1oat.org

On 2019-03-21 06:57, Obsolescence wrote:

Frederic,

It works here! Great idea to use Norbert Landsteiner's CRT emulation.

I tested your recipe on my PiDP with a Pi Zero, my old software version and the most recent Raspbian.

I found that the latest Docker will crash on older Pi's due to some bug (https://github.com/docker/for-linux/issues/149)

but

         sudo apt-get install docker-ce=18.06.1~ce~3-0~raspbian
got me the latest working version. The other steps of your recipe then worked as described.

Thanks!

Kind regards,

Oscar.

--
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+unsubscribe@googlegroups.com.

[Obsolescence]

Ian, Frederic,

I too have been 'planning' (in the loose sense of the word) to add a proper VC8E to the PiDP-8. Especially since I spent the last few days with Vince Slyngstad, who just finished a real VC8E replacement board for his PDP-8/e. If you 'plan' for something long enough, chances are that someone else will have already done it! The other thing I am still planning to do is to build a Lab-8 type of instrument, which also is not too hard to do really. Both things are worthwhile extensions of the 8.

I'd love a copy of the updated simh.

Kind regards,

Oscar.

[Frederic RIBLE]

Ian, thank you for the information.
Yes, I would like a copy of this modified Simh.
That should be a good starting point for my project.
I plan to keep the tcp port 2222 protocol for compatibility with already
existing CRT emulators, including my own implementation.
But use 605x IOT instructions to push data to this socket, instead of
TTY IOT.

Best regards.
Frederic.

[Ian Schofield]

Dear Frederic,

 No problem. Here is the link to the zip file. This is the entire simh system which is coverity checked etc and verified for Linux,Windows and MacOS. You may be able to use the code in pdp8_vc8.c which is the simh handler for this device. You can adjust this to create a socket to send/receive data.

 Hope it works.

Regards, Ian.

---

Simh-5-11-2018.zip

[Frederic RIBLE]

Ian, thank you for the source code.
I am analyzing how tcp/2222 feature could be implemented as an
additional mode, without breaking your implementation.
I can see VC8_SOCK and VC8_X11 flags defined, but not used.
I am wondering if they have been defined for future display mode
switching, like the one I have to implement?

Best regards.
Frederic.

On 2019-03-26 18:06, Ian Schofield wrote:
> Dear Frederic,
>

[Ian Schofield]

Dear Frederic,

 Thanks for your note. If you are planning on using the ttx/TCP route, this rather implies a separate app for the display. As you will have gathered from the code, the interface and VC8 display system is integrated into simh and the IOTs directly write to the screen via display_point in sim_vc8.c.

 Am I correct in think that you want a remote display rather than via the HDMI interface in your PiDP8I? If so, I have attached a file that I think came from Warren and written by Anthony Starks which is worth a look.

Hope this helps, regards, Ian.

[Frederic RIBLE]

Hello Ian,

Yes, the CRT emulation is handled by my own separate web application.
I have used spacewar_on_hdmi.zip as reference to understand the protocol on tcp/2222.

I plan to add a configuration option in pdp8_vc8.c so that we can switch between integrated CRT or remote tcp/2222 CRT.

Best regards.
Frederic

On 2019-04-05 23:14, Ian Schofield wrote:

Dear Frederic,

 Thanks for your note. If you are planning on using the ttx/TCP route, this rather implies a separate app for the display. As you will have gathered from the code, the interface and VC8 display system is integrated into simh and the IOTs directly write to the screen via display_point in sim_vc8.c.

 Am I correct in think that you want a remote display rather than via the HDMI interface in your PiDP8I? If so, I have attached a file that I think came from Warren and written by Anthony Starks which is worth a look.

Hope this helps, regards, Ian.

On Wednesday, March 27, 2019 at 10:48:26 PM UTC, Frederic Rible wrote:

Ian, thank you for the source code.
I am analyzing how tcp/2222 feature could be implemented as an
additional mode, without breaking your implementation.
I can see VC8_SOCK and VC8_X11 flags defined, but not used.
I am wondering if they have been defined for future display mode
switching, like the one I have to implement?

Best regards.
Frederic.

On 2019-03-26 18:06, Ian Schofield wrote:
> Dear Frederic,
>
>  No problem. Here is the link to the zip file. This is the entire simh
> system which is coverity checked etc and verified for Linux,Windows
> and MacOS. You may be able to use the code in pdp8_vc8.c which is the
> simh handler for this device. You can adjust this to create a socket
> to send/receive data.
>  Hope it works.
>
> Regards, Ian.
>

--

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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/29a7c088-34bc-41c5-8e2c-229b9a46cecf%40googlegroups.com.

[Obsolescence]

Kyle Owen just adapted his assembler version of Game of Life to Ian's simh version...

https://drive.google.com/open?id=1NDLCT813b0IuEsUBrwEoYwm7ejJXLfaZ

https://github.com/drovak/pdp8life

...gorgeous. Making it somewhat urgent now to get Ian's graphics update into the PiDP-8! TBC.

Kind regards,

Oscar.

[Frederic RIBLE]

Great motivation for my project!
I am analyzing how I can merge Ian's code with PiDP-8 code, and then add the tcp/2222 support.
Any recommendation is welcome: I am not yet very familiar with fossil capabilities and workflow for efficient merging.

Best regards.

Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/26d36a3e-10f5-448d-be8d-dd88f2db5d6b%40googlegroups.com.

[Frederic RIBLE]

Good news: I have integrated Ian's VC8 code within PiDP-8.
I am testing with remote X11 display for now.
Should work also with RPi framebuffer and HDMI output.
Few seconds after "set vc8 enable" command, I can see a new window coming on my X11 terminal.
Now, I need to learn how to compile pdp8life for testing the display!
Below, screenshot of the session.
Frederic.

[Ian Schofield]

Dear Frederic,

 Brilliant. If the display window opens, all is well. As you can imagine, this can get more involved. Are you using the latest PiDP8I software version from Warrens site to do this. If so, I have some simple test programmes in c for you to try.

Regards, Ian.

[Frederic RIBLE]

Hello Ian,

Yes, I am using the latest Warrens' software, coming from the fossil repository.
Testing software will be helpful.

Best regards.
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/58796f78-cf18-4a90-b3fb-96b5d52ff051%40googlegroups.com.

[Warren Young]

On Monday, March 25, 2019 at 12:18:53 PM UTC-6, Ian Schofield wrote:

If Warren would consider this being included in the current PiDP8I build, not a problem.

I think it would be better if you got this into upstream SIMH and we sync it back down from there.

I assume that is already in progress, since you mention Mark Pizzolato, the main SIMH maintainer.

About the only reason I'd merge it in directly is if it looked like it was going to take an unreasonably long time to get it into upstream.

I've just updated the PiDP-8/I trunk to the latest SIMH, so the diffs relative to your version should now be restricted mostly to the new code, plus whatever's happened upstream since you forked your version.

It's most important that we don't have three separate versions: Ian's, Mark's, and mine. It needs to live canonically in one place only, then get sync'd down from there everywhere else.

[Frederic RIBLE]

Hello,

For those who want to test, here is a first working version:
https://www.dropbox.com/s/jp83vh8dg47z5uy/pidp8i-vc8e-2019-04-16.tgz?dl=0

Tested successfully with LIFE.PAL by Oscar under pidp8_201804.zip firmware.
On my side, I am running it with latest Warren's firmware.

The command "set vc8 enable" will create the X11 window.
After that, you can launch life software.

With Oscar's firmware, here is the compilation recipe:

tar xvzf pidp8i-vc8e-2019-04-16.tgz

cd pidp8i

sudo apt-get install libncurses-dev

sudo apt-get install fossil

rm .fslckout

sudo apt install python-pexpect

sudo apt install python-pkg-resources

sudo apt-get install libsdl2-dev

./configure

make

sudo make install

I am now merging with trunk, but I have many conflicts to manage in sim_video.c.
Looks like I will need to extract Ian's CRT refresh routines in a separate file to remain compatible with upstream.
Next step will be tcp/2222 mode support.

Frederic.

On 2019-04-13 20:32, Frederic RIBLE wrote:

Hello Ian,

Yes, I am using the latest Warren's software, coming from the fossil repository.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/1f94ecff-e2e2-8df9-f090-9b4413c476b1%40rible.com.

[Oscar Vermeulen]

Frederic,

On Sun, 21 Apr 2019 at 10:09, Frederic RIBLE <fri...@rible.com> wrote:

With Oscar's firmware, here is the compilation recipe:

Small correction - that recipe is not for my old firmware, but for the pidp8i software from Ian Schofield, his pidp8i tarball. Which I assume is a fork of Warren's Official PiDP-8 sotware.

To clarify for those who have not been around from the beginning:

- My old version ('pidp8' without i at the end) is by now truly obsolete. It should be forgotten. I will remove any references to it in the upcoming update of the web site etc.

- Ian Schofield fixed many bugs and did the first 'glow like a lamp, instead of flicker like a LED version'

- Warren took things much further and hosts the current "Official" PiDP-8 software here: https://tangentsoft.com/pidp8i/wiki?name=Home

...and thus, (correct me if I am wrong) we now have (1) the Official version on Tangentsoft without VC8E support for now, and (2) Ian's recent VC8E-enhanced version that runs fine, but needs to be tucked back in the Official version.

A little confusing. But only for the moment ;)

But indeed, give this recipe a try with Life! It's a very pretty graphics demo for the 8. Thanks to you and Ian for putting time in VC8E.

On my side, the news is that I hope to start making a new version of the PiDP-8 kit again in a week or two. I got delayed due to my mother's health problems, but the first batch of PCBs should be coming back in two weeks now and I've got all the other bits waiting. The new version of the PiDP-8 is identical on the outside, just easier to build.

Kind regards,

Oscar.

[Frederic RIBLE]

Oscar, that looks like we have tested successfully with 3 different firmware:
- tangentsoft firmware (this is my development platform)
- old pidp8_201804.zip (test I have done few days ago on a RPi Zero, the recipe is coming from there)
- yourself with Ian's firmware (I do not have the URL for this one)

So, the recipe seems ok for all these 3 firmware!
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAJAwMc2Y7osoM0UjjvGqk_o3wJZLo9ZRp8stGRjVGV4HoLfYpQ%40mail.gmail.com.

[Warren Young]

On Sunday, April 21, 2019 at 2:09:27 AM UTC-6, Frederic Rible wrote:

sudo apt-get install fossil

I'm not sure what the point of that command is. A tarball installation doesn't require Fossil. And if it did, you wouldn't want to use the version currently shipped with Raspbian's stable package repo, because it's badly outdated (v1.37), enough so that it can't communicate with my Fossil repository, which requires at least Fossil 2.1 for basic interop and Fossil 2.5 for full interop.

If you need Raspbian Fossil binaries, I provide them here: https://tangentsoft.com/pidp8i/uvlist

I expect to stop providing those binaries sometime after the next major version of Raspbian ships, which will probably include Fossil 2.8.

 

rm .fslckout

I don't see why you'd want to do that. That's a brute force way of disassociating a Fossil checkout directory from its Fossil repository. The only time it's needed is if you have such a checkout, and neither "fossil close" nor "fossil close -f" work properly, but you need to close the current checkout directory before re-opening it against a different repository. It's a really rare case in practice, not something you'd generally recommend as a stock step.

If you're just integrating your patches atop a checkout of my repository, you should leave the .fslckout file alone, because you presumably still want to get later updates from my repo. If those updates cause merge conflicts, you need to accommodate them anyhow, since for the most part, what we provide in src/SIMH is unchanged from the upstream version. The size of our diffs against upstream are pretty small these days.

 

Looks like I will need to extract Ian's CRT refresh routines in a separate file to remain compatible with upstream.

Do let me know when this patch is accepted upstream. I generally only pull new versions down from the GitHub SIMH repo in two cases:

1. when they have something new which I know in advance that I want to apply to my version

2. shortly before a new release of my version, to sync up with whatever they've done upstream since the last update

The timing of neither case is predictable, and there can be a long time between either occurring, so if you don't tell me when it's happened, it could take me months to do the pull for my own idiosyncratic reasons.

[Obsolescence]

Frederic, or for anyone who wants to try:

I wanted to run the original VC8E spacewar (as in, not the one that once was modified by Kyle Owen for simh), but I met with limited success.

Source file: http://www.pdp8.net/pdp8cgi/os8_html/SPCWR3.PA?act=file;fn=images/jby/jbyos8.tu56;to=ascii;blk=510,131,0;plain=1

Assembly options: in the source file, set VC8E and DK8EP to 1 to indicate a PDP-8 with VC8E and the DK8EP clock

Compile with palbart, no errors

If I run the result, I get nothing until I press a key (which happens to generate an interrupt) - then spacewar generates 1 frame.

The graphics output looks garbled though: the center star in the game looks good, the spaceships do not:

So it seems the clock is not generating an interrupt.

This page (link) describes exactly the same problem on a real PDP-8, and identified the bug. After 40 years...  TAD (5300 should be TAD (5310. Otherwise, the clock interrupts will not be enabled.

OK, so I did that, recompiled, and as opposed to what was the case on the real PDP-8, that did not solve the problem. I.e., the clock still does not generate an interrupt. The CLK device in simh (SHOW CLK) is enabled by default, I don't really see what I should change in the configuration of it.

Maybe my incompetence, but maybe some compatibility issues still!

Kind regards,

Oscar.

[Obsolescence]

I also tried the somewhat famous Kaleidoscope demo program.

That works (play with the SR switches to get some interesting pattern), but some intense front panel play did freeze simh once - nonreproducible so far alas.

Source for palbart:

/ Kaleidoscope program for the VC8E/VR14 scope.
    / Based on suggestions from page 6-19 of the Small Computer
    / Handbook, 1973.

    / The advice given is to experiment with settings of
    / the switch register bit positions 9, 10 and 11, leaving
    / all higher bits zero.  The advice is good; this is a
    / nice "screen saver" for non-storage scopes.

    DISD=   6052
    DILX=   6053
    DILY=   6054
    DIXY=   6055

    *       200
    START,  TAD     Y
        JMS     SCALE
        CMA
        TAD     X
        DCA     X       / X = X - SCALE(Y)
        TAD     X
        DILX
        JMS     SCALE
        TAD     Y
        DILY
        DISD
        JMP     .-1
        DIXY
        DCA     Y       / Y = Y - SCALE(X)
        JMP     START

    X,      3777            / any initial value works, but
    Y,      6               / 0,0 is least interesting.

    / Divide AC by 2**SR
    SCALE,  .-.
        DCA     TEM
        OSR
        CIA
        DCA     C
        TAD     TEM
        CLL
        SPA
        CML
        RAR             / Arithmetic right shift
        ISZ     C
        JMP     .-5
        JMP I   SCALE

    TEM,    .-.
    C,      .-.

    $

[clasystems]

I could write chapter and verse on why  most of these assumptions are wrong, but cutting to your chase:

What system are you trying to run this on.  SIMH does not support the PROGRAMMABLE clock, does it.  Please correct me if I am wrong, but to my knowledge, it has the so-called line clock, DK8E-A, not DK8EP.

So, fix a bug or not, how do you expect it to work when the bug fix is for non-existent hardware, emulated or nor.

A quick historic note:

POLY SPACEWAR is from 1969.  Your arguments about whose latter-day version is more original-like is somewhat limited.

Hardware requirements:

4K straight PDP-8 with EAE

A variety of display devices.  The original is the AA01A which is a three-channel 12-bit D-A converter.  The third channel is used as a poor-man's scope intensify when hooked to such as HP 'scopes.

Also can be easily tailored to AX08,PDP-12, VC8E, etc.

Does NOT require a clock.  Runs without interrupts.  Wastes too much time trying to time the output.  The effect is quite nice trying to refresh the scope as fast as possible.  Doug Wrege was not that good a programmer until later.  But he also never had our source code to ponder.  Kyle in turn never saw ours, but he did see Doug's.

The input was either to the top 4 and bottom 4 front panel switches which is cramped for "non-symmetric" players, better on the PDP-12 because the left player can move to the LSR high four.

Better yet, if you have the AF01 and set it to short sampling, connect two control boxes with a nine-volt battery inside.  Press a button and it flips to a positive voltage.  Only the high-order bit of the conversion is used, etc.

Or build an input to such as the DR8E or the SXL inputs on the PDP-12.  It is always best the players are on the end of cables and well physically separated.

Please note that PDP-8 EAE is:

a) Not the mode B of the PDP-8/E, just mode A

b) Unlike all newer EAE [and machines with just an MQ] the PDP-8 DOES NOT support the SWP operation, thus some code has what appears to be inefficiencies if you 
are expecting newer hardware.  You can shave a couple cycles here and there by rewriting.

The original version loads into all but the last page, but running it wipes out the operating system.  A later version eliminates that by shaving an entire page by eliminating 4/5 of the sin/cos lookup table.

We also built the POLY MUSIC REGISTER to create nice sound effects.  We had so many crowds, we had to lock people out of the room so we could get our own work done!

cjl

[Oscar Vermeulen]

Charles,

On Tue, 23 Apr 2019 at 01:57, clasystems wrote:

I could write chapter and verse on why  most of these assumptions are wrong, but cutting to your chase:

What system are you trying to run this on.  SIMH does not support the PROGRAMMABLE clock, does it.  Please correct me if I am wrong, but to my knowledge, it has the so-called line clock, DK8E-A, not DK8EP.

Indeed... that is the answer! I just checked the simh docs, you're right.

Bummer - I was just about to try out BASIC/RT, but that too will expect the DK8EP for at least some of its features.

POLY SPACEWAR is from 1969. 

I just came across what I presume is that version an hour ago in fact (link, link). I will try that tomorrow, it's rather late at night here. But I saw that indeed it also covers the VC8E.

The input was either to the top 4 and bottom 4 front panel switches which is cramped for "non-symmetric" players

I actually soldered my spacewar controller switches straight on the back of the SR switches - so for me that will work.

 

The original version loads into all but the last page, but running it wipes out the operating system.  A later version eliminates that by shaving an entire page by eliminating 4/5 of the sin/cos lookup table.

The version I found is in the above link, I believe I got the right one.

We also built the POLY MUSIC REGISTER to create nice sound effects.  We had so many crowds, we had to lock people out of the room so we could get our own work done!

More things to replicate ;)

Thank you! I will continue tomorrow with this version of spacewar, and see if BASIC/RT will talk to the display.

Kind regards,

Oscar.

[CLASystems]

On Mon, Apr 22, 2019 at 9:23 PM Oscar Vermeulen <vermeul...@gmail.com> wrote:

Charles,

On Tue, 23 Apr 2019 at 01:57, clasystems <clasy...@gmail.com> wrote:

I could write chapter and verse on why  most of these assumptions are wrong, but cutting to your chase:

What system are you trying to run this on.  SIMH does not support the PROGRAMMABLE clock, does it.  Please correct me if I am wrong, but to my knowledge, it has the so-called line clock, DK8E-A, not DK8EP.

Indeed... that is the answer.

Bummer - I was just about to try out BASIC/RT, but that too will expect the DK8EP for at least some of its features.

Correct.  LAB-8/E BASIC is the same source code as 8K BASIC.  However. it occupies ALL of 8K and part of field 1 is not even the code stack, but rather the added-on lab functions.  As such, at best it is a lot less capable than 8K BASIC, so you better really need the lab functions or don't bother unless you write relatively smaller BASIC programs, etc.  And it needs ALL the LAB-8/E hardware [8K BASIC needs none]

POLY SPACEWAR is from 1969. 

I just came across what I presume is that version an hour ago in fact (link, link). I will try that tomorrow, it's rather late at night here. But I saw that indeed it also covers the VC8E.

That version is totally unknown to me, but I quickly looked at it and have some "wet reading" comments.

1) This could run on an 8/L, i.e., no EAE at all.

2) Very low precision calculations, goes hand in hand with not requiring EAE.

3) Very low precision SIN/COS table lookup values.

4) The control boxes are indeed the same as for POLY SPACEWAR but it's a coincidence.  Likely from the meager documentation of what the PDP-1 version had.  While the PDP-1 version is clearly the most historic, it requires more hardware and memory than POLY SPACEWAR, thus from a programming standpoint, it is a "lower hanging fruit" program.  When you use the PDP-8, you learn to use EVERY resource!

5) Curiously, it has [no internal documentation] the proper use of trigonometric identities to eliminate the need for longer lookup tables and multiple tables.

In short, you can use various simple identities to derive ANY angle SIN or COS to reduce into the SIN(X) where X is 0-90 degrees where the result has to be perhaps complemented or use a complementary angle to preconvert to get the right result, or a combination of techniques.  The point is that the simple math to precondition is only a few instructions and not material.  The table lookup saves the vast bulk of the time.  I have seen more "rinky dink" versions where not only less features but sloppy coding practices to the point of the need for 2 complete 360 degree tables!  That is pathetic since all you need to do is overlap the tables offset by 90 degrees.

For the excellent mathematical modeling performed, the original used 12-bit precision results; this program seems to use less than six!

In any case, this is a "sensitive" issue as this last feature to eliminate all but a single 90 degree table was done by a now-deceased member of our group,  Prior to his work, the 5/4 pages method was used and as such, the program variables had to destroy 07600-07777.  As such, playing the game needed manual bootstrap afterwards.  But the final result has one table in 1/4 of one page thus the last page is now preserved, making it compatible with nearly every PDP-8 operating system including P?S/8, the R-L Monitor System [where it was developed] and even OS/8.

The design uses accurate table lookup results, but not 1 per degree.  You only really need 32 possible values.  Wetstudied the needs of the math, you need accuracy of result but not really all that accurate angle parameters. [I know that sounds slightly counter-intuitive, but the actual game plays the same]
 
I have available the documentation of the POLY MUSIC REGISTER if anyone wants it.  Basically, it is a reload count value for an oscillator that free runs unless a 0000 is placed in it, and a timing register that gates how long the output is audible.  Zeroing either shuts it down.  A calibrated table is available to provide a useful set of musical notes over several octaves is included, but no surviving hardware prints.  It should not be hard to derive because we know the frequencies of the desired results, etc.

POLY SPACEWAR has this cool blowup routine that also uses the music register, but it is also firing sounds influenced by watching reruns of ST:TOS which was in the first generation or reruns at 6 PM NY time while it was being written, so many of you already know those sounds.  It was because we were playing it with the speakers connected [we had a good amp and big speakers] that started attracting a crowd.  Note:  We never charged admission, but we considered it.  Eventually we did raise some money for the school charging to play during a fund-raising drive.  We only had one machine other than the one year we also had a DEC sent PDP-12 on loan.  Can't get any work done when p\people want to play such a popular game.
Of course, eventually we solved the problem, we just lived there literally used the machine 24/7.  I got a bed and I provided the TV which was part of my large-screen oscilloscope project hooked to the PDP-8 so it belonged there anyway.  Those were the days!

So far the source files of the last version have not turned up.  to my knowledge, the "ugly" source code without the nice frills is all we have, so all is not lost.  I have the R-L Monitor source files apparently [others are converting very old DECtapes and the "POLY Action Pack Games DECtape seems to have been recovered.  All of the popular games source files are on it.  I need to put it onto the er wWindows SIMH and run the RL-> P?S/8 conversion program [we never had any interest in reverse conversion!] and then a few file management commands and it will still be "ugly" but then at least readable everywhere.

I have put this project on the back burner because I was holding out hope [still have some] for finding the better source code:

1) All the proper tab settings corrected.  [Note: One of the major improvements of P?S/8 over R-L is the support of the HT character.  Thus, R-L files cannot help but be "ugly" even if you want it better [unless you fill a file with a ton of SP characters]

2) Conditionals to handle most of the relevant input and output devices on various configurations such as the AA01A and AF01A original, the AX08, PDP-12 and LAB-8/E [easy to add the VC8I which is different from the LAB-8/E VC8E]

3) Lots of comments [well, a goodly "some" is a lot better than virtually none!]

4) My labors and time can correct all of the above and more, but the SIN/COS in 1/4 page trig stuff analogous to this AX08 only versus you pointed me too was added by our late member.  And I am certain I created such a file.

So, I need someone to look at what you pointed me to, and get it documented or explained [it is zero comments!] and adapt the resultant code for the less angle increments but more accurate needs of this program [I don't claim to know enough to remember how to do it, just I do remember that it can be done!].  I need a math whiz with a rudimentary understanding of the PDP-8 instruction set and I will provide the 5/4 page version and this program and see if we can resurrect the entire program!

[In the back of my paranoid brain is the notion:  I will do all that work and then A WEEK LATER we will unearth the original work I did so many years ago!]



Anyway, thanks for that version to provide a little help in the overall effort.

Once the source is reconstructed, let all judge which of any and all of these is the better game.  [Note: The programs that need 8K can hardly justify the extra memory usage.  This really is a 4K game if carefully written; we had no choice.  Such is the nature of PDP-8 programming, and again, NO interrupts are used; it is better to display as fast as you can to avoid flicker and as a practical matter, there really aren't that many objects on the screen.  If you refresh faster, the output on the scope doesn't change, but if you go too slow it flickers.  Thus, no point in bothering with interrupts.

cjl

The input was either to the top 4 and bottom 4 front panel switches which is cramped for "non-symmetric" players

I actually soldered my spacewar controller switches straight on the back of the SR switches - so for me that will work.

I rejected that because we had the AF01A and the short-cycling option [six-bits through 12-bits and the less the faster and only keep the high-order bit.  The players are sampled as a background task so it doesn't matter.  The main loop is the latest calculation and displaying all live points on the screen.

Also, attaching  stuff to a PDP-8 front panel is asking for static electricity troubles!

 

The original version loads into all but the last page, but running it wipes out the operating system.  A later version eliminates that by shaving an entire page by eliminating 4/5 of the sin/cos lookup table.

The version I found is attached.

And thanks, that part discussed above is useful.

We also built the POLY MUSIC REGISTER to create nice sound effects.  We had so many crowds, we had to lock people out of the room so we could get our own work done!

More things to replicate ;)

Really easy.

Thank you! I will continue tomorrow with this version of spacewar, and see if BASIC/RT will talk to the display.

Will be a problem because of timing from the programmable clock requirements.

Kind regards,

Oscar.

OK

cjl

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Frederic RIBLE]

Warren, thank you for the recommendations.
Actually, the "rm .fslckout" was only a quick and dirty fix to achieve compilation when I downloaded the tarball on a brand new RPi Zero.
I am keeping  this file on my dev machine, and I am now finalizing merge with your last commits.
When done, I will analyze how I can modify my patch for SIMH upstream.

Best regards.
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/a2f1907f-91cb-43fd-9dd2-e3a2588a43a7%40googlegroups.com.

[Obsolescence]

Changing the clock to the regular DK-8EA in Wrege's spacewar version solves my problem and presents a running game. Thank you, Charles!

Attached is the version that seems to work. However, for some reason I cannot get it to print out the options menu if you press O. Or let the keyboard do anything else than reset the game. TBC...

(And indeed, BASIC/RT will not work without the EP clock).

[AndyB]

fantastic info Charles!  

andy

[Ian Schofield]

ear All,

 As Oscar say, the clock must be DK-8EA. Here are the conditionals for D Wrege's V3A. Works with Frederic's build with one minor change to the makefile as below as at the moment,

 you can't steer one of the ships from the keyboard. If you are using the SR ... no problem!

Defines for Spacewar.pa V3A

SIMEAE=0

VC8E=1

SERVID=0

PDP12=0

DK8EA=1

DK8EC=0

AX08=0

T30G=0

DK8EP=0

FCLOCK=0

KW12=0

 

makefile in pidp8i as supplied by Frederic.

# C build flags for the PDP-8 simulator and its PiDP-8/I extensions.

SIM_CFLAGS := -g -O2 -std=c99 -fipa-cp-clone -fno-strict-overflow -fpredictive-commoning -fgcse-after-reload -finline-functions -fno-unsafe-loop-optimizations -O2 \

-Wno-unused-result -Wno-parentheses \

-DUSE_READER_THREAD -DHAVE_DLOPEN=$(subst .,,.so) -DPIDP8I \

-DSIM_ASYNCH_IO -DUSE_DISPLAY -DUSE_SIM_VIDEO -DHAVE_LIBSDL -DSDL_MAIN_AVAILABLE -DHAVE_REGEX_H -DHAVE_GLOB \

-DSIM_GIT_COMMIT_ID=$(SGCID) -DSIM_GIT_COMMIT_TIME=$(SGCTM) \

-D_GNU_SOURCE -DPDP8\

-U__STRICT_ANSI__ \

-I ./src/SIMH -I ./src/pidp8i -I src -I src/SIMH -I src/pidp8i

Added -DPDP8 .. this sets the keyboard mapping for the PDP8 as opposed to a variety of other systems (Apologies for not sending a patch file but this is a minimal change).

On run, OS/8 terminal for Option commands try ucase 'O' (oh) 

Keyboard commands with focus in graphics window: (code from sim_ws.c) NB make sure your PiDP8I's SR is zero if you want to use the keyboard.

void display_keydown(int k)

{

    switch (k) {

    case 'f': case 'F': spacewar_switches |= 01; break; /* torpedos */

    case 'd': case 'D': spacewar_switches |= 02; break; /* engines */

    case 'a': case 'A': spacewar_switches |= 04; break; /* rotate R */

    case 's': case 'S': spacewar_switches |= 010; break; /* rotate L */

    case '\'': case '"': spacewar_switches |= HI1; break; /* torpedos */

    case ';': case ':': spacewar_switches |= HI2; break; /* engines */

    case 'k': case 'K': spacewar_switches |= HI3; break; /* rotate R */

    case 'l': case 'L': spacewar_switches |= HI4; break; /* rotate L */

    default: return;

    }

}

 If you fancy a remap, here is the place to do it.

Hope this helps, regards, Ian

[Obsolescence]

Ian,

Thanks! I got it working last night and played spacewar for far too long to follow up ;)

On Wednesday, April 24, 2019 at 11:11:26 PM UTC+2, Ian Schofield wrote:

Keyboard commands with focus in graphics window:

Ah! That, I did not figure out, very handy indeed!

Kind regards,

Oscar.

[Obsolescence]

Frederic, Ian,

Now we're blessed with VC8E in simh, I took the jump and bought a cheap laser galvo. The sort of thing that paints a laser vector display on the wall at noisy disco parties ;)

The idea is to see if a $100 setup has enough speed and precision to play a decent game of spacewar.

The setup:

$70 galvo unit (link)

$5 laser

$4 DAC module that will get its X/Y data over I2C from the Pi. Meaning the VC8E code in simh needs to send its bits to the free I2C pins on the GPIO.

I'm not sure this will have the speed to do something as complicated as the spacewar imagery. But if not, it should still paint a decent Snoopy picture or perhaps Kyle Owen's Game of Life, all from the PiDP-8. I can always try a more expensive galvo afterwards.

To drive the galvo properly would need a lot more sophisticated programming (taking into account the acceleration and deceleration of the little mirrors that deflect the laser beam). That is way beyond me, but let's see what can be done with primitive code.

Now 4 weeks of waiting for parcels from China.

Kind regards,

Oscar.

[Ian Schofield]

Dear Oscar,

 Oh yeah! You mentioned this. Anyway, I2C writes could go in the IOT routine in pdp8_vc8.c where vc8_xreg and vc8_yreg are loaded.

NB VC8 does have to be enabled to call this routine.

Regards, Ian.

[Frederic RIBLE]

Oscar, very interesting project!
On my side, I am now adding tcp/2222 capability to pdp8_vc8.c with a configuration command.
Currently, the syntax is "attach vc8 X11" for X11 display, and "attach vc8 2222" for tcp mode.
That will be easy to add "attach vc8 dac" or any other mode in the future.

For galvo, I guess the best applications will be vector graphics, where the spot is following a curve.

Best regards.
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/fae2ba0e-c16d-4141-b313-7cf89b60f36d%40googlegroups.com.

[Oscar Vermeulen]

Frederic,

On Thu, 25 Apr 2019 at 11:44, Frederic RIBLE <fri...@rible.com> wrote:

That will be easy to add "attach vc8 dac" or any other mode in the future.

Indeed, I was hoping to ride along on your efforts ;)

 

For galvo, I guess the best applications will be vector graphics, where the spot is following a curve.

I guess emulating a point-plot display with - essentially - a vector display in the shape of a laser is part of the challenge. As long as the number of elements on the display is limited, I would think it is OK. I'll find out the hard way!

Kind regards,

Oscar.

[Frederic RIBLE]

Good progress with VC8E emulation over tcp/2222.
I can now run SPCWR3_vc8i.bin with my javascript VR14 emulator! (see picture below).
Should be ok with all other tcp/2222 terminal implementations.
I have put some placeholders in the code for future DAC implementation.

Best regards.
Frederic.

/* Attach master unit */

t_stat vc8_attach (UNIT *uptr, CONST char *cptr)

{

t_stat r;

int32 t;

vc8_screen_mode_t new_mode;

static char filename[40] = "";

if (!cptr || !strcasecmp(cptr, "X11")) {

vc8_port = 0;

new_mode = vc8_screen_x11;

strcpy(filename, "X11");

}

else if (!strcasecmp(cptr, "DAC")) {

new_mode = vc8_screen_dac;

strcpy(filename, "DAC");

}

else {

vc8_port = atoi(cptr);

new_mode = vc8_screen_tcp;

sprintf(filename, "tcp/%d", vc8_port);

}

switch (new_mode) {

case vc8_screen_x11:

display_init(DIS_VR17, RES_FULL, &vc8_dev);

t = sim_rtcn_init (uptr->wait, TMR_CLK);

sim_activate (uptr, t);

break;

case vc8_screen_tcp:

vc8_master_sock = sim_master_sock_ex(cptr, &r, SIM_SOCK_OPT_REUSEADDR);

if (r != SCPE_OK) /* error */

return r;

sim_activate (uptr, 0); /* start poll at once */

break;

case vc8_screen_dac:

// Placeholder for future DAC implementation

break;

default:

return SCPE_NXDEV;

}

vc8_screen_mode = new_mode;

uptr->filename = filename;

uptr->flags = uptr->flags | UNIT_ATT;

return SCPE_OK;

}

....

static void add_point()

{

int x,y;

switch (vc8_screen_mode) {

case vc8_screen_x11:

/* recall that x and y values are signed;

this converts them to unsigned values, origin in lower left */

x = (vc8_xreg & 01777);

y = (vc8_yreg & 01777);

/* scale x and y to the displayed number of pixels */

x = x / PIX_SCALE;

y = y / PIX_SCALE;

display_point(x, y, 7, 0);

break;

case vc8_screen_tcp:

vc8_write_tcp(vc8_xreg-512, vc8_yreg-512);

break;

case vc8_screen_dac:

// Placeholder for future DAC implementation

break;

default:

break;

}

}

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/0289b7d9-90f4-4efc-b62d-751e7e46403f%40googlegroups.com.

[Frederic RIBLE]

Hello,

For those who want to test the last evolution of VC8E emulation, here is a new tarball:
https://www.dropbox.com/s/obqv22hydcwh22s/pidp8i-vc8e-2019-04-26.tgz?dl=0

You will find already compiled binary in pidp8i/bin/pidp8i-sim

With this new release, display activation syntax has changed:

• "attach vc8 x11" to activate a X11 window (formerly "set vc8 enable")
• "attach vc8 tcp/2222" to activate pixels rendering over TCP port 2222, with 2 options to display the image
• use DJ's VR14E emulator available at https://www.ez-robot.com/uploads/user/DB763BE15E695777689418BE7364E0A3/VC8E-SpaceWarDisplay-636571092179294095.zip
• use my Javascript VR14 emulator available at https://cloud.docker.com/u/f1oat/repository/docker/f1oat/pidp8i-vr14

"detach vc8" is supported.

Keyboard support on tcp is not yet implemented, you have to use front panel SR switches to play Spacewar!

I hope X11 is not broken, I cannot test it currently. Please, give me feedback.
Also I noticed different behavior of OS/8 when using the "DIR" command from a mRemoteNG ssh session:

• the screen is erased and the prompt  is at the top
• I need to use the scrollbar to see the list of files

I do not know if this is a regression.

Best regards.
Frederic.

[Frederic RIBLE]

Hello,

Here is an update: https://www.dropbox.com/s/mviksncr7kfchrs/pidp8i-vc8e-2019-05-01.tgz?dl=0
With the following enhancements:

• The keyboard is supported in "tcp/2222" mode
• There is now an embedded web server providing VR14 emulation webapp
• Use "attach vc8 http/8000" to activate this web server on port 8000
• Then, from a Chrome brower, open the url "http:<your_pidp8_ip>:8000"
• You will see the VR14 screen
• Hit a key to launch the CRT refresh
  

The tarball is including compiled pidp8i/bin/pidp8i-sim

Before using it, you will need to install libwebsockets and HTML pages related to the VR14 emulator:

• sudo apt install libwebsockets-dev
• sudo make wwwinstall

Tu play Spacewar! over HTTP, you can use the following boot script:

set cpu noidle
set nothrottle
deposit int-throttle THROT_DELAY 3
set df disabled
attach vc8 http/8000
load ../spacewar3/SPCWR3_vc8i.bin
g 200

Option keys on the console are working.

Best regards.
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/56a7010d-1237-3bfd-f622-a99e356905f6%40rible.com.

[Frederic RIBLE]

Hello,

New update: https://www.dropbox.com/s/q493ki4kzujnv0s/pidp8i-vc8e-2019-05-02.tgz?dl=0

You can now connect 2 or more PC to the same VR14 web session.
All sessions will display the same screen.
Spacewar! keys are combined for network multiplayer experience.
Typically, one player will use left keys on the first PC, and second player will use right keys on a second PC.

Best regards.
Frederic.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/b055f5b5-4326-cb5d-0fbd-7097eab53073%40rible.com.

[Warren Young]

On Thursday, May 2, 2019 at 2:10:19 PM UTC-6, Frederic Rible wrote:

New update: https://www.dropbox.com/s/q493ki4kzujnv0s/pidp8i-vc8e-2019-05-02.tgz?dl=0

Are you working on getting this into the upstream SIMH v4 project? I'd be happy to ship it as part of the PiDP-8/I software, but this isn't really PiDP-8/I specific. All PDP-8 SIMH users should be able to use this feature, should they wish to.

[Obsolescence]

Warren, Frederic,

On Saturday, May 11, 2019 at 12:39:40 PM UTC+2, Warren Young wrote:

Are you working on getting this into the upstream SIMH v4 project? I'd be happy to ship it as part of the PiDP-8/I software, but this isn't really PiDP-8/I specific. All PDP-8 SIMH users should be able to use this feature, should they wish to.

Ian knows more than I do, but from him I got the impression that it will take a long time before the simh guys will get around to implementing Ian's vc8e. Let alone the more specific additions of Frederic. So bringing it into pidp8i sounds worthwhile to me. But at least for me, saying so is easier than doing so...

Kind regards,

Oscar.

[CLASystems]

Send this to Dave Gesswein.  Either he will put it in "upstream" as you might refer to it as, or the "long time" may be far longer than you imagine.  There are other things missing as well; perhaps a "critical mass" effect can be useful to all.

One of my problems is basically an academic mission.  I want as an operational mode of my PEPS package (SIMH greatly enhanced for Windows) is to be able to teach abject novices to PDP-8 the incredible tedium of working with ONLY the "paper-tape operating system" in its "full glory" so that they can better appreciate storage-based operating systems.  This is especially useful on the PiDP-8 due to having a front panel of course.  But the point is, the documentation in the program is that there is a command to dump [save] memory and the documentation exceeds reality, as in it does not work at all because someone never finished the PDP-8 version of that command.  [There are some other architectures that apparently it works for].

Thus, this limits the scope of "course material" etc. for teaching just the cpu and memory and the console and maybe the high-speed reader/punch because of a sore point that should not exist.

Since the command is partially present, it should be little work to complete it.  Then, a more productive update can be presented, etc.

I have already gotten Dave to add two related changes:  Change one parameter line for each (TC08 and TD8E) and this allows longer DECtapes.  This was needed because real-world longer DECtapes are quite real (I have them and also image files of them working) and this requires preventing the absolute length limiting to 2702 octal blocks that happens without the patch.  Because of the possibility of more than the usual extended length of 3300 octal blocks real-world, the patches allow "fantasy" DECtapes of up to 4096 blocks, which is supported by P?S/8 on the Windows version of SIMH.  This allows P?S/8 to have a nice amount of working storage (8 DECtapes times 4096 blocks) while OS/8 is configured for four RK8E/RK05 packs [and also DTA1: to allow inter-system data interchange] all at once in one "super configuration".  This allows either operating system to boot to the other in a larger SIMH session and other niceties.  I also have two screen icons so you can choose which O/S starts it up (and gets to process PTR: input) but as necessary boot back and forth within the session, etc.  [Note:  Unlike most of the needlessly simplistic configurations, these systems presently "enhance" each other as both lack complementary features.  As I develop more of P?S/8, that equation will change, but for the present, a lot of things done really needs both systems, not the least of which is that the standard method of generation P?S/8 is from a running OS/8 system, although clearly there is an end to that scheduled for the next release]

In any case, lets make sure the basic principle of SIMH sharing the work of many people is maintained for the benefit of all.  Most of what I am speaking to is "generic" as it should be.  And of course, I would welcome VC8E support in Windows as well.

cjl

Kind regards,

Oscar.

--
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/rhb_YuwXRgs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/9ceec4ba-2de9-4aef-9b46-87f5724b198a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Oscar Vermeulen]

Charles,

I'll email Dave Gesswein to see how Regular simh can include this.

Regarding your idea of demonstration the full pain of having only paper tape storage: that can be demonstrated with the PiDP with nearly as much suffering as on the original machine.

In short, prepare USB sticks with each of the paper tapes (read or write ones). Each USB stick only contains a <filename>.pt. The filename actually does not matter.

You can then

• toggle in the boot loader manually (or through simh, depends on the pain you are looking to inflict);
  
• stick the USB "paper tape" with the Bin Loader into the Pi,
  
• mount it, load it, run it,
  
• stick the USB "paper tape" with maybe Focal, mount that, load it, etc.

The procedure is described here: link, under the '1969' section. The only unrealistic things:

You have to mount the USB stick with a toggle switch action, rather than put a real tape into the Teletype.

And of course the load times are way faster than on the original.

But it comes close enough to make people see how an interactive language felt like paradise compared to the process of editing & compiling via paper tape, how significant a development that was. And is just short enough that young people will not run away, most of the time.

The paper tape image files to copy on USB sticks are in the pidp8 distribution.

Kind regards,

Oscar.

[CLASystems]

On Mon, May 13, 2019 at 10:49 AM Oscar Vermeulen <vermeul...@gmail.com> wrote:

Charles,

I'll email Dave Gesswein to see how Regular simh can include this.

OK.

Regarding your idea of demonstration the full pain of having only paper tape storage: that can be demonstrated with the PiDP with nearly as much suffering as on the original machine.

To be sure!  But then it is not "generic" pain :-)

In short, prepare USB sticks with each of the paper tapes (read or write ones). Each USB stick only contains a <filename>.pt. The filename actually does not matter.

This is not an issue,.

You can then

• toggle in the boot loader manually (or through simh, depends on the pain you are looking to inflict);
  

Generically true.  SIMH includes BIN loader support "magically".

• stick the USB "paper tape" with the Bin Loader into the Pi,
  
• mount it, load it, run it,
  

There is the notion of a default directory in SIMH at the command level.  I set which one using one of the many NEARLY OR TOTALLY UNDOCUMENTED commands you can put in the .ini files.  [There are some really nifty things that work fine, but I doubt 10 people in the world know they exist!   I just guessed some of them WOULD exist!  btw, they are often patterned after MS-DOS/WINDOWS BATCH commands. Who knew?]

That way I encourage the student to just use their name, with an optional extension if they understand that.  Remember, for a student the course is not to end it at paper-tape, just go through all that and progress to something better.  P/S/8 is far easier to learn than OS/8 and you can't get into as much mischief, especially when you are a "dangerous" novice.  I expect the entire paper-tape "experience" to be quite distasteful and harder to grasp.  Just for perspective, over the years i have carried out this greater scenario with others [always adults due to the circumstances].  They appreciate P?S/8 in ten minutes or less!

 

• stick the USB "paper tape" with maybe Focal, mount that, load it, etc.

That part is already there.  The loading is not the problem.  It's easier than your description actually.  I will provide appropriate files.  For the present, I have the binaries of FOCAL, INIT and of course PAL III.  If someone gets the ability to save memory finished [it's called the DUMP command, read the built-in HELP, but it doesn't completely work as advertised,  If you leave out the file name, it correctly complains, if you put it in it gets an error and you can never get any further.

My workaround, which I do not like because it means you have to "jump" to even more knowledge of the entire environment which violates the "academic flow" is to always use the high-speed reader or punch as the input or output.  But you have to exit the session.  In the command level I have an icon that swaps the PTR and PTP files.  By additional kludge, the PTR: stream can be saved as a file in the default directory, etc.  [I haven't bothered to make it functional, it just would be par of the intrusion.  Nothing is as good as it being fixed

BTW, back when this was a PDP-10 program and was simulating specifically a PDP-8/I ONLY and no other machines, it DID work, all the code them was written by Bob Supnik.  But these days, he has disavowed all of them because they have ruined it in various ways.  I can understand his sentiment since stuff that had worked no doesn't AND the documentation is so flawed on so many levels, documents exist and code doesn't, code exists and documents don't, and command syntax follows no general form, just the pet projects of people doing their own without regard for overall impact.  Mind you, I am glad that it works at all, but this is partially out of control over the years, etc.  But the original was ONLY for paper-tape and it completely worked.  Features should be added to any project, not misfeatures that break other things and they don't get fixed.

The procedure is described here: link, under the '1969' section. The only unrealistic things:

You have to mount the USB stick with a toggle switch action, rather than put a real tape into the Teletype.

And of course the load times are way faster than on the original.

I have already passed that compromise by using the PTR and PTP instead of the teletype, but remember, in a realistic course setting, we have to get past paper-tape, not get buried in it!

But it comes close enough to make people see how an interactive language felt like paradise compared to the process of editing & compiling via paper tape, how significant a development that was. And is just short enough that young people will not run away, most of the time.

Indeed.  If the command is fixed, that should happen even less.

The paper tape image files to copy on USB sticks are in the pidp8 distribution.

I'll indicate if I am short on anything in particular.

I will also include 4K and 8K BASIC which you cannot save from, same problem.

You mention FOCAL, 1969.  If the DUMP command can be fixed to include multiple ranges into one file, the LOCATIONS command can be made functional as intended.

Kind regards,

Oscar.

cjl

[Oscar Vermeulen]

Charles,

Keep in mind though that the PiDP-8 has some extra tricks over simh. Such as the mounting of USB sticks as paper tapes (or as disk packs). No need to do any CTRL-E.

On Mon, 13 May 2019 at 19:20, CLASystems <clasy...@gmail.com> wrote:

BTW, back when this was a PDP-10 program and was simulating specifically a PDP-8/I ONLY and no other machines, it DID work, all the code them was written by Bob Supnik.

Oh! Would you perchance still have a copy of the PDP-10 emulator of the PDP-8? Seeing as I plan to come up with a KA10 'replica', that would complete the circle (and be an interesting bit of PDP-10 programming to chew on).

Kind regards,

Oscar.

[CLASystems]

On Mon, May 13, 2019 at 3:37 PM Oscar Vermeulen <vermeul...@gmail.com> wrote:

Charles,

Keep in mind though that the PiDP-8 has some extra tricks over simh. Such as the mounting of USB sticks as paper tapes (or as disk packs). No need to do any CTRL-E.

that sounds like an extremely quirky feature; some systems have to freeze the running executable if system resources are changed.  how is it done, and is it really "clean"? In SIMH, things can be mounted before or after the session, but not during.

On Mon, 13 May 2019 at 19:20, CLASystems <clasy...@gmail.com> wrote:

BTW, back when this was a PDP-10 program and was simulating specifically a PDP-8/I ONLY and no other machines, it DID work, all the code them was written by Bob Supnik.

Oh! Would you perchance still have a copy of the PDP-10 emulator of the PDP-8? Seeing as I plan to come up with a KA10 'replica', that would complete the circle (and be an interesting bit of PDP-10 programming to chew on).

Haven't seen it for decades, and the site I saw it on is also long gone.  That said, bitsavers might have some leads.  You can contact Bob himself on LINKEDIN, etc.

Kind regards,

Oscar.

[Oscar Vermeulen]

Charles,

On Tue, 14 May 2019 at 00:43, CLASystems <clasy...@gmail.com> wrote:

On Mon, May 13, 2019 at 3:37 PM Oscar Vermeulen <vermeul...@gmail.com> wrote:

Keep in mind though that the PiDP-8 has some extra tricks over simh. Such as the mounting of USB sticks as paper tapes (or as disk packs). No need to do any CTRL-E.

that sounds like an extremely quirky feature; some systems have to freeze the running executable if system resources are changed.  how is it done, and is it really "clean"? In SIMH, things can be mounted before or after the session, but not during.

It is quirky. An octal number on the IF switches determines the device (1 being the PTR), hitting the SING_STEP will trigger simh to do a mount of whatever .pt is found on a newly inserted USB stick on the PTR device.

Kind regards,

Oscar.

[Ron Pool]

On Monday, May 13, 2019 at 3:37:41 PM UTC-4, Obsolescence wrote:

Oh! Would you perchance still have a copy of the PDP-10 emulator of the PDP-8? Seeing as I plan to come up with a KA10 'replica', that would complete the circle (and be an interesting bit of PDP-10 programming to chew on).

I have no idea if it's what Charles is referring to, but I remembered seeing a reference to a PDP-8 emulator for the pdp-10 and spent a few minutes digging up where I saw it.

You'll find one listed as ITEM 10-102 (PDP-8 Simulator on the PDP-10) in the DECUS DEC-10/-20 program library catalog.  A copy of the catalog can be found at http://www.bitsavers.org/pdf/dec/decus/programCatalogs/DECUS_Catalog_PDP-10_Apr78.pdf.  You can find tape images for a lot of the stuff from that catalog at http://pdp-10.trailing-edge.com/.  The trailing-edge web pages seem to indicate that 10-102 is missing from trailing-edge's tape images, but when I check their list of files for tape "DECUS 10-LIB-1" in their index of that tape at http://pdp-10.trailing-edge.com/decuslib10-01/index.html, I see the files for that emulator:

    1       25(7)  <007> 43,50014 30-Sep-75 dcus:[43,50146]102.inf
   21     2688(36) <007> 43,50014  5-Sep-69 dcus:[43,50146]8kpdp8.sav
   17     2074(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]common.mac
    4      422(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]consol.mac
    5      596(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]core.mac
   17     2176(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]demo.sav
  254    32454(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]df32.fil
   16     2035(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]df32.mac
   34     4254(36) <007> 43,50014  5-Sep-69 dcus:[43,50146]driver.mac
    7      773(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]f.mac
   69     8832(36) <007> 43,50014  5-Sep-69 dcus:[43,50146]focal.tpe
    8     1004(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]line.mac
    2      153(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]lptser.mac
    3      269(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]memory.mac
    8      898(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]p.mac
    1       14(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]patch.mac
   17     2140(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]pdp8.mac
    3      311(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]ploter.mac
    5      606(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]ptape.mac
   30     3831(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]rm08.mac
    1       57(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]sim.ccl
   27     3434(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]sim.opr
    5      546(36) <007> 43,50014  4-Sep-69 dcus:[43,50146]tty.mac

Also in that same DECUS catalog is 10-248 (TR.MAC) which seems to be another PDP-8 simulator.  That one seems to be in tape "DECUS 10-LIB-6" whose index is in http://pdp-10.trailing-edge.com/decuslib10-06/index.html.  The files for this simulator seem to be:

    1       25(7)  <007> 43,50037 17-Feb-76 dcus:[43,50370]248.inf
   38    24205(7)  <007> 43,50037 17-Dec-75 dcus:[43,50370]pdp.8
  156    99625(7)  <007> 43,50037 17-Dec-75 dcus:[43,50370]pdp.lst
   13     8255(7)  <007> 43,50037 17-Dec-75 dcus:[43,50370]pdp.sav
   24    15155(7)  <007> 43,50037 17-Dec-75 dcus:[43,50370]s.
   11     6410(7)  <007> 43,50037 17-Dec-75 dcus:[43,50370]tr.lst
    4     2270(7)  <007> 43,50037  4-Oct-75 dcus:[43,50370]tr.mac

I'm not set up to read PDP-10 tape images, so I can't actually try extracting that tape to see if those files are in there.  One of these days I'll find time to get a PDP-10 and DEC-20 emulator going and play around with TOPS-10 and TOPS-20, but I'm still busy with SIMH versions of PDP-11s and VAXen and some of their OSs.

[CLASystems]

I can't comment on the second collection, but Don Witcraft had a hand in the first one.  He is one of the principal authors of TSS8.

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/rhb_YuwXRgs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/4173d266-131f-4a71-ac36-9f2e093decdb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Tockey]

Oscar and all,

I think that this only counts for half of the pain . . . (smile).

Has anyone actually been able to WRITE a .pt file onto a USB yet? Reading from USB seems to work fine, but I still haven't been able to, for example, put my own PAL-3 program onto a .pt file, assemble it using PAL-3, and get the .bn output on a .pt file on the USB.

If there is some magic to having the PiDP-8/i write to .pt files on a USB, I would sure like to know it.

-- steve

[Oscar Vermeulen]

Steve,

Writing to PTP USB sticks: It should work, because that was the intention. OTOH, I wrote it, so maybe I better check when I'm back in front of the PiDP-8 ;)

The last two years I've only used it for loading the BIN Loader and Focal.

Kind regards,

Oscar.

--

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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/58d5e289-7d16-442f-beea-088b9b52188e%40googlegroups.com.

[Warren Young]

On Tuesday, May 14, 2019 at 10:46:07 AM UTC-6, Steve Tockey wrote:

Has anyone actually been able to WRITE a .pt file onto a USB yet?

I haven't tried it, but from inspection of the code, you need to have a *.pt file on a USB stick that your Pi can mount without any help, then set DF=2 and toggle SING_STEP. The PiDP-8/I simulator won't just pick a *.PT file name and write to it on an empty stick.

put my own PAL-3 program onto a .pt file, assemble it using PAL-3, and get the .bn output on a .pt file on the USB.

There isn't a front-panel detach-and-unmount mechanism for PT-on-USB, so it's possible there's unflushed data if you do the SING_STEP + DF=2 -> save PAL edit buffer to PTP:, SING_STEP + DF=1 -> assemble -> swap sticks -> SING_STEP + DF=2 sequence you'd need for that. And the sequence is that simple only if you're happy getting an assembled binary out of the assembler: no map, no listing, and no CREF file. Those add additional passes, which require more media attachment and detachment.

Furthermore, the automatic media attachment mechanism just selects the first file it finds that matches its criteria and uses it, so you'd need at least 2 USB sticks to make this work, one for the PAL assembly input code and one for the binary output code. Add more for listing, map, and CREF output, else each pass overwrites some prior pass.

Personally, I'd just use Ctrl-E and SIMH att/det commands. That'll let you put everything onto one bit of external storage and name them intelligently based on what you're working on.

[Ian Schofield]

Dear Steve,

 Do I get the impression that you are trying to do a paper-tape development cycle on you PiDP8I? If so, that takes one back a bit! As Warren says, the current config for USB is really boot only. You need to att/det files to the PTP/PTR to get this going. After that, you need the patience of a saint to edit/build/run a 'reasonable' programme. To this end, I think significant effort went into providing the 4K disk operating system which could be used with a single 32k (word) DF32. When we got this for our 8/I, it was a breath of fresh air!!!! No more mounds of tape etc. And, 4K FORTRAN was not bad either. While I am in purist mode, I will risk a torrent of abuse by suggesting that this is the 'right' OS for the 8/I.

Also, to return to the title of this thread, we used a Tek 603 storage scope driven by a home-built DAC (like a VC8) next to our Tek 4014 for final output.

Regards, Ian.

[CLASystems]

On Wed, May 15, 2019 at 5:27 PM Ian Schofield <isy...@gmail.com> wrote:

Dear Steve,

Perhaps this is addresses to me, Charles Lasner [easy to get confused with so many back and forths.

 Do I get the impression that you are trying to do a paper-tape development cycle on you PiDP8I?

To be completely accurate, I am pointing out that my serious improvements to SIMH for use only on Windows makes it a serious development environment in general.  This gives you paper-tape, P?S/8 and OS/8,. more or less all at once.

For the training of true beginners, which I would hope would be young students, I want to show just how much a well-utilized storage device causes profound improvement, but inquisitive minds need to not just accept the words, they need to see for themselves.  As such, we need to largely recreate th original paper-tape environment "horns and all".

If so, that takes one back a bit!

If that applies to you now picture a new generation facing the same issues.  An important historic fact set regarding the PDP-8 is that it was several years before the storage devices for the machine became available.

Regardless of what was going on in DEC, we students at Brooklyn Poly, headed by Richard Lary [who is most famous for all of the following in no particular order:  The R-L Monitor System for TC01/TC09 and A SINGLE DECtape drive, POLY BASIC which was COMPLETELY DEVELOPED on the R-L Monitor System, oh, and OS/8.  While some of us did wind up working for DEC, I and the others who did not stayed with the R-L Monitor and spent well over a decade greatly upgrading it to what it is now, P?S/8.  [Some of the internal features and concepts are unchanged.]

But it is true, that DEC sold machines with nary a peripheral other than an ASR-33 Teletype.  We were "luckier" because we had a KSR-35 which meant we had no opportunity to face the "mischief" and waste of time and resources of paper-tape, etc.

As Warren says, the current config for USB is really boot only.

You need to att/det files to the PTP/PTR to get this going.

Correct, and in my PEPS for Windows version, there are icons to press to get that done as fast as you can click on them.

 

 After that, you need the patience of a saint to edit/build/run a 'reasonable' programme.

Agreed.  The purpose is to quickly transition students to more practical environments, but "first blood" is "drawn" from an extended paper-tape session IF all the components worked.

Sadly, while it is properly documented in among other things, the built-in SIMH help commands, the DUMP <memory ranges> <output filename> doesn't work, although it useless partially does.  You can get up to the command parse, the memory ranges, and a proper error if you leave the output file out.  But if you supply the file, you get some internal error because it is simply not all there.  That said, I suspect this is not a major amount of work to fix, but it should be sent "upstream" to Github so all SIMH implementations are fixed all at once, etc.

But yes. I have defined an editing session in the host Windows in your choice of several popular editors [some others are likely possible, but they have to conform, and a few at times didn't, fortunately, for example Notepad++ and EditPad now do.]

Then you invoke PAL III by loading it from the default directory inside of SIMH [The commands completely work, albeit the documentation is very meager, but it totally functions.  I can provide documentation on how to manage it, as I have already made all of this work in the Windows version,]

You set the front panel switches so PAL does an input from HSR and can punch to HSP.  You can also create a listing on the HSB and get that text-processed and cleaned up in the host environment using my infamous "STRIP" TECO macro that handles all known forms of malformed textual files, etc.  You can even get print-ready copy turned into PDF files on Greenbar wide-carriage "paper".  I can point anyone to examples of this on my archive on Ibiblio.org.

Created binary files can be loaded and started and use breakpoints in the SIMH command level.  It is quite complete and totally "invisible".  The BIN loader function is built in automagically allowing loading in anything, even the RIM loader or BIN loader or HELP loader if you really wanted to, etc.
 
But with the broken DUMP command, you cannot save your program, this the basics are all there, but for this want-of-a-nail.

Warren and I had a short off-group conversation, but the upshot is do not just add on frills over broken code.  The functionality that SHOULD be the dump command is all that is really missing.  I've made all the rest just tolerable enough to not frustrate a beginner, but clearly they will want to quickly move past paper-tape regardless.  [But when they satisfy themselves!]

To this end, I think significant effort went into providing the 4K disk operating system which could be used with a single 32k (word) 32. When we got this for our 8/I, it was a breath of fresh air!!!! No more mounds of tape etc. And, 4K FORTRAN was not bad either. While I am in purist mode, I will risk a torrent of abuse by suggesting that this is the 'right' OS for the 8/I.

The opening of the P?S/8 main keyboard monitor source file is a dedication to the Disk Monitor System, WITHOUT WHICH it has always run.  It would have been truly worthless compared to what we as a group did.  Please note that POLY BASIC is a standalone operating system just for BASIC and includes a multiple-stage compiler and loader, etc.  It is a sizable project, and the Disk Monitor System is simply outclassed here.  But the only difference is we had a single DECtape to work with but look what was accomplished.  I think you had an understandable situation.  Anything was better than where you were before, but we were developers with high goals, etc.

Also, to return to the title of this thread, we used a Tek 603 storage scope driven by a home-built DAC (like a VC8) next to our Tek 4014 for final output.

We had intermittent access to OTHER sites running the same software we created that had real lineprinters eventually, and at the beginning of P?S/8 development, we used a TOPS-10 system within easy driving distance, left with large stacks of lineprinter paper, files on PDP-10 DECtapes [which btw, SIMH supports!] and miles and miles of paper-tapes to be read in on an ASR-33 attached to an 8K 8/L where I worked, etc.

Some relevant PDP-8 history:
They wanted DEC to adopt my work in updating it to P?S/8 and there were two attempts at a demo to the most dullard managers you could imagine.

The staff loved it the first time, but the manager sandbagged me with a BS question:  He wanted to know NOT the RECOMMENDED amount of memory, but the MINIMUM configuration of memory, and I honestly told him 4K.  Merely for that reason alone he told be the following, no, DEC [meaning him!] cannot support this BECAUSE IT MIGHT DISCOURAGE MEMORY SALES.

The second one was even more pathetic.  It was a "shootout" where OS/8 looked mighty bad by comparison, and the manager FAKED the need to have to leave that very minute just to blow me off [knowing I had traveled six hours to get there and this was Friday].

Eventually, I sold limited rights to the then-current P?S/8 to the Intersil Corporation for use on their RX01-compatible-based Intercept I system.  So, instead of a donation to the school, I got some $CASH and retain full rights to the software.  We unearthed a copy of Intersil's manual for "IFDOS" as they called it, I agreed to remain 'invisible" to their customers.  A copy is available on my Ibiblio.org archive now if anyone wants to see where the system was well over ten years of additional work not yet performed.

For those of you who have had problems grasping enough of OS/8 to not shoot yourself in the foot just to get the basics of things, P?S/8 is generally learned by intelligent humans of all ages in about ten minutes.  It is best configured as an "adjunct" of OS/8 so both sr ystems can inter-communicate in the same SIMH session; this includes one boots the other either way.

Regards, Ian.

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/rhb_YuwXRgs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/f9f04024-2583-4131-941c-2325d3767ca3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Tockey]

Ian (and Charles),

Simulating PAL-III assembly is one interesting goal, but not the only one. Another problem is, for example, that the DecTape version of OS/8 (IF == 3) runs but it's fairly limited. One really big gap is that the system tape, DTA0:, doesn't have BUILD.SV on it so it essentially makes it a closed system. I have not been able to get either a new TC08 or TD8E DecTape driver to work reliably with any of the .dt files. So another use of .pt is to be able to (hopefully) transfer files like BUILD.SV and the device drivers around the various OS/8 system images so that I can really get them configured the way I want.

Thanks,

-- steve

[CLASystems]

All I can say is this is a non-issue on the Windows Version.

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/rhb_YuwXRgs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/a57b4697-d669-4713-9139-14e733b9d84b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Tockey]

That's great, but some of us avoid Windoze like the plague that it is . . .   :^)

Still, how can I get BUILD.SV and any relevant device driver .bn files onto the DTA0: DecTape for IF==3?

On Thursday, May 16, 2019 at 11:03:10 AM UTC-7, CLASystems wrote:

All I can say is this is a non-issue on the Windows Version.

cjl

On Thu, May 16, 2019 at 1:50 PM Steve Tockey <steve...@gmail.com> wrote:

Ian (and Charles),

Simulating PAL-III assembly is one interesting goal, but not the only one. Another problem is, for example, that the DecTape version of OS/8 (IF == 3) runs but it's fairly limited. One really big gap is that the system tape, DTA0:, doesn't have BUILD.SV on it so it essentially makes it a closed system. I have not been able to get either a new TC08 or TD8E DecTape driver to work reliably with any of the .dt files. So another use of .pt is to be able to (hopefully) transfer files like BUILD.SV and the device drivers around the various OS/8 system images so that I can really get them configured the way I want.

Thanks,

-- steve

On Wednesday, May 15, 2019 at 2:27:45 PM UTC-7, Ian Schofield wrote:

Dear Steve,

 Do I get the impression that you are trying to do a paper-tape development cycle on you PiDP8I? If so, that takes one back a bit! As Warren says, the current config for USB is really boot only. You need to att/det files to the PTP/PTR to get this going. After that, you need the patience of a saint to edit/build/run a 'reasonable' programme. To this end, I think significant effort went into providing the 4K disk operating system which could be used with a single 32k (word) DF32. When we got this for our 8/I, it was a breath of fresh air!!!! No more mounds of tape etc. And, 4K FORTRAN was not bad either. While I am in purist mode, I will risk a torrent of abuse by suggesting that this is the 'right' OS for the 8/I.

Also, to return to the title of this thread, we used a Tek 603 storage scope driven by a home-built DAC (like a VC8) next to our Tek 4014 for final output.

Regards, Ian.

--
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/rhb_YuwXRgs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/a57b4697-d669-4713-9139-14e733b9d84b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Warren Young]

On Thursday, May 16, 2019 at 12:29:28 PM UTC-6, Steve Tockey wrote:

how can I get BUILD.SV and any relevant device driver .bn files onto the DTA0: DecTape for IF==3?

In the latest release, the default IF=3 media does now include BUILD.SV. If you're on a prior release, it won't have that.

If you did upgrade, then you need to follow one of the paths documented in the Overwriting the Local Simulator Setup section of the top-level README.md file. Briefly, you're still using old media from a prior release, which wasn't overwritten by default, on purpose.

As for the device drivers and other customizations, you can achieve that through a small matter of os8-run scripting. That's the very sort of use case Bill Cattey designed it to support.

[Frederic RIBLE]

Hello,
Here is an update with a small stability fix: https://www.dropbox.com/s/omkou2juyfkq6xf/pidp8i-vc8e-2019-05-18.tgz?dl=0
Integration with upstream SIMH will not be so easy because my modifications are based on the already heavily modified sim_video.c by Ian.
I will need help on that topic.
Frederic.

--
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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/5d75f4cf-29d1-4be2-83cc-58924be8307f%40googlegroups.com.