Share your demo procedures?

[Dylan McNamee]

Now that I'm done building (and it worked the first time -- woohoo!), I want to show it off to my friends and family. Yes, they're a patient lot.

I had luck getting into adventure once, but I've either messed up that disk pack, or forgotten which settings I used to get there. I've been getting lots of TAPE READ or "no unmounted ... found" messages, so I think I'm manipulating the "device select" switches wrong.

With all the switches off, a fresh boot gives me a long directory listing, but I can't find anything cool to show off among those files. I know I'm in for a bunch of manual-reading, but the manual won't talk about the fancy front-panel media switching setup. :)

Please share your fun things to do, but a tutorial of how to get around the mode-switching would be great. Oscar's video helps, but I'm not sure if it's in sync with our software.

I'm fairly confident with the basic "here's how you stop, write down the PC, load an address, examine the memory for a few locations, re-enter and load the PC, and resume" kinds of actions, which is a nice demo itself! The next level of comfort has eluded me so far.

thanks,

dylan

[Obsolescence]

Dylan,

On Thursday, July 23, 2015 at 5:35:42 PM UTC+2, Dylan McNamee wrote:

Oscar's video helps, but I'm not sure if it's in sync with our software.

The video is of the prototype machine, which is out of date because it used sing_step + sing_inst as a mount command.

That's changed - see the web pages and the picture below:
 

In terms of demos: The demos on the web site *should* work as described there. This is what I use to test:

Running Adventure:
after booting into OS/8, just "RUN RKB0 ADVENT"

Running Life:after booting into OS/8, "R BASIC", "OLD", "RKB0:LIFE", "RUN".
then, enter a pattern to start with, like
  xxxxxx xx
 xxxx xxx xxx
xxx xxxx
z

(z starts the simulation)

Focal from USB paper tape
The '1969' demonstration with USB sticks as paper tapes:
See the two paper tape image files in /opt/pidp8/imagefiles/copytoUSBsticks. Put the bin loader on the first USB stick, Focal on the other stick.

Now...

* reboot the PiDP into RIM Loader state by setting IF to 001, hit Sing_step. Set IF back to 000.
* hit stop.
* Insert BIN Loader USB stick. Wait 10 seconds for it to get recognised, set IF to 001, hit Sing-step. BIN loader is now mounted. Set IF back to 000.
* set address to 7756, hit Load_addr, then start. After 1 second, hit Stop. BIN loader is now in.

* Set DF to 001, insert second USB stick, wait 10 secs, hit Sing_step. Focal tape is now mounted. Set DF back to 000.
* Set address to 7777, hit load_addr, set address to 3777, hit start.
* wait until PDP-8 halts, set address to 0200, hit load_add, then hit start.

Focal now greets you with a *. Type PRINT "HELLO WORLD to astonish the gathering crowd.


Regards,

Oscar.

[Obsolescence]

Correction:

Instead of

   Focal now greets you with a *. Type PRINT "HELLO WORLD to astonish the gathering crowd.

Read

  Focal now greets you with a *. Type _TYPE "HELLO WORLD to astonish the gathering crowd.

Because PRINT, of course, is not a Focal command. It's what is used in this big bloated new Basic language. Not Focal...

[Norman Davie]

A number of demos with source are on GRC.com.
I haven't built my unit yet, but I plan on getting these running.

Deep Thought
blinkenlights level 2
https://www.grc.com/pdp-8/deepthought-sbc.htm

Lights out
A logic game.
https://www.grc.com/pdp-8/lightsout-sbc.htm

[Tim Goldenburg]

I'd love to see how far you get with Deep Thought.  After getting my PiDP working tonight, I made a bumbling attempt, and didn't get too far.

I created a /opt/pidp8/bootscripts/5.script with the following in it (it's just Steve Gibson's source https://www.grc.com/pdp-8/deepthought-sbc.htm in a format readable by simh):

d 00000 0000

d 00001 2165

d 00002 5053

d 00003 7604

d 00004 7041

d 00005 1172

d 00006 7440

d 00007 5012

d 00010 2166

d 00011 5051

d 00012 4057

d 00013 3000

d 00014 4057

d 00015 6206

d 00016 0012

d 00017 0001

d 00020 4057

d 00021 0156

d 00022 7450

d 00023 1151

d 00024 1154

d 00025 7410

d 00026 5124

d 00027 3170

d 00030 7404

d 00031 3172

d 00032 1172

d 00033 0152

d 00034 7001

d 00035 3046

d 00036 1172

d 00037 7002

d 00040 0152

d 00041 3163

d 00042 4057

d 00043 0163

d 00044 7001

d 00045 4067

d 00046 0000

d 00047 7040

d 00050 3166

d 00051 1162

d 00052 3165

d 00053 6046

d 00054 1170

d 00055 6005

d 00056 5400

d 00057 0000

d 00060 1171

d 00061 4067

d 00062 5545

d 00063 1157

d 00064 3171

d 00065 1166

d 00066 5457

d 00067 0000

d 00070 3167

d 00071 1155

d 00072 3164

d 00073 3165

d 00074 3166

d 00075 1167

d 00076 7104

d 00077 3167

d 00100 7420

d 00101 5107

d 00102 1467

d 00103 1165

d 00104 3165

d 00105 7420

d 00106 2166

d 00107 2164

d 00110 5115

d 00111 7300

d 00112 1165

d 00113 2067

d 00114 5467

d 00115 1165

d 00116 7104

d 00117 3165

d 00120 1166

d 00121 7004

d 00122 3166

d 00123 5075

d 00124 7200

d 00125 3171

d 00126 1161

d 00127 3130

d 00130 6211

d 00131 7200

d 00132 1171

d 00133 0153

d 00134 1160

d 00135 3571

d 00136 2171

d 00137 5132

d 00140 1130

d 00141 1151

d 00142 3130

d 00143 1130

d 00144 0156

d 00145 7440

d 00146 5130

d 00147 6201

d 00150 5012

d 00151 0010

d 00152 0077

d 00153 0177

d 00154 0200

d 00155 7764

d 00156 0070

d 00157 0541

d 00160 5200

d 00161 6211

d 00162 7770

g

It appears to work, but it's so fast that I cannot get the lights to slow down with any of the switches.  I tried throttling simh down to .333 MIPS with 'set throttle 333K', but that didn't seem to slow it down either.

[Obsolescence]

By the way: I believe that the OS/8 disk cartridges that are the default boot for the PiDP originate from GRC.com. There's tons of games on them as described on his web site. just DIR RKB0:

Regards,

Oscar.

[Paul R. Bernard]

Tim Goldenburg <tim.gol...@gmail.com> writes:

> I'd love to see how far you get with Deep Thought.  After getting my PiDP working tonight, I made a
> bumbling attempt, and didn't get too far.
>
> I created a /opt/pidp8/bootscripts/5.script with the following in it (it's just Steve Gibson's source 
> https://www.grc.com/pdp-8/deepthought-sbc.htm in a format readable by simh):

...

> It appears to work, but it's so fast that I cannot get the lights to slow down with any of the switches.
>  I tried throttling simh down to .333 MIPS with 'set throttle 333K', but that didn't seem to slow it
> down either.

Those programs on his site will probably need to be modified to work the
same on the PiDP-8. It's been a while since I read them so I'm working
from memory here, but the problem areas will be:

1) It makes one or more calls on a service routine that is on the
SBC-6120 that isn't in a genuine PDP-8. (I can't remember what that's
for.)

(The front panel on the 6120 is driven by an interrupt handler running
on the machine (that wouldn't be present on a real PDP-8) that obtains
and exposes the registers inside the single chip processor to the front
panel for display.)

2) He's outputing characters on the TTY and waiting for the interrupt.
This is to generate the delay. This is almost certainly what your
problem is. It appears in my playing with PiDP-8 that the rate of
character output is far in excess of 10 cps that you would get on a real
PDP-8. There might be a "stty" command line trick on linux to slow the
output down when output is going to a pseudo-tty. This would be a case
for using the optional serial line (set for 110 baud) on the PiDP-8, or
in software with that newly-released nifty CLK device.

- paul

[Dylan McNamee]

I bumbled into exactly the same place with Deep Thought, and also tried a similar trick with Lights Out. It also doesn't work - lots of blinking lights, but no response to the panel switches. I would post my set of deposit commands for Lights Out, but I'm guessing it's of no use yet. My guess is (maybe) the CALLBIOS command that seems to be unique to the SBC6120. Hrm.

dylan
--

[Dylan McNamee]

I just toggled in a simple program that causes the "Multiplier Quotient" lights to count up (I was getting worried that I hadn't seen them doing anything) and the accumulator to count down. It's small enough that this is a pretty great toggling demo. I got the program from here: http://dustyoldcomputers.com/pdp8/pdp8i/testprogs/acmqblinker.html

Once you're tired of toggling, here's a script (maybe save as 5.script in bootscripts?):

d 0000 2020 
d 0001 5000 
d 0002 7200 
d 0003 1021 
d 0004 7421 
d 0005 1021 
d 0006 7040 
d 0007 2021 
d 0010 7000 
d 0011 5000 
g 0000

pretty cool!

[Ed Fox]

Thanks...it is a nice demo program and a good way to check out the PiDP-8.
ED

[Rick Murphy]

Here's one that uses TECO to calculate the digits of PI.

A Pi calculating PI :)

.R TECO

*i100$$

*GZ0J\UNQN"E 40UN ' BUH BUV HK

QN< J BUQ QN*10/3UI

QI< \+2*10+(QQ*QI)UA B L K QI*2-1UJ QA/QJUQ

QA-(QQ*QJ)-2\ 10@I// -1%I >

QQ/10UT QH+QT+48UW QW-58"E 48UW %V ' QV"N QV^T ' QWUV QQ-(QT*10)UH >

QV^T @^A/

/HKEX$$

3141592653589793238462643383279502884096548392828580051774206964461331476026438773944051683122394366

The "*" is TECO's prompt. The "$" aren't really dollar signs, you press ESC for those.

The first command, "i100$$" inserts the number of digits to calculate (100) into the buffer.

Then the rest of the line noise does the calculation. You can increase the number of digits, but it'll run more slowly as it goes up.

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To 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/3d8fdcad-cebb-488f-a55d-c96a276372c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

[J. E. Myers]

Thanks Rick for the post!

Program works great!  I love that the Pi is calculating Pi...

Works great key'd in, but I have been having trouble scripting it.  Sure it's a TECO thing, that I will eventually figure out..

J. E. Myers

To unsubscribe from this group and stop receiving emails from it, 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/3d8fdcad-cebb-488f-a55d-c96a276372c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Radwan]

Are there any text scroller programs for the PDP8? Something that would scroll letters across the LEDs on the front panel like a crawl/stock ticker?

[Dylan McNamee]

I've been working on a "deep-thought" like program of my own (because creating them is as much or more fun than just running them). I've got it going now, and thought I'd share with the group. I've attached source (.pal) and binary (.bin). Link to short video of it running.

To run the binary, you have two options:

1) scp the .bin to your Pi, then at the simh> prompt:

simh> load /home/pdp/gray.bin
simh> g 200

2) load it into your OS/8 hard drive image:

.
type <ctrl-e> to halt SIMH
simh> at ptr /home/pdp/gray.bin
simh> c
R PIP
*GRAY.BN<PTR:/I
^ (press return here to actually load the tape image)
* (press ESC here to exit PIP)
.LOAD GRAY.BN
.SAVE SYS GRAY
.R GRAY

and from now on, GRAY.SV is on your hard-drive, so R GRAY will work.

This was a fun exercise - I hope some of you enjoy it.

dylan

(If you try to assemble the PAL source, I found some PAL assemblers don't support all of the opcodes - I changed mine to support them, and could post a link to the github repository with that modified assembler, if there's any interest).

[David Ray]

This is cool.  Thanks.  Got it working.  I had to use /home/pi/gray.bin since my account is pi rather than pdp.  I guess using ~/gray.bin does not work.

Oh... just looked at your video.  My Step Counter light don't cylon like yours.  Wonder why.

Thanks for this,

David

[Jeremy Radwan]

On Wednesday, March 23, 2016 at 9:23:29 PM UTC-4, David Ray wrote:

Oh... just looked at your video.  My Step Counter light don't cylon like yours.  Wonder why.

Hmmm ... I get the cylon effect in the step counter LEDs when I run GRAY. I assume you've tested and know those LEDs work? 

[David Ray]

Yes.  You got me wondering and I went and ran Paul Bernard's pidp-test program.  I get good step counter LEDs there.  But none in GRAY.  odd.

[slob]

There are bugs/shortcomings in SIMH explained in the "step counter indicator lights" thread that will prevent these from working (at least with the code as packaged dated 12-15).  Following the instructions in those posts, I modified the source and recompiled the code. I'm not sure if anything newer is posted.

PDP8 programs that are written for the emulator won't light those until the pidp8 program is updated, even if they are specifically written to use them.  Programs written for native Linux and then run outside the emulator can, assuming that the hardware is OK.

[Jeremy Radwan]

On Sunday, March 27, 2016 at 10:28:41 PM UTC-4, slob wrote:

There are bugs/shortcomings in SIMH explained in the "step counter indicator lights" thread that will prevent these from working (at least with the code as packaged dated 12-15).

Ah, right! I forgot I had made those changes ... that's why I have the SC lights working in GRAY. 

 

[slob]

I'm still sorting out what peripherals I will use with my machine (I've tried out a Panasonic printing terminal and a VT320). For a little more accuracy in terms of computing era, I have a spare ADM-3A (restored with new tube!) to use. I plan on hooking up a paper tape reader that I am working on. I can make paper tapes on genuine unobtanium DEC fan or roll tape.

I have raised eyebrows at work by VPN'ing into my network at home and using Attachmate's telnet client (FREE, and really good) to SSH to the machine and then log in to TSS/8 and then run a BASIC program - on an iPhone! Being text based, this uses virtually no wireless data. Don't forget to turn off the VPN when you are done, though :).

