Toolkit for DOOM/DOOMTOOL.ISO/net_doom/ser3.txt

Text File | 1994-04-25 | 5KB | 107 lines

1.    I won't compile Id's non-portable small-model code in large-model.
2.    I won't compile Id's non-portable small-model code in large-model.
3.    I won't compile Id's non-portable small-model code in large-model.
...
998.  I won't compile Id's non-portable small-model code in large-model.
999.  I won't compile Id's non-portable small-model code in large-model.
1000. I won't compile Id's non-portable small-model code in large-model.

Ok, I've learned my lesson now. :-)

There's a very interesting (and non-portable) line of code that
copies all of sersetup's arguments into a string so it can pass them
to doom.exe.  The reason ser.exe and ser2.exe don't work if you use
any arguments is that the arguments aren't getting passed -- and that
includes the two new arg's that serstup appends to the list which are
"-net" and the address of the doomcom structure for doom.exe to use.
Without those last two, doom.exe just starts up and goes straight to
the demo.

My appologies.

Well, having solved that problem, I've now learned quite a bit about
how sersetup works.  I've created a ser3.exe, which is in ser3.zip.
It's pretty close to ser2.exe, but I added a few print
statments in the connect() routine so we can see the PLAY0_0p msgs
being passed.  I also modified the stats a little, and added a couple
of new ones such as avg. bytes sent and received per minute, and per
interrupt.  Maybe that'll give us some kind of benchmark to compare
with.  And, of course, it still has these fixes:  (Are there more?)

  o  head and tail becoming too large (actually all mod's have been removed).
  o  extratics now set to 1, plus a -noextratics option.
  o  able to run with up to 19200 baud with the -19200 option.
  o  -irq and -port options fixed
  o  able to run with -dial and -answer, plus setup.exe (rename ser3.exe to
     sersetup.exe).  Ditch the dial.bat and answer.bat that came with ser2 :-)
  o  usage info with -? or -help.

I did a lot of testing, and had success with all 3 connection
types:  using a comm program, -dial & -answer, and setup.exe.  I also
tried using several arguments such as -deathmatch, -com2, -19200,
etc.  I also used the modem.cfg file for the init string -- but be
aware that some modems don't process anything after ATZ -- AT&F
(reset to factory defaults) is probably a safer bet.  I also sent
this to a few people to let them try it out first, and it seems to be
working right this time.  One person said they saw a big difference
with 14400, another said -player1 on the slower computer helped
quite a bit.

For those interested, here's the normal flow of msgs during the connect()
routine ("Attempting to connect..."):

        A                 B
    PLAY0_0 --->
                    <---PLAY1_0
    PLAY0_1 --->
    (launch doom)
                    <---PLAY1_2
                    (launch doom)

The first digit after the PLAY is the player #, the second is a
sequence # they use to figure out when both have decided on the
correct player #.  In the above example, computer A is player 0, and
B is player 1.  Both machines start at player 0 (unless the -player1
option is selected), but if a machine reads the PLAY0_0 msg from the
other side, it increments its own player # to 1.  If you've had the
problem of getting stuck in the "Attempting..." loop, there are now
print statements to help figure out what's going wrong.  I had that
happen once when one modem didn't have the proper setting for 14440
baud, but the other one did.  The modems connected, but they couldn't
talk.

Here are some numbers I got with the stats at the end of the game:

1.  With two 486-66's and two 14.4 modems (16550 UARTs) using 14,400 baud:
    313,261 Bytes read                    305,109 Bytes written
     89,444 Receive interrupts             38,151 Transmit interrupts
   32,239.6 Avg. rx bytes/minute         31,400.6 Avg. tx bytes/minute
        3.5 Avg. rx bytes/rx interrupt        8.0 Avg. tx bytes/tx interrupt

2.  With a 486-66 and a 386-25, both with same modems above:
    126,044 Bytes read                     55,637 Bytes written
     37,687 Receive interrupts              7,232 Transmit interrupts
   22,113.0 Avg. rx bytes/minute          9,760.9 Avg. tx bytes/minute
        3.3 Avg. rx bytes/rx interrupt        7.7 Avg. tx bytes/tx interrupt

The first configuration was of course perfectly smooth.  The second
was unplayable.  One person wrote me and said he had only 0.8 bytes
per interrupt, but it was perfectly smooth after he used 14400 baud.
My guess is that it's better to have lower bytes per interrupt on the
read side, and higher on the write side.  This may be more true when
using a 16550 UART, since it's writing up to 16 bytes each
interrupt.  Also, since the read interrupt is generated on the first
byte (in the 16 byte buffer), if you get low bytes/interrupt then the
computer is getting to that first byte very quickly and not letting
many pile up in the queue.  You would hope so especially if you have
an 8250 (16450) UART, since it only has a one byte buffer.  I haven't
done enough testing to see exactly what the difference in the numbers
is when using a 16450 with the same configuration -- soon though...

Any results sent to me would be greatly appreciated.  It'd be interesting
to know your type of hardware and modem speed as well as some of the
numbers you got.  Maybe we'll be able to figure out what configurations
are really necessary for a smooth game.  Thanks alot,

Russell     ([e-mail])