> Uthernet support would definitely be nice to have in the future, as I
> use one, and it kinda sucks having to move the laptop to get the thing
> running.

Sorry.  :-)  Only so much I can work on at a time.  It is open source,
and because of the //gs addition the specifics of SuperSerial (6551)
vs SSC (8530) are moved into separate included files.  So if if anyone
wants to take a crack at writing the following routines for Uthernet,
I'm all for it!

Init: Must initialize card and get it in a ready state
Send: Send one byte of data without interrupts (poll for empty buffer
if necessary)
Recv: Receive one byte of data without interrupts (polling unless
Uthernet buffers data for you)

Should be in RAW mode to work properly.  But is it possible to type
IN#n on the Apple and have it respond to telnet commands?  That's the
behavior I rely on for bootstrapping AGS.

> And, maybe add in an Q (or a PR#0) in the transmission to
> force it into 40 column mode before starting? That way, someone like
> me who defaults to 80 columns doesn't have to change it manually.

Agreed.  Actually, there is some "show display" code that is sent over
after the screen buffer is put into memory (which is why the hires
page shows up).  All I have to do is stick in the call to disable 80-
col firmware.

> I did notice, the apple2gs machine type doesn't work at all, the
> apple2gs_test type works perfectly.

Good to know.  Not sure why, but that would take more testing on my
part to determine.   Thank goodness I left that test routine in there!

> Here's what I get in apple2gs mode:
>
> /* executing line 141 */
> Failure writing line, retrying...

That's the hint.  Looking at that line in the init.txt file (in the
lib/data directory) reveals what it was trying to type.  The
difference was that the _test target disables a mode called
"echoCheck" which is used to verify what is being typed.  What I did
was use the _test target and I also took out a critical line sending
PR#{port}.  Because of that, the //gs never redirects output (echo)
back to the java program and it assumes there is a problem with the
communication.  echoCheck allows the program to send characters
immediately when it receives confirmation the previous character was
received.   Without echoCheck, it just adds a long delay and,
subsequently, takes longer to key in the program.

> ]C\
> ]C\

Yep.  it was typing "CALL -151" without a PR#2 before it, which should
happen in the [apple2gs] section but not the [apple2gs_test] section.
Sorry!  I forgot to put that back in.  Since the C wasn't sent back
from the apple to the java program, the java program canceled the line
and tried again -- unsuccessfully as it could tell.  For now, just use
the _test script target, or modify the file (look at the [apple2e]
section above, use {port} instead of {slot}).

> ]{at}{at}{at}{at}{at}{at}{at}{at}{at}{at}{at}{at}

At this point, the program says "screw it!" and decides you are
probably still running the SOS main loop (sitting in the menu already
-- {at} is a command to send an acknowledgment).  This assumption is if
you put the driver on a boot sector and put the disk in the drive.
(oh, did I mention you guys could try that too?  sorry, forgot to
mention that AGS supports load-via-bootdisk -- at least in theory!)
At any rate, if you're using the driver as a boot sector, the program
assumes the failure to key in the program is because you already
started the driver.  :-)

Wonky logic, but some feeble attempt to cover all bases.  :-D
-B
--- SBBSecho 2.12-Win32