SERNET and MIDINET instructions

Both SERNET and MIDINET provide you with low-cost networking like the Toolkit 2-Network. SERNET allows you to connect two or more machines which run SMSQ/E via the serial ports, whereas MIDINET allows you to connect two or more ATARI computers running SMSQ/E via the MIDI ports.

Both the SERNET and the MIDINET are organised as a circular net. In case of MIDI, the MIDI port OUT of every machine has to be connected to the MIDI port IN of the next machine. All cables have to form a complete circle. Every machine in the circle has to be working and the driver has to be loaded in order to have a running network. The same applies to the SERNET: with two machines, you can use a Null-Modem-Cable. With three or more machines, you have to wire your own cables so that all output signals from one machine are connected to the input signals of the next machine and so on, to form a complete circle as well.

SERNET has to be configured so that it knows which port to use as its communication port. Use MenuConfig to configure SERNET.RXT or SERNET_REXT (depending on your disk format) and define the ports. You should always add the "hd" parameters. but in case your port does not support hardware handshake, you can add "xd" for xon/xoff instead. BEFORE you LRESPR the SERNET driver you have to set the port to the correct BAUD rate. Naturally, all machines in the SERNET circle require to have their SERNET ports set to the same baudrate.

If you have differently powerful machines connected, then it can happen that slower machines do not respond to server requests. With fast machines, the server timeout of 0 should work perfectly well. For slower machines, increase the timeout to 1 or 2. The timeout needs to be changed only on machines where the server does not react properly. Try setting all timeouts to 0 first and see if this works, as higher timeouts reduce the net performance.

Of course, you can run MIDINET and SERNET at the same time to form two different circular networks of different machines, and these machines can also still be connected via TK2-Network (remember, in this case, you have to rename the MIDINET driver name from "N" to, say "M").

The MIDI driver

This is a simple I/O driver in many ways similar to a fast serial port. The MIDI driver maintains queues of received and transmitted data. These queues are accessed by the N driver and the server-job. You can use this driver by itself. if you wish, using the normal OPEN/CLOSE INPUT/PRINT and COPY commands from Basic.

The data which is read from a MIDI channel comes from the "previous" machine, the data which is sent to the MIDI channel goes to the "next" machine in the circle. With two machines only, data transfer is quite easy.

The MIDINET driver

This is a communications driver, which receives and transmits data in packets with headers and checksums, and has a built in retry system to handle transmission errors. It is used in conjunction with the server-job. It takes the stream of data from the MIDI driver queues and maintains a list of received packets, which is used by the server job. It is a directory driver, normally called 'N', but on a QL which already has a network called 'N', there is the ability to change the name to another single letter. Due to a bug in QDOS you should avoid letters already being used as the first letter of other drivers (eg 'F' is no good. as there is a 'FLP' driver).

The MIDINET driver has several associated keywords:

The current version of the drivers support all trap #2 operations except FORMAT, and most trap #3 operations including the extended version 2 filing system traps. Trap #3 operations which are NOT supported are: IO.EDLIN (IOB.ELIN) $4, SD.EXTOP (IOW.XTOP) $9, SD.FOUNT (IOW FONT) $25 and all graphics traps from $30 to $36 inclusive, and the extended trap #3 commands used by the Pointer Interface. Some of these may be added in later versions.

The access to a file on a remote machine is the same as accessing a file on the own (host) machine, but with Nx put in front of the filename. The N is the net driver name (which can be renamed, of course), the x should be the the number of the remote station. Some examples:

It is much easier if you use default directories or the DEV device:

MIDINET server-job

This is roughly equivalent to the Toolkit 2 FSERVE task. It monitors the list of received packets produced by the N driver, and acts on any commands it finds. You only need the server-job running on the remote machine, the one whose facilities you wish to access. Start it with the SuperBASIC command MIDINET or execute the MIDINET Thing with EXEP "MIDINET"

The current version of the server-job includes some special facilities for file protection:

Files beginning with (or in directories beginning with) *H or *h will be treated as Host Only, and cannot be read over the net. Any attempt to use these files will return 'not found'. Files beginning with *R will be classed as Read Only, and can be read, but not written to, as if the device is write protected. Files beginning *D will return 'not implemented' to prevent hackers accessing disallowed files by direct sector techniques.

These facilities allow you to keep sensitive files on a hard disc without anyone on the network being able to access them. However, these can cause problems with some software which does not expect access to be denied.

The SERNET Driver

There is a direct equivalent for most SERNET driver commands as found for the MIDINET driver. Instead of MNET these commands start with SNET.

The SERNET server-job

Of course, there is also an equivalent job for the MIDINET server job, called "SERNET". It can be invoked in the same way:

SERNET or execute the SERNET Thing with EXEP "SERNET"

SERNET/MIDINET Batchfile Execution

It is possible to invoke an SBASIC job on a remote machine and instruct it to execute a given SBASIC program. With this facility, you can do everything you like on the remote machine because you can provide SBASIC programs which do whatever you want them to do. To start an SBASIC program on a remote machine, use

EX "n1_*dev1_program_bas"

where "n1_" can be any kind of network name and station number, e.g. s2_, m1_ etc. and "devl_program_bas" can be any program on any device on the remote machine. Example: You would like to see what kind ofjobs are running on another machine. Create the following short program first, and save it to, say n1_ram1_jobs_bas

Then, after having it transferred to the remote machine, start it there with

EX "n1_*ram1_jobs_bas"

Please note, that the SBASIC filename specified must be the full filename, including device and extension. The server will not check PROG_USE settings, check for BAS or SAV endings because the remote machine can have totally different default devices than your machine, possibly resulting in an execution of a different program.

Return to Serial Links page