• Please review our updated Terms and Rules here

Swtpc pr40

falter

Veteran Member
Joined
Jan 22, 2011
Messages
6,556
Location
Vancouver, BC
I finally got around to getting my SWPTC PR40 going. I've had it a while but never tested it. It appears to have a Db25 male connector and the wiring seems to match what you'd expect for a standard parallel connection, with the strobe and data lines. I thought for a rough and ready test, I'd connect it to one of my old PCs and try copying a basic text file over to the LPT1. However, I get a 'paper out' error, which if memory serves is the error you normally get if the computer cannot detect anything attached to the port. I'm wondering if there's a way around this - ie.. I'm wondering if I need to short or connect the PAPER OUT pin to something?
 
I suspect you will need to tie one or more of PAPER OUT, SELECT and ERROR to the correct state to make it happy. I'm not sure off the top of my head if the "correct" state will be grounding them or pulling them up... going to lean toward grounding. Do it through a current limiting resistor, of course.

Here's an article about interfacing a PR-40 to a TRS-80, that machine has a very similar parallel port. It suggests the status line it has should serve as the "BUSY" input. The article also says the TRS-80's strobe signal isn't quite right and the author added some inverters to delay it, hopefully you don't have that problem with the PC.
 
I suspect you will need to tie one or more of PAPER OUT, SELECT and ERROR to the correct state to make it happy. I'm not sure off the top of my head if the "correct" state will be grounding them or pulling them up... going to lean toward grounding. Do it through a current limiting resistor, of course.

Here's an article about interfacing a PR-40 to a TRS-80, that machine has a very similar parallel port. It suggests the status line it has should serve as the "BUSY" input. The article also says the TRS-80's strobe signal isn't quite right and the author added some inverters to delay it, hopefully you don't have that problem with the PC.

Many thanks. I may just give in and bring out my actual 6800 system or something and see if that will work. I was hoping to quickly prove that the printer works.. it doesn't do much other than put out a faint click when it's turned on. Hopefully it just needs a valid signal to actually do something.
 
Tying the status lines on a PC parallel port should be easy enough, but I do wonder if a “faint click” is a bad sign.

Driving it with an Arduino would probably work and not take a lot of effort to program.
 
… the other thing you could try if you’ve already wired up the data lines and strobe is simply use BASIC to OUT a byte to port 0x378. (Assuming this is an oldskool PC with a real hardware parallel port on LPT1.) Pretty sure a blind write will trigger the strobe without caring about the input status lines.
 
So I ended up setting up my 6800 again to try and get this thing going. I traced out the pins on the male DB25 connector for the printer, and while most line up with a standard parallel port, some don't. Pin 1 for example, which on a PC would be strobe, appears to be ground on this PR40. Anyway, I figured I might as well just go with the equipment it was intended for. So far no dice. There's a lot of variables to account for and I'm not sure if I'm getting them all.

The instructions for the PR40 were written up when they were still using MIKBUG as the primary monitor for the 6800. My machine is SWTBUG, so I'm not sure if that has any impact. Another thing in the MP-LA instructions is that they advise to wire up PORT A on the card as output, and port B as input. On my card, it is the reverse. I don't know if that matters, but the manual says for best compatibility with SWTPC software that's how they recommend doing it.

What I did to try and get things going is I took the printer's male DB25 and plugged it into a female to female DB25 serial. From what I could ascertain each pin on that cable stays the same from one end to the other (no crossovers) so I figured that ought to be able to play ball as a parallel gender changer. I then used short jumper wires from the other end of that cable to the MP=LA's PORT B which as I mentioned is configured as the input.

I entered in the test program from the manual. I looked at the code and to my eyes it should have worked fine with SWTBUG. I have the MP-LA plugged into slot 3, so I set A002 and A003 to 80 0C respectively.

The only thing I wasn't so sure of was where the data ready and data accepted pins went. I sort of tried it both ways, but when running the program of course nothing happens.

For all I know, the printer may have issues of its own, or this MP-LA isn't working. Not entirely sure. But yeah, running the program by invoking J 404A produces nothing at all.
 
… backing up. When you connected this to the PC did you just use a straight through cable, you didn’t make your own custom one? I guess I missed the part where you said this PR-40 has a 25 pin DB connector on it. All the docs for this printer say the interface pins come out on J4, a 12 pin Molex connector. Is this DB-25 connected to that?
 
That is correct. From J4 there is a color coded ribbon cable that comes to a male DB25. It has 10 wires. For the PC test, I connected that DB25 directly to the parallel port on the PC. But I'm assuming that won't work, since the PC's strobe is pin 1, and on this printer pin 1 traces to gnd on J4.

I traced each from the pin on the DB25 back to where it connects on J4.

Pin 1 - connects to J4 GND
Pin 2 - connects to J4 bit 6
Pin 3 - connects to J4 bit 5
Pin 4 - connects to J4 bit 4
Pin 5 - connects to J4 bit 3
Pin 6 - connects to J4 bit 2
Pin 7 - connects to J4 bit 1
Pin 8 - connects to J4 bit 0
Pin 9 - connects to J4 Data Ready
Pin 10 - connects to J4 Data Accepted

What I'm calling pin 1 is what would be pin 1 on a standard female DB25.
 
Found this somewhat useful manual - mentions an interface they built to use the printer with the PET.

What I probably need is some way of verifying the MP-LA is working.. just to rule out issues with the computer.
 
… ouch. FWIW, I would recommend *never* just randomly plugging DB-25 plugs on ancient computer hardware into other things with the same plug with a straight through cable unless you know for absolute sure they’re meant to go together. That plug is probably the most overused/abused connector on planet . This pin out is bit-reversed for a PC, and while you probably didn’t smoke it the PC probably didn’t appreciate having strobe grounded.

If you want to try making a *correct* cable it looks to me based on that TRS-80 article the pin out would be something like (assuming your pin out of the 25 pin plug is correct):
SwtpcPC
Do, pin 82
D1, 73
D2, 64
D3, 55
D4, 46
D5, 37
D6, 28
Strobe/Data Ready, pin 91
Data accepted/ready, pin 10, let’s think about this belowBusy, 11
DittoACK, 10
Other status lines
See below
GND, pin 118-25 not all needed
I see two options for handshaking. In the TRS-80 article the author inverted the printer’s DATA ACCEPTED and connected that to BUSY. That is probably a good idea, and if you’re willing to hook up a 7404 I endorse it. The other option I see is connecting ACCEPTED to ACK and tying BUSY to ground with a resistor. That probably will not provide good handshaking but it should let you issue OUT commands in BASIC to the port.

As for the paper out/sel/etc, those may need to be tied high or low for standard printer drivers to work, but I *think* if BUSY looks okay it may not be necessary.
 
… or here’s a terrible idea: pull a +5 line so you have both that and ground and use 7 resistors to pull up/down the data lines so you’re asserting 0x0D (13) on the data lines and wire a push button to pull strobe down to ground. The manual says carriage return is the only control code it responds to, hitting the button should now advance the paper.
 
Ok so I sort of went back to basics here. First, I tested the serial cable I was using as a gender changer and.. surprise.. the pins don't line up from end to end. They crossover in a couple of places. Which is weird.. this is not a null modem cable.. so I don't know why it would do that.

The second thing is I reread the manual and discovered I had my address for the ports on the card wrong. I had 800C in my test program, but apparently there are four addresses per card.. 800C, 800D, 800E, and 800F for a card plugged into slot 3. C and D, if I read right, go to port A in the card.. E and F go to port B.

So yeah.. possible double fault. So I decided to make things easier by using the jumper on the mpla to change port a from an input to an output as SWTPC prefers. Then I removed the male db25 from the end of the cable coming from the printer and plugged the wires directly into Port A's molex connector. I'm hoping that'll do the trick.
 
Okay so, I hooked up a logic probe, then fired up the 6800, inputted SWTPC's test program, set the port address to 800C, and ran the program.

The printer did not react. I checked the pins on the MP-LA - on some of the data bit pins I have a low logic signal, on others, nothing. On the Data Accepted and Strobe lines, I see activity. However, if I disconnect those two wires coming from the printer, the activity is gone. Checking the two wires from the printer removed from the MP-LA, I still see activity on both. I'm thinking I shouldn't be seeing that.

