Well, the LSB byte of the called address is almost 'unknown'.
It should be 0xFF in 99,9% of the cases, iirc the sole known exception is the Gradiente Expert (Brazilian machine).
So, if you want to be sure to work even in those cases,
you need to waste 256+1 bytes of ram for each interrupt routine to be pointed.
I am somewhat confused,what if someone uses the hardware to generate interrupts in im2.Wouldn't that be so much faster than interrupt mode 1?In the sense that a vector table could be used for the keyboard,another for a controller,or mouse,or cartridge that would be connected to msx,or another one for midi.Am i saying something wrong?
can something like this be done?
The Yamaha CX5M does this. The software can set the value to be put on the data bus for midi interrupts and timer interrupts iirc. So the yamaha software uses this to determine what type of interrupt occurred. Note though, that the software disables the VDP interrupts, probably because the VDP doesn't put a well known value on the databus when interrupt occur.
Wouldn't that be so much faster than interrupt mode 1?
Of course it is, IM2 interrupts are usually faster (or at least easier) because in MSX the IM1 mode is used commonly through hooks or page 0 swapping strategies.
For a plain use, if you don't mind to loose those 257 bytes and can live with the weird ISR allocation address (LSB=MSB), IM2 is indeed a very powerful interrupt mode. When dealing with specialized hardware, this mode has no rivals, it was designed for this kind of tasks
If you need to read the LSB value of IM2 mode interrupt, you can use this Z80 databus monitor program:
http://www.msx.org/forumtopic3816.html
BUMP!
In most konami roms and megaroms the main loop of the game is something like
LOOP: JR Loop
Wouldn't it be better if it was something like this?
Loop:Halt
Jr loop
It would be better on modern architecture (power savings while waiting are possible) or for emulators (needs less cpu power when waiting for the next calculated interrupt).
However, on the real Z80 the 'JR loop' use as much CPU power as the HALT and is smaller in memmory usage, therefore I would even prefer that short one instead of including the unneeded HALT.
though including the halt would have a faster IRQ response
So the faster irq response would mean more speed in the custom interrupt handler?
