Re: A86: interrupts
[Prev][Next][Index][Thread]
Re: A86: interrupts
>Alright, even though I hate to argue about this, you have to realize
>that there is an incredible speed advantage to be gained ... especially
>with things like greyscale. I don't think either, that you would want
>to use im 2 from the OS, but it in a game... ;-)
How will IM 2 be a speed advantage?
Couldnt you just have it the user routine pop hl so it returns back to $38,
and just clear the usr_int flag before it ends the program so the OS doesnt
call the user routine, thus runs normally. You would still have the speed
advantage during the game, minus the keyboard reading and run indicator..
-Matt
http://www.dogtech.com/cybop/ti86/
>The vector table space isn't real a problem: you have almost all of page
>1 to work with.
>
>Kirk Meyer wrote:
>>
>> 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: