DI EI

This is a memorable post... it's my 2525th

DI means that the z80 will ignore any interrupt from VDP
EI means that the z80 will jump to 38h when the VDP signals the interruptcorrection: DI means the Z80 will ignore any interrupt requests, period. Not just the VDP one(s)... EI means interrupt requests are accepted again. It depends on the Interrupt Mode which address is used to jump to:
IM 0 (not used on MSX): $38
IM 1 (generally on MSX): $38
IM 2 (device dependent): interrupt vector is derived from the I register and some device data

Even though the MSX only uses IM 1, it is of course possible to set IM 0 or IM 2.

It don't even matter if your routine will exceed the time that's between 2 interrupts. As long as those interrupts are withing 1 screen refresh.
I use that all the time. For example

LNI on 100, do a big VDP copy (will take about 100 lines in screen length)
EI after the copy instruction and do some more stuff I don't care about.

LNIon 140, do more stuff BUT VDP action. (the copy from LNI100 will still be active)

You see, overlapping INTs is no prob. (not really the INTs r overlapping, it's just the huge copy instruction)
just calculate and check. No need to DI and EI. Btw. DI is already done while on BIOS interrupt, so no need to use that one.

EI and DI are only necessary in NON interrupt routines (where ya don't know when another int will come while doing some bizar VDP zapping). Again, check and calculate. I always keep my INTs on as much as possible. But then again, I'm an idiot.

Interrupts.... aaah the sweet topic returns

Actually, IM0 has no jump address, it just makes Z80 put IORQ and M1 into the active state and execute a command from the databus after that. So since you cannot rely there is FF on databus for IM2 and expect it'll jump on vector at I×256+255, you also can't rely on it for IM0 that RST 38h will be received and expect jumping at all, not saying 38h.

P.S. Necroposting, I know

This is not quite exact in the case of mode 2. Mode 2 can be (and is) used in MSX regardless of the value of the bus. All you need is a 257-byte buffer aligned to a 256-byte boundary, and an interrupt service routine that starts at an address multiple of 257. You fill the 257-byte buffer with 257 repetitions of the address of the ISR divided by 257 and set the I register to the high byte of this buffer.

For mode 0, I agree, it's not safe to use unless you have guarantees that an external device places a valid instruction on the bus (typically an RST instruction). I guess it's safe-ish to use in MSX because there are no known devices designed to use IM 0 or IM 2, and therefore no one changes the default $FF.

Fair point.

I've made a test program to check the value of the bus during an interrupt, using IM 2. A de Bruijn sequence of order 2 and length 256 requires an alphabet of size 16, so that's what I've used. With some Python-Fu I have sorted and numbered the entries appropriately. There's a lot of wasted space that I didn't figure out how to avoid.

The test program has the following requirements:
- It needs at least 16K RAM.
- It uses addresses up to 0xEDF0, so care needs to be taken that these addresses are not used (disabling one floppy drive might suffice, not sure).
- In a 16K machine, there are only 192 bytes available to BASIC, so there's only room for short commands and no variables or BASIC program.

Run it with:

BLOAD"intbus"
DEFUSR=&HC201
?USR(0)

The last statement prints the value of the bus at interrupt time. Preferably run ?USR(0) several times so that there's no doubt. In OpenMSX it prints 255 as expected.

This zip includes the source, an intbus binary for floppy and an intbus.cas file for cassette.
http://www.formauri.es/personal/pgimeno/temp/intbus.zip