By far the best would be source level debugging for openmsx debugger.
A debugger running on z80 itself isn't reliable. And VDP acess etc cant be debugged on the MSX itself.
A simple file format and all the rest is the job of coders converters/makefiles.
filename sourcecode startaddress,endaddress,index_in_text startaddress,endaddress,index_in_text page 23 add ff00 mask 3fff startaddress,endaddress,index_in_text startaddress,endaddress,index_in_text
the "page" command is to make various buckets, because addresses can overlap in mapper business.
the page number isn't really a number but a string as ID.
who knows, there could be ROM mapper, or RAM mapper, or a sheme mapper*subslot.
the debuger doesn't bother all that, instead does display the bucket where the bytes of an interval match the binary.
startaddress,endaddress,index_in_text,c30000
one does not need to list all of the code of an interval.
to make it easy for converters from all sorts of .lst formats.
the end address is still needed:
an arrow displays at the index position in the text. the arrow will stay at this text index as long as the program counter matches the interval.
when no interval matches, make a question mark. show the closest matching region of the recently displayed page.
when multiple pages match, also show recent page, but show an exclamation mark 
change the view only when the arrow moves.
so as one is stepping and scrollbaring thru the source, the steps dont reset the view.
well some converter may get at info only per-function and that may be more than a screen high.
the "mask" does AND on both program counter and interval addresses. to match things in 16k page business.
a mask of 0xff will work with relocatible bloads.
and the add is done on the interval values only (in 16bit ring arithmethic). maybe it can help when some module started at 0 while after linking it is somewhere else.
the ADD should be done before the AND.
best is when each interval object has a mask, an add value, a pointer to string, then just run thru it statemachine style.
the commands processed in order of appearance.
Well I try to describe a little mechanism that could serve a lot of cases
The rest is all the job of the converters.
It works for both asm and C.
this is what SDCC puts in the .lst file
899 ;app.c:196: void main() {
900 ; ---------------------------------
901 ; Function main
902 ; ---------------------------------
0428 903 _main_start::
0428 904 _main:
0428 DD E5 [15] 905 push ix
042A DD 21 00 00 [14] 906 ld ix,#0
042E DD 39 [15] 907 add ix,sp
0430 21 EB FF [10] 908 ld hl,#-21
0433 39 [11] 909 add hl,sp
0434 F9 [ 6] 910 ld sp,hl
911 ;app.c:200: for (i = 0; i < 5; i++) { beep(); }
0435 11 05 00 [10] 912 ld de,#0x0005
0438 913 00109$:
0438 D5 [11] 914 push de
0439 2Ar08r00 [16] 915 ld hl,(_beep)
043C CDr00r00 [17] 916 call __sdcc_call_hl
043F D1 [10] 917 pop de
0440 1B [ 6] 918 dec de
0441 7A [ 4] 919 ld a,d
0442 B3 [ 4] 920 or a,e
0443 20 F3 [12] 921 jr NZ,00109$
922 ;app.c:202: *BAKCLR = 0;
0445 21 EA F3 [10] 923 ld hl,#0xF3EA
0448 36 00 [10] 924 ld (hl),#0x00
925 ;app.c:203: screen(8); //screen8();
044A 3E 08 [ 7] 926 ld a,#0x08
044C F5 [11] 927 push af
044D 33 [ 6] 928 inc sp
044E CDr07r01 [17] 929 call _screen
0451 33 [ 6] 930 inc sp
this is what I modeled the suggestion after.
grab a sourcecode line, then grab code address in next line, and grab the opcodes of that line. output a chunk in the format of the file in the other posting.
converters are relatively easy to write for all sorts of assemblers.
and PAGE / MASK commands for the address collisions that can happen on the slotted mapped MSX.
about telling the code of an interval,
one should be able to tell less code than the interval, more code (to give more clear identity when multiple chunks got same address), and "??" for places where DW variables are.
and then the arrow in the source would hop along with the debugger stepping, hop hop
