• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

bqt said:
But you do have a point in that, in case case you actually do read all 129 words of a block, it becomes complicated. With DECtape, I know that you don't have to. OS/8 do not, even through the block itself always have 129 words.
RF08 do not, as far as I can recall, require that you read in all 128 or 129 words
Click to expand...

The RF08 and DF32 are unusual devices since the sector size is 1 word. You specify the platter, track, and word address where you want the transfer to start and the length of the transfer up to 4k. The controller pretty much handles the rest. The DF32 was the first disk controller I wrote code to talk to directly and everything after that was a disappointment in that you had to deal with sectors and buffering.

Yeah, OS/8 just ignores the 129th word on DECtape. To do anything else would have been problematic. If you didn't have the handler space limitations my temptation would have been to use it as some kind of checksum of the block.
 
I checked the DEC RF08 DMS driver - and it only deals in units of 129 words per block. So, even though the hardware is capable of transferring 1..n words, this is not how DMS uses it.

The code is as follows:

Code: 
7730: TAD 7746 // Negative number of words.
7731: DCA 7750 // Store to where the disk controller can get at it.
 ...
7746: 7577     // -129 words (DECIMAL).

Doug, thanks for the information on the serial port. I seemed to remember a straight-8 having the MSB set from the UART in AC4 - but if the teletype was set for MARK parity that would do it!

If I set the serial port up with no parity - we should be good to go...

Dave
 
Haven't had much to contribute to the DMS effort, I'm afraid.

My "big list" project is getting there, though:

http://svn.so-much-stuff.com/svn/trunk/pdp8/src/xx/xx.php

I'm thinking that very soon I'll begin the process of switching over to this thing as the replacement for the current "DEC" and "MAINDEC" pages in the software section of www.so-much-stuff.com.

If that sounds like a terrible idea, please let me know :-o!

Vince
 
Well.... what I did..... quite a bit, but doesn't seem like I accomplished much. I got up this morning to 6-8 inches of new snow. So I started to clean it up and found that it had a density just shy of lead. Boy was it heavy. Then I thought I'd look at my email and one of my hard drives bit the dust. Spent a lot of time repairing that, installed an SDD. Maybe that will last a little longer. I've been working on a CPM 2.2 program to read certain tracks and sectors from my 8 inch disk drives. Got stuck there. Then I thought I fire up my raspberry pi with the serial disk for my PDP8E, just for a little deversion. The PI would not respond to the password via putty. Horsed around with that for a while, no soap. So I started the Serial Disk program from the keyboard and monitor. That worked fine. Next to fire up the PDP8E and then as if gun shot when off, followed by the acrid smell of burnt electric equipment. I suspect a capacitor committed suicide, one that I probably neglected to replace. Anyway, my repair list is blooming, at least the driveway is clear and the email computer works. Seems each time I play with the old stuff, I end up having to open them up and do surgery. They don't make stuff like they used to. Mike
 
Well..... that was lucky. I found one of my NEW capacitors on the M8310 board that was blown to smithereens. All that was left were the leads. I replaced the capacitor and powered up the board alone with no trouble. Then I removed all the cards and checked the power supply that was OK. Inspected the other cards and nothing looked or smelled bad. Loaded up the minimal setup and the PDP8E came to life. Added the I/O and the EAE and that also worked fine. Dodged a bullet, but I wonder why the new capacitor failed. It was on the 5 volt bus and was rated at 35 volts. There has to be at least 20 more in my PDP8E. These capacitors are 6.8 uF 35 volt 10% solid tantalum. Was this a poor choice?

I still have the problem of starting my Raspberry PI remotely. In the past I just started PUTTY, entered the IP address and the PI asked for the name 'PI' and password 'raspberry'. I checked the PI's ip address, figuring that maybe the DHCP changed it, but that was not the case. If it were, I would not have gotten into the PI. I looked around on the internet and found SUDO passwd PI would change the password. That worked. A few months ago my ATT uverse modem/router fried, the new one seems to juggle the IP addresses quite a bit. The PI seems to have a different IP address each time I turn it on. Maybe I should assign a static address. Mike
 
