Is it possible to receive data on a //c's printer port?

[Ivan X]

I have recently acquired my first //c (it's a third revision, "memory expansion" model), and have only recently started using the IIc Plus I got last year.

I'd like to use both of the serial ports for general communication -- one for ADTPro/VSDRIVE, and one for ProTERM. But if I tell ADTPro to use slot 1, there's no activity.

I tried to use IN#1, but was surprised to discover the easter egg that you'd get with IN#5 on the earlier revisions (if you type 10 IN#1 : INPUT A$: PRINT A$ you get the names of four people). It won't accept ctrl-A or ctrl-I to change the serial parameters. This is true on both machines. This seems pretty odd to me unless Apple really intended the printer port for output only.

(Also, I can't use IN#2 on my IIc Plus -- it freezes -- until it warms up for a few minutes. I suspect that's my particular unit.)

So: does anyone know if it's actually possible to do modem (bidirectional) communiation on a //c printer port?

[Riccardo]

Both ports are hardware side similar (bidirectional), but change manager firmware software on ROM that you can use. By way, you can use #1 by real printer or can use #1 connect to PC/MAC by VIRTUAL PRINTER ;-) at the same time you use #2 by ADTPro.

Ric.

[Moose]

Yes, the printer port is definitely bi-directional.

My Apple //c printer cable is also a null-modem cable - so I can plug the end into a PC with a serial port and start transferring disks with ADTPro. I don't know / can't remember if this was the case for all / most //c printer cables.

[Ivan X]

On Monday, June 3, 2013 5:44:41 PM UTC-4, Moose wrote:
> Yes, the printer port is definitely bi-directional.
>
> My Apple //c printer cable is also a null-modem cable - so I can plug the end into a PC with a serial port and start transferring disks with ADTPro. I don't know / can't remember if this was the case for all / most //c printer cables.

Well, this is definitely not the case on my platinum keyboard //c (ROM version 3), or my IIc Plus (ROM version 5). The same cables which work fine with ADTPro on the modem port do not work when plugged into the printer port. It says WAITING FOR HOST REPLY and never starts; on the server side, it says "No Activity". I've tried various baud rates, no go. But it all works fine on the modem port, though.

And, I do find the fact that IN#1 is non-operational -- entirely and visibly by design -- to be very suspicious. (To reiterate, IN#1 on my machines returns four developer names in a string -- which results in a ?SYNTAX ERROR if you haven't written a program to catch it -- and does NOT go into any kind of interactive mode like IN#2 does, or IN#1 on my IIgs does. CTRL-A and CTRL-I do nothing, and I can't "type" over the serial port.)

I think that the printer port on the later (platinum keyboard) //c's might be outbound-only.

[Riccardo]

> > My Apple //c printer cable is also a null-modem cable - so I can plug the end into a PC with a serial port and start transferring disks with ADTPro. I don't know / can't remember if this was the case for all / most //c printer cables.
>

All original printer cables are't null-modem.

>
> Well, this is definitely not the case on my platinum keyboard //c (ROM version 3), or my IIc Plus (ROM version 5). The same cables which work fine with ADTPro on the modem port do not work when plugged into the printer port. It says WAITING FOR HOST REPLY and never starts; on the server side, it says "No Activity". I've tried various baud rates, no go. But it all works fine on the modem port, though.
>

Try to configure (port 1) like (com port) by System Utilities. After exit and try again.
>

[David Schmenk]

IvanX- maybe the other DaveX will chime in, but I believe ADTPro only works with the modem port on the //c. There is no way to select multiple serial cards in ADTPro, so I'm guessing it uses first one it finds when scanning down from slot 7. Aside from some differences in interrupt connections and firmware, the 6551's are wired the same. You can check out how the interrupts may affect how the serial ports operate by looking at the //c tech ref man.

Dave...

[David Schmidt]

On 6/14/2013 10:06 AM, David Schmenk wrote:
> IvanX- maybe the other DaveX will chime in, but I believe ADTPro only works with the modem port on the //c. There is no way to select multiple serial cards in ADTPro, so I'm guessing it uses first one it finds when scanning down from slot 7. Aside from some differences in interrupt connections and firmware, the 6551's are wired the same. You can check out how the interrupts may affect how the serial ports operate by looking at the //c tech ref man.

Other DaveX here - I was going to keep out of it, because you guys were
having a fine time all on your own. But if you want pedantic details,
I'm your man...

While it's true that ADTPro will detect and favor "slot" 2 on the IIc,
that doesn't keep you from choosing slot 1. And it'll poke at it as if
it is an SSC, so it should work. Ric mentions changing slot defaults
using the System Utilities - that may indeed help. There are a couple
of physical mode switches on the SSC that are advantageous to throw that
I *think* don't have virtual equivalents - the one(s) controlling
printer-ness (Ctrl-I) vs. modem-ness (Ctrl-A).

The GS positively can not use the printer port. It would be trivial to
add, and I can control printer-ness vs. modem-ness via programmatic SCC
(no, that's not a typo) port setup. But there's approximately no one
who would want that - and it only offers one more chance for users to
screw something up in the already persnickety world of serial
communications.

Which brings me to an idea I've been kicking around lately... I think
I'll be removing the ability to change baud rates. There should be no
reason to ever go below top speed. I've yet to see a case where slowing
down ever actually helped a situation. If you can't run at top speed,
something else is wrong. And allowing users to change them simply adds
yet another thing that can become mismatched and impede communications
(which tends to generate more email for me).

[Ivan X]

On Friday, June 14, 2013 10:22:24 AM UTC-4, schmidtd wrote:
> On 6/14/2013 10:06 AM, David Schmenk wrote:
>
> Other DaveX here - I was going to keep out of it, because you guys were
> having a fine time all on your own. But if you want pedantic details,
> I'm your man...

We are all ethusiasts of, if not active developers for, an obsolete computing platform. Pedantic details are what we live for.

[Ivan X]

On Friday, June 14, 2013 10:04:01 AM UTC-4, Riccardo wrote:

> Try to configure (port 1) like (com port) by System Utilities. After exit and try again.

This was a huge clue. I had no idea that tool was even in there. So, after I changed the printer port to "modem" mode, and set all the attributes to match that of the modem port...it worked. Sort of. IN#1 behaved as expected, and I was able to actually bootstrap ADTPro.

However, ADTPro itself still doesn't seem to be able to talk to the server on the printer port, even if I tell it to operate on SSC Slot 1. I believe that it must be able to work, since you and the esteemed author just said it could, but...I couldn't get it going. It just sits and waits. If I move the cable to the modem port, and tell ADTPro to use that, no problem.

Also, the printer port (as expected) reverts back to its defaults when the machine powers off, so I'd probably have to write some kind of startup program to get the port into the right state

Any other ideas about how I might get ADTPro working on the printer port on this //c, or at least why it might not be?

[Riccardo]

>
> Also, the printer port (as expected) reverts back to its defaults when the machine powers off, so I'd probably have to write some kind of startup program to get the port into the right state
>

0 REM "CHANGE.PORT"
1 REM THIS PROGRAM CHANGES THE
2 REM STARTUP CONFIGURATION OF
3 REM SERIAL PORT 1 OR 2
100 PN=1: REM SERIAL PORT 1
110 AD=0:IF PN=2 THEN AD=4
120 POKE 49153,0: REM 80STOREON
130 POKE 49237,0: REM SELECT AUXILIARY MEMORY
140 POKE 1144+AD,0: REM SET CONTROL REGISTER TO EXTRA SPEED (115.200bps) (1bit stop 8 bit data)
150 POKE 1145+AD,11:REM SET COMMAND REGISTER NO PARITY
160 POKE 1146+AD,1: REM COMM.PORT
170 POKE 1147+AD,0: REM NO CR INSERTION
180 POKE 49236,0: REM RETURN TO MAIN MEMORY

[Ivan X]

On Saturday, June 15, 2013 10:23:52 AM UTC-4, Riccardo wrote:
> >
>
> > Also, the printer port (as expected) reverts back to its defaults when the machine powers off, so I'd probably have to write some kind of startup program to get the port into the right state
>
> >
>
> 0 REM "CHANGE.PORT"
>
> 1 REM THIS PROGRAM CHANGES THE
>
> 2 REM STARTUP CONFIGURATION OF
>
> 3 REM SERIAL PORT 1 OR 2

<snip>

Thanks, Riccardo! This is super helpful and saved me a ton of time. What I want to do is make a machine language SYS file out of it, so it could be S1.MODEM.SYSTEM, and once it does that, if it isn't running from BASIC.SYSTEM, it could run the next .SYSTEM file in the catalog. That way, it could be sort of slipstreamed into any boot environment to get your ports doing what they want.

With that said, I still can't get ADTPro 1.2.7 to work on the printer port of my IIc ROM rev 3, no way, no how. I've verified that I can get the printer port to work with bidirectional communication using Zlink, and also in BASIC.SYSTEM but only if I skip line 140, which sets the high-speed mode. (When I do that, and PR#1, I can send characters out, but I can't receive characters using IN#1 unless I skip that line and use a slower baud rate.)

This might be a good enough solution for the time being since ZLink will operate on the printer port (unlike ProTERM and Modem.MGR). The point was that I wanted to be able to use VSDRIVE or ADTPro and also be able to log into my RasPi command line from my IIc, and now I think I can do that.

[Riccardo]

>
> Thanks, Riccardo! This is super helpful and saved me a ton of time.

I'm always a pleasure to help a CSA2 fellow. But, if i will able to go at KF2013, you will can offer to me one cup of Italian coffee ;-)

>
>
> With that said, I still can't get ADTPro 1.2.7 to work on the printer port of my IIc ROM rev 3, no way, no how. I've verified that I can get the printer port to work with bidirectional communication using Zlink, and also in BASIC.SYSTEM but only if I skip line 140, which sets the high-speed mode. (When I do that, and PR#1, I can send characters out, but I can't receive characters using IN#1 unless I skip that line and use a slower baud rate.)
>
>
>
> This might be a good enough solution for the time being since ZLink will operate on the printer port (unlike ProTERM and Modem.MGR). The point was that I wanted to be able to use VSDRIVE or ADTPro and also be able to log into my RasPi command line from my IIc, and now I think I can do that.

No worry!

Change line 140 to:

POKE 1144+AD,16

and try again.

(16=$10=0001 0000)

See pag. 307 of "Inside the Apple //c" book, for more detail about Control Register pattern bit configuration.

Ric.

[Riccardo]

Yeah!

I just set to work my //c by -- port #1 -- @115.200 bps in Terminal Mode with PC running TeraTerm.


Ric.

[Riccardo]

>
> > With that said, I still can't get ADTPro 1.2.7 to work on the printer port of my IIc ROM rev 3, no way, no how.

I've a doubt, did you remember to press CONFIG(G) on ADTPro menu and select COMMS DEVICE by SSC SLOT 1 and after save configuration?

Ric.

[Hugh Hood]

Riccardo:

Nice work. I had completely forgotten that the IIc stores it's default
Serial Port values in the AUXMEM screen holes.

Thanks for showing that if you master those, you can lose the System
Utilities drudgery.

For others interested in Riccardo's technique, I recommend reading (from the
July 1985 Issue of Incider, pages 28-36) Aussie Jack Higbie's article "Any
Port in a Storm", which gives a great, detailed explanation of how the IIc
deals with the configuration of its serial ports using the screen holes. He
also gives a BASIC program which is along the same lines as Riccardo's.

For the 'paperless' among us, I notice that scans of the July '85 Incider
are available from the usual suspects. Much to my wife's dismay, I actually
kept all of mine. <grin>


Regards,




Hugh Hood



in article 1e53b504-373e-48c8...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 6/17/13 8:59 AM:

[Riccardo]

> Change line 140 to:
>
>
>
> POKE 1144+AD,16
>
>
>
> and try again.
>
>
>
> (16=$10=0001 0000)
>

Hi Guys,

One more thing..

Analyzing the IC 6551:

1) It have a RxC (Receive Clock) at PIN 5, it is a bi-directional pin which serves as either the receiver 16x clock input or the receiver 16x clock output, but //c does not support the external clock option (RxC is disconnected i think)
2) The internal Transmitter/Receiver sections of the 6551 are two subsection (Tx and Rx) clock, connected by internal switch on RxC line, activated from 4 bit of control register
3) In $00 configuration for example, since RxC is free-out, we probably have Sub-receiver section float, but it works same as $10 how i tested, but i don't sure. We can have potentially Rx and Tx at different frequency.
4) DTR 6551 output is not used
5) DSR ( this is the unique difference between port 1 and port 2, but it do not influence the comms), it is't connected to external port like other normal RS-232C
6) In port 2, DSR can use to generate an interrupt signal, it's connected to //c keyboard strobe signal
7) In port 1, DSR can use to generate an interrupt signal, it's connected to //c pin 9 on the external disk drive connector. It is very strange, i don't know how, but it could be useful for any "virtual drive" project connected to disk port.

