ctuel@polyslo.CalPoly.EDU (Cliff Tuel) (10/27/88)
I'm trying to write a program for my Apple //c which will monitor the modem and print a message to the screen if a call comes in. It should tell me how many people called and (perhaps) how many times the phone rang per call. I know it's possible, but I can't get the computer to receive the modem's result codes. Am I missing something? -- b---------------------------d ____ b----------------------------------------d | Cliff Tuel | / ` | "If sometimes you can't hear me, it's | | ctuel@polyslo.CalPoly.EDU | \__|_, | because I'm in parenthesis." S Wright | p---------------------------q | p----------------------------------------q
avenger@runx.ips.oz (Troy Rollo ) (11/06/88)
> I'm trying to write a program for my Apple //c which will monitor the > modem and print a message to the screen if a call comes in. It should tell > me how many people called and (perhaps) how many times the phone rang per > call. I know it's possible, but I can't get the computer to receive the > modem's result codes. Am I missing something? Try turning it on. Then try telling the modem to send back the full control response codes: ATQ0 ATV1 (if your modem has this option) ATX4 Now, when using the apple //c, if you're not concerned about portability, monitor $C0A9 - when bit 7 goes high a character has come in. Load it from $C0A8. This way you can forget about all parity by simply ignoring the incoming error results. Now, set up a routine intercepting interrupts. Provided you are not using anything else which generates interrupts at the same time as you run the comms program (VBL, some external disks, and mice), you can ignore checking for the ID of the interrupt and assume it's an incoming character on port 2. This can lead to portability problems, but in my experience the reliability of the checks on this port are not very good. I didn't bother to figure out why, but it will often lead to the machine giving a system error if you do interrupts on port 2 any other way. Now set up port 2 to pass incoming character interrupts onto the IRQ vector at 3Fsomething, place the characters in the buffer ofn the first half of page 8 in auxiliary memory. Then you can either set things up so that a call to the standard port 2 routines will return the character, but I suggest you write your own routine. Now that you have you characters minus parity checks, just process them and they should always be recognisable. I suggest setting bit 7 because it's easier to work that way on the Apple // range. Now, by setting the word format to 7N1, you can still communicate with most services. However if you come across one which doesn't like it, then you can bit fiddle the output of the comms port by setting the break signal for a one bit length period for every outgoing zero bit. This way you can have outgoing data at 8N1 or whatever you like, and keep it simple on incoming with 7N1. You can also do splitting of baud rates with this (although your crappy Bell standard in this area isn't of the greatest amount of use for your purposes, but if you use V23 - something sensible - then you can make use of this). Sett your timing loop to be as fast as is recognisable at the destinations, and the incoming characters will not affect it sufficiently to stuff up your loop. Confused? Well you won't be after this episode of "Soap". ---------------------------------------------------------------- Internet: avenger@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!avenger Me? Founder of the LCC? Would I do something that nasty? Cookie, cookie, gimme a cookie! Have a *NICE* day! How you can have a day I don't know but I'm sure there's some pervert out there who can figure it out!