Transfer files from PC to OpenMSX

Resident (49)

28-05-2018, 23:50

Gents,

I swear I tried finding this. Google, etc. I cannot see how this is done. Ideally I would like to have a folder on the PC mapped inside OpenMSX as a drive, i.e. G:. Is this possible?
If not, what is the best way to transfer files back and forth? Idea is, I want to code on Notepad++ and then just transfer the .C file to the OpenMSX...

Thanks!

Entrar ou registrar-se para comentar

Por Manuel

Ascended (18695)

28-05-2018, 23:51

You can use the dir-as-disk feature as you described... Just specify a file folder instead of a disk image. Note: it's limited to 720kB.

Por Grauw

Ascended (10558)

29-05-2018, 00:01

You can simply plug in a folder as a disk drive like so:

openmsx -diska path_to_folder

This feature is called “dir as disk” and is described in the manual here. Note a ~720K size limit applies.

Alternatively the more advanced user can make a TCL script which uses the openMSX diskmanipulator to create a FAT12 HD image which can be max 32M in size, for use with the IDE or MegaFlashROM SCC+ SD interface emulations. I do this in most of my projects, compared to dir-as-disk it’s less easy to use, can be larger, does not write file modifications back to the PC directory, and access times are much faster since it emulates an HD instead of an FDD.

Por DarkSchneider

Paladin (942)

29-05-2018, 08:27

@Grauw the problem of that is you can't use a SVC system (mandatory nowadays IMO) as it would transfer the whole virtual HDD file as modified.

Por Grauw

Ascended (10558)

29-05-2018, 09:06

What problem? You need to elaborate 'cause I don't follow, it works fine for me and I use Mercurial for all my projects. Binaries should not be checked into source control... The disk image is created in the temp directory when I run the emulator for a project.

Por DarkSchneider

Paladin (942)

29-05-2018, 10:31

But can you transfer the files to the virtual HDD while running the emulator?. I think the file is locked by the program. At least on Windows I have to close the emulator before modifying an inserted DSK with diskmgr. So I suppose will be the same for HDD files. I think I tried and cannot.

When using a MSX compiler, you have to transfer the sources to HDD and then compile. That is an extra step on each compilation, you modify the sources on Notepad++, change to command prompt to execute the script, then change to the emulator to compile. If the virutal HDD cannot be changed in real time, too bad, I don't feel comfortable at all having to launch the emulator on each compilation. I prefer even to use virtual FDD.

Also when using the MSX compiler, you need to have all the structure on that disk, system, tools, compilers and libs. If you create the disk at that moment (on the tmp), you have to copy all the stuff each time.

Even more, the tools for transfering files to MSX HDDs at least on Windows is not very good. You have to open the HDD manually, setting it the format each time, and then drop the files inside (with the mouse).

I only see the option if "diskmanipulator import" could be used with the emulator on. But I see that in all examples they do "set power off". This could allow, with an extra step (running the TCL), to import the host folder source files to the HDD and then compile. Extra import, as you should import each time all the asm, C and H files, but OK they are small and on a SSD there should not be a problem.

Edit: OK, tested and it works. So I think is even better solution to use diskmanipulator import to bring files to the emulator HDD. I'll try it for a while and then decide if using it or virtual FDD. As need to balance if the extra F10 (open console) -> cursor up (only need to write the command 1st time) -> F10 (close console) and then compile is worth compared to use virtual FDD on the host.

Seems it would be something similar to:
diskmanipulator import hda1 [glob -d HOST_FOLDER *.h *.c *.mac]
But, ups, it doesn't overwrite existing files. It says "preserving changes".

Por Wolverine_nl

Paragon (1159)

29-05-2018, 11:58

you can open the first hdd .dsk file in an editor/dsk manager and then start OpenMSX with also another 2nd hdd .dsk as second drive.Then you can edit your files in the first one on PC (depending on the dsk manager, sometimes you need to copy the file into the dsk image), which is read-only in OpenMSX and compile it to the second hdd, which OpenMSX completely controls. Just an idea.
(mind, it only works if you open the dsk image before starting OpenMSX, then it becomes read-only for OpenMSX and write/read for PC))

Por Grauw

Ascended (10558)

29-05-2018, 12:27

DarkSchneider wrote:

But can you transfer the files to the virtual HDD while running the emulator? [...] I don't feel comfortable at all having to launch the emulator on each compilation. I prefer even to use virtual FDD.

Why don’t you feel comfortable? I don’t keep the emulator running, I boot up the emulator with a hotkey combination in my editor (which invokes "make run") when I want to test, it generates the HDD image from the contents of the "bin" directory and disables throttling for the first n seconds to speed through the boot & loading, and the image has an autoexec.bat which runs the program (or in the case of MSX-C, compiles first). So I can iterate quickly with zero typing in either the MacOS console, the openMSX console, or MSX-DOS.

The creation of the disk image with diskmanipulator is really quick, even with a 32M image full of files (as I frequently do with VGMPlay), so speed is not a concern.

DarkSchneider wrote:

This is also all automated for me, it simply packages the contents of the "bin" directory into a disk image when the emulator boots using the built-in openMSX diskmanipulator functionality, whatever’s in there (command.com, etc.) will be available to me in the emulator. Much better than having several typing and mousing steps.

Check out the Makefile and openmsx.tcl scripts in the VGMPlay repository. It’s all pretty simple and works really well for me, I can iterate very quickly with full automation and no hassle.

Por DarkSchneider

Paladin (942)

29-05-2018, 15:16

@Wolverine_nl I think that is an interesting idea. Very interesting indeed, A drive the MSX one, and B drive a locked by the host OS one. You know about some disk manager that link the files, instead having to copy them each time? That would be required.

@Grauw the problem is about rebooting on each compilation. Modifying many files, misstypings (compilation errors), and etc.etc. at the end of the day you see the damn MSX logo about thousand times.
Let's compare:

- Using virtual drive (currently FDD): edit on Notepad++, press Ctrl+S to save, alt-tab to change to openMSX, cursor up (to rewrite the last command, compile), return and F9. If the binary loads content, press F9 for faster or use http://openmsx.org/manual/commands.html#fullspeedwhenloading and that's all.

- Using HDD and scripts: we create a TCL that set power off (required to overwrite and safer), import files, set power on and enable throttle (for faster boot). Then modify files on Notepad++, ctrl+S to save, alt-tab to change to openMSX, F10 (console), cursor up (repeat last command, that is execute the TCL), it reboots, F10 to hide console, and then compile (pressing F9 for faster). To this, add you have to modify the TCL depending on what you want to bring (only sources, also assets). Rebooting for each compilation (not execution, but too) really kills me.

Balancing currently I prefer the virtual FDD, the disk speed can be solved pressing F9. The main problem is the lack of capacity, but ok we manage dividing. The HDD would be mandatory for testing the final product, as the FDD has not enough space.

Por santiontanon

Paragon (1633)

29-05-2018, 17:10

I also launch the emulator at each compilation. But I have no idea how to use disks with an MSX anyway (never owned an MSX2), and all the work I do is using ROMs. So, I might have a different use case

Por Grauw

Ascended (10558)

29-05-2018, 17:29

DarkSchneider wrote:

@Grauw the problem is about rebooting on each compilation. Modifying many files, misstypings (compilation errors), and etc.etc. at the end of the day you see the damn MSX logo about thousand times.

Although I do cross-compile, I feel like my iteration time is very low. I can’t bear long iteration times either. Maybe give it a try, it really boots up quick unthrottled.

DarkSchneider wrote:

Using HDD and scripts: we create a TCL that set power off (required to overwrite and safer), import files, set power on and enable throttle (for faster boot). Then modify files on Notepad++, ctrl+S to save, alt-tab to change to openMSX, F10 (console), cursor up (repeat last command, that is execute the TCL), it reboots, F10 to hide console, and then compile (pressing F9 for faster). To this, add you have to modify the TCL depending on what you want to bring (only sources, also assets). Rebooting for each compilation (not execution, but too) really kills me.

All of these manual steps are not necessary, you can script all of this with a start-up tcl script and an autoexec.bat. This is how it is for me, using HDD and scripts: edit source files, press ALT-~ hotkey.