One very strange thing I have found is that for some reason, I can telnet from OS/X all day ,no problemo on TSS/8 with two serials and two telnet attachments all running simultaneously. HOWEVER, if I use PuTTY on Windows to make the connection instead of OS/X this crashes simh instantly. The Microsoft telnet client, same deal.

[Bill Wuttke]

It looks like most PiDP-8'ers are running demo programs to make the blinkenlights blink. I've taken a different route - programming demos using the ASR-33 for input and output. I've started posting my PiDP-8 vintage computing experiences, along with videos, to my new blog: https://oldfellowstoys.net.

Bill

[AB]

oh my that is a beautiful teletype :-)

[sunnyboy010101]

I've been spending my time playing with old FORTRAN programs I wrote in Engineering grad school back in the early '80s. So far I have many of them working, and it's great to be able to duplicate ancient work on this little device.

My only regret so far is that OS8 FORTRAN does not support double precision. There are lots of numerical methods that won't converge to a solution with only single precision.

I'm finding a few other quirks in the OS8 FORTRAN compiler but so far nothing that has killed an old program. It's great fun watching the lights go crazy on some of the more calculation intensive programs. None have endless loops, but a few take quite a long time to finish.

[Bill Wuttke]

Finally got blinkenlights working to the tune of the teletype:

https://www.youtube.com/watch?v=B8T8wLG1ZDM

[slob]

DAT SOUND...brings back memories.  I haven't had my hands on one since 1974 and I still know it.

[Peter Willard]

I agree.  I've not been around one since 1979 and it still feels like *home* to hear that.  I had one that sat 10 feet from me in the office that printed everyone's email (in the days before everyone had a VT terminal attached to a network connected host)

[Neil Higgins]

78 or 79 since I put hands on an ASR33. Man they were amazing machines.

[Remy van Elst]

Here is a very basic article on toggling in a shifter program: https://raymii.org/s/articles/Toggling_in_a_simple_program_on_the_DEC_PDP-8_and_PiDP-8_using_the_switch_register.html

Most of the contents is from here: http://retrocmp.com/projects/blinkenbone/simulated-panels/251-blinkenbone-playing-with-the-pdp8i - with details and screenshots added.

Op donderdag 23 juli 2015 17:35:42 UTC+2 schreef Dylan McNamee:

[Paul Duncan]

First thing I did was copy this procedure from a real PDP-8:

https://www.youtube.com/watch?v=DPioENtAHuY

[Cristian Arezzini]

Hello,
I too have been looking for a nice demo program, and as I said on my "presentation post", I wrote a script that's "almost perfect" for my needs...
I just entered the TECO "Calculate Pi" program, then immediately after running it, I saved the machine state.
Then I replaced the script #5 with my own, that does the following:
- loads the saved state
- slows down the CPU so that it only executes about 15 instructions per second
- Resumes execution.

This results in a very impressive show; it's definitely not random, you can see it's actually *doing* something. There are several different patterns you can recognize.
For me, the "key" is the CPU slowdown, which I obtained with the command "set throttle 1/17" (meaning it executes an instruction and then pauses for 17 milliseconds). Different values of course give different speeds.

Now, if only I could find a complex program that also uses the bottom "multiplier" LED row... :)

Also, my method is pretty "brute force", and not very efficient (i.e. I had to save the whole machine state). It would be better to just pass the commands to run TECO and enter the program into it and run it... but I don't know how to do that... :)

Cristian Arezzini

[Warren Young]

On Thursday, October 12, 2017 at 3:05:42 AM UTC-6, Cristian Arezzini wrote:

my method is pretty "brute force", and not very efficient (i.e. I had to save the whole machine state). It would be better to just pass the commands to run TECO and enter the program into it and run it... but I don't know how to do that... :)

I took that as a challenge.

A few minutes ago, I checked a new demo program into the PiDP-8/I software project repository which builds atop the same mechanisms we've been working on for the past few months to build OS/8 disk images in a repeatable, reliable, configurable fashion. These mechanisms let us drive SIMH and OS/8 with commands from the outside.

With a few minor extensions and a whole lot of refactoring, I was able to make these mechanisms useful to other programs, starting with this TECO pi demo program.

To see it run, just check out the tip of trunk and say "make". Then say "bin/teco-pi-demo" to start it running.

If you're doing this on a multi-core Pi, be sure to disable the ILS by reconfiguring with --no-lamp-simulator because the check to automatically disable the ILS happens too early in the simulator startup process for our demo to trigger it. The ILS utterly fails when you use the ratio form of SET THROTTLE command. (This is documented.)

[Gordon Henderson]

On Thu, 12 Oct 2017, Cristian Arezzini wrote:

> Now, if only I could find a complex program that also uses the bottom
> "multiplier" LED row... :)

Not at all complex but when testing some stuff I did this:

http://unicorn.drogon.net/pdp8/larson.pal

Gordon

[Ian Schofield]

Dear Gordon/All,

Love the Larson demo. However, a bit fast on an unthrottled PiDP8 and, for those of you who might type this into OS/8, the data lines are too long for PAL8. Here is an updated version.

Regards, Ian.

[Gordon Henderson]

On Thu, 12 Oct 2017, Ian Schofield wrote:

> Dear Gordon/All,
>
> Love the Larson demo. However, a bit fast on an unthrottled PiDP8 and, for
> those of you who might type this into OS/8, the data lines are too long for
> PAL8. Here is an updated version.

Thanks.

One day I'll get OS/8 going - got to write the RK05 driver in my own
emulator first, although that's creeping to the top of my to-do list.
Right now I'm using palbart on the Pi Zero and tape loading.

My aim to make it cycle accurate to a real 8/I or 8/E and I think I'm
close, however in about 2 weeks time I'm hoping to have my hands on a real
8/I and an 8/E to compare and tune.

Gordon

>
> Regards, Ian.
>
>
> On Thursday, July 23, 2015 at 4:35:42 PM UTC+1, Dylan McNamee wrote:
>>
>> Now that I'm done building (and it worked the first time -- woohoo!), I
>> want to show it off to my friends and family. Yes, they're a patient lot.
>>
>> I had luck getting into adventure once, but I've either messed up that
>> disk pack, or forgotten which settings I used to get there. I've been
>> getting lots of TAPE READ or "no unmounted ... found" messages, so I think
>> I'm manipulating the "device select" switches wrong.
>>
>> With all the switches off, a fresh boot gives me a long directory listing,
>> but I can't find anything cool to show off among those files. I know I'm in
>> for a bunch of manual-reading, but the manual won't talk about the fancy
>> front-panel media switching setup. :)
>>
>> Please share your fun things to do, but a tutorial of how to get around
>> the mode-switching would be great. Oscar's video helps, but I'm not sure if
>> it's in sync with our software.
>>
>> I'm fairly confident with the basic "here's how you stop, write down the
>> PC, load an address, examine the memory for a few locations, re-enter and
>> load the PC, and resume" kinds of actions, which is a nice demo itself! The
>> next level of comfort has eluded me so far.
>>
>> thanks,
>> dylan
>>
>

> --
> 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/50d24504-70b0-4cdf-a37a-24376b55e7e3%40googlegroups.com.

[Cristian Arezzini]

Il giorno giovedì 12 ottobre 2017 15:06:26 UTC+2, Warren Young ha scritto:

A few minutes ago, I checked a new demo program into the PiDP-8/I software project repository which builds atop the same mechanisms we've been working on for the past few months to build OS/8 disk images in a repeatable, reliable, configurable fashion. These mechanisms let us drive SIMH and OS/8 with commands from the outside.

With a few minor extensions and a whole lot of refactoring, I was able to make these mechanisms useful to other programs, starting with this TECO pi demo program.

To see it run, just check out the tip of trunk and say "make". Then say "bin/teco-pi-demo" to start it running.

Warren, forgive me but I'm a bit lost. I don't understand how to install and run it. I assume it's not just a normal pidp script? Remember I'm using an almost-stock PipaOS SD image.
Should I update the whole simh environment? I have no idea how to do this...
I don't even have a ~/pidp8i folder. But I have a /opt/pidp8 folder (without the "i" at the end). Should I install fossil (which is not on my system) and run it on that folder? I'm a bit afraid of breaking my system...

Since it seems that your OS version is much more supported, I may even just switch to that, instead of pipaOS, though I'll be sorry to loose all my current personalisations (besides the faster boot, that is)...

Cristian

[Cristian Arezzini]

Il giorno giovedì 12 ottobre 2017 19:52:18 UTC+2, Ian Schofield ha scritto:

Love the Larson demo. However, a bit fast on an unthrottled PiDP8 and, for those of you who might type this into OS/8, the data lines are too long for PAL8. Here is an updated version.

