Re: Read full 8-bit character from serial port (reprise)

["david__schmidt" <david__schmidt@a2central.com.remove-7ow-this>]

  To: comp.sys.apple2
rtk wrote:

 > Working with the ADTpro serial code I now have Forth setting up the
 > serial port, with baud rates up to 57600, and I can send full 8-bit
 > data out at that speed.  However, reading characters just hangs unless
 > I just sent a few characters, in which case it returns the characters
 > just sent.

Are you using the INITZSCC code too?

 > 0> B9600 initPort    \ setup for 9600, 8N1
 > 0> 65 m> 66 m> 67 m>    \ send ABC, which is received just fine
 > 0> m< emit             \ get a character, outputs "A"
 > 0> m< emit             \ outputs "B"
 > 0> m< emit             \ outputs "C"
 > 0> m< emit             \ hangs, characters sent from the other
 > computer do not appear

This rings a very, very faint bell.  Something I struggled with until I 
finally got things to work. :-/

 > So, this leads me to two questions:

 > 1.  Why are the sent characters still in a buffer where they can be re- 
 > read?

I can't remember.  As I said, it sounds familiar; there's still something 
wrong in there.

 > 2.  Why the lack of input characters.. is there a mode switch that
 > needs to be made?

No.  ADTPro uses the SCC code in a very dumb way.  When the user selects the 
IIgs modem port, it runs through the INITZGS code.  That will set up the SCC 
comms parameters and patch (*ahem* self-modify) to point to the SCC 
send/receive routines.  Then, whenever a byte needs to go out, it calls the 
send routine with the character to send in the accumulator.  Likewise, to 
receive - it runs the receive routine and expects the result in the 
accumulator (and if the user wants to cancel, the escape key will stop 
everything dead in its tracks and return to the main menu).  So all the SCC 
logic ADTPro needs is in that iigsscc.asm file.

 > As background, I'm using the send/receive character routines from
 > ADTpro (link to the source a few posts above).  The output a character code 
 > is unchanged, the input code does not look for ESC and stores the received 
 > character in a zero page location so Forth can pick it up.

Yeah, that should be fine.  Only variable left: the init routine.

 > I looked through the rest of the ADTpro code, for the client, and
 > failed to see where data is sent.

The received character is left in the accumulator.  Upon returning from the 
call to the receive routine, the caller just stashes the accumulator wherever 
they need to (typically the Big Buffer, for example).

P.s. I replied a bit earlier, thinking the lda $C000 followed immediately by 
lda GSCMDB was in the ADTPro code - hence a bug - but I see now that was part 
of the mods you're in the middle of, not something in the repository.  Whew!
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.