In the future, an option in menu may be added.

@joysfera what is (was :)) the policy for adding command line parameters? Does every parameter have to an UI counterpart or it is OK to introduce standalone command line switches?

However, I have commited this change. If I have to make this one commit, write me please. The second option is to squash two commits, but I do not have Github Desktop.

Don't worry, push as many commits as you like. I'll squash it by merging.

ok, thanks, it makes things much simplier :) The PR is ready :)

Well next PR is waiting (cleanup rather)...

@mikrosk it's indeed better when a new feature comes with UI setting as well. But in this case we might want to test this from command line before bothering with UI refactoring, to find out how useful it is.

BTW, the menu is hard to develop. That stopped me to do the menu entry for this option; I was afraid I'd miss something.
And I needed it asap, so that was a good start to check if this is valuable and usable for people (I think: yes, it is)
I'll think about changing the menu structure to more struct-driven than code-driven. Once I have done this for microcontrollers and LCD.

About settings H: rename I propose such solution:
The line:
"H: device (hard disk)"
change to:
"Hard disk device (:)" , eventually ": device (hard disk)"

Lines H1:...H4: rename so dynamically

and everywhere H: is mentioned , renamed letter should appear.

In advanced options add line:
Use hard disk device as '<letter'.

When pressed, add requester with a letter to enter from keyboard (or a mesh with all A-Z letters?)

What do you think?

@jhusak I think entering the letter is sufficient, I guess everyone knows the alphabet. ;-)

The H: options could use some cleanup. I'd put everything into "Hard disk options". Then you could have:

• Hard disk device: H (changed after clicking)
• Device state: disabled / ro / rw
• Atari executables path
• x1 ... x4 clickable paths (no idea why these are duplicated in the advanced options and not even clickable)
• is that "currently open files" good for something?

It is rather not to enter !@#$%& as device "letters".

Hi!

I created a pull request with a proposed new menu arrangement.

@jhusak I think entering the letter is sufficient, I guess everyone knows the alphabet. ;-)

Instead, I implemented that each click advances the current letter, avoiding "C", "E", "K" and "S". It
is simpler to implement and fast for the user.

The H: options could use some cleanup. I'd put everything into "Hard disk options". Then you could have:

I also renamed "hard disk" to "host device". IMHO, this makes sense, as nobody actually uses hard-disks
as "H:" in real Atari, and the functionality actually exports "host" files to the emulator.

• Hard disk device: H (changed after clicking)
• Device state: disabled / ro / rw

I put the enable/disable first, because the other options "depend" on it.

• Atari executables path
• x1 ... x4 clickable paths (no idea why these are duplicated in the advanced options and not even clickable)

Those are the current working directory in each of the emulated devices.

• is that "currently open files" good for something?

I renamed the menu to "status", as those are actually the status of the H devices.

Have Fun!