Again, forgive my "noob" question, but... How do you run these programs on the pidp? And for that matter, how do you even transfer a file to the Pi without physically disassembling the pidp and removing the sd card? (I'm connecting via ssh)...

Cristian

[Gordon Henderson]

If you can ssh, then you can run scp or rsync. These are both file-copy
programs that work using ssh.

As for running - right now I'm using an assembler called palbart which
runs under Linux and produces a .bin file - under simh, you simply

load larson.bin
run 200

and off it goes. No need for any OS, etc.

Although you raise an interesting point - how are people getting
programs/data to/from RK05 disk images when using OS/8? I'm assuming paper
taping them via simh (to/from Linux-side files), but is there another way?
(Anyone written a fuse mounter for OS/8 disk/tapes?)


Gordon

[clasystems]

On Thursday, October 12, 2017 at 1:52:18 PM UTC-4, Ian Schofield wrote:

Dear Gordon/All,

Love the Larson demo. However, a bit fast on an unthrottled PiDP8 and, for those of you who might type this into OS/8, the data lines are too long for PAL8. Here is an updated version.

Regards, Ian.

I see you've stumbled on to yet another idiotic aspect of PAL8.

Try having conditional assembly and your line is truncated at an arbitrary point and by luck what IS seen happens to be syntactically without reported errors, but not what you wanted!

Here is a partial explanation.  I say partial because there is somehow an anomaly in the restriction.  [Meaning it is not quite consistent to its own limitations.

All of the other assemblers in all PDP-8 systems all the way back to present day all do assembly [on a fundamental level] proceed as follows:

Read the input file until you find the end of the statement [either the end of the line OR a semi-colon.  Nothing fancy, just straight-forward.

PAL8 DOES NOT WORK THAT WAY!!!

Go read the source code if you want to do your own due dilligence.

PAL8 reads the source code into a buffer within PAL8.  The source code is processed until the end of the line always.

THEN the source code is read OUT OF THE BUFFER.  If a semi-colon is encountered, you can have multiple statements.

However, any characters that didn't make it into that internal buffer are THROWN AWAY.  There is a hard truncation [well, see below].  But before the line is parsed, the input fileis advanced to after the end of the line [CR, LF is ignored]

Note that this method is pathetic, amateurish and just plain wrong.

I have a theory as to WHY this was done [which leads perhaps to why the anomaly; see even further below]

I think the original fool who "wrote": this turkey had no idea how it worked when he "lifted" it from some other system [There are various theories here; perhaps he was someone who got a D+ in some college course and should have admitted it wasn't for him, or he just wanted to get it over with.  This is unimportant it's his "legacy" to us.

I can tell you a few historical facts:

1) Richard Lary needed a lot of help to get the original PS/8 out in a somewhat functional way past the virtually non-functional demo the suits insisted be used, and in the process alienated the other four best PDP-8 programmers there ever were.

2) I have the dubious distinction of being the fifth person to turn him down and he agreed with my reasoning to develop his far superior R-L Monitor System.  P?S/8 is the result of literally thousands of man hours of work past that point.

However, I did agree to USE it and be one of a bunch of people providing (negat9ve) feedback.  The name of that early group was "the software buffer".  Some people may even find some of these early documents.  I am certain some have been found under a more formal name.  Bill Cattey can provide some of that info, etc.

I found MANY things wrong with it that precluded my ability to use it at all.  For example, before they fixed the memory sizing bugs, I couldn't even run it on our 8K PDP-8/L because the illogic decided the machine was always 32K.  At first they laughed at me because they couldn't reproduce the bug, but eventually they agreed I was correct.  You cannot claim you cannot reproduce the problem unless you in fact try it out on the SAME COMPUTER!  Eventually someone else got the identical results, and eventually there was a replacement memory sizing routine that worked correctly on all of the models. Turns out others complained about different configurations also failing for alternate reasons and once it was implemented, the new routines worked on all machines, etc.

But I did manage to get Richard Lary to work on PAL8 because of many OTHER problems that surfaced because of this bad hack of a benchwarner they hired to create it in the first place.  Eventually Richie actually APOLOGIZED to me personally, saying essentially he hadn't realized just how bad it was, and very quickly he fixed a lot of things all at once to make ot "tolerable" but had to move on to other things they insisted be done, etc.  And yes, he nominally made it a lot better, thus for the most part it became on a scale of  0 to 1 useful.  But it still had this inept design flaw.

I believe I understand the reason why this clod did what he did [which should an utter disregard for understanding just how the PDP-8 assembly language is all about]..

Some other assemblers did not understand the concept of horizontal tab.  For PARSING purposes, it is equivalent to a space character.  For PRINTING purposes, it creates part of a printout line that has the align to nearest 8 colums requirement.  This is a subtle point but you have to understand this:

The actual printed output of a successful assembler aligns the output to a multiple of 8 spaces, however this is only with respect to an arbitrary starting point in the printout.  All that comes before this is NOT ALIIGNED.

If you look at any output in any proper assembler, there is no specific requirement for how many columns of assembller-produced output to the left of the starting point actually is used.  But then this becomes the starting point for the aligned output.

For example, in P?S/8 PAL, [as in TOPS-10 PAL10, the cross-reference option may be in effect.  This means the listing output is prepended with a statement number [NOT a line number!].and other output which in fact is varied by the number of command-line options.  [Brief partial explanation.  A listing has some binary output thus addresses and generated values; others have the line number which changes things;  PAL8 dies NOT support cross referencing at all!  Instead the LISTING file of PAL8 is post-processed by CREF which is not only a time-consuming process it is quite flawed.  For example, of you use commentary by the form of unassembled failing conditionals, commonly done, CREF cross-references the comments as individual words, instead of just ignoring all of it.  It doesn't check to see there is no associated binary lines at the left margin, etc. and of course, you see LINE numbers and not STATEMENT numbers.  To add insult to injury, CREF numbers in 13-bit arithmetic, thus you get line 1 through 8191, and then it doesn't quite start over again, it starts over at 4096 so for longer assemblies, the cross-reference output is inherently anomalous.  In any case, P?S/8 PAL numbers to statement number 99999 merely because we felt to allow even longer assemblies was unlikely and would cause the printout of every line to be always one column wider.  To date, this has been a wise decision, but there are assemblies longer than what feeble CREF can handle.  In fact, CREF cannot fully CREF the source code of P?S/8 PAL ironically!  You have to use the so-called "mammoth" option and the symbol table has been optimized [symbol name balancing" to favor the CREF internal rule of pass 1 only does statements below LGNNNN and pass 2 does LGNNNN and symbols sorting higher.  Several times over the active development lifetime, symbols were arbitrarily renamed to help out CREF, etc.  But eventually that also didn't work and the only way is to also NOT cross-reference literals.  Fortunately, literals are only used for once-only initialization  code thus, this is merely pathetic, but not serious.]

Thus, the correct method is to output whatever is prepended to the leftside of output lines, and that establishes an offset value.  Using the offset value, as a HT character is encountered, the proper column to the nearest multiple of 8 spaces is calculated, and the correct number of spaces is printed accordingly.

But in PAL8, as HT is encountered in the source line, the correct number of spaces is put into the internal parsing buffer!  Yes, this means that it is ALWAYS true that the actual source line is not parsed for assembly, but rather a derivative of it with extra space characters!.  This in turn makes the effectiveness of this internal buffer even lower.  [Thus, the truncation point is made even more prematurely for wide-line input.

I cannot fathom any worse a method for a clod to come up with to misunderstand and ruin the assembly process, but there is a small "flaw" in my reasoning:

It has to be slightly worse than I describe.  Why?

Because there is an anomaly I can't account for.  I leave it to someone else to get disgusted reading the PAL8 source code to experience first-hand all I have said already, and then still be motivated to find the additional problem:

I tend to write code with as wide a comment as I possibly can.  [I'm sure none of you are surprised.]  The more commentary the better.  This was taught to me by Ed Yourdon who was a schoolmate.  [He's the guy who scared everybody about the Japanese taking over the software community and also Y2K, not one of his better moments.  But feel free to Google him.]

One thing I have learned over the years.  If you are so foolhardy to thing you don't need deep commentary on your own code, it will never work.  You'll have to perpetually rewrite it from scratch because NO ONE can remember what their code did later.  the time frame might vary, but you are delusional if you believe you can figure out your own uncommented code later.  [Newbies haven't been programming long enough to even know when ";later" starts.  I can tell you from experience I worked on a single project for about six months [with two others] and I could not just read the code words to understand what I wrote a few months earlier when I had to go back and review what I had done to then-presently write some additional code that had to reference it.  The comments saved my ass.  [Sometimes, years later, I look at the code and say, how does this work, refer to my former self's comments and say, that's a great piece of code.  I honestly don't remember writing it,  But the point is the comments make the code self-sufficient regardless of who has to maintain it.  Good programmers learn this with age.  Bat ones are doing something else, like flipping burgers.

Back to the specifics

Off the top of my head, this is the correct number, you can derive it if you want to know [the number is not what is important, the concept of the specifics of the limitation are].  If you write a line consisting of the following:  Start the line with a / and then an HT and then free-form text without HT until you get to the magic number [which means that some comments will exactly fill the line to the limit, some won't, but none will ever be wider] then in the PAL8 output you will see every intended character.   If you go past the magic limit column, it will be [harmlessly in this case] truncated [ruining the commentary].

That said, if the line is a code statement [which starts with the address and perhaps the code word in octal] then the input is truncated TWO COLUMNS to the right.  [It's probably due to some fortuitous bug and the length of the parse buffer has a safety margin of some columns normally not having the real source line characters transferred into].

Thus, when you are trying to figure out how you must adjust your input so PAL8 can handle it, remember you are on a fool's errand caused by the incompetence of another fool who was not properly supervised.

This is why I am anticipating the removal from my own methods of having to require the P?S/8 source files be  completely PAL8 compatible.  In the very early days, this was required because we simply didn't have enough access to PAL10.  It was a semi-reasonable road trip to the nearest PDP-19 installation, but was clearly impractical when OS/8 became tolerable [yet hated constantly].

However, with the arrival of the quite nice fully functional SIMH [it was years ago just a useless toy by any standard] the situation has changed.  I can assemble with P?S/8 PAL while performing source editing in the host [Windows] environment.  When I finish all of the legal difficulties and I can release PEPS to the PD, I strongly suggest you abandon working on any PDP-8 work on the PiDP-8 and develop any and all programs on PEPS and then bring back the compatible device images to the PiDP-8 to run them;   It's a far easier environment to write code in [and a lot more fun].  [And of course, I do not believe in less is more; nice to have both to achieve the best of both words, etc.]  If anyone has checked out what I have done with PEPS with regards to FOCAL, 1969 [available on ibiblio,org] you can get an appreciation for just how much more can be done in that environment, etc.

In any case, I now only use PAL8 when I believe it will still be necessary for the present; i have to revamp some ugly kludged mechanisms I need to generate P?S/8 from itself.  Currently it depends on OS/8 in two ways, the first of which is arbitrary and can be just jettisoned; the second will take some effort, and there will be transitional phase where i write some support that actually helps OS/8 users as a side-effect.].  This will also allow me to take advantage of the super-set features of P?S/8 PAL which have come up in other projects [such as conditional literals and additional assembler directives, etc.].

A side issue:  The PAL language is strictly upper-case.  P?S/8 OS8CON automatically upper-cases the input so can assemble this program without change.  [OS/8 PAL8 still won't be able to unless you rewrite the data lines, which is unreasonable since they are fine in ALL other assemblers.]

cjl

[Warren Young]

On Thursday, October 12, 2017 at 5:38:44 PM UTC-6, Cristian Arezzini wrote:

Il giorno giovedì 12 ottobre 2017 15:06:26 UTC+2, Warren Young ha scritto:

A few minutes ago, I checked a new demo program into the PiDP-8/I software project repository 

I don't understand how to install and run it.

You have many choices:

1. Switch to my OS images, then do an update of what was shipped to the latest trunk, which will get you the demo program along with many many other improvements relative to what you're using now.

2. Check the Fossil source tree out onto your existing OS file system and do a side-by-side installation. The PiDP-8/I project has quite a lot of documentation. Most helpful in that effort will be the HACKERS.md and top-level README.md files. You needn't worry about a collision because the many file naming changes allow both versions to be installed on the same hardware. You can only have one program driving the front panel at a time, of course.

3. Check the source tree out, then copy over just the bits you want to use, running them against your existing simulator. That would involve starting from the Python script I pointed you to, then chasing down all of its dependencies and getting them running on PipaOS. That would be a fair bit of work, which I have no interest in doing, but maybe you like this option best.

I assume it's not just a normal pidp script?

I don't know what a "normal pidp script" is. It's not a Bourne shell script or a SIMH boot script, it's a Python script with assorted dependencies.

 

Should I update the whole simh environment? I have no idea how to do this...

The simplest way to do that is to take option 1.

 

I don't even have a ~/pidp8i folder.

If you wanted that within your existing OS, that's option 2.

 

Should I install fossil (which is not on my system) and run it on that folder? I'm a bit afraid of breaking my system...

Option 2 again: no, don't overwrite the existing one, do a side-by-side install.

 

I'll be sorry to loose all my current personalisations

You should have those backed up somewhere as a hedge against data corruption anyway.

[Ian Schofield]

Dear Gordon,

 You have just asked the wrong question!!!! Just had a recent discussion with Bill Cattey about this problem and I wrote and app to do just what you suggest of having an a direct link to a booted OS/8 volume and the app allows you to upload to and edit files on the live system ... Check this group for the code. Be warned ... it requires a bit of care to use but it does reduce the hassle with getting stuff in and out.

Regards, Ian.

[Warren Young]

On Thursday, October 12, 2017 at 7:06:26 AM UTC-6, Warren Young wrote:

If you're doing this on a multi-core Pi, be sure to disable the ILS by reconfiguring with --no-lamp-simulator

I've just checked in an improvement which avoids the necessity for this. When you run a simulator built for ILS mode but set its throttle using the ratio syntax (SET THROTTLE M/N) it reverts to NLS mode until you switch the throttle back to one of the IPS modes. This is necessary because ratio mode throws off the calculations used by the ILS to calculate its brightness values.

The practical upshot of this is that if you built your simulator for ILS mode, it does run in ILS mode briefly while teco-pi-demo gets the demo set up, then reverts to NLS mode for the actual demo, all automatically.

[Gordon Henderson]

A quick update to this thread - eventually managed to get some hands-on
time with a real PDP-8 (although it was an 8/f) where I keyed in my larson
program (and others) to test the speed/timings in my own emulator. It's
almost there, but for your enjoyment and boredom:

https://www.youtube.com/watch?v=qFt_9LsAgso

Cheers,

Gordon