> Response of own-interrupt-expert Grauw...
>
> If you are programming a game or so I'd suggest you switch RAM in slot 0
> (who uses the bios?) or use another interrupt-mode (IM 2, if I'm correct.
> Don't forget to switch back to IM1 afterwards!).
Yes, it's IM2.
But it's not that easy to use. IM2 works like this:
- interrupt register contains high byte of entry in interrupt vector table
- at the time of an interrupt, the data bus contains low byte of
entry in interrupt vector table
In the interrupt vector table, an address is read and that is where
will be jumped to (begin of interrupt handler).
Most MSX systems have #FF on the databus at the time of an interrupt,
but I heard (from one of the NOP members) that some cartridges mess
with this, so you cannot be sure.
The safe way is to store the same value in a 257 byte long range like
#4000-#4101 and set the I register to #40 in this example. If the
value stored is #41, #4141 will always be the address.
But I think a custom BIOS is much easier to use, unless you plan to
use BIOS routines.
> :#FD9A: called on every interrupt which occurs,
> : normally not used by the system, only some special software.
> : - there shouldn't be problems if I won't call this old entry
>
> Used by the newest version of MBWAVE and its basic-replayer.
But your custom BIOS can call the MBWAVE replayer directly, if you
use it.
> Also, the stop of the drive isn't really 'good' when you call it 256 times
> after a diskoperation, it will STOP. Immediately after every disk-access.
> Which isn't that nice...
That's true, you have to stop the drive after every block of disk
actions.
Another thing to remember: if you need disk swapping in your game and
you run under DOS2, be sure to invalidate the disk buffers before
every block of disk actions. There is a DOS2 call that does this.
Otherwise, the disk change will not be detected on most machines. On
non-turbo-R, DOS2 'detects' disk change simply by counting the time
since the last disk action. It is assumed that no-one can swap a
disk in less than a second (or another small time interval). If you
stop calling #FD9F, the counting stops and DOS2 can think the last
disk action was very recent but in fact several minutes have passed
since.
> :What is your opinion? Will I be in troubles by removing this two calls?
>
> No troubles, I think, but some things might not work correct anymore.
Isn't that a form of trouble?
> In my own interrupt-routines, I always call #FD9A and if it's an
> VDP-interrupt I also call #FD9F, fill in the key-table, increase JIFFY and
> do some game-related things.
>
> But I dunno if you can speed-up the interrupt that much.
> Yes, I know your thinking... You hope to be able to delete some PUSH and
> POP-instructions at the beginning.
The real speed gain comes from:
- Not filling the key-table: games are usually interested in only a
few keys, not the whole keyboard. Besides, why not read the keyboard
directly from your game?
- Keeping VDP status register 2 enabled all of the time. Or register
1, if you use line interrupts frequently. This doesn't make your
interrupt routine faster, but it can speed up your non-interrupt code.
- Not decreasing the disk drive counter, which requires a slow
inter-slot-call.
- No writing to the joystick registers of the PSG. If you omit that,
you will be able to use the JoyNet without disabling interrupts.
So you gain speed not by doing the same in less time, but by doing
less.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
