Menu
▾
▴
#68 Auto-run feature
It would be nice to have an optional autorun feature.
Whatever (MSX-) file you give to openMSX, it will try
to run it. So, if you give a bas file, it will create a
disk image and run it. If you give a tape image, it
will plug the cassetterecorder and start to load the
content (needs some clever file type detection, but the
fMSX for Symbian OS seems to have it too), if you give
the files mygame.ldr and mygame.bin, it should run the
ldr file, etc.
Would be very useful and save users from creating disk
images all the time (OK, they can also use DirAsDSK to
prevent that... but still: autorun would be very valuable.)
Logged In: YES
user_id=358343
It's probably useful to have a link to the MRC discussion in which this
feature was mentioned: http://www.msx.org/forumtopic961p315.html
What fMSX/S60 does not seem to be exactly the same as what you
describe. fMSX/S60 looks inside a disk image and presents a menu of
files that can be started. What you propose is to do autodetection on
files on the host OS (and feed them to openMSX using dir-as-disk?).
I think autorun would be a nice feature for the user. We already have a
limited form of autorun: the auto detection of passed files by their
extension (.rom, .dsk etc). However, my impression is that advanced
autorun would belong in an external launcher program (like Catapult)
instead of in the openMSX core.
The trick used in fMSX/S60 works because it has complete control over
the MSX configuration that is booted. Things become a lot more
complex if you want to start a program on an arbitrary MSX
configuration. For example, if you have a harddisk, the floppy drive
may not be A:. The MSX may not boot in BASIC at all, but in firmware
or in DOS. Some configurations don't even have BASIC (for example
the C-BIOS machines).
Another problem is that the implementation of this feature needs a
hook into the emulated MSX, to know when to feed the load command.
For example, fMSX/S60 takes over the PINLIN BIOS routine. Although
this is unlikely to cause problems in everyday use, it does mean the
emulated machine behaves differently from a real MSX. I don't like the
idea of a core feature that decreases emulation accuracy. And I think it
could be implemented outside of the core, for example by a launcher
setting a breakpoint via the control connection.