sutton@cherokee.cis.ohio-state.edu (roy a sutton) (02/06/90)
A while ago someone brought up an idea that is old to many 8 bit machines, but still unimplemented on the Amiga. It's a very simple solution the need for multiple serial ports for all Amiga models. This solutions is so simple, that it makes me wonder why no one has developed it. The only extra hardware would be a plain cable, which would make it the most cost effective solution around. And heck, if the software was written right, it could allow for the addition of two extra serial ports. It even seems to me that if an existing serial device driver could be found, its modification for this project would be a relatively simple task. What I re-propose is that a serial device driver be implemented for the software configurable use with either of the existing joystick ports. This solution would allow any existing Amiga to have three serial ports. Ok some people wouldn't want to loose there mouse input, and that fine because that software allow us to use either port we choose. However there are many situation where the Amiga can be set up to run, taking advantage of its new serial I/O, and not even need mouse input. An obvious example for its use is a multiple line BBS. What about all of us who have a terminal, a modem, and/or another Amiga connected to our system and hate not being able to use them simultaneously. Another idea for its use is in the creation of linear networking path. Let say we have more that two Amigas that we would like to connect together. With our new joystick serial ports, we could have as many machine as we like connected in an alternating fashion... joystick port to joystick port , serial port to serial port, etc. This project could be potentially beneficial to all, and to an experienced Amiga programmer, it shouldn't be that long of a project. Let's here what people think of this ideal. Am I the only one who need something like this or are there others who share my feelings? Does this should like a hard project? Is there anyone interested in its development? If someone has any source code for serial drivers, please mail it to me. I am just learning 'C', but if someone wiser than I does not take this project, I guess that I will be forced to attempt it! ************************************************************************
ckp@grebyn.com (Checkpoint Technologies) (02/06/90)
In article <76649@tut.cis.ohio-state.edu> sutton@cherokee.cis.ohio-state.edu (roy a sutton) writes: > > A while ago someone brought up an idea that is old to many 8 bit > machines, but still unimplemented on the Amiga. It's a very simple > solution the need for multiple serial ports for all Amiga models. This > solutions is so simple, that it makes me wonder why no one has developed > it. > > What I re-propose is that a serial device driver be implemented for the > software configurable use with either of the existing joystick ports. I invite you go forge ahead and implement this. You probably know why I wouldn't want to, I sell an add-in multi-serial card :-). I recognize the validity of the approach - I used to own a Tandy Color Computer, and it's serial port was a bit-banger. It works, but you shouldn't expect high performance. The Amiga could probably manage 1200 baud on a bit-banger without much loss and without hitting on system performance too hard. Higher performance than that will only come by sacrificing multi-tasking, and I doubt you really want to do that. You'll surely be able to make cheap serial ports, but cost-effective? That's a purely subjective call, depending on the application.
farren@well.UUCP (Mike Farren) (02/06/90)
sutton@cherokee.cis.ohio-state.edu (roy a sutton) writes: > What I re-propose is that a serial device driver be implemented for the > software configurable use with either of the existing joystick ports. Bad idea. In the first place, as you note, it would make one, the other, or both of the joystick ports unusable, a situation which I (for one) would find totally unacceptable. In the second place, there aren't enough lines on the joystick ports to implement full modem control. In the third place, the signals at the joystick ports are TTL levels, NOT RS-232 levels. And in the fourth, and most important, place - any serial data sent out the joystick ports would have to be under total processor control. This means that the maximum speed you could drive from those ports would be severely limited. It also means that multitasking is right out, unless you were willing to put up with dropped characters. I've used some of those 8-bit machines with this scheme implemented. It worked poorly enough for them that I found it unusable. For the Amiga, it's just plain dumb. -- Mike Farren farren@well.sf.ca.usa
swarren@convex.com (Steve Warren) (02/07/90)
In article <15996@well.UUCP> farren@well.UUCP (Mike Farren) writes: >sutton@cherokee.cis.ohio-state.edu (roy a sutton) writes: >> What I re-propose is that a serial device driver be implemented for the >> software configurable use with either of the existing joystick ports. [...] >I've used some of those 8-bit machines with this scheme implemented. >It worked poorly enough for them that I found it unusable. For the Amiga, >it's just plain dumb. Oh, come on, it's not *that* bad. There are ways to get around all the objections except the character-dropping/multitasking problem. Granted, that is a serious problem, but there *are* people who would see this as a reasonable trade-off to save hundreds of dollars. I wouldn't want CBM to support such a cludge ;^). But then how about some of the other cludges that people are using that CBM doesn't support. Are they dumb too? How about Matt Dillon's parallel-port DNET implementation? Does that filesystem ever drop characters under intense multitasking? (I'm asking - I don't know). I know it's a lot slower than the local file system, and a lot slower than the "legitimate" solution (ethernet). But it works and people apparently get good use out of it. In fact I'm not positive but it seems like there was power passed out through the joy-stick port. There are now RS232 chips that generate all the required voltages from +5 volts. And it would be possible to build the adapter to pass-through the joystick lines under program control. The joystick port would then only be unuseable when data is not currently being transmitted. If the user is willing to accept this restriction (as well as limiting compute-intensive work while using the extra port), then I don't see it as dumb at all. It's a cludge, but if it is useful and well-thought-out then I would consider it pretty clever, even if I personally didn't have a use for it. Cheers, -- --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
NETOPRBH@ncsuvm.ncsu.edu (Brandon Hill) (02/07/90)
I (along with some others around here) have contemplated the same idea.
However, to convert the game port to a serial port is not as trivial as
it may first sound.
First, the game port cannot alone drive a serial connection, as it is not
set up to sink or source the currents required for a serial connection.
Second, you can't directly receive RS-232 standard signals, because they
can be anywhere between -12 and +12 volts (way out of line with what you
can expect to apply directly to the game port)
Therefore, you must have something to transmit and receive signals. I have
heard that the Maxim Max-232 can transmit and receive standard signals more
or less from a 5 volt source using an internal DC-DC converter to drive the
lines at near 12 volts. If such a chip could service all the needed signals,
it could probably be stashed inside the hood of a db25 connector...which would
make the cable look like a simple db9 - db25 converter.
The hardware end, therefore, is almost trivial...or at least as near as can
be expected for such a project. The software is not nearly as trivial.
The first problem is that there are no lines on the game ports that will
trigger an interrupt in the cpu. This means that if you wish to receive data,
you will have to poll the receive line constantly. You might be able to get
by with simply polling at the bit rate (1200 times per sec at 1200 baud),
but you would be much safer polling at twice the bit rate to take care of
any switching transients. This will result in quite a bit of software
overhead which gets you nothing unless you are actually receiving or
transmitting data. I am not even sure that the amiga is capable, without
external hardware, of interrupting exactly a certain number of times per
second. (At least, the master int disable would reek major havoc on a software
driven bit level protocol)
In short, you might be able to do it, but you would be better off hanging a
uart off of the parallel port to get an extra serial port. And you would be
able to run at measurable speeds using a uart too :-)
BlHsutton@canopus.cis.ohio-state.edu (roy a sutton) (02/08/90)
In article <90037.161429NETOPRBH@NCSUVM.BITNET> you write: > >In short, you might be able to do it, but you would be better off hanging a >uart off of the parallel port to get an extra serial port. And you would be >able to run at measurable speeds using a uart too :-) > > BlH Thank you for your informative responce. I realy am not a level of schooling or Amiga hardware experience to completely understand what this would involve. I guess my scope only looks at the surface of the actual problem and is driven by my burning desire for college budget serial port. How feasible would it be to build hardware to use the parallel port? Could it be eligantly designed to allow other devices to use it when need? What about a hardware device to multiplex the existing serial port and uses the second joystick port for control switching? And finally... What about a SCSI hardware device? Shouldn't there be protocal provisions for this type I/O in the SCSI "standard." Ok, I will try anything that works resonably if it can be had cheaply.
farren@well.sf.ca.us (Mike Farren) (02/08/90)
A little clarification seems in order. First off, "just plain dumb" was my own judgement of the merits of a "bit-banging" serial interface for the Amiga, and not any kind of comment on the poster. As to why I consider the idea "just plain dumb", here's a bit of my reasoning, based on my own experience programming just such an interface on two separate occasions: The timing required for any full-duplex serial port makes it quite difficult to get reliable results at any baud rate above 1200, unless you are willing to dedicate the processor totally to the job. At 2400 baud, you have approximately 450 microseconds in which to grab a bit, shift it in (if it's a data bit), set a timer so that you can get the next bit, move the completed byte to a buffer if it's the final bit in a word, check to see if it's time to send an output bit out, get the next output byte if it's the last bit of a given word, update the buffer pointers, and last (but certainly not least) allow the application that's doing the communicating to do whatever it is going to do with the data. And that's not even counting OS overhead if you're trying to work in an OS-compatible way. Unless you are running a dedicated application which totally takes over the whole system, you're just not going to have enough time to handle all of the details of operation, unless you make severe sacrifices somewhere in the chain. The problem is simply in the amount of small-scale bit-fiddling you have to do in such a setup. The only time I was ever able to get a scheme like this to be useful was when I was programming a dedicated controller to do it, entirely separate from the main CPU. And even then, the absolute maximum speed I could get out of the thing was 4800 baud. 9600 baud gave me only 120 microseconds per bit, which was barely enough time to do all of the housekeeping necessary for either the input or output word, and not both. This was, admittedly, with a rather crude processor (an Intel 8021), but it wasn't THAT crude - it had a one microsecond instruction time, which isn't that far off from the actual instruction execution time of the 68000 at 8 MHz or so, when you factor in memory cycle time, and the multiple cycle nature of many 68000 instructions. -- Mike Farren farren@well.sf.ca.usa
dca@toylnd.UUCP (David C. Albrecht) (02/09/90)
In article <90037.161429NETOPRBH@NCSUVM.BITNET>, NETOPRBH@ncsuvm.ncsu.edu (Brandon Hill) writes: > First, the game port cannot alone drive a serial connection, as it is not > set up to sink or source the currents required for a serial connection. > > Second, you can't directly receive RS-232 standard signals, because they > can be anywhere between -12 and +12 volts (way out of line with what you > can expect to apply directly to the game port) Check out the MC1488 & MC1489 ICs (I think Radio Shack still carries them as 276-2520 & 276-2521). These chips are quad line drivers and receivers respectively. Their intention is DTL/TTL to RS232 conversion (or vice versa). David Albrecht
scotth@corp.sgi.com (Scott Henry) (02/10/90)
Hmmm... I can think of a couple of uses for a low-speed (1200bps) output only serial port. Like my crufty old 80cps Epson MX-80 printer (if I had another use for the parallel port), or one of those serial-interfaced X10 controllers, etc. Why waste a high speed port on a slow peripheral? -- Scott Henry <scotth@sgi.com> | These are my | Tardis Express -- when it Information Services, | Opinions only!| absolutely, positively Silicon Graphics, Inc | Whose else? | has to be there -- yesterday.
marki@tahoe.unr.edu (tahoe.unr.edu news administration) (02/11/90)
In article <90037.161429NETOPRBH@NCSUVM.BITNET> NETOPRBH@ncsuvm.ncsu.edu (Brandon Hill) writes: > >First, the game port cannot alone drive a serial connection, as it is not >set up to sink or source the currents required for a serial connection. > >Second, you can't directly receive RS-232 standard signals, because they >can be anywhere between -12 and +12 volts (way out of line with what you >can expect to apply directly to the game port) > >Therefore, you must have something to transmit and receive signals. I have >heard that the Maxim Max-232 can transmit and receive standard signals more >or less from a 5 volt source using an internal DC-DC converter to drive the >lines at near 12 volts. If such a chip could service all the needed signals, >it could probably be stashed inside the hood of a db25 connector...which would >make the cable look like a simple db9 - db25 converter. > [remainder deleted...] I've used both the MAX232 and, currently, the MAX233 on my thesis. The '233 has onboard capacitors and has worked with NO problems. For testing, the thesis was inside of an environmental chamber and it was connected to a Sun-4; distance of 60 (sixty) feet. I've done testing that took all day (10 hrs) with the instrument (thesis) dumping at least several megabytes to the Sun with no problems... so far!!! It generates ~+-10V from a single +5V supply. ...seems to be a good chip. --mark -- Mark N. Iverson uunet!unrvax!tahoe!marki / We dance round in a ring and suppose, marki@tahoe.unr.edu (scientists)->| but The Secret sits in the middle, marki@clouds.unr.edu \ and knows. -- R. Frost
tron1@tronsbox.UUCP (HIM) (02/11/90)
>---------- > Resp: 4 of 5 by *Masked* at ncsuvm.ncsu.edu >Author: [Brandon Hill] > Date: Thu Feb 08 1990 23:18 >First, the game port cannot alone drive a serial connection, as it is not >set up to sink or source the currents required for a serial connection. This is >NOT< a major problem. >The first problem is that there are no lines on the game ports that will >trigger an interrupt in the cpu. This means that if you wish to receive data, >you will have to poll the receive line constantly. You might be able to get >by with simply polling at the bit rate (1200 times per sec at 1200 baud), >but you would be much safer polling at twice the bit rate to take care of >any switching transients. This will result in quite a bit of software >overhead which gets you nothing unless you are actually receiving or >transmitting data. I am not even sure that the amiga is capable, without >external hardware, of interrupting exactly a certain number of times per >second. (At least, the master int disable would reek major havoc on a software >driven bit level protocol) Hmm.. when I looked at the software (wich I am more than willing to do) I was just going to do normal I/O through the gameport.device , this device currently has support for independant and simultaneous reception of at least 5 signals (left, right , up, down, fire) -- this is enough for a serial connection. Now , you would NOT run that mode of the device but you see my point , I think with the help of a 16550A (a UART with on board 15 character buffer) you should be able to get 2400 baid easy using the stanadrd intuition I/O library for that gameport -- forget the baud rate , let a clock on the external hardware set/decode it .. (fixed rate with a toggle switch maybe??) **************************************************************************** Everything I say is Copr. 1990, except the stuff I stole from someone else and the stuff I don't want responsibility for. Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
walker@sas.UUCP (Doug Walker) (02/13/90)
In article <5194@convex.convex.com> swarren@convex.com (Steve Warren) writes: >of the other cludges that people are using that CBM doesn't support. Are >they dumb too? How about Matt Dillon's parallel-port DNET implementation? >Does that filesystem ever drop characters under intense multitasking? >(I'm asking - I don't know). I know it's a lot slower than the local >file system, and a lot slower than the "legitimate" solution (ethernet). >But it works and people apparently get good use out of it. > What is kludgey about the parallel-port stuff? It's under interrupt control, so it doesn't hog the CPU; the parallel.device is DESIGNED and SPEC'ED for handling both input and output; NET: is an honest-to-god file system, installed with the Commodore-supplied MOUNT command and following all the rules. No, it doesn't drop characters. (It does occasionally hang, but I'm working on it :-). Ethernet is absolutely no more 'legitimate' than parnet. What makes the joystick-serial device illegitimate is that it would kill multitasking. If the user wants to put up with this, fine, let him. But it'll never be supported by C=. >Cheers, >-- >--Steve >------------------------------------------------------------------------- > {uunet,sun}!convex!swarren; swarren@convex.COM ***** =*|_o_o|\\=====Doug Walker, Software Distiller================================ *|. o.| || | o |// "Yes, it's time to change it, but I don't have anything to say" ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker