🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.transputer
1 messages
1 total messages Started by Moshe Braner Thu, 15 Mar 1990 16:24
link.c standard
#480
Author: Moshe Braner
Date: Thu, 15 Mar 1990 16:24
53 lines
3058 bytes
I'll leave it to the Inmos people to tell us how to get an "official"
copy of the semi-standard.  It is a set of C function calls for accessing
the transputer link(s), something like this:

int ld = OpenLink (char * "linkname");
int ResetLink (int ld);
int bytes_written = WriteLink (int ld, char *buf, int nbytes, int timeout);
int bytes_read = ReadLink (int ld, char *buf, int nbytes, int timeout);
int CloseLink (int ld);

and so on.  If all board makers would supply you with a driver that boils
down to those same calls, it would be easy to link to your code unchanged.

I have implemented extensions to the link.c calls, and have suggested
(still suggesting) adding them to the standard.  The extensions include:

An additional argument to OpenLink:
			int ld = OpenLink (char * "linkname", int flags);
			- the flag bits are OL_RDONLY, OL_DMA, etc.

int	StartRead()	- same a ReadLink(), but may return before the
			transfer is done, to be finished in the background.
			(Additional details on how to find out when the
			transfer is done, install an interrupt handler
			for when it's done, etc, skipped here...)
			And of course there is a StartWrite(), etc.

For IBM-PCs:

int	FarRead  (int ld, char far *buf, int nbytes, int timeout);
int	FarWrite (int ld, char far *buf, int nbytes, int timeout);
	                       ^^^
(This is not needed in the large-data memory models, but I need to use
far buffers in a small-model program.)

At another level, I have suggested (and implemented) another standard, for
MS-DOS, that operates at a lower level than the link.c standard, i.e., is
complementary to it.  The suggestion is to implement link.c via SOFTWARE
INTERRUPTS, to be handled by a memory-resident (TSR) driver.  (I use the
interrupt number 65 hex, is that a good choice?)  The advantage of this
is that the board vendor does not need to supply the driver in source
form, and the user DOES NOT NEED TO LINK the driver itself in.  Instead,
if the software interrupt interface is standard, the user links a stub
interface that is GENERIC AND PUBLIC, that just translates OpenLink()
to a certain software interrupt protocol, etc.  The application thus
created will WORK WITHOUT CHANGE with ANY board for which the appropriate
memory-resident driver is available and installed.  The downside is some
added overhead (execution time) for the software interrupt, about 200
microsecs on an 8 MHz PC-AT.  Not too bad, in my view, since it is
insignificant on the case of the transfer of large blocks of data, and
irrelevant in the case of an interactive program.

- Moshe
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads