Please help testing upcoming openMSX release!

Page 18/61
11 | 12 | 13 | 14 | 15 | 16 | 17 | | 19 | 20 | 21 | 22 | 23

By Manuel

Ascended (18073)

Manuel's picture

13-05-2020, 14:43

friguron wrote:

I just feel many MSX users think openmsx is too technical for their taste. Starting to yield messages which are informative and human at the same time (and which explain you the exact picture describing an issue) is something that probably widens "our" audience in a nice way. At least I welcome this kind of messages and I try to create them when I write my programs.

Believe it or not, we also try to create clear, informative, short (error) messages.

By donluca

Expert (75)

donluca's picture

13-05-2020, 15:32

Honestly, openMSX has been a fantastic piece of software for me so far.
Like MAME, openMSX needs a bit of learning at the beginning in order to get it up and running (although including the C-Bios is a great way to have a machine ready to go from the start). I'm afraid we've been spoiled by lots of recent emulators which are very, very user friendly, but then they aim at simpler devices (such gaming consoles with no internal ROMs/BIOS).

For me, whenever something went south, openMSX always gave me the needed information.
When I started and I wanted to run my own MSX Machine I didn't know what was needed, but just trying to run the machine I wanted printed errors that some files were missing.
A quick google solved that problem and in less than 10 minute I was up and running.
The possibility of using a folder as a disk has been a true godsend for quick testing.
The internal console is godlike.
The debugger is godlike as well.

One thing I wanted and couldn't find how to achieve was to keep the various LEDs (CAPS, KANA, FDD, etc.) always visible. I read the documentation over and over but couldn't find how to do it.

And I think I've found a couple bugs, but need to get the latest version from the repository to make sure they haven't been fixed already.

By Manuel

Ascended (18073)

Manuel's picture

13-05-2020, 20:01

For the LEDs try the load_icons command. The new set3 is permanent.
Thanks for the compliments! Would like to hear about the bugs!

By ren

Paragon (1855)

ren's picture

13-05-2020, 22:54

(Replying to #comment-380184)

# LEDs
Yes, implementing accurate LED availability & display would totally fit openMSX's philosophy.
OTOH the Pana turbo (wasn't there another not Pana brand/model with turbo as well?) AFAIK it would be fine to have a 'virtual' LED for that as well, thus relaxing the <> real world strictness there. This could perhaps go under a toggle, so people have to manually enable it (and emphasizing it's non-standard that way as well.)

Yes, and then there's the extension LED issue as well, would be totally cool if that's gonna see an implementation someday :)


# z80_freq
Hmm.. in the Console Command Reference 5.369318 MHz *is* mentioned.

(I also wondered about emulation of 7 Mhz turbo kits. Would that basically be the same thing as setting z80_freq to 7159090 (as per example in the reference)?)

Now, when I'm at 5.37 Mhz (testing w/ FRS's Gradius 2 enhanced), unlock the z80 freq via z80_freq_locked, the freq actually jumps to 3579545, the current z80_freq value. I think it's kinda unexpected behavior, perhaps, if this is actually how the functionality should behave, tweak the documentation a bit here to make things more clear?


# info display at start up
Yes, brief fading out if the info_panel would be cool I think (like the rom_info after drag-drop).

I wasn't really familiar with the different icon sets, thanks for the pointer.
Btw, would it be an idea to display the current set in use when to command is called without argument?


# led_
Ah drat, it's a setting (set).. :) I think I got thrown off there as there was no usage example to go w/ the command (and I looked it up swiftly) :)


# Drag-drop
Yeah, hope you also think displaying the filename at top is a good idea as well ;-)

When drag-dropping a ROM from explorer when the openMSX window has no focus I have to double click btw (first click so the openMSX window has focus (again)). Can this be remedied? (I can e.g. drag from (thus interact with) an explorer window that doesn't have focus.)

Do you mean confirm mapper type for recognized media as well? I don't think that's necessary. If there's (some mysterious) need you can change that afterwards in the console, though I believe you have to issue a complete cart command then?
If you mean confirm for unrecognized media, nah that's not necessary I think, but I think an out-fading confirmation of what you've selected would be sweet :)

I also think you can make the dialog a bit more wide (when there are files w/ long names inserted).

Yes, expanding rom_info a bit would be nice. For both recognized as unrecognized ROMs I would add the filename & mapper type.

I also think the font-size, for both rom_info & the drop dialog is a bit on the large side when you're at >= 3x. This isn't configurable (ATM) is it?

Wouldn't it be a possibility to adapt to the space available? When you're at scale_factor >= 3x there's ample room. I think you should let go of 'should fit at 2x', simply make use the extra space available at > 2x(!)

Another option I was thinking about: display summary info in the OSD, refer the the console for more details when applicable. It could also be an option to print out (complete) machine configuration info when starting a machine in the console. Would be kinda sweet and not to hard to implement? :) Just need to press F10 to have a quick check/look.


# Crispiness console & LEDs
The LEDs scale with the scale_factor. They're nice & crisp at 2x, but become kinda ugly when going beyond that. I would be happy if it keeps that 2x scaling (like the console or the info panel). Perhaps LED (or I guess more generic: OSD) scaling behavior could be a setting/preference as well?

The console keeps the same scaling/crispiness throughout, though the console text does seem to be a bit less crisp (i.e. text is somewhat more blurry) when compared to 0.15.

By Manuel

Ascended (18073)

Manuel's picture

14-05-2020, 00:19

ren wrote:

# LEDs
Yes, implementing accurate LED availability & display would totally fit openMSX's philosophy.
OTOH the Pana turbo (wasn't there another not Pana brand/model with turbo as well?) AFAIK it would be fine to have a 'virtual' LED for that as well, thus relaxing the <> real world strictness there. This could perhaps go under a toggle, so people have to manually enable it (and emphasizing it's non-standard that way as well.)

I think a display of the actual CPU frequency would be more useful. But do realize that this is quite non-mainstream... But see below.

Quote:

Yes, and then there's the extension LED issue as well, would be totally cool if that's gonna see a implementation someday Smile

Yeah. But as the discussion shows there's quite some questions to answer on the details.

Quote:

Hmm.. in the Console Command Reference 5.369318 MHz *is* mentioned.

Yes, but what is your point?

Quote:

(I also wondered about emulation of 7 Mhz turbo kits. Would that basically be the same thing as setting z80_freq to 7159090 (as per example in the reference)?)

It's not entirely the same. Many 7MHz kits have switch-back circuitry when certain I/O ports are addressed. And usually the sound pitch is affected by them. But this is not implemented in openMSX, i.e. in openMSX each device has its own clock (perfectly in sync with the others).

Quote:

Now, when I'm at 5.37 Mhz (testing w/ FRS's Gradius 2 enhanced), unlock the z80 freq via z80_freq_locked, the freq actually jumps to 3579545, the current z80_freq value. I think it's kinda unexpected behavior, perhaps, if this is actually how the functionality should behave, tweak the documentation a bit here to make things more clear?

It's simple: when the frequency is LOCKED, it means the MSX controls it. When it's NOT LOCKED, the setting controls it. Clarified it a bit in the manual.

Quote:

# info display at start up
Yes, brief fading out if the info_panel would be cool I think (like the rom_info after drag-drop).

I did some experiments with this, but currently it's quite interfering with the (default) LED stuff. So it needs some changes there to make this work.

Quote:

I wasn't really familiar with the different icon sets, thanks for the pointer.
Btw, would it be an idea to display the current set in use when to command is called without argument?

Good idea, done.

Quote:

# Drag-drop
Yeah, hope you also think displaying the filename at top is a good idea as well ;-)

Where? In the ROM-info? Do you really think it's useful, even if the title is already being shown?

Quote:

When drag-dropping a ROM from explorer when the openMSX window has no focus I have to double click btw (first click so the openMSX window has focus (again)). Can this be remedied? (I can e.g. drag from (thus interact with) an explorer window that doesn't have focus.)

I don't know why this is, but I don't think it can be remedied. We just use the API from SDL2 and it doesn't say anything about this.

Quote:

Do you mean confirm mapper type for recognized media as well? I don't think that's necessary. If there's (some

No, I meant for all types of files you can drop.

Quote:

mysterious) need you can change that afterwards in the console, though I believe you have to issue a complete cart command then?
If you mean confirm for unrecognized media, nah that's not necessary I think, but I think an out-fading confirmation of what you've selected would be sweet :)

Isn't that in the ROM info displayed now? Well, at least the mapper type is now.

Quote:

I also think you can make the dialog a bit more wide (when there are files w/ long names inserted).

Which dialog you mean exactly?

Quote:

Yes, expanding rom_info a bit would be nice. For both recognized as unrecognized ROMs add the filename & mapper type.

I also think the font-size, for both rom_info & the drop dialog is a bit on the large size when you're at >= 3x. This isn't configurable (ATM) is it?

You can just hack the scripts to change it if you really like. Why don't you try it and propose new values?

Quote:

Wouldn't it be a possibility to adept to the space available? When you're at scale_factor >= 3x there's ample room. I think you should let go of 'should fit at 2x', simply make use the extra space available at > 2x(!)

What exactly are you talking about now? The info_panel?
It's a bit tricky to make it adjusting for the scale. Especially if we will move to more flexible scaling later. The trickiest part is the texts. It's hard to let these scale along without running in to clipped texts either on the side or at the bottom.

Quote:

Another option I was thinking about: display summary info in the OSD, refer the the console for more details when applicable. It could also be an option to print out (complete) machine configuration info when starting a machine in the console. Would be kinda sweet and not to hard to implement? :) Just need to press F10 to have a quick check/look.

That's possible. I wonder who is actually interested in these things though. Any thoughts, other people?
It's quite invasive to just add that.

Quote:

# Crispiness console & LEDs
The LEDs scale with the scale_factor. They're nice & crisp at 2x, become kinda ugly when going beyond that. I would be happy if it keeps that 2x scaling (like the console). Perhaps the LED scaling could be a setting/preference as well?

It's actually part of the icon-set definition. That definition is actually a Tcl script with such settings. For instance, the handheld LED icon set is like this:

set scale 1
set xwidth 16
set yheight 16
set xspacing 20
set yspacing 16
if {$position == "default"} { set position "bottom" }

The icons are mere bitmaps, so they scale up badly, of course.

Quote:

The console keeps the same scaling/crispiness throughout, though the console text does seem to be a bit less crisp (i.e. text is somewhat more blurry) when compared to 0.15.

That's strange, the console text is all anti-aliased font rendering. Can you make 2 comparable screenshots to see what you mean?

By donluca

Expert (75)

donluca's picture

14-05-2020, 01:02

Manuel wrote:

For the LEDs try the load_icons command. The new set3 is permanent.
Thanks for the compliments! Would like to hear about the bugs!

I'll have to compile the new version first, then I'll send you a mail since it would require me to send you a modified ROM.

By donluca

Expert (75)

donluca's picture

14-05-2020, 17:07

Bug!

It happens only on the latest dev build, not the public 0.15.

macOS High Sierra 10.13, bluetooth Apple Magic Keyboard and trackpad.

Pressing the CAPS LOCK button on my Apple keyboard makes the CAPS led in openMSX blinking continuously on and off instead of having it to stick to on.

This translates to extra characters when using certain combinations. Example: with CAPS on, doing " on italian keyboard (Shift + 2) makes "> instead of only ".

The other bugs I found on the 0.15 are gone in the latest dev build.

EDIT: the icon set 3 is great! I'd just like to be them a bit more spaced from one other, they are a bit cluttered horizontally, otherwise perfect.

By ren

Paragon (1855)

ren's picture

14-05-2020, 20:28

Quote:

Clarified it a bit in the manual.

Hmm, not making things more clear for me. I was thinking more along the lines of:

These two settings control the Z80 clock frequency. When z80_freq_locked is true the emulated Z80 runs at the normal 3.579545 MHz (or possibly 5.369318 MHz on machines that are able to switch the CPU to 'turbo' mode, e.g. the Panasonic MSX2+ models). When z80_freq_locked is false the value of z80_freq is taken as the Z80 clock frequency. Note: the value of z80_freq is by default the MSX Z80 standard of 3579545, so when z80_freq is untouched, setting z80_freq_locked to false will set the clock frequency of a CPU in 5.37 Mhz turbo mode back to 3.58 Mhz.

Not sure if 7 Mhz should be mentioned as well, would make the story a bit more complete, but openMSX doesn't emulate it (ATM).

Quote:

Where? In the ROM-info? Do you really think it's useful, even if the title is already being shown?

When dropping a ROM file, the dialog only asks in which slot to put it, it doesn't tell me which file I just dropped. Just an extra visual cue to verifiy you actually dropped the right file.

Btw: thanks for adding file & mapper for unrecognized ROMs. One thing: with long file paths text will clip. I was thinking it would be sufficient / clear enough to display only the filename (without path info) though.

When using a full path I would make sure the filename is visible, e.g. when needed by clipping text in the middle and displaying an ellipsis there.

Quote:

Which dialog you mean exactly?

The drop dialog.

Quote:

You can just hack the scripts to change it if you really like. Why don't you try it and propose new values?

Sure, will have a look (sooner or later) (don't wait for it Wink)

Quote:

What exactly are you talking about now? The info_panel?

Hehe, yes things got a bit messy / intermingled, sorry for that Smile
The info_panel indeed, but the drop dialog as well (with long file names quite a bit is clipped)
Any reason the dialog is not dead center (horizontally) btw?

Quote:

Especially if we will move to more flexible scaling later/

Oh, any plans for that? I was thinking free-scaling (e.g. by means of a window that's resizable) would be sweet, is that what you're referring to? (Seems to work pretty well in WebMSX btw Smile)

The texts themselves don't have to scale do they (like they don't do now) (edit: well, the OSD stuff does), or are you planning otherwise?

I think it would be kinda sweet to have the info_panel use 100% width all the time (although, at 4x you would have quite some margin then when there's not much to display.. (e.g. 80% width centered could then be used?))

Quote:

That's strange, the console text is all anti-aliased font rendering.

I will provide screenshots later (if still necessary). The anti-aliasing is different. Where in 0.15 it was modest, and just filling some corners so to say (and basically nothing 'extra' is added along the vertical sides of characters), now I see, when zooming in on the screenshot, there's a lot more going on vertically. E.g. there's AA now on both sides of the 'U' (where there's nothing in 0.15), and e.g. to the right of T's stem (where in 0.15 that character is clean, no AA at all there).

Of course, behavior might be different between platforms here. No change noticeable in Ubuntu (if that's what you're using)? Mac users? (It's enough to be kinda annoyed about Wink)

Thanks for the other stuff!

By Manuel

Ascended (18073)

Manuel's picture

14-05-2020, 21:30

donluca wrote:

Bug!

It happens only on the latest dev build, not the public 0.15.

macOS High Sierra 10.13, bluetooth Apple Magic Keyboard and trackpad.

Pressing the CAPS LOCK button on my Apple keyboard makes the CAPS led in openMSX blinking continuously on and off instead of having it to stick to on.

Well, it works for me. Can you start openMSX from a terminal, then open the console and enter this command:
set kbd_trace_key_presses on
then close the console and press CAPS once. Then paste the text in the terminal here.

This is the output I get:

Key released, keyCode: 0x400123, keyName: F10,RELEASE
Key pressed, unicode: 0x0000, keyCode: 0x0012d, keyName: CAPSLOCK
Changing CAPS lock state according to SDL request
Key released, keyCode: 0x40012d, keyName: CAPSLOCK,RELEASE
Changing CAPS lock state according to SDL request
Quote:

EDIT: the icon set 3 is great! I'd just like to be them a bit more spaced from one other, they are a bit cluttered horizontally, otherwise perfect.

You can tweak it yourself. Check the share/skins/set3/skin.tcl file... or copy the folder and make your own skin Smile

By Manuel

Ascended (18073)

Manuel's picture

14-05-2020, 21:41

ren wrote:
Quote:

Clarified it a bit in the manual.

Hmm, not making things more clear for me. I was thinking more along the lines of:

Thanks, I'll use your text.

Quote:
Quote:

Where? In the ROM-info? Do you really think it's useful, even if the title is already being shown?

When dropping a ROM file, the dialog only asks in which slot to put it, it doesn't tell me which file I just dropped. Just an extra visual cue to verifiy you actually dropped the right file.

Well, you only get that drop dialog if it's ambiguous what should happen. So if there is only one cartridge slot, or one diskdrive, it doesn't show. As I said in the first reply, most of the devs already found it a bit overkill to have a dialog at all. So I'd rather not introduce such a dialog in all cases and for all file types that are dropped.

Quote:

Btw: thanks for adding file & mapper for unrecognized ROMs. One thing: with long file paths text will clip. I was thinking it would be sufficient / clear enough to display only the filename (without path info) though.

When using a full path I would make sure the filename is visible, e.g. when needed by clipping text in the middle and displaying an ellipsis there.

Too bad that's not very easy to implement with the current OSD primitives. I can easily strip off the path though, if you think that's better.

Quote:

Any reason the dialog is not dead center (horizontally) btw?

It's cheaply using the exact same dialog you get when you use the OSD menu to insert a cartridge in any slot (you get that when there are more than 2 cartridge slots. It's also new Smile)

Quote:

Especially if we will move to more flexible scaling later/

Oh, any plans for that? I was thinking free-scaling (e.g. by means of a window that's resizable) would be sweet, is that what you're referring to? (Seems to work pretty well in WebMSX btw Smile)

Plans existed for years and some steps have been taken. But that's all for now. It'll be done some day, I guess.

Quote:

The texts themselves don't have to scale do they (like they don't do now) (edit: well, the OSD stuff does), or are you planning otherwise?

I think it would be kinda sweet to have the info_panel use 100% width all the time (although, at 4x you would have quite some margin then when there's not much to display.. (e.g. 80% width centered could then be used?))

Yeah, the OSD menu does scale. I should rewrite that info panel some day so that it also scales. At first I didn't do that, because at 4x for instance, it takes only a little bit of space in the border. But if it would also scale along, it always takes the same relative space of your MSX screen. I'd rather have it in a not so overlapping place.

I also had an idea to make the info panel expandable (with some button on it?) to show more detailed information, like the used CPU/frequency and whatever people come up with (ideas?).

Page 18/61
11 | 12 | 13 | 14 | 15 | 16 | 17 | | 19 | 20 | 21 | 22 | 23