Re: Game server and SSC

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

> Let's try to debug this together :)

Definately.  ;-)

> The bad news is I don't speak java and don't even know how to recompile the
> java source.

No worries.  That's what I'm here for.

> Or is it interpreted? But still you need to byte-compile, right?

Well, yes and no.  The main program itself is java.  HOWEVER, the
script that is used to send over all the programming to the apple is an
interpreted text file, and resides in the lib folder.  The init.txt
script sets up the apple for the desired baud rate and sets it to
115.2kbaud, and the driver.txt contains the actual driver program.  You
should be able to control what the java program is doing just be
editing these two files.

> The good news is I have all kinds of toys line scopes and logic analizers.

nice.  I have an iPod that plays Doom and Tetris.  Maybe we should have
coffee some time.  :-D

> So here is what I see:
> 1. Power cycle a2e and type "IN#2".
> 2. Start a2gameserver in 19200 mode.
>...
> error in script, line 60:expected ] but timed out

This means it was waiting for the apple to send a basic prompt ] to the
java program right away, but the apple is not playing nicely and
redirecting output as expected.  Most likely you have to do this before
running the java program:

IN#2 (as usual)
CTRL-A (brings up a special SSC prompt) 2S (prompt disappears)
CTRL-A (SSC prompt again..) EE (prompt disappears)
CTRL-A (SSC prompt...) XD (prompt disappears)

then start the java program.

What these commands mean is:
2S: Redirect screen output to slot 2
EE: Enable echo
XD: Disable XON/XOFF flow control, which drops it back down to hardware
flow control

> Apple beeps with a "syntax error", but I see "PR#2" on the screen.

Well, what is going on by this point is that the apple is (supposed to
be) redirecting all screen output to the serial card, as per the PR#2
command.  If you comment the pr#2 line out (or remove it) and set !echo
false then you can actually watch it "type" everything to the apple.
this may help with debugging the problem but it won't be as reliable.

> I don't think it's a case of missing bits: same exact thing happens at 300
> baud.

> If I control-C out of it and start a terminal at 19200 it looks like the SOS
> driver
> is executing fine: @ results in "hi" sent back. "Axx" works etc.

Wow.  well, if you got that far I'll let you in on a secret.  kill the
java program (if it hasn't died already) and then replace the contents
of the init.txt file with:

!baud 19200
!flow HARDWARE

And then remove EVERYTHING from driver.txt (leave the file blank)
Since the apple is already running the driver, you can just skip ahead
to the fun part.  For extra points, save the driver to disk (bsave
SOS,A$BEEF,L232) and just BRUN the file to save time in the future.  I
plan to make a disk image that contains this in track 0, sector 0.
(you can do this by making a 140kb file and just replace the first 232
bytes with the raw driver code -- should work in theory)

> I'm affraid I am. Is there any way to execute java with a debugger? Should
> be easy with an interpreted language...

Yes, actually.  Netbeans is a free java IDE that also includes a
wonderful debugger -- also free.  It's how I debugged some of the
trickier code in this thing.  Anyway, you got the driver on the apple
and it executes, you've VERY close to enjoying the fruit of your
efforts.

If you get it up and running (you'll know, trust me), please let me
know if Montezuma's Revenge works.  I can't get it to run on my //c
anymore even though the binary is not corrupt. :-/

Good luck!
-B