gilgan@ug.cs.dal.ca (S.O.D.) (02/13/90)
I have recieved many replies(like almost 10...) from my posting asking for help on using the SERIAL port(modem)..they all asked "PLEASE foward me any info you recieve.." but no replies(at least via email, I believe there was one reply on the net that I got) telling me how to do anything.. SOMEBODY must know how to do it or have source on how to open, read to, write from Serial.. apparently many people are having the same problem as I am, hence all the requests to me, so your words wouldn't fall on deaf ears.. thanks again... Tom
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/14/90)
In article <1990Feb12.223912.7167@ug.cs.dal.ca> (tom) writes: > I have recieved many replies(like almost 10...) from my posting asking > for help on > using the SERIAL port(modem)..they all asked "PLEASE foward me any info > you recieve.." but no replies(at least via email, I believe there was one > reply on the net that I got) telling me how to do anything.. > SOMEBODY must know how to do it or have source on how to open, read to, > write from Serial.. > apparently many people are having the same problem as I am, hence all > the requests to me, so your words wouldn't fall on deaf ears.. This seems a good testamonial to my case on the problems with the Amiga "serial" architecture. Anyway, the answer isn't simple. It goes something like this : Somewhere in your main routine you need to open the serial.device, to do this you have to allocated an extended IORequest structure, and created a reply port. There are descriptions on how to do this in the RKM but basically the flow is something like : ... struct IOExtSer Myserialstruct; port = CreatePort(0, 0); if (!port) abort("Can't create port!"); Myserialstruct.IOSer.io_Message.ReplyPort = port; error = OpenDevice("serial.device", 0, &Myserialstruct, 0); if (error) abort("Can't open serial.device!"); ... char read_a_character() { char a; Myserialstruct.IOSer.io_Command = READ; Myserialstruct.IOSer.io_Length = 1; Myserialstruct.IOSer.io_Data = &a; DoIO(&Myserialstruct); if (Myserialstruct.IOSer.io_Error != 0) return (0); else return (a); } Etc etc for the write and set parameters calls. If you want to just check to see if a character is available and return if there isn't one, then you will need to look up doing asynchronous I/O using SendIO/WaitIo. Read and understand the following sections of the available manuals and then ask more specific questions if you want to get answers : RKM Libraries and Devices : Chapter on serial.device Chapter on Exec/IO RKM AutoDocs and Includes : devices/serial.h serial.device Sorry about not going into great detail, but you have to meet us at least halfway. --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?!"
ric@hpspdra.HP.COM (Ric Peregrino) (02/14/90)
Concerning the serial port. I have an Amiga 2000 and more importantly I have
the hardware manual. In the manual you'll find the information needed to
interface to the serial port.
Personally, I was able to write code to read from the serial port and output
to the screen- string to tell if data "ok" or if "overrun" occured;
number of bytes received before timeout (if no overrun);
data received;
I used this to get MIDI data from a sampler. It entailed:
1. setting baud rate - writing number to SERPER register (114)
2. storing interupt enables in temp storage from INTENAR
3. disabling all interupts 0x7fff to INTENA
4. loop that
a. get data from SERDATR
b. check receive buffer full bit RBF if not goto a.
if yes check for overrun bit OVR if yes leave with error
if not strip off lower 8 bits and save in memory and increment stuff
c. loop times out with a counter
5. replace temp OR 0x8000 into INTENA and end
Rhe program can be used with redirection into a file to get serial data
into a file.
I don't have the manual with me so I can't give you the specific addresses
of these hardware registers. They are all in 0xdffxxx though. If you're
going to be doing anything specific for your own needs, get the manual.
I'd be happy to send you source for the above mentioned program which I
wrote in Lattice 5.04 C.
The manual also tells you about the rest of the hardware if you ever need
to know.
ric@hpspdnew@udel.edu (Darren New) (02/15/90)
In article <13570019@hpspdra.HP.COM> ric@hpspdra.HP.COM (Ric Peregrino) writes: >Concerning the serial port. I have an Amiga 2000 and more importantly I have >the hardware manual. In the manual you'll find the information needed to ^^^^^^^^^^^^^^^ >interface to the serial port. Ack! Yuck! Don't do this! What do you think this is, CP/M? :-) :-) Actually, I just grabbed the source for VT100r29 from xanth.cs.odu.edu. It looks like this will answer all your questions about doing I/O to the serial port, including multi-port boards and such. I you go direct to the hardware, neither multiport boards nore port-on-a-card boards can be used. Also, other programs won't know you are using the port, and preferences won't automatically configure it for you. Really, check out the VT100 sources. -- Darren
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/15/90)
In article <13570019@hpspdra.HP.COM> ric@hpspdra.HP.COM (Ric Peregrino) writes: >Concerning the serial port. I have an Amiga 2000 and more importantly I have >the hardware manual. In the manual you'll find the information needed to >interface to the serial port. > >Personally, I was able to write code to read from the serial port and output >to the screen- string to tell if data "ok" or if "overrun" occured; > number of bytes received before timeout (if no overrun); > data received; > >I used this to get MIDI data from a sampler. It entailed: [goes on to describe a lot banging on custom chip registers and interrupt disabling] For 99% of all applications, this is completely the wrong way to access the serial port. There are system routines for managing the serial device in a multi-tasking friendly manner, which should be used *whenever* possible. Reading MIDI sysex and MIDI sample dumps is just about the only exception I know of, since the Amiga will otherwise drop bytes on large transfers with the current software and hardware. Even then, commercial software (or quality PD) should allocate the serial port interrupt before banging away at the hardware, and should give the user the option of going through the system software in case she's using a third party serial board or a later rev of the system software which does keep up with MIDI data rates without dropping bytes on large transfers. [mini-flame coming up] If you want to be quick and dirty, you can write 0x7fff to INTENA in the privacy of your own home; I've been known to do kluges like this from time to time. But *don't* release software like that, and don't encourage other people to do it. It's the wrong way to do things on a multi-tasking system, and it ties you completely to the current system hardware. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
ric@hpspdra.HP.COM (Ric Peregrino) (02/15/90)
Concerning the serial port. In my experiences, I found that data overruns were occuring at higher data rates. Thus I went straight to the hardware and temporarily disabled interupts. Then I no longer got overruns, but this stopped all other processes. Good for getting large chunks of data fast, but not for a continuous link at low baud rates. Also, Pregnant Badger Software reports in their .doc that for large MIDI dumps (31.25kps), they lose one byte about every 4 kbytes. Unclear to me if they used the kernel or went straight to the hardware. The Amiga hardware manual reports rates of 100-250 kps possible with tight assembly loops. ric@hpspd
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/17/90)
In article <13570019@hpspdra.HP.COM> (Ric Peregrino) writes:
->Concerning the serial port. I have an Amiga 2000 and more importantly I have
->the hardware manual...
->1. setting baud rate - writing number to SERPER register (114)
-> ... I don't have the manual with me so I can't give you the specific
-> addresses of these hardware registers. They are all in 0xdffxxx though.
I take back everything I said about Europeans.
--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?!"ric@hpspdra.HP.COM (Ric Peregrino) (02/22/90)
No need to take back everything you said about Europeans. I'm from the USA. What's wrong with using the hardware manual to get a job done. I thought about this serial problem and the only solution that might be portable would be to make a board with about 512 kbytes of buffer and let it listen to the port continuously. Here a driver would interface the board to the AMIGA "correctly". This would be a big job, but it could work faster. 614kbaud is the max data rate from a Yamaha TX16W sampler. (RS422) In reading the RKM I found a statement saying that one should not disable interupts for more than 250us. My routine violated this but it exited gracefully; at least with no other active processes. Does any one know the underlying reason for the 250us? How about comments on a "cleaner" way of interfacing to MIDI without losing data on large data dumps (hundreds of kilobytes). 10 bits at 31.25kps (start+8+stop) is 320us. I noticed the RBF interupt is priority 6. How long does it take between an interupt to when service routine gets CPU? "damn the torpedos" ric@hpspd
navas@cory.Berkeley.EDU (David C. Navas) (02/22/90)
In article <13570022@hpspdra.HP.COM> ric@hpspdra.HP.COM (Ric Peregrino) writes: >In reading the RKM I found a statement saying that one should >not disable interupts for more than 250us. My routine violated >this but it exited gracefully; at least with no other active >processes. Does any one know the underlying reason for the 250us? Well, I've been bad in this manner -- and discovered that my interlaced screen would often de-interlace, seeing as how I was not allowing my copper interrupts to run... :) David Navas navas@cory.berkeley.edu