Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #849 > unrolled thread

Super Serial Card sending high ASCII with PR#?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Super Serial Card sending high ASCII with PR#? ivan@ivanx.com - 2013-09-03 03:16 -0700
    Re: Super Serial Card sending high ASCII with PR#? David Schmidt <schmidtd@my-deja.com> - 2013-09-03 07:26 -0400
    Re: Super Serial Card sending high ASCII with PR#? Hugh Hood <hughhood@earthlink.net> - 2013-09-03 21:32 -0500
      Re: Super Serial Card sending high ASCII with PR#? ivan@ivanx.com - 2013-09-04 05:32 -0700
        Re: Super Serial Card sending high ASCII with PR#? Hugh Hood <hughhood@earthlink.net> - 2013-09-04 08:18 -0500
          Re: Super Serial Card sending high ASCII with PR#? ivan@ivanexpert.com - 2013-09-04 12:38 -0700
        Re: Super Serial Card sending high ASCII with PR#? "John B. Matthews" <nospam@nospam.invalid> - 2013-09-04 17:17 -0400
    Re: Super Serial Card sending high ASCII with PR#? Egan Ford <datajerk@gmail.com> - 2013-09-03 21:46 -0600
      Re: Super Serial Card sending high ASCII with PR#? dempson@actrix.gen.nz (David Empson) - 2013-09-04 18:19 +1200
        Re: Super Serial Card sending high ASCII with PR#? BLuRry <brendan.robert@gmail.com> - 2013-09-06 13:39 -0700

#849 — Super Serial Card sending high ASCII with PR#?

Hey serial geniuses,

I'm seeing something I don't understand at all.

In A2CLOUD, slot 1 is used for serial shell connection to the Pi. This works fine in Z.LINK and ProTERM.

I want to write a simple program that "types" a command at the Linux prompt, presuming I'm already logged in.

I tried the following program:

10 ?CHR$(4);"PR#1"
20 ?CHR$(9);"12B"; : REM set 4800 baud
30 ?"true" : REM sample Linux command
40 ?CHR$(4);"PR#0"

I then fired up my comm program to see what happened. I can up-arrow to see the previous cammand, and I see "true" appear. But when I press return, I get:

'\364\362\365\345\215\212': command not found

That's octal for every letter of "true" followed by ctrl-J and ctrl-M, but with bit 7 inappropriately set.

Just to be super sure of what was happening, I write a version that explicitly sent the the characters I wanted (e.g. CHR$(116), etc) but I got the same result.

So somehow Linux is receiving the characters as high ascii. I have no idea why. Does anyone else?

Thanks,
Ivan.

[toc] | [next] | [standalone]

#850

On 9/3/2013 6:16 AM, ivan@ivanx.com wrote:
> That's octal for every letter of "true" followed by ctrl-J and ctrl-M, but with bit 7 inappropriately set.

Hmmm.  Ron Kneusel had a series of articles here having to do with the 
high bit on the GS... have a google for:
Read full 8-bit character from serial port?
Read full 8-bit character from serial port (reprise)

You might also check your parity bit settings on the SSC (SW2-1/SW2-2) - 
see the SSC manual on printer vs. comms mode settings depending on which 
mode you're in.

[toc] | [prev] | [next] | [standalone]

#851

Ivan:

Schmidt's the serial genius, but this is a horse of a different color, so
I'll take a stab.

It's the doggone 'COUT' routine called from BASIC that's setting the high
bit, whether you want it to or not.

I _know_ I've got a short BASIC routine around here somewhere that POKEs a
few things and avoids the issue. Heck, I _think_ I saw a reprise of it in
comp.sys.apple2 within the last year or 2.

Probably something you can use SLAMMER with?

I'll look tonight.

As a temporary workaround to test your concept, you can use 'Space' parity
with the SSC and it will _force_ bit 7 low. For example, if you normally use
8,N,1 use instead 7,S,1.

<CTRL-A>1D<RETURN> or <CTRL-I>1D<RETURN>
<CTRL-A>7P<RETURN> or <CTRL-I>7P<RETURN>


Note that the SSC will require a <RETURN>, but the IIc will not. {The IIGS
doesn't support space parity at all}.

BTW, thanks for putting in all the work on A2Cloud (and A2Server). You
really don't sleep, do you?




Hugh Hood



in article cf8fc035-de7b-4ca9-8f06-c489834f5848@googlegroups.com,
ivan@ivanx.com at ivan@ivanx.com wrote on 9/3/13 5:16 AM:

> Hey serial geniuses,
> 
> I'm seeing something I don't understand at all.
> 
> In A2CLOUD, slot 1 is used for serial shell connection to the Pi. This works
> fine in Z.LINK and ProTERM.
> 
> I want to write a simple program that "types" a command at the Linux prompt,
> presuming I'm already logged in.
> 
> I tried the following program:
> 
> 10 ?CHR$(4);"PR#1"
> 20 ?CHR$(9);"12B"; : REM set 4800 baud
> 30 ?"true" : REM sample Linux command
> 40 ?CHR$(4);"PR#0"
> 
> I then fired up my comm program to see what happened. I can up-arrow to see
> the previous cammand, and I see "true" appear. But when I press return, I get:
> 
> '\364\362\365\345\215\212': command not found
> 
> That's octal for every letter of "true" followed by ctrl-J and ctrl-M, but
> with bit 7 inappropriately set.
> 
> Just to be super sure of what was happening, I write a version that explicitly
> sent the the characters I wanted (e.g. CHR$(116), etc) but I got the same
> result.
> 
> So somehow Linux is receiving the characters as high ascii. I have no idea
> why. Does anyone else?
> 
> Thanks,
> Ivan.

[toc] | [prev] | [next] | [standalone]

#854

On Tuesday, September 3, 2013 10:32:55 PM UTC-4, Hugh Hood wrote:

> It's the doggone 'COUT' routine called from BASIC that's setting the high
> bit, whether you want it to or not.

A ha. I thought I'd be cute and see if I could get it to not clear it by typing INVERSE, but that didn't work.

> I _know_ I've got a short BASIC routine around here somewhere that POKEs a
> few things and avoids the issue.

I'd like to see it!

> As a temporary workaround to test your concept, you can use 'Space' parity
> with the SSC and it will _force_ bit 7 low. For example, if you normally use
> 8,N,1 use instead 7,S,1.

This totally worked. I had an idea along these lines but was unaware of the existence of "space" parity. I was able to set it using either the ctrl-I code, or the System Utilities application.

> Note that the SSC will require a <RETURN>, but the IIc will not. {The IIGS
> doesn't support space parity at all}.

So my workaround for no space parity was to actually use stty to simply set 7N1 communications -- sort of unorthodox, but every term program supports it, and so that worked too.

I also tried stty istrip, as suggested by datajerk, and it certainly *seemed* like that should have worked by its description, but it had no effect. I did verify that it was actually enabled with stty -a.

So, this did indeed get me to the point where I could prove my concept. I was able to send, from Applesoft, "wget appleii.ivanx.com/nuinput/files/NUINPUT111.P.DSK; vsd1 NUINPUT111.P.DSK" and then boom, when I typed CAT,S2,D1, there was NuInput. spiffy.

This makes me think that I want to write an ampersand routine, so you can just send arbitrary Linux commands to the prompt, and get responses, without having to fire up a comm program. I could probably even make it a little bit smart and have it log you in if you aren't. I guess I'd need to figure out whether I want to talk to the SSC directly, or use the usual in/out vectors that I'm used to. (Any opinions about this?)

> BTW, thanks for putting in all the work on A2Cloud (and A2Server). You
> really don't sleep, do you?

You're welcome! And not nearly enough, no.

[toc] | [prev] | [next] | [standalone]

#855

Ivan:

Well, I _still_ haven't found that BASIC routine I've used to bypass the
forced high bit, but, here's another one. It was in a thread from 11 years
ago in comp.sys.apple2, presented courtesy of David's macgui.com:

<http://macgui.com/usenet/?group=1&id=201491#msg>

Just drill down to just about the end. You'll get the idea. The characters
you want to send are loaded into the accumulator (one by one) and then COUT
is called directly.

I'll keep looking. Based on your past performance, though, I'm confident
that whatever you come up with will be 'new and improved'.




Hugh Hood




in article 09ce076c-f68a-4abd-883c-9ad7d53d11ab@googlegroups.com,
ivan@ivanx.com at ivan@ivanx.com wrote on 9/4/13 7:32 AM:

> On Tuesday, September 3, 2013 10:32:55 PM UTC-4, Hugh Hood wrote:
> 
>> It's the doggone 'COUT' routine called from BASIC that's setting the high
>> bit, whether you want it to or not.
> 
> A ha. I thought I'd be cute and see if I could get it to not clear it by
> typing INVERSE, but that didn't work.
> 
>> I _know_ I've got a short BASIC routine around here somewhere that POKEs a
>> few things and avoids the issue.
> 
> I'd like to see it!
> 
> This makes me think that I want to write an ampersand routine, so you can just
> send arbitrary Linux commands to the prompt, and get responses, without having
> to fire up a comm program. I could probably even make it a little bit smart
> and have it log you in if you aren't. I guess I'd need to figure out whether I
> want to talk to the SSC directly, or use the usual in/out vectors that I'm
> used to. (Any opinions about this?)
> 
>> BTW, thanks for putting in all the work on A2Cloud (and A2Server). You
>> really don't sleep, do you?
> 
> You're welcome! And not nearly enough, no.

[toc] | [prev] | [next] | [standalone]

#856

Thanks. This looks perfect!

[toc] | [prev] | [next] | [standalone]

#857

In article <09ce076c-f68a-4abd-883c-9ad7d53d11ab@googlegroups.com>,
 ivan@ivanx.com wrote:

> This makes me think that I want to write an ampersand routine, so you 
> can just send arbitrary Linux commands to the prompt, and get 
> responses, without having to fire up a comm program. I could probably 
> even make it a little bit smart and have it log you in if you aren't. 
> I guess I'd need to figure out whether I want to talk to the SSC 
> directly, or use the usual in/out vectors that I'm used to. (Any 
> opinions about this?)

You might get some ideas from this simple terminal program written in 
Kyan Pascal and assembly.

<http://home.roadrunner.com/~jbmatthews/ssc.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#852

On 9/3/13 4:16 AM, ivan@ivanx.com wrote:
> So somehow Linux is receiving the characters as high ascii. I have no idea why. Does anyone else?

Another workaround would be to use "stty istrip" on the Linux side.  The 
istrip option will zero out the incoming high bit.

[toc] | [prev] | [next] | [standalone]

#853

Egan Ford <datajerk@gmail.com> wrote:

> On 9/3/13 4:16 AM, ivan@ivanx.com wrote:
> > So somehow Linux is receiving the characters as high ascii. I have no
> > idea why. Does anyone else?
> 
> Another workaround would be to use "stty istrip" on the Linux side.  The
> istrip option will zero out the incoming high bit.

Another possible option: the 6551 chip used on the Super Serial Card has
a parity mode which forces bit 7 to zero ("space parity" combined with
parity enable and 7-bit data) on transmit. In this mode, the receiver
will ignore the parity bit, so it won't help if you need to receive or
transmit 8-bit data.

Looking up a PDF of the manual, this mode is enabled by printing the
following commands:

<Ctrl-A>1D
<Ctrl-A>7P

The 1D command sets 7-data 1-stop bit mode.
The 7P command enables space parity.

To restore full 8-bit operation, use:

<Ctrl-A>0D
<Ctrl-A)0P

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#858

On Wednesday, September 4, 2013 1:19:11 AM UTC-5, David Empson wrote:
> Egan Ford <datajerk@gmail.com> wrote:
> 
> 
> 
> > On 9/3/13 4:16 AM, ivan@ivanx.com wrote:
> 
> > > So somehow Linux is receiving the characters as high ascii. I have no
> 
> > > idea why. Does anyone else?
> 
> > 
> 
> > Another workaround would be to use "stty istrip" on the Linux side.  The
> 
> > istrip option will zero out the incoming high bit.
> 
> 
> 
> Another possible option: the 6551 chip used on the Super Serial Card has
> 
> a parity mode which forces bit 7 to zero ("space parity" combined with
> 
> parity enable and 7-bit data) on transmit. In this mode, the receiver
> 
> will ignore the parity bit, so it won't help if you need to receive or
> 
> transmit 8-bit data.
> 
> 
> 
> Looking up a PDF of the manual, this mode is enabled by printing the
> 
> following commands:
> 
> 
> 
> <Ctrl-A>1D
> 
> <Ctrl-A>7P
> 
> 
> 
> The 1D command sets 7-data 1-stop bit mode.
> 
> The 7P command enables space parity.
> 
> 
> 
> To restore full 8-bit operation, use:
> 
> 
> 
> <Ctrl-A>0D
> 
> <Ctrl-A)0P
> 
> 
> 
> -- 
> 
> David Empson
> 
> dempson@actrix.gen.nz

I encountered this when build Apple Game Server -- I took a different route and handled it on the host/pc side so that the user is not required to change the default settings of the serial port for any specific reason.  (yay for transparency!)

-B

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web