I'm trying to create a "slideshow" based on a loader (.COM) and several picture files (.RAW). The app works fine as a standard DSK; but after creating the ROM (I'm using dsk2rom -dfc 2 <input> <output> it shows a strange behaviour depending the machine where it runs. Seems that on MSX2 machines boots & run fine; but in TurboR machines it doesn't boot at all, it always start BASIC and I can see the disk content when "files" is executed. Any clue of what's happening here?
The readme states that this tool only works for emulators; so this means that I can't dump the rom created to a FlashROM and execute it on a real MSX?

Are MSXDOS.SYS and COMMAND.COM included in the DSK when you make the ROM? If not it will always end on BASIC

Also the program cannot write anything "on disk" - mainly because there is no real disk - everything is read from the ROM.

Check the DSK size... I once tested 180k single sized disks and end up on BASIC as you described. Test 360k, 720k disks and see if the same happens.

And I just tested... indeed it doesnt work on real MSX... dont know why

How do you execute the ROM ?
I remember on msx1 and msx2 if 4142 is present in 4000 and 4001, it will "boot" the cartrigde rom (make the rom start) if you call 0000 or reset.

On turbo-R i think you have to call another routine to do it, since call/jp 0000, will not "boot" even if 4142 is present.

-Claus-

Quote:

Are MSXDOS.SYS and COMMAND.COM included in the DSK when you make the ROM? If not it will always end on BASIC

Yep, in fact they're MSXDOS2 & COMMAND2. When booting the MSX2 emulated machine I load also the MSXDOS2 rom and all runs fine; but when comes to repeat the process on the TurboR it doesn't boots.

Edit: I'm trying several combinations and I'm not able to boot even the DSK; so seems that it has nothing to do with DSK2ROM. I'm not able too boot an MSXDOS2 dsk with TurboR, nor using BlueMSX neither OpenMSX. I've tried with/out a MSXDOS2 rom loaded (IIRC the TR machines were shipped with a 2.30 kernel). Now I'm confused, MSXDOS2.SYS, COMMAND2.COM & ROM kernel must exactly match versions in order to work?
The file set I'm using now (all DOS 2.20) works fine on a MSX2.

Quote:

Also the program cannot write anything "on disk" - mainly because there is no real disk - everything is read from the ROM.

Yes, I'm only using read operations. The actual disksize is 720Kb and the ROM generated seems to work on an emulated MSX2 machine (actually I've needed to use the -d flag, still not sure about the reason).

Quote:

How do you execute the ROM ?

No problem here, it's executed by the emulator right after being created by this tool. It's only a 64Kb "standard" ROM as the initial files are still small (I think that finally it could be 256Kb).

AFAIK, a turboR only boots dos2 if the floppy was formatted in DOS2. Maybe that's the problem? With:
diskmanipulator test.dsk create 720
you create DOS2 disks by default.

I dont think DSK2ROM emulates DOS2, only DOS1 calls - maybe that's the problem

As for running on a real machine, I tried loading the ROM with execrom, loadrom and trload - none worked

Quote:

a turboR only boots dos2 if the floppy was formatted in DOS2

Indeed It could the reason!. Right now I'm dynamically creating the DSK using the wrdsk tool by Arnold Metselaar. Looking at the code he uses this boot data to create the disk image:

byte BootBlock[] =
{
  0xEB,0xFE,0x90,0x56,0x46,0x42,0x2D,0x31,0x39,0x38,0x39,0x00,0x02,0x02,0x01,0x00,
  0x02,0x70,0x00,0xA0,0x05,0xF9,0x03,0x00,0x09,0x00,0x02,0x00,0x00,0x00,0xD0,0xED,
  0x53,0x58,0xC0,0x32,0xC2,0xC0,0x36,0x55,0x23,0x36,0xC0,0x31,0x1F,0xF5,0x11,0x9D,
  0xC0,0x0E,0x0F,0xCD,0x7D,0xF3,0x3C,0x28,0x28,0x11,0x00,0x01,0x0E,0x1A,0xCD,0x7D,
  0xF3,0x21,0x01,0x00,0x22,0xAB,0xC0,0x21,0x00,0x3F,0x11,0x9D,0xC0,0x0E,0x27,0xCD,
  0x7D,0xF3,0xC3,0x00,0x01,0x57,0xC0,0xCD,0x00,0x00,0x79,0xE6,0xFE,0xFE,0x02,0x20,
  0x07,0x3A,0xC2,0xC0,0xA7,0xCA,0x22,0x40,0x11,0x77,0xC0,0x0E,0x09,0xCD,0x7D,0xF3,
  0x0E,0x07,0xCD,0x7D,0xF3,0x18,0xB4,0x42,0x6F,0x6F,0x74,0x20,0x65,0x72,0x72,0x6F,
  0x72,0x0D,0x0A,0x50,0x72,0x65,0x73,0x73,0x20,0x61,0x6E,0x79,0x20,0x6B,0x65,0x79,
  0x20,0x66,0x6F,0x72,0x20,0x72,0x65,0x74,0x72,0x79,0x0D,0x0A,0x24,0x00,0x4D,0x53,
  0x58,0x44,0x4F,0x53,0x20,0x20,0x53,0x59,0x53,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xF3,0x2A,
  0x51,0xF3,0x11,0x00,0x01,0x19,0x01,0x00,0x01,0x11,0x00,0xC1,0xED,0xB0,0x3A,0xEE,
  0xC0,0x47,0x11,0xEF,0xC0,0x21,0x00,0x00,0xCD,0x51,0x52,0xF3,0x76,0xC9,0x18,0x64,
  0x3A,0xAF,0x80,0xF9,0xCA,0x6D,0x48,0xD3,0xA5,0x0C,0x8C,0x2F,0x9C,0xCB,0xE9,0x89,
  0xD2,0x00,0x32,0x26,0x40,0x94,0x61,0x19,0x20,0xE6,0x80,0x6D,0x8A,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}; 

Is it a DOS2 boot block?. If finally that's the reason I think that could be handy to add an option to select the correct boot block to write...

Quote:

I dont think DSK2ROM emulates DOS2, only DOS1 calls - maybe that's the problem

...but the same works flawlessly on a plain MSX2 machine!. Seems that only TR are affected

Quote:

As for running on a real machine, I tried loading the ROM with execrom, loadrom and trload - none worked

Very bad news for me.....I had plans based on this feature

Quote:

Some doubts about DSK2ROM...

Oh no!

Quote:

The readme states that this tool only works for emulators; so this means that I can't dump the rom created to a FlashROM and execute it on a real MSX?

The tool was made when I bought a MegaFlashSCC; so actually it was targetted for flash devices (or 'real' roms).

Quote:

Yes, I'm only using read operations. The actual disksize is 720Kb and the ROM generated seems to work on an emulated MSX2 machine (actually I've needed to use the -d flag, still not sure about the reason).

The -d flag will disable exclusive mode. Exclusive mode means that the dsk2rom diskrom prevents other diskroms from booting (called it "hostile" mode). This is done so other diskroms (internal diskrom and dos2 diskrom) won't snoop some extra memory and images that require 'ctrl' to boot, still work.

Quote:

As for running on a real machine, I tried loading the ROM with execrom, loadrom and trload - none worked

That's correct, and not fixable (maybe if you load the rom image in another mapper than the primary mapper, don't know if these tools are able to do that). When data is loaded from the diskrom, it will probably overwrite the diskrom itself. An abstract illustration; the diskrom (the one that you converted) is at $4000 in ram, when data is loaded, eg. via msxdos, it could overwrite the 'program' at $4000 => crash.

Quote:

Is it a DOS2 boot block?. If finally that's the reason I think that could be handy to add an option to select the correct boot block to write...

I don't think so, I think that's indeed the problem why it fails on turboR and not on msx2.