I'm not sure if I've got one problem or two or none - I feel like if I've got the program set up right, and the MP-LA is working, when i run the program, regardless of whether the printer is attached, I should see some activity on the strobe line as it tries to send stuff out?
 
First things first - let's go right back to basics...

What configuration do you have on the MP-LA card? You can configure whether port A is an input or output or port B is an input or output. You can also configure the interrupts (if any).

So, how is your particular MP-LA card configured?

As the interface IC is a 6820 - you can drive it at the 'bare metal' level and output specific values to the ports (assuming configured as outputs) or read the values presented to the ports (assuming configured as inputs).

Dave
 
Dave! Nice to hear from you.

So originally the card was configured with B as an output and A as input. I read in the documentation that for compatibility reasons with SWTPC software it was best to have A set up as an output, so I changed the jumper. Now both ports are outputs. I will probably change the B port to an input later as I have a SWTPC joystick I'd like to use.

I'm not really sure what to expect with parallel output.. ie.. if I run a program that continuously outputs something, should I be seeing activity? Or does it need another device handshaking with it to actually try sending anything?
 
Yes, I keep popping up from time to time! Just too busy with real work at the moment...

So, both ports are configured as outputs.

The PIA that is on the board configures both ports as inputs when it is reset. You have to program the port A and B data direction register and modes of operation - and this has to match the configuration of the external buffers. You have to, therefore, program the PIA ports A and B as outputs and then you should be able to write a value to the A and B data ports and these values should appear on the output connectors.

I am just going out for a walk, so I will give you a bit more detail when I get back.

Dave
 
Well I appreciate your thoughts whenever they are available, always!

I am following the PR40 test program PRNTST-1. I *think* this program does as you describe but not sure. I am looking over the PARINT-1 diagnostic provided for the MPL to maybe test the card that way.
 
Alright.. so I reconfigured the MPLA to have B as input, A as output.. and then I did the PRNTST program. It does seem to mostly work. If I type A, I get A back. However, I also get extra characters back also. The photo here shows:

https://drive.google.com/open?id=16...Z&authuser=bradhodge75@gmail.com&usp=drive_fs

I'm not sure if this is a problem per se or just the lack of handshaking, differences between SWTBUG and MIKBUG, or such. It does faithfully return each key I press.. it just always has the extra unwanted characters.
 
Can you point me at a site for the test program please?

Found it at https://deramp.com/swtpc.com/Notebook/PARINT_1.pdf

Yes, so that looks correct...

A is OUTPUT.
B is INPUT.

You should have some cross-connections between the 8 bits of the A output port and the 8 bits of the B input port. There is no handshake in use at all.

The test program should wait for a keyboard character. Output it to the A output port. Read from the B input port and display the character it received.

If you press an UPPER CASE A (hex $41) you should observe the bit pattern 0100 0001 on the A output port.

The assembler listing of the test program is 'screwed up'. Hopefully, the hexadecimal bytes aren't!

EDIT:

The hexadecimal bytes look better than the assembler next to it! The assembler is rubbish!

Port A is set to an OUTPUT.
Port B is set to an INPUT.
Port A control is setup for no interrupts and no handshaking.
Port B control is setup for no interrupts and no handshaking.

LOOP:
The MIKBUG or SWTBUG console character is read.
The ASCII value of the character just read is output to port A.
The loopback connector should wire the outputs from port A back to the inputs of port B.
Port B is read.
The resulting register value from port B is output as an ASCII character to the MIKBUG or SWTBUG console.
GOTO LOOP

Just out of interest - you haven't got your terminal configured for half duplex have you (i.e. to echo the character you enter)? If you have, the 'A' will be the echo and the next 'funny' character will be from the MP-LA (possibly)?

Cheers,

Dave
 
Last edited:
Thanks Dave. No, the terminal is full duplex. I actually checked that while running the test program.

One thing that may or may not have bearing - I am not using the stock SWTPC serial/comm card - I am using one of Bob Corsham's new SS30 serial cards. I don't *think* that would impact the playback any..

Putting that aside - the parallel card is putting out something at least.. should that not be enough to drive the printer, even if it is gibberish?

I'm going to read through the theory of operation again on the printer.. I'm not really sure what I should be seeing on those handshaking lines if it isn't connected to anything.
 
Back
Top