Mike_Z said:
Well..... that was lucky. I found one of my NEW capacitors on the M8310 board that was blown to smithereens. All that was left were the leads. I replaced the capacitor and powered up the board alone with no trouble. Then I removed all the cards and checked the power supply that was OK. Inspected the other cards and nothing looked or smelled bad. Loaded up the minimal setup and the PDP8E came to life. Added the I/O and the EAE and that also worked fine. Dodged a bullet, but I wonder why the new capacitor failed. It was on the 5 volt bus and was rated at 35 volts. There has to be at least 20 more in my PDP8E. These capacitors are 6.8 uF 35 volt 10% solid tantalum. Was this a poor choice?

I still have the problem of starting my Raspberry PI remotely. In the past I just started PUTTY, entered the IP address and the PI asked for the name 'PI' and password 'raspberry'. I checked the PI's ip address, figuring that maybe the DHCP changed it, but that was not the case. If it were, I would not have gotten into the PI. I looked around on the internet and found SUDO passwd PI would change the password. That worked. A few months ago my ATT uverse modem/router fried, the new one seems to juggle the IP addresses quite a bit. The PI seems to have a different IP address each time I turn it on. Maybe I should assign a static address. Mike
Click to expand...

Mine have mdns enabled. I would suspect maybe yours have as well?
In which case you should be able to find it as "raspberrypi.local". So no need to really track what the IP address is, assuming your putty client also understands mdns...
I usually come from a Unix system, and just ssh into it. And then it's easy...
 
To be perfectly honest, I'm not a network guy. In fact just a retired coal fired power plant engineer. I looked up mdns and still don't under stand what it is. Putty has the ssh radio button on, but that is all I know so far. Need to read a little more. Thanks Mike
 
>>> I found one of my NEW capacitors on the M8310 board that was blown to smithereens.

>>> They don't make stuff like they used to.

So they clearly don't make stuff like they used to :)!

>>> ... but I wonder why the new capacitor failed.

So, at work we are getting a few thousand boards (that date from the 1980s) remanufactured. Interestingly the highest fault rate we are getting is from solid tantalum bead capacitors used across power rails. These are on the 24V supply rails I think (just before the voltage regulators). Again, a very large margin based on their rating.

These boards are powered up as part of the ATE (Automated Test Equipment) as they go through the factory - so they did work then.

We have constructed some burn-in rigs and are subjecting all the cards to a 400 hour monitored burn-in process. We are testing approximately 60 of these cards in every burn-in batch and we usually have a problem with each batch having at least one or two that 'trip' the 24 Volt power supply monitoring. They are all going back under warranty for a repair. All of the capacitors are brand new directly from the manufacturer - so there shouldn't be a quality issue.

Because of the high failure rate we are looking into it as a matter of course. Interestingly, the failure rate is still lower (just) than that stated by the component manufacturer for the part from new... We are going to examine some of the failed parts forensically to see what actually occurred.

These parts seem to be the weak link in the chain...

More than willing to look them up on the Bill of Materials when I have a bit of time to see exactly what the device(s) is/are that are failing and what the voltage ratings is/are.

Dave
 
Mike_Z said:
To be perfectly honest, I'm not a network guy. In fact just a retired coal fired power plant engineer. I looked up mdns and still don't under stand what it is. Putty has the ssh radio button on, but that is all I know so far. Need to read a little more. Thanks Mike
Click to expand...

Assuming you know what DNS is (essentially how computers get from host names to IP addresses), mDNS is a way of doing this for a local network without having any DNS server. It works by using multicasts, hence the 'm'. Simply explained, if you are using mDNS, then any name that ends in ".local" is assumed to be for a machine on the local network, which can be resolved via mDNS. So the machine wanting to find out the address does a multicast asking for that machine name, and the target machine will detect this query, and send a response, telling what IP address it has.

So, in putty, instead of putting in the IP address for connecting, try "raspberrypi.local", and see if you manage to connect using that. If it works, then you do not have to try and remember/configure/figure out what IP address your raspberry pi is at.
And the name is just the one that I observed my raspberry pi happen to have. I suspect it's just the name configured in the image that Oscar prepared, so if you are using that one, there is chance this just works.
However, it does obviously also depend upon the machine where you are using putty also understands and can use mDNS.
 
The next step in my Lab-8/e adventure will be to get OS/8 to boot using Kyle Owen's SerialDisk application (https://github.com/drovak/os8diskserver).

I have one M8650 which can only do 110bps unless I change the crystal and a M8655 which can go much higher.
Mouser and Digikey have suitable 19.661 MHz crystals, but that means I would have to wait a week. There is nothing here in Australia.
The 110 bps are just enough for a console so I will use the M8650 for the SerialDisk interface.

As it turns out it is not that easy to find a USB to serial converter that actual works with 110 bps.

The most reputable converter is made by FTDI. They have an application note where they describe how to hack ftdiport.inf to alias for example 600 bps to a new baudrate say 110 bps. This works great for higher speeds, but it just doesn't go as low as 110 bps (as confirmed with an oscilloscope). The added problem is that Windows 10 makes you jump through a few hoops before it allows you to install a now non-certified driver (after all you have hacked ftdiport.inf).

I eventually found a converter made by ATEN which also didn't get down to 110 bps with the standard Windows 10 driver. After I downloaded and installed the latest driver from the ATEN website it worked perfectly at 110 bps.

Next I researched the serial cable connector on the M8650 side. There are 40 pins, but you need only need 3 - TX, RX and GND plus another 2 looped back on the connector to feed the RS232 converterted to TTL levels RX data back into the TTL input of the board (weird to do this in the connector rather than a jumper on the board).

Kyle Owen has a nice step-by-step description on what to do to build his SerialDisk app and how to prepare the OS/8 image for use with SerialDisk.

I hope to run OS/8 soon.

Best regards
Tom Hunter
 
I have succcessfully booted OS/8 via Kyle Owen's SerialDisk via a M8655 running at 19200 bps.

I also found that my terminal connection using the M8650 running at 110 bps is stretching my patience too far.
The crystal on the M8650 is 14.418 MHz so limits me to 110 bps. If I understand correctly by upgrading the crystal to 19.661 MHz I could run at speeds up to 2400 bps which is more tolerable.
Has anybody tried this crystal upgrade?

Thanks and best regards
Tom Hunter
 
djg said:
I have the 19.661 MHz crystal in mine. Faster baud rates work fine you just have to solder wire to IC pin. The M8650 can go faster than the M8655.
https://homepage.divms.uiowa.edu/~jones/pdp8/hard8e/kl8e.html
Click to expand...

Thanks Doug,

I found a possible local supplier of the crystal and I hope I will get it quicker from Melbourne/Victoria than via Digikey or Mouser in the US.
Your link shows that the M8650 can go much faster than the M8655 but common USB to serial converters won't be able to use the speeds over 38400 bps.
Nevertheless this is twice as fast as the 19200 bps I am using with SerialDisk now.
I will use the M8655 for the terminal connection and the now higher speed M8650 for SerialDisk.

Best regards
Tom Hunter
 
djg = David Gesswein. Added my name to profile.

If you want 57600 or above I think that works with 14.7456 MHz crystal. Won't be able to do the common lower frequencies but if dedicated for SerialDisk won't mater.
 
djg said:
djg = David Gesswein. Added my name to profile.

If you want 57600 or above I think that works with 14.7456 MHz crystal. Won't be able to do the common lower frequencies but if dedicated for SerialDisk won't mater.
Click to expand...

Sorry David,

You linked to Doug's article so I wrongly guessed "djg" is Doug.

For the higher speeds to work I would need power of 2 multiples of 110:

57600 / 110 = 523.64

523.64 / 512 = 1.023

This means there is a 2.3% error but that is fine for async comms.

57600 bps is a substantial improvement on the 38400 possible wiith the 19.661 MHz crystal upgrade.

Actually 115200 bps should be equally possible with the same bitrate error.

Thanks for pointing out this possibility.

Best regards
Tom Hunter
 
Grats on getting serial disk running!
thunter0512 said:
Thanks Doug,
Click to expand...
It wasn't me.
thunter0512 said:
Your link shows that the M8650 can go much faster than the M8655 but common USB to serial converters won't be able to use the speeds over 38400 bps.
Nevertheless this is twice as fast as the 19200 bps I am using with SerialDisk now.
I will use the M8655 for the terminal connection and the now higher speed M8650 for SerialDisk.
Click to expand...
The limiting factor on the M8655 is the UART. Some of them will work at 19200. The M8650 with a different crystal could go a lot faster.

I have been working on making a parallel port disk. I have the OS/8 handler written. I was going to just modify Kyle's Serial Disk server but there were all kinds of changes to it I wanted to make. Most of those changes have to do with support for 12 devices in the SYS handler and performance changes. Performance is irrelevant when you use a low baud rate serial port but it is possible to do a lot better than that when using a parallel port. It looks like about the worst that could be expected would be around 55k words per second (82.5k bytes per second or 660k bps). I am hoping to see speeds of over 100k words per second. For comparison I believe there was a drum device that would transfer a word every 16us which would be a rate of 62500 words per second. The current version of serial disk if running at 19200 baud would transfer 960 words per second.

Anyway, working on parallel disk is several projects down the list.
 
I finally fixed the operation of
*.-1 177+1
in my cross assembler. I had to completely redo expression handling so that it processes left to right, etc.

Also ran into a curious bit assembling the source for 8BAL (decus-8-497). The correct answer for this:
SZA CLA^2
is "SZA CLA" times 2, or 7500. But this:
JMP FOO+1
in the case where FOO is offpage, is very definitely *not* the same as "JMP FOO" + 1!
Fun times.

I've been working to close about a hundred tabs that I opened when upgrading the "DEC" and "DECUS" software collections on my website. (One of them was the links to the source for 8BAL and 8BALIB.) 8BAL uses quite a few exotic constructs that the cross assembler wasn't dealing with correctly.

I also fixed a bug where "(" and "[" literals went to separate pools that didn't know about each other, in the case where "(" was used while on page zero (which generated a "page zero" message, but also gave wrong code).

I haven't committed the new assembler yet, through, as I want to see it work correctly for more sources, first.

Vince
 
vrs42 said:
Also ran into a curious bit assembling the source for 8BAL (decus-8-497). The correct answer for this:
SZA CLA^2
is "SZA CLA" times 2, or 7500.
Click to expand...

I can't think of why you would ever want to do that. In what context does that make sense? A 7500 is an SMA. Is this some kind of code obfuscation?

Ok, I looked at the source and I still don't understand it. There is a table of these with magic constants. 8BAL is a macro processor. The comment has to do with making an assumption that if the code is known then it is probably not an 8BAL IF construct. Somehow they match the SZA CLA with the 7500.

Vince, is there a document describing 8BAL? I didn't see more than just the broad DECUS overview.

(See how easily I am distracted?)
 
Last edited:
DougIngraham said:
I can't think of why you would ever want to do that. In what context does that make sense? A 7500 is an SMA. Is this some kind of code obfuscation?
Click to expand...

Well, it was new to me, too. No idea why some conditionals are multiplied by 2, and others are multiplied by 4 (then incremented, IIRC?). Probably some slick memory saving hack we don't understand yet.

is there a document describing 8BAL? I didn't see more than just the broad DECUS overview.

(See how easily I am distracted?)
Click to expand...

There's the DECUS abstract as you have seen, but I haven't found a more extensive write-up or manual yet. I do see several mentions of dialects of FORTRAN where 8BAL was used to implement structured programming constructs in scientific applications. Unfortunately, no cool macro libraries seem to survive, either.

Vince
 
You must log in or register to reply here.
Back
Top