Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - ZvikaZ

Pages: [1] 2 3 4
SCI Development Tools / General MIDI vs MT-32
« on: September 04, 2023, 01:13:48 PM »
I've read a long time ago, and I don't remember where, that first SCI games were composed with a MT-32 (and therefore sound best with a MT-32, or Munt), while later SCI games were composed with a SC-55 (and therefore sound best with General MIDI).

Is it accurate?

When was this transform from MT-32 to SC-55 done?
In other words, I want to know which games are better sounded with MT-32, and which games are better sounded with GM.


SCI Development Tools / Dynamix resources?
« on: September 16, 2022, 02:24:58 AM »
Hope it's on topic...

Are there any tools for Dynamix games resources hacking?
Any documentation?
Any interesting info?

Forum Support and Suggestions / Seeing send PMs?
« on: August 31, 2022, 04:31:02 PM »
I have sent a few personal messages - in the past, and recently.
But when I go to "Home ┬╗Community ┬╗Personal Messages ┬╗Sent Items" it says "No messages..."

Can something be done to show those messages? Maybe some configuration change?
If my old messages cannot be saved, at least I would like to see my new sent messages in the future.

SCI Development Tools / Sounder 0.5 - with many improvements
« on: August 29, 2022, 07:00:33 AM »
Sounder version 0.5 is available. It includes many new features, improvements, and bug fixes.
Windows installer can be downloaded from:
Or, if you prefer the Python source:

Read the User Guide (from the Help menu) for the detailed usage instructions.

The Sounder source link has been changed from previous posts.

SCI Development Tools / "Sounder" tool - alpha version is ready
« on: August 01, 2022, 07:34:13 AM »
Sounder tool is ready for alpha testing...

It should be able to do (more or less) almost anything you can think of with sound formats of SCI1+, SCI0 and SC0-Early.
Few features are planned to be added in the near future (most interesting one IMO - ability to add digital sample from any file, like MP3).

It even has a Graphical User Interface (I still prefer the command line, but I know that many people disklike such things...)

The installer can be downloaded from
In order to access the command line just run 'sounder.exe --help'.

If anyone prefers without installer:
(the beginning of the file has notes how to set up a Conda environment with anything needed to run it)

Important notes:
  • This is really an Alpha version, it probably has bugs
  • I like to code, but hate to test, so, I haven't found those bugs
  • The good news - please report bugs that you found, and I will try to fix 'em
  • You can report here, or at (please prefix the issue with 'sounder')
  • If anyone wants to run in Linux, and needs help - just say
  • Feature requests, or any other comments, are also welcomed

I just discovered that with the installer the command line isn't working. I have an idea how to fix it. Meanwhile, in order to run the command line, use the Python file directly from GitHub, and not the installer.

CLI is working now, with a different shortcut pointing to a .bat file, with the exact path.

The SCI0 sound spec says:
The MT-32 always plays channel 9, the MIDI percussion channel, regardless of whether or not the channel is flagged for the device. Other MIDI devices may also do this.

Are we sure that it's true?

This can be demonstrated by SQ3, sound.073
The MT-32 doesn't report using channel 9, but this channel exists, and is used by ADLIB and FB01.

SCICompanion and SCI Resource Viewer report that MT-32 is not using channel 9, as the header supposedly says - but unlike that comment I quoted from spec.

Ravi's SCI0 Sound Resource Format seems to have a small typo:
The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.
Should be:
The fact that F8h waits F0h ticks makes me think that EFh is the largest technically allowable delta time.
The meaning of that value is F0h - 1, which is EFh, but can be easily mistaken for E9h.

Note: when I read this sentence (a few times...) it made perfectly sense for me. I only discovered it when some file failed with the assertion that I wrote that the value should be <= E9h.

Ravi's spec states for SCI0 early - Header (kq4, 1988 xmas card):
The lower 4 bits specify which drivers should react on that channel. Bit 0 set means AdLib shall react. Bit 1 set means PCjr shall react. MT32 will react on all channels. Bit 3 signals the control channel.
What does Bit 2 mean?
I think it's PC Speaker, because:
  • It should be there somewhere...
  • In a few files that I have checked, there was exactly one channel with Bit 2, which looks typical for the PC Speaker

