🚀 go-pugleaf

In a message posted on 22 Oct 90 18:24:49 GMT,
blubaugh@ucqais.uc.edu (Dr. Blubaugh) wrote:
DB>    I'd like the ability to drop in a serial card and have the system
DB>automagically know what it is and how to talk to it.  This means that

 ASDG tried with their ReDirector - If you opened 'Serial.Device', it
would actually pop up a requestor when you did the Open (IE:Only when
you FIRST run whatever program) and it would then use whatever device the
user had selected after that point.  Those authors that allowed for Any
device to be used (IE: About everything that I use ;-) would just use
CBMSER.device or SIOSBX.device (units 0 and 1).
   Now, what would have been interesting for them to have done is have:
  Unit 0: Eithor ask the question, or get the answer from some preferences
manager.
  Unit 1: 'internal' serial (cbmser.device, unit 0)
  Unit 2: siosbx.device Unit 0
  Unit 3: siosbx.device Unit 1

So, someone COULD write a shell that would allow you to set up a Preferences
to map Serial.device 'units' to device/unit combinations for the specific
software.
  For this list to come up on AutoConfig, Commodore Themselves would obviously
have to set this up.  The hardware Locations are already part of AutoConfig, 
the Software for the specific Card need only have Softeware on it as well.  
Since these are Devices, it's easier to have the user do a '1-time install' of
the specific software into the devs:, and then just have the user use
preferences to deal with the rest.

DB>getting the resident portion of the code going.  I then want DOS to
DB>know that additional serial/parallel devices are out there and have a

Here's the problem, though.  It's not DOS that needs to know about these
things, but the application.  Right now a lot of software just has 
'serial.device', unit 0 hardwired into the Binary.  IF it allows you to change
units (Which is what you need to do in the BEST case), the program usually also
allowes you to change the device. So, no matter what the specific authors do,
this has to be standardized.

DB>mountlist or worry about the slot that a card exists in.  When I access

???  Mountlists are only used for Handlers (IE: ser:) - Writing a SERx: that
would go through this preferences (x is the UNIT) would be trivial. This is
not where the software issues are.

DB>that is their and our loss.  I just think its ridiculous that IBM people
DB>can add multi-port cards and most all of their software can find the

This is because they have a hardware standard, not a software one - They are
in a much worse position than we are at this point.  They also STILL have to
have software SPECIFICALLY WRITTEN to allow multiple serial boards to work with
it - You can't just 'NewZap' the binary like a lot of us do now with Amiga
software (IE: NewZap references to 'serial.device' to 'supra.device' to use
the Supra CardModem)

DB>    Is this something that is bigger than Commodore?  Should the Amiga
DB>Software Developers be addressing this instead??  If third parties could

We're talking about 10 lines of code Total, something that I myself have done
many times.  Commodore seems to refuse to do it on Religious grounds.
 (IE: UNIX has this *BUG*, so AmigaDos needs it too ;-)

DB>agree upon a mechanism can we be sure that Commodore won't take a NIH
DB>(not invented here) approach much as they did with ARP??

Ahh, but we know what happened to ARP - I have a 3000 running 2.0 - I don't
miss arp - Once I get a replacement to RENAME, 2.0 will have EVERYTHING that
ARP did (And more...)

DB>Dwight Blubaugh Ph.D.
DB>UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP
DB>INTERNET: blubaugh@ucqais.uc.edu

---
  Opinions expressed in this message are my Own.  My Employer does not even
know what these networks ARE.

  Russell McOrmond   rwm@atronx.UUCP   {fts1,alzabo}!atronx!rwm 
  FidoNet 1:163/109  Net Support: (613) 230-2282
  Amiga-Fidonet Support  1:1/109