Please help testing upcoming openMSX release!

Page 23/57
16 | 17 | 18 | 19 | 20 | 21 | 22 | | 24 | 25 | 26 | 27 | 28

By Louthrax

Prophet (2405)

Louthrax's picture

17-05-2020, 13:38

Thanks Manuel, I'll check that and also clean the .filecache file. What puzzles me is that the ROMs checks were random (not always the same ROMs). I'll let you know of my results.

Grauw, I'm using AVG antivirus. Have you seen a relation with that ?

By Louthrax

Prophet (2405)

Louthrax's picture

17-05-2020, 13:53

Grauw wrote:

Do you use an antivirus program?

Ah, nice catch! Indeed, disabling the antivirus program solves the problem Smile Have you found any workaround for that (disabling some directories or programs in the antivirus) ?

EDIT: Looks like adding this exclusion in AVG:

C:\Projects\mdk\bin\openmsx\share\systemroms\*

works here.

But I do really not understand how an antivirus could change anything related to parsing ROM files ??

By Grauw

Ascended (9904)

Grauw's picture

17-05-2020, 14:03

It was just a hunch. Antivirus programs tend to access files right as the program accesses them, and not all of them do this in a nice way either which can cause issues. They break basic guarantees normally given by the file system and/or operating system.

E.g. I know that in the SVN and Mercurial version control programs they had to implement workarounds for Windows because sometimes files in their internal data store could not be deleted because antivirus software still had a handle on them (without the proper flags that would allow it), and the repository could get corrupted as a result.

In this case it looks like the AV perhaps touches the file modification times, triggering a rehash. Or maybe it blocks writing to .filecache while it scans it.

By Manuel

Ascended (17941)

Manuel's picture

17-05-2020, 14:02

Yes, the time stamp if the file is the first thing openMSX checks to see whether it might be modified. Perhaps that was the thing here then.

By Louthrax

Prophet (2405)

Louthrax's picture

17-05-2020, 14:05

Makes sense. Troubling if we can't completely rely 100% on basic things such as accessing files, but good to know Smile

By donluca

Expert (75)

donluca's picture

17-05-2020, 15:09

Grauw wrote:

For me that’s

Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Btw you can also get dev builds from GitHub, and these ones don’t have the caps-lock issue for me.

That's because you're on Catalina, while I'm on High Sierra, so there's a difference in the compiler version, it's to be expected.
I can try to inject the command line tools from Catalina on my 10.13 installation but that might end messing up my developing environment (something I'm not really looking forward to).

Thanks for the link to github with the on-demand builds, I'll try them later.

By Manuel

Ascended (17941)

Manuel's picture

17-05-2020, 15:45

ren wrote:

I don't have an env. set up to quickly test things, but perhaps, somwhat of a wild guess, the font hinting setting might have an effect?

Well, I checked, and the NORMAL hinting is what is the default and what it is actually set on. We never set it explicitly in openMSX, but when I do set it explicitly, we get the same result. When I set it explicitly to MONO hinting (which is only supposed to be used for monochrome bitmap output), I seem to get the same hinting as before. But that is theoretically the wrong setting, so I'm not very eager to change it. Note that with that setting, the TEXT80 does fit in the box in the info_panel!

When I run 0.15.0, which is on Linux dynamically linked against SDL_ttf and FreeType, I also get the 'blurry' behaviour. So, something has changed in one of these libraries.

Quote:

Well it's not like you're in the console all the time, so not a biggie. I do prefer the sharper rendering though.

Me too, but for now, perhaps we shouldn't touch it. If there is some bug in the external libs, they may fix it at some point and our fonts look like before (or they were never intended to look like they looked before).

Quote:
Quote:

But what is the point if in many cases you don't even get that whole dialog?

What's the point of anything? ;) I think taking care of (many) details improves the overall quality/experience, but I understand this isn't high prio ;)
So perhaps I'll have a look then at some point ;)

You can do that, but as I said, I am currently using the exact same dialog you also get when you select "Insert ROM (any slot)", which you get if your MSX has 3 slots (e.g. Sony HB-F500P). And in that use case, there is no file yet, so this will then have to be taken into account.

Quote:
Quote:

If we keep flexible scaling in mind [...]

I understand your reasoning, but I guess it isn't that hard to define some sane defaults for 2 to 4x. And when free-scaling comes to play it would be kinda like CSS media queries ;-)

It just means a lot of extra code with several cases for all the scale factors. Doable, but not nice :) And it will break as soon as the free-scaling is implemented.

Quote:
Quote:

How would you use tool tips for the info panel?

E.g. for stuff that doesn't fit in the individual panel boxes. E.g. long software titles / file names, or perhaps (when possibly extending it) abbreviate things and show full info on mouse over. Just an(other) idea.
E.g. ATM the boosted TR config name doesn't fit in it's box, nor the 'TEXT80' screen mode. VRAM & RAM boxes looks a bit cramped as well :)

Yes, possible. But it's not too easy, as the OSD doesn't have a usual GUI toolkit. It's not a matter of doing a setToolTip(text). The OSD is quite bare bones, so it would involve some manual coding.

Quote:
Quote:

The list will quickly become very long. Note that there is a variable number of slots and disk drives in a system.

Sure, therefore the suggestion to list only the default machine cartridge slots & disk drives. That would not exceed 2+2 right? A tooltip could be used here for extended info. As you brought up buttons yourself, a possibility: 'print to console' for stuff that doesn't fit and/or would be too much info to display (in a tooltip).

I think most (casual) users just run a ROM or disk and that's it. I do think it would be nice to display what's e.g. in drive A when there's a ROM running.

As I said, some machines have 0, 1 or 3 cartridge slots. Drives could be limited to a and b (if exist).
Looks like your main point is: show an overview of the status of the machine (what is in which slot/drive/etc.). I agree that overview is lacking a bit if you're not using a Catapult.

By sdsnatcher73

Paragon (1978)

sdsnatcher73's picture

17-05-2020, 15:47

Manuel wrote:

Louthrax: this happens if you have a sha1sum in your machine configuration that is not found in the /share/.filecache file. openMSX will then start looking for the file ("indexing") in the file pools that are configured. It reports progress on this indexing once per second or so, showing the current file it was indexing, and how many files it has indexed so far (the number between square brackets).

So, important in this case is the ROMs with sha1sum cc57c1dcd7249ea9f8e2547244592e7d97308ed0 (NMS 8245 EPROM dump) and sha1sum d97c9b4e936d999954ac89173d0d69bc7fc88d7b (unknown to me) . Apparently they were not in the filecache?

For the former case, the standard 8245 has this ROM as first of 4 alternatives. Perhaps you have one of the later mentioned alternatives installed. I think currently openMSX will first try to find the first one (including indexing) and then a later one. Perhaps we should change this behaviour.

To avoid this for now, install the full system ROM set Smile

Ah I’m seeing this as well (and I cleaned up my system ROMs folder so it e.g. boots the 8245 with the latest version). I think if any version is found in file cache (this should be the first check then) no new scan is performed. Also currently openMSX cannot match these versions between the different rom (main bios, subrom, diskrom). Maybe we should have versioning on the whole system and the CLI/UI allows choosing the machine version.

By Manuel

Ascended (17941)

Manuel's picture

17-05-2020, 15:49

donluca wrote:

Thanks for the link to github with the on-demand builds, I'll try them later.

That would be good to get more info about whether the CAPS lock issue depends on the build, the macOS version or some combination.

By Manuel

Ascended (17941)

Manuel's picture

17-05-2020, 15:52

sdsnatcher73 wrote:

Ah I’m seeing this as well (and I cleaned up my system ROMs folder so it e.g. boots the 8245 with the latest version). I think if any version is found in file cache (this should be the first check then) no new scan is performed. Also currently openMSX cannot match these versions between the different rom (main bios, subrom, diskrom). Maybe we should have versioning on the whole system and the CLI/UI allows choosing the machine version.

Can you show what you're seeing?
IF you have the latest 8245 ROM, which is mentioned first in the XML file, you shouldn't get the scan, as it will be able to find that one. I don't understand what/why you say here: "cannot match these versions between the different rom".

Page 23/57
16 | 17 | 18 | 19 | 20 | 21 | 22 | | 24 | 25 | 26 | 27 | 28