Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Apple IIc/IIc+ 115200 Baud ProTERM 3.1 Macro
599 views
Skip to first unread message
Hugh Hood
Jun 30, 2013, 9:48:37 PM6/30/13
to
OK,
Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
Apple IIc, IIc+, or Laser 128.
I've tested it on a real IIc+ for general functionality, but I could really
use some independent confirmation of its proper operation at 115,200 baud.
Do to internal space limitations within the ProTERM IIc driver itself, this
macro will remove the 110 Baud selection and replace it with 115,200 Baud.
If you still need 110 Baud, this macro is not for you.
(BTW, there is yet _another_ driver for the IIc Pseudo RTS/CTS Install so
_this_ macro doesn't apply to them).
To use a ProTERM macro such as this, just add it to your PT3.GLOBAL file in
place of the normally unused OPTION-f macro.
ProTERM has a limited size macro table, so if you've added many other macros
to your default (PT3.GLOBAL) set, you may need to comment some out.
Anything between asterisks (* This is a comment *) is a comment. Please see
the ProTERM 3.1 manual
<http://lostclassics.apple2.info/download/InTrec/InTrec_A2-PT31.pdf>
if you need further information on ProTERM macros, or ask
here.
When you activate the macro by pressing <option>-f, the 115,200 baud rate is
selected and should be reflected in your online parameters display.
Hugh Hood
*
==========================================================================
ProTERM 3.1 High-Speed 115,200 Baud Built-In Port Macro for Apple IIc/IIc+
Version C1.0.3.C
NOTE: For IIe and IIGS, see other macros
by Hugh Hood / June 30, 2013
(with big-time thanks to Ivan Drucker for preliminary testing)
==========================================================================
*
*
OPTION-f (IIc) : Adds 115,200 Baud Option to Printer/Modem Port ACIA Driver
Parameters and Sets Baud to 115,200 (for Apple IIc/IIc+).
*
@@f
BP 0 * Beep Bell One Time *
IF !(ANd (EQual (MEm 2331), 138), (EQual (MEm 2350), 139)), {NOte
"This macro is only for use on an Apple IIc/IIc+ with^m"+
" the Printer/Modem Port Driver in ProTERM 3.1." EXit}
* Checks memory to ensure that 'Printer/Modem Port' driver is selected
on an Apple IIc/IIc+. ($091B/2331 = $8A/138 and $092E/2350 = $8B/139) *
NOte " This macro adds a 115,200 Baud Option to the^m"+
"Printer/Modem Port Driver and SETS the Baud to 115,200.^m^m"+
" To select 19,200 Baud and lower rates,^m"+
" use the standard ProTERM Online Parameters dialog.^m^m"+
" Press ^[ ESCAPE ^[ to cancel."
IF $w, {EXit}
* If they cancel <ESC> exit *
IF $d, {KEy "^["} * Leave Editor or Scrollback *
MEm 2437,"00" * Add 115200 Baud Entry in place
of 110 Baud Entry in ACIA
Control Register Table
($0984/2436) *
MEm 9162,"3131352E32"
* Add "115.2" Selection to
Table (Hex) in place of
"110" Selection
($23CA/9162) *
MEm 9208,"8004"
* Add "1152" [Integer] to Top
Line Display Table (Hex)
($23F8/9208) *
DO "online:parameters","Baud:<115.2>[ok]"
* Select 115,200 Baud Rate
from entries at Super Serial
Card Control Register Table
($984/2436) and Bump ProTERM
to accept changed values *
JSr 2343,16,288
* Bump ACIA Control Register with
presumed changeable values
($0927/2343)
A = $10/16
X = $20/32 (Low Byte)
Y = $01(00)/256 (High Byte) *
EXit * End Macro *
Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
Apple IIc, IIc+, or Laser 128.
I've tested it on a real IIc+ for general functionality, but I could really
use some independent confirmation of its proper operation at 115,200 baud.
Do to internal space limitations within the ProTERM IIc driver itself, this
macro will remove the 110 Baud selection and replace it with 115,200 Baud.
If you still need 110 Baud, this macro is not for you.
(BTW, there is yet _another_ driver for the IIc Pseudo RTS/CTS Install so
_this_ macro doesn't apply to them).
To use a ProTERM macro such as this, just add it to your PT3.GLOBAL file in
place of the normally unused OPTION-f macro.
ProTERM has a limited size macro table, so if you've added many other macros
to your default (PT3.GLOBAL) set, you may need to comment some out.
Anything between asterisks (* This is a comment *) is a comment. Please see
the ProTERM 3.1 manual
<http://lostclassics.apple2.info/download/InTrec/InTrec_A2-PT31.pdf>
if you need further information on ProTERM macros, or ask
here.
When you activate the macro by pressing <option>-f, the 115,200 baud rate is
selected and should be reflected in your online parameters display.
Hugh Hood
*
==========================================================================
ProTERM 3.1 High-Speed 115,200 Baud Built-In Port Macro for Apple IIc/IIc+
Version C1.0.3.C
NOTE: For IIe and IIGS, see other macros
by Hugh Hood / June 30, 2013
(with big-time thanks to Ivan Drucker for preliminary testing)
==========================================================================
*
*
OPTION-f (IIc) : Adds 115,200 Baud Option to Printer/Modem Port ACIA Driver
Parameters and Sets Baud to 115,200 (for Apple IIc/IIc+).
*
@@f
BP 0 * Beep Bell One Time *
IF !(ANd (EQual (MEm 2331), 138), (EQual (MEm 2350), 139)), {NOte
"This macro is only for use on an Apple IIc/IIc+ with^m"+
" the Printer/Modem Port Driver in ProTERM 3.1." EXit}
* Checks memory to ensure that 'Printer/Modem Port' driver is selected
on an Apple IIc/IIc+. ($091B/2331 = $8A/138 and $092E/2350 = $8B/139) *
NOte " This macro adds a 115,200 Baud Option to the^m"+
"Printer/Modem Port Driver and SETS the Baud to 115,200.^m^m"+
" To select 19,200 Baud and lower rates,^m"+
" use the standard ProTERM Online Parameters dialog.^m^m"+
" Press ^[ ESCAPE ^[ to cancel."
IF $w, {EXit}
* If they cancel <ESC> exit *
IF $d, {KEy "^["} * Leave Editor or Scrollback *
MEm 2437,"00" * Add 115200 Baud Entry in place
of 110 Baud Entry in ACIA
Control Register Table
($0984/2436) *
MEm 9162,"3131352E32"
* Add "115.2" Selection to
Table (Hex) in place of
"110" Selection
($23CA/9162) *
MEm 9208,"8004"
* Add "1152" [Integer] to Top
Line Display Table (Hex)
($23F8/9208) *
DO "online:parameters","Baud:<115.2>[ok]"
* Select 115,200 Baud Rate
from entries at Super Serial
Card Control Register Table
($984/2436) and Bump ProTERM
to accept changed values *
JSr 2343,16,288
* Bump ACIA Control Register with
presumed changeable values
($0927/2343)
A = $10/16
X = $20/32 (Low Byte)
Y = $01(00)/256 (High Byte) *
EXit * End Macro *
David Schmidt
Jun 30, 2013, 10:15:25 PM6/30/13
to
On 6/30/2013 9:48 PM, Hugh Hood wrote:
> OK,
>
> Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
> Apple IIc, IIc+, or Laser 128.
>
> I've tested it on a real IIc+ for general functionality, but I could really
> use some independent confirmation of its proper operation at 115,200 baud.
I'm confused about the Laser 128 claim - I understand you aren't
> OK,
>
> Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
> Apple IIc, IIc+, or Laser 128.
>
> I've tested it on a real IIc+ for general functionality, but I could really
> use some independent confirmation of its proper operation at 115,200 baud.
asserting you've tested it, but the Laser 128's treatment of the ACIA
registers is a little different... specifically masking DSR on send. I
don't think I see that as part of your patch. Is that treated elsewhere?
Hugh Hood
Jun 30, 2013, 11:12:59 PM6/30/13
to
David:
Yeah, I've made an assumption about the Laser 128 sharing the same IIc baud
rate driver, which, as you point out, may not be correct.
I had initially concluded that ProTERM contained only (5) different ACIA
drivers, (see prior posting on IIe Macro), but earlier this evening I ran
across at least one more and it's entirely plausible that the Laser 128 has
a separate one as well. (See PT3.CODE0 file)
I previously completely missed ProTERM's 'Pseudo RTS/CTS' driver because it
doesn't do the normal indexed STA $C08B, X stuff, but rather is using
absolute STA $C0AB instead.
In any case, the 'check' routine at the start of the macro will abort things
if the active driver isn't loaded at the expected address, so there
shouldn't be any harm in trying it on a Laser.
Also, the _only_ thing that is being changed by the macro is the value sent
to the low nibble of the ACIA control register. Other parameters are not
affected by the macro, (ProTERM reloads those before the STA $C08B, X) and
ProTERM is handling everything else other than Baud rate.
BTW, have you got a Laser you can check this out on? You are, after all, Mr.
Serial Comm. <grin>
In fact, I credit you, along with Empson and Wilson (the other Daves) with
guiding me through the Zilog 8530 SCC stuff for the IIGS 115,200 baud
ProTERM macro a few years ago. That is really how I was asked to do this IIc
macro, so I dug my IIc+ out of storage and gave it a shot.
Regards,
Hugh Hood
in article kqqodp$duj$1...@dont-email.me, David Schmidt at schm...@my-deja.com
wrote on 6/30/13 9:15 PM:
Yeah, I've made an assumption about the Laser 128 sharing the same IIc baud
rate driver, which, as you point out, may not be correct.
I had initially concluded that ProTERM contained only (5) different ACIA
drivers, (see prior posting on IIe Macro), but earlier this evening I ran
across at least one more and it's entirely plausible that the Laser 128 has
a separate one as well. (See PT3.CODE0 file)
I previously completely missed ProTERM's 'Pseudo RTS/CTS' driver because it
doesn't do the normal indexed STA $C08B, X stuff, but rather is using
absolute STA $C0AB instead.
In any case, the 'check' routine at the start of the macro will abort things
if the active driver isn't loaded at the expected address, so there
shouldn't be any harm in trying it on a Laser.
Also, the _only_ thing that is being changed by the macro is the value sent
to the low nibble of the ACIA control register. Other parameters are not
affected by the macro, (ProTERM reloads those before the STA $C08B, X) and
ProTERM is handling everything else other than Baud rate.
BTW, have you got a Laser you can check this out on? You are, after all, Mr.
Serial Comm. <grin>
In fact, I credit you, along with Empson and Wilson (the other Daves) with
guiding me through the Zilog 8530 SCC stuff for the IIGS 115,200 baud
ProTERM macro a few years ago. That is really how I was asked to do this IIc
macro, so I dug my IIc+ out of storage and gave it a shot.
Regards,
Hugh Hood
in article kqqodp$duj$1...@dont-email.me, David Schmidt at schm...@my-deja.com
wrote on 6/30/13 9:15 PM:
Hugh Hood
Jul 1, 2013, 9:13:19 AM7/1/13
to
David:
Please disregard my request for you to try the ProTERM IIc/IIc+ macro with
your Laser 128.
You are right -- the ProTERM 3.1 IIc/IIc+ driver is a different animal than
the ProTERM 3.1 Laser 128 driver. I did some more late night disassembly on
the driver code last night that confirms that. Fun stuff. <grin>
It appears that Laser 128 support will require a separate macro, just as is
the case with a IIGS and IIe with SSC. At one point you had mentioned using
the PASCAL entry with your ADTPro, but did that permit 115,200 baud, or are
you using some other technique to enable that?
In any case, allow me to retract the "Laser 128" from my previous statement:
>
> Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
> Apple IIc, IIc+, or Laser 128.
>
Make that instead:
"Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
Apple IIc or IIc+".
I _still_ could use testers, though, on the IIc/IIc+.
As always, thanks for your input and insight. I appreciate it.
Hugh Hood
in article CDF65DEB.C109%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 6/30/13 10:12 PM:
Please disregard my request for you to try the ProTERM IIc/IIc+ macro with
your Laser 128.
You are right -- the ProTERM 3.1 IIc/IIc+ driver is a different animal than
the ProTERM 3.1 Laser 128 driver. I did some more late night disassembly on
the driver code last night that confirms that. Fun stuff. <grin>
It appears that Laser 128 support will require a separate macro, just as is
the case with a IIGS and IIe with SSC. At one point you had mentioned using
the PASCAL entry with your ADTPro, but did that permit 115,200 baud, or are
you using some other technique to enable that?
In any case, allow me to retract the "Laser 128" from my previous statement:
>
> Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
> Apple IIc, IIc+, or Laser 128.
>
"Here's the macro to enable 115,200 Baud for ProTERM 3.1 when running on an
I _still_ could use testers, though, on the IIc/IIc+.
As always, thanks for your input and insight. I appreciate it.
Hugh Hood
in article CDF65DEB.C109%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 6/30/13 10:12 PM:
David Schmidt
Jul 1, 2013, 10:01:46 AM7/1/13
to
On 7/1/2013 9:13 AM, Hugh Hood wrote:
> David:
>
> Please disregard my request for you to try the ProTERM IIc/IIc+ macro with
> your Laser 128.
*Whew* Dodged that bullet. ;-)
> David:
>
> Please disregard my request for you to try the ProTERM IIc/IIc+ macro with
> your Laser 128.
> You are right -- the ProTERM 3.1 IIc/IIc+ driver is a different animal than
> the ProTERM 3.1 Laser 128 driver. I did some more late night disassembly on
> the driver code last night that confirms that. Fun stuff. <grin>
some of the status bits differently.
> It appears that Laser 128 support will require a separate macro, just as is
> the case with a IIGS and IIe with SSC. At one point you had mentioned using
> the PASCAL entry with your ADTPro, but did that permit 115,200 baud, or are
> you using some other technique to enable that?
Laser 128 (kindly donated by an interested party) and was able to
diagnose what was happening in real time. Pascal entry points are
relegated to 19.2k and below. You have to bang on the ACIA to get
115.2k in all cases.
Checking status bits ($C089) on send requires you to AND with $10
instead of the usual $50, masking off DSR. Checking on receive requires
you to AND with $08 instead of the usual $68. You can see the
self-modifying (for speed!) code in ssc.asm:
http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/client/src/prodos/serial/ssc.asm?view=markup
look for MOD5 and MOD6. If we find a Laser 128, MOD5+1 gets set to $10,
and MOD6+1 gets set to $08.
Riccardo
Jul 16, 2013, 7:37:11 AM7/16/13
to
1) ProTerm3.1 (//c) <--> TeraTerm VT (PC)
Sets: Global Patch 115200 Active
Comm #2
Send ASCII mode, TXT file
Test OK
See, next step.
-Ric.
Riccardo
Jul 16, 2013, 11:37:05 AM7/16/13
to
1) ProTerm 3.1 (//c) <---Null modem cable---> TeraTerm VT 4.78 (PC)
Dial OK @115200 #2
Zmodem OK @115200 #2
This could be a cool method for transfer single or few selected files (TXT, BIN) w/o pass to Disk Image and ADTPro.
-Ric.
Dial OK @115200 #2
Zmodem OK @115200 #2
This could be a cool method for transfer single or few selected files (TXT, BIN) w/o pass to Disk Image and ADTPro.
-Ric.
Hugh Hood
Jul 16, 2013, 11:16:37 PM7/16/13
to
Riccardo:
I appreciate your taking the time to test the 115,200 baud ProTERM macro on
your IIc.
Please permit me to ask you (2) questions regarding your ongoing testing:
1. Were your Zmodem transfers _to_ the PC, or were they _from the PC?
Perhaps you tried transfers in both directions?
2. Did your Null Modem Cable use any of the handshaking (RTS/CTS/DTR/DSR)
lines, or just TxD/RxD/Grd?
Thanks.
Hugh Hood
in article 096dbb85-fe6a-406f...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/16/13 10:37 AM:
I appreciate your taking the time to test the 115,200 baud ProTERM macro on
your IIc.
Please permit me to ask you (2) questions regarding your ongoing testing:
1. Were your Zmodem transfers _to_ the PC, or were they _from the PC?
Perhaps you tried transfers in both directions?
2. Did your Null Modem Cable use any of the handshaking (RTS/CTS/DTR/DSR)
lines, or just TxD/RxD/Grd?
Thanks.
Hugh Hood
in article 096dbb85-fe6a-406f...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/16/13 10:37 AM:
Riccardo
Jul 17, 2013, 5:24:23 AM7/17/13
to
> I appreciate your taking the time to test the 115,200 baud ProTERM macro on
>
> your IIc.
>
>
> Please permit me to ask you (2) questions regarding your ongoing testing:
>
>
>
> 1. Were your Zmodem transfers _to_ the PC, or were they _from the PC?
>
>
>
> Perhaps you tried transfers in both directions?
>
>
>
> 2. Did your Null Modem Cable use any of the handshaking (RTS/CTS/DTR/DSR)
>
> lines, or just TxD/RxD/Grd?
>
>
I now use Null Modem Cable drive by Null Modem ProTERM driver w/o HS.
But, i have also a normal Printer Cable HS pass trough i think, to test next.
P.S All thing with the benefit of the doubt :-)
-Ric.
Riccardo
Jul 21, 2013, 5:10:56 PM7/21/13
to
> > 1. Were your Zmodem transfers _to_ the PC, or were they _from the PC?
>
ZMODEM A//c --> PC @115200 #2 OK (TXT,BIN)
ZMODEM PC --> A//C @115200 #2 NO (CRC errors, re-transmitting loop)
-Ric.
Hugh Hood
Jul 22, 2013, 12:01:39 AM7/22/13
to
Riccardo:
Thanks for posting the updated test results on your 115,200 baud Zmodem
transfers with your IIc.
May I ask if these tests were made with the _non_ RTS/CTS handshaking cable
(and driver) you mentioned using in an earlier post?
If so, it appears that the 'upload' to the PC is not hindered by the lack of
hardware RTS/CTS handshaking since the PC is probably pretty fast with a
large buffer and never has the need to stop the IIc from sending data.
Conversely, the IIc doesn't have the same luxury (speed and large buffer)
and fails since it can't stop the PC from sending data when necessary to
prevent overflow.
But, if these tests _were_ with a RTS/CTS hardware handshaking cable and
driver it means I've still got more work to do trying to come up with a
consistently reliable solution for IIc owners using ProTERM at 115,200 baud.
Regards,
Hugh Hood
in article be267898-8b26-4664...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/21/13 4:10 PM:
Thanks for posting the updated test results on your 115,200 baud Zmodem
transfers with your IIc.
May I ask if these tests were made with the _non_ RTS/CTS handshaking cable
(and driver) you mentioned using in an earlier post?
If so, it appears that the 'upload' to the PC is not hindered by the lack of
hardware RTS/CTS handshaking since the PC is probably pretty fast with a
large buffer and never has the need to stop the IIc from sending data.
Conversely, the IIc doesn't have the same luxury (speed and large buffer)
and fails since it can't stop the PC from sending data when necessary to
prevent overflow.
But, if these tests _were_ with a RTS/CTS hardware handshaking cable and
driver it means I've still got more work to do trying to come up with a
consistently reliable solution for IIc owners using ProTERM at 115,200 baud.
Regards,
Hugh Hood
in article be267898-8b26-4664...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/21/13 4:10 PM:
Michael J. Mahon
Jul 22, 2013, 12:35:03 AM7/22/13
to
would be too slow to handle 115200kb.
A dedicated, simplified receive loop would work fine (as might an
accelerated Apple).
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Riccardo
Jul 22, 2013, 2:47:48 AM7/22/13
to
>
> May I ask if these tests were made with the _non_ RTS/CTS handshaking cable
>
> (and driver) you mentioned using in an earlier post?
>
As i said, i'm now using: Null Modem Cable drive by null modem ProTERM driver w/o HS.
> May I ask if these tests were made with the _non_ RTS/CTS handshaking cable
>
> (and driver) you mentioned using in an earlier post?
>
-Ric.
Riccardo
Jul 22, 2013, 2:52:22 AM7/22/13
to
>
> A dedicated, simplified receive loop would work fine (as might an
>
> accelerated Apple).
>
-Ric.
Riccardo
Jul 22, 2013, 5:47:36 AM7/22/13
to
-Ric.
Riccardo
Jul 22, 2013, 6:23:17 AM7/22/13
to
ProTerm 3.1 (A//c-Prodos8 v2.0.3 8bit) <---Null modem cable (with HS) and HS Drive---> TeraTerm VT 4.78 (PC-Windows 7 32bit)
DIAL/ASCII A//c<-->PC @115200 #2 OK
ZMODEM A//c --> PC @115200 #2 OK (TXT,BIN)
My printer cable + null modem adapter (cross TX/RX and RTS/CTS)pass through
Tx --> Rx
Rx --> Tx
RTS --> CTS
CTS --> RTS
GND --> GND
All with the benefit of doubt!
-Ric.
Riccardo
Jul 22, 2013, 10:17:55 AM7/22/13
to
Il giorno lunedì 22 luglio 2013 12:23:17 UTC+2, Riccardo ha scritto:
> ProTerm 3.1 (A//c-Prodos8 v2.0.3 8bit) <---Null modem cable (with HS) and HS Drive---> TeraTerm VT 4.78 (PC-Windows 7 32bit)
>
Xon/Xoff control flow both Computers
> ProTerm 3.1 (A//c-Prodos8 v2.0.3 8bit) <---Null modem cable (with HS) and HS Drive---> TeraTerm VT 4.78 (PC-Windows 7 32bit)
>
>
> DIAL/ASCII A//c<-->PC @115200 #2 OK
>
>
>
> ZMODEM A//c --> PC @115200 #2 OK (TXT,BIN)
>
>
>
> ZMODEM PC --> A//C @115200 #2 NO (Timeout waiting error)
>
>
1) Hardware control on PC and Xon/Xoff on A2
> DIAL/ASCII A//c<-->PC @115200 #2 OK
>
>
>
> ZMODEM A//c --> PC @115200 #2 OK (TXT,BIN)
>
>
>
> ZMODEM PC --> A//C @115200 #2 NO (Timeout waiting error)
>
>
DIAL/ASCII A//c--> PC only direction
ZMODEM A//c --> PC @115200 #2 NOT works
ZMODEM PC --> A//C @115200 #2 NOT works
2) Hardware control flow on PC and non control flow on A2
DIAL/ASCII A//c--> PC only direction
ZMODEM not works both directions
-Ric.
Hugh Hood
Jul 22, 2013, 11:42:09 PM7/22/13
to
Riccardo:
Thanks again for your persistence during these tests. Many would have given
up by now!
I see from your posted results that we have a 'Timeout Waiting' error on the
Zmodem send to the IIc. I'm not sure if it's important in this diagnostic
exercise, but may I ask if this message was displayed by Tera Term or was
it displayed by ProTERM?
Anyway, while I'm not familiar with Tera Term on the PC, a Google search on
Tera Term, hardware handshaking, and cable turned up something that _may_
(or may not) be helpful.
One Tera Term user who was successfully using 'hardware handshaking' gave
the pinout for his cable, which he claimed 'worked' at 38,400 baud.
His cable used the DTR/DSR lines for hardware handshaking rather than the
RTS/CTS lines. Is it possible that Tera Term uses those for hardware
handshaking and disregards RTS/CTS?
So (and this is _pure_ speculation on my part), you might consider making a
custom cable using the DTR/DSR lines (#4 & #6 DB-9) instead of the RTS/CTS
lines (#7 & #8 DB-9) to see if that solves this issue with Zmodem.
I know and I realize that it's inconvenient to make a custom cable, but if
you are currently handshaking with RTS/CTS it _might_ be worth a try.
Honestly, I'll admit that the reason that I know it's inconvenient is that I
have been putting off hooking my own IIc+ to test the 115,200 baud ProTERM
macro because of being too lazy to take it up to work, and to make the time,
the effort, and the cable!
So if you'd rather not do it, I understand _completely_. You've already been
most generous in your testing, and I appreciate what you've done.
Regards,
Hugh Hood
in article 43f72b5f-b4e7-425a...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/22/13 5:23 AM:
Thanks again for your persistence during these tests. Many would have given
up by now!
I see from your posted results that we have a 'Timeout Waiting' error on the
Zmodem send to the IIc. I'm not sure if it's important in this diagnostic
exercise, but may I ask if this message was displayed by Tera Term or was
it displayed by ProTERM?
Anyway, while I'm not familiar with Tera Term on the PC, a Google search on
Tera Term, hardware handshaking, and cable turned up something that _may_
(or may not) be helpful.
One Tera Term user who was successfully using 'hardware handshaking' gave
the pinout for his cable, which he claimed 'worked' at 38,400 baud.
His cable used the DTR/DSR lines for hardware handshaking rather than the
RTS/CTS lines. Is it possible that Tera Term uses those for hardware
handshaking and disregards RTS/CTS?
So (and this is _pure_ speculation on my part), you might consider making a
custom cable using the DTR/DSR lines (#4 & #6 DB-9) instead of the RTS/CTS
lines (#7 & #8 DB-9) to see if that solves this issue with Zmodem.
I know and I realize that it's inconvenient to make a custom cable, but if
you are currently handshaking with RTS/CTS it _might_ be worth a try.
Honestly, I'll admit that the reason that I know it's inconvenient is that I
have been putting off hooking my own IIc+ to test the 115,200 baud ProTERM
macro because of being too lazy to take it up to work, and to make the time,
the effort, and the cable!
So if you'd rather not do it, I understand _completely_. You've already been
most generous in your testing, and I appreciate what you've done.
Regards,
Hugh Hood
in article 43f72b5f-b4e7-425a...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/22/13 5:23 AM:
Riccardo
Jul 23, 2013, 4:09:59 AM7/23/13
to
Il giorno martedì 23 luglio 2013 05:42:09 UTC+2, Hugh Hood ha scritto:
> Riccardo:
>
>
>
> Thanks again for your persistence during these tests. Many would have given
>
> up by now!
>
>
>
> I see from your posted results that we have a 'Timeout Waiting' error on the
>
> Zmodem send to the IIc. I'm not sure if it's important in this diagnostic
>
> exercise, but may I ask if this message was displayed by Tera Term or was
>
> it displayed by ProTERM?
>
ProTERM
> Riccardo:
>
>
>
> Thanks again for your persistence during these tests. Many would have given
>
> up by now!
>
>
>
> I see from your posted results that we have a 'Timeout Waiting' error on the
>
> Zmodem send to the IIc. I'm not sure if it's important in this diagnostic
>
> exercise, but may I ask if this message was displayed by Tera Term or was
>
> it displayed by ProTERM?
>
>
>
> His cable used the DTR/DSR lines for hardware handshaking rather than the
>
> RTS/CTS lines. Is it possible that Tera Term uses those for hardware
>
> handshaking and disregards RTS/CTS?
>
>
>
> So (and this is _pure_ speculation on my part), you might consider making a
>
> custom cable using the DTR/DSR lines (#4 & #6 DB-9) instead of the RTS/CTS
>
> lines (#7 & #8 DB-9) to see if that solves this issue with Zmodem.
>
See you next step.
-Ric.
Hugh Hood
Jul 23, 2013, 8:50:06 AM7/23/13
to
Riccardo:
Thanks for the update.
You are correct. The IIc does not have proper DTR and DSR lines at the 5-pin
connector. As you've probably seen from the IIc serial port schematics, it
uses a rather strange implementation of the 6551 ACIA lines.
The experiment proposed here would be to connect the (2) handshaking lines
that the IIc _does_ have to the DTR and DSR lines (rather than RTS/CTS) on
the PC end under the assumption (perhaps incorrect) that Tera Term is using
the DTR/DSR lines for the PC's hardware handshaking. That is what one Tera
Term user suggested in the post I previously mentioned.
Again, this may be fruitless, but ...
FWIW, I recall hearing of some Windows program that 'spies' on the serial
port and perhaps it could give a visual indication of the handshaking lines
while a Zmodem send attempt to the IIc is in progress.
Unfortunately, the name of that 'spy' program escapes me. Maybe someone else
here is familiar with it?
Hugh Hood
in article 505742dd-b5e1-48e1...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/23/13 3:09 AM:
Thanks for the update.
You are correct. The IIc does not have proper DTR and DSR lines at the 5-pin
connector. As you've probably seen from the IIc serial port schematics, it
uses a rather strange implementation of the 6551 ACIA lines.
The experiment proposed here would be to connect the (2) handshaking lines
that the IIc _does_ have to the DTR and DSR lines (rather than RTS/CTS) on
the PC end under the assumption (perhaps incorrect) that Tera Term is using
the DTR/DSR lines for the PC's hardware handshaking. That is what one Tera
Term user suggested in the post I previously mentioned.
Again, this may be fruitless, but ...
FWIW, I recall hearing of some Windows program that 'spies' on the serial
port and perhaps it could give a visual indication of the handshaking lines
while a Zmodem send attempt to the IIc is in progress.
Unfortunately, the name of that 'spy' program escapes me. Maybe someone else
here is familiar with it?
Hugh Hood
in article 505742dd-b5e1-48e1...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/23/13 3:09 AM:
Riccardo
Jul 23, 2013, 9:17:32 AM7/23/13
to
Il giorno martedì 23 luglio 2013 14:50:06 UTC+2, Hugh Hood ha scritto:
> Riccardo:
>
>
>
> Thanks for the update.
>
>
>
> You are correct. The IIc does not have proper DTR and DSR lines at the 5-pin
>
> connector. As you've probably seen from the IIc serial port schematics, it
>
> uses a rather strange implementation of the 6551 ACIA lines.
>
>
>
> The experiment proposed here would be to connect the (2) handshaking lines
>
> that the IIc _does_ have to the DTR and DSR lines (rather than RTS/CTS) on
>
> the PC end under the assumption (perhaps incorrect) that Tera Term is using
>
> the DTR/DSR lines for the PC's hardware handshaking. That is what one Tera
>
> Term user suggested in the post I previously mentioned.
>
I see.
> Riccardo:
>
>
>
> Thanks for the update.
>
>
>
> You are correct. The IIc does not have proper DTR and DSR lines at the 5-pin
>
> connector. As you've probably seen from the IIc serial port schematics, it
>
> uses a rather strange implementation of the 6551 ACIA lines.
>
>
>
> The experiment proposed here would be to connect the (2) handshaking lines
>
> that the IIc _does_ have to the DTR and DSR lines (rather than RTS/CTS) on
>
> the PC end under the assumption (perhaps incorrect) that Tera Term is using
>
> the DTR/DSR lines for the PC's hardware handshaking. That is what one Tera
>
> Term user suggested in the post I previously mentioned.
>
>
> Again, this may be fruitless, but ...
>
>
>
> FWIW, I recall hearing of some Windows program that 'spies' on the serial
>
> port and perhaps it could give a visual indication of the handshaking lines
>
> while a Zmodem send attempt to the IIc is in progress.
>
>
>
> Unfortunately, the name of that 'spy' program escapes me. Maybe someone else
>
> here is familiar with it?
>
>
>
-Ric.
Riccardo
Jul 23, 2013, 9:35:30 AM7/23/13
to
Hugh Hood
Jul 23, 2013, 1:01:04 PM7/23/13
to
Riccardo:
Thanks for the link. Yes, using a modem with indicator lights is one
possibility for serial port diagnostics, but I found a Serial Port Spy for
Windows (free) that may be much easier to use, and would not introduce the
quality (or lack thereof) of the telephone lines into the equation. Here is
one of the screenshots from the program:
<http://www.232analyzer.com/images/MainScreen.jpg>
You'll notice that it logs the handshaking lines, in addition to all the
other serial port information.
Also, I did some more research with Google, and another Tera Term user
mentioned that in order to use Hardware Handshaking with Tera Term, not only
did the DTR and DSR lines need to be connected, but also that the RTS and
CTS lines needed to be jumpered/tied together on the PC COM port end.
Such fun!!
Hugh Hood
in article 1bad207b-32b1-49fe...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/23/13 8:35 AM:
> Like this:
>
> http://www.usr.com/images/products/product-emea.asp?prod=3453c&loc=itly
Thanks for the link. Yes, using a modem with indicator lights is one
possibility for serial port diagnostics, but I found a Serial Port Spy for
Windows (free) that may be much easier to use, and would not introduce the
quality (or lack thereof) of the telephone lines into the equation. Here is
one of the screenshots from the program:
<http://www.232analyzer.com/images/MainScreen.jpg>
You'll notice that it logs the handshaking lines, in addition to all the
other serial port information.
Also, I did some more research with Google, and another Tera Term user
mentioned that in order to use Hardware Handshaking with Tera Term, not only
did the DTR and DSR lines need to be connected, but also that the RTS and
CTS lines needed to be jumpered/tied together on the PC COM port end.
Such fun!!
Hugh Hood
in article 1bad207b-32b1-49fe...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 7/23/13 8:35 AM:
> Like this:
>
> http://www.usr.com/images/products/product-emea.asp?prod=3453c&loc=itly
Riccardo
Jul 23, 2013, 5:08:51 PM7/23/13
to
Il giorno martedì 23 luglio 2013 19:01:04 UTC+2, Hugh Hood ha scritto:
> Riccardo:
>
>
>
> Thanks for the link. Yes, using a modem with indicator lights is one
>
> possibility for serial port diagnostics, but I found a Serial Port Spy for
>
> Windows (free) that may be much easier to use, and would not introduce the
>
> quality (or lack thereof) of the telephone lines into the equation. Here is
>
> one of the screenshots from the program:
>
>
>
> <http://www.232analyzer.com/images/MainScreen.jpg>
>
>
>
> You'll notice that it logs the handshaking lines, in addition to all the
>
> other serial port information.
Good stuff! and good idea!
> Riccardo:
>
>
>
> Thanks for the link. Yes, using a modem with indicator lights is one
>
> possibility for serial port diagnostics, but I found a Serial Port Spy for
>
> Windows (free) that may be much easier to use, and would not introduce the
>
> quality (or lack thereof) of the telephone lines into the equation. Here is
>
> one of the screenshots from the program:
>
>
>
> <http://www.232analyzer.com/images/MainScreen.jpg>
>
>
>
> You'll notice that it logs the handshaking lines, in addition to all the
>
> other serial port information.
I'll try to put it at works for determinate my serial cables pin configuration from A2, when possible.
-Ric.
oz390gta
Aug 20, 2013, 7:51:11 PM8/20/13
to
I haven't used Proterm in 20 years but decided to have a go at getting some files to my IIc. I currently have ADTPro to my Mac running fine but want to try and transfer files other than disk images. I have noticed that in this thread Hugh and Richardo are trying to get 115200 baud working. I am happy for anything above 19200 but to do this I have a few questions.
What is the most reliable speed that anyone has got from Proterm and a IIc with only a SND/RCV/GRD cable?
How do I get Proterm to go above 19200 as this appears to be the maximum speed in the settings of the software.
oz390gta
What is the most reliable speed that anyone has got from Proterm and a IIc with only a SND/RCV/GRD cable?
How do I get Proterm to go above 19200 as this appears to be the maximum speed in the settings of the software.
oz390gta
Hugh Hood
Aug 21, 2013, 11:19:27 AM8/21/13
to
Well, I'm afraid the jury is still out on this one.
Ivan 'A2Cloud' Drucker seems to be at the forefront on testing this, and he
has sent me a few preliminary test results, but it would be best if Ivan
would share those himself.
In a nutshell, a 1MHz Apple IIc without hardware handshaking seems to have a
hard time at 115,200 in ProTERM.
I've dumped the disassemblies of the ProTERM IIc drivers, but haven't really
studied them enough to bring anything good to the table of discussion, yet.
Is ID in 'da house?
Hugh Hood
in article c8d4c3cc-b533-4974...@googlegroups.com, oz390gta
at oz39...@gmail.com wrote on 8/20/13 6:51 PM:
Ivan 'A2Cloud' Drucker seems to be at the forefront on testing this, and he
has sent me a few preliminary test results, but it would be best if Ivan
would share those himself.
In a nutshell, a 1MHz Apple IIc without hardware handshaking seems to have a
hard time at 115,200 in ProTERM.
I've dumped the disassemblies of the ProTERM IIc drivers, but haven't really
studied them enough to bring anything good to the table of discussion, yet.
Is ID in 'da house?
Hugh Hood
in article c8d4c3cc-b533-4974...@googlegroups.com, oz390gta
at oz39...@gmail.com wrote on 8/20/13 6:51 PM:
Hugh Hood
Aug 21, 2013, 1:08:33 PM8/21/13
to
Riccardo:
Please allow me to apologize, as I realized after posting that you too (In
addition to Ivan) had posted 115,200 baud results with ProTERM on your IIc
using XON/XOFF handshaking, and that you actually had experienced some
success doing it.
In fact, I think you had better results than Ivan did.
If you are still working to get RTS/CTS working with your IIc to PC setup,
please keep us updated.
Regards,
Hugh Hood
in article CE3A44AF.24435%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 8/21/13 10:19 AM:
Please allow me to apologize, as I realized after posting that you too (In
addition to Ivan) had posted 115,200 baud results with ProTERM on your IIc
using XON/XOFF handshaking, and that you actually had experienced some
success doing it.
In fact, I think you had better results than Ivan did.
If you are still working to get RTS/CTS working with your IIc to PC setup,
please keep us updated.
Regards,
Hugh Hood
in article CE3A44AF.24435%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 8/21/13 10:19 AM:
Riccardo
Aug 21, 2013, 4:31:30 PM8/21/13
to
I have not forgotten to do those tests when will possible. I'll keep you update.
-Ric.
Ivan X
Aug 21, 2013, 10:58:45 PM8/21/13
to
On Wednesday, August 21, 2013 11:19:27 AM UTC-4, Hugh Hood wrote:
> Well, I'm afraid the jury is still out on this one.
>
>
>
> Ivan 'A2Cloud' Drucker seems to be at the forefront on testing this, and he
>
> has sent me a few preliminary test results, but it would be best if Ivan
>
> would share those himself.
>
>
> Well, I'm afraid the jury is still out on this one.
>
>
>
> Ivan 'A2Cloud' Drucker seems to be at the forefront on testing this, and he
>
> has sent me a few preliminary test results, but it would be best if Ivan
>
> would share those himself.
>
>
> Is ID in 'da house?
You rang?
I just tested this all again, using:
- ROM version 03 Apple IIc (Woz extremely limited edition!)
- DIN5 to DE9 serial cable with pinout as described here:
http://adtpro.sourceforge.net/connectionsserial.html#DIN5
- Raspberry Pi with latest Raspbian
- cheap USB-to-DE9 adapter with Prolific PL2303 chipset
I set up a getty (shell login) for the USB-to-serial adapter.
Things that shouldn't make a difference: I'm using the printer port thanks to another one of Hugh's clever ProTERM patches, and I'm running ProTERM from VSDRIVE over the modem port connected to another USB-to-serial adapter.
Here's what I can tell you: 115200 definitely works. How usably is an individual determination, but for me not quite enough. Everything is certainly visible and you can certainly tell what's going on and type any Linux command which pleases you. But characters do get dropped. Bursts of data (file dump, or even ls) will lose good chunks of expected output. I am able to use YMODEM successfully to transfer files, and it is indeed pretty zippy. ZMODEM I can't get working at all. (Hugh tried to help me with this by tweaking the serial port settings in Linux, but I haven't spent much time on it.) Anything that depends on lots of VT-100 escape codes (e.g. nano) you can completely forget about.
It's much more usable IMO at 19200, but still drops chars here and there. 9600 seems pretty close to perfect. Hugh told me how he can run at at a slower speed and then upshift to 115200 for transfers, and I could see huge benefit to doing so, and might try to incorporate it into the A2CLOUD workflow at some point. My method, though, is to instead use command line tools (nulib2 and AppleCommander) to unshrink and copy files into or out of a disk image accessed by VSDRIVE. I'll be explaining how to do this if I ever get around to releasing a finished version of A2CLOUD.
0 new messages