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: