Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!stpeter!cmcmanis
From: cmcmanis@stpeter.Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Question about multiple serial boards
Message-ID: <130368@sun.Eng.Sun.COM>
Date: 17 Jan 90 17:55:02 GMT
References: <7970@nigel.udel.EDU> <14137@grebyn.com> <130261@sun.Eng.Sun.COM> <4943@sugar.hackercorp.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Distribution: na
Organization: Sun Microsystems, Mountain View
Lines: 125

In article <4943@sugar.hackercorp.com> (Peter da Silva) writes:
>What should they have done? The serial port is in a documented name space.
>It's up to applications developers to provide a way of specifying the port
>number and device name to their program. Hardcoding ("serial.device",0) is as
>bad as a UNIX program hardcoding ("/dev/acu") or ("UNIX:0").

Why do people use the serial.device and not SER: ? The reason is fairly
simple, because the handler doesn't do what most people want to do with
a serial device, which is usually things like :

	set_baud_rate()
	set_frame_format()
	set_parity()
	query_baud_rate()
	query_frame_format()
	query_parity()
	check_for_character()
	wait_for_character()
	send_character()
	send_buffer()
	send_break()
	query_status()


These are the kinds of operations that any application might want to do
with the serial port, but the handler doesn't let them. Rather the 
handler will just let them read it and write it. (buffered no less) 

>I've seen people go around and around on this, and I'm still missing the
>point. Devices have names. Are the names aesthetically displeasing or
>something? Whatever *new* scheme Commodore came up with would have no better
>chance of being supported by developers than the *old* scheme.

You are absolutely correct, devices do have names but no one is arguing
that file requesters should put up "trackdisk.device", "harddisk.device"
as selections. But you may be overly cynical in believing that a new
scheme would not have a better chance of being supported. I think this
is only true if the new system didn't offer any benefits over and above
old scheme. And yet the benefits are clearly sufficicent to merit the change.

Consider what we are trying to accomplish, and the obstacles thereto.
The handler for the serial device sucks, granted, so lets fix it so
that people will use it instead. No more DoIO's to the serial device
and training new kids on the block that the loop :
	for (;;) { 
		Waitfor_1_char();
	  	Display_1_char();
	} 

which has the two disadvantages that these are custom routines built out
of calls to DoIO/SendIO/etc, and that they will be slower than molasses
in winter because the massive overhead of the various system calls for
each character. Instead have the handler read and write characters 
efficiently to and from the device for you, which it can because it is
a separate task. Then use a loop like :
	for (;;) {
		l = Read(ser, &buf, 256); /* Return all characters in buf */
		Write(con, &buf, l); 	  /* Write them to console 	  */
	}

which will have acceptable performance and uses prebuilt routines. That
will get people to use the _handler_ instead of the actual device
(because anyone who has written massive serial code with DoIO's will
welcome the change). Just that will have a *tremendous* benefit, now
with people using SER: instead of serial.device,0 we can point the
handler at anybodies serial device code just like we point the printer
handler PRT: to different printer drivers. Now people like CheckPoint
and ASDG can just deliver their drivers and tell users "To use our
port, set your preferences selection for the serial device to WhizBang"
And the application will automatically pick up the new serial device.

Once you get people using the name of the handler, you can actually make
it into a full fledged name space if you chose. We have pipe handlers that
let you do a directory of named pipes, why not a serial handler that lets
you do a directory of available serial devices. Type dir SER: and get things
like "modem, asdg1, asdg2, amiga" and now not only do you get human readable
names (rather than trying to remember that serial unit 6 is the third board
from the right, or was it left, first port). You also get a system supported
way for listing all of the serial ports attached to a system (which is
currently impossible given the DeviceList structure definition). Application
developers want some way of providing a selection of devices, well this is
it and they can use the same code that is in their file requester. 

Another red herring pops up in this discussion all the time as well,
what about backward compatibility with those programs that don't use
SER: ? Nonproblem, they still work with the Amiga serial port just fine
so what have you lost ? Nothing. The commercial applications will migrate
or die. The PD ones would definitely migrate because it would be so 
much easier to write them using this scheme. 

So what is this proposal/suggestion ? It can be laid out as follows :

	o New Serial Handler SER: that uses a field in preferences to 
	  to determine which device it defaults to. Additionally,
	  it supports packets that allow users to change/query baud rates
	  etc etc as described above. And it supports "locks" on different
	  devices so that the high level DOS commands such as DIR, COPY,
	  etc would do what you expected them to. 

	o New library, serial.library that does the actual grunge work of
	  sending the packets to the handlers and actually implement the
	  routines I've shown above. 

What do you end up with ? Well, you end up with a system that can now
have an unlimited number of serial ports added to it that can be
supported by all future applications because they have a well defined
and useful interface by which to access them. And further they can be
easily understood by experienced and novice users because all you have
to do is look in the directory and see which devices are there. This is
a Good Thing. It also gives us another leg up on the competition (PC,
Mac, and ST) because none of them have an expandable serial port
architecture.

If you play your cards right you can do this with PAR: as well and then
you are even better off. 

Of course it only works if Commodore decides to do it, if I write the
handler and library and give them away for free it will be 'nonstandard'
and no one will rely on them because you may not have them on your disk.
So here I sit.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"