Re: A86: interrupts
[Prev][Next][Index][Thread]
Re: A86: interrupts
the point though is (I THINK) that we want this to work all the time,
even in the OS. in which case we would have to use the user_int instead
of im 2. although you could use the memory addresses you found, lots of
people want to use those. _slink might be used by someone (i.e. me :)
soon and so might the alt_off_exec, not to mention the fact that the 257
byte table would spill into something else since _alt_off_exec is 200
bytes... (what i'm saying is, it can be done but for compatibility
purposes it should be done in the _alt_interrupt_exec).
Dux Gregis wrote:
>
> I found a nice place in the user off routine ($d500) and pointed it to
> $d3d3 (_slink). Besides, if you're just using it in a game, you can
> load the vector table to the graph memory or something like that.
> I admit, though, it is a pain ... but you can, however, really speed up
> greyscale games (would be very zoomin' if that port of Daedelus ever
> comes out--might even be faster than the 85 despite page swapping).
>
> Kirk Meyer wrote:
> >
> > yes, except using IM 2 gets messy. where are you going to find (257+x)
> > bytes of space to put the vector table and program (that's a rhetorical
> > question :)
> >
> > Dux Gregis wrote:
> > >
> > > Well, $d2fe is called within 38h (it's called at around 60h; hl, when it is
> > > popped in our routine, contains about 60h) . Our actual "user" code is stored
> > > at $d2fe. The pop instruction gets rid of the pushed program counter with the
> > > contents 60h. Then the reti instruction we put near $d2fe pops the address
> > > from whence the interrupt (38h) occured back into the pc register. (pc =
> > > program counter, if anybody didn't catch that :-) So here's what happens: our
> > > code is being executed, the interrupt is called, the interrupt gets the
> > > checksum and jumps to $d2fe, at $d2fe we tell it to return to where the
> > > interrupt was originally called rather than going back and finishing the
> > > interrupt. If it finished the interrupt, it would go do the stuff with the
> > > keypad and on ports, which starts at 66h (just a coincidence, there is no
> > > non-maskable interrupt).
> > >
> > > This is just so that you can understand what's going on. I think that if you
> > > really wanted to speed up the interrupt use in an asm prog, you would use
> > > interrupt mode 2, and just throw out 38h altogether.
> > >
> > > Matt2000 wrote:
> > >
> > > > Cool, I understand now. Yes, that was a good explanation :) . I see that it
> > > > this is using Mode 1 Interrupt Response, I honestly didnt know that before.
> > > > So basically when 38h is called it returns to 38h instead of 60h and thus
> > > > bypasses all the ports. Are any of those ports important though? What do
> > > > they do?
> > > >
> > > > >The interrupt itself is at 38h (I'm sure you knew that already :-) ;
> > > > >what the interrupt does is load a checksum into $d2fd and then make a
> > > > >call to $d2fe (the user interrupt routine). After it returns, somewhere
> > > > >around 60h, it does alot of wacked out stuff with the ports. Whenever
> > > > >you call, what you're actually doing is pushing the current program
> > > > >counter to the stack and loading the program counter with the address
> > > > >you pointed to (ex: call $d842). An rst instruction will also push pc
> > > > >and in the same way; so will the interrupt. Now, when the user
> > > > >interrupt executes, you have pc pushed onto the stack twice: the first
> > > > >address on the stack is the one where the user routine was called from
> > > > >the interrupt, the second one is the place of execution when the
> > > > >interrupt occured. When you tell the cpu to pop hl, you are actually
> > > > >popping pc into hl--the address to return to from the user routine--and
> > > > >throwing it away. When the reti executes, a different address will be
> > > > >loaded into the program counter: the original address from where 38h was
> > > > >called. This way, you can still use the interrupt, but skip all the
> > > > >stuff that the ROM does with the ports and thus speed up applications
> > > > >using it.
> > > > >
> > > > >Not a terrible explanation, I hope? :-)
> >
> > --
> >
> > =====================================
> > = =
> > = Kirk Meyer (mailto:_@ibm.net) =
> > = http://www.bigfoot.com/~kirkmeyer =
> > = =
> > = "Set your affection on things =
> > = above, not on things on the =
> > = earth." Colossians 3:2 =
> > = =
> > =====================================
--
=====================================
= =
= Kirk Meyer (mailto:_@ibm.net) =
= http://www.bigfoot.com/~kirkmeyer =
= =
= "Set your affection on things =
= above, not on things on the =
= earth." Colossians 3:2 =
= =
=====================================
Follow-Ups:
References: