• Please review our updated Terms and Rules here

Swtpc pr40

If you are driving the printer with 'gibberish' then what will the printer do I ask myself... Probably not what you think it should I would suspect.

This simple test only checks out the 8 bits of the input and output ports. It doesn't check CA1, CA2, CB1 or CB2. If these aren't used by the printer - that's fine. But (if they are) this could be a further source of confusion.

With the test program running what do you actually get for the following keys?

Key 'A' (capital) pressed on the keyboard. What character(s) do you observe? If you use your logic probe on port A and B bits 0 to 7 - what logic levels do you observe?

Repeat the above with the following keys: '@', 'B', 'D', 'H', 'P', 'a' (lower case) and the numeral '0'. These keys test all of port bits (with the exception of the most significant bit) for being stuck.

Bit 7654 3210
0 $30 0011 0000 ; This is the numeral zero.
@ $40 0100 0000
A $41 0100 0001
B $42 0100 0010
D $44 0100 0100
H $48 0100 1000
P $50 0101 0000
a $61 0110 0001 ; Lower case 'a'.

Dave
 
Thanks Dave.. I'll run through that shortly. Is it possible that when I type and initially get the letter I'm typing back, that's just the computer/terminal echoing it back? I thought the test program was supposed to suppress that.. so it should be the parallel card returning what I'm typing. I went through the whole keyboard and it always sends back the correct character, but followed by the wrong one. Anyway, I'll test what you've got there and advise.

Also I am not 100% sure we can trust these test programs, which were scanned/OCRed by Michael Holley - I was looking over the printer test one again yesterday and noticed numerous errors, mainly in the memory addresses where I guess the OCR got it wrong. I'm wondering if that carries over into the actual hex instructions/data as well. I was trying to find a scan of the original SWTPC documents but haven't had any luck.
 
The hex bytes on page 3 of https://deramp.com/swtpc.com/Notebook/PARINT_1.pdf look OK to me. The corresponding assembler on page 3 is largely rubbish...

Don't forget that memory addresses $A002 and $A003 need to be filled in with the base address of the PIA on the MP-LA (say $800C for slot 3). In this case $A002 is required to be filled in with $80 and $A003 is required to be filled in with $0C. You need to do this before executing the test program at $A04A.

>>> Is it possible that when I type and initially get the letter I'm typing back, that's just the computer/terminal echoing it back? I thought the test program was supposed to suppress that.

That's what I was trying to ascertain. The echo has nothing to do with the test program - but may be a function of the monitor ROM routines that the test program calls.

Dave
 
falter said:
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?
Click to expand...

I'm kind of talking out of my rear here because I'm a little fuzzy when it comes to MOS interface chips, but re: this:

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.
Click to expand...

It would be my wild guess (and this is based on skimming this datasheet and manuals for the MP-L and SWTPC PR-40 manuals on deramp.com) that you should be seeing the C2 line of the port toggle with every character output *and* the driver that's pushing characters out should stop until the "data accepted" output from the printer connected to C1 is toggled by the printer. (IE, it looks like the port should be programmed for the "Handshake on Write" mode described in the 68020 datasheet?) Unless C2 is open collector and needs to be externally driven (the manual says it can source 5ma, though, so I don't think that's the case?) I would thus expect that would have to be detect-ably transitioning ("strobe"-ing) for every character output regardless of whether you have the printer hooked up. If all that's changing on the port is the data lines with no strobe then the printer isn't going to react to it.

*If* you're getting a strobe then, yeah, I would think the printer should "respond to gibberish", in that it sounded like from my brief scan of the manual it should spit out a line of text whenever its line buffer fills up? My vague understanding is the only control code the printer responds to is carriage return. Maybe it treats extraneous non-printable-and-control-other-than-carriage-return ASCII characters as NOPs that don't go in the buffer but I would assume that a string of 40 bytes anything between 32 and 127 would count.
 
Yes, CA2 is the output from the PIA to the printer (it is not open collector) to signify that a character is ready. CA1 is the input to the PIA from the printer to signify that the SWTPC may send further characters.

It would appear from the PRNTST-1 software (however) that the strobe itself (on CA2) is generated by the software alternately clearing and then setting the bit - rather than the 'smarter' mode offered by the PIA hardware itself. Obviously, this is purely down to the software as to how it is going to drive the hardware and thence how the interface would be wired to the printer itself. It may be possible to substitute the hardware handshake for the software handshake without any effect on the physical PIA/printer interface - but I would have to look again at exactly how the 'smart' handshake mode works. Sometime they use signals from the 'B' side of the PIA (or am I confusing the Z80 PIO modes I wonder?).

Yes, when a 0Dh is received, or the buffer fills up, the printer should burst into life.

We need to find out what software Falter is using to drive the printer. Is it PRNTST-1?

Dave
 
Incidentally, I found a bug in the PARINT_1 program...

The instruction at address A04C: (B7 80 07 ; STA A $8007) should be A04C: B7 A0 0C ; STA A $A00C - disable echo.

According to the manual the terminal echo should be turned off. I don't see how this will work if the accumulator is written to memory location $8007 instead of $A00C.

Dave
 
Yes I am using PRNTST-1 to try and drive the printer. It's the only software I know of to do this with my 6800.

Just working on Dave's test with PARINT_1 and will try changing the disable echo. I wonder if that's a difference between MIKBUG and SWTBUG? These diagnostics were written before SWTBUG it appears..
 
Okay so I reentered the program with Dave's fix for suppressing terminal echo.. here is what came out in (keypressed) - (result onscreen) format. There was no echoing this time, and I confirmed pressing the same key multiple times produced exactly the same result each time. I also checked with my multimeter to make sure the jumpers between the bits were all making good connections.

0 - Can't tell if it is a 0 or a letter O onscreen
@- I don't seem to have that key?
A - >
B - =
D - ;
H - 7
P - /
Lower case a - not sure how to produce this with a CT1024.

I did some additional characters of my own in case:

1 - N
2 - M
3 - L
4 - K
5 - J
Q - .
W - (
E - :
R - -
T - +
Y - &
 
Somehow, the bit pattern you are getting back is the inverse of what is being sent!

For example:

‘A’ = $41 = 01000001. ‘>’ = $3E = 00111110.

Note that the top bit (most significant bit) is cleared by the monitor PROM.

Can you check the buffer ICs on the MP-LA card to make sure they are all of the correct type (DM8833). It is just possible that one has been replaced by the wrong type...

Dave
 
Nope.. on the A side they are DM8833 but on the B side they are DM8835

Looks like DM8835 is same as DM8833 except it inverts everything?
 
There’s yer problem with the loopback test program!

The DM8833 is a non inverting device whilst the DM8835 is an inverting device.

What is sent out of one parallel port is inverted before it is read back in again, thus giving you the wrong character code displayed for the key you entered.

According to the MP-LA manual IC3-IC7 should all be DM8833 (the non inverting variety).

That gets to the root of the loopback problem!

The printer only uses one half of the parallel interface (the ‘A’ side - output port). One of the ICs is used to buffer the control signals from both sides of the PIA. What type is this device I wonder? This should be a DM8833 (otherwise the control signals to/from the printer will also be inverted)!

EDIT: IC5-IC7 have to be DM8833 type. We can move on to the printer test and the printer interface tomorrow if these ICs are the correct type.

Dave
 
Last edited:
Thanks Dave.

So originally the card was jumpered with A as an input, and B as an output. Naturally I tried the printer test program with the printer connected to port B. This likely would not have worked anyway, since I probably would have needed to use a different address (800E?) to reach it.. but yeah, even if I had that would have produced some weird stuff.

Following SWTPC's recommendation but not cluing in which chips were where, I reversed the jumpers and made B an input and A the output. Both chips for A are 8833s, both chips for B are 8835 (I assume they are grouped together on each side where each port is).

So theoretically, connecting to port A, the printer should have driven it just fine then?

I have probed the individual pins with prntst-1 running, and I see nothing changing on any of the A side pins -- all in a low state. There is no evidence of anything going on with handshaking. The printer meanwhile seems to have activity on both the printer ready and data accepted pins, even disconnected from the computer.
 
There is an extra buffer chip at location IC7 for the control signal buffering. You haven’t described what type of IC that is...

Dave
 
Excellent.

So, the first thing is to get the SWTPCs MP-LA card connected correctly to the PR-40 printer and then to work on the software.

We will be using the MP-LA 'A' port only with the 'A' port configured as an OUTPUT (OA wired to G).

The 'B' port on the MP-LA card will not be used and should, therefore, remain unconnected.

One of the issues I come across is differing pinouts in various documents and errors in the various documents. Without a 'terms of reference' for what pin numbers are being described - you are sunk. In this post I will go back to the original reference documents from SWTPC...

The pinout I am using for the MP-LA card is here: https://deramp.com/downloads/swtpc/h...structions.pdf. On page 7 you will find the red-blue PCB layout. The 'A' connector is the bottom of the two connectors (identified as 'SIDE A'). You will notice the faint descriptions for each pin:

C1 (INPUT - Used to indicate that the printer has accepted the data).
C2 (OUTPUT - Used to indicate to the printer that it has some data to print).
A0 (Data - Least significant bit to printer).
A1
A2
A3
A4
A5
A6 (Data - Most significant bit to printer).
A7 (Data - unused by the printer).
Unused pin.
GND

The ICs IC5, IC6 and IC7 on the MP-LA must be of type DM8833 (non inverting) otherwise the data and/or control lines will be inverted!

I would suggest reviewing the MP-LA pins and checking the PCB tracking as follows to ensure that we have identified the correct pins:

C1 and C2 are tracked to IC7.

A0 through A3 are tracked to IC6.

A4 through A7 are tracked to IC5.

OK, now we have this figured out let's turn our attention to the printer itself...

Let's make sure we understand the pin numbering for J4 on the printer PCB shall we? This can be found in here: https://deramp.com/downloads/swtpc/h.../PR40_Wire.pdf.

This document describes the function of each pin https://deramp.com/downloads/swtpc/h...structions.pdf. See pages 7 and 8.

The schematic (https://deramp.com/downloads/swtpc/h..._Schematic.pdf) pinout for J4 should be consistent with the above document reference - but I have spotted an error! J4-2 appears twice! It appears as both a GND connection and the DATA ACCEPTED output from the printer. Both can't be simultaneously true. J4-2 should be the DATA ACCEPTED output from the printer. The GND connection marked as J4-2 should be J4-4. Update your schematic now!

If you have any intermediate cables/connectors, you should draw these out...

Now we should be able to assemble the cable. When you come to test it - check everything from the MP-LA connector end to the printer J4 end to make sure everything is connected correctly and that there are no open or short circuits anywhere.

Code: 
MP-LA Function      Direction PR-40
C1    DATA ACCEPTED <<==      J4-2
C2    INPUT STROBE  ==>>      J4-3
A0    Data (LSB)    ==>>      J4-10
A1                  ==>>      J4-11
A2                  ==>>      J4-12
A3                  ==>>      J4-8
A4                  ==>>      J4-9
A5                  ==>>      J4-5
A6    Data (MSB)    ==>>      J4-6
GND   Ground                  J4-1 and/or J4-4

The only pin not wired on the PR-40 J4 connector should be J4-7 (this is unused) and (possibly) one of the GND pins.

The only pins not wired on the MP-LA (SIDE A) should be A7 (unused data bit) and the unused pin.

I will have a look at the software this afternoon ( https://deramp.com/downloads/swtpc/h...structions.pdf pages 17 and 18 ). That should give you time to make up (or check) the cable that you are using...

Incidentally, the ONLY pin that should be active on the PR-40 (with it not connected to anything) should be J4-2 (the data accepted output from the printer to the computer). There is, however, a pull-up resistor on both J4-2 and J4-3 at the PR-40 printer end. If you see any other activity with the PR-40 printer disconnected, there is something wrong with the PR-40 printer somewhere...

Dave
 
Last edited:
The software described in https://deramp.com/downloads/swtpc/h...structions.pdf on pages 17 and 18 does appear to do what it says on the tin.

You must (however) remember to fill in the base address of the MP-LA PIA into memory locations $A002 (high byte) and $A003 (low byte) and start the printer test program at address $A04A.

The test program can 'lock up' whilst waiting for the handshake signal back from the printer. In this case, the data lines from the MP-LA port A should be frozen at the last data byte to be output. If the printer doesn't respond to the first character to be output by the test program ($0D) then this should be present on the port A data lines. The test program then cycles around various combinations of sequential data bytes ($21 '!' to $3F '?') and ($40 '@' to $5F '_') as two (2) separate lines of text that should be displayed on the printer. Each line being separated by a $0D <CR>.

Note that the manual erroneously states that the last character output is 5E. I think this should be $5F.

Please also note the warning about not running this test for any length of time (I would suggest 20 to 30 seconds at the most). With the printer actually working (...) the character stream could overheat the printer mechanism and reduce the life.

There could be an issue with interrupts. The handshake from the printer uses the interrupt mechanism of the PIA. However, if the MP-LA PIA is physically connected to the CPU interrupt's line, and the CPU interrupts are enabled, this could cause the CPU to erroneously malfunction.

Let me know what you find out - or if you need any more explanation.

Dave
 
Last edited:
Thanks so much Dave!

You'll be pleased to hear before I did any hooking up I actually traced the cable out from the printer. It is a flat rainbow colored ribbon cable so it made it really easy. The ribbon cable obviously goes to a connector plugged into J4 on the printer. On the other side, the previous owner had attached a DB25.

It was arranged as follows:( pin on DB25 / pin on j4 / color of wire used )

Pin 1 - GND J4 -1- Black
Pin 2 - Bit 6 J4 - 6- Blue
Pin 3 - Bit 5 J4 - 5- Purple
Pin 4 - Bit 4 J4 - 9 - Yellow
Pin 5 - Bit 3 J4 - 8 - Green
Pin 6 - Bit 2 J4 - 12 - Brown
Pin 7 - Bit 1 J4 - 11 - Red
Pin 8 - Bit 0 J4-10 - Orange
Pin 9 - Data Ready J4 3 - Grey
Pin 10 - Data Accepted J4-2 - White

What I did was cut off the DB25 and strip down a bit of each wire, and then connected directly to the MPLA.

So I have GND to GND
Bit 6 -0 to Bit 6-0
Data Ready to c2
Data accepted to c1.

I set A002 to 80 and A003 to 08 (I am using Slot #2 now - I plugged the card in there for the other test as well)

I plugged in the prntst program as the manual requires, and did J A04A.

Nothing.

I probed the Data bits A0-A6 - all low, no changing.

put my logic probe to C1 - there is a 'ringing' or activity there.
I put my logic probe to C2 - there is a 'ringing' or activity there.

I removed the strobe and data accepted wires from C1 and C2, and probed them.. they are ringing even while not plugged into the MPLA.
 
I think, from a cursory read of your post, that the problem probably lies with the printer.

However, before we bark up that tree, I would like to try a test tomorrow with just the SWTPC on its own (disconnected from the printer). I am expecting to see the $0D output to the ‘A’ port. If we don’t see that, there is something wrong with the SWTPC end as well...

If you see some activity on the printers J4-3 (input strobe from computer to printer) when the printer is disconnected from the computer (nothing plugged into J4) we need to chase that issue down. My guess would be something wrong with the +5 Volt rail of the printer to start with...

Dave
 
daver2 said:
If you see some activity on the printers J4-3 (input strobe from computer to printer) when the printer is disconnected from the computer (nothing plugged into J4) we need to chase that issue down. My guess would be something wrong with the +5 Volt rail of the printer to start with...
Click to expand...

Yeah, that's a big red flag, given that line is supposed to be an input to the printer, not an output.
 
You must log in or register to reply here.
Back
Top