             Fryers32 DLL Initialization Sequence
                     02/25/96 -med

The First thing that has to happen is to create the Fryers32 port object.
This is done the first time that the object is accessed. The actual 
command that is used is not important. It can even be invalid. 
It is the access to the object that triggers its creation. 

The port object can be destroyed by specifically calling the destroy
function in your application. If you do not destory it, it will remain
open (and possibily using memory resources) until your program terminates.
Given that the resources are small, this may not be a problem.


Note that disabling the Fryers32 driver with funtion $FF00 will not 
destroy the port object, it will release the communications port and
turn off the packet flow if enabled. The packet enable function 
provides a quick way to turn the packets on or off as needed without 
having to reinitialize the whole system. If the port object is 
not destoryed by the program, it will be destroyed when the program
terminates. A port object does not have to be destroyed. If you don't 
destroy it, it will however retain the memory resources it has allocated.

Any COM port from 0 to 15 can be opened (as long as the 
associated hardware exists). Note: You should always test for error 
returns to insure that the function succeeded. Once opened, the COM 
port will belong to the program until it is closed or the program 
terminates. You cannot share a comport with two objects at once. 
Only one object per comport is allowed. 


There are three commands needed to begin port operation:

  InitPort     $00xx - initialize the port configuration
  SelectPort   $FF00 - Start/Stop the port thread
  EnablePacket $FF10 - Start/Stop packet operation

InitPort $00xx :
 
This intializes the port object to the specified values. It is 
possible to call this function at anytime, even when packet operation
is engaged. This is to be compatible with the older versions of Fryers.
Keep in mind though that changing the configuration will cause any 
packet operation to be canceled since the code must shut down the port 
to reinitialize it. Port operation will be restored to previous 
conditions after the change is completed (except that the requested 
changes will be in effect). 

Unlike the MSDOS driver, in Windows, this function will not change 
the port hardware until a port thread is running (see SelectPort).

The function will check if the port is open, if it is, it will cancel 
any packet in process, close the port, re-initialize the port to the 
new baudrate (about the only thing that this function actually does). 
It will then turn on the port if that was the previous state (or 
leave it off if the port was not on). If packet operation was on,that 
will also be enabled. Any packet command that was in operation during
this will however be lost. 

If a port is not open, the function will save the configuration value 
for later when the SelectPort command is called.

Note: as a side effect of this function, any running port thread will 
be destroyed. It will be recreated afterwards if the port was 
previously enabled. It should be noted though that it is possible
for Windows to fail this function should the resources not be 
available at the time of the request. It is unlikely, but is possible.

It can fail either because the port was stolen (or in use) by another 
application, it can fail if this is the first port object call and 
there were not enough resources to allocate the object, or it can fail 
if there were not enough resources available to restore the port thread 
if a thread was running at the time this command was called.


SelectPort $FF00 :

This will create or destroy the port thread. As a side effect it also
controls the packet operation in that if the port thread is destroyed, 
the packet operation is also disabled. Once the packet operation is 
disabled, you have to call the Packet enable function to restore it. 
This function does not automatically re-enable packet operation.

If the port was never initialized with the InitPort ($00xx) function,
either the last known baudrate, or the default baudrate (9600) will be
used when the port thread is turned on. As with the MSDOS version, 
if this port is already running and there are no changes, this command
will be ignored. 

The attempt to obtain access to the requested port will happen at the 
start of this command. If it fails, the port thread will not be 
created, and the result will be the same as if this function had been
called with the disable request.

Note: Since this command creates a thread that attaches to a COM port,
it is possible for Windows to fail the command should the resources 
not be available at the time of the request. 

It can fail either because the port was in use by another application, 
it can fail if this is the first port object call and there were not 
enough resources to allocate the object, or it can fail if there were 
not enough resources available to create the port thread.

If Windows fails the function, a negative value will be returned in 
register AX. If there is no failure, register AX will return a 
positive value.


EnablePacket $FF10 :

This will control the packet operation. When this is turned on, the 
port thread will begin looking for and responding to polls. When it 
is turned off, the thread will save the incomming data to a receive 
buffer that can be accessed with commands $02xx and $03xx. If the 
buffer overflows, the excess data will be discarded. 

There is no unusual failure from this command other than if it 
attempts to call a port that doesn't exist, or the port object was 
never initialized (in which case the command will be rejected).
Command $FF00 must have been called before this command to enabled 
the communications thread.

As a side note to myself, I want to leave open this function 
capability to be compatible to the old Fryers driver such that it 
will operate as a buffered ASCII IO port with available CTS/RTS 
control when the port is open but packets disabled. That way if 
for some reason we need to use it to talk ASCII with the application
using the DLL we can do that. I'm thinking here of the old 10K 
application. There may be a need to support the audiometer in 
ASCII mode as well. I don't think that there will be a need to
support the 3100 or 5500Z which used ASCII since these are obsolete
and there are very few of the systems that used RS232 left. 

---

Notes: There is no Fryers command to discard a port object directly, 
but you can use the object destroy command to discard a port object
once you are done with it. Discarding a port object will cause it 
to turn off packet operation and destroy any associated port thread.
Any existing packet command will be canceled.


Example call to shut down communication and release a port object:

  FryersIO[FryersHandle].Destroy;


history:
12/13/96 -med : first creation
02/25/96 -med : revised

<eof>