Regarding "SCI0 Early" - it seems that both SCI Resource Viewer and SCICompanion have problems with it.
When loading sound.001 from Kings Quest 4 1.000.111 (attached), SCI Resource Viewer thinks that it supports the following devices:
MT32, FB01, Adlib, Casio, Tandy1000, PC Speaker and "7".
That list seems to be too long, according to the possible devices in the SCI0-early spec.

Furthermore, it reports that PC Speaker uses channels 1, 9, 11, 13, 15 and 16; which of course, doesn't make sense as well.

However, when this file is loaded with Sounder (, it reports only PC_JR, SPEAKER, MT_32 (and CONTROL CHANNEL); and the PC SPEAKER is using only channel 1.

So far I had the impression that SCI Resource Viewer is a perfect tool. It's interesting to find a bug in it, even if minor ;)

SCI Development Tools / SCI1 Sound Resource Format
« on: July 30, 2022, 04:51:32 PM »
I'm writing here a draft of SCI1 Sounder Resource Format description.
I will be more than happy to hear any comments, feedback, or pointing out mistakes.
Hopefully, later, I will write it in ScummVM wiki (just because I have writing permissions over there, and I think this should be documented. I'd be glad to have it other relevant Wikis as well).

The file starts with Sierra Sound magic number: 84h 00h. Those bytes aren't taken into account when calculating offsets, etc.

Then comes a header, which describes for each device (1) what channels it's using.
Each device starts with one byte, describing its type. This is SCICompanion's list:
Code: [Select]
Adlib, Sound Blaster ($00)
Amiga/Mac ($06)
General Midi ($07)
Unknown ($08)
Game Blaster ($09)
Unknown ($0b)
Roland MT-32, GM ($0c)
PC Speaker ($12)
Tandy 3v / IBM PS1 ($13)
I also encountered $16 (Eco Quest 1, at 185.snd).
If FFh is encountered, it means that there are no more devices, and the header ends immediately.
If F0h is encountered, it's called by ScummVM and SCICompanion "Digital track" (3); they both don't support it (according to the comments in the code). In that case, there are 6 bytes (first of them might be priority), then FFh.
Any other value means regular device, according to the devices type table.

For each device, after its type, comes the supported channels list.
Each supported channel starts with a byte that is either FFh, marking end of channels list (and end of device). Don't confuse end-of-channels FFh with end-of-devices FFh. If that byte is not FFh, its meaning is unknown.
The following byte has also unknown meaning.
Next 2 bytes are channel's data offset (from beginning of file [ignoring the magic id]).
Next 2 bytes are channel's data size.

That concludes the header.

The channel data referred to from the header is as following:
If the first byte is FEh, this is a digital channel, described later. Otherwise:
4 lower bits of that byte are channel number
4 higher bits of that byte are flags. According to SCICompanion's code:
Code: [Select]
                        // Flag 0x1:    Channel offset start is 0 instead of 10 (?) (haven't encountered this yet)
                        // Flag 0x2:    Prevent re-mapping (commonly set on 9)
                        // Flag 0x4:    Start muted (?)
, and channel 9 is treated as if flag 2 is set even if it's not.
Next byte, 4 lower bits are 'poly', and 4 higher bits are 'priority'. 4
All the following bytes until end of channel data (according to its size in header; note that this size includes the 2 previous bytes) are midi messages.

If the channel is digital, it start with the following header:
first byte is prio
next 2 bytes are frequency
next 2 bytes are sample length
next 2 bytes are offset from end of header
next 2 bytes are end of sample
then, after 'offset' bytes, comes the PCM sample itself.

Theoretically, this mechanism could allow each device to have completely different channels; i.e., ADLIB might use some "channel 1" which is different than MT-32's "channel 1". However, in practice it seems to not be the case in few files I have examined. Furthermore, SCICompanion has an assertion that if I understand correctly makes sure that if channel X is mentioned by device Y, it will be the same channel X when mentioned by device Z.
Therefore, my claim that it's better to call it "device" rather than "track", and that it's similar to SCI0 mechanism.

(1) SciCompanion and ScummVM code call it 'track'. I prefer to call it 'device' in order to use the same terminology used by SCI0 spec, and because I find it less confusing, as using the term 'track' suggests that it has something to do with 'MIDI track' (it doesn't), and it also suggests that it's a different concept than SCI0 'device' (it's not).
(2) I wander where is this list from? Decompilation? If so, why are there unknowns?
(3) I'm really curios where did this term comes from. And how come it's not supported, and no one seems to care?
(4) I have no idea what is their effect.

I'm working on my 'sounder' tool, and want to check my support for SCI1+ .snd digital channel.
(note, I'm talking about digital *channel*, not digital *track*, see

I've searched all of SQ6, and couldn't find one (or maybe I'm having some mistake in my search...)

If anyone can refer me to such sound file in some game, it'd be great.

We've started working on Hebrew translation of SQ6 (after completing SQ1, SQ3, and near completion of SQ5).
I found an interesting string, in (script 460), line 1880 (in my decompilation, it might vary of course):
   I DEDICATE THIS GAME TO MY LOVING WIFE, MICHELE, AND OUR WONDERFUL SON, SEAN.__I LOVE THEM BOTH VERY MUCH!\n\n________________________________LOVE,\n________________________________STEVE

I'm not sure what triggers this message, but it seems to be some very specific situation.

I wander if this was some "private easter egg", that only that Steve was aware of...
I guess it's Steve Conrad:,3106/

If anyone manages to understand how to trigger it in game, it'd be nice ;)

This topic has been mentioned here in few threads, and some information is at
I have made now some modifications to ScummVm's code (which will be probably available tomorrow at their daily builds).

The situation with my fixes should be (if I'm not mistaken ;) ):
  • The game's GameID in WinAGI is determined by the .com file's name, or `AGI` if it's ``
  • Once the game files are being changed, ScummVM fails to find the game in its detection table
  • ScummVM tries fallback detection, based on GameID's value in WinAGI
  • If it's a value that's known to ScummVM (ignoring case), it will be used
  • Otherwise, it will be `agi-fanmade`
  • ScummVM's `gameid` for each game can be seen in scummvm.ini, or at
  • Note that Space Quest 1 (for example) might have '' in some distributions, which will make its GameID in WinAGI to be 'SQ', while scummvm expects it to be 'sq1'. Just modify it in WinAGi

I assume that's enough for the translation work.
If something else is needed, or if I'm mistaken, please notify me.

AGI Development Tools / WinAGI: automatically setting gameid
« on: April 17, 2022, 05:38:30 AM » says:

According to AGK, WinAGI and AGI Studio are choosing the GameID based on the presence of the .COM game loader in the imported game folder. Usually it's, which sets the GameID to "AGI"

Suggestion - in case that's the .com loader is just, maybe the gameid can be set by checking the `"SQ");` command's value.

AGI Development Tools / WinAGI - "Invalid or Missing WinAGI file"
« on: April 17, 2022, 05:28:58 AM »
I've imported SQ1. 'Edit Game Properties' dialog popped up, and I modified GameID to `sq1`, saved, and exited. So far, no error message or warning.
Then I reopened WinAGI, and got an error: "Invalid or Missing WinAGI file", saying that sq1.wag file is invalid or missing, and removed from Most Recent Files list.

It's really not critical issue, as I can still manually load the wag file, but it seems like something needs to be fixed here.
(maybe change the .wag file name if the gameid is changed? or maybe fix the Most Recent Files list?)

AGI Development Tools / AGI extended character support
« on: April 02, 2022, 02:21:00 PM »
This topic was mentioned at, but it's off topic for that thread, and it already got many interesting topics, so I'm replying at a new thread...

AGKorson discussed what's possible with the original Sierra AGI interpreter, running on Dos/Dosbox.

However, with ScummVM we have more flexibility. Actually, I have translated PQ1 to Hebrew -

For instructions, please see
I admit that these instructions were phrased mainly as a reference for myself in the future, but I will gladly help if you want.

Also, maybe some minor modification need to be done to ScummVM to support AGI French, but I can do this as well.

I'm trying to understand the scripts' format (with the help of, and I don't understand the exports segment.

Let's take SQ1VGA, script 103.
ScummVM's debugger ("dissect_script 103"), says that its exports segment is:
Code: [Select]
Obj type #7, size 0xa: Exports
000004: 01 00 22 03  00 00                                   |.."...          |
According to the Wiki, it means that there is one exported function, at address 0x322.
But 0x322 is the middle of the Object 'rm103'. I expected it be something in a code block.

What's going on?

Pages: [1] 2 3 4

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.057 seconds with 17 queries.