jdg@elmgate.UUCP (Jeff Gortatowsky) (06/02/86)
In article <3100002@megamax>, eric@megamax writes: > What you need to do is establish a different mechanism for communicating > between the interrupt routine and the main program. The easiest method is > to declare some space in the interrupt procedure, preceeding it with a label, > and use PC relative addressing to access it. If you save A4 in the space > then you can directly access C global variables from your interrupt procedure. > Thanks for the response Eric... The premise I was under was munged up. I kept thinking that some routine was bombing my code. Indeed it 'twas I that was screwing up some system routine by incrementing the interrupted code's D7. As soon as I stopped incrementing D7 everything went hunky dori. However...... A new question..... why do I get spurious interrupt traps 40-50% of the time or more when I crank that timer up? To see what I mean use a prescaler of 4 and a data value of 14 or less. Indeed, at times the machine goes to sleep period. Other times as I've mentioned you'll be staring at 24 bombs. Correct me if I'm wrong, the MFP interrupts at CPU level 6. Further, since we use the MFP's software end of interrupt mode, no new level 6 interrupt can interrupt or pass it's vector during my interrupt routine. Not even the level 14 and 15 MFP interrupts. Since their are no level 7 (NMI) interrupts that I'm aware of (are there?) what could be causing the spurious interrupts? Even if their were another level 6 source (I believe the MFP is the only one) it should be blocked because the CPU is already at level 6. Right? The timer is clocked at 2.457 (or something like that) mhz so I don't *THINK* it's timing out before my code (being run at 8mhz) is completed. And again even if it were it won't be noticed until I clear the In Service Register right? Is there a limitation of the MFP I don't know of? For example you can't generate another interrupt with xxxus of the previous because the vector register junk can't setup in time. Or something like that? If so I missed it in the Motorola MFP manual. Any ideas? Anyone??? Now this is the type of stuff we should be discussing. I love it... PS. Has anyone noticed that the current ST could NOT use a 68020? The $##%$#$! OS writer's used the upper byte of the exeception vectors for data! Just like Motorola said not to! Wonderful aye? Of course their are other things that would need changing as well. Guess they never intended to extend the ST/TOS system beyond the current ST's. Then again considering GEMDOS.... it might be just as well. 8-) PPS. Does anyone know if GEMDOS is reentrant. I've heard that it is NOT and I've heard it is to 4 levels. Anyone know fur sure? Neil? What kinda hacking would it take to make fully reentrant? How 'bout the XBIOS and BIOS code? Is it fully reentrant? -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>