🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #11316

Re: Multiple serial article from the European Developer's Conference

#11316
From: R. Scott Bartlett
Date: Tue, 07 Feb 1989 05:59
71 lines
3936 bytes
In article <3382@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>Flame on...
>AAAAARGH! Don't do it! Don't do it! Please please please don't implement
>this system. It provides no extra capabilities and adds YET ANOTHER LEVEL
>OF NAMING. There's too much name/level confusion as it is... just make
>new programs specify a device name and number...
>Flame off...
>-- 
>Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.

How does this new standard deal with multiple multi-ser cards?

For instance:

	User has a multi-ser card that has all of its ports used:

		Builtin Port -> terminal w/ AUX:
		Multi Port 1 -> modem
		Multi Port 2 -> printer
		Multi Port 3 -> Midi
		Multi Port 4 -> You think of something

Anyway, this user decides that he/she wants to start a multiport bbs while
keeping the original modem port reserved for his own use.  The user decides
that adding another Multi Port card would be a great idea.

Major questions pop up in my mind:

	1)  How do the two Multi-port cards deal with each other?  (does
	    autoconfig deal w/ non-memory cards?)
	2)  How does the serial.device deal with the two cards?
	3)  How are port numbers assigned between the two boards? (does it
	    depend on which is closer to the CPU? ala autoconfig)
	4)  What happens when you use cards from different manufacturers?

After reading the EuroDevCon paper on multi-ser ports, I am just left with too
many questions.  The proposed standard (or is it too late?) is good as a quick
fix, but i think that it is just a bandaid fix that is bound to wear out
sooner or later. (see above)

The default ser-port is a good idea, but i think the rest should be left up to
the individual board.  ie, have individual devices for each card.  This is going
to complicate the installation process for the user, but lets face it, computers
are complicated, and if users are going to want to do complicated things, they
are going to have to do a little reading and learn a little about what is going
on.  The problem for C= and 3rd pary developers is making this literature
available and readable.

	I know this is getting off the subject, but it is sort of related.
Many Mac enthusiests (sp?) tout that their machine is easier to use than the
Amiga.  This is true to some extent.  Macs come with a great piece of software
called (if i remember correctly) "Introduction to the Macintosh."  The Amiga
however lacks a comparable piece of software.  When you buy an Amiga, you are
on your own.  C/A needs to write a "Intro to the Amiga:  A friend you can trust"
program, and include it with ALL new machines and software upgrades.  The
manual can help the user with the hardware setup, and then direct the user to
insert the Into disk and power up the machine.  From then on, the user is
introduced to the Amiga, starting with the mouse.

Oh well, this has gotten entirely too long, and it has gotten off the subject.

						rsb

--
All of the abuv speling mistakes are entintional!! ;-)

-- 
rsb@dukeac.ac.duke.edu		///	"Amigas do it with hardware."-- Me
rutgers!mcnc!ecsvax!dukeac!rsb ///     "Sycamore is open."-- Negativ Land
I'm a HORSE, of course.    \\\///     "I luv S&M!!!"   "No geeks here!!"
Disclaimer NOT included!    \XX/     "This space for rent"
Technical Details
Message-ID: <1223@dukeac.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!ukma!xanth!mcnc!ecsvax!dukeac!rsb
References: <5877@cbmvax.UUCP> <3382@sugar.uu.net>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!ukma!xanth!mcnc!ecsvax!dukeac!rsb
From: rsb@dukeac.UUCP (R. Scott Bartlett)
Newsgroups: comp.sys.amiga.tech,comp.sys.amiga
Subject: Re: Multiple serial article from the European Developer's Conference
Summary: Possible problems with proposed standard
Keywords: Long
Message-ID: <1223@dukeac.UUCP>
Date: 7 Feb 89 05:59:41 GMT
References: <5877@cbmvax.UUCP> <3382@sugar.uu.net>
Reply-To: rsb@dukeac.UUCP (R. Scott Bartlett)
Organization: Center for Demographic Studies, Duke University, Durham, NC
Lines: 71