DEC PDT-11/150

This is an unusual one. The PDT-11/150 is one of a series of “smart terminals” based on the PDP-11/03’s LSI-11 chip set and so is basically a little PDP-11 atop a pair of massive 8″ disk drives.

It came to me from a friend who presides over a massive collection but is still, like the rest of us, unable to keep everything. His collection is mostly home machines and quite game focused and this business machine doesn’t fit and so I got a message.

This is just the kind of thing I love. The left-field, unloved and under appreciated machines like this are just the cut of my jib.

Details

Looking on the net there is not a lot of details on this one but according to the manual has 16 or 30 (sic) k-words of RAM, 2Β  8″ floppy drives and 6 serial ports. The processor is the LSI-11 in 3 chips.

From the front the machine is dominated by the floppy drives. The processor and all it’s additions are under the small “lid” and behind the smart label…

The state of things.

It’s not working… I don’t think there is much wrong with it as when I apply power, the disks make moving noises, the LEDs on the front light and go out but I can’t get any life out of the serial port and onto my PC that’s running a serial terminal.

Things to do.

The run mode switch on the back had been bent and become a bit flaky. I’ve replaced it with a new one (RS part number 7109551) but it didn’t make it run properly. It did give me a feeling of satisfaction though πŸ™‚

Multicomp revisited.

Way back in April 2015 I wrote about building an FPGA computer based on Grant Searles Multicomp.

To be honest, it’s not had a lot of use. It has sat, largely unloved, in a cupboard awaiting redisovery. Well. in a roundabout way I have rediscovered it.

Back in September last year, I exhibited a few retro machines at the Centre for Computing History‘s Retro Festival with an old friend. There were quite a few exhibitors from all over the place and one, Neal, was demonstrating the multicomp as a fully loaded 6809 machine. The really nice feature for me was that Neal had used a PCB to build his whereas mine was using a bit of blob board I had kicking around. What was nicer was that Neal had a spare blank board that he was willing to pass on to me.

This board has been sitting on the “Shelf of good intentions” until the right time and its time has come.

Getting started.

The design files for the PCB and instructions can be found on the Retrobrew website and package the information nicely. Be careful when coosing the CF card socket and the RCA connector as there are more than one design of each out there and it’s easy to get a wrong example of each… I have found.

The first step is to solder the connectors and the components for the VGA interface and PS/2 keyboard. This can be considered a minimal system and is a good place to stop and see how you are doing.

At this stage you should have a working 6809 machine with VGA output and 2k of built-in RAM.

This is where I’m up to now. More to follow shortly.

 

 

RetroChallenge 2017/10 – Last day

So another Retrochallenge comes to a close.

What did I do lately?

Well, in the last 24 hours I have tested all of the 74 series chips, with the exception of the 74LS163 (my tester won’t touch them). All were fine, no problems at all.

I swapped the 74LS 163s around to see if the fault moved. It didn’t.

I swapped the 81LS97s, again to to see if the fault moved. It didn’t.

Where are we?

It’s hard to tell.

My newest addition is still not playing ball and I’m stumped as to why, but, that’s not the point of Retrochallenge. The point is to dust off this old kit and have a play and I’ve certainly done that πŸ™‚

 

Roll on RC2018/4

 

RetroChallenge 2017/10 – Slow progress

Well progress has been slow but thanks to some helpful and knowledgeable people (here), progress has been made.

So what do I know now that I didn’t know before? Well, I burned a ROM that just tried to access an imaginary I/O port. When I ran that and watched the _IOREQ_ line, I saw it going up and down which suggests that the program is running correctly from ROM. I put one of my screen-filling ROMS in that just access ROM and screen RAM and didn’t see any _IOREC_ activity so I think I can safely say that the processor is up and running.

About a screen.

I wanted to see if the screen output I’m seeing is coming from video RAM or is being created on the fly by the hardware fault.

So I pulled out a video RAM chip. When I powered on the machine and reset it, the pattern on the screen was different to what I had seen previously. I took another RAM chip out as well and saw a different pattern. Each RAM chip on the Nascom-1 is 1 bit wide and so unfilled sockets will make the corresponding bit float high when accessed.

I think this means that the video RAM is being read correctly or at least feasibly by the video circuitry.

So now I’m looking at the memory addressing and swapping chips to see if the symptoms change. I’m also waiting for some spare 74LS chips to arrive so I have some contingency.

 

More soon.

RetroChallenge 2017/10 – More clues but what do they mean?

So here we are, two thirds of the way through the month and the Nascom-1 is looking just as it did when I started πŸ™‚

But now, take a look at this picture…

This is the Nascom with a ROM in it that fills the screen with NULLs. I’ve just pressed reset.


Now look at this photo…

This is a different ROM. ThisΒ  one fills the screen with ‘*’s. Again I’ve just pressed reset.

Their behaviour with these ROMs after reset is pretty consistant but not guaranteed.

But what does it mean?

I don’t know, but I’m sure it means something. It could mean I’ve mucked up the ROMs. As 2708s are hard to find and program, I’m using a 2716 in a little adapter that I made myself but they look fine.

With the alternative ROMs in place, we’re only using the screen RAM and the addressing logic, buffers etc.

 

RetroChallenge 2017/10 – Mid challenge – all the red herrings.

Oh now this is getting a bit disappointing.

It was a bit too much to think the tri-state buffers had failed and changing them one by one made no difference. Hmm.

I think that the screen memory is OK because the noise on the screen shows each of the bits both set and cleared so no sticky bits either high or low.

I wrote a noddy program and blew ROM just to clear the video RAM and nothing else. It didn’t fix anything but, on reset it tends to look a bit different. I’m not sure what any of this means.

Sometimes I do wish I could get an old machine and it would just work.

Never mind. More next time.

 

RetroChallenge 2017/10 – Purely by coincidence

So here’s a thing. I recently met up with an old acquaintance who I hadn’t seen in years and as we’re both retro-computing fans we were talking about old machines.

I have just received an email from an old acquaintance of mine who is a dedicated retro-computing fan and has spotted my plight in these pages after following me on Twitter (@acollins22 if you’re interested).

He mentioned that he had had a similar problem on a Nascom a few years ago and it was caused by a buffer failing. Now I know this is wishful thinking but it’s worth a look.

The chip in question was an 81LS97, a 3-STATE Octal Buffer.

I’m not the most familiar with this to be honest, a keen amateur. My take on this is that Y1 will equal A1 when _G1_ is low. At other times it will be tri-stated. The other pairs (A2-Y2, A3-Y3 and A4-Y4 will do the same).

Is this right.

I wired up my old Blackstar logic analyser to IC47, the 81ls97 as follows…

  • CH0 – _G1_
  • CH1 – A1
  • CH2 – Y1
  • CH3 – A2
  • CH4 – Y2
  • CH5 – A3
  • CH6 – Y3
  • CH7 – A4

It’s set to trigger on CH0 being low. This is what we get.

What I see here is CH0 going low and so the outputs are enabled. Surely that means that CH4 should echo CH3 but as you’ll see, it doesn’t.

Does that mean I have a faulty 81LS97 or a faulty understanding of what’s going on. It seems a coincidence that a friend tells me how he fixed his Nascom and mine has the same fault but the trace above suggests just that.

Spooky.

RetroChallenge 2017/10 – More things it’s not

Having checked the clocks and finding things look well, it’s time to see if the ROMs are OK.

The Nascom uses 2708 EPROMs. These are 1k by 8 bits and must have been one of the first EPROMs available. The problem with them is that they need three different voltage rails and most modern EPROM programmers can’t do that. Even my old Stag won’t. :-(.

I can program 2716s however as these only need a single 5V rail and thanks to tkc8800 I was able to make a couple of plug in adapters so I can use the bottom half of two 2716s to replace the 2708s.

I have now put Nassys3 in the two 2716s and tried that.

Still the same… Arrgghhh!

 

RetroChallenge 2017/10 – Still looking for clues

In my last post I was suspecting the clocks.

Now I’m not so sure there is a problem with the clocks. Having traced them through everything looks fine. I’m not sure what I was doing wrong but the symptoms haven’t changed but I’m seeing bus activity now and also the _CS_ on the main 2708 EPROM is wiggling around as I suspect it should.

I’ll see if I can read the EPROM and see if it has bit-rot.

EDIT…. It turns out my programmer can’t read 2708s. Doh.

RetroChallenge 2017/10 – and the beat goes on

Yesterday I checked the voltages with my DMV and everything looked OK. Today I checked with the ‘scope just to check for ripple and they all look pretty clean to me.

Clocks

I also saw that there was a running clock but overnight I became increasing worried that it wasn’t a very good clock.

Here’s the circuit…

It doesn’t look too tricky.

Check with the scope.

A scope trace shows it’s a bit funny. I’m not sure quite what the Z80 needs but I thought it should have a better back edge than that.

More thought needed.

A short step from where you are.