U46050@UICVM.BITNET (JOHN ZAFIRIS) (10/20/88)
Brian Walker, in response to my "interrupts" note writes: ...(stuff deleted)... >Third, when resetting the ipl, always save the initial value and replace >the value when you are finished. Then you don't have to guess what the >ipl should be. Remember, there are other interrupts out there and you >must remember to cooperate with other interupts. Vectors were left as they were found. I want to shut off ALL interrupts. In shutting them all off, there should be no conflicts. >Fourth, when dealing with interrupts, make it short and sweet. When >interrupting, keep it short. When stopping interrupts, do so only in >critical sections. Long intervals tend to mess up the computer's sense >of timing. This is a bit of a problem. My program executes for a long time: over 30 seconds. During this time the only part of the computer that is used is the parallel port (sound chip ports A & B) accessed directly (move.b). Why would the machine's timing be thrown 'off'? If the interrupts are shut off and my program alone has control of the processor, where would timing problems occur? No keys are pressed during execution nor is the mouse moved (unplugged). Nothing is active on any ports: midi, rs232 etc The timers in the MFP still tick away though. Could this be a source of trouble? >Also, mouse events come in through the keyboard processor. Each key or >button press and release is reported to the processor as make/break >sequences. It could be that you have held the interrupts too long and >caused the processor to miss a make sequence. In that case, a break >code without a preceeding make code is considered an error. This may be a problem because a key is pressed to initiate the program. The key is probably still down when the interrupts are shut off and is released before the program is finished. If this is what is causing my trouble I am going to kill myself. I'll look into it. >That's the hard way to do things. You should never have to short-circuit >interrupts. You also tend to lose information this way since the device >interrupts and is not serviced. In the case of the rs-232 and ACIA interrupts >the next interrupt will occur due to buffer overflow. Again, you're messing >witrh the machine's timing. I would not suggest doing something like this. I was desperate... >Also, have you considered try to write your routine as an interrupt driven >routine on something like the 200Hz or VBL processing. If you can do it, >you may not have to go through all of this. 200Hz is too slow and VBL is even slower, besides it has to be asynchronous. >>so I had all the interrupts clear registers 8 & 9 (ISRA,ISRB) of the MFP just >>before executing RTE. This did not work so I disabled all 16 interrupt sourc >>within the MFP by clearing registers 4 & 5 and restoring their original value >>before exiting: again no go. >Again, you're complicating the problem. Don't try to replace interrupts >unless you plan to do so permanently or over an extended period of time. >These interrupts are, for the most part, not covered by atari documentation >and basically not intended for use by programmers. Basically, you have no >idea what Atari plans to use them for or does with them. If you aren't >working with them, best to leave them alone. What I did was shut off all of them and then restored them to their old state when I was finished with them. I don't really care what Atari plans to do with them when they get around to providing new ROMs because this is not to be a commercial program, just a quick and simple (so I thought) way to accomplish a task. >By the sound of it, and I don't mean to sound calous, you are not exactly an >expert on low level processor operations. Therefore, do not consider >tinkering with your computer. That is, unless you have money to waste on >another machine. Not only do custom modifications void warrantees, big deal >eh, they can really mess up the circuits if you don't know what what you're >doing or may be doing. I don't mean to sound arrogant but the reason I need to get this program to work is to allow data transfer between the ST and another computer. The other computer is one that I have designed and built (68000 12+MHz) and which I have had absolutely no trouble with (unlike the ST: which has been around since 1985 and has had X revisions of the hardware and 0 revisions of the software (do you suppose this software can have some bugs that would make my life miserable???). Anyway, the problem does not occur on my 68000 box but does on Atari's. I would like to develop my software on my computer intead of on the ST but the ST has better assemblers, editors etc. (mine has none because I have not written it yet). I would consider porting the programs over and have them run X times faster but I don't feel like, or have the time to write a clone of GEM/TOS (do we really need another beast like that around?) I am not a novice in either hardware or low level software development but I have not run into this sort of a problem before either. Thanks for your suggestions. I will look into the keypress possibility and notify the net if it does indeed fix the problem. Thanks again... ...John
U46050@UICVM.BITNET (JOHN ZAFIRIS) (10/20/88)
Mike Russell writes the following in response to my "interrupts" note: > 1) turn of timer C - this gets rid of most of the big interrupts > and largely solved my problem of doing programmed i/o to > get a video image. > This looks promising: I'll give it a try. > 4) set the processor level to 7. This shuts out everything, however > keyboard event processing can easily get out > of synch if you leave things like this for more than 3ms. > Not a pretty sight - the keyboard decides it received a key > down event - then auto repeat kicks in. Yuck. The keyboard getting out of sync might be what is causing my trouble but would it do so much as freeze the machine up? I could see how the keyboard could get messed up and repeat 'til the cows come home but this (I don't think) would cause the machine to freeze up. My routine leaves interrupts off for much longer than 3ms. Is there a way to get around this? >I can send you this code if you think it'd be useful. It compiles under >Laser C. It's a bit of trouble for me to send it, so please consider >how useful it will be to you. > >Other questions: are you doing any disk i/o? If so losing interrupts could >hang things. Are you doing the spl's from interrupt code? Any bios, xbios, >vdi, or aes calls with the priority set high? Any details on exactly what >you're trying to do will help. If you just need reasonably quick access >to an ST device there may be some tricks you can do with interrupts. I haven't done anything in C for years and would have more trouble understanding the language than the algorithm...thanks for the offer. The ONLY part of the ST that I use is the ports on the sound chip (A & B). I use them to transfer data to another computer using a custom (read: rigged) parallel port and one handshaking line. The handshaking timing is what is critical. Thanks for the suggestions. I'll look into them... ...John