ScummVM/Falcon060 pre-release

Latest news in the Atari world

Moderators: Mug UK, Silver Surfer, Moderator Team

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Sun Feb 11, 2024 12:49 pm Eero, how far is this in the game? :D I played about 20 minutes, couldn't find this location.
It's something like this:
- get bar from railing
- use bar on door & exit to balcony
- come back once guard misses you
- go down/left to elevator room
- put circuit board to junk shell (=> Joye)
- ask Joye to fix lift drone
- when drone brings barrel to elevator
- drop to elevator hole => furnace room
- ask Joye to open door (=> "Reich" security guy gets killed)
- exit => goes up the stairs (to outside the factory)
- go left and see guard (outside the factory)
- exit and come back later, so guard is gone [1]
- go left to control room

[1]: I'm assuming the other steps in between that I did would not be needed. I did not test that though.
mikro wrote: Sun Feb 11, 2024 12:49 pm Can you maybe provide a save state?
Attached. Save state is named as "control". I could not reproduce the bug with it though i.e. exit being clickable while interacting with the old man.

(I did that by triggering interaction with the man by accident when trying to exit the room, don't remember exactly how it happened...)
You do not have the required permissions to view the files attached to this post.
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Oh man, then I perhaps pass on this one. Sounds like a game bug anyway. If you manage to get a stable repro, I'll take a look. I'm much more interested in that "not starting Hatari bug" mentioned above.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Fri Feb 09, 2024 8:19 pm - unpack the full version above
- copy the dig demo as dig-demo to the same folder
- run hatari as hatari -c hatari-64.cfg ./scummvm.ttp ((attached, TOS 4.04 required)
- add the game
- quit the launcher
- quit hatari
- run hatari as hatari -c hatari-64.cfg ./scummvm.ttp

Game doesn't start. Now erase scummvm.ini, start anew and try:

- either quit the launcher, double-click on scummvm.ttp in the desktop and run the game

- or don't quit the launcher and just start the game

Game starts. WTF?! I couldn't reproduce this with EmuTOS 1.2.1, I have no clue what this means. I quickly glanced at the profiler where it's stuck but I couldn't see anything obvious (somewhere in TOS area...).
I could reproduce this when "digdemo" is in same dir with ScummVM (but not when it's in "scummvm/digdemo" subdir with the other games).

What's more interesting, is that I could not reproduce the problem when I invoked debugger before invoking the game => indicates issue being with the ScummVM keyboard handling.

And indeed, if I press Space key before starting the game with Enter, the game starts fine. Odd thing about that is needing to click the ScummVM game list before Enter goes through (after pressing Space).

Another way of getting rid of the issue, is enabling the CPU cache / cycle-exact mode emulation (with "--cpu-exact on").

(Enabling CPU prefetching with "--compatible on" was not enough, although I was initially suspecting that as the culprit. There's a good reason why that option is named "--compatible" for 68000 emulation, but maybe it's not so significant for 020+.)

Maybe there's some race condition with the ScummVM keyboard handling (and e.g. what TOS does) that happens only when one disables CPU cache, i.e. makes some things running under emulation much slower per emulated 030 clock-cycle?

PS. Looking at your other config options... Rather than using symbolic key mapping, I would suggest scancode one, and setting suitable keyboard value in NVRAM (e.g. with Hatari "--layout <lang>" option) for TOS. Borders could be disabled also ("--borders off"), as they're pretty useless for Falcon emulation.
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Oh f**k. So we have no clues as of where it gets stuck and why? (It would help to know if it's checking some hardware bit or something). I have learned to live with the fact that Hatari's keyboard is not perfect (no key repeat in FF, no double click, an occasional underun etc) but hanging, that's not cool.

As for the cfg, you know how it is, developer's setup is always the messiest one.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Tue Feb 13, 2024 8:08 am Oh f**k. So we have no clues as of where it gets stuck and why? (It would help to know if it's checking some hardware bit or something)
Things are broken already before starting a game. I think game start freezing is just a late side-effect of some issue in ScummVM KBD initialization / handling.

Doing any other interaction than pressing Enter to start the game when ScummVM comes up, causes issue to be non-reproducible. E.g. just clicking to game list (or using mouse scroll wheel) before pressing Enter.

Pressing any other key than Enter (e.g. up or down arrow) means that Enter does not any more start the game, I first need to click to the game list before Enter works again.

However, no such thing happens when either "CE" (cycle exact) emulation is enabled, or EmuTOS is used. Enter starts the game regardless of whether I press other keys before it. Only in non-CE mode with TOS4, I need to first click to game list to get that (correct) behavior.

=> Seems that with TOS4 under non-CE mode, ScummVM input handler needs to process some mouse event before its key event handling works properly. And if that is not done before starting a game, game can freeze...

Maybe ScummVM kbd initialization code has race condition with something TOS4 does, that gets triggered by some things executing slower (per 030 clock) without caches in non-CE mode?
mikro wrote: Tue Feb 13, 2024 8:08 am I have learned to live with the fact that Hatari's keyboard is not perfect (no key repeat in FF, no double click, an occasional underun etc) but hanging, that's not cool.
Key repeat & double click not working under fast-forward are ScummVM specific problems. Repeat works fine in TOS (try e.g. file info dialog), as does Hatari's double click emulation (with middle button).
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Eero, I guess I will need some help with the debugger here. I've tried to follow https://hatari.tuxfamily.org/doc/debugg ... reakpoints (trace.ini contains "symbols scummvm.sym" and "trace cpu_symbols") and it nearly works: it prints all the symbols but ... the symbols are totally wrong. I mean I'm starting scummvm.ttp and I see:

Code: Select all

> symbols scummvm.sym
Reading 'nm' style ASCII symbols from 'scummvm.sym'...
Removed 617 symbols in same addresses as other symbols.
Skipping detailed duplicate symbols reporting when autoload is enabled.
Loaded 94477 symbols (77615 for code) from 'scummvm.sym'.
> trace cpu_symbols
Removed CPU breakpoint 1:
        pc = TEXT :once :trace :file trace.ini
Sword2::PSXScreensEntry::read(unsigned char const*)
2 repeats of: Sword2::PSXScreensEntry::read(unsigned char const*)
Sci::SoundChannel_PC9801_FM4OP::programChange(unsigned char)
Sword2::PSXScreensEntry::read(unsigned char const*)
2 repeats of: Sword2::PSXScreensEntry::read(unsigned char const*)
Sci::SoundChannel_PC9801_FM4OP::programChange(unsigned char)
Obviously this can't be right. This is from the last full version published in this thread. So am I doing something wrong?
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Wed Feb 21, 2024 9:08 pm Eero, I guess I will need some help with the debugger here. I've tried to follow https://hatari.tuxfamily.org/doc/debugg ... reakpoints (trace.ini contains "symbols scummvm.sym" and "trace cpu_symbols") and it nearly works: it prints all the symbols but ... the symbols are totally wrong. I mean I'm starting scummvm.ttp and I see:

Code: Select all

> symbols scummvm.sym
...
Obviously this can't be right. This is from the last full version published in this thread. So am I doing something wrong?
Yes, because (ScummVM) program symbol addresses are relative.

Code: Select all

> h symbols
'symbols' - load CPU symbols & their addresses
Usage:  symbols <code|data|name> [find] -- list symbols containing 'find'
	symbols <prg|free> -- load/free symbols
	        <filename> [<T offset> [<D offset> <B offset>]]
	symbols <autoload|match> -- toggle symbol options
...
When you're neither using addresses that are absolute (as is case e.g. with EmuTOS *.sym file, and some demos & resident programs), nor "symbols prg" command, you need to tell to the debugger what offsets it should use for the addresses:

Code: Select all

> symbols scummvm.sym TEXT
If you care about data and BSS symbols, you may need to give offsets for those too (as it's compiler dependent whether data and BSS addresses it generates are relative to their relative sections, or also to TEXT section).

PS. by using Hatari snapshot version, you would not need to do anything, as Hatari Git supports loading <programname>.sym file automatically if it exists, and that loading happens automatically whenever you drop to debugger (invoke breakpoint), when program is already running.

PPS. enable also profiling, so that you get backtrace whenever you drop to debugger (backtrace is only for part of code executed/profiled since previous debugger invocation).
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Eero Tamminen wrote: Thu Feb 22, 2024 8:02 am

Code: Select all

> symbols scummvm.sym TEXT
If you care about data and BSS symbols, you may need to give offsets for those too (as it's compiler dependent whether data and BSS addresses it generates are relative to their relative sections, or also to TEXT section).
Does this work multiple times? I.e. that I split the symbols into files for text, data and bss and then do something like:
symbols scummvm-text.sym TEXT
symbols scummvm-data.sym DATA
symbols scummvm-bss.sym BSS
PS. by using Hatari snapshot version, you would not need to do anything, as Hatari Git supports loading <programname>.sym file automatically if it exists, and that loading happens automatically whenever you drop to debugger (invoke breakpoint), when program is already running.

PPS. enable also profiling, so that you get backtrace whenever you drop to debugger (backtrace is only for part of code executed/profiled since previous debugger invocation).
Actually neither of this helps in my case, I can't jump into the debugger as the ScummVM infinite loop is not reproducible then. I'm still considering the scenario that this is actually a Hatari bug but I want to be sure.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Thu Feb 22, 2024 9:22 am Does this work multiple times? I.e. that I split the symbols into files for text, data and bss and then do something like:
symbols scummvm-text.sym TEXT
symbols scummvm-data.sym DATA
symbols scummvm-bss.sym BSS
New symbol list replaces the earlier one. Hatari "symbols" command neither has an option, nor support for merging new symbols lists to an existing one.

So far it hasn't been really needed. One can give the addresses with a single command, there's no advantage in splitting the files.

When post-processing profiling data, it's IMHO actually better to ask post-processor separately details for (absolute) ROM addresses and (relative) program addresses, and how they get called.

I think the main/only case for merged symbols lists would be interactive debugging of interactions between multiple programs and/or ROM.
mikro wrote: Thu Feb 22, 2024 9:22 am
PS. by using Hatari snapshot version, you would not need to do anything, as Hatari Git supports loading <programname>.sym file automatically if it exists, and that loading happens automatically whenever you drop to debugger (invoke breakpoint), when program is already running.

PPS. enable also profiling, so that you get backtrace whenever you drop to debugger (backtrace is only for part of code executed/profiled since previous debugger invocation).
Actually neither of this helps in my case, I can't jump into the debugger as the ScummVM infinite loop is not reproducible then.
To be exact, it's not the debugger invocation that makes it non-reproducible (pressing AltGr+Pause does not affect emulation), but mouse moving (before you press Enter) in the emulated Falcon when you refocus the emulator window.

But you can use automated (chained) breakpoints to invoke debugger without any Hatari window interaction (causing emulated mouse to move).
mikro wrote: Thu Feb 22, 2024 9:22 am I'm still considering the scenario that this is actually a Hatari bug but I want to be sure.
Can you disable CPU cache on real Falcon before running ScummVM, and if yes, does it then freeze like with Hatari?
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Eero Tamminen wrote: Tue Feb 13, 2024 11:30 pmThings are broken already before starting a game. I think game start freezing is just a late side-effect of some issue in ScummVM KBD initialization / handling.
Actually, there wasn't any freezing involved. Everything ticked inside, just keyboard wasn't responding.
Doing any other interaction than pressing Enter to start the game when ScummVM comes up, causes issue to be non-reproducible. E.g. just clicking to game list (or using mouse scroll wheel) before pressing Enter.
Yeah, a pretty weird error. It started to be visible after introducing the interrupt-driven audio mixer. However in the end, all it took was calling the mixer routine (!) without any prior Atari setup.

From what I could see, the problem was my handling mentioned in viewtopic.php?p=446400#p446400: Hatari, for reasons I can't explain, somehow created a situation where 'Return' was still accepted by the original handler (like... how? even if I waited 10 seconds in the launcher!), then emitting an IKBD error (again, how?) while already being in my handler and finally emitting a 'Return' released event. So what happened was that the original TOS handler expected 'Return' released and that lead to some weird scenario which I again can't explain -- 'Return' was stuck, sure, but how this affected The Dig's audio mixing... If this were on real hardware, I'd dig deeper but here it could be still Hatari's imperfection (esp. in combination with the FF mode) so I don't care that much.
Key repeat & double click not working under fast-forward are ScummVM specific problems. Repeat works fine in TOS (try e.g. file info dialog), as does Hatari's double click emulation (with middle button).
Key repeat doesn't work in FF at all (it's insanely fast), that's why it there is the option to disable it in the GUI, isn't there? And as for the double click, it is surely related to Falcon's emulation speed (it's quite hard to double-click also on real 16 MHz Falcon). FF makes a false impression of a faster machine but in fact it is internally as slow as before, therefore OSystem::update() gets called as (not) often as before and therefore double-click is not registered within the specified time limit.

https://mikro.naprvyraz.sk/private/scum ... i-lite.zip
https://mikro.naprvyraz.sk/private/scum ... i-full.zip

contain two changes:
  • IKBD overruns are not handled anymore. That means that the Hatari issue with The Dig doesn't happen anymore however I fear whether I haven't introduced a regression. Here: viewtopic.php?p=446378#p446378 I mention that even with kbdvec() version (vs. raw IKBD vector version) I still get keyboard overruns but I'm unable to replicate that now (IIRC all it took was to run Hatari + FF + do some heavy lifting in the launcher like opening the options dialog + move mouse at the same time).
  • Double-clicks work! Ok, nearly always work. ScummVM uses a 500ms interval for registering a double-click, current code usually meets that limit even on a real 16 MHz Falcon (I'm always shocked how slow everything is there!). Also Hatari's mouse wheel's double-click emulation works now.
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Eero Tamminen wrote: Mon Apr 10, 2023 10:00 pm Nippon Safes Inc

Perf of game play in first screen is bound by screen updates, but there's fair bit of busy waiting too (clock checks are called most often):

Code: Select all

Time spent in profile = 137.95457s.
...
Used cycles:
  24.38%                   539479237                       c2p1x1_8_start
  19.11%                   422994925                       c2p1x1_8_pix16
  16.72%  16.90%  16.90%   370102380 374081397 374081397   OSystem_Atari::getMillis(bool)
   9.03%                   199950298                       OSystem_Atari::delayMillis(unsigned int)
   8.24%                   182315067                       Parallaction::Gfx::bltMaskNoScale(Common::Rect const&, unsigned char*, Graphics::Surface*, unsigned short, unsigned char)
While investigating for some bigger tasks ahead I've accidentally bumped into this. Into what you ask? Into the delayMillis() calls. Until now I've lived in a nice world of assuming that if there's a delay needed, it has a good reason (like sending MIDI notes, slowly fading palette, breaks between game events etc). Imagine my surprise, when more often than not I was discovering code like this:

Code: Select all

        if ((g_engineFlags & kEnginePauseJobs) && (_input->_inputMode != Input::kInputModeInventory)) {
		return;
	}

	_gfx->animatePalette();
	_gfx->updateScreen();
	_system->delayMillis(30);
30 milliseconds, hm. For comparison, when playing at 60 FPS, that equals to 16.67 milliseconds. So no matter what you do, this game (Nippon Inc) is capped to ~33 FPS at most. But what happens if animePalette() and updateScreen() already already take at least 30 milliseconds? Well... our game's frame suddenly takes 30 + 30 = 60 milliseconds which translates to ~17 FPS. Just like that.

Some games do have an intelligent frame limiter in place but some don't.

Eero, if you have time, could you measure how big impact these two executables have in the profile output: https://mikro.naprvyraz.sk/private/nippon-test.zip. "No delay" version has the delayMillis() removed, "delay" has kept it in place. This applies only to Nippon, Inc.

Of course, one can't just simply remove the call because on a faster computer (CT60, Aranym, not to mention PCs) the game becomes too fast (i.e. walking, sprite animations etc). So the proper fix is to introduce a frame limiter like the "good" games do.

However this poses the other problem which I'm bumping into from time to time: to what extend to support ScummVM User Experience. If I chose just SCUMM (LucasArts games), that's clear, I have one engine to take care of, so if anything weird happens in a game, I can easily track it down to the engine source code. But with tens of games?

The ideal solution would be to go engine-by-engine and investigate all of their delayMillis() calls. And in most cases, the code is quite straight-forward. However:

- sometimes it is not
- sometimes I can't test the game/impact because it's hires and/or more than 640x480 engine
- it's like 200 engines and 600 delayMillis() calls to investigate
- PC users don't really care, so nobody will appreciate it except our atari backend
- it's a boring as f**k job

Most likely I'll bite the bullet and create an official pull request but the amount of wasted time on this will be disheartening.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

Verified that the kbd fix works, and that double clicks emulated with middle button under fast-forward work now. Dig demo does not have the slightly echo-y speech at start any more which is also a bonus.

(Btw. When testing anything audio related in Hatari, please make sure that you do have cache emulation enabled with "--cpu-exact on", as caches have huge impact on how fast the emulated programs work in Atari-time.)

Noticed that (DOS) AGI Tetris does not accept number for starting level at beginning, one can only proceed by pressing Enter. That seems to happen also with the 2.8 release, so it's not a regression.
mikro wrote: Sun Feb 25, 2024 7:29 pm Eero, if you have time, could you measure how big impact these two executables have in the profile output: https://mikro.naprvyraz.sk/private/nippon-test.zip. "No delay" version has the delayMillis() removed, "delay" has kept it in place. This applies only to Nippon, Inc.
What kind of comparison you were thinking of?

For now, I did just a quick walking around in first Nippon screen with "no-delay" version, and game seemed still playable.

Delay's are indeed gone:

Code: Select all

Time spent in profile = 207.88226s.
...
Used cycles:
  35.99%                  2400688103                       c2p1x1_8_rect_start
  27.82%                  1855618331                       c2p1x1_8_rect_pix16
   8.78%                   585514099                       Parallaction::Gfx::bltMaskNoScale(Common::Rect const&, unsigned char*, Graphics::Surface*, unsigned short, unsigned char)
   7.68%                   511927344                       copy256
   4.72%   4.80%   4.80%   314958142 320302679 320341924   Parallaction::MaskBuffer::getValue(unsigned short, unsigned short) const
   3.80%                   253532289                       ROM_TOS
   2.22%                   148345431                       Parallaction::Gfx::bltNoMaskNoScale(Common::Rect const&, unsigned char*, Graphics::Surface*, unsigned char)
   1.46%   1.49%   1.49%    97646050  99599031  99612291   Parallaction::BackgroundInfo::hasMask()
   0.91%                    60799894                       sprite8_xloop

mikro wrote: Sun Feb 25, 2024 7:29 pm Of course, one can't just simply remove the call because on a faster computer (CT60, Aranym, not to mention PCs) the game becomes too fast (i.e. walking, sprite animations etc). So the proper fix is to introduce a frame limiter like the "good" games do.

However this poses the other problem which I'm bumping into from time to time: to what extend to support ScummVM User Experience. If I chose just SCUMM (LucasArts games), that's clear, I have one engine to take care of, so if anything weird happens in a game, I can easily track it down to the engine source code. But with tens of games?

The ideal solution would be to go engine-by-engine and investigate all of their delayMillis() calls.
...
Most likely I'll bite the bullet and create an official pull request but the amount of wasted time on this will be disheartening.
I'd do that only for engine (or two) which you care about most, where impact seems largest, and effort is reasonable.

For rest, I think grepping for problematic looking delays, and filing per-engine bugs requesting them to be switched to frame limiting instead (with your PR as example) would be enough.
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

As for the comparison, yeah, I wanted some impartial confirmation that the cycles really went into *that* specific delay. The game should feel also more playable, at least in theory.

Hopefully in a near feature I'll provide you a way to measure *exact* frame rate, so we don't need to rely only on relative percentages between the most used functions.

I spent some time on it yesterday, I've settled on the idea of implementing the frame limiter into engines which we support. It's not that much and most likely there will be some cases which I probably leave as is but it's a good start. I can't rely on bug reports because nobody would fix it -- there's no reason/gain for them.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Mon Feb 26, 2024 8:30 am I spent some time on it yesterday, I've settled on the idea of implementing the frame limiter into engines which we support. It's not that much and most likely there will be some cases which I probably leave as is but it's a good start. I can't rely on bug reports because nobody would fix it -- there's no reason/gain for them.
Atari is not the only platform with limited CPU capabilities. In ScummVM git I see recent activity e.g. for Amiga and PSP backends. If you know their maintainers, maybe you could CC them on improvement ideas that would improve perf also with their backends?

Even if they would not do the work, they could at least voice their support that such a change would be desirable for multiple platforms, and test the PRs to report how visible the improvement is, and to help verify that they do not break something.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

mikro wrote: Sat Feb 24, 2024 3:20 am If this were on real hardware, I'd dig deeper but here it could be still Hatari's imperfection (esp. in combination with the FF mode) so I don't care that much.

Key repeat doesn't work in FF at all (it's insanely fast), that's why it there is the option to disable it in the GUI, isn't there?
No and yes. Key repeat being insanely fast still means that it works fine from emulation point of view. :-)

(Repeat speed is just a by product of emulation proceeding much faster compared to how long you keep the key pressed down.)
mikro wrote: Sat Feb 24, 2024 3:20 am And as for the double click, it is surely related to Falcon's emulation speed (it's quite hard to double-click also on real 16 MHz Falcon). FF makes a false impression of a faster machine but in fact it is internally as slow as before, therefore OSystem::update() gets called as (not) often as before and therefore double-click is not registered within the specified time limit.
Yes, fast-forward only skips host wait on VBL, used for syncing emulation progress to host. It does not affect emulation itself (unless RTC is used, as Hatari queries RTC time from host clock).

With cache emulation disabled, emulated machine is actually considerably slower than real HW. Disabling it helps FF speed only because cache emulation is so expensive (especially on slower PCs), that there's much less VBL waiting.

As ScummVM boots nowadays reasonable fast, I would strongly suggest using Hatari normally with cache emulation enabled though, and booting Hatari with CE disabled only if you need to fast-forward some longer periods.

PS. Was ScummVM using 50 Hz or 60 Hz? Nicolas is currently looking into Falcon 50Hz vs. 60Hz emulation...
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Just quickly:

Amiga (OS4) and PSP are most likely still able to finish a game's frame (especially for 320x200 titles) fast enough.

ScummVM uses whatever OS provides (via VsetMode()).
Teki
Atariator
Atariator
Posts: 22
Joined: Sat Oct 09, 2021 12:23 am

Re: ScummVM/Falcon060 pre-release

Post by Teki »

a lot happening and i still read with all here...
i have a lot to write about speed , compatiblity and some questions, netusbee and so on so maybe i split it and begin with configuration :

-atari falcon ct060 full 060 at 90 mhz
-16mb(14mb) atari ram + 512 mb sd kingston ram
-32 gb pata (arround 1,1mb sec) <--- correct me if wrong
- netUsbee (around 550kb/s) <--- correct me if wrong
- freemint from feb. 2024 and an easymint 1.90 at the moment just for scumm games with long filenames from ssd (32 gb in different tos and linux partitions)

scumm ini 8195 hz samplerate and 1024 buffer size

most scumm games where possible with real speech and music and converted from 0gg/fla/mp3 to wav for atari,
some games have its own audio formats
3 or 4 of the later games like feeble files have long filenames, so make sure you transfer with long filenames on your atari
linux partition

so we com to net usbee speed ...
most rgb games works fine with scumm 2.90 from usb stick some vga games also (maybe some animation/clips would run faster from ssd)
so thats my 1st question a 2*cd rom have 300 kb/s a quad speed 600kb/sec ...
in that falcon time the pc cd games are mostly running with 2*cd rom
so NETUsbee should have enough speed for the most games ???

short question before going on with a feeble files question and running speed description,
neverhood and other worlds dont run ? anymore? i remember at least an earlier version was able to play neverhood ...
BTW. RAMA runs fine aswell
for me the best piece of software since years especially for 060 as it brings a lot of rpg and point and click adventures that really is worth a 060 :)
thanks a lot mikro and all who was helping
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

@Teki: your setup and speed values look OK to me.

As for the question of USB vs. 90's CD-ROMs: don't forget that ScummVM is a *reimplementation* of the respective games' engines. In simpler words, imagine the original engine is an optimised m68k assembly code while ScummVM is rewritten (from scratch, usually) in C++. I have even fixed a couple of REALLY inefficient file handling code blocks (like Gobliins taking one minute to load...). So our machines get some beating with ScummVM because it's code targeted at current hardware, not 90s hardware. The fact that some games run even on 50 MHz (and lower) 68030 CPU is a pure miracle.

Neverhood: I'm not aware of any changes. Can you download 2.8.0 and compare your results?
Teki
Atariator
Atariator
Posts: 22
Joined: Sat Oct 09, 2021 12:23 am

Re: ScummVM/Falcon060 pre-release

Post by Teki »

after complete system "install", i copied scumm again and there are long filenames also in the scumm folder /data/ neverhood.dat ...
so neverhood working again ... be sure also to copy scumm with long filenames (not only the games)
Teki
Atariator
Atariator
Posts: 22
Joined: Sat Oct 09, 2021 12:23 am

Re: ScummVM/Falcon060 pre-release

Post by Teki »

feeble files ... a while ago i tried to patch feeble files to my native language and i dont know how but sound and speech was gone completly
BUT the animations and game runs smooth as hell without sound/speech ... does it means the sound takes such a lot of disc acess and/or processing power ?
would a dsp mixer help a bit if its the disc acess ?
normally the game is good playable just the intro/cutscene animations stuttering
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3610
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM/Falcon060 pre-release

Post by Eero Tamminen »

Teki wrote: Sun Apr 07, 2024 2:38 pm after complete system "install", i copied scumm again and there are long filenames also in the scumm folder /data/ neverhood.dat ...
so neverhood working again ... be sure also to copy scumm with long filenames (not only the games)
Yes, there are ScummVM data files for few game engines with longer than 8+3 names under data/ dir, neverhood is one of them. They were discussed some time earlier, as those games do not work under TOS because ScummVM scans the dir for file names instead of just trying to open the files (latter works fine for long file names even under plain TOS, former method does not).
Teki wrote: Sun Apr 07, 2024 2:49 pm feeble files ... a while ago i tried to patch feeble files to my native language and i dont know how but sound and speech was gone completly
BUT the animations and game runs smooth as hell without sound/speech ... does it means the sound takes such a lot of disc acess and/or processing power ?
would a dsp mixer help a bit if its the disc acess ?
normally the game is good playable just the intro/cutscene animations stuttering
I've noticed that ScummVM engines constantly re-read the sound files, they do not cache them. On PCs, OS will cache the read files for applications, but under TOS AFAIK only the harddisk driver does that[1]. As you have lot of RAM, you could try setting your disk caches sizes to something crazy, eg. 64MB.

Btw. Is this game speedup visible already in the Feeble Files intro? If yes, I could profile that intro a bit using HD images (so that TOS disk accesses CPU usage is visible in profiles, as normally I use GEMDOS HD to avoid that overhead)...

[1] C-library can do some caching also, but by default that buffer is very small, and setvbuf() needs to be specifically set for each opened file i.e. it won't help when game engine closes and reopens the audio files.
Teki
Atariator
Atariator
Posts: 22
Joined: Sat Oct 09, 2021 12:23 am

Re: ScummVM/Falcon060 pre-release

Post by Teki »

yes eero ... the feeble files intro runs fast as hell without speech and without music ... i was sitting there and WOW ...
i have 512mb ram at my 060 so i can set cache even to 128 or 256 mb ???
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Teki wrote: Sun Apr 07, 2024 2:49 pmdoes it means the sound takes such a lot of disc acess and/or processing power ?
would a dsp mixer help a bit if its the disc acess ?
Yes, it's even mentioned in the README: https://github.com/scummvm/scummvm/blob ... #L372-L383.

A DSP mixer would help with all sorts of issues but of course, sound data always have to be read & decoded first so maybe in this particular case this wont help *that* much.
Eero Tamminen wrote: Mon Apr 08, 2024 12:18 am [1] C-library can do some caching also, but by default that buffer is very small, and setvbuf() needs to be specifically set for each opened file i.e. it won't help when game engine closes and reopens the audio files.
Indeed, they even have a separate C++ wrapper for that task. That's what I used for fixing the terrible Gobliiins performance. I also have it in my TODO but I always need a test case which I seem to have now (The Feeble Files). Before that it was COMI but since I have increased its internal cache and implemented my "anti stutter" audio system, the intro (and game) doesn't seem to suffer that much even without SuperVidel.
Teki
Atariator
Atariator
Posts: 22
Joined: Sat Oct 09, 2021 12:23 am

Re: ScummVM/Falcon060 pre-release

Post by Teki »

stuttering sound extremly is also at sanitarium intro and spiderman sinister six ...
darbi the dragon btw. works fine ... are there more children games like this ?
also sherlock holmes rose of the tatoo is playable good but intro sound also stuttering
btw i use freemint (thorsten otto) for scumm as it seems faster for scumm then easymint and i only have a vga monitor
mikro
Hardware Guru
Hardware Guru
Posts: 4105
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM/Falcon060 pre-release

Post by mikro »

Sanitarium intro? Really? Hmm, I have to take a look, Sanitarium is one of the most tested things in my list, I would have noticed some stuttering for sure... on the other hand, I can't swear I tested it after my audio stuttering fix.

Yeah, The Rose of the Tattoo is known beast, there's nothing to be done except detailed profiling. I guess it uses a lot of custom copy routines instead of relying on common/optimised ones (same as Sanitarium, btw).

The FreeMiNT difference seems odd, I'm not even calling that many OS functions during ScummVM run.

Anyway, I'll take a look at the Sanitarium, Spiderman and The Feeble Files.
Post Reply

Return to “News & Announcements”