[Scummvm-git-logs] scummvm master -> 6ee9afacb932a0dc34de2e58001f7004a387878b

mikrosk noreply at scummvm.org
Sat Oct 10 14:58:20 UTC 2026 

This automated email contains information about 1 new commit which have been
pushed to the 'scummvm' repo located at https://api.github.com/repos/scummvm/scummvm .

Summary:
6ee9afacb9 BACKENDS: ATARI: Update docs


Commit: 6ee9afacb932a0dc34de2e58001f7004a387878b
    https://github.com/scummvm/scummvm/commit/6ee9afacb932a0dc34de2e58001f7004a387878b
Author: Miro Kropacek (miro.kropacek at gmail.com)
Date: 2026-10-11T00:58:08+10:00

Commit Message:
BACKENDS: ATARI: Update docs

Changed paths:
    backends/graphics/atari/atari-graphics.cpp
    backends/platform/atari/readme.txt
    backends/platform/atari/readme.txt.in


diff --git a/backends/graphics/atari/atari-graphics.cpp b/backends/graphics/atari/atari-graphics.cpp
index 31406cfeb85..15f67592087 100644
--- a/backends/graphics/atari/atari-graphics.cpp
+++ b/backends/graphics/atari/atari-graphics.cpp
@@ -678,6 +678,14 @@ void AtariGraphicsManager::updateScreen() {
 
 		if (s_screenSurf == nullptr) {
 			// BACK_BUFFER2 has been set; guard it from overwriting while presented
+
+			// TODO: this assumes that the video base written in VblHandler() is applied
+			// in the same frame. True for Videl (video counter reloaded at VDB, after VBL)
+			// but not for TT: like ST/E, its Shifter reloads the video counter about three
+			// lines before the VBL (and again on the following line), so FRONT_BUFFER is
+			// still displayed for one more frame while it becomes BACK_BUFFER1, i.e. the
+			// work screen. On TT, the video base can be written here directly instead,
+			// BACK_BUFFER2 is then displayed once a VBL (_frclock) has passed since.
 			Screen *tmp = _screen[kBackBuffer2];
 			_screen[kBackBuffer2] = _screen[kFrontBuffer];
 			_screen[kFrontBuffer] = tmp;
diff --git a/backends/platform/atari/readme.txt b/backends/platform/atari/readme.txt
index 0ddc4a18171..4669166fb80 100644
--- a/backends/platform/atari/readme.txt
+++ b/backends/platform/atari/readme.txt
@@ -71,6 +71,8 @@ Minimum hardware requirements: Atari Falcon with 4 + 32 MB RAM and 68040 CPU.
 
 - Native MIDI output.
 
+- Native OPL2/OPL3 output.
+
 - Native CDDA support.
 
 - Runs also in Hatari and ARAnyM but in case of ARAnyM don't forget to disable
@@ -104,8 +106,9 @@ executable size.
   but still allows playing speech/sfx samples and/or CD audio and/or native
   MIDI music).
 
-- "null" music driver is automatically enabled (i.e. OPL emulation is never
-  used but still allows playing speech/sfx samples and/or CD audio).
+- "None" AdLib emulator is automatically enabled (i.e. OPL emulation is never
+  used but still allows playing speech/sfx samples and/or CD audio and/or
+  native OPL music).
 
 - DOSBox and MAME OPL emulator is disabled => smaller executable size.
 
@@ -372,8 +375,11 @@ MIDI vs. AdLib vs. sampled music
 
 It could seem that sampled music replay must be the most demanding one but on
 the contrary! Always choose a CD version of a game (with *.wav tracks) over any
-other version. With one exception: if you have a native MIDI device able to
-replay the given game's MIDI notes (using the STMIDI plugin).
+other version. With two exceptions: if you have a native MIDI device able to
+replay the given game's MIDI notes (using the STMIDI plugin) or a real OPL chip
+able to replay the given game's AdLib music (using one of the "[nFM]" devices
+in "AdLib emulator", e.g. the NokturnFM2/NokturnFM3 cartridge or Hatari once
+nFM's patch is merged).
 
 MIDI emulation (synthesis) can easily eat as much as 50% of all used CPU time
 (on the CT60 and even if no OPL music is produced at the moment). By default,
@@ -385,11 +391,11 @@ better quality synthesis, otherwise the lowest quality will be used (applies
 for MAME OPL only).
 
 On TT, in most cases it makes sense to use ScummVM only if you own a native
-MIDI synthesiser (like mt32-pi: https://github.com/dwhinham/mt32-pi). MIDI
-emulation is out of the question and downsampling to 8-bit resolution takes a
-good chunk of CPU time which could be utilised elsewhere. However, there are
-games which are fine with sampled music/speech even on a plain TT (e.g. Lands
-of Lore).
+MIDI synthesiser (like mt32-pi: https://github.com/dwhinham/mt32-pi) or a real
+OPL chip (like the NokturnFM cartridge). MIDI/OPL emulation is out of the
+question and downsampling to 8-bit resolution takes a good chunk of CPU time
+which could be utilised elsewhere. However, there are games which are fine with
+sampled music/speech even on a plain TT (e.g. Lands of Lore).
 
 CD music slows everything down
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -506,8 +512,9 @@ Changes to upstream
 -------------------
 
 - This port contains experimental / pending optimisations to audio mixing
-  (https://github.com/scummvm/scummvm/pull/7385). I'll try to get them merged
-  in the next release.
+  (https://github.com/scummvm/scummvm/pull/7599). I'll try to get them merged
+  in the next release. It also contains fake audio thread implementation by
+  Anders Granlund (which more or less depend on the PR).
 
 
 Known issues
diff --git a/backends/platform/atari/readme.txt.in b/backends/platform/atari/readme.txt.in
index f978639115c..56eb779adda 100644
--- a/backends/platform/atari/readme.txt.in
+++ b/backends/platform/atari/readme.txt.in
@@ -71,6 +71,8 @@ Minimum hardware requirements: Atari Falcon with 4 + 32 MB RAM and 68040 CPU.
 
 - Native MIDI output.
 
+- Native OPL2/OPL3 output.
+
 - Native CDDA support.
 
 - Runs also in Hatari and ARAnyM but in case of ARAnyM don't forget to disable
@@ -104,8 +106,9 @@ executable size.
   but still allows playing speech/sfx samples and/or CD audio and/or native
   MIDI music).
 
-- "null" music driver is automatically enabled (i.e. OPL emulation is never
-  used but still allows playing speech/sfx samples and/or CD audio).
+- "None" AdLib emulator is automatically enabled (i.e. OPL emulation is never
+  used but still allows playing speech/sfx samples and/or CD audio and/or
+  native OPL music).
 
 - DOSBox and MAME OPL emulator is disabled => smaller executable size.
 
@@ -372,8 +375,11 @@ MIDI vs. AdLib vs. sampled music
 
 It could seem that sampled music replay must be the most demanding one but on
 the contrary! Always choose a CD version of a game (with *.wav tracks) over any
-other version. With one exception: if you have a native MIDI device able to
-replay the given game's MIDI notes (using the STMIDI plugin).
+other version. With two exceptions: if you have a native MIDI device able to
+replay the given game's MIDI notes (using the STMIDI plugin) or a real OPL chip
+able to replay the given game's AdLib music (using one of the "[nFM]" devices
+in "AdLib emulator", e.g. the NokturnFM2/NokturnFM3 cartridge or Hatari once
+nFM's patch is merged).
 
 MIDI emulation (synthesis) can easily eat as much as 50% of all used CPU time
 (on the CT60 and even if no OPL music is produced at the moment). By default,
@@ -385,11 +391,11 @@ better quality synthesis, otherwise the lowest quality will be used (applies
 for MAME OPL only).
 
 On TT, in most cases it makes sense to use ScummVM only if you own a native
-MIDI synthesiser (like mt32-pi: https://github.com/dwhinham/mt32-pi). MIDI
-emulation is out of the question and downsampling to 8-bit resolution takes a
-good chunk of CPU time which could be utilised elsewhere. However, there are
-games which are fine with sampled music/speech even on a plain TT (e.g. Lands
-of Lore).
+MIDI synthesiser (like mt32-pi: https://github.com/dwhinham/mt32-pi) or a real
+OPL chip (like the NokturnFM cartridge). MIDI/OPL emulation is out of the
+question and downsampling to 8-bit resolution takes a good chunk of CPU time
+which could be utilised elsewhere. However, there are games which are fine with
+sampled music/speech even on a plain TT (e.g. Lands of Lore).
 
 CD music slows everything down
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -506,8 +512,9 @@ Changes to upstream
 -------------------
 
 - This port contains experimental / pending optimisations to audio mixing
-  (https://github.com/scummvm/scummvm/pull/7385). I'll try to get them merged
-  in the next release.
+  (https://github.com/scummvm/scummvm/pull/7599). I'll try to get them merged
+  in the next release. It also contains fake audio thread implementation by
+  Anders Granlund (which more or less depend on the PR).
 
 
 Known issues

More information about the Scummvm-git-logs mailing list