Re: Game server and SSC

["BLuRry" <brendan.robert@gmail.com>]

Alex Freed wrote:
> After I read about the "game server" here I decided to try it. I don't have
> a 2c and (at least for me) it failed on a 2e with a SuperSerial card.
>
> Did anyone else try the combination?

Yeah, but it was a little tricky.  Read the FAQ on the website for a
few tips.  I plan to get the //e+SSC details a little more polished,
but have had a series of personal crisises at home that have prevented
me from turning on the //e long enough to debug the problem further.
And my serial USB driver hangs half the time when hardware flow control
is enabled -- which is unfortunately required to communicate with a SSC
but not with a //c.

> I don't even understand how it could possibly work: the game server's driver
> initializes the card for 115200 baud. This assumes a 1.8xxx MHz clock at the
> RxC pin of the
> 6551. Looks like this pin is not even wired on an SS card :(

Oh, it works.  But it is also possible to scrap the driver's init code
(set the first 4 bytes of the driver to EA, aka NOP) and in the
init.txt just comment or remove the section that sends the 115.2kbaud
init code as well.  Then set the SSC to 19200 baud and edit the
init.txt script to do the same for the java program (via the command:
!baud 19200)

> In addition if I just reboot the 2e and type IN#2 it shows "PR#2" on the
> screen after
> game server is started, but then beeps with a syntax error! The only way
> around it
> is issuing PR#2 from the keyboard first.
> Why?

Very odd.  If you have disabled the echo feedback mode, then it is most
likely that bytes were dropped along the way.  The core problem is that
the SSC (and //c) firmware is very very slow and unbuffered.  So if the
host is sending data faster than the apple can keep up (and this is
very easy to recreate at 19200 baud), the apple drops characters right
and left.

One way to avoid this is to use an echo feedback (!echo true) which
means the java program sends a character to the apple and the apple
turns around and sends that character back to the java program.  This
feedback loop is used to pace the data rate such that each character is
guarenteed received before sending the next, and so on.  As for the
syntax error, very tricky stuff.  In one case on the //e+SSC setup, I
was able to quickly type 300g<enter> to start the driver before the
java program gave up and everything worked fine.

Again, the FAQ and troubleshooting sections have some more information
about this.  Let me know if you're still stuck.

-B