Is this your MSX2 hardware configuration?

because this differs, i need make a kernel for each hardware. The most popular almost.

Offtopic:

As an example it would be nice to have option to format for example only tracks 80-82

BTW it seems, that reading/writing tracks 80-82 is can be done on most MSX computers, but you can not format them. I wrote a program for MSX tR that formatted 738KB disks instead of 720KB and they worked just fine also in other MSX's that I tested (at least NMS8250 and NMS8280). Only problematic machine where I tested this was Sony HP-G900P that did not read it because of physical limitations of disk drive. This could have been solved by changeing diskdrive model.

My PC did not understand this format, but what you could expect from Windows machine It would be nice to test these disks with Linux, Amiga or Macintosh. I think they can follow the standard usually a bit better. This format is nice if you want to exchange DSK files between HD's as the whole image fit's to disk and you don't need any special software for read/write tracks. 8)

~NYYRIKKI

MNBIOS not suport the DISK-ROM because the MNBIOS remplace the original MSX2 BIOS on loading process.

I don't think, that you need original MSX BIOS to get basic functions of DISK ROM working, but you need to rewrite some routines & hooks on #C000-FFFF area. I must say that I'm not really sure about this, but maybe it is worth of check out. The disassembled NMS8245 DISK ROM source seems to have only 20 references to MSX BIOS and I don't think that they are used while doing just pure DISK I/O (no filesystem etc.).

If they are really used, you can select same RAM block to area #0000-3FFF and #C000-FFFF and fit the "MSX BIOS emulation code" to that space. Most of the slot I/O is done trough #F380 and #F38C so I think, you can hook the possible unwanted slot switching trough these addresses.

Anyway... this is just an idea, that could maybe work.

~NYYRIKKI

The problem is, the #c000 to #FFFE havn't free bytes for that, especially F380 or upper.

Well... You have to load the disk interface driver to some RAM page anyway. (I remember reading that disk drive takes extra 16K.) That same space can be used to make a interface driver to standard disk ROM as well. If this seems too hard, I think, that you can reserve another page of RAM as well to get it working. This may cause, that the whole kernel and all system variables need to be removed from visible page for a while and you may need to relocate SP etc. Anyway after loading you may return to the same situation. Worst thing is, that you may loose some interrupts while loading is in progress and RAM might be chuck away from aplications.

If #C000-FFFF is in use you can safely put the data away for a while and return it back after the load. This can be proved by executing routine below from BASIC. After this the original page 0, that is typically used for #C000-#FFFF is empty and there is still no any problems. Everything works even if you use DOS2 (In DOS2 remember to reserve page first). I know, that MSX-DOS manual says, that you should newer change last page, but there is actually no reason for that as long as the data is there. In this case you don't even need all the data.

	DEFB #FE
	DEFW BEGIN
	DEFW END
	DEFW BEGIN

	ORG #D000
BEGIN:
	IN A,(#FE)
	PUSH AF
	LD A,5
	OUT (#FE),A
	LD HL,#C000
	LD DE,#8000
	LD BC,#4000
	LDIR
	OUT (#FF),A
	XOR A
	OUT (#FE),A
	LD HL,#8000
	LD DE,#8001
	LD BC,#3FFF
	LD (HL),A
	LDIR
	POP AF
	OUT (#FE),A
	RET
END:

The only problem that might get you in trouble is, that I've seen mapper, that only worked on range #4000-#BFFF This is not anyway MSX standard mapper, so I don't think that you need to worry about that. I also guess, that you don't like this kind of ugly "glue" to your BIOS, but the only reason, why I'm suggesting this is, that I would really like to see this BIOS in action on all MSX machines as fast as possible, even if the disk handling is not fully implemented.

The better machine specific DISK routines can be then implemented later, but people get possibility to start developing already before those routines. Even if this makes the original BIOS mandatory (so that you just swap the BIOS versions on the fly), i think it is ok as this is a thing that can be fixed later. There are ton's of different disk drive solutions around and implementing them one by one will take horribly lot of time.

I know, that I'm impatient as you have been working on this for 6 years, but I think, that at this point the standard definition is not changeing that much anymore and you could really give it for people to play with.

~NYYRIKKI

I found some more info from: www.work.de/nocash/portar.htm#fdcioaddresses From the list I did forget at least Panasonic A1-W(S)X that has also probabbly TC 8566 AF connected somewhere.

~NYYRIKKI