Thanks for your attention

[Hugh Hood]

Ivan:

While I realize that ZLink is doing the job for you, if you still would like
to try ProTERM 3.1 using your IIc's _Printer_ Port instead of the _Modem_
Port, I've got a one-byte patch for you to make to the PT3.CODE0 file to
allow that.

Just follow the file with your block/sector editor until you get to the
string 'Apple IIc Modem Port' which in Greg's July 5, 1998 build of
PT3.CODE0 (yours may be earlier - mine apparently is even later than what
the Lost Classics project has) starts at Byte $068F.

At the end of this string you'll notice a series of (12) $20 characters,
followed by an $06, and $07, and then a $20. The $20 represents the 'Slot'
number stored by ProTERM in $800, and which is LDXed before passing to an
$C08B,X instruction for the 6551 ACIA control and command registers.

Change the $20 to $10, save back to disk, re-start, select the IIc Modem
Port with the null modem driver and see if it works for you. If it does, I
also believe that the 115,200 baud 'macro' patch for the Super Serial Card
will work also.

BTW, if you'd rather not mess with the patch let me know and I'll send you a
patched copy to try. In any case, keep a backup of the original, just in
case a 'situation' occurs.




Hugh Hood




in article cf556785-90de-4019...@googlegroups.com, Ivan X at
iv...@ivanx.com wrote on 6/17/13 2:21 AM:

[Riccardo]

Hugh:

Where i can find your ProTERM's patch?
I will to take a look to it too.

Thanks

[Hugh Hood]

Riccardo:

The ProTERM 3.1 patch to allow selection of the IIc Printer Port instead of
the IIc Modem Port was just something I proposed after doing a quick
disassembly of the PT3.CODE0 file, where ProTERM 3.1 stores its drivers.

If you (or anyone else) would like to try it, I've patched a copy of the
file for you and put it up on my site at the following link:

<http://home.earthlink.net/~hughhood/ProTERM%20Stuff/PATCHCODE0.SHK>

You'll need to unshrink it, of course.

In the 'Install' section of ProTerm, the selection you want now reads "Apple
IIc Prntr Port Beta" rather than "Apple IIc Modem Port".

Since you'll need to replace your existing PT3.CODE0 file with the patched
file, please put your original in a safe place so that you can restore it
later.

Try it and let us know if it works. If it does, I can get a little more
sophisticated with how to implement it.

There is another patch (only Ivan has it now for testing purposes) that lets
ProTERM 3.1 run at 115,200 baud with a Super Serial Card, and probably also
with the 6551's built into the IIc and IIc+. I'd rather Ivan check it out
before I turn it lose on the group. It is macro-based (modifies memory code
on the fly) and is along the same lines as my IIGS 115,200 baud patch for
ProTERM.

Regards,




Hugh Hood






in article 81c512b0-5fd6-4183...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 6/19/13 2:47 PM:

[Ivan X]

Hugh, wanted to let you know that the ProTERM IIc Printer Port patch works great, at least on my IIc+. I'll try my IIc when I get back home.

Now I've got what I want: the ability to connect both ports to two serial interfaces on the Raspberry Pi (one onboard, one via USB converter). One is dedicated to console, which I can access via ProTERM, and one is dedicated to ADTPro/VSDRIVE. That way, I can, using only my IIc, I can get any Apple II disk image from wherever, and start using it immediately.

It's interesting, because I actually applied the patch for the IIc driver before realizing that ProTERM has a separate driver entry for the IIc+. So in ProTERM, I just chose the regular IIc driver option, since that's what I patched, and it worked like a champ. I wonder if there's any difference between the IIc and IIc+ driver in ProTERM.

I'm gonna try out the 115,200 SSC patch when I'm back home on Sunday, now that I've got a config set up where I can.

[Hugh Hood]

Ivan:

Thanks for the report. It's nice when something works the first time. As
you know, we're usually not that lucky, or as in my case, not that good.

My brief examination of the IIc and IIc+ drivers showed no _readily_
apparent differences, so ostensibly, we could rename the Port 1 driver to
"Apple IIc/IIc+ Printer Port" and the Port 2 driver to "Apple IIc/IIc+ Modem
Port" with no ill effects, and support both ports for install purposes.

I'm looking forward to your test of the 115,200 baud SSC macro. As I
mentioned, even with a lightning-quick program like ProTERM, screen updates
of incoming data received at 115,200 baud may exhibit character loss,
particularly on a 1 MHz machine. Zmodem file transfers though should be
pretty speedy (no video), and anything you send from the Apple IIc to the Pi
should be swell.

BTW, something has come up so I'll be away from 'connectivity' for a few
days, but as Arnold said, "I'll be back."

Regards,





Hugh Hood



in article 1cdb2a80-b827-4be9...@googlegroups.com, Ivan X at
iv...@ivanx.com wrote on 6/20/13 7:57 AM: