5

Are there some tests that can be done to verify the operation of an Orange Micro Grappler+ printer interface card (1982) in an Apple IIe? I've searched around the web and the paper manuals for solutions or debugging ideas but haven't landed on anything definitive.

Issue A - Grappler+ is in slot 1 and my understanding is that PR#1 should direct commands to the printer and PR#0 should return to screen output. Instead PR#1 (or PR#2 when in slot 2) makes the IIe unresponsive to everything except control+open apple+reset. This is the case whether or not the ribbon cable is attached to the card.

Issue B - If PR#1 is invoked and printer is on (regardless of paper inserted or printer 'select' status or any other printer buttons) "NOT SELECTED" flashes on screen and there is a constant fast beep until the printer is turned off. I don't know if this signals a card issue or a printer issue or something else.

Printer details - The printer is an Apple ImageWriter II. It successfully passed the self-test, the printer buttons do what they're supposed to (line feed, etc.) and I can successfully print from Windows PC (generic driver) via USB (plus a couple adapters to attach to the serial printer cable). Everything seems to work properly.

General details - I have always changed cards and cables with the power off. Tried Grappler+ in slots 1 and 2. I reviewed the Grappler+ operating manual and set the DIP switches (tried a few variations). I'm using an IDC to DB25 ribbon cable (red to left/center/away from pin 25) on the card, and a serial printer cable (same one as for the USB test above). Tried with and without 80 column card in slot 0. Tried with DOS 3.3, and ProDOS 1.1.1/AppleBasic 1.1.

I grew up with an Apple IIe and knew the details fairly well, but after so many years this one has me stumped. Thanks for any tips you can provide.

Improve this question
1
  • Grappler is a PARALLEL card. Imagewriter is a SERIAL printer. They won't work with each other.
    – bjb
    Commented Mar 12, 2018 at 17:15

2 Answers 2

Reset to default
5

Issue A is probably just the card waiting to detect a printer. (But I haven't disassembled the ROM.)

Issue B is probably because you're trying to connect a serial printer to a (Centronics) parallel card.

From the Grappler plus Operator's Manual, top left on page 3:

GRAPPLER+ STATUS CHECK

Before sending a character to the printer, the GRAPPLER+ will check the SELECT and PAPER EMPTY status lines. If the printer is not "on-line," or is out of paper, a warning will be printed on the screen and the Apple will beep.

This suggests the card ROM is working fine, but it wants SELECT and (not) PAPER EMPTY.

Improve this answer
9
  • Issue B is the most important one, it basically boils down to "cannot work" - Issue A is just a follow-up problem.
    – tofro
    Commented Mar 10, 2018 at 12:29
  • Well, there are serial (eg USB) to parallel adaptors, but you'd still need to check that the statuses are making it through.
    – Nick Westgate
    Commented Mar 10, 2018 at 19:12
  • Upon PR#1 with the printer on it does print "NOT SELECTED" on the screen and beeps. Evidently it is doing this continuously as NOT SELECTED flashes and the beep happens continuously (about six times per second). Also, it happens regardless of whether Select is lit or off, even with paper in. There is no red error light.
    – snyderj
    Commented Mar 10, 2018 at 19:13
  • 1
    @snyderj: The Operator's Manual says it's parallel on page 1. Also, parallel cards are very simple, with just a ROM and some 74 series logic chips. Serial cards will have a serial controller chip, but the Grappler(+) doesn't.
    – Nick Westgate
    Commented Mar 10, 2018 at 19:49
  • 1
    The grappler+ is a parallel card in hardware. "recognize as a serial interface" just means that it implements the driver for a serial card, for better software compatibility. This is important for Pascal, and applications using the Pascal approach to hardware, which depend on these ROM interfaces.
    – fluffysheap
    Commented Mar 10, 2018 at 21:10
0

Sounds much like a damaged/unreliable ROM code.

  • Can you read bytes from the PROM area using the monitor? ($C100..$C1FF)

  • Are these the same values as expected?

  • Can you read bytes from the EPROM area using the monitor? ($C800..$CFFF)

  • Are these the same values as expected?

  • Try to clean the contacts and repeat.

Improve this answer
3
  • I cleaned the contacts, and I did the call -151 C100 <return> and watched values. Lots of hex but don't know what the expected outcome should be. There weren't any odd characters. I'm thinking that if the card won't respond to PR#0 after PR#n (doesn't matter which slot it's in) then perhaps the card (or a chip on the card) is bad.
    – snyderj
    Commented Mar 10, 2018 at 3:27
  • There wo't any 'odd characters'. It's what the CPU reads at this locations. It should be the programm. After all, PR#1 does nothing but redirekting CSW, thus every subsequent outputed character gets done so via a JSR $C100. In this case you typed it, it will be the next BASIC prompt (transfered in A). Now if the (E)PROM is damaged, this code may no longer work. The sugggeetion was to compare this code to what should be there to see if teh (E)PROM is still valid or not. It's all about the software here.
    – Raffzahn
    Commented Mar 10, 2018 at 11:09
  • A serial printer will never work on a parallel port, regardless of how reliable the ROM is...
    – tofro
    Commented Mar 10, 2018 at 12:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .