[Scummvm-git-logs] scummvm branch-3-0 -> 893e6f364770148d469212583ddee1e789ceebbf
mikrosk
noreply at scummvm.org
Fri Nov 21 02:30:10 UTC 2025
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:
893e6f3647 BACKENDS: ATARI: Update readme.txt
Commit: 893e6f364770148d469212583ddee1e789ceebbf
https://github.com/scummvm/scummvm/commit/893e6f364770148d469212583ddee1e789ceebbf
Author: Miro Kropacek (miro.kropacek at gmail.com)
Date: 2025-11-21T12:29:48+10:00
Commit Message:
BACKENDS: ATARI: Update readme.txt
Changed paths:
backends/platform/atari/readme.txt
backends/platform/atari/readme.txt.in
diff --git a/backends/platform/atari/readme.txt b/backends/platform/atari/readme.txt
index 62da95bb662..e0ed301c816 100644
--- a/backends/platform/atari/readme.txt
+++ b/backends/platform/atari/readme.txt
@@ -13,22 +13,22 @@ New port?
---------
Keith Scroggins (aka KeithS) has been providing ScummVM (and many other) builds
-for the Atari community for unbelievable 17 years. He put quite a lot of time
+for the Atari community for an unbelievable 17 years. He put quite a lot of time
into testing each release, updating ScummVM dependencies to their latest
-version and even regularly upgrading his compiler toolchain to get the best
+versions and even regularly upgrading his compiler toolchain to get the best
possible performance.
-However ScummVM (and SDL to some extent) is a beast, it requires quite a lot of
-attention where the cycles go, e.g. an additional screen refresh can easily
-drop frame rate to half.
+However, ScummVM (and SDL to some extent) is a beast; it requires quite a lot
+of attention regarding where the cycles go, e.g. an additional screen refresh
+can easily drop the frame rate by half.
After I had seen how snappy NovaCoder's ScummVM on the Amiga is (who coded his
-own backend), I decided to check whether there isn't a way to get a better
+own backend), I decided to check whether there was a way to get a better
performing port on our platform. And there is!
-I have managed to create a "native" Atari port talking directly to hardware,
-skipping the SDL layer altogether, which is in some cases usable even on plain
-32 MHz Atari TT.
+I have managed to create a "native" Atari port talking directly to the
+hardware, skipping the SDL layer altogether, which is in some cases usable even
+on a plain 32 MHz Atari TT.
Differences between the versions
@@ -43,14 +43,14 @@ Atari Full package
Minimum hardware requirements: Atari Falcon with 4 + 64 MB RAM, 68040 CPU.
-- Because there's a limited horsepower available on our platform, features like
+- Because there is limited horsepower available on our platform, features like
16bpp graphics, software synthesisers, scalers, real-time software
MP3/OGG/FLAC playback etc., are omitted. This saves CPU cycles, memory and
disk space.
- Tailored video settings for the best possible performance and visual
experience (Falcon RGB overscan, chunky modes with the SuperVidel, TT 640x480
- for the overlay, ...)
+ for the overlay, ...).
- Direct rendering and single/triple buffering support.
@@ -60,13 +60,14 @@ Minimum hardware requirements: Atari Falcon with 4 + 64 MB RAM, 68040 CPU.
- Custom (hardware based) aspect ratio correction (!)
-- Full support for the SuperVidel, incl. the SuperBlitter (!)
+- Full support for the SuperVidel, including the SuperBlitter (!)
- External DSP clock support for playing back samples at PC frequencies
- (Falcon only). Dual clock input frequency supported as well (Steinberg's FDI).
+ (Falcon only). Dual clock input frequency supported as well (Steinberg's
+ FDI).
- Support for PC keys (page up, page down, pause, F11/F12, ...) and mouse wheel
- (Eiffel/Aranym only)
+ (Eiffel/Aranym only).
- Native MIDI output (if present).
@@ -97,7 +98,7 @@ features but also improves performance and reduces executable size.
- Overlay doesn't support alternative themes => faster loading time.
- "STMIDI" driver is automatically enabled (i.e. MIDI emulation is never used
- but still allows playing speech/sfx samples and/or CD audio)
+ but still allows playing speech/sfx samples and/or CD audio).
FireBee package
~~~~~~~~~~~~~~~
@@ -106,7 +107,7 @@ Hardware requirements: MCF5475 Evaluation Board or FireBee.
This one is still built and provided by Keith.
-- Based on most recent SDL
+- Based on the most recent SDL.
- Contains various optimisations discovered / implemented from the Atari
backend.
@@ -114,13 +115,13 @@ This one is still built and provided by Keith.
- Works in GEM (in theory also in XBIOS but that seems to be still broken on
FireBee).
-- Support for all engines is included in the build, this does not mean all
+- Support for all engines is included in the build; this does not mean all
games work. For instance, support for OGG and MP3 audio is included but the
- system can not handle playback of compressed audio, not enough processing
- power for both gameplay and sound at the same time.
+ system can not handle playback of compressed audio; there is not enough
+ processing power for both gameplay and sound at the same time.
Scalers can be utilized to make the GEM window larger on the Firebee.
- Performance is best when not usimg AdLib sound, using STMIDI would be
+ Performance is best when not using AdLib sound; using STMIDI would be
optimal, but untested as of yet (I have been unable to get MIDI to work on my
FireBee).
@@ -155,7 +156,7 @@ that Falcon doesn't allow mixing in 16-bit mono, so this will have no effect on
this machine.
"print_rate" in scummvm.ini: used for optimising sample playback (where
-available). It prints input and output sample format as well as name of the
+available). It prints input and output sample format as well as the name of the
converter used. See below for details.
"audio_buffer_size" in scummvm.ini: number of samples to preload. Default is
@@ -171,7 +172,7 @@ Graphics modes
--------------
This topic is more complex than it looks. ScummVM renders game graphics using
-rectangles and this port offers following options to render them:
+rectangles and this port offers the following options to render them:
Direct rendering
~~~~~~~~~~~~~~~~
@@ -181,26 +182,26 @@ done natively, on Videl a chunky to planar conversion takes place beforehand.
Pros:
-- on SuperVidel this offers fastest possible rendering (especially in 640x480
+- On SuperVidel this offers fastest possible rendering (especially in 640x480
with a lot of small rectangle updates where the buffer copying drags
- performance down)
+ performance down).
-- on Videl this _may_ offer fastest possible rendering if the rendering
+- On Videl this _may_ offer fastest possible rendering if the rendering
pipeline isn't flooded with too many small rectangles (C2P setup isn't for
free). However with fullscreen intro sequences this is a no-brainer.
Cons:
-- screen tearing in most cases
+- Screen tearing in most cases.
-- on Videl, this may not work properly if a game engine uses its own buffers
- instead of surfaces (which are aligned on a 16pix boundary). Another source of
- danger is if an engine draws directly to the screen surface. Fortunately, each
- game can have its own graphics mode set separately so for games which do not
- work properly one can still leave the default graphics mode set.
+- On Videl, this may not work properly if a game engine uses its own buffers
+ instead of surfaces (which are aligned on a 16pix boundary). Another source
+ of danger is if an engine draws directly to the screen surface. Fortunately,
+ each game can have its own graphics mode set separately so for games which do
+ not work properly one can still leave the default graphics mode set.
-- on Videl, overlay background isn't rendered (the gui code can't work with
- bitplanes)
+- On Videl, overlay background isn't rendered (the GUI code can't work with
+ bitplanes).
SuperBlitter used: sometimes (when ScummVM allocates surface via its create()
function; custom/small buffers originating in the engine code are still copied
@@ -215,17 +216,17 @@ which ones they were.
Pros:
-- second fastest possible rendering
+- Second fastest possible rendering.
Cons:
-- screen tearing in most cases
+- Screen tearing in most cases.
-- if there is too many smaller rectangles, it can be less efficient than
- updating the whole buffer at once
+- If there are too many smaller rectangles, it can be less efficient than
+ updating the whole buffer at once.
-SuperBlitter used: yes, for rectangle blitting to screen and cursor restoration.
-Sometimes also for generic copying between buffers (see above).
+SuperBlitter used: yes, for rectangle blitting to screen and cursor
+restoration. Sometimes also for generic copying between buffers (see above).
Triple buffering
~~~~~~~~~~~~~~~~
@@ -238,24 +239,24 @@ two.
Pros:
-- no screen tearing
+- No screen tearing.
-- best compromise between performance and visual experience
+- Best compromise between performance and visual experience.
-- works well with both higher and lower frame rates
+- Works well with both higher and lower frame rates.
Cons:
-- if there is too many smaller rectangles, it can be less efficient than
- single buffering
+- If there are too many smaller rectangles, it can be less efficient than
+ single buffering.
-- slightly irregular frame rate (depends solely on the game's complexity)
+- Slightly irregular frame rate (depends solely on the game's complexity).
-- in case of extremely fast rendering, one or more frames are dropped in favour
- of showing only the most recent one
+- In case of extremely fast rendering, one or more frames are dropped in favour
+ of showing only the most recent one.
-SuperBlitter used: yes, for rectangle blitting to screen and cursor restoration.
-Sometimes also for generic copying between buffers (see above).
+SuperBlitter used: yes, for rectangle blitting to screen and cursor
+restoration. Sometimes also for generic copying between buffers (see above).
Triple buffering is the default mode.
@@ -263,19 +264,19 @@ Triple buffering is the default mode.
SuperVidel and SuperBlitter
---------------------------
-As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That means
-that if the SuperVidel is detected, it does the following:
+As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That
+means that if the SuperVidel is detected, it does the following:
-- uses 8bpp chunky resolutions
+- Uses 8bpp chunky resolutions.
-- patches all surface addresses with OR'ing 0xA0000000, i.e. using SV RAM
- instead of slow ST RAM (and even instead of TT RAM for allowing pure
- SuperBlitter copying)
+- Patches all surface addresses by OR'ing 0xA0000000, i.e. using SV RAM instead
+ of slow ST RAM (and even instead of TT RAM for allowing pure SuperBlitter
+ copying).
-- when SuperVidel FW version >= 9 is detected, the async FIFO buffer is used
- instead of the slower sync blitting (where one has to wait for every rectangle
- blit to finish), this sometimes leads to nearly zero-cost rendering and makes
- a *huge* difference for 640x480 fullscreen updates.
+- When SuperVidel FW version >= 9 is detected, the async FIFO buffer is used
+ instead of the slower sync blitting (where one has to wait for every
+ rectangle blit to finish), this sometimes leads to nearly zero-cost rendering
+ and makes a *huge* difference for 640x480 fullscreen updates.
Aspect ratio correction
@@ -286,52 +287,53 @@ implements this functionality using yet another fullscreen transformation of
320x200 surface into a 320x240 one (there is even a selection of algorithms for
this task, varying in performance and quality).
-Naturally, this would pose a terrible performance anchor on our backend so some
-cheating has been used:
+Naturally, this would impose a terrible performance penalty on our backend so
+some cheating has been used:
-- on RGB, the vertical refresh rate frequency is set to 60 Hz, creating an
- illusion of creating non-square pixels. Works best on CRT monitors.
+- On RGB, the vertical refresh rate frequency is set to 60 Hz, creating an
+ illusion of non-square pixels. Works best on CRT monitors.
-- on VGA, the vertical refresh rate frequency is set to 70 Hz, with more or
+- On VGA, the vertical refresh rate frequency is set to 70 Hz, with more or
less the same effect as on RGB. Works best on CRT monitors.
-- on SuperVidel, video output is modified in such way that the DVI/HDMI monitor
+- On SuperVidel, video output is modified in such way that the DVI/HDMI monitor
receives a 320x200 image and if properly set/supported, it will automatically
stretch the image to 320x240 (this is usually a setting called "picture
expansion" or "picture stretch" -- make sure it isn't set to something like
- "1:1" or "dot by dot")
+ "1:1" or "dot by dot").
Yes, it's a hack. :) Owners of a CRT monitor can achieve the same effect by the
-analog knobs -- stretch and move the 320x200 picture unless black borders are no
-longer visible. This hack provides a more elegant and per-game functionality.
+analog knobs -- stretch and move the 320x200 picture unless black borders are
+no longer visible. This hack provides a more elegant and per-game
+functionality.
Audio mixing
------------
ScummVM works internally with 16-bit samples so on the TT a simple downsampling
-to 8-bit resolution is used. However there's still one piece missing - an XBIOS
-emulator (so ScummVM doesn't have to access hardware directly). There are two
-options (both available from https://mikrosk.github.io/xbios): STFA and X-SOUND,
-any of these will do. Or executing ScummVM in EmuTOS which contains the same
-routines as X-SOUND.
+to 8-bit resolution is used. However, there is still one piece missing - an
+XBIOS emulator (so ScummVM doesn't have to access hardware directly). There are
+two options (both available from https://mikrosk.github.io/xbios): STFA and
+X-SOUND, any of these will do. Or executing ScummVM in EmuTOS which contains
+the same routines as X-SOUND.
Performance considerations/pitfalls
-----------------------------------
It's important to understand what affects performance on our limited platform to
-avoid unpleasant playing experiences.
+avoid unpleasant gaming experiences.
Game engines with unexpected performance hit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A typical example from this category is Gobliiins (and its sequels), some SCI
-engine games (Gabriel Knight, Larry 2/7, ...) or Sherlock engine (The Case of
-the Rose Tattoo). At first it looks like our machine or Atari backend is doing
-something terribly wrong but the truth is that it is the engine itself which is
-doing a lot of redraws, sometimes even before reaching the backend. The only
-solution is to profile and fix those engines.
+engine games (Gabriel Knight, Larry 2/7, ...) or the Sherlock engine (The Case
+of the Rose Tattoo). At first it looks like our machine or Atari backend is
+doing something terribly wrong but the truth is that it is the engine itself
+which is doing a lot of redraws, sometimes even before reaching the backend.
+The only solution is to profile and fix those engines.
Too many fullscreen updates
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -346,7 +348,7 @@ 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) to any
+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).
@@ -355,14 +357,15 @@ MIDI emulation (synthesis) can easily eat as much as 50% of all used CPU time
to be fastest but also least accurate) but some engines require the DOSBOX one
which is even more demanding. By the way, you can put "FM_high_quality=true" or
"FM_medium_quality=true" into scummvm.ini if you want to experiment with a
-better quality synthesis, otherwise the lowest quality will be used (applies for
-MAME OPL only).
+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 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 plain TT (e.g. Lands of Lore).
+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).
CD music slows everything down
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -371,11 +374,11 @@ Some games use separate audio *and* video streams (files). Even if the CPU is
able to handle both, the bottleneck becomes ... disk access. This is visible in
The Curse Of Monkey Island for example -- there's audible stuttering during the
intro sequence (and during the game as well). Increasing "audio_buffer_size"
-makes the rendering literally crawling! Why? Because disk I/O is busy with
-loading even *more* sample data so there's less time for video loading and
-rendering. Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e.
-symlink to u:/ram in FreeMiNT), you'll be pleasantly surprised with the
-performance boost gained.
+makes the rendering literally crawl! Why? Because disk I/O is busy with loading
+even *more* sample data so there's less time for video loading and rendering.
+Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e. symlink to
+u:/ram in FreeMiNT), you'll be pleasantly surprised with the performance boost
+gained.
Mute vs. "No music"
~~~~~~~~~~~~~~~~~~~
@@ -389,10 +392,10 @@ music (and therefore avoiding the expensive synthesis emulation) but beware, it
doesn't affect CD (*.wav) playback at all! Same applies for speech and sfx.
The least amount of cycles is spent when:
-- "No music" as "Preferred device": this prevents MIDI synthesis of any kind
-- "Subtitles" as "Text and speech": this prevents any sampled speech to be
- mixed
-- all external audio files are deleted (typically *.wav); that way the mixer
+- "No music" as "Preferred device": This prevents MIDI synthesis of any kind.
+- "Subtitles" as "Text and speech": This prevents any sampled speech to be
+ mixed.
+- All external audio files are deleted (typically *.wav); that way the mixer
won't have anything to mix. However beware, this is not allowed in every game!
Sample rate
@@ -400,27 +403,28 @@ Sample rate
It's important to realise the impact the sample rate has on the given game. The
most obvious setting is its value: the bigger, the more demanding audio mixing
-becomes. However if you inspect many games' samples, you will notice that most
+becomes. However, if you inspect many games' samples, you will notice that most
of them (esp. the ones from the 80s/90s) use simple samples like mono 11025 Hz
(sometimes even less).
Obviously, setting "output_channels" to "1" is the easiest improvement
-(unfortunately only on TT). Next best thing you can do is to buy an external DSP
-clock for your Falcon: nearly all games use sample frequencies which are
-multiplies of 44100 Hz: 22050, 11025, ... so with the external clock there won't
-be the need to resample them.
+(unfortunately only on TT). Next best thing you can do is to buy an external
+DSP clock for your Falcon: nearly all games use sample frequencies which are
+multiples of 44100 Hz: 22050, 11025, ... so with the external clock there
+won't be the need to resample them.
There's one caveat, though: it is important whether your replay frequency is
-equal, multiply of or other than the desired one. Let's consider 44100 and 22050
-frequencies as an example (also applies to all the other frequencies):
-
-- if you set 44100 Hz and a game requests 44100 Hz => so called "copyConvert"
- method will be used (fastest)
-- if you set 22050 Hz and a game requests 44100 Hz => so called "simpleConvert"
- method will be used (skipping every second sample, second fastest)
-- if you set 44100 Hz and a game requests 22050 Hz => so called
- "interpolateConvert" method will be used (slowest!)
-- any other combination: "interpolateConvert" (slowest)
+equal to, a multiple of, or other than the desired one. Let's consider 44100
+and 22050 frequencies as an example (also applies to all the other
+frequencies):
+
+- If you set 44100 Hz and a game requests 44100 Hz => so called "copyConvert"
+ method will be used (fastest).
+- If you set 22050 Hz and a game requests 44100 Hz => so called "simpleConvert"
+ method will be used (skipping every second sample, second fastest).
+- If you set 44100 Hz and a game requests 22050 Hz => so called
+ "interpolateConvert" method will be used (slowest!).
+- Any other combination: "interpolateConvert" (slowest).
So how do you know which frequency to set as "output_rate" ? This is where
"print_rate" comes to rescue. Enabling this option in scummvm.ini will tell you
@@ -443,56 +447,56 @@ distributed with repackaged theme files with compression level zero.
Changes to upstream
-------------------
-There is a few features that have been disabled or changed and are not possible
+There are a few features that have been disabled or changed and are not possible
/ plausible to merge into upstream:
- the aforementioned "print_rate" feature, too invasive for other platforms
-- this port contains an implementation of much faster tooltips in the overlay.
- However there is a minor rendering bug which sometimes corrupts the
+- This port contains an implementation of much faster tooltips in the overlay.
+ However, there is a minor rendering bug which sometimes corrupts the
background. But since its impact is huge, I left it in.
Known issues
------------
-- when run on TT, screen contains horizontal black lines. That is due to the
- fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer B
- interrupt.
+- When run on TT, screen contains horizontal black lines. That is due to the
+ fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer
+ B interrupt.
-- horizontal screen shaking doesn't work on TT because TT Shifter doesn't
+- Horizontal screen shaking doesn't work on TT because TT Shifter doesn't
support fine scrolling. However it is "emulated" via vertical shaking.
-- aspect ratio correction has no effect on TT because is not possible to alter
- its vertical screen refresh frequency.
+- Aspect ratio correction has no effect on TT because it is not possible to
+ alter its vertical screen refresh frequency.
-- the talkie version of SOMI needs to be merged from two sources:
- - the DOS version (install.bat) to obtain file "monster.sou"
- - the FLAC version (install_flac.bat) to obtain folders "cd_music_flac" and
+- The talkie version of SOMI needs to be merged from two sources:
+ - The DOS version (install.bat) to obtain file "monster.sou".
+ - The FLAC version (install_flac.bat) to obtain folders "cd_music_flac" and
"se_music_flac" (these *.flac files then have to be converted to *.wav
- manually)
- - files "monkey.000" and "monkey.001" can be taken from either version
- - point the extra path to the folder with *.wav files (or copy its content
- where monkey.00? files are located)
+ manually).
+ - Files "monkey.000" and "monkey.001" can be taken from either version.
+ - Point the extra path to the folder with *.wav files (or copy its content
+ where monkey.00? files are located).
-- following engines have been explicitly disabled:
+- Following engines have been explicitly disabled:
- Cine (2 games)
- - incompatible with other engines / prone to freezes
+ - Incompatible with other engines / prone to freezes.
- https://wiki.scummvm.org/index.php?title=Cine
- Director (many games)
- - huge game list slows detection for other games, and would require
- (currently missing) localization support
- - only small subset of games actually supported by upstream, but none of
- them detected on TOS 8+3 file system
+ - Huge game list slows detection for other games, and would require
+ (currently missing) localization support.
+ - Only small subset of games actually supported by upstream, but none of
+ them detected on TOS 8+3 file system.
- https://wiki.scummvm.org/index.php?title=Director
- Hugo (3 games)
- - uses (lot of) overlay dialogs which are problematic for Atari backend
- - engine GUI (for save/load/etc) does not support 8-bit screens
+ - Uses (lot of) overlay dialogs which are problematic for Atari backend.
+ - Engine GUI (for save/load/etc) does not support 8-bit screens.
- https://wiki.scummvm.org/index.php?title=Hugo
- Ultima (many games)
- - the only non-hires ultima engine is ultima1; see
+ - The only non-hires ultima engine is ultima1; see
https://bugs.scummvm.org/ticket/14790
- - this prevents adding the 15 MB ultima.dat to the release archive
+ - This prevents adding the 15 MB ultima.dat to the release archive.
- https://wiki.scummvm.org/index.php?title=Ultima
- When using FreeMiNT, ScummVM requires a recent kernel (>= 2021), otherwise
@@ -504,28 +508,28 @@ Known issues
Future plans
------------
-- DSP-based sample mixer (WAV, FLAC, MP2)
+- DSP-based sample mixer (WAV, FLAC, MP2).
-- avoid loading music/speech files (and thus slowing down everything) if muted
+- Avoid loading music/speech files (and thus slowing down everything) if muted.
-- cached audio/video streams (i.e. don't load only "audio_buffer_size" number
- of samples but cache, say, 1 second so disk i/o won't be so stressed)
+- Cached audio/video streams (i.e. don't load only "audio_buffer_size" number
+ of samples but cache, say, 1 second so disk i/o won't be so stressed).
-- using Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php for game
- engine plugins to relieve the huge binary size
+- Using Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php for game
+ engine plugins to relieve the huge binary size.
-- true audio CD support via MetaDOS API
+- True audio CD support via MetaDOS API.
-- OPL2LPT and Retrowave support (if I manage to purchase it somewhere)
+- OPL2LPT and Retrowave support (if I manage to purchase it somewhere).
Closing words
-------------
-Many optimisations and improvements wouldn't be possible without help of Eero
-Tamminen, so thank you for all the help with profiling in Hatari.
+Many optimisations and improvements wouldn't be possible without the help of
+Eero Tamminen, so thank you for all the help with profiling in Hatari.
Miro Kropacek aka MiKRO
-Kosice / Slovakia
+Brisbane / Australia
miro.kropacek at gmail.com
http://mikro.atari.org
diff --git a/backends/platform/atari/readme.txt.in b/backends/platform/atari/readme.txt.in
index a6e21950b93..8b31536508a 100644
--- a/backends/platform/atari/readme.txt.in
+++ b/backends/platform/atari/readme.txt.in
@@ -13,22 +13,22 @@ New port?
---------
Keith Scroggins (aka KeithS) has been providing ScummVM (and many other) builds
-for the Atari community for unbelievable 17 years. He put quite a lot of time
+for the Atari community for an unbelievable 17 years. He put quite a lot of time
into testing each release, updating ScummVM dependencies to their latest
-version and even regularly upgrading his compiler toolchain to get the best
+versions and even regularly upgrading his compiler toolchain to get the best
possible performance.
-However ScummVM (and SDL to some extent) is a beast, it requires quite a lot of
-attention where the cycles go, e.g. an additional screen refresh can easily
-drop frame rate to half.
+However, ScummVM (and SDL to some extent) is a beast; it requires quite a lot
+of attention regarding where the cycles go, e.g. an additional screen refresh
+can easily drop the frame rate by half.
After I had seen how snappy NovaCoder's ScummVM on the Amiga is (who coded his
-own backend), I decided to check whether there isn't a way to get a better
+own backend), I decided to check whether there was a way to get a better
performing port on our platform. And there is!
-I have managed to create a "native" Atari port talking directly to hardware,
-skipping the SDL layer altogether, which is in some cases usable even on plain
-32 MHz Atari TT.
+I have managed to create a "native" Atari port talking directly to the
+hardware, skipping the SDL layer altogether, which is in some cases usable even
+on a plain 32 MHz Atari TT.
Differences between the versions
@@ -43,14 +43,14 @@ Atari Full package
Minimum hardware requirements: Atari Falcon with 4 + 64 MB RAM, 68040 CPU.
-- Because there's a limited horsepower available on our platform, features like
+- Because there is limited horsepower available on our platform, features like
16bpp graphics, software synthesisers, scalers, real-time software
MP3/OGG/FLAC playback etc., are omitted. This saves CPU cycles, memory and
disk space.
- Tailored video settings for the best possible performance and visual
experience (Falcon RGB overscan, chunky modes with the SuperVidel, TT 640x480
- for the overlay, ...)
+ for the overlay, ...).
- Direct rendering and single/triple buffering support.
@@ -60,13 +60,14 @@ Minimum hardware requirements: Atari Falcon with 4 + 64 MB RAM, 68040 CPU.
- Custom (hardware based) aspect ratio correction (!)
-- Full support for the SuperVidel, incl. the SuperBlitter (!)
+- Full support for the SuperVidel, including the SuperBlitter (!)
- External DSP clock support for playing back samples at PC frequencies
- (Falcon only). Dual clock input frequency supported as well (Steinberg's FDI).
+ (Falcon only). Dual clock input frequency supported as well (Steinberg's
+ FDI).
- Support for PC keys (page up, page down, pause, F11/F12, ...) and mouse wheel
- (Eiffel/Aranym only)
+ (Eiffel/Aranym only).
- Native MIDI output (if present).
@@ -97,7 +98,7 @@ features but also improves performance and reduces executable size.
- Overlay doesn't support alternative themes => faster loading time.
- "STMIDI" driver is automatically enabled (i.e. MIDI emulation is never used
- but still allows playing speech/sfx samples and/or CD audio)
+ but still allows playing speech/sfx samples and/or CD audio).
FireBee package
~~~~~~~~~~~~~~~
@@ -106,7 +107,7 @@ Hardware requirements: MCF5475 Evaluation Board or FireBee.
This one is still built and provided by Keith.
-- Based on most recent SDL
+- Based on the most recent SDL.
- Contains various optimisations discovered / implemented from the Atari
backend.
@@ -114,13 +115,13 @@ This one is still built and provided by Keith.
- Works in GEM (in theory also in XBIOS but that seems to be still broken on
FireBee).
-- Support for all engines is included in the build, this does not mean all
+- Support for all engines is included in the build; this does not mean all
games work. For instance, support for OGG and MP3 audio is included but the
- system can not handle playback of compressed audio, not enough processing
- power for both gameplay and sound at the same time.
+ system can not handle playback of compressed audio; there is not enough
+ processing power for both gameplay and sound at the same time.
Scalers can be utilized to make the GEM window larger on the Firebee.
- Performance is best when not usimg AdLib sound, using STMIDI would be
+ Performance is best when not using AdLib sound; using STMIDI would be
optimal, but untested as of yet (I have been unable to get MIDI to work on my
FireBee).
@@ -155,7 +156,7 @@ that Falcon doesn't allow mixing in 16-bit mono, so this will have no effect on
this machine.
"print_rate" in scummvm.ini: used for optimising sample playback (where
-available). It prints input and output sample format as well as name of the
+available). It prints input and output sample format as well as the name of the
converter used. See below for details.
"audio_buffer_size" in scummvm.ini: number of samples to preload. Default is
@@ -171,7 +172,7 @@ Graphics modes
--------------
This topic is more complex than it looks. ScummVM renders game graphics using
-rectangles and this port offers following options to render them:
+rectangles and this port offers the following options to render them:
Direct rendering
~~~~~~~~~~~~~~~~
@@ -181,26 +182,26 @@ done natively, on Videl a chunky to planar conversion takes place beforehand.
Pros:
-- on SuperVidel this offers fastest possible rendering (especially in 640x480
+- On SuperVidel this offers fastest possible rendering (especially in 640x480
with a lot of small rectangle updates where the buffer copying drags
- performance down)
+ performance down).
-- on Videl this _may_ offer fastest possible rendering if the rendering
+- On Videl this _may_ offer fastest possible rendering if the rendering
pipeline isn't flooded with too many small rectangles (C2P setup isn't for
free). However with fullscreen intro sequences this is a no-brainer.
Cons:
-- screen tearing in most cases
+- Screen tearing in most cases.
-- on Videl, this may not work properly if a game engine uses its own buffers
- instead of surfaces (which are aligned on a 16pix boundary). Another source of
- danger is if an engine draws directly to the screen surface. Fortunately, each
- game can have its own graphics mode set separately so for games which do not
- work properly one can still leave the default graphics mode set.
+- On Videl, this may not work properly if a game engine uses its own buffers
+ instead of surfaces (which are aligned on a 16pix boundary). Another source
+ of danger is if an engine draws directly to the screen surface. Fortunately,
+ each game can have its own graphics mode set separately so for games which do
+ not work properly one can still leave the default graphics mode set.
-- on Videl, overlay background isn't rendered (the gui code can't work with
- bitplanes)
+- On Videl, overlay background isn't rendered (the GUI code can't work with
+ bitplanes).
SuperBlitter used: sometimes (when ScummVM allocates surface via its create()
function; custom/small buffers originating in the engine code are still copied
@@ -215,17 +216,17 @@ which ones they were.
Pros:
-- second fastest possible rendering
+- Second fastest possible rendering.
Cons:
-- screen tearing in most cases
+- Screen tearing in most cases.
-- if there is too many smaller rectangles, it can be less efficient than
- updating the whole buffer at once
+- If there are too many smaller rectangles, it can be less efficient than
+ updating the whole buffer at once.
-SuperBlitter used: yes, for rectangle blitting to screen and cursor restoration.
-Sometimes also for generic copying between buffers (see above).
+SuperBlitter used: yes, for rectangle blitting to screen and cursor
+restoration. Sometimes also for generic copying between buffers (see above).
Triple buffering
~~~~~~~~~~~~~~~~
@@ -238,24 +239,24 @@ two.
Pros:
-- no screen tearing
+- No screen tearing.
-- best compromise between performance and visual experience
+- Best compromise between performance and visual experience.
-- works well with both higher and lower frame rates
+- Works well with both higher and lower frame rates.
Cons:
-- if there is too many smaller rectangles, it can be less efficient than
- single buffering
+- If there are too many smaller rectangles, it can be less efficient than
+ single buffering.
-- slightly irregular frame rate (depends solely on the game's complexity)
+- Slightly irregular frame rate (depends solely on the game's complexity).
-- in case of extremely fast rendering, one or more frames are dropped in favour
- of showing only the most recent one
+- In case of extremely fast rendering, one or more frames are dropped in favour
+ of showing only the most recent one.
-SuperBlitter used: yes, for rectangle blitting to screen and cursor restoration.
-Sometimes also for generic copying between buffers (see above).
+SuperBlitter used: yes, for rectangle blitting to screen and cursor
+restoration. Sometimes also for generic copying between buffers (see above).
Triple buffering is the default mode.
@@ -263,19 +264,19 @@ Triple buffering is the default mode.
SuperVidel and SuperBlitter
---------------------------
-As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That means
-that if the SuperVidel is detected, it does the following:
+As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That
+means that if the SuperVidel is detected, it does the following:
-- uses 8bpp chunky resolutions
+- Uses 8bpp chunky resolutions.
-- patches all surface addresses with OR'ing 0xA0000000, i.e. using SV RAM
- instead of slow ST RAM (and even instead of TT RAM for allowing pure
- SuperBlitter copying)
+- Patches all surface addresses by OR'ing 0xA0000000, i.e. using SV RAM instead
+ of slow ST RAM (and even instead of TT RAM for allowing pure SuperBlitter
+ copying).
-- when SuperVidel FW version >= 9 is detected, the async FIFO buffer is used
- instead of the slower sync blitting (where one has to wait for every rectangle
- blit to finish), this sometimes leads to nearly zero-cost rendering and makes
- a *huge* difference for 640x480 fullscreen updates.
+- When SuperVidel FW version >= 9 is detected, the async FIFO buffer is used
+ instead of the slower sync blitting (where one has to wait for every
+ rectangle blit to finish), this sometimes leads to nearly zero-cost rendering
+ and makes a *huge* difference for 640x480 fullscreen updates.
Aspect ratio correction
@@ -286,52 +287,53 @@ implements this functionality using yet another fullscreen transformation of
320x200 surface into a 320x240 one (there is even a selection of algorithms for
this task, varying in performance and quality).
-Naturally, this would pose a terrible performance anchor on our backend so some
-cheating has been used:
+Naturally, this would impose a terrible performance penalty on our backend so
+some cheating has been used:
-- on RGB, the vertical refresh rate frequency is set to 60 Hz, creating an
- illusion of creating non-square pixels. Works best on CRT monitors.
+- On RGB, the vertical refresh rate frequency is set to 60 Hz, creating an
+ illusion of non-square pixels. Works best on CRT monitors.
-- on VGA, the vertical refresh rate frequency is set to 70 Hz, with more or
+- On VGA, the vertical refresh rate frequency is set to 70 Hz, with more or
less the same effect as on RGB. Works best on CRT monitors.
-- on SuperVidel, video output is modified in such way that the DVI/HDMI monitor
+- On SuperVidel, video output is modified in such way that the DVI/HDMI monitor
receives a 320x200 image and if properly set/supported, it will automatically
stretch the image to 320x240 (this is usually a setting called "picture
expansion" or "picture stretch" -- make sure it isn't set to something like
- "1:1" or "dot by dot")
+ "1:1" or "dot by dot").
Yes, it's a hack. :) Owners of a CRT monitor can achieve the same effect by the
-analog knobs -- stretch and move the 320x200 picture unless black borders are no
-longer visible. This hack provides a more elegant and per-game functionality.
+analog knobs -- stretch and move the 320x200 picture unless black borders are
+no longer visible. This hack provides a more elegant and per-game
+functionality.
Audio mixing
------------
ScummVM works internally with 16-bit samples so on the TT a simple downsampling
-to 8-bit resolution is used. However there's still one piece missing - an XBIOS
-emulator (so ScummVM doesn't have to access hardware directly). There are two
-options (both available from https://mikrosk.github.io/xbios): STFA and X-SOUND,
-any of these will do. Or executing ScummVM in EmuTOS which contains the same
-routines as X-SOUND.
+to 8-bit resolution is used. However, there is still one piece missing - an
+XBIOS emulator (so ScummVM doesn't have to access hardware directly). There are
+two options (both available from https://mikrosk.github.io/xbios): STFA and
+X-SOUND, any of these will do. Or executing ScummVM in EmuTOS which contains
+the same routines as X-SOUND.
Performance considerations/pitfalls
-----------------------------------
It's important to understand what affects performance on our limited platform to
-avoid unpleasant playing experiences.
+avoid unpleasant gaming experiences.
Game engines with unexpected performance hit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A typical example from this category is Gobliiins (and its sequels), some SCI
-engine games (Gabriel Knight, Larry 2/7, ...) or Sherlock engine (The Case of
-the Rose Tattoo). At first it looks like our machine or Atari backend is doing
-something terribly wrong but the truth is that it is the engine itself which is
-doing a lot of redraws, sometimes even before reaching the backend. The only
-solution is to profile and fix those engines.
+engine games (Gabriel Knight, Larry 2/7, ...) or the Sherlock engine (The Case
+of the Rose Tattoo). At first it looks like our machine or Atari backend is
+doing something terribly wrong but the truth is that it is the engine itself
+which is doing a lot of redraws, sometimes even before reaching the backend.
+The only solution is to profile and fix those engines.
Too many fullscreen updates
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -346,7 +348,7 @@ 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) to any
+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).
@@ -355,14 +357,15 @@ MIDI emulation (synthesis) can easily eat as much as 50% of all used CPU time
to be fastest but also least accurate) but some engines require the DOSBOX one
which is even more demanding. By the way, you can put "FM_high_quality=true" or
"FM_medium_quality=true" into scummvm.ini if you want to experiment with a
-better quality synthesis, otherwise the lowest quality will be used (applies for
-MAME OPL only).
+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 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 plain TT (e.g. Lands of Lore).
+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).
CD music slows everything down
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -371,11 +374,11 @@ Some games use separate audio *and* video streams (files). Even if the CPU is
able to handle both, the bottleneck becomes ... disk access. This is visible in
The Curse Of Monkey Island for example -- there's audible stuttering during the
intro sequence (and during the game as well). Increasing "audio_buffer_size"
-makes the rendering literally crawling! Why? Because disk I/O is busy with
-loading even *more* sample data so there's less time for video loading and
-rendering. Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e.
-symlink to u:/ram in FreeMiNT), you'll be pleasantly surprised with the
-performance boost gained.
+makes the rendering literally crawl! Why? Because disk I/O is busy with loading
+even *more* sample data so there's less time for video loading and rendering.
+Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e. symlink to
+u:/ram in FreeMiNT), you'll be pleasantly surprised with the performance boost
+gained.
Mute vs. "No music"
~~~~~~~~~~~~~~~~~~~
@@ -389,10 +392,10 @@ music (and therefore avoiding the expensive synthesis emulation) but beware, it
doesn't affect CD (*.wav) playback at all! Same applies for speech and sfx.
The least amount of cycles is spent when:
-- "No music" as "Preferred device": this prevents MIDI synthesis of any kind
-- "Subtitles" as "Text and speech": this prevents any sampled speech to be
- mixed
-- all external audio files are deleted (typically *.wav); that way the mixer
+- "No music" as "Preferred device": This prevents MIDI synthesis of any kind.
+- "Subtitles" as "Text and speech": This prevents any sampled speech to be
+ mixed.
+- All external audio files are deleted (typically *.wav); that way the mixer
won't have anything to mix. However beware, this is not allowed in every game!
Sample rate
@@ -400,27 +403,28 @@ Sample rate
It's important to realise the impact the sample rate has on the given game. The
most obvious setting is its value: the bigger, the more demanding audio mixing
-becomes. However if you inspect many games' samples, you will notice that most
+becomes. However, if you inspect many games' samples, you will notice that most
of them (esp. the ones from the 80s/90s) use simple samples like mono 11025 Hz
(sometimes even less).
Obviously, setting "output_channels" to "1" is the easiest improvement
-(unfortunately only on TT). Next best thing you can do is to buy an external DSP
-clock for your Falcon: nearly all games use sample frequencies which are
-multiplies of 44100 Hz: 22050, 11025, ... so with the external clock there won't
-be the need to resample them.
+(unfortunately only on TT). Next best thing you can do is to buy an external
+DSP clock for your Falcon: nearly all games use sample frequencies which are
+multiples of 44100 Hz: 22050, 11025, ... so with the external clock there
+won't be the need to resample them.
There's one caveat, though: it is important whether your replay frequency is
-equal, multiply of or other than the desired one. Let's consider 44100 and 22050
-frequencies as an example (also applies to all the other frequencies):
-
-- if you set 44100 Hz and a game requests 44100 Hz => so called "copyConvert"
- method will be used (fastest)
-- if you set 22050 Hz and a game requests 44100 Hz => so called "simpleConvert"
- method will be used (skipping every second sample, second fastest)
-- if you set 44100 Hz and a game requests 22050 Hz => so called
- "interpolateConvert" method will be used (slowest!)
-- any other combination: "interpolateConvert" (slowest)
+equal to, a multiple of, or other than the desired one. Let's consider 44100
+and 22050 frequencies as an example (also applies to all the other
+frequencies):
+
+- If you set 44100 Hz and a game requests 44100 Hz => so called "copyConvert"
+ method will be used (fastest).
+- If you set 22050 Hz and a game requests 44100 Hz => so called "simpleConvert"
+ method will be used (skipping every second sample, second fastest).
+- If you set 44100 Hz and a game requests 22050 Hz => so called
+ "interpolateConvert" method will be used (slowest!).
+- Any other combination: "interpolateConvert" (slowest).
So how do you know which frequency to set as "output_rate" ? This is where
"print_rate" comes to rescue. Enabling this option in scummvm.ini will tell you
@@ -443,56 +447,56 @@ distributed with repackaged theme files with compression level zero.
Changes to upstream
-------------------
-There is a few features that have been disabled or changed and are not possible
+There are a few features that have been disabled or changed and are not possible
/ plausible to merge into upstream:
- the aforementioned "print_rate" feature, too invasive for other platforms
-- this port contains an implementation of much faster tooltips in the overlay.
- However there is a minor rendering bug which sometimes corrupts the
+- This port contains an implementation of much faster tooltips in the overlay.
+ However, there is a minor rendering bug which sometimes corrupts the
background. But since its impact is huge, I left it in.
Known issues
------------
-- when run on TT, screen contains horizontal black lines. That is due to the
- fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer B
- interrupt.
+- When run on TT, screen contains horizontal black lines. That is due to the
+ fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer
+ B interrupt.
-- horizontal screen shaking doesn't work on TT because TT Shifter doesn't
+- Horizontal screen shaking doesn't work on TT because TT Shifter doesn't
support fine scrolling. However it is "emulated" via vertical shaking.
-- aspect ratio correction has no effect on TT because is not possible to alter
- its vertical screen refresh frequency.
+- Aspect ratio correction has no effect on TT because it is not possible to
+ alter its vertical screen refresh frequency.
-- the talkie version of SOMI needs to be merged from two sources:
- - the DOS version (install.bat) to obtain file "monster.sou"
- - the FLAC version (install_flac.bat) to obtain folders "cd_music_flac" and
+- The talkie version of SOMI needs to be merged from two sources:
+ - The DOS version (install.bat) to obtain file "monster.sou".
+ - The FLAC version (install_flac.bat) to obtain folders "cd_music_flac" and
"se_music_flac" (these *.flac files then have to be converted to *.wav
- manually)
- - files "monkey.000" and "monkey.001" can be taken from either version
- - point the extra path to the folder with *.wav files (or copy its content
- where monkey.00? files are located)
+ manually).
+ - Files "monkey.000" and "monkey.001" can be taken from either version.
+ - Point the extra path to the folder with *.wav files (or copy its content
+ where monkey.00? files are located).
-- following engines have been explicitly disabled:
+- Following engines have been explicitly disabled:
- Cine (2 games)
- - incompatible with other engines / prone to freezes
+ - Incompatible with other engines / prone to freezes.
- https://wiki.scummvm.org/index.php?title=Cine
- Director (many games)
- - huge game list slows detection for other games, and would require
- (currently missing) localization support
- - only small subset of games actually supported by upstream, but none of
- them detected on TOS 8+3 file system
+ - Huge game list slows detection for other games, and would require
+ (currently missing) localization support.
+ - Only small subset of games actually supported by upstream, but none of
+ them detected on TOS 8+3 file system.
- https://wiki.scummvm.org/index.php?title=Director
- Hugo (3 games)
- - uses (lot of) overlay dialogs which are problematic for Atari backend
- - engine GUI (for save/load/etc) does not support 8-bit screens
+ - Uses (lot of) overlay dialogs which are problematic for Atari backend.
+ - Engine GUI (for save/load/etc) does not support 8-bit screens.
- https://wiki.scummvm.org/index.php?title=Hugo
- Ultima (many games)
- - the only non-hires ultima engine is ultima1; see
+ - The only non-hires ultima engine is ultima1; see
https://bugs.scummvm.org/ticket/14790
- - this prevents adding the 15 MB ultima.dat to the release archive
+ - This prevents adding the 15 MB ultima.dat to the release archive.
- https://wiki.scummvm.org/index.php?title=Ultima
- When using FreeMiNT, ScummVM requires a recent kernel (>= 2021), otherwise
@@ -504,28 +508,28 @@ Known issues
Future plans
------------
-- DSP-based sample mixer (WAV, FLAC, MP2)
+- DSP-based sample mixer (WAV, FLAC, MP2).
-- avoid loading music/speech files (and thus slowing down everything) if muted
+- Avoid loading music/speech files (and thus slowing down everything) if muted.
-- cached audio/video streams (i.e. don't load only "audio_buffer_size" number
- of samples but cache, say, 1 second so disk i/o won't be so stressed)
+- Cached audio/video streams (i.e. don't load only "audio_buffer_size" number
+ of samples but cache, say, 1 second so disk i/o won't be so stressed).
-- using Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php for game
- engine plugins to relieve the huge binary size
+- Using Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php for game
+ engine plugins to relieve the huge binary size.
-- true audio CD support via MetaDOS API
+- True audio CD support via MetaDOS API.
-- OPL2LPT and Retrowave support (if I manage to purchase it somewhere)
+- OPL2LPT and Retrowave support (if I manage to purchase it somewhere).
Closing words
-------------
-Many optimisations and improvements wouldn't be possible without help of Eero
-Tamminen, so thank you for all the help with profiling in Hatari.
+Many optimisations and improvements wouldn't be possible without the help of
+Eero Tamminen, so thank you for all the help with profiling in Hatari.
Miro Kropacek aka MiKRO
-Kosice / Slovakia
+Brisbane / Australia
miro.kropacek at gmail.com
http://mikro.atari.org
More information about the Scummvm-git-logs
mailing list