ModdingWiki - User contributions [en-gb]

Eye of the Beholder

2025-10-30T06:37:41Z

The coder: Added reference for very comprehensive EOB file formats description

{{NeedMoreInfo}}
{{Game Infobox
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = Edit
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

'''Eye of the Beholder''' is a Dungeon & Dragons role-playing video game for computers and video game consoles developed by [[:Category:Westwood Studios|Westwood Studios]]. A party of 4 adventurers explores the dungeons under Waterdeep in the Forgotten Realms. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro.

There is a dedicated wiki for EOB file formats https://web.archive.org/web/20130923004015/http://eob.wikispaces.com/

{{BeginGameFileList}}{{GameFile
| Name = *.pak
| Format = [[PAK Format (Westwood)]]
| KnownFormat = Yes
| Desc = File archives
}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}
{{GameFile
| Name = *.cps, *.ega, *.cmp
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}
{{GameFile
| Name = *.pal, *.col
| Format = [[VGA_Palette#The_.22Classic.22_format|6-bit RGB 256-colour palette]]
| KnownFormat = Yes
| Desc = Palette
}}
{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}
{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}
{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Strings
}}
{{GameFile
| Name = *.dat, *.dec
| Format = [[Eye of the Beholder Decorations Format]]
| KnownFormat = Yes
| Desc = Items
}}
{{GameFile
| Name = *.fnt
| Format = [[Westwood Font Format v2]]
| KnownFormat = Yes
| Desc = Fonts
}}
{{GameFile
| Name = *.inf, *.dro, *.elo
| Format = [[Eye of the Beholder Maze Information Format]]
| KnownFormat = Yes
| Desc = Maps
}}
{{GameFile
| Name = *.maz
| Format = [[Eye of the Beholder Maze Format]]
| KnownFormat = Yes
| Desc = Maps
}}
{{GameFile
| Name = *.sav
| Format = [[Eye of the Beholder Save Game Format]]
| KnownFormat = Partial
| Desc = Save Game
}}
{{GameFile
| Name = *.vcn
| Format = [[Eye of the Beholder VCN Format]]
| KnownFormat = Yes
| Desc = Tileset (View Cone)
}}
{{GameFile
| Name = *.vmp
| Format = [[Eye of the Beholder VMP Format]]
| KnownFormat = Yes
| Desc = Maps (View Cone)
}}
{{EndGameFileList}}

[[Category:Westwood Studios]]
[[Category:3D dungeon]]

Secret Agent encryption

2024-07-12T12:54:37Z

The coder: typo fixed

Most [[Secret Agent]] data files are encrypted, but not compressed: an encrypted file has exactly the same size as its corresponding unencrypted file.

== Key ==

Encrypting and decrypting files for Secret Agent depend on a key. The key consists of the string "Copyright 1991 Peder Jungck" followed by a null-character. So the length of the key is 28 characters.

The first time the key is used (the first byte to decode), it is the ASCII code of the first character in the string. So, it will be 67 (because the 67th entry in the ASCII table is 'C'). The second time (for the second byte to decode) it is 111 ('o'), and so on. When all 28 characters are used, including the null-character, the key loops back to the beginning with 67 ('C').

The game appears to perform the decryption after reading in a particular amount of data, which means the key appears to reset (start again from 67/'C') at the boundaries of these data chunks. Thus when encrypting or decrypting a whole file in one go, the key must be reset after a particular number of bytes:

* Level files (<tt>SAM?03.GFX</tt>) - reset every 42 bytes. If the value 0 is used to decrypt the 42nd byte in a chunk (instead of the expected character '1') the last two bytes of the chunk will form a newline (0x0D0A), making the resulting file easier to read in a text editor. While this won't produce the exact original file, it is harmless as the game only uses the first 40 bytes of each chunk in a level file.
* 8×8 sprite files (<tt>SAM?02.GFX</tt>) - reset every 2048 bytes
* 16×16 sprite files (<tt>SAM?01.GFX</tt>) - reset every 8064 bytes

== Decryption ==

For all bytes in a file, do:

# Read a byte.
# Swap the order of the bits in the byte. For example, 00000001 becomes 10000000, and 10110000 becomes 00001101.
# XOR this turned-around-byte with the next key-value.
# Return the result

== Encryption ==

Encryption is the reverse of decryption. So, after reading a byte, XOR it with the next key-value and then turn the bits around.

== Credits ==

This encryption was reverse engineered by [[User:Frenkel|Frenkel]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Secret Agent]]
[[Category:Encryption algorithms]]

EXE Format

2021-01-23T09:14:18Z

The coder:

{{Executable Infobox
| Interpreted = N
| Platform = MS-DOS
| Code = 16-bit x86
| Hidden = Y
}}
The '''EXE format''' is used by all but the smallest DOS games to store the machine code instructions for running the game itself.

== File format ==

=== Signature ===

The first two characters of the file are "MZ". The following values (see below) will indicate the size of the .exe file, however this should not be relied upon because it is not uncommon for additional data to be appended onto the end of the .exe. The other header fields can however be inspected to ensure the values are sensible, particularly the ones about memory requirements which will never ask for more than 640 kB of memory, otherwise the file would not run on the majority of DOS machines.

=== Header ===

{|class="wikitable"
! Data type !! Name || Description
|-
| [[char]] || signature[2] || "MZ"
|-
| [[UINT16LE]] || lenFinal || Size of final block in the file, or <tt>0</tt> if the final block is a full 512 bytes.
|-
| [[UINT16LE]] || numBlocks || Number of 512-byte blocks in the file, including the final block which may not be the full 512 bytes.
|-
| [[UINT16LE]] || numReloc || Number of entries in the relocation table.
|-
| [[UINT16LE]] || pgHeader || Number of 16-byte blocks (paragraphs) in the file header, including the "MZ" and up until the machine code starts.
|-
| [[UINT16LE]] || pgMemExtra || Number of 16-byte paragraphs of extra memory that must be allocated for the program to run.
|-
| [[UINT16LE]] || pgMemMax || If the program doesn't need all available memory, this value can limit it to a smaller number of paragraphs.
|-
| [[INT16LE]] || segSS || Stack segment offset. This value is added to the load segment and set as the stack segment (<tt>SS</tt> register).
|-
| [[UINT16LE]] || regSP || Initial value of the <tt>SP</tt> (stack pointer/index into stack) register. The stack is located at the segment:offset <tt>SS:SP</tt>.
|-
| [[UINT16LE]] || checknum || Usually ignored and set to zero. Supposedly if all UINT16LE values in the file are summed they should equal zero, and this value can be tweaked to ensure that is the case.
|-
| [[UINT16LE]] || regIP || Initial value of the <tt>IP</tt> (instruction pointer) register, where execution will actually begin. This is normally 0x100 as DOS writes some information (the PSP) between memory offsets 0 and 0x100. This means the first 0x100 bytes of the file are usually 0x00 bytes to avoid code getting overwritten, however to avoid wasting this space in the .exe files, some programs set <tt>regCS</tt> to -16 which will cause everything to be shifted back by 0x100 bytes. This means the code gets loaded at offset 0, then before it gets overwritten with the PSP <tt>regCS</tt> is applied, changing the segment and making the code visible at offset 0x100 instead. Thus the PSP can be written to memory before the code and execution begins at offset 0x100, without needing 0x100 bytes of zeroes at the start of the machine code.
|-
| [[INT16LE]] || regCS || Offset for the <tt>CS</tt> (code segment) register relative to the segment the code was loaded in. Execution begins at <tt>CS:IP</tt> so a value of <tt>1</tt> would skip the first 16 bytes of code that follows the .exe header. May be negative.
|-
| [[UINT16LE]] || offReloc || Offset of the first entry in the relocation table, relative to the start of the .exe file. Increasing this value allows more data to be stored in the .exe header. [[PKLite]] for example uses it to store a copyright message.
|-
| [[UINT16LE]] || overlayIndex || Overlay number, or zero for the main .exe file. Rarely used.
|}

Additional data can appear in the header until <tt>offReloc</tt> is reached where the relocation table begins.

=== Relocation table ===

The relocation table consists of a number of four-byte entries. Beginning at offset <tt>offReloc</tt> from the start of the file and continuing until <tt>numReloc</tt> four-byte entries have been read.

Additional data can appear after the relocation table, until offset <tt>pgHeader * 16</tt> where the machine code begins.

{{TODO|Explain how the relocation table works}}

=== Machine code ===

The actual machine code that runs begins at the end of the .exe header (file offset <tt>pgHeader * 16</tt>) and continues until the last (possibly partial) block has been read. This can be calculated like so:

lenCode = numBlocks * 512
if (lenFinal != 0) {
// Last block is not 512 but less than this, so adjust it.
lenCode = lenCode - 512
lenCode = lenCode + lenFinal
}

After this point it is possible for more data to be stored in the .exe, but it will not be loaded into memory by DOS and is essentially ignored. Some games use this to store extra game data in their main .exe, opening their own .exe file at runtime to read out the extra data. These can often be spotted by the fact that the .exe file is much larger than one that will typically fit into memory.

To calculate the offset of this extra data, find the beginning of the code (<tt>pgHeader * 16</tt>) and add the size of the code (<tt>lenCode</tt> above). This will be the offset of the trailing data, or if there is none, it will match the size of the .exe file itself.

== Compression ==

A few schemes exist to compress .exe files while still leaving them executable. These work by compressing the original code and inserting a small decompression routine at the start of the data. When DOS loads the .exe into memory, it ends up running the decompression routine instead of the original code. This routine expands the compressed data and then passes control to it so the program appears to work as normal. The trick with this process is figuring out how to decompress the data while using as little extra memory as possible, as most .exe files take up large amounts of memory and there is typically not enough memory to store both the compressed and decompressed code at the same time. So the decompressor must carefully expand the data such that it overwrites only the compressed data that has already been decompressed and is no longer needed.

Typically the .exe file headers are set up such that DOS will load both the decompression routine and the compressed code into memory at the same time, so the decompressor does not have to worry about opening and reading files.

The individual compression schemes are documented on their own pages, but they refer back to the .exe headers described here. There are many more schemes than listed here as this list only includes those used by games documented on this wiki.

* [[LZEXE]]
* [[PKLite]]

== Successors ==

The .exe format has been extended to add functionality and to work on other platforms:

* [[New Executable (NE) Format]] was introduced with 16-bit Windows.
* [[Linear Executable (LX/LE) Format]] adds 32-bit support and was used by many DOS games from the late 1990s running in protected mode (DOS4GW).
* [[Portable Executable (PE) Format]] was introduced with 32-bit Windows.

Most of these extensions are backwards compatible in that a small "MZ" stub is included that prints an error if the file is run on a platform that does not support the extensions.

== Tools ==

{{BeginFileFormatTools|Type=exe}}
{{FileFormatTool
| Name = MS-DOS debug.exe
| Platform = MS-DOS
| canView = Yes
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = No
| editHidden = Yes
| notes = Loads into correct offsets, disassemble with "u" command.
}}
{{FileFormatTool
| Name = [[LZEXE]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = Yes, LZEXE
| canDecompress = No
| editHidden = No
}}
{{FileFormatTool
| Name = [[PKLite]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = Yes, PKLite
| canDecompress = Yes, PKLite
| editHidden = No
}}
{{FileFormatTool
| Name = [[LZEXE|UNLZEXE]]
| Platform = MS-DOS
| canView = No
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = Yes, LZEXE
| editHidden = No
}}
{{FileFormatTool
| Name = [https://github.com/devbrain/mz-explode/ mz-explode]
| Platform = Portable
| canView = No
| canCreate = No
| canModify = No
| canCompress = No
| canDecompress = Yes, [[LZEXE|LZEXE]], [[PKLite|PKLite]], [[Knowledge Dynamics LZW COMPRESSOR|KNOWLEDGE DYNAMICS]], [[Microsoft EXEPACK|EXEPACK]]
| editHidden = No
| notes = C++ library
}}
{{EndFileFormatTools}}

== Credits ==

The .exe structure was taken from the [http://www.delorie.com/djgpp/doc/exe/ DJGPP documentation]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Stargunner Sprites Format

2020-05-30T16:31:31Z

The coder: Created page with "{{Tileset Infobox | ImageNativeWidth = Y | Hardware1 = VGA | MaxTiles = 65535 | Palette = External | Names = N | TileMaxSize = 65535×65535 | NumPlanes = 1 | Plan..."

{{Tileset Infobox
| ImageNativeWidth = Y
| Hardware1 = VGA
| MaxTiles = 65535
| Palette = External
| Names = N
| TileMaxSize = 65535×65535
| NumPlanes = 1
| PlaneArrangement = Linear
| HasTransparency = N
| HasHitmap = Unknown
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Games =
{{Game|Stargunner}}
}}
The '''Stargunner Sprites Format''' is used by [[Stargunner]] to store the graphics used to draw various objects.

== Signature ==

There is no signature, but careful parsing of the fields to ensure they have expected values can allow files to be detected. There is no data trailing the <tt>pixelData</tt> field, so if this field ends right at the end of the file, it is highly probable the file is in this format.

== File format ==
The file begins with short header, followed by index table and raw pixels data

=== Header ===
{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || DWORD1 || Unknown. same as NUM
|-
| [[UINT32LE]] || PAYLOAD || Length of pixel data
|-
| [[UINT32LE]] || NUM || Number of sprites in this file
|}

=== Sprite descriptors ===
Just after the header there are NUM of sprite descriptors. Every sprite descriptor is 40 bytes long
{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || INDEX || Index number of this sprite
|-
| [[UINT32LE]] || W || Width of this sprite in pixels (only low 16 bits are set)
|-
| [[UINT32LE]] || H || Height of this sprite in pixels (only low 16 bits are set)
|-
| [[INT32LE]] || UNK1 || Unknown - roughly is W/2
|-
| [[INT32LE]] || UNK2 || Unknown - roughly is H/2
|-
| [[INT32LE]] || UNK3 || Unknown - may be negative
|-
| [[INT32LE]] || UNK4 || Unknown
|-
| [[UINT32LE]] || OFFSET1 || Offset to the data in the payload area
|-
| [[UINT32LE]] || OFFSET2 || Unknown
|-
| [[UINT32LE]] || OFFSET3 || Unknown
|}

=== Payload area ===
Just after the end of the sprite descriptors is the payload area. It starts at 3*sizeof(UINT32) + 40*NUM from the beginning of the file. Every offset in the sprite descriptor is relative to the payload area.
Sprites are stored as 8-bit play VGA image of W*H size

Stargunner

2020-05-30T16:15:09Z

The coder:

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

== File formats ==
Most of the data files for Stargunner are stored in <tt>STARGUN.DLT</tt>, which is an archive file containing a number of other files. For the file format of <tt>STARGUN.DLT</tt> itself, see [[DLT Format]].

=== Files in <tt>STARGUN.DLT</tt> ===

{{BeginGameFileList}}
{{GameFile
| Name = *.anm
| Format = [[ANM Format (Stargunner)]]
| KnownFormat = Partial
| Desc = Definition of animation groups
}}
{{GameFile
| Name = *.ctl
| Format = Plain text
| KnownFormat = Yes
| Desc = In game texts
}}
{{GameFile
| Name = *.dfs
| Format = INI file
| KnownFormat = Yes
| Desc = Definition of music and timings for animation cutscenes
}}
{{GameFile
| Name = *.evt
| Format =
| KnownFormat = No
| Desc = Events script?
}}
{{GameFile
| Name = *.flc
| Format = [http://woodshole.er.usgs.gov/operations/modeling/flc.html FLIC format]
| KnownFormat = Yes
| Desc = Cutscene animations
}}
{{GameFile
| Name = *.mod
| Format = [[https://en.wikipedia.org/wiki/Module_file MOD Format]]
| KnownFormat = Yes
| Desc = Background music
}}
{{GameFile
| Name = *.mpr
| Format =
| KnownFormat = No
| Desc = Level maps?
}}
{{GameFile
| Name = *.pal
| Format = 6-bit classic [[VGA Palette]]
| KnownFormat = Yes
| Desc = VGA palette file
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = Full screen image
}}
{{GameFile
| Name = *.pts
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.rec
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.seq
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.smp
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.spd
| Format = [[Stargunner Sprites Format]]
| KnownFormat = Partial
| Desc = Sprite sheets
}}
{{GameFile
| Name = *.tld
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.tlr
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.wav
| Format = [https://en.wikipedia.org/wiki/WAV Microsoft RIFF wave files]
| KnownFormat = Yes
| Desc = Sound
}}
{{GameFile
| Name = *.xlt
| Format =
| KnownFormat = Yes
| Desc = Sound
}}
{{EndGameFileList}}

In the official release these files are all compressed when stored inside the DLT file. Each compressed file begins with the string "PGBP", however if this signature is missing the game will use the data as is, without attempting to decompress it first. Thus it is possible to replace files with uncompressed versions and the game will still work correctly.

* The game does NOT check for the existence of files in the current directory, they must be inside the DLT to be seen.
* If a file is removed (or renamed) inside the DLT, the game will still refuse to check the current directory and appears to continue somewhat unpredictably, as if the file was loaded successfully even though it wasn't.
* If the DLT file is missing, the game will still not look for files in the current directory, and will complain about the absent DLT file being the wrong version.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = No decompression
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows
| grp = View
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

[[Category:Apogee]]
[[Category:Sidescroller]]
[[Category:Space Invaders]]

Stargunner

2020-05-17T07:18:51Z

The coder: Refactoring

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

== File formats ==
Most of the data files for Stargunner are stored in <tt>STARGUN.DLT</tt>, which is an archive file containing a number of other files. For the file format of <tt>STARGUN.DLT</tt> itself, see [[DLT Format]].

=== Files in <tt>STARGUN.DLT</tt> ===

{{BeginGameFileList}}
{{GameFile
| Name = *.anm
| Format = [[ANM Format (Stargunner)]]
| KnownFormat = Partial
| Desc = Definition of animation groups
}}
{{GameFile
| Name = *.ctl
| Format = Plain text
| KnownFormat = Yes
| Desc = In game texts
}}
{{GameFile
| Name = *.dfs
| Format = INI file
| KnownFormat = Yes
| Desc = Definition of music and timings for animation cutscenes
}}
{{GameFile
| Name = *.evt
| Format =
| KnownFormat = No
| Desc = Events script?
}}
{{GameFile
| Name = *.flc
| Format = [http://woodshole.er.usgs.gov/operations/modeling/flc.html FLIC format]
| KnownFormat = Yes
| Desc = Cutscene animations
}}
{{GameFile
| Name = *.mod
| Format = [[https://en.wikipedia.org/wiki/Module_file MOD Format]]
| KnownFormat = Yes
| Desc = Background music
}}
{{GameFile
| Name = *.mpr
| Format =
| KnownFormat = No
| Desc = Level maps?
}}
{{GameFile
| Name = *.pal
| Format = 6-bit classic [[VGA Palette]]
| KnownFormat = Yes
| Desc = VGA palette file
}}
{{GameFile
| Name = *.pcx
| Format = [[PCX Format]]
| KnownFormat = Yes
| Desc = Full screen image
}}
{{GameFile
| Name = *.pts
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.rec
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.seq
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.smp
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.spd
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.tld
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.tlr
| Format =
| KnownFormat = No
| Desc =
}}
{{GameFile
| Name = *.wav
| Format = [https://en.wikipedia.org/wiki/WAV Microsoft RIFF wave files]
| KnownFormat = Yes
| Desc = Sound
}}
{{GameFile
| Name = *.xlt
| Format =
| KnownFormat = Yes
| Desc = Sound
}}
{{EndGameFileList}}

In the official release these files are all compressed when stored inside the DLT file. Each compressed file begins with the string "PGBP", however if this signature is missing the game will use the data as is, without attempting to decompress it first. Thus it is possible to replace files with uncompressed versions and the game will still work correctly.

* The game does NOT check for the existence of files in the current directory, they must be inside the DLT to be seen.
* If a file is removed (or renamed) inside the DLT, the game will still refuse to check the current directory and appears to continue somewhat unpredictably, as if the file was loaded successfully even though it wasn't.
* If the DLT file is missing, the game will still not look for files in the current directory, and will complain about the absent DLT file being the wrong version.

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = No decompression
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [[Wombat]]
| Platform = Windows
| grp = View
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

[[Category:Apogee]]
[[Category:Sidescroller]]
[[Category:Space Invaders]]

Terminal Velocity

2018-10-14T09:01:34Z

The coder: link fixed

{{Stub}}
{{Game Infobox
| Levels = Edit
| Tiles = Edit
| Sprites = Edit
| Fullscreen = No
| Sound = Edit
| Music = Edit
| Text = Edit
| Story = Edit
| Interface = No
}}

[[Terminal Velocity]] is a first-person aerial shooter. The later Fury3 engine is backwards compatible enough that it can run Terminal Velocity without modification.

== File formats ==

This section lists the major file formats used in the game.

All text files are in DOS format (CRLF line endings).

* [[POD Format]] - group file storing most of the game data.
* [[WAV Format]] - The RemoteRidicule and other game sounds are stored in .WAV files.
* [[VOX Format (Terminal Velocity)|VOX Format]] - The level order seems to be stored in these files, as well as the audio config file <tt>VOX.INI</tt>.
* [[INI Format]] - Used for POD mounting and configuration. The file <tt>POD.INI</tt> starts with a number specifying the number of PODs to mount, subsequent lines are the file names of the PODs to load. The configuration file <tt>SETUP.CFG</tt> seems to be in standard .INI format.

=== POD files ===

The POD files contain a number of other data files:

{|class="wikitable"
! Filename !! Purpose !! Format
|-
| art\*.raw || Textures || 64x64 8bpp images (no header)
|-
| art\*.act || Palettes || 6-bit [[VGA Palette]]
|-
| data\*.clr || unknown || 256x256 8bpp image (no header)
|-
| data\*.def || unknown || ASCII text
|-
| data\*.nav || Waypoints || ASCII text, first line is number of waypoints
|-
| data\*.raw || Level heightmap || 256x256 8bpp image (no header)
|-
| data\*.tdf || unknown || ASCII text
|-
| data\*.tex || List of textures || ASCII text, one filename per line, first line is decimal texture count
|-
| data\*.txt || Level introduction/story || ASCII text, first line is model to show, second line is texture to render it with, rest of file is shown in story window
|-
| levels\*.lvl || Level info || ASCII text (which files to use for this level)
|-
| music\*.mod || Music || Six-channel [[MOD Format]]
|-
| sound\*.wav || Sound effects || [[WAV Format]]
|}

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = Edit
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://mtm2.com/~mtmg/cpod/about.shtml C-POD]
| Platform = Windows GUI
| grp = Edit
| map = No
| gfx = Edit
| mus = Edit
| sfx = Edit
| txt = Edit
| sav = No
| exe = No
}}
{{FileFormatTool
| Name = [http://www.wolfensteingoodies.com/archives/geocities/TimesSquare/8271/index.html GFE (Game File Explorer)]
| Platform = Windows GUI
| grp = Edit
| map = Export
| gfx = Export
| mus = Export
| sfx = Export
| txt = Export
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

== See also ==

* Lots of information on the [https://web.archive.org/web/20160729125600/http://rewiki.regengedanken.de:80/wiki/Terminal_Velocity REwiki Terminal Velocity] page

[[Category:3DRealms]]
[[Category:3D]]
[[Category:Flight Sim]]
[[Category:First-Person Shooter]]

MID Format

2015-01-28T11:52:47Z

The coder: /* External links */

{{Music Infobox
| Type = MIDI
| Instruments = MIDI
| NumChannels = 16
| NumTracks = 65535
| Game1 = Blood
| Game2 = Boppin'
| Game3 = Duke Nukem 3D
| Game4 = Hi Octane
| Game5 = Hocus Pocus
| Game6 = Magic Pockets
| Game7 = Prince of Persia
| Game8 = Rise of the Triad
| Game9 = Sango Fighter
| Game10 = Shadow Warrior
| Game11 = SimCity 2000
| Game12 = Wacky Wheels
| Game13 = Where In the World Is Carmen Sandiego?
}}
The Musical Instrument Digital Interface (MIDI) file format is used for storing the notes required to accurately reproduce a song. Commercial instruments are available that "speak" the MIDI protocol, and a MIDI file (.mid) simply stores the data sent over the wire, with a few headers on the front.

== File format ==

A MIDI file starts with an overall ''MThd'' header, followed by one or more ''MTrk'' headers for each "track" (a track is normally created for each instrument, for simplicity when the song is being composed.)

=== MThd Header ===
The file begins with a header:

{|class="wikitable"
!Data type!!Name!!Description
|-
|BYTE[4]||cSignature||"MThd" (not NULL-terminated)
|-
|UINT32BE||iLength||Length of MThd block (usually 6)
|-
|UINT16BE||iType||0, 1 or 2 (for format-0, 1 or 2)
|-
|UINT16BE||iNumTracks||Number of tracks (will be 1 for format-0)
|-
|UINT16BE||iTicksPerQuarterNote||Number of MIDI delay ticks in a quarter-note
|}

If the high bit in <tt>iTicksPerQuarterNote</tt> is set (0x8000) then the file uses SMPTE timing instead, which is rare and not covered here.

=== MTrk block ===

The ''MTrk'' block is repeated once for each track in the song (the '''iNumTracks''' field in the MThd header.)

{|class="wikitable"
!Data type!!Name!!Description
|-
|BYTE[4]||cSignature||"MTrk" (not NULL-terminated)
|-
|UINT32BE||iLength||Length of block
|-
|BYTE[iLength]||cData||MIDI data
|}

=== MIDI data ===

The MIDI data consists of a delay value (in MIDI variable-length integer notation), followed by a MIDI event byte (see [[#MIDI events]] below.) The event data follows, and will be different depending on the event. It then starts again with the delay value for the next event.

==== MIDI lengths ====

MIDI lengths are stored as variable length integers, between one and four bytes long. Each byte only uses the lower 7-bits, with the MSB set if there is another length byte following. The bytes are in big endian order. Some examples of these length bytes are:

50 // Hex value 0x50
81 50 // Hex value 0xD0 ((0x81 & 0x7F) >> 1) | (0x50 & 0x7F)

Here is some C code to read these values:

<source lang="c">
const char *midi_data = "\x81\x50";
unsigned long val = 0;

for (int i = 0; i < 4; i++) {

// Include the lower 7-bits of this byte into the value
val |= midi_data[i] & 0x7F;

// If the high bit is set, shift the value up
// seven bits to make room for the next value
if (midi_data[i] & 0x80) val <<= 7;
else break; // High bit unset means end of value
}

printf("Value is %lu\n", val);
</source>

Generally speaking, MIDI data that can be sent over the wire uses these values (e.g. delays), whereas data only used to write .mid files on disk (e.g. MTrk lengths in bytes) use normal big-endian fixed-length values.

==== MIDI events ====

This table lists the different MIDI events that can occur in a song. The events are listed as channel zero (e.g. 0x80, which would become 0x85 for channel five.) Removing the high bit (<code>(byte & 0x7F) >> 4</code>) will give the 'event number'.

{|class="wikitable"
!Register value!!Event number!!Data size!!Purpose
|-
|0x80||0||2||Note off
|-
|0x90||1||2||Note on
|-
|0xA0||2||2||Polyphonic key pressure
|-
|0xB0||3||2||Controller
|-
|0xC0||4||1||Instrument change
|-
|0xD0||5||1||Channel pressure
|-
|0xE0||6||2||Pitch bend
|-
|0xF0||7||Any||Sysex
|-
|0xFF||N/A||Any||Meta-event
|}

The data bytes for each event are described in the sections below.

Each event is preceded by a delay (as a MIDILEN variable-length integer, see [[#MIDI lengths]] above) which specifies the number of MIDI ticks until the event should be actioned.

To convert the number of MIDI ticks into a usable time value, the <tt>iTicksPerQuarterNote</tt> field from the header will allow the tick count to be converted into a fractional number of quarter notes, then the song's tempo (in microseconds per quarter note) will allow this fractional number of quarter notes to be converted into microseconds.

The default tempo of 500,000 microseconds per quarter note applies until overridden by a [[#0x51: Set tempo|set-tempo]] event.

===== Running-status =====

Any event values without the high-bit set (i.e. less than 0x80) are so-called "running status" values. If one of these bytes is encountered as a MIDI event, it is actually the first data byte of the event instead. The actual event is the same as the previous one. For example, these two lines are equivalent: (delay bytes omitted for clarity)

90 40 7F 91 44 7F 91 47 7F 81 44 7F (full syntax)
90 40 7F 91 44 7F 47 7F 44 00 (with running status)

This means:
* 90 40 7F: Turn note 0x40 on channel 0 at maximum velocity
* 91 44 7F: Then turn note 0x44 on channel 1 at maximum velocity
* 47 7F: Turn note 0x47 on the same channel (running status means use event 0x91 from before)
* 44 00: Turn note 0x44 off on the same channel (running status uses event 0x91 again, and takes advantage of note-on at zero velocity being the same as note-off)

Meta-events do not affect running status, so any event from 0xF0 to 0xFF can appear in the middle of data without affecting the running status. For example the following line is equivalent to the two lines above:

90 40 7F 91 44 7F FF 01 02 AA BB 47 7F F0 02 AA F7 44 00

===== 0x80: Note off =====
Stops the specified note from sounding on this channel. Does not affect any other notes currently being played on the same channel. A note-on event with a velocity of zero is the same as a note-off event.
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iNote||MIDI note number to key-off (0-127)
|-
|UINT8 iVelocity||How hard to release the note (0-127)
|}

===== 0x90: Note on =====
Plays the specified note on the given channel. Multiple notes can be sounding at the same time on the same channel. A velocity of zero is the same as a note-off event (this is often used with running status to minimise the amount of data used.)
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iNote||MIDI note number to key-on (0-127)
|-
|UINT8 iVelocity||How hard to press the note (0-127)
|}

===== 0xA0: Polyphonic key pressure =====
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iPressure||Pressure value (0-127)
|-
|UINT8 iNote||MIDI note number to affect (0-127)
|}

===== 0xB0: Controller =====
Set a MIDI controller to the specified value. TODO: List of standard controllers
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iController||Controller index (0-127)
|-
|UINT8 iValue||Value to set (0-127)
|}

===== 0xC0: Instrument change =====
Set the channel to the specified instrument.
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iInstrument||Instrument number (0-127)
|}

===== 0xD0: Channel pressure =====
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iPressure||Pressure value (0-127)
|}

===== 0xE0: Pitch bend =====
Bend all notes on the channel up or down by the specified amount. The value is between 0 and 16384. The value 8192 is in the middle and means no bend, thus 8192 can be subtracted from this the value to create a signed integer between -8192 and +8191, with zero meaning "no bend." The actual pitch resulting from the bend depends on the range, which is set (usually at the start of the song) by a MIDI controller message.
{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iLSB||Least significant byte (0-127)
|-
|UINT8 iMSB||Most significant byte (0-127)
|}

The value is calculated by combining the lower seven bits from each of the two bytes into a single 14-bit value: <code>value = (iMSB << 7) | iLSB</code>

===== 0xF0: System exclusive =====
These messages are used to send proprietary commands to various MIDI devices. They are essentially a list of raw bytes to send. The channel is not used, so 0xF0 through 0xFF are different "sysex" messages. Since 0xFF is used as a reset it would have no use in a .mid file on disk, so this event is used for meta-events described below.

The event type (0xF0 to 0xFE) is followed by this structure:

{|class="wikitable"
!Data bytes!!Purpose
|-
|MIDILEN iLength||Length of data
|-
|UINT8 cData[iLength]||Block of data, iLength bytes long
|}

Event 0xFF has a different structure and is covered below. The event types are defined as follows:

{|class="wikitable"
!Event type!!Purpose
|-
|0xF0||Start system exclusive event
|-
|0xF1||MIDI time code
|-
|0xF2||Song position pointer
|-
|0xF3||Song select
|-
|0xF4||(Unused)
|-
|0xF5||(Unused)
|-
|0xF6||Tune request
|-
|0xF7||End system exclusive event (EOX)
|-
|0xF8||Timing clock
|-
|0xF9||(Unused)
|-
|0xFA||Start playback
|-
|0xFB||Continue playback
|-
|0xFC||Stop playback
|-
|0xFD||(Unused)
|-
|0xFE||Active sensing
|-
|0xFF||System reset (used for meta-event in a MIDI file)
|}

==== Meta events ====

Meta events are events specific to MIDI files themselves. They are not transmitted to MIDI devices. A meta event is signalled by the 0xFF system exclusive event. The following table lists the format of the bytes following the 0xFF.

{|class="wikitable"
!Data bytes!!Purpose
|-
|UINT8 iType||Meta-event type
|-
|MIDILEN iLength||Length of event data
|-
|UINT8 cData[iLength]||Event data
|}

The following section lists the meaning of various values of <tt>iType</tt>.

===== 0x01 - 0x0F: Text =====
These events set various types of text. The event data is the text to set.

{|class="wikitable"
!Event type!!Text use
|-
|0x01||Generic text event. Often the first text event in a song is used as its title.
|-
|0x02||Copyright notice
|-
|0x03||Track name. Often the first event (format-0) or the first track (format-1) is the song title.
|-
|0x04||Instrument name
|-
|0x05||Lyric
|-
|0x06||Marker
|-
|0x07||Cue point (e.g. stage instructions)
|}

===== 0x2F: End of track =====
Mandatory event at the end of each MTrk track. The length field is always zero, so there are no bytes of event data.

===== 0x51: Set tempo =====
This event should always have a length of three. The event data is a big-endian integer ('''not''' in MIDI variable-length notation) indicating the number of microseconds in a quarter note. Together with the <tt>iTicksPerQuarterNote</tt> value from the header, this allows MIDI ticks to be converted into microseconds for correct playback speed of the MIDI file.

Unless overridden by this event, the number of microseconds in a quarter note defaults to 500,000.

===== 0x7F: Manufacturer-specific =====
The first data byte of this event is a manufacturer ID. If it is 0x00, then the following [[UINT16BE]] is the actual manufacturer ID. This means either one or three bytes total will be read to obtain the manufacturer ID.

If the manufacturer ID is 0x3F then it is an Ad Lib, Inc. event, and the file format is technically <tt>.mdi</tt> (an Ad Lib MIDI file with embedded OPL instruments.) In this case, read another UINT16BE to obtain the opcode, then the data following the opcode is arranged as:

{|class="wikitable"
! Opcode !! Purpose !! Description
|-
| 1 || Instrument change || 29 data bytes follow:<table class="wikitable">
<tr><th>Type</th><th>Name</th><th>Description</th></tr>
<tr><td>[[UINT8]]</td><td>voice</td><td>MIDI channel number to assign instrument to</td></tr>
<tr><td>BNK_ENTRY</td><td>patch</td><td>OPL register settings</td></tr>
</table>
|-
| 2 || Sound mode || One data byte. 0=melodic/rhythm-off, 1=percussive/rhythm-on
|-
| 3 || Pitch bend range || One data byte, value in range 1-12 inclusive. {{TODO|Explain how this works}}
|}

<tt>BNK_ENTRY</tt> is defined as follows: (note this is identical to the layout of an instrument inside a [[AdLib Instrument Bank Format]] .bnk file. See that article for the explanation of the <tt>OPLREGS</tt> structure.)

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[AdLib Instrument Bank Format|OPLREGS]] || oplModulator || Register values for the Modulator operator (op 0)
|-
| [[AdLib Instrument Bank Format|OPLREGS]] || oplCarrier || Register values for the Carrier operator (op 1)
|-
| [[UINT8]] || iModWaveSel || Modulator wave select (OPL base register 0xE0)
|-
| [[UINT8]] || iCarWaveSel || Carrier wave select (OPL base register 0xE0)
|}

===== Additional meta-events =====

Other meta-events (not so important for playing back game music) are listed on various web sites:

* http://www.omega-art.com/midi/mfiles.html#meta

== Tools ==
* [[DRO2MIDI]] - converts .dro files into [[MID Format|.mid files]]

== Similar formats ==
* [[CMF Format|CMF files]] store their song data in MIDI format.
* [[MUS Format|MUS files]] are single-track MIDI files made by id Software.
* [[XMI Format|XMI files]] are Extended MIDI files.

== External links ==
* https://web.archive.org/web/20070104033706/http://www.cybermuff.cz/music/MIDIspec.htm - great reference for the MIDI spec

[[Category:Build engine]]

OPL chip

2015-01-28T11:48:57Z

The coder: /* References */

= Programmer's Guide to Yamaha YMF 262/OPL3 FM Music Synthesizer =
Version 1.00 Nov-24-1994

Written by Vladimir Arnost, QA-Software
Internet: xarnos00@dcse.fee.vutbr.cz

This manual can be distributed freely if not modified.

=== Disclaimer ===

I assume no responsibility for any damages arising out of use or inability to use this text. No warranty is provided about correctness of any information in this file. You are on your own.

== Introduction ==

The chip I am going to describe is getting more and more common, but programming information is still scarce, so I have decided to fill in this gap. All information contained in this file is a result of my experience in Adlib programming, research (read: reverse engineering) and finally of my effort to write down everything necessary to understand and use this piece of hardware. No official sources (i.e. development kits, books about this topic, etc.) were available to me except:

: Adlib Programming Guide - by Tero Töttö, and
: The PC Games Programmers Encyclopedia V1.0

The information below is a combination of known features of Adlib (alias Yamaha YM 3812/OPL2) and my own uncountable experiments and failures, which brought out a lot of important details you have to know about the chip.

As far as I know, there are four major sound cards based on OPL3 chip:

* Sound Blaster Pro II (not Sound Blaster Pro I)
* Sound Blaster 16
* Adlib Gold
* Pro Audio Spectrum Plus/16

I currently have a Sound Blaster Pro II-compatible card only, so all the programming info I provide will be based on this card. (The other cards are quite similar, however. They are just wired at different I/O-port addresses.)

Note: I assume some knowledge of FM music programming (mainly Adlib FM synthesizer) in this manual. If you are new to this topic I recommend you try Adlib first before going higher. Anyway, OPL3 is a direct descendant of OPL2 (what a surprise), so most features of OPL2 are also present on OPL3.

== Description of the Synthesizer ==

My card's user manual says: "[this card contains] ... a stereo music FM synthesizer with 20 channels consisting of four (4) operators each ... " I thought: "Wow -- that's together eighty operators. This must be a GOOD sound-card." I was wrong. Just another advertising lie.

So let's clear some facts. First, OPL3 has only thirty-six (36) operators which can be combined in several ways:

* 18 FM channels (36 operators), or
* 15 FM channels (30 ops) and 5 percussion instruments (6 ops), giving us 20 channels altogether, or
* up to 6 four-operator FM channels (max 24 ops), the rest again being divided into two-operator FM channels and drums.

From the table above you can see that not all channels can be used in four-operator (4-OP) mode -- only a part of the synthesizer is really capable of making 4-OP sounds -- the rest uses traditional two-operator (2-OP) mode.

Second, the manual states this card is capable of "stereo" music. Yes, the quotes are necessary, because the stereo capabilities are very limited. You are given ability to control output going to left or right channel by turning it on and off. That's all. So the sound can flow from very left side, center and very right side. No sound panning, no special stereo effects. :-(

Well, flaming apart, back to the main topic.

The OPL3 chip is capable of making sounds in several ways:

=== Two-operator Additive Synthesis ===

Output of both operators is simply added. It is the simplest way to make any sound, and it works on both OPL2 and OPL3. The diagram should make it clear.

<pre>
┌────────────┐
│ │
│ Operator 1 ├────────┐
│ │ │
└────────────┘ │
├────────> Output
┌────────────┐ │
│ │ │
│ Operator 2 ├────────┘
│ │
└────────────┘
</pre>

=== Two-operator Frequency Modulation (FM) Synthesis ===

Output from the first operator (Modulator) is sent to the input of the second one (Carrier) and is used to modulate (alter) frequency of the second operator. Only the second operator produces sound. Most of interesting sounds are made this way. This also works on OPL2. Hope the picture helps.

<pre>
┌────────────┐ ┌────────────┐
│ │ │ │
│ Operator 1 ├────────>│ Operator 2 ├────────> Output
│(Modulator) │ │ (Carrier) │
└────────────┘ └────────────┘
</pre>

=== Four-operator "Mess" Modulation Synthesis ===

All of OPL3's 4-OP configurations are combinations of the above two modes of synthesis. OPL3 combines these two modes in four ways. I have no words to describe these four ways. Only the pictures can show their principle.

<pre>
a) FM-FM Mode

┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ │ │ │ │ │ │ │
│ Op. 1 ├─────>│ Op. 2 ├─────>│ Op. 3 ├─────>│ Op. 4 ├─────> Output
│ │ │ │ │ │ │ │
└───────┘ └───────┘ └───────┘ └───────┘

b) AM-FM Mode

┌───────┐
│ │
│ Op. 1 ├───────────────────────────────────┐
│ │ │
└───────┘ │
│
┌───────┐ ┌───────┐ ┌───────┐ │
│ │ │ │ │ │ │
│ Op. 2 ├─────>│ Op. 3 ├─────>│ Op. 4 ├─────┴─────> Output
│ │ │ │ │ │
└───────┘ └───────┘ └───────┘

c) FM-AM Mode

┌───────┐ ┌───────┐
│ │ │ │
│ Op. 1 ├─────>│ Op. 2 ├─────┐
│ │ │ │ │
└───────┘ └───────┘ │
├─────> Output
┌───────┐ ┌───────┐ │
│ │ │ │ │
│ Op. 3 ├─────>│ Op. 4 ├─────┘
│ │ │ │
└───────┘ └───────┘

d) AM-AM Mode

┌───────┐
│ │
│ Op. 1 ├────────────────────┐
│ │ │
└───────┘ │
│
┌───────┐ ┌───────┐ │
│ │ │ │ │
│ Op. 2 ├─────>│ Op. 3 ├─────┼─────> Output
│ │ │ │ │
└───────┘ └───────┘ │
│
┌───────┐ │
│ │ │
│ Op. 4 ├────────────────────┘
│ │
└───────┘
</pre>

Nice, aren't they?

The only way I think this can be written is a math formula. Symbol + (plus) means additive synthesis, and * (asterisk) means frequency modulation (Op1 * Op2 means operator 1 modulates operator 2, not vice versa). Here they are:

# FM-FM Mode: (Op1 * Op2 * Op3 * Op4) ────> Output
# AM-FM Mode: Op1 + (Op2 * Op3 * Op4) ───> Output
# FM-AM Mode: (Op1 * Op2) + (Op3 * Op4) ──> Output
# AM-AM Mode: Op1 + (Op2 * Op3) + Op4 ───> Output

=== Percussion Mode ===

In this mode 6 operators are used to produce five different percussion instruments:

* Bass Drum (2 operators)
* Snare Drum (1 operator)
* Tom-Tom (1 operator)
* Cymbal (1 operator)
* Hi-Hat (1 operator)

<strike>Because these instruments occupy only three melodic channels, only Bass Drum, Snare Drum and Tom-Tom frequencies can be set. Cymbal and Hi-Hat frequencies are fixed.</strike>

Based on the behaviour of the DOSBox OPL synth, the following points hold true: {{TODO|Verify using a real chip}}

* Setting the block/fnum on each percussive channel affects the pitch of both instruments sharing the channel
** The pitch on channel 7 affects both the hihat and the snare
** The pitch on channel 8 affects both the cymbal and tomtom
** The pitch on channel 6 (of course) affects just the bass drum
* The register 0xC0 has no effect on the percussive channels (so setting 0xC6, 0xC7 and 0xC8 will have no effect)
** This means in OPL3 mode, the panning L/R bits are ignored and the percussive instruments are always played through both channels, as if the bits are always set.
* Changing the modulator output level (0x40) has no effect for modulator-only instruments. This means the hihat and tomtom cannot have their volume set. The other instruments (those that use the output level set in the carrier operator) can have their volume adjusted normally using the carrier output level instead.

The ''AdLib Programmer's Manual'' contains playback code that uses the Tom-Tom frequency for all percussion instruments. It is possible this is the source of the confusion. Here, when a note is played on the Tom-Tom channel, that note will of course cause the Top Cymbal to change as well because of the shared channel. But the code increases this pitch by seven semitones and sets that frequency for channel 7 at the same time, ensuring the Hi-Hat and Snare Drum are always set to seven semitones above the last Tom-Tom note. (See [[AdLib MIDI Format]] for details.)

This mode is identical with that of OPL2. For more details see ADLIB.DOC.

== Programming the Synthesizer ==

OPL3 may be found at the following addresses:

{|class="wikitable"
| Sound Blaster Pro II || 220h or 240h (selectable), also 388h
|-
| Adlib Gold || 388h
|-
| Pro Audio Spectrum Plus/16 || ? (if you have a PAS you should know it)
|}

The base address of the synthesizer will be called "base".

The chip occupies four I/O addresses:

{|class="wikitable"
| base+0 || Primary index register (write), Status register (read)
|-
| base+1 || Primary data register (write-only)
|-
| base+2 || Secondary index register (write)
|-
| base+3 || Secondary data register (write-only)
|}

The index registers are used to select internal registers and data registers are used to write to them. Status register returns the state of two timers built in the chip.

OPL3 contains two sets of registers. The Primary set maps to channels 0-8 (operators 0-17) and the secondary maps to channels 9-17 (operators 18-35). The reason for this is simple: all these registers wouldn't fit into single register set.

Unlike Adlib (OPL2), OPL3 doesn't need delay between register writes. With OPL2 you had to wait 3.3 µs after index register write and another 23 µs after data register write. On the contrary OPL3 doesn't need (almost) any delay after index register write and only 0.28 µs after data register write. This means you can neglect the delays and slightly speed up your music driver. But using reasonable delays will certainly do no harm.

The data registers can't be read (they are write-only) on both OPL2 and OPL3.

== Register Map ==

The registers are grouped in the same manner as in the OPL2 chip. Programs using both OPL2 and OPL3 chips may use the same code provided that their direct I/O interface is well written. The only thing you have to change is operator-to-register mapping, which must accomodate the fact that registers are spread between two register sets.

(The register map is nearly the same so I dared to copy it from ADLIB.DOC.)

=== Status Register (base+0) ===

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| IRQFlag || T1Flag || T2Flag || || || || ||
|}

=== Data Registers (base+1, base+3) ===

{|class="wikitable centred fixed-width"
! REG !! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| 01 ||colspan=2| Test Register ||style="background-color: #CCFFCC;"|(WSEnable)||colspan=5| Test Register
|-
| 02 ||colspan=8| Timer 1 Count (80 µsec resolution)
|-
| 03 ||colspan=8| Timer 2 Count (320 µsec resolution)
|-
| 04* ||IRQReset|| T1Mask || T2Mask ||colspan=3| ||T2 Start||T1 Start
|-
| 04** ||colspan=2| ||style="background-color: #CCFFCC;"|4-OP B-E||style="background-color: #CCFFCC;"|4-OP A-D||style="background-color: #CCFFCC;"|4-OP 9-C||style="background-color: #CCFFCC;"|4-OP 2-5||style="background-color: #CCFFCC;"|4-OP 1-4||style="background-color: #CCFFCC;"|4-OP 0-3
|-
| 05** ||colspan=7| ||style="background-color: #CCFFCC;"| OPL3
|-
| 08 ||style="background-color: #CCFFCC;"| (CSW) ||style="background-color: #CCFFCC;"|NOTE-SEL||colspan=6|
|-
| 20-35 ||style="background-color: #CCCCFF;"|Tremolo ||style="background-color: #CCCCFF;"|Vibrato ||style="background-color: #CCCCFF;"|Sustain ||style="background-color: #CCCCFF;"| KSR ||colspan=4 style="background-color: #CCCCFF;"| Frequency Multiplication Factor
|-
| 40-55 ||colspan=2 style="background-color: #CCCCFF;"| Key Scale Level ||colspan=6 style="background-color: #CCCCFF;"| Output Level
|-
| 60-75 ||colspan=4 style="background-color: #CCCCFF;"| Attack Rate ||colspan=4 style="background-color: #CCCCFF;"| Decay Rate
|-
| 80-95 ||colspan=4 style="background-color: #CCCCFF;"| Sustain Level ||colspan=4 style="background-color: #CCCCFF;"| Release Rate
|-
| A0-A8 ||colspan=8 style="background-color: #FFE0CC;"| Frequency Number (Lower 8 bits)
|-
| B0-B8 ||colspan=2| ||style="background-color: #FFE0CC;"| KEY-ON ||colspan=3 style="background-color: #FFE0CC;"| Block Number ||colspan=2 style="background-color: #FFE0CC;"| F-Num (hi bits)
|-
| BD ||style="background-color: #CCFFCC;"|Trem Dep||style="background-color: #CCFFCC;"|Vibr Dep||style="background-color: #FFCCDD;"|PercMode||style="background-color: #FFCCDD;"| BD On ||style="background-color: #FFCCDD;"| SD On ||style="background-color: #FFCCDD;"| TT On ||style="background-color: #FFCCDD;"| CY On ||style="background-color: #FFCCDD;"| HH On
|-
| C0-C8 ||style="background-color: #FFE0CC;"| OutCh_D ||style="background-color: #FFE0CC;"| OutCh_C ||style="background-color: #FFE0CC;"| Right ||style="background-color: #FFE0CC;"| Left ||colspan=3 style="background-color: #FFE0CC;"|FeedBack Modulation Factor||style="background-color: #FFE0CC;"|SynthTyp
|-
| E0-F5 ||colspan=5| ||colspan=3 style="background-color: #CCCCFF;"| Waveform Select
|}

{|
|style="background-color: #CCFFCC;"| Chip-wide setting
|style="background-color: #CCCCFF;"| Per operator
|style="background-color: #FFE0CC;"| Per channel
|style="background-color: #FFCCDD;"| Rhythm-mode only
|}

:<nowiki>*</nowiki> This applies only to port base+1
:<nowiki>**</nowiki> This applies only to port base+3

For register bases A0, B0 and C0 there is one register per output channel. The primary register set holds the first nine channels (0-8) and the secondary holds last nine channels (9-17). For bases 20, 40, 60, 80 and E0 there are two registers per channel. Each register maps to one operator. Unfortunately the operator's register numbers are not continuous. The following table shows which operator maps to which register set and offset (in hex).

{|class="wikitable centred"
! Op. !! Set/Offset !! Op. !! Set/Offset
|-
| 0 || 0/00 || 18 || 1/00
|-
| 1 || 0/01 || 19 || 1/01
|-
| 2 || 0/02 || 20 || 1/02
|-
| 3 || 0/03 || 21 || 1/03
|-
| 4 || 0/04 || 22 || 1/04
|-
| 5 || 0/05 || 23 || 1/05
|-
| 6 || 0/08 || 24 || 1/08
|-
| 7 || 0/09 || 25 || 1/09
|-
| 8 || 0/0A || 26 || 1/0A
|-
| 9 || 0/0B || 27 || 1/0B
|-
| 10 || 0/0C || 28 || 1/0C
|-
| 11 || 0/0D || 29 || 1/0D
|-
| 12 || 0/10 || 30 || 1/10
|-
| 13 || 0/11 || 31 || 1/11
|-
| 14 || 0/12 || 32 || 1/12
|-
| 15 || 0/13 || 33 || 1/13
|-
| 16 || 0/14 || 34 || 1/14
|-
| 17 || 0/15 || 35 || 1/15
|}

The following tables summarize which operators form a channel in various modes:

1. Two-operator Melodic Mode

{|class="wikitable centred"
! Channel !! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !! 16 !! 17
|-
| Operator 1 || 0 || 1 || 2 || 6 || 7 || 8 || 12 || 13 || 14 || 18 || 19 || 20 || 24 || 25 || 26 || 30 || 31 || 32
|-
| Operator 2 || 3 || 4 || 5 || 9 || 10 || 11 || 15 || 16 || 17 || 21 || 22 || 23 || 27 || 28 || 29 || 33 || 34 || 35
|}

2. Two-operator Melodic and Percussion Mode

{|class="wikitable centred"
! Channel !! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! BD !! SD !! TT !! CY !! HH !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !! 16 !! 17
|-
| Operator 1 || 0 || 1 || 2 || 6 || 7 || 8 || 12 || 16 || 14 || 17 || 13 || 18 || 19 || 20 || 24 || 25 || 26 || 30 || 31 || 32
|-
| Operator 2 || 3 || 4 || 5 || 9 || 10 || 11 || 15 ||colspan=4| - || 21 || 22 || 23 || 27 || 28 || 29 || 33 || 34 || 35
|}

3. Four-operator Melodic Mode

{|class="wikitable centred"
! Channel !! 0 !! 1 !! 2 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 15 !! 16 !! 17
|-
| Operator 1 || 0 || 1 || 2 || 12 || 13 || 14 || 18 || 19 || 20 || 30 || 31 || 32
|-
| Operator 2 || 3 || 4 || 5 || 15 || 16 || 17 || 21 || 22 || 23 || 33 || 34 || 35
|-
| Operator 3 || 6 || 7 || 8 ||colspan=3| - || 24 || 25 || 26 ||colspan=3| -
|-
| Operator 4 || 9 || 10 || 11 ||colspan=3| - || 27 || 28 || 29 ||colspan=3| -
|}

Channels 3, 4, 5 and 12, 13, 14 can't be used separately because their operators became part of channels 0, 1, 2 and 9, 10, 11 respectively. For instance a four-operator channel 1 consists of two two-operator channels number 1 and 4. (The second 2-OP channel number is always the first 2-OP channel number plus three.)

OPL3 allows you to enable/disable 4-OP mode separately for any of channels 0, 1, 2, 9, 10 and 11 (see register 104h in the reference below). This means for instance when you switch only channel 2 into 4-OP mode, channels number 0, 1, 3, 4, 6, 7, 8, 9, etc. will be still independent 2-OP channels.

Channels 6, 7, 8 and 15, 16, 17 are always two-operator ones. They can't be grouped to form four-operator channels.

4. Four-operator Melodic and Percussion Mode

{|class="wikitable centred"
! Channel !! 0 !! 1 !! 2 !! BD !! SD !! TT !! CY !! HH !! 9 !! 10 !! 11 !! 15 !! 16 !! 17
|-
| Operator 1 || 0 || 1 || 2 || 12 || 16 || 14 || 17 || 13 || 18 || 19 || 20 || 30 || 31 || 32
|-
| Operator 2 || 3 || 4 || 5 || 15 ||colspan=4| - || 21 || 22 || 23 || 33 || 34 || 35
|-
| Operator 3 || 6 || 7 || 8 ||colspan=5| - || 24 || 25 || 26 ||colspan=3| -
|-
| Operator 4 || 9 || 10 || 11 ||colspan=5| - || 27 || 28 || 29 ||colspan=3| -
|}

Examples:

Two-operator channel #14 consists of operators 26 and 29 which occupy these registers (all are in the secondary register set):

{|class="wikitable"
| 12A || Operator 1 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 12D || Operator 2 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 14A || Operator 1 || Key Scale Level/Output Level
|-
| 14D || Operator 2 || Key Scale Level/Output Level
|-
| 16A || Operator 1 || Attack Rate/Decay Rate
|-
| 16D || Operator 2 || Attack Rate/Decay Rate
|-
| 18A || Operator 1 ||Sustain Level/Release Rate
|-
| 18D || Operator 2 || Sustain Level/Release Rate
|-
| 1A5 || || Frequency Number (low)
|-
| 1B5 || || Key On/Block Number/Frequency Number (high)
|-
| 1C5 || || FeedBack/Synthesis Type
|-
| 1EA || Operator 1 || Waveform Select
|-
| 1ED || Operator 2 || Waveform Select
|}

Four-operator channel #1 consists of operators 1, 4, 7 and 10. All registers except register 104h are in the primary set:

{|class="wikitable"
|-
| 104 || bit 1 = 1 || Enable Four-Operator Synthesis in channel #1
|-
| 21 || Operator 1 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 24 || Operator 2 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 29 || Operator 3 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 2C || Operator 4 || Tremolo/Vibrato/Sustain/KSR/Multiplication
|-
| 41 || Operator 1 || Key Scale Level/Output Level
|-
| 44 || Operator 2 || Key Scale Level/Output Level
|-
| 49 || Operator 3 || Key Scale Level/Output Level
|-
| 4C || Operator 4 || Key Scale Level/Output Level
|-
| 61 || Operator 1 || Attack Rate/Decay Rate
|-
| 64 || Operator 2 || Attack Rate/Decay Rate
|-
| 69 || Operator 3 || Attack Rate/Decay Rate
|-
| 6C || Operator 4 || Attack Rate/Decay Rate
|-
| 81 || Operator 1 || Sustain Level/Release Rate
|-
| 84 || Operator 2 || Sustain Level/Release Rate
|-
| 89 || Operator 3 || Sustain Level/Release Rate
|-
| 8C || Operator 4 || Sustain Level/Release Rate
|-
| A1 || || Frequency Number (low)
|-
| A4 || || Unused
|-
| B1 || || Key On/Block Number/Frequency Number (high)
|-
| B4 || || Unused
|-
| C1 || || FeedBack/Synthesis Type (part 1)
|-
| C4 || || Synthesis Type (part 2)
|-
| E1 || Operator 1 || Waveform Select
|-
| E4 || Operator 2 || Waveform Select
|-
| E9 || Operator 3 || Waveform Select
|-
| EC || Operator 4 || Waveform Select
|}

NOTE: If a register number is greater than 100h, then it belongs into the secondary register set. (I use this numbering to emphasize the fact that the particular register MUST be written to the secondary set.) See the example code below for details.

== OPL3 Register Reference ==

Because the registers of OPL3 are almost the same as of OPL2, I have copied their descriptions from file ADLIB.DOC.

=== Status Register ===

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| IRQ || T1 || T2 ||colspan=5| -
|}

* bit 7: IRQ Flag. Set whenever any timer has elapsed.
* bit 6: Timer 1 Flag. Set every time the preset time in Timer 1 has elapsed.
* bit 5: Timer 2 Flag. Set every time the preset time in Timer 2 has elapsed.

Timer interrupts are not wired to any IRQ (why??). The timers can be used to detect the OPL2/OPL3 chip (see Appendix B).

=== Data Registers ===

==== 01: Test Register / Waveform Select Enable ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=2| Test Register
| (WSE)
|colspan=5| Test Register
|}

* bits 7-6: Test Register. Must be reset to zero before any operation.
* bit 5: Waveform Select Enable. If clear, all channels will use normal sine wave. If set, register E0-F5 (Waveform Select) contents will be used.
* bits 0-4: Test Register. Must be reset to zero before any operation.

OPL3 does not implement WSE bit, and it should be left clear. In OPL2 mode all four waveforms are always available, and in OPL3 mode all eight waveforms are always available. For compatibility with OPL2, when a program is finished using an OPL3, the waveform select registers should be set to 0, if the next program assumes that by setting WSE bit to 0 the waveform is always sine like on a real OPL2.

==== 02: Timer 1 Count ====

Upward 8 bit counter with a resolution of 80 µsec. If an overflow occurs, the status register bit is set, and the preset value is loaded into the timer again.

==== 03: Timer 2 Count ====

Same as Timer 1, but with a resolution of 320 µsec.

==== 004 (port: base+1): IRQ-Reset / Mask / Start ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| Rst
| T1M
| T2M
|colspan=3| -
| T2S
| T1S
|}

* bit 7: IRQ-Reset. Resets timer and IRQ flags in status register. All other bits are ignored when this bit is set.
* bit 6: Timer 1 Mask. If 1, status register is not affected in overflow.
* bit 5: Timer 2 Mask. Same as above.
* bit 1: Timer 2 Start. Timer on/off.
* bit 0: Timer 1 Start. Same as above.

==== 104 (port: base+3): Four-Operator Enable ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=2| -
| ChB
| ChA
| Ch9
| Ch2
| Ch1
| Ch0
|}

* bit 5: Enable four-operator synthesis for channel pair 11 - 14 (decimal).
* bit 4: Same as above for channel pair 10 - 13.
* bit 3: Same as above for channel pair 9 - 12.
* bit 2: Same as above for channel pair 2 - 5.
* bit 1: Same as above for channel pair 1 - 4.
* bit 0: Same as above for channel pair 0 - 3.

If reset to zero, OPL3 can produce 18 two-operator sounds at a time. If nonzero, OPL3 produces four-operator sound in appropriate channel pair.

==== 105 (port: base+3): OPL3 Mode Enable ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=7| -
| OPL3
|}

* bit 0: OPL3 Mode Enable. When set, OPL3 extensions (36 operators, 4-OP synthesis, 8 waveforms, stereo output) can be used. When reset, the chip behaves as an ordinary OPL2. This bit is zero by default for compatibility with OPL2.

==== 08: CSW / NOTE-SEL ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| (CSW)
| N-S
|colspan=6| -
|}

* bit 7: Composite sine wave mode on/off. All KEY-ON bits must be clear in order to use this mode. The card is unable to create any other sound when in CSW mode. (Unfortunately, I have no info how to use this mode :-< ). The CSW mode is not implemented on an OPL3 and this bit is ignored.
* bit 6: NOTE-SEL. Controls the split point of the keyboard. When 0, the keyboard split is the second bit from the bit 8 of the F-Number. When 1, the MSb of the F-Number is used. (???)

The Note Select bit defines what kind of F-NUM values are used within an octave so the chip knows how to split an octave into two parts. When Note Select bit is 0, F-NUM values used within an octave all have their MSB bit (bit 9) set, ranging from 0x200 to 0x3FF, so the second most significant bit, bit 8 is used to determine if currently playing note belongs to lower (0x200-0x2FF) or upper (0x300-0x3FF) half within an octave. When Note Select bit is 1, the F-NUM value MSB bit, bit 9, is used to determine if the note belongs to lower (0x000-0x1FF) or upper (0x200-0x3FF) half within an octave.

==== 20-35: Tremolo / Vibrato / Sustain / KSR / Frequency Multiplication Factor ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| Tre
| Vib
| Sus
| KSR
|colspan=4| Multiplication
|}

* bit 7: Tremolo (Amplitude vibrato) on/off.
* bit 6: Frequency vibrato on/off.
* bit 5: Sound Sustaining. When 1, operator's output level will be held at its sustain level until a KEY-OFF is done.
* bit 4: Envelope scaling (KSR) on/off. When 1, higher notes are shorter than lower notes.
* bits 0-3: Frequency Multiplication Factor (MULTI). Operator's frequency is set to (see registers A0, B0) F-Number * Factor.

{|class="wikitable"
! MULTI !! Factor
|-
| 0 || 0.5
|-
| 1 || 1
|-
| 2 || 2
|-
| 3 || 3
|-
| 4 || 4
|-
| 5 || 5
|-
| 6 || 6
|-
| 7 || 7
|-
| 8 || 8
|-
| 9 || 9
|-
| 10 || 10
|-
| 11 || 10
|-
| 12 || 12
|-
| 13 || 12
|-
| 14 || 15
|-
| 15 || 15
|}

==== 40-55: Key Scale Level / Output Level ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=2| KSL
|colspan=6| Output level
|}

* bits 6-7: Key Scale Level. Attenuates output level towards higher pitch:

{|class="wikitable centred fixed-width"
! KSL !! Attenuation
|-
| 0 || -
|-
| 1 || 3.0 dB/oct
|-
| 2 || 1.5 dB/oct
|-
| 3 || 6.0 dB/oct
|}

The attenuation level is based on the 3-bit octave (block number) value and top four bits of the FNUM value, so each octave is subdivided into 16 parts.

* bits 0-5: Output Level. Attenuates the operator output level. 0 is the loudest, 3F is the softest. Attenuation range is 48dB with 0.75dB resolution.
{|class="wikitable centred fixed-width"
! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| 24dB || 12dB || 6dB || 3dB || 1.5dB || 0.75dB
|}

* In additive synthesis, varying the output level of any operator varies the volume of its corresponding channel. In FM synthesis, varying the output level of the carrier varies the volume of the channel. Varying the output of the modulator will change the frequency spectrum produced by the carrier. The following table summarizes which operators' output levels should be updated when trying to change channel output level.

{|class="wikitable centred fixed-width"
! Mode !! Op 1 !! Op 2 !! Op 3 !! Op 4
|-
| AM || Y || Y || N/A || N/A
|-
| FM || - || Y || N/A || N/A
|-
| FM-FM || - || - || - || Y
|-
| AM-FM || Y || - || - || Y
|-
| FM-AM || - || Y || - || Y
|-
| AM-AM || Y || - || Y || Y
|}

==== 60-75: Attack Rate / Decay Rate ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=4| Attack rate
|colspan=4| Decay rate
|}

* bits 4-7: Attack Rate. Determines the rising time for the sound. The higher the value, the faster the attack. If value is 0, the sound will never attack, and if value is 15, the volume jumps directly from minimum to maximum.
* bits 0-3: Decay Rate. Determines the diminishing time for the sound. The higher the value, the shorter the decay. If value is 0, the sound does not decay towards sustain level and stays at maximum volume after attack.

==== 80-95: Sustain Level / Release Rate ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=4| Sustain level
|colspan=4| Release rate
|}

* bits 4-7: Sustain Level. Determines the point at which the sound ceases to decay and chages to a sound having a constant level. The sustain level is expressed as a fraction of the maximum level. 15 is the softest and 0 is the loudest sustain level. Note that the Sustain-bit in the register 20-35 must be set for this to have an effect. Otherwise the sound will continue with release phase after hitting sustain level.

{|class="wikitable centred fixed-width"
! SL3 !! SL2 !! SL1 !! SL0
|-
| -24dB || -12dB || -6dB || -3dB
|}

There is an exception when all bits are set (value=15), the actual level is -93dB instead, matching as if the value were 31.

* bits 0-3: Release Rate. Determines the rate at which the sound disappears after KEY-OFF. The higher the value, the shorter the release. Value of 0 causes the sound not to release at all, it will continue to produce sound at level before KEY-OFF.

==== A0-A8: Frequency Number ====

Determines the pitch of the note. Highest bits of F-Number are stored in the register below.

==== B0-B8: Key On / Block Number / F-Number(hi bits) ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=2| -
| Note on
|colspan=3| Block number
|colspan=2| Frequency num.
|}

The '''note on''' bit is set to 1 to play a note on the channel, and 0 to silence the note. Setting this value to 1 when a note is already playing has no effect (it does not retrigger the note.)

The '''block number''' is often referred to as the octave, but this is a misleading description. The value of the block controls the frequency range spanned by the frequency numbers. A larger block allows higher frequencies (pitch) to be reached, at the expense of there being a greater difference in pitch of two adjacent frequency numbers. This works out well, since a low block number allows a very high pitch accuracy for deep notes where it is most noticeable, while high block numbers mean the coarse pitch settings need only be used at high frequencies where the coarseness is unnoticeable.

The following table illustrates the effect of different block numbers.

{|class="wikitable"
!rowspan=2| Block !!colspan=2| Note frequency !!rowspan=2| Difference between adjacent notes (Hz)
|-
! F-num=1 !! F-num=1023
|-
|align=center| 0 ||align=right| 0.047 Hz ||align=right| 48.503 Hz ||align=right| 0.048 Hz
|-
|align=center| 1 ||align=right| 0.094 Hz ||align=right| 97.006 Hz ||align=right| 0.095 Hz
|-
|align=center| 2 ||align=right| 0.189 Hz ||align=right| 194.013 Hz ||align=right| 0.190 Hz
|-
|align=center| 3 ||align=right| 0.379 Hz ||align=right| 388.026 Hz ||align=right| 0.379 Hz
|-
|align=center| 4 ||align=right| 0.758 Hz ||align=right| 776.053 Hz ||align=right| 0.759 Hz
|-
|align=center| 5 ||align=right| 1.517 Hz ||align=right| 1,552.107 Hz ||align=right| 1.517 Hz
|-
|align=center| 6 ||align=right| 3.034 Hz ||align=right| 3,104.215 Hz ||align=right| 3.034 Hz
|-
|align=center| 7 ||align=right| 6.068 Hz ||align=right| 6,208.431 Hz ||align=right| 6.069 Hz
|}

This shows that block 7 is capable of reaching the highest note (6.2kHz) but since there are 6Hz between notes the accuracy suffers. Note A-4 is 440Hz but in this block, the two closest frequency numbers are 72 and 73, which create tones at 437Hz and 443Hz respectively, neither of which is particularly accurate. Blocks 3 and below are unable to reach as high as 440Hz, but block 4 can. With block 4, frequency numbers 579 and 580 produce 439.4Hz and 440.2Hz, considerably closer to the intended frequency.

In other words, when calculating notes, the best accuracy is achieved by selecting the lowest possible block number that can reach the desired note frequency.

The '''frequency number''' is split between registers A0 and B0, with the upper two bits being stored here. The full frequency number is a value between 0 and 1023 inclusive. The following formula is used to determine the frequency number for a given note frequency (in Hertz) and block:

: f-num = freq * 2^(20 - block) / 49716

This formula can produce frequency numbers outside of the allowed 0-1023 range if the block number is too low, or the frequency is higher than the hardware can produce.

The sampling frequency of OPL2 and OPL3 chips is approximately 49716 Hz, leading to the constant in the formula. Occasionally this is rounded to 50000 leading to a small pitch variation if the wrong constant is used to play these songs. OPL2 cards like Adlib and early Sound Blasters used the 14.31818 MHz oscillator signal from ISA bus slot and divided it by four on card, thus running the OPL2 chip at 3.579545 MHz, which gets divided internally by 72 to get the sampling rate. OPL3 cards had to be compatible, and mostly the sound cards have separate 14.31818 MHz oscillator on board which the OPL3 uses directly, and this gets divided internally by 288 to get the sampling rate.

NOTE: In four-operator mode only the register value of Operators 1 and 2 is used, value of Operators 3 and 4 in this register is ignored. In other words: one channel uses only one frequency, block and KEY-ON value at a time, regardless whether it is a two- or four-operator channel.

Setting the frequency and/or block while the ''note on'' bit is set will result in the frequency changing immediately. By changing the values gradually, pitch bends can be achieved.

{{TODO|Does changing the frequency just after a note-off cause a pitch bend for those instruments with lengthy release rates?}}

==== BD: Tremolo Depth / Vibrato Depth / Percussion Mode / BD/SD/TT/CY/HH On ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| Tre
| Vib
| Per
| BD
| SD
| TT
| CY
| HH
|}

* bit 7: Tremolo (Amplitude Vibrato) Depth. 0 = 1.0dB, 1 = 4.8dB.
* bit 6: Frequency Vibrato Depth. 0 = 7 cents, 1 = 14 cents. A "cent" is 1/100 of a semi-tone.
* bit 5: Percussion Mode. 0 = Melodic Mode, 1 = Percussion Mode.
* bit 4: BD On. KEY-ON of the Bass Drum channel.
* bit 3: SD On. KEY-ON of the Snare Drum channel.
* bit 2: TT On. KEY-ON of the Tom-Tom channel.
* bit 1: CY On. KEY-ON of the Cymbal channel.
* bit 0: HH On. KEY-ON of the Hi-Hat channel.

NOTE: KEY-ON bits of channels 6, 7 and 8 must be clear and their F-Nums, Attack/Decay/Release rates, etc. must be set properly to use percussion mode.

==== C0-C8: FeedBack Modulation Factor / Synthesis Type ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
| OutCh_D
| OutCh_C
| R
| L
|colspan=3| Feedback
| Syn
|}

* bit 7: CHD, Output Channel D Enable. When set, channel output goes to fourth digital audio output channel.
* bit 6: CHC, Output Channel C Enable. When set, channel output goes to third digital audio output channel.
* bit 5: Right Speaker Enable. When set, channel output goes to second digital audio output channel, connected to right speaker.
* bit 4: Left Speaker Enable. When set, channel output goes to first digital audio output channel, connected to left speaker.
** In OPL3 mode, at least one of the left/right bits must be set to hear the channel.
** In OPL2 mode, these bits are ignored and audio is sent to all channels for compatibility reasons.
** Left/Right bits can be used to realize sound "panning", but this method offers only three pan positions (left/center/right).
** These bits apply only to operators producing sound (Carriers). Modulators are not affected by their setting.
** Sound cards use only one stereo DAC, so only two of the four digital output channels are available.
* bits 1-3: FeedBack Modulation Factor. If 0, no feedback is present. If 1-7, operator 1 will send a portion of its output back into itself.

{|class="wikitable centred fixed-width"
! FeedBack !! Factor
|-
| 0 || 0
|-
| 1 || π/16
|-
| 2 || π/8
|-
| 3 || π/4
|-
| 4 || π/2
|-
| 5 || π
|-
| 6 || 2π
|-
| 7 || 4π
|}

When in four-operator mode, the FeedBack value is used only by Operator 1, value of Operators 2, 3 and 4 is ignored.

* bit 0: Synthesis Type. 1 = Additive synthesis, 0 = Frequency Modulation. In four-operator mode, there are two bits controlling the synthesis type. Both are the bit 0 of register C0, one of Operators 1 and 2 and the second of Operators 3 and 4.

{|class="wikitable centred fixed-width"
! Op 1&2 !! Op 3&4 !! Type
|-
| 0 || NONE || FM
|-
| 1 || NONE || AM
|-
| 0 || 0 || FM-FM
|-
| 1 || 0 || AM-FM
|-
| 0 || 1 || FM-AM
|-
| 1 || 1 || AM-AM
|}

==== E0-F5: Waveform Select ====

{|class="wikitable centred fixed-width"
! D7 !! D6 !! D5 !! D4 !! D3 !! D2 !! D1 !! D0
|-
|colspan=5| -
|colspan=3| Waveform
|}

* bits 0-2: WaveForm Select (WS): <gallery widths=261px perrow=4>
Image:OPL_Wave0_Digital.svg|Waveform 0: Sine
Image:OPL_Wave1_Digital.svg|Waveform 1: Half-sine
Image:OPL_Wave2_Digital.svg|Waveform 2: Abs-sine
Image:OPL_Wave3_Digital.svg|Waveform 3: Pulse-sine
Image:OPL_Wave4_Digital.svg|Waveform 4: Sine - even periods only
Image:OPL_Wave5_Digital.svg|Waveform 5: Abs-sine - even periods only
Image:OPL_Wave6_Digital.svg|Waveform 6: Square
Image:OPL_Wave7_Digital.svg|Waveform 7: Derived square
</gallery>

* NOTE: Bit 5 of register 01 must be set to use waveforms other than sine. Waveforms 4-7 are available only on OPL3. See files WAVEn.GIF for real waveforms, where n is a number between 0 and 7.

== Examples ==

These examples show a few working routines used in my MUS Player. They are written in Borland C++ 3.1 but should be easy to translate to any other language.

<source lang="C">
// I prefer using these Assembler-like types
typedef unsigned int WORD;
typedef unsigned char BYTE;

/*
* FM Synthesizer base port. SB Pro II - 0x220, Adlib 0x388
*/
WORD FMport = 0x220;

/*
* Enables OPL3 extensions.
*/
WORD OPL3 = 1;

/*
* Direct write to any Adlib/SB Pro II FM synthetiser register.
* reg - register number (range 0x001-0x0F5 and 0x101-0x1F5). When high byte
* of reg is zero, data go to port FMport, otherwise to FMport+2
* data - register value to be written
*/
BYTE FMwriteReg(WORD reg, BYTE data)
{
asm {
mov dx,FMport
mov ax,reg
or ah,ah // high byte is nonzero -- write to port base+2
jz out1
inc dx
inc dx
}
out1: asm {
out dx,al
mov cx,6
}
loop1:asm { // delay between writes
in al,dx
loop loop1

inc dx
mov al,data
out dx,al
dec dx
mov cx,36
}
loop2:asm { // delay after data write
in al,dx
loop loop2
}
return _AL;
}

/*
* Write to an operator pair. To be used for register bases of 0x20, 0x40,
* 0x60, 0x80 and 0xE0.
*/
void FMwriteChannel(BYTE regbase, BYTE channel, BYTE data1, BYTE data2)
{
static BYTE adlib_op[] = {0, 1, 2, 8, 9, 10, 16, 17, 18};
static BYTE sbpro_op[] = { 0, 1, 2, 6, 7, 8, 12, 13, 14,
18, 19, 20, 24, 25, 26, 30, 31, 32};
static WORD rg[] = {0x000,0x001,0x002,0x003,0x004,0x005,
0x008,0x009,0x00A,0x00B,0x00C,0x00D,
0x010,0x011,0x012,0x013,0x014,0x015,
0x100,0x101,0x102,0x103,0x104,0x105,
0x108,0x109,0x10A,0x10B,0x10C,0x10D,
0x110,0x111,0x112,0x113,0x114,0x115};

if (OPL3)
{
register WORD reg = sbpro_op[channel];
FMwriteReg(rg[reg]+regbase, data1);
FMwriteReg(rg[reg+3]+regbase, data2);
} else {
register WORD reg = regbase+adlib_op[channel];
FMwriteReg(reg, data1);
FMwriteReg(reg+3, data2);
}
}

/*
* Write to channel a single value. To be used for register bases of
* 0xA0, 0xB0 and 0xC0.
*/
void FMwriteValue(BYTE regbase, BYTE channel, BYTE value)
{
static WORD ch[] = {0x000,0x001,0x002,0x003,0x004,0x005,0x006,0x007,0x008,
0x100,0x101,0x102,0x103,0x104,0x105,0x106,0x107,0x108};
register WORD chan;

if (OPL3)
chan = ch[channel];
else
chan = channel;
FMwriteReg(regbase + chan, value);
}
</source>

== Detection Methods ==

An official method of Adlib (OPL2) detection is:

# Reset Timer 1 and Timer 2: write 60h to register 4.
# Reset the IRQ: write 80h to register 4.
#* NOTE: Steps 1 and 2 can't be combined together.
# Read status register: read port base+0 (388h). Save the result.
# Set Timer 1 to FFh: write FFh to register 2.
# Unmask and start Timer 1: write 21h to register 4.
# Wait in a delay loop for at least 80 µsec.
# Read status register: read port base+0 (388h). Save the result.
# Reset Timer 1, Timer 2 and IRQ as in steps 1 and 2.
# Test the results of the two reads: the first should be 0, the second should be C0h. If either is incorrect, then the OPL2 is not present.

* NOTE1: You should AND the result bytes with E0h because the unused bits are undefined.
* NOTE2: This testing method doesn't work in some SoundBlaster compatible cards.

=== OPL3 Detection ===
--------------

# Detect OPL2. If present, continue.
# Read status register: read port base+0.
# AND the result with 06h.
# If the result is zero, you have OPL3, otherwise OPL2.

* NOTE: This is NOT an official method. I have dug it out of a sound driver. I haven't tested it, because I haven't an OPL2 card (Adlib, SB Pro I). Nevertheless it "detects" my SB Pro II properly. ;-)

Another possible detection method for distinguishing between SB Pro I and SB Pro II would be to try to detect OPL2 at I/O port base+0 and then at port base+2. The first test should succeed and the second should fail if OPL3 is present. (Remember: SB Pro I contains twin OPL2 chips at addresses base+0 and base+2, while SB Pro II contains one OPL3 chip at I/O address base+0 thru base+3).

== BLASTER Environment Variable ==

Perhaps the most recommended "detection" method. Reading this variable avoids blindfold I/O port scanning and possible device conflicts. The user is responsible for its proper setting.

The variable has this format:

BLASTER=Aaddr Iirq Ddma Ttype

* A: Base I/O address given in hex. For most Sound Blasters the default is 220.
* I: IRQ Number (decimal). Default 7.
* D: DMA Number (decimal). Default 1.
* T: Card Type (decimal):
** 1 - Sound Blaster 1.5
** 2 - Sound Blaster Pro I
** 3 - Sound Blaster 2.0
** 4 - Sound Blaster Pro II

Example:

BLASTER=A220 I7 D1 T4

== References ==

''The PC Games Programmers Encyclopedia'', Mark Feldman and many others on Usenet and Internet, http://bespin.org/~qz/pc-gpe/
: ... you can find (almost) everything you need there

''Sound Blaster - The Official Book'', Richard Heimlich, David M. Golden, Ivan Luk, Peter M. Ridge, Osborne/McGraw Hill, ISBN 0-07-881907-5
: ... this is a number-one in my book-wishlist. If anyone wanted to get rid of the book, I wouldn't scorn it ... :-)

''The SoundBlaster Developer Kit'', Creative Labs Inc, Creative Technology PTE LTD
: ... I wonder if you can find something comprehensible in that.

User talk:Malvineous

2014-12-12T21:03:10Z

The coder: Question

== Wolfenstein 3D -> Wolfenstein 3-D ==
I've corrected the infamous 3D tyop in the names of several Wolf3D-related pages; can you please delete the following ones?

[[:Category:Wolfenstein 3D]] -> Superseded by [[:Category:Wolfenstein 3-D]] 
[[:Image:Wolfenstein_3D.png]] -> Superseded by [[:Image:Wolfenstein_3-D.png]]

Thanks :) --De Zeurkous (zeurkous@zeurcomp.nichten.info), Thu Nov 22 08:18:42 UTC 2007

:Haha, you've certainly been busy. Don't forget that this wiki isn't meant to be an encyclopaedia of the games, its main purpose is documenting the file formats and editing tools that can be used with the games, as opposed to how the games behave without any mods, or what they might be called if you forget to change the title screen :-) -- [[User:Malvineous|Malvineous]] 11:14, 22 November 2007 (GMT)

::Nah, I haven't forgotten. As we're reinventing the wheel for a semi-virgin wiki, the naming and something static like the cheats seemed like a good place to start :) --De Zeurkous (zeurkous@nichten.info), Thu Nov 22 12:20:04 UTC 2007

== Jill of the Jungle palette ==

Hi, I'm currently working on a level viewer for [[Jill of the Jungle]] (maybe an editor later on). Some of the information I found here has been very useful, but there's one thing I'm a bit stuck on. On the [[SHA Format]] page it says:
:''Each array item contains 4 unsigned bytes, representing CGA, EGA and VGA, respectivley, and then a null value. [...] Each byte maps to the index of a colour in the palette. If there are no colours required, the tile set uses the default colours.''
However, it doesn't say anywhere where the palette can be found. Is it stored in the EXE file? I hope you can help me on this :)

Regards, [[User:Spinal|Spinal]] 13:00, 2 March 2008 (GMT)

:Unfortunately I didn't write the JotJ SHA page, and I haven't yet had the time to figure this out. For Xargon I've taken the quick and dirty route and used a screenshot from within DOSBox as the source of the palette, until I can figure out where the palette is located. If you find this out, don't forget to update the page! :-) -- [[User:Malvineous|Malvineous]] 22:02, 2 March 2008 (GMT)

::Hey Spinal, sorry, I wrote the [[SHA Format]] page, so that was probably my bad. I wasn't able to find the palette either. I assume it's in the .EXE, however I spent a fair bit of time manually mapping it using a Wombat tool (http://www.szevvy.com/node/3). I was also writing a level viewer (initally in XHTML which turned out to be too slow, so then I moved to Flash 9). I tried to email you my findings, but the email bounced. I'm not sure if they were 100% accurat, which is why I never added them to the documentation.

::Hey Malvineous, it seems the Jill - [[DMA Format]] page has been removed. Do you have a log of what happened to it? I'm sure it existed at some point.

::- [[User:dheim|Daniel]] 20:00, 5 March 2008

:::I don't ever remember seeing a DMA page - certainly there's nothing in the wiki logs about it being deleted or renamed. Maybe you started working on it but never got around to saving it? Or is it one of the Xargon pages that shares the same format as Jill? (by the way, you can type <nowiki>~~~~</nowiki> to automatically put in the signature in these messages.) -- [[User:Malvineous|Malvineous]] 11:28, 5 March 2008 (GMT)

::::Sorry, it must have been the stuff in the [[SHA Format]] page that I was thinking of. I may have added the link to the [[DMA Format]] page, and never expanded on it. - [[User:Dheim|Daniel]] 02:46, 6 March 2008 (GMT)

:::::Hi guys. Sorry for the mistake, I mixed up the authors of the SHA and level formats. I've written a level viewer in PHP the last week, by using static images instead of getting them from the actual files. This causes some problems for episode 2, which uses a different palette, but besides that it works great :) When everything is done I'll upload the maps to my server and the tile/object lists to this wiki.
:::::@Daniel: strange that it bounced, I confirmed my address so it should be working fine... You can mail it to spinal -at- zanderz -dot- net. Also, I saw on your Wombat page that you "have a vague idea of how to do" [[Hocus Pocus]]. Could you share your findings on this wiki? I'd love to make maps, or even a level viewer/editor for that game :) -- [[User:Spinal|Spinal]] 00:32, 8 March 2008 (GMT)
:Okay, with help of [[User:Dheim|Daniel]] who send me the palette I found it! I'll put my findings on [[Jill of the Jungle palette]]. -- [[User:Spinal|Spinal]] 15:36, 13 March 2008 (GMT)

== Halloween Harry/Alien Carnage ==

Hi Malvineous. Thanks for your edits on the GMF article! I notice you mentioned there exist versions of the game which don't require exploding a BNK to get at the game data. What does the directory structure look like for the version you have? I'm working on a map viewer (which will become a map editor at some point) and would like it to be able to work on whatever versions are out there. Thanks for any info. -[[User:Duckthing|Duckthing]] 04:41, 11 December 2010 (GMT)

: Hi Duckthing - no worries, Halloween Harry has long been an interest of mine, but my map editor sadly needs a lot more work before I can begin reverse engineering more file formats so I'm glad you've made a start! AFAIK technically Halloween Harry has no compression, but for whatever reason (probably listed in the Apogee FAQ) they decided to swap episodes 1 and 3, compress the BNK file and then re-release it under the name Alien Carnage. You can download all available versions (including registered versions since the game was released as freeware in 2007) from [http://www.classicdosgames.com/game/Alien_Carnage.html RGB Classic Games]. BTW not sure if you noticed but I also posted a couple of things on the GMF article's talk/discussion page. -- [[User:Malvineous|Malvineous]] 06:08, 11 December 2010 (GMT)

:: Thank you! Working with the uncompressed version will keep things less complicated. I did notice the GMF discussion you added, but haven't had a chance to really go through it yet. -- [[User:Duckthing|Duckthing]] 06:41, 11 December 2010 (GMT)

::: No worries. If you're running Linux or MacOSX you should be able to compile [[Camoto|libgamearchive]] which will let you copy files in and out of the BNK files. This is a library so it's also possible to use it in your own program for accessing and editing the map files while they're still inside the BNK, for instance. (BTW the 'minor' tickbox should only be used when the edit does not affect the information on the page - e.g. fixing a typo or a broken URL. If you are changing the actual content on a page it is never a minor edit!) -- [[User:Malvineous|Malvineous]] 07:51, 11 December 2010 (GMT)

== Dangerous Dave ==

Working on this, does anyone have any info on the formats? The EGA graphics are 84KB and external, but CGA and VGA graphics unrelated to them are in the 174KB executable, apparently uncompressed, I don't know how this is possible. I've found the levels and partially reverse engineered the format (The first 1000 bytes, a 100x10 array of tiles.) but each level is followed by ~280 bytes of variable and unknown data I assume is sprites. I have a list of internal files in the executable, looks like most of it is non-game code. Any help would be appreciated. -[[User:Levellass|Endian? What are you on about?]] 06:03, 12 December 2010 (GMT)

: Hmm, interesting. All I can suggest for the levels is - as you're probably already familiar with - changing the values in a hex editor then loading the game to see what happens. I would suspect that all the graphics would be in a similar format, so if there are any headers or structures used in the EGA graphics files perhaps they're duplicated for CGA/VGA? Also John Romero seems pretty accessible, perhaps you could ask him directly? Failing that, randomly writing data into the .exe until the images change could be used as a last resort! -- [[User:Malvineous|Malvineous]] 12:09, 12 December 2010 (GMT)

: Ha, that was easier than I expected - uncompressed VGA data is easy to find with a good hex editor ;-) [http://www.shikadi.net/pics/ddave-vga-hexdump.png This looks like it] -- [[User:Malvineous|Malvineous]] 12:17, 12 December 2010 (GMT)

: Ok that was only the menu graphics. At offset 0xC629 there's some sort of offset table which looks very similar to the contents of EGADAVE.DAV but there are extra bytes dotted all over the place - perhaps it's RLE encoded? Actually just before that there's the number 0x6CAA. If you go a bit less than 0x6CAA bytes after this you end up with another table, which to me suggests that 0x6CAA is the decompressed size of that first table. -- [[User:Malvineous|Malvineous]] 13:01, 12 December 2010 (GMT)

:If I remember it correctly, the VGA sprites and tiles are RLE compressed and it's not too hard to decompress them. The positions of the enemies in the levels on the other hand are still a mystery to me. [[User:Calvero|Calvero]] 20:43, 12 December 2010 (GMT)

: Looking at the levels, which directly follow the VGA palette, they seem to contain 256 bytes of header data, then the 100x10 tiles, then eight bytes of lead-out data. Then the next level's 256 bytes of header, 100x10 tiles, then eight bytes of lead-out. Although I say "level", the first "level" seems to contain both level 1 and 2, and this seems to be the way it works in the game - in some levels you can see through to others. I'm not sure what the 256 bytes of header data are for, but some levels have FF FF 00 00 repeated which seems to indicate two uint16 fields which are blanked out for those levels. -- [[User:Malvineous|Malvineous]] 13:15, 13 December 2010 (GMT)

::First up, levels; where does level 1 start? It's possible I'm reading the start of a level as the previous level's end, I looked for the start of tile data, which I assumed, like Keen 1, would be the level start.

::Next, palette; I'm assuming, as you said, it is located just before the level data?

::There is VGA and CGA graphics in the executable, plus headers, but the bulk of graphics for CGA and VGA I haven't been able to locate. If the data is RLE compressed I should think it would use either Keen 1-3 fullscreen or Jazz Jackrabbit tile RLE, both of which I know well. I'll look into both of these options, cheers! -[[User:Levellass|Endian? What are you on about?]] 12:03, 20 December 2010 (GMT)

:::I've found the VGA and CGA data for the menu graphics. It looks like the CGA data is stored in a series of 1-bit-per-pixel (monochrome) images. Or it could be EGA data with the planes split out (e.g. red plane for all images, then green plane for all images, etc.) I think I found three planes which means it's probably EGA, as CGA would have a max of two planes. I've also found the font graphics, this looks like 4bpp/16 colour EGA data. Haven't seen level graphics yet. I've successfully modded the levels with a hex editor (putting the jetpack everywhere) so now I've finally looked at all the levels! The creatures are definitely not stored in the 100x10 tile data. Putting random bytes in there revealed that the values are indices into the image files, because if you put the value in for fire it will animate, and the following three or so values show up as still frames from the fire animation.

:::The VGA palette starts at 0x26B0A (I updated the main DDave page with this) + 768 bytes leads straight onto the start of level 1 at 0x26E0A. So at 0x26E0A there are 256 bytes of data, then 100x10 tiles, then 24 bytes of footer data. Some of this data (perhaps footer data) might be the level start coordinates, because Dave doesn't always start the level at the same place (e.g. the warp level when you climb the tree on level 5 and jump off the edge of the screen.) -- [[User:Malvineous|Malvineous]] 12:24, 20 December 2010 (GMT)

:::I think I've found all the files so far, I've updated [[Dangerous Dave]] with the offsets of the files, including what appears to be CGA and VGA tiles. I'm not sure what sort of format they're in though, it looks like they might be compressed (and so the offsets in that list might be off by ~4, as I may have cut off the decompressed-size field.) I've also updated the map format page, I think it's pretty much fully reverse engineered now. -- [[User:Malvineous|Malvineous]] 05:13, 21 December 2010 (GMT)

== Noahs Ark 3D and IMFs ==

Been poking around Noah's Ark 3D, an adaption of the Wolfenstein game and found a few interesting things which I'm hoping to confirm.

First, the game uses MID files, not IMF files for music, second, the MIDI files have an extra word at the start of the file giving the file length. Third, the code uses the first word of the midi file as the length of data to read from the file and put into memory to play. After poking around a bit in Wolfenstein and Keen I believe this is the same with IMF files, that is, ALL IMF files are type 0 as it were and the type 1s are read just like type 0s by the games (The first word is read as the amount of IMF data to copy into memory to play, this is then read as type 0.) I'm not quite sure what this does for the two types since type 1 is would essentially be a type 0 with a header and footer that are part of the AUDIO.xxx format, much like PC\adlib sounds can have the huffman lengths at the start. Are there any games that use 'individual' type 1 IMFs (Even if included as part of a group file. All I've seen are games like cosmo, where non-AUDIO IMFs are type 0.)

Should there be a Noah's Ark 3D page and should we add the midi note to the AUDIO format page? It seems that the format can hold any type of music file the game can read, not just IMFs. -- Levellass

: Yes it is known that the type-1 header might really be part of the AUDIO.xxx format but alas there were many type-1 files floating around the place (incorrectly extracted, you could argue) before this was realised, so the format variant is here to stay. It does have some advantages though (like tagging files with the song title) but I'm not sure whether anyone has figured out definitively whether the header (and footer, in the case of the Wolf3D files) belongs to the IMF or the AUDIO file. I guess you'd have to browse the game source code and see how the game uses the data to know for sure.

: As far as the MIDI goes, I believe the AUDIO.xxx file is just a container file like any other, capable of supporting any data at all. It's up to the game to decide how to use it. If anything this makes me think it would fit better if the AUDIO.xxx article was merely documenting the structure, with links to actual audio formats like PC SFX, Adlib SFX, IMF and MIDI and notes about which games make use of which formats.

: Oh and yes, by all means create a page for the new game. -- [[User:Malvineous|Malvineous]] 08:41, 3 February 2011 (GMT)

== Sound Files category ==

I don’t know why there’s a Sound Files category and also an Audio Files category... it seems redundant. I left those categories the way they are though.

Also, the [[File format data types]] page needs some signed ints, but I didn’t know what naming convention you wanted to use. I described something as an [[INT16LE]] on [[BMC Format]]. [[User:Yellowantphil|Yellowantphil]] 20:12, 11 September 2011 (GMT)

: Not sure about the Sound vs Audio - I use the term 'audio' to mean both sound and music, but you're right, if there are separate sound and music categories we don't really need an audio one as well. Feel free to update. [[INT16LE]] is perfectly fine too! I added a note to the data types page. -- [[User:Malvineous|Malvineous]] 22:30, 11 September 2011 (GMT)

== GamePage template ==

Should the GamePage template add the page to its own category? It seems a little odd that [[Wacky Wheels]] is not in the Wacky Wheels category. [[User:Yellowantphil|Yellowantphil]] 04:51, 16 September 2011 (GMT)
: I decided against this because there is a link to the game's page in the category intro at the top of the page. It seemed unnecessary having another link in amongst all the other pages. This was also because the game page was really only meant to be a summary, there wasn't supposed to be a huge amount of detail on it, only links to other pages with the detail (which then would appear in the category list.) I would imagine that, eventually, [[Wacky Wheels]] would be tweaked to move a lot of the content onto subpages. -- [[User:Malvineous|Malvineous]] 12:58, 16 September 2011 (GMT)

== Scope of the wiki ==

I don’t know how extensive you want the information to be on ModdingWiki... I added a few lists of audio and graphics files a while ago, and there will probably be other information that I’ll find out that’s potentially helpful for level editing but not directly related to it. I can move some information to my website if it starts to become out of scope for your wiki. I also sometimes end up documenting everything imaginable... there’s some minutiae on my website and possibly on your wiki that I ought to go through and delete. [[User:Yellowantphil|Yellowantphil]] 05:28, 10 October 2011 (GMT)

:Hmm, that's a difficult one - I'm always in favour of documenting more rather than less. Generally speaking if it's related to a game and it would help either a programmer writing a utility or a someone trying to change a game manually then it should be documented. About the only thing that comes to mind that's over documenting is when some small calculation is expressed in a couple of different programming languages, but I've left that in so people can just copy it rather than trying to figure it out from the text. But the [[Wacky Wheels]] page is probably the gold standard for what all wiki pages should look like :-) Do you have anything in particular you're unsure of whether it would fit here? -- [[User:Malvineous|Malvineous]] 10:07, 10 October 2011 (GMT)

::I was mainly thinking of the list of VOC files on [[Wacky Wheels Music and Sound Effects]] and the list of <tt>*.sp</tt> files on [[Wacky Wheels Graphics Formats]]. I have an expanded list of the <tt>*.sp</tt> files on my computer but it isn’t finished yet. I guess there isn’t all that much more Wacky Wheels information to be added to this wiki though. There is still some modding information on my website that ought to be moved over here, so that would take up another page or two. I’ve been lazy about doing Wacky Wheels stuff lately, but I might find some time for it this weekend.

::By the way, I guess that guy from Cascadia Games emailed you. It’s pretty interesting that WW might become an iPhone app. He told me that he was going to be using his own game engine, which sounds a lot easier than trying to get a hold of the WW source code and porting it. —[[User:Yellowantphil|Yellowantphil]] 16:46, 15 October 2011 (GMT)

::: I was going to say the list of VOCs might be overkill, but then the list of .sp files might be useful. To be honest, it's the sort of thing that you could probably omit if you were feeling lazy, but likewise I don't mind at all if you choose to include it, so since it's already there I'm happy to keep it.

::: Yes I did get an e-mail from Cascadia, I was going to pass along your details but it sounds like you're already aware of it! Using their own engine might make it a bit smoother than the original, as the jerkiness of turning is my only criticism of the game. -- [[User:Malvineous|Malvineous]] 00:14, 16 October 2011 (GMT)

== Wacky Wheels ==

Basically all of the WW modding information from my website is here now. I moved one page when I realized it should probably be capitalized to match the rest of the pages on this site... you can delete the redirect at [[Wacky Wheels high score files]] if you want to.

Now, I need to remove most of the modding information from my website and refer people here. Then we’ll have reached the glorious future where all WW modding information is in one place. I’m going to keep those two text files of notes on my website though—the information in them is disorganized and I think not 100% accurate, but they might have some information that isn’t here yet.

By the way, how’s Camoto going? I’m planning to use it to make a new WW level, but I won’t have time for it for a few more months. —[[User:Yellowantphil|Yellowantphil]]

: Sounds good! Thanks for all the effort you've put in by moving it across. I think Wacky Wheels is now the most completely documented game on the wiki! Also can't hurt leaving your own info up - sometimes it's nice to go back to the original source if something is unclear. Camoto's going well, but unfortunately I haven't had much time to work on it over the last few weeks. You probably won't be able to make much of a level until I add in the ability to select a tile from the tileset, but that's in progress and hopefully will be ready by the time you are! Keep me posted when you do start your level(s?) -- [[User:Malvineous|Malvineous]] 12:22, 2 February 2012 (GMT)

::Well, as I was reading some of the information on my website, I noticed that it isn’t written very well. I wrote those pages back when I had very little experience programming. Anyway, I’m planning to redesign my website soon, and this will save me from having to rewrite a few of those pages.

::The tile editor in Camoto as it is now is still certainly useful—I can add new tile types to a level using a binary editor and then move them around in Camoto. I think that it shouldn’t be too hard to make a new WW level using the Gimp and Camoto plus some binary editing. I recall having some problems with the route editor for the computer players, but I didn’t look into it at the time—I’ll let you know when I’m working with Camoto again, and I’ll try to come up with some useful bug reports or fixes if I run into problems. —[[User:Yellowantphil|Yellowantphil]] 14:06, 2 February 2012 (GMT)

== Catacomb ==

Hey [[User:Malvineous|Malvineous]], do you know anyone who has properly read the [[Inverse_Frequency_Sound_format|Inverse Sound Frequency]] file format and got the sound playing? I'm struggling with some fine details in my game. Sounds play near what they should sound like, but the sound quality is all crackly and some sounds play totally incorrect. I followed a basic [http://web.archive.org/web/20000818033701/http://www.dd.chalmers.se/~f98anga/projects/keen/sounds2raw.c code sample] by Anders Gavare. Does your tool support this? Interested in helping me figure this out? My current code is available at [https://code.google.com/p/cataclone/source/browse/trunk/src/catacomb/catacomb_sound.c catacomb_sound.c] - [[User:Eros|Eros]] 11:57, 5 May 2012 (GMT)
: Should this be moved to my talk page? - [[User:Eros|Eros]] 11:59, 5 May 2012 (GMT)
:: Probably best to keep it on my talk page if you want me to respond in a timely manner :-) I based my old utility off Anders' one too, but it's been a long time since I looked at the code. My latest utility doesn't support sound effects yet. I know Levellass has written a few utilities to play and edit those sound files, so I think your best bet would probably be to post over at the [http://www.keenmodding.org Keen:Modding] forum. Do note that PC Speaker effects do sound crackly at the best of times, though! Also make sure you've got the right audio format (8-bit vs 16-bit, signed vs unsigned) - I remember some inconsistencies there causing some very distorted results for me. I love the name 'Cataclone' - does your code compile under Linux? -- [[User:Malvineous|Malvineous]] 13:21, 5 May 2012 (GMT)
::: I currently compile the code using Code::Blocks with GCC 4.6 -std=gnu99. It *should* compile under Linux. But I haven't tested that out yet. [[Catacomb]] sounds also have flags attached to each one, It's not exactly the same specification as what it says @ the [[Inverse_Frequency_Sound_format|Inverse Sound Frequency]] format page. Perhaps the flags would make a difference to the sounds? I have the sound setup @ [https://code.google.com/p/cataclone/source/browse/trunk/src/sound_manager.c sound_manager.c] in the sound_manager_init() method. I use AUDIO_S16 (signed 16-bit) @ 22050 Hz with 2 channels. I have not added support for the priority of the sounds yet, I plan on doing that after I get them playing properly.
::: I found some information on the [[ROTT]] sound format here: [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/_rt_soun.h _rt_soun.h]. This format should be similar to Catacomb as ROTT was developed by [[Apogee]] using the [[Doom]] engine. Here are the flags for the sounds that they define:
#define SD_OVERWRITE 0x01
#define SD_WRITE 0x02
#define SD_LOOP 0x04
#define SD_PITCHSHIFTOFF 0x08
#define SD_PLAYONCE 0x10
::: There are also many other sound files for ROTT: [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/rt_sound.c], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/rt_sound.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/snd_reg.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/snd_shar.h], [http://src.gnu-darwin.org/ports/games/rottdc/work/rottdc-1.0-2/rott/sndcards.h]
:::: I tried it last night and I was able to get it to compile (after a few changes, like using '/' instead of '\' in a couple of #includes) but all I got was a black window and a beep sound, then nothing. How far advanced is the project? Should I expect more than that? I would expect small variations in the file formats between games, but I would be surprised if the core sound data has changed over time. -- [[User:Malvineous|Malvineous]] 02:38, 6 May 2012 (GMT)
::::: On Windows, you can run around the levels, collide with walls, collect items, etc... I still need to implement monsters, AI and power shots. However, that beep means that the sounds playing. (see line 71 in main.c: catacomb_sounds_play("foundsound");). I just committed the catacomb_data.h file. Update it accordingly, you should now see much more than a black screen.
:::::: Oh wow, that works really well now! I see what you mean by the sounds. You might have to output the PCM data to a .wav/.raw file and look at it in a sound editor to see what's going on. It sounds like there might be wrapping or something going on. Also some sounds (like being blocked by a door) play multiple times over the top of themselves. I guess this is what you meant by priority not being implemented (although maybe you wouldn't need to handle priority if you can play multiple sounds at the same time, unlike the real PC Speaker.) One suggestion - if you do decide to support Linux, abstract the calls that open files so that they search for filenames instead - that way you don't have to rename all the Catacomb files to be uppercase, since Linux has a case-sensitive filesystem and most filenames are usually all lowercase. -- [[User:Malvineous|Malvineous]] 03:42, 6 May 2012 (GMT)
::::::: I have exported the raw data to a file, then imported the raw data into Audacity using various settings. All of them sound like they do in the game, crackly and sometimes distorted. I really think its some sort of post FX used by the flags. As for files, I'll code some sort of SafeFileOpen, SafeFileClose functions like the id codebase that open files regardless of case when i get around to implementing the Linux version. - [[User:Eros|Eros]] 03:54, 6 May 2012 (GMT)
:::::::: If you can e-mail me one of the files (preferably a 'quiet' one that's not supposed to be crackly) I can take a look if you like - malvineous@shikadi.net -- [[User:Malvineous|Malvineous]] 03:57, 6 May 2012 (GMT)

== Merge ==

Is there a way to tag two pages such that it is clear that they should be merged?
For example, [[Crystal Caves Tileset Format]] describes the same format as [[Duke 1 Tileset Graphics]].[[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 21:00, 15 July 2013 (GMT)

: You can mention it on the talk page for one of the articles. Any suggestions as to what we should call the merged page? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 03:09, 20 July 2013 (GMT)

::Dark Ages is the first game that got released that uses this format, so ''Dark Ages Tileset Format'' could be the name, like all those formats that are named after Commander Keen 1-3.
::Or we name it after Duke Nukem 1, because that game is probably more popular than Dark Ages, Crystal Caves and Secret Agent, like [[Commander Keen 1-3 Level format]], although Slordax used it before Commander Keen 1-3 did.[[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 19:13, 20 July 2013 (GMT)

::: Yes I was thinking along the same lines, naming it after the first game that used the format. But then the release date doesn't necessarily indicate which game "invented" the format, if one game took longer to develop and was released late. I was wondering whether there is a common thread amongst all these games, such as the same programmer or company we could use instead. In many ways I would prefer a name like "Replogle tileset format" or "Apogee EGA tileset format". What do you think? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 23:36, 20 July 2013 (GMT)

:::: I've read the [http://www.3drealms.com/news/2006/04/the_apogee_legacy_15.html | Apogee Legacy interview with Peder Jungck] again today. He wrote the ProGraphx Toolbox.
:::: DN1.EXE contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox'',
:::: CC1.EXE contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox'',
:::: SAM1.EXE contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck'' and
:::: DA3.EXE contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox'' (DA1.EXE and DA2.exe contain gibberish).
:::: So I would suggest ''ProGraphx Toolbox tileset format''. Peder also wrote a book about the toolbox called ''Graphics Programming & Animation: Ultra-Fast Assembly Routines for EGA/VGA Graphics Animation''. Maybe that book has a better name for the file format. [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 11:03, 21 July 2013 (GMT)

::::: So we know of three different versions of the ProGraphx Toolbox. Dark Ages and Duke Nukem 1 use version 1.0. Each tileset is 8064 bytes long and is in a separate file. Crystal Caves uses version 1.5 and each tileset is 8003 bytes long, but they are all in the same file. Secret Agent uses version 2.0 Each tileset is again 8064 bytes long, they are all in the same file and the file is encrypted. [[User:Frenkel|Frenkel]] ([[User talk:Frenkel|talk]]) 17:00, 28 July 2013 (GMT)

:::::: Thanks for figuring all that out. I've merged the pages and changed the name to [[ProGraphx Toolbox tileset format]] as suggested. Please feel free to correct anything I have missed. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:40, 4 August 2013 (GMT)

== Guidelines for proper Wiki Editing ==
Dear Malvineous! Could you post the guidelines (or guide) for proper editing of the Wiki? [[User:The coder|The coder]] ([[User talk:The coder|talk]])

Eye of the Beholder

2014-12-12T20:26:25Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.dat, *.dec
| Format = [[Eye of the Beholder decorations Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.fnt
| Format = [[Eye of the Beholder bitmap font Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.inf, *.dro, *.elo
| Format = [[Eye of the Beholder maze information Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.maz
| Format = [[Eye of the Beholder maze Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Eye of the Beholder Maze Information Format

2014-12-12T20:25:30Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

.dro files are used in localized versions such as the spanish one. .dro files are non-compressed .inf files.
.elo files are used in some localized versions such as the german one. .elo files are non-compressed .inf files without header.

'''General'''
Each maze consist of a .maz file and an accompaning .inf file. This document describes the .inf file and how it relates to the .maz files.
The .inf files are standard CPS files. However the german and spanish versions are uncompressed. This document assumes that you've depacked the .inf files using for instance uncps.exe.

'''Header'''
<pre>
struct Monster
{
unsigned char index;
unsigned char levelType;
unsigned short pos;
unsigned char subpos;
unsigned char direction;
unsigned char type;
unsigned char picture;
unsigned char phase;
unsigned char pause;
unsigned short weapon;
unsigned short pocket_item;
}
</pre>

Position gives the x and y values. It's lower 5 bits are the y coordinate value and the next 5 bits are the x coordinate value.
<pre>
x_pos = (pos >> 5) & 0x1F;
y_pos = pos & 0x1F;
</pre>

Values sign must be confirmed.
<pre>
struct Inf
{
unsigned short triggersOffset;
char mazeName[12];
char vmpVcnName[12];
char paletteName[12];
unsigned char unknown[9];
unsigned char monster1CompressionMethod;
unsigned char monster1Name[12];
unsigned char monster2CompressionMethod;
unsigned char monster2Name[12];
unsigned char unknown[5];
Monster monsters[30];
unsigned short nbrDecCommands;
DecCommand commands[nbrDecCommands];
}
</pre>

'''Decoration data'''
After the header comes the decoration data. It's loaded as a command sequence. The first unsigned short determines number of commands to execute. After that follows the first command code. Each command code is one byte.

Command codes
<pre>
0xec (Load overlay image picture + overlay image rectangle data)

graphics data name, 12 bytes containing a null terminated string. Points to a .cps file containg wall graphics data.
rectangles data name, 12 bytes containing a null terminated string. Points to a .dat file containing rectangular data that point into the graphics data.

0xfb (Define wall mapping)

struct WallMapping
{
unsigned char wallMappingIndex; /* This is the index used by the .maz file. */
unsigned char wallType; /* Index to what backdrop wall type that is being used. */
unsigned char decorationID; /* Index to and optional overlay decoration image in
the DecorationData.decorations array in the
[[eob.dat|.dat]] files. */
unsigned char unknownFlags1;
unsigned char unknownFlags2;
};
</pre>

'''Event data'''
After the decoration data comes a sequence of event data. It's also loaded as a command sequence. Each command code is one byte.
<pre>
Command codes

0xff (Set wall)
0xfe (Change wall)
0xfd (Open door)
0xfc (Close coor)
0xfb (Create monster)
0xfa (Teleport)
0xf9 (Steal small item)
0xf8 (Message)
0xf7 (Set flag)
0xf6 (Sound)
0xf5 (Clear flag)
0xf4 (Heal)
0xf3 (Damage)
0xf2 (Jump)
0xf1 (End code)
0xf0 (Return)
0xef (Call)
0xee (Conditions)
0xed (Item consume)
0xec (Change level)
0xeb (Give experience)
0xea (New item)
0xe9 (Launcher)
0xe8 (Turn)
0xe7 (Identify all items)
0xe6 (Encounters)
0xe5 (Wait)
0xe4 (Update screen)
0xe3 (Text menu)
0xe2 (Special window pictures)
</pre>

Each command code is executed using a parsing function for that specific code. Number of bytes following each code is very specific to what command it is.
<pre>
0xff (Set wall)

unsigned char subcode=nextUnsignedChar();

switch (subcode)
{
case 0xf7: // Set complete maze block (all four walls)
unsigned short position=nextUnsignedShort();
unsigned char wallMappingIndex=nextUnsignedChar();
for (int i=0; i<4; i++)
maze[position][i]=wallMappingIndex;
break;

case 0xe9; // Change one wall
unsigned short position=nextUnsignedShort();
unsigned char wallMappingIndex=nextUnsignedChar();
unsigned char direction=nextUnsignedChar();
maze[position][direction]=wallMappingIndex;
break;

case 0xed; // Turn party
Party.facing = nextUnsignedChar();
};

0xfe (Change wall)

unsigned char subcode=nextUnsignedChar();

switch (subcode)
{
case 0xf7: //Flip four sides
unsigned short position=nextUnsignedShort();
unsigned char sourceWallMappingIndex=nextUnsignedChar();
unsigned char destinationWallMappingIndex=nextUnsignedChar();
for (int i=0; i<4; i++)
{
if (maze[position][i] == sourceWallMappingIndex)
maze[position][i] = destinationWallMappingIndex;
}
break;

case 0xe9;// Change one wall
unsigned short position=nextUnsignedShort();
unsigned char direction=nextUnsignedChar();
unsigned char sourceWallMappingIndex=nextUnsignedChar();
unsigned char destinationWallMappingIndex=nextUnsignedChar();
if (maze[position][direction] == sourceWallMappingIndex)
maze[position][direction] = destinationWallMappingIndex;
break;

case 0xea; // Unknown
unsigned short unknown=nextUnsigndShort();
break;
};

0xfb (Monster Creation)

char MoNo;
char MoTime;
short int position;
char subpos;
char facing;
char type;
char pic;
char phase;
char pause;
short int weapon; /* Item Number */
short int pocket; /* Dropped on Monster killed */

0xf6 (Sound)

char SoundId;
short int position;

0xf6 (Sound) in the demo version of the EOB1

char SoundId;
</pre>

All other commands, except 0xf6, are identical in all EOB1 versions.

Far from all command codes have been documented here, however most of it have already been reverse engineered. Feel free to check the source code for the script decompiler: Script Decompiler 2 at the tools section.

<pre>
.inf dump with comments
EOB1 INF file resourced for assembler 68000 (To See here for all the INF files
EOB-InfFile-Asm.lha
EOB-InfFile-Asm.lha

Details
Download
91 KB

BOPT uo+
BOPT ue-
BOPT ua+
OUTPUT LEVEL1.INF.dec
;Source Created by "EOB Langage File ReSourcerINF" Beta
;A Tool done by CFou! on June 2006
Start
Hunk0:
dc.b Hunk3-Start,(Hunk3-Start)/$100 ; dc.w $B10A
; Maze name
dc.b 'level1.maz',0,0
; VCN/VMP name
dc.b 'brick',0,'.maz',0,0
; Palette name
dc.b 'brick',0,'.maz',0,0
_0026:
; Nb of doors and doorknobs
dc.w $0000,$FF03
_002A:
; Max monster / tdiff etc
dc.b $00,$00,$00,$00,$00
_002F:
; Number of procedure for extraction of monster picture
dc.b $01
; Name Of Monster pic CPS file
dc.b 'kobold',0,'maz',0,0
_003C:
; Number of procedure for extraction of monster picture
dc.b $00
; Name Of Monster pic CPS file
dc.b 'leech',0,0,'maz',0,0
_0049:
; Timer0 | Timer 1| Timerdiff (in Ticks)
dc.b $00,$19
; Timer0 | Timer 1| Timerdiff
dc.b $01,$23
; End of Timer
dc.b $FF
_004E:
; Monster Description X 30: Start point and so on
dc.b $01,$00,$14,$01,$04,$02,$00,$00,$06,$00,$04,$00,$00,$00
dc.b $02,$00,$F4,$00,$04,$02,$00,$00,$06,$00,$00,$00,$04,$00
dc.b $03,$00,$15,$01,$04,$02,$00,$00,$06,$00,$04,$00,$00,$00
dc.b $04,$00,$F5,$00,$04,$02,$00,$00,$06,$00,$04,$00,$37,$00
dc.b $05,$00,$B4,$01,$00,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $06,$00,$B4,$01,$01,$00,$00,$00,$04,$00,$00,$00,$04,$00
dc.b $07,$00,$B4,$01,$02,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $08,$00,$B4,$01,$03,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $09,$00,$4A,$02,$04,$01,$00,$00,$05,$00,$00,$00,$04,$00
dc.b $0A,$00,$4B,$02,$04,$03,$00,$00,$05,$00,$04,$00,$00,$00
dc.b $0B,$00,$4C,$02,$04,$01,$00,$00,$05,$00,$04,$00,$00,$00
dc.b $0C,$00,$2C,$03,$02,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $0D,$00,$2C,$03,$03,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $0E,$00,$59,$02,$02,$02,$00,$00,$04,$00,$00,$00,$04,$00
dc.b $0F,$00,$59,$02,$03,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $10,$00,$6B,$02,$04,$01,$00,$00,$06,$00,$04,$00,$3B,$00
dc.b $11,$00,$2C,$02,$04,$02,$00,$00,$06,$00,$00,$00,$00,$00
dc.b $12,$00,$8F,$01,$04,$02,$00,$00,$01,$00,$00,$00,$00,$00
dc.b $13,$01,$86,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $14,$01,$66,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $15,$01,$45,$03,$04,$01,$01,$01,$05,$00,$00,$00,$00,$00
dc.b $16,$01,$2A,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $17,$01,$E8,$02,$04,$01,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $18,$01,$EF,$02,$04,$03,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
_01F2:
Hunk1:
; Nb of $EC & $FB command Hunk 1
dc.w $1B00
; Command $EC & $FB
dc.b $EC
dc.b 'brick1',0,'maz',0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$27,$01,$00,$03,$04
dc.b $FB,$28,$01,$01,$04,$04
dc.b $FB,$3E,$01,$17,$02,$04
dc.b $FB,$2B,$01,$28,$02,$04
dc.b $FB,$3F,$01,$16,$02,$04
dc.b $FB,$32,$01,$04,$02,$04
dc.b $FB,$41,$01,$1A,$02,$04
dc.b $FB,$2F,$01,$30,$02,$04
dc.b $FB,$2C,$01,$2F,$02,$04
dc.b $FB,$2A,$01,$31,$02,$04
dc.b $EC
dc.b 'brick2',0,'at',0,0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$1A,$00,$1C,$00,$03
dc.b $FB,$17,$04,$21,$00,$05
dc.b $FB,$18,$05,$22,$00,$05
dc.b $FB,$1C,$00,$1D,$00,$03
dc.b $FB,$19,$00,$FF,$00,$07
dc.b $FB,$3C,$01,$24,$03,$04
dc.b $FB,$3D,$01,$25,$04,$04
dc.b $FB,$37,$01,$1E,$03,$04
dc.b $FB,$38,$01,$1F,$04,$04
dc.b $FB,$1D,$01,$20,$0A,$84
dc.b $FB,$33,$01,$26,$02,$04
dc.b $FB,$3A,$01,$23,$00,$04
dc.b $EC
dc.b 'brick3',0,'at',0,0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$45,$00,$27,$02,$04
dc.b $FB,$31,$00,$2D,$02,$04
;$1B Command Resourced
Hunk2:
; New Section
_02CF: dc.b $EE,$E0,$01
_02D2: dc.b $FF,$EE,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_02D6: dc.b $EE,$ED,$01
_02D9: dc.b $FF,$EE,_0308-Start,(_0308-Start)/$100 ; dc.b $08,$03
_02DD: dc.b $EE,$EF,$1F,$00
_02E1: dc.b $FF,$EE,_02EA-Start,(_02EA-Start)/$100 ; dc.b $EA,$02
_02E5: dc.b $E6,$0A
_02E7: dc.b $F7,$EF,$1F
_02EA: dc.b $F8,"going down...",0,$05,$00
_02FB: dc.b $F6,$4F,$00,$00
_02FF: dc.b $EC,$E5,$02,$F3,$02,$01
_0305: dc.b $F2,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_0308: dc.b $F8,"you can't go that way.",0,$0F,$00
_0322: dc.b $F6,$1D,$00,$00
_0326: dc.b $EE,$01,$00
_0329: dc.b $FF,$EE,_0333-Start,(_0333-Start)/$100 ; dc.b $33,$03
_032D: dc.b $FA,$E8,$00,$00,$12,$03
_0333: dc.b $EE,$01,$01
_0336: dc.b $FF,$EE,_0340-Start,(_0340-Start)/$100 ; dc.b $40,$03
_033A: dc.b $FA,$E8,$00,$00,$F1,$02
_0340: dc.b $EE,$01,$02
_0343: dc.b $FF,$EE,_034D-Start,(_034D-Start)/$100 ; dc.b $4D,$03
_0347: dc.b $FA,$E8,$00,$00,$D2,$02
_034D: dc.b $EE,$01,$03
_0350: dc.b $FF,$EE,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_0354: dc.b $FA,$E8,$00,$00,$F3,$02
_035A: dc.b $EE,$E0,$04
_035D: dc.b $FF,$EE,_0395-Start,(_0395-Start)/$100 ; dc.b $95,$03
_0361: dc.b $EE,$01,$00
_0364: dc.b $FF,$EE,_036E-Start,(_036E-Start)/$100 ; dc.b $6E,$03
_0368: dc.b $FA,$F5,$F2,$02,$12,$03
_036E: dc.b $EE,$01,$01
_0371: dc.b $FF,$EE,_037B-Start,(_037B-Start)/$100 ; dc.b $7B,$03
_0375: dc.b $FA,$F5,$F2,$02,$F1,$02
_037B: dc.b $EE,$01,$02
_037E: dc.b $FF,$EE,_0388-Start,(_0388-Start)/$100 ; dc.b $88,$03
_0382: dc.b $FA,$F5,$F2,$02,$D2,$02
_0388: dc.b $EE,$01,$03
_038B: dc.b $FF,$EE,_0395-Start,(_0395-Start)/$100 ; dc.b $95,$03
_038F: dc.b $FA,$F5,$F2,$02,$F3,$02
_0395:
dc.b $F1
_0396: dc.b $EE,$EF,$0A,$00
_039A: dc.b $FF,$EE,_03A5-Start,(_03A5-Start)/$100 ; dc.b $A5,$03
_039E: dc.b $EB,$E2,$40,$06
_03A2: dc.b $F7,$EF,$0A
_03A5:
dc.b $F1
_03A6: dc.b $EB,$E2,$10,$27
_03AA:
dc.b $F1
_03AB: dc.b $EE,$EF,$08,$00
_03AF: dc.b $FF,$EE,_03BA-Start,(_03BA-Start)/$100 ; dc.b $BA,$03
_03B3: dc.b $EB,$E2,$40,$06
_03B7: dc.b $F7,$EF,$08
_03BA:
dc.b $F1
_03BB: dc.b $EE,$EF,$04,$00
_03BF: dc.b $FF,$EE,_03CA-Start,(_03CA-Start)/$100 ; dc.b $CA,$03
_03C3: dc.b $EB,$E2,$90,$01
_03C7: dc.b $F7,$EF,$04
_03CA:
dc.b $F1
_03CB: dc.b $F6,$01,$AD,$01
_03CF: dc.b $FE,$EA,$AE,$01
_03D3: dc.b $EE,$EF,$01,$00
_03D7: dc.b $FF,$EE,_03E2-Start,(_03E2-Start)/$100 ; dc.b $E2,$03
_03DB: dc.b $EB,$E2,$20,$03
_03DF: dc.b $F7,$EF,$01
_03E2:
dc.b $F1
_03E3: dc.b $EE,$F7,$75,$01,$01
_03E8: dc.b $FE,$EE,_03F6-Start,(_03F6-Start)/$100 ; dc.b $F6,$03
_03EC: dc.b $FF,$F7,$11,$02,$01
_03F1: dc.b $FF,$F7,$2E,$03,$01
_03F6: dc.b $EE,$EF,$02,$00
_03FA: dc.b $FF,$EE,_0405-Start,(_0405-Start)/$100 ; dc.b $05,$04
_03FE: dc.b $EB,$E2,$90,$01
_0402: dc.b $F7,$EF,$02
_0405:
dc.b $F1
_0406: dc.b $EE,$F7,$11,$02,$01
_040B: dc.b $FE,$EE,_041F-Start,(_041F-Start)/$100 ; dc.b $1F,$04
_040F: dc.b $FF,$E9,$C9,$02,$00,$01
_0415: dc.b $FF,$F7,$75,$01,$01
_041A: dc.b $FF,$F7,$4D,$03,$01
_041F: dc.b $F7,$EF,$02
_0422:
dc.b $F1
_0423: dc.b $EE,$E9,$00,$B7,$01,$01
_0429: dc.b $FE,$EE,_0444-Start,(_0444-Start)/$100 ; dc.b $44,$04
_042D: dc.b $F6,$07,$B7,$01
_0431: dc.b $FE,$EA,$B6,$01
_0435: dc.b $EE,$EF,$05,$00
_0439: dc.b $FF,$EE,_0444-Start,(_0444-Start)/$100 ; dc.b $44,$04
_043D: dc.b $EB,$E2,$20,$03
_0441: dc.b $F7,$EF,$05
_0444:
dc.b $F1
_0445: dc.b $EE,$F7,$D6,$01,$1C
_044A: dc.b $FF,$EE,_0465-Start,(_0465-Start)/$100 ; dc.b $65,$04
_044E: dc.b $F6,$0C,$D6,$01
_0452: dc.b $FE,$EA,$B6,$01
_0456: dc.b $EE,$EF,$07,$00
_045A: dc.b $FF,$EE,_0465-Start,(_0465-Start)/$100 ; dc.b $65,$04
_045E: dc.b $EB,$E2,$20,$03
_0462: dc.b $F7,$EF,$07
_0465:
dc.b $F1
_0466: dc.b $EE,$E0,$01
_0469: dc.b $FF,$F5,$FF,$36,$02,$00
_046F: dc.b $FF,$F9,$E0,$04,$FF
_0474: dc.b $F5,$FF,$36,$02,$01
_0479: dc.b $FF,$F9,$F1,$36,$02,$00
_047F: dc.b $FF,$F9,$F8,$EE,_048C-Start,(_048C-Start)/$100 ; dc.b $8C,$04
_0485: dc.b $F6,$0C,$36,$02
_0489: dc.b $FD,$76,$02
_048C: dc.b $EE,$E0,$02
_048F: dc.b $FF,$F5,$FF,$36,$02,$00
_0495: dc.b $FF,$F9,$E0,$08,$FF
_049A: dc.b $F5,$FF,$36,$02,$00
_049F: dc.b $FF,$F9,$F1,$36,$02,$00
_04A5: dc.b $FF,$F9,$F8,$EE,_04B2-Start,(_04B2-Start)/$100 ; dc.b $B2,$04
_04AB: dc.b $F6,$0C,$36,$02
_04AF: dc.b $FC,$76,$02
_04B2:
dc.b $F1
_04B3: dc.b $F6,$01,$52,$02
_04B7: dc.b $FE,$EA,$53,$02
_04BB:
dc.b $F1
_04BC: dc.b $EE,$E9,$01,$6E,$02,$01
_04C2: dc.b $FE,$EE,_04DD-Start,(_04DD-Start)/$100 ; dc.b $DD,$04
_04C6: dc.b $F6,$07,$6E,$02
_04CA: dc.b $FE,$EA,$4E,$02
_04CE: dc.b $EE,$EF,$05,$00
_04D2: dc.b $FF,$EE,_04DD-Start,(_04DD-Start)/$100 ; dc.b $DD,$04
_04D6: dc.b $EB,$E2,$20,$03
_04DA: dc.b $F7,$EF,$05
_04DD:
dc.b $F1
_04DE: dc.b $EE,$F7,$4D,$02,$1C
_04E3: dc.b $FF,$EE,_04FE-Start,(_04FE-Start)/$100 ; dc.b $FE,$04
_04E7: dc.b $F6,$0C,$4D,$02
_04EB: dc.b $FE,$EA,$4E,$02
_04EF: dc.b $EE,$EF,$07,$00
_04F3: dc.b $FF,$EE,_04FE-Start,(_04FE-Start)/$100 ; dc.b $FE,$04
_04F7: dc.b $EB,$E2,$20,$03
_04FB: dc.b $F7,$EF,$07
_04FE:
dc.b $F1
_04FF: dc.b $F6,$07,$B2,$02
_0503: dc.b $F6,$0D,$93,$02
_0507: dc.b $FE,$F7,$93,$02,$00,$01
_050D: dc.b $FA,$F3,$93,$02,$73,$02
_0513: dc.b $EE,$EF,$06,$00
_0517: dc.b $FF,$EE,_0522-Start,(_0522-Start)/$100 ; dc.b $22,$05
_051B: dc.b $EB,$E2,$40,$06
_051F: dc.b $F7,$EF,$06
_0522:
dc.b $F1
_0523: dc.b $F6,$07,$BA,$02
_0527: dc.b $FA,$F3,$99,$02,$79,$02
_052D: dc.b $F6,$0D,$99,$02
_0531: dc.b $FE,$F7,$99,$02,$00,$01
_0537: dc.b $EE,$EF,$06,$00
_053B: dc.b $FF,$EE,_0546-Start,(_0546-Start)/$100 ; dc.b $46,$05
_053F: dc.b $EB,$E2,$40,$06
_0543: dc.b $F7,$EF,$06
_0546:
dc.b $F1
_0547: dc.b $EE,$E9,$01,$E7,$02,$01
_054D: dc.b $FE,$EE,_0568-Start,(_0568-Start)/$100 ; dc.b $68,$05
_0551: dc.b $F6,$07,$E7,$02
_0555: dc.b $FE,$EA,$C8,$02
_0559: dc.b $EE,$EF,$05,$00
_055D: dc.b $FF,$EE,_0568-Start,(_0568-Start)/$100 ; dc.b $68,$05
_0561: dc.b $EB,$E2,$20,$03
_0565: dc.b $F7,$EF,$05
_0568:
dc.b $F1
_0569: dc.b $F6,$07,$C9,$02
_056D: dc.b $EE,$E9,$00,$C9,$02,$01
_0573: dc.b $FE,$EE,_0590-Start,(_0590-Start)/$100 ; dc.b $90,$05
_0577: dc.b $FE,$EA,$C8,$02
_057B: dc.b $FF,$E9,$E7,$02,$01,$01
_0581: dc.b $EE,$EF,$05,$00
_0585: dc.b $FF,$EE,_0590-Start,(_0590-Start)/$100 ; dc.b $90,$05
_0589: dc.b $EB,$E2,$20,$03
_058D: dc.b $F7,$EF,$05
_0590:
dc.b $F1
_0591: dc.b $F6,$0C,$11,$03
_0595: dc.b $FD,$F1,$02
_0598:
dc.b $F1
_0599: dc.b $EE,$E0,$01
_059C: dc.b $FF,$F5,$FF,$F0,$02,$00
_05A2: dc.b $FF,$F9,$EE,_05AE-Start,(_05AE-Start)/$100 ; dc.b $AE,$05
_05A7: dc.b $F6,$0C,$F0,$02
_05AB: dc.b $FC,$F1,$02
_05AE: dc.b $EE,$E0,$04
_05B1: dc.b $FF,$F1,$F0,$02,$00
_05B6: dc.b $FF,$F5,$FF,$F0,$02,$02
_05BC: dc.b $FD,$F9,$F9,$EE,_05C9-Start,(_05C9-Start)/$100 ; dc.b $C9,$05
_05C2: dc.b $F6,$0C,$F0,$02
_05C6: dc.b $FC,$F1,$02
_05C9:
dc.b $F1
_05CA: dc.b $EE,$EF,$00,$00
_05CE: dc.b $FF,$EE,_05F1-Start,(_05F1-Start)/$100 ; dc.b $F1,$05
_05D2: dc.b $F8,"it smells terrible here.",0,$02,$00
_05EE: dc.b $F7,$EF,$00
_05F1:
dc.b $F1
_05F2: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_0624: dc.b $EE,$EF,$03,$00
_0628: dc.b $FF,$EE,_0633-Start,(_0633-Start)/$100 ; dc.b $33,$06
_062C: dc.b $EB,$E2,$20,$03
_0630: dc.b $F7,$EF,$03
_0633:
dc.b $F1
_0634: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_0657: dc.b $EE,$EF,$03,$00
_065B: dc.b $FF,$EE,_0666-Start,(_0666-Start)/$100 ; dc.b $66,$06
_065F: dc.b $EB,$E2,$20,$03
_0663: dc.b $F7,$EF,$03
_0666: dc.b $EE,$E7,$F5,$00
_066A: dc.b $FF,$EF,$01,$00
_066E: dc.b $FF,$F9,$EE,_067C-Start,(_067C-Start)/$100 ; dc.b $7C,$06
_0673: dc.b $EA,$3A,$00,$FF,$FF,$00
_0679: dc.b $F7,$EF,$01
_067C:
dc.b $F1
_067D: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_06AF: dc.b $EE,$EF,$03,$00
_06B3: dc.b $FF,$EE,_06BE-Start,(_06BE-Start)/$100 ; dc.b $BE,$06
_06B7: dc.b $EB,$E2,$20,$03
_06BB: dc.b $F7,$EF,$03
_06BE:
dc.b $F1
_06BF: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_06E2: dc.b $EE,$EF,$03,$00
_06E6: dc.b $FF,$EE,_06F1-Start,(_06F1-Start)/$100 ; dc.b $F1,$06
_06EA: dc.b $EB,$E2,$20,$03
_06EE: dc.b $F7,$EF,$03
_06F1:
dc.b $F1
_06F2: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_0715: dc.b $EE,$EF,$03,$00
_0719: dc.b $FF,$EE,_0724-Start,(_0724-Start)/$100 ; dc.b $24,$07
_071D: dc.b $EB,$E2,$20,$03
_0721: dc.b $F7,$EF,$03
_0724:
dc.b $F1
_0725: dc.b $EE,$EF,$03,$00
_0729: dc.b $FF,$EE,_0734-Start,(_0734-Start)/$100 ; dc.b $34,$07
_072D: dc.b $EB,$E2,$20,$03
_0731: dc.b $F7,$EF,$03
_0734: dc.b $EE,$F1,$CE,$01,$01
_0739: dc.b $FF,$EE,_07AF-Start,(_07AF-Start)/$100 ; dc.b $AF,$07
_073D: dc.b $EE,$E9,$03,$CF,$01,$2C
_0743: dc.b $FF,$EE,_0789-Start,(_0789-Start)/$100 ; dc.b $89,$07
_0747: dc.b $F8,"something scurries deeper into the floor drain.",0,$02,$00
_077A: dc.b $FF,$E9,$CF,$01,$03,$3E
_0780: dc.b $FF,$E9,$CF,$01,$01,$2C
_0786: dc.b $F2,_07AC-Start,(_07AC-Start)/$100 ; dc.b $AC,$07
_0789: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_07AC: dc.b $F2,_081E-Start,(_081E-Start)/$100 ; dc.b $1E,$08
_07AF: dc.b $EE,$E9,$01,$CF,$01,$2C
_07B5: dc.b $FF,$EE,_07FB-Start,(_07FB-Start)/$100 ; dc.b $FB,$07
_07B9: dc.b $F8,"something scurries deeper into the floor drain.",0,$02,$00
_07EC: dc.b $FF,$E9,$CF,$01,$01,$3E
_07F2: dc.b $FF,$E9,$CF,$01,$03,$2C
_07F8: dc.b $F2,_081E-Start,(_081E-Start)/$100 ; dc.b $1E,$08
_07FB: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_081E:
dc.b $F1
_081F: dc.b $FF,$E9,$CF,$01,$03,$2C
_0825: dc.b $FF,$E9,$CF,$01,$01,$2C
_082B:
dc.b $F1
_082C: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_085E: dc.b $EE,$EF,$03,$00
_0862: dc.b $FF,$EE,_086D-Start,(_086D-Start)/$100 ; dc.b $6D,$08
_0866: dc.b $EB,$E2,$20,$03
_086A: dc.b $F7,$EF,$03
_086D:
dc.b $F1
_086E: dc.b $EE,$EF,$03,$00
_0872: dc.b $FF,$EE,_087D-Start,(_087D-Start)/$100 ; dc.b $7D,$08
_0876: dc.b $EB,$E2,$20,$03
_087A: dc.b $F7,$EF,$03
_087D: dc.b $EE,$DD,$04,$01
_0881: dc.b $FF,$EE,_08A7-Start,(_08A7-Start)/$100 ; dc.b $A7,$08
_0885: dc.b $F8,"kobold rune for 'entrance'.",0,$02,$00
_08A4: dc.b $F2,_08C5-Start,(_08C5-Start)/$100 ; dc.b $C5,$08
_08A7: dc.b $F8,"this rune is unrecognized.",0,$02,$00
_08C5:
dc.b $F1
_08C6: dc.b $EE,$EF,$03,$00
_08CA: dc.b $FF,$EE,_08D5-Start,(_08D5-Start)/$100 ; dc.b $D5,$08
_08CE: dc.b $EB,$E2,$20,$03
_08D2: dc.b $F7,$EF,$03
_08D5: dc.b $EE,$DD,$04,$01
_08D9: dc.b $FF,$EE,_08FF-Start,(_08FF-Start)/$100 ; dc.b $FF,$08
_08DD: dc.b $F8,"kobold rune for 'entrance'.",0,$02,$00
_08FC: dc.b $F2,_091D-Start,(_091D-Start)/$100 ; dc.b $1D,$09
_08FF: dc.b $F8,"this rune is unrecognized.",0,$02,$00
_091D:
dc.b $F1
_091E: dc.b $EE,$F5,$05,$0C,$03,$00
_0924: dc.b $FB,$F0,$01,$00
_0928: dc.b $FF,$F9,$EE,_0962-Start,(_0962-Start)/$100 ; dc.b $62,$09
_092D: dc.b $F8,"special quest for this level!",0,$03,$00
_094E: dc.b $F6,$1C,$00,$00
_0952: dc.b $F7,$F0,$01
_0955: dc.b $ED,$05,$0C,$03
_0959: dc.b $EA,$31,$00,$0C,$03,$08
_095F: dc.b $F7,$F0,$01
_0962: dc.b $EE,$EF,$09,$00
_0966: dc.b $FF,$EE,_0971-Start,(_0971-Start)/$100 ; dc.b $71,$09
_096A: dc.b $EB,$E2,$90,$01
_096E: dc.b $F7,$EF,$09
_0971:
dc.b $F1
_0972: dc.b $F8,"fallen rocks block the way.",0,$02,$00
_0991:
dc.b $F1
_0992: dc.b $FF,$E9,$CA,$01,$02,$31
_0998:
dc.b $F1
_0999: dc.b $FF,$E9,$CA,$01,$02,$45
_099F:
dc.b $F1
_09A0: dc.b $EE,$E9,$03,$62,$00,$08
_09A6: dc.b $FF,$EE,_0A86-Start,(_0A86-Start)/$100 ; dc.b $86,$0A
_09AA: dc.b $EE,$E7,$E1,$26
_09AE: dc.b $FF,$E7,$F6,$01
_09B2: dc.b $FF,$F9,$EE,_09C3-Start,(_09C3-Start)/$100 ; dc.b $C3,$09
_09B7: dc.b $F6,$0E,$81,$00
_09BB: dc.b $FD,$62,$00
_09BE: dc.b $ED,$FF
_09C0: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_09C3: dc.b $EE,$E7,$E1,$26
_09C7: dc.b $FF,$EE,_09E5-Start,(_09E5-Start)/$100 ; dc.b $E5,$09
_09CB: dc.b $F8,"it doesn't fit.",0,$06,$00
_09DE: dc.b $F6,$51,$81,$00
_09E2: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_09E5: dc.b $EE,$E7,$E1,$1C
_09E9: dc.b $FF,$EE,_0A66-Start,(_0A66-Start)/$100 ; dc.b $66,$0A
_09ED: dc.b $EE,$DC,$08,$01
_09F1: dc.b $FF,$EE,_0A43-Start,(_0A43-Start)/$100 ; dc.b $43,$0A
_09F5: dc.b $F6,$51,$81,$00
_09F9: dc.b $F8,"failed lock pick attempt.",0,$05,$00
_0A16: dc.b $EE,$DB,$01,$64,$00,$01
_0A1C: dc.b $FF,$EE,_0A40-Start,(_0A40-Start)/$100 ; dc.b $40,$0A
_0A20: dc.b $F6,$52,$00,$00
_0A24: dc.b $F8,"the lock picks break!.",0,$06,$00
_0A3E: dc.b $ED,$FF
_0A40: dc.b $F2,_0A63-Start,(_0A63-Start)/$100 ; dc.b $63,$0A
_0A43: dc.b $F8,"only a thief can pick locks.",0,$06,$00
_0A63: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_0A66: dc.b $F8,"this lock requires a key.",0,$0F,$00
_0A83: dc.b $F2,_0AA2-Start,(_0AA2-Start)/$100 ; dc.b $A2,$0A
_0A86: dc.b $F8,"the lock appears jammed.",0,$06,$00
_0AA2:
dc.b $F1
_0AA3: dc.b $FF,$E9,$22,$00,$03,$31
_0AA9:
dc.b $F1
_0AAA: dc.b $FF,$E9,$22,$00,$03,$45
_0AB0:
dc.b $F1
_0AB1:
Hunk3:
; Nb reloc info
dc.b $26,$00
dc.b $F2,$02,$A8,_02CF-Start,(_02CF-Start)/$100 ; dc.b $CF,$02
dc.b $F1,$02,$08,_0396-Start,(_0396-Start)/$100 ; dc.b $96,$03
dc.b $AA,$01,$08,_03A6-Start,(_03A6-Start)/$100 ; dc.b $A6,$03
dc.b $96,$02,$08,_03AB-Start,(_03AB-Start)/$100 ; dc.b $AB,$03
dc.b $CE,$01,$60,_03BB-Start,(_03BB-Start)/$100 ; dc.b $BB,$03
dc.b $AD,$01,$00,_03CB-Start,(_03CB-Start)/$100 ; dc.b $CB,$03
dc.b $50,$01,$08,_03E3-Start,(_03E3-Start)/$100 ; dc.b $E3,$03
dc.b $91,$01,$08,_0406-Start,(_0406-Start)/$100 ; dc.b $06,$04
dc.b $B7,$01,$00,_0423-Start,(_0423-Start)/$100 ; dc.b $23,$04
dc.b $D6,$01,$08,_0445-Start,(_0445-Start)/$100 ; dc.b $45,$04
dc.b $36,$02,$78,_0466-Start,(_0466-Start)/$100 ; dc.b $66,$04
dc.b $52,$02,$00,_04B3-Start,(_04B3-Start)/$100 ; dc.b $B3,$04
dc.b $6E,$02,$00,_04BC-Start,(_04BC-Start)/$100 ; dc.b $BC,$04
dc.b $4D,$02,$08,_04DE-Start,(_04DE-Start)/$100 ; dc.b $DE,$04
dc.b $B2,$02,$00,_04FF-Start,(_04FF-Start)/$100 ; dc.b $FF,$04
dc.b $BA,$02,$00,_0523-Start,(_0523-Start)/$100 ; dc.b $23,$05
dc.b $E7,$02,$00,_0547-Start,(_0547-Start)/$100 ; dc.b $47,$05
dc.b $C9,$02,$00,_0569-Start,(_0569-Start)/$100 ; dc.b $69,$05
dc.b $11,$03,$00,_0591-Start,(_0591-Start)/$100 ; dc.b $91,$05
dc.b $F0,$02,$28,_0599-Start,(_0599-Start)/$100 ; dc.b $99,$05
dc.b $79,$02,$08,_05CA-Start,(_05CA-Start)/$100 ; dc.b $CA,$05
dc.b $07,$03,$00,_05F2-Start,(_05F2-Start)/$100 ; dc.b $F2,$05
dc.b $CD,$02,$00,_0634-Start,(_0634-Start)/$100 ; dc.b $34,$06
dc.b $14,$03,$00,_067D-Start,(_067D-Start)/$100 ; dc.b $7D,$06
dc.b $B8,$02,$00,_06BF-Start,(_06BF-Start)/$100 ; dc.b $BF,$06
dc.b $32,$02,$00,_06F2-Start,(_06F2-Start)/$100 ; dc.b $F2,$06
dc.b $CF,$01,$00,_0725-Start,(_0725-Start)/$100 ; dc.b $25,$07
dc.b $8E,$01,$08,_081F-Start,(_081F-Start)/$100 ; dc.b $1F,$08
dc.b $94,$01,$00,_082C-Start,(_082C-Start)/$100 ; dc.b $2C,$08
dc.b $93,$01,$00,_086E-Start,(_086E-Start)/$100 ; dc.b $6E,$08
dc.b $CF,$02,$00,_08C6-Start,(_08C6-Start)/$100 ; dc.b $C6,$08
dc.b $0C,$03,$60,_091E-Start,(_091E-Start)/$100 ; dc.b $1E,$09
dc.b $CA,$01,$00,_0972-Start,(_0972-Start)/$100 ; dc.b $72,$09
dc.b $EB,$01,$08,_0992-Start,(_0992-Start)/$100 ; dc.b $92,$09
dc.b $EA,$01,$08,_0999-Start,(_0999-Start)/$100 ; dc.b $99,$09
dc.b $81,$00,$00,_09A0-Start,(_09A0-Start)/$100 ; dc.b $A0,$09
dc.b $41,$00,$08,_0AA3-Start,(_0AA3-Start)/$100 ; dc.b $A3,$0A
dc.b $21,$00,$08,_0AAA-Start,(_0AAA-Start)/$100 ; dc.b $AA,$0A
END
</pre>

<pre>
Eye of the Beholder 2

The .inf file structure and data is somewhat different from its predecessor.

All offsets here are 16bit. All strings are null terminated c-strings. Filenames have usually 13 byte (8 letters + dot + 3 letters + null)

There are different data blocks:

Beginning of .inf file:
#x0000 offset to block_B
#x0002 block_A

block_A:
{
subblocks belong to different sublevels:
sub_block_A1:
{
#x0000 offset (relative to start of block_A) to sub_block_A2
#x0002 control byte, when = #xEC then this block follows:
#x0003:
{
#x0000: maze file name string usually "levelx.maz"; length: 13 byte
#x000D: file name string without extention: used to load .vmp .pal; length: 13 byte
#x001A: usually 0xFF, if not then the next 13 byte are again a string
without extention and used to load .pal
}
next: file name string without extention for sound file .adl or .snd
-> depends on game configuration;length: 13 byte
next: 2 bytes -> each my have the value #xEC or #xEA

more to follow here (monster and decoration data)
}
the following blocks are optional: [
sub_block_A2:
{
#x0000 offset to sub_block_A3
...
}

sub_block_A3
{
...
} ]
} end of block_A

block_B:
{
#x0000 offset to block_C after the scripting data
#x0002 control byte, if #xEC then this block follows:
{
(control byte | data byte) sequence;
first control byte = #xFF is already next data structure
}
here follows: 30*monster data structure, each with length 30 byte
after that: scripting data block:
{
#x0000 offset (relative to scripting data block) of the first string
next: events
next: strings
}
} end of block_B

block_C:
{
#x0000 number of special blocks wich follow; these link maze
fields to scripting data and contain flags; each 6 bytes long
#x0002 maze special 1
#x0008 maze special 2
#x000E maze special 3
...
} end of block_C

----

a maze special block has the following structure:
{
uint16: number of block in maze (0...1023)
uint16: flag
uint16: offset to scripting data (relative to scripting data block)
}

More Eye of the beholder 2 info, nothing new here. but nice to show the data storage.

struct sMonsterGFX
{
bool used;
int loadProg;
int unk0;
u8 unk1;
char* label;
};
struct sDice
{
u8 count;
u8 dice;
u8 plus;
};

struct sMonsterType
{
u8 idx; // 0
u8 unk0; //1
u8 THAC0; //2
u8 unk1; //3

sDice HPDice; //4
u8 numberOfAttacks; // 7
sDice attackDice[3]; // 16
unsigned short specialAttackFlag; //18
unsigned short AbilitiesFlag; // 20
unsigned short unk2; //22
unsigned short EXPGain; //24

u8 size;
u8 attackSound;
u8 moveSound;
u8 unk3;
// optional
bool isAttack2;
u8 distantAttack;
u8 MaxAttkCnt;
u8 attackList[4];

u8 turnUndead;
u8 unk4;
u8 unk5[3];

};

struct sMonster
{
u8 MoNo;
u8 MoTime;
short position;
u8 subpos;
u8 facing;
u8 type;
u8 pic;
u8 phase;
u8 pause;
short weapon; /* Item Number */
short pocket; /* Dropped on Monster killed */
};

struct sWallMapping
{
u8 idx;
u8 WallType;
u8 DecorationID;
u8 FileIndex; // index number in DecorationFNames
u8 unk0;
u8 unk1;
};

struct sDecorationFName
{
char GFXName[13];
char DECName[13];
};

struct sRectangle
{
short x;
short y;
short w;
short h;
};

struct sDoorInfo
{
u8 cmd;
u8 idx;
u8 typ;
u8 knob;
char GFXfile[13];

sRectangle doorRect[3];
sRectangle buttionRect[2];
u8 buttonPos[2][2];

};

.inf EOB2 dump with comments
EOB2 INF resourced fro assembler 68000 (To See here for all the INF files
EOB2-GB-FilesToTranslate.lha
EOB2-GB-FilesToTranslate.lha

Details
Download
170 KB

BOPT uo+
BOPT ue-
BOPT ua+
OUTPUT LEVEL10.INF.dec
;Source Created by "EOB2 Language File ReSourcerINF V2" Beta
;A Tool done by CFou! on Nov 2006
Start
Hunk0:
dc.b Hunk1-Start,(Hunk1-Start)/$100 ; dc.b $E9,$00
SubHunk0:
dc.b SubHunk1-Start-2,(SubHunk1-Start-2)/$100 ; dc.b $E7,$00
dc.b $EC
;Maze name
dc.b 'level10.maz',0,0
;VCN/VMP File name
dc.b 'mezz',0,'10.maz',0,0
;Palette File name
dc.b $01
dc.b 'azure',0,'0.maz',0,0
;Sound File name
dc.b 'azure',0,'0.maz',0,0
;Door name & Positions + offset
dc.b $EC
dc.b 'door2',0,'0.maz',0,0
dc.b $00,$00,$00,$14,$00,$47,$00,$09,$00,$46,$00,$09,$00,$8F,$00,$07
dc.b $00,$2F,$00,$10,$00,$58,$00,$04,$00,$1D,$00,$10,$00,$B3,$00,$01
dc.b $00,$0A,$00,$7E,$00,$28,$00,$11,$00,$B3,$00,$01,$00,$06,$00,$72
dc.b $00,$2A,$00
;Door name & Positions + offset
dc.b $FF

;Max nb Monster ????
dc.b $00,$00
;Monster file name
dc.b $FF
;Monster file name
dc.b $FF
;Monster Struct
dc.b $FF
;Decorate Structure
dc.b $EC
; Nb Decorate Block
dc.b $0C,$00
dc.b $EC
; Decorate file name
dc.b 'azure1',0,'.maz',0,0
; Decorate file name
dc.b 'azure.dec',0,'z',0,0
; Decorate Positions/offsets
dc.b $FB,$1B,$01,$11,$03,$04
dc.b $FB,$1C,$01,$12,$04,$04
dc.b $FB,$23,$00,$07,$00,$03
dc.b $FB,$24,$00,$09,$00,$03
dc.b $FB,$25,$00,$0D,$00,$03
dc.b $FB,$29,$01,$05,$00,$04
dc.b $FB,$28,$01,$03,$02,$04
dc.b $FB,$2C,$00,$FF,$00,$07
dc.b $FB,$2D,$01,$0B,$0A,$84
dc.b $FB,$2E,$01,$FF,$00,$07
dc.b $FB,$4A,$00,$FF,$00,$04
dc.b $01,$00
dc.b $03,$00
dc.b $FF,$FF,$FF,$FF
SubHunk1:
Hunk1:
dc.b Hunk3-Start,(Hunk3-Start)/$100 ; dc.b $F5,$03
dc.b $FF
Hunk2:
;TextBank Offset
dc.b TextBank-Hunk2,(TextBank-Hunk2)/$100 ; dc.b $89,$02
;Game script
_0002: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0007: dc.b $FF,$EE,_0077-Hunk2,(_0077-Hunk2)/$100 ; ->Condition branch/case
_000B: dc.b $EE,$ED,$D2,$02,$00 ; -> Condition Test
_0010: dc.b $FF,$EE,_0027-Hunk2,(_0027-Hunk2)/$100 ; ->Condition branch/case
_0014: dc.b $F8,$00,$00,$05,$00 ; FCT: Display Message
_0019: dc.b $F6,$4F,$00,$00 ; FCT: Sound
_001D: dc.b $EC,$E5,$06,$00,$16,$02,$02 ; FCT: Change Level
_0024: dc.b $F2,_0074-Hunk2,(_0074-Hunk2)/$100 ; FCT: Jump Code
_0027: dc.b $F8,$01,$00,$0F,$00 ; FCT: Display Message
_002C: dc.b $F6,$1D,$00,$00 ; FCT: Sound
_0030: dc.b $EE,$D2,$02,$00,$D2,$00,$00 ; -> Condition Test
_0037: dc.b $FF,$EE,_0041-Hunk2,(_0041-Hunk2)/$100 ; ->Condition branch/case
_003B: dc.b $FA,$E8,$00,$00,$16,$02 ; FCT: Teleport????
_0041: dc.b $EE,$D2,$02,$00,$D2,$01,$00 ; -> Condition Test
_0048: dc.b $FF,$EE,_0052-Hunk2,(_0052-Hunk2)/$100 ; ->Condition branch/case
_004C: dc.b $FA,$E8,$00,$00,$F5,$01 ; FCT: Teleport????
_0052: dc.b $EE,$D2,$02,$00,$D2,$02,$00 ; -> Condition Test
_0059: dc.b $FF,$EE,_0063-Hunk2,(_0063-Hunk2)/$100 ; ->Condition branch/case
_005D: dc.b $FA,$E8,$00,$00,$D6,$01 ; FCT: Teleport????
_0063: dc.b $EE,$D2,$02,$00,$D2,$03,$00 ; -> Condition Test
_006A: dc.b $FF,$EE,_0074-Hunk2,(_0074-Hunk2)/$100 ; ->Condition branch/case
_006E: dc.b $FA,$E8,$00,$00,$F7,$01 ; FCT: Teleport????
_0074: dc.b $F2,_0080-Hunk2,(_0080-Hunk2)/$100 ; FCT: Jump Code
_0077: dc.b $FA,$F5 ; FCT: Teleport????
_0079: dc.b $EB,$F6,$01 ; FCT: Give Experience
_007C: dc.b $E5,$06,$16,$02 ; FCT: Wait
_0080: dc.b $F1 ; FCT: End Code
_0081: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0086: dc.b $FF,$EE,_00F6-Hunk2,(_00F6-Hunk2)/$100 ; ->Condition branch/case
_008A: dc.b $EE,$ED,$D2,$03,$00 ; -> Condition Test
_008F: dc.b $FF,$EE,_00A6-Hunk2,(_00A6-Hunk2)/$100 ; ->Condition branch/case
_0093: dc.b $F8,$02,$00,$05,$00 ; FCT: Display Message
_0098: dc.b $F6,$4F,$00,$00 ; FCT: Sound
_009C: dc.b $EC,$E5,$0B,$00,$D1,$03,$03 ; FCT: Change Level
_00A3: dc.b $F2,_00F3-Hunk2,(_00F3-Hunk2)/$100 ; FCT: Jump Code
_00A6: dc.b $F8,$01,$00,$0F,$00 ; FCT: Display Message
_00AB: dc.b $F6,$1D,$00,$00 ; FCT: Sound
_00AF: dc.b $EE,$D2,$03,$00,$D2,$00,$00 ; -> Condition Test
_00B6: dc.b $FF,$EE,_00C0-Hunk2,(_00C0-Hunk2)/$100 ; ->Condition branch/case
_00BA: dc.b $FA,$E8,$00,$00,$F2,$03 ; FCT: Teleport????
_00C0: dc.b $EE,$D2,$03,$00,$D2,$01,$00 ; -> Condition Test
_00C7: dc.b $FF,$EE,_00D1-Hunk2,(_00D1-Hunk2)/$100 ; ->Condition branch/case
_00CB: dc.b $FA,$E8,$00,$00,$D1,$03 ; FCT: Teleport????
_00D1: dc.b $EE,$D2,$03,$00,$D2,$02,$00 ; -> Condition Test
_00D8: dc.b $FF,$EE,_00E2-Hunk2,(_00E2-Hunk2)/$100 ; ->Condition branch/case
_00DC: dc.b $FA,$E8,$00,$00,$B2,$03 ; FCT: Teleport????
_00E2: dc.b $EE,$D2,$03,$00,$D2,$03,$00 ; -> Condition Test
_00E9: dc.b $FF,$EE,_00F3-Hunk2,(_00F3-Hunk2)/$100 ; ->Condition branch/case
_00ED: dc.b $FA,$E8,$00,$00,$D3,$03 ; FCT: Teleport????
_00F3: dc.b $F2,_00FF-Hunk2,(_00FF-Hunk2)/$100 ; FCT: Jump Code
_00F6: dc.b $FA,$F5 ; FCT: Teleport????
_00F8: dc.b $EB,$D2,$03 ; FCT: Give Experience
_00FB: dc.b $E5,$0B,$D1,$03 ; FCT: Wait
_00FF: dc.b $F1 ; FCT: End Code
_0100: dc.b $EE,$E7,$F6,$D2,$FF,$FF ; -> Condition Test
_0106: dc.b $FF,$EE,_010D-Hunk2,(_010D-Hunk2)/$100 ; ->Condition branch/case
_010A: dc.b $FF,$ED,$03 ; ->Condition branch/case
_010D: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0112: dc.b $FF,$EE,_0126-Hunk2,(_0126-Hunk2)/$100 ; ->Condition branch/case
_0116: dc.b $F6,$0F,$11,$03 ; FCT: Sound
_011A: dc.b $FF,$ED,$01 ; ->Condition branch/case
_011D: dc.b $FA,$E8,$00,$00,$01,$03 ; FCT: Teleport????
_0123: dc.b $F2,_012E-Hunk2,(_012E-Hunk2)/$100 ; FCT: Jump Code
_0126: dc.b $FA,$F5 ; FCT: Teleport????
_0128: dc.b $EB,$11,$03 ; FCT: Give Experience
_012B: dc.b $EB,$01,$03 ; FCT: Give Experience
_012E: dc.b $F1 ; FCT: End Code
_012F: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0134: dc.b $FF,$EE,_0148-Hunk2,(_0148-Hunk2)/$100 ; ->Condition branch/case
_0138: dc.b $F6,$0F,$C5,$03 ; FCT: Sound
_013C: dc.b $FF,$ED,$01 ; ->Condition branch/case
_013F: dc.b $FA,$E8,$00,$00,$CC,$02 ; FCT: Teleport????
_0145: dc.b $F2,_0150-Hunk2,(_0150-Hunk2)/$100 ; FCT: Jump Code
_0148: dc.b $FA,$F5 ; FCT: Teleport????
_014A: dc.b $EB,$C5,$03 ; FCT: Give Experience
_014D: dc.b $EB,$CC,$02 ; FCT: Give Experience
_0150: dc.b $F1 ; FCT: End Code
_0151: dc.b $F8,$03,$00,$01,$00 ; FCT: Display Message
_0156: dc.b $F1 ; FCT: End Code
_0157: dc.b $F8,$04,$00,$01,$00 ; FCT: Display Message
_015C: dc.b $F1 ; FCT: End Code
_015D: dc.b $EE,$E9,$03,$43,$02,$D2,$08,$00 ; -> Condition Test
_0165: dc.b $FF,$F5,$01,$FF,$62,$02,$D2,$00,$00 ; ->Condition branch/case
_016E: dc.b $FB,$F9,$EE,$84,$01
_0173: dc.b $ED,$FE,$62,$02 ; FCT: Item Consume
_0177: dc.b $FD,$43,$02 ; FCT:Open Door
_017A: dc.b $E4 ; FCT: Update Screen
_017B: dc.b $E5,$01,$00 ; FCT: Wait
_017E: dc.b $FF,$E9,$41,$02,$01,$1B ; ->Condition branch/case
_0184: dc.b $F1 ; FCT: End Code
_0185: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_018A: dc.b $FF,$EE,_019F-Hunk2,(_019F-Hunk2)/$100 ; ->Condition branch/case
_018E: dc.b $F6,$0F,$65,$02 ; FCT: Sound
_0192: dc.b $FC,$43,$02 ; FCT: Close Door
_0195: dc.b $FF,$ED,$01 ; ->Condition branch/case
_0198: dc.b $FA,$E8,$00,$00,$2C,$03 ; FCT: Teleport????
_019E: dc.b $F0 ; FCT: Return
_019F: dc.b $FA,$F5 ; FCT: Teleport????
_01A1: dc.b $EB,$65,$02 ; FCT: Give Experience
_01A4: dc.b $EB,$2C,$03 ; FCT: Give Experience
_01A7: dc.b $F1 ; FCT: End Code
_01A8: dc.b $F6,$01,$0F,$01 ; FCT: Sound
_01AC: dc.b $E4 ; FCT: Update Screen
_01AD: dc.b $E5,$01,$00 ; FCT: Wait
_01B0: dc.b $FF,$E9,$0F,$01,$00,$1B ; ->Condition branch/case
_01B6: dc.b $FF,$F7,$4F,$00,$2C ; ->Condition branch/case
_01BB: dc.b $F7,$EF,$01 ; FCT: Set Flag
_01BE: dc.b $F1 ; FCT: End Code
_01BF: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_01C4: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_01CD: dc.b $FF,$F9,$E0,$D2,$04,$00 ; ->Condition branch/case
_01D3: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$01,$00 ; ->Condition branch/case
_01DC: dc.b $FF,$F9,$F1,$F1,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_01E5: dc.b $FF,$F9,$F8,$EE,_01FA-Hunk2,(_01FA-Hunk2)/$100 ; ->Condition branch/case
_01EB: dc.b $FF,$F7,$4D,$00,$24 ; ->Condition branch/case
_01F0: dc.b $F6,$0C,$4D,$00 ; FCT: Sound
_01F4: dc.b $FF,$E9,$0F,$01,$00,$1B ; ->Condition branch/case
_01FA: dc.b $EE,$E0,$D2,$02,$00 ; -> Condition Test
_01FF: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0208: dc.b $FF,$F9,$E0,$D2,$08,$00 ; ->Condition branch/case
_020E: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0217: dc.b $FF,$F9,$F1,$F1,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0220: dc.b $FF,$F9,$F8,$EE,_0235-Hunk2,(_0235-Hunk2)/$100 ; ->Condition branch/case
_0226: dc.b $FF,$F7,$4D,$00,$23 ; ->Condition branch/case
_022B: dc.b $F6,$0C,$4D,$00 ; FCT: Sound
_022F: dc.b $FF,$E9,$0F,$01,$00,$01 ; ->Condition branch/case
_0235: dc.b $F1 ; FCT: End Code
_0236: dc.b $EE,$EF,$01,$D2,$01,$00 ; -> Condition Test
_023C: dc.b $FF,$EE,_025B-Hunk2,(_025B-Hunk2)/$100 ; ->Condition branch/case
_0240: dc.b $EE,$EF,$02,$D2,$01,$00 ; -> Condition Test
_0246: dc.b $FF,$EE,_0258-Hunk2,(_0258-Hunk2)/$100 ; ->Condition branch/case
_024A: dc.b $FF,$F7,$4F,$00,$00 ; ->Condition branch/case
_024F: dc.b $F5,$EF,$01 ; FCT: Clear Flag
_0252: dc.b $F5,$EF,$02 ; FCT: Clear Flag
_0255: dc.b $F2,_025B-Hunk2,(_025B-Hunk2)/$100 ; FCT: Jump Code
_0258: dc.b $F7,$EF,$02 ; FCT: Set Flag
_025B: dc.b $F1 ; FCT: End Code
_025C: dc.b $EE,$F7,$4F,$00,$D2,$2C,$00 ; -> Condition Test
_0263: dc.b $FF,$EE,_0288-Hunk2,(_0288-Hunk2)/$100 ; ->Condition branch/case
_0267: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_026C: dc.b $FF,$EE,_0280-Hunk2,(_0280-Hunk2)/$100 ; ->Condition branch/case
_0270: dc.b $F6,$0F,$4F,$00 ; FCT: Sound
_0274: dc.b $FF,$ED,$01 ; ->Condition branch/case
_0277: dc.b $FA,$E8,$00,$00,$2C,$03 ; FCT: Teleport????
_027D: dc.b $F2,_0288-Hunk2,(_0288-Hunk2)/$100 ; FCT: Jump Code
_0280: dc.b $FA,$F5 ; FCT: Teleport????
_0282: dc.b $EB,$6F,$02 ; FCT: Give Experience
_0285: dc.b $EB,$2C,$03 ; FCT: Give Experience
_0288: dc.b $F1 ; FCT: End Code

;TextBank
TextBank:
dc.b 'going down...',0
dc.b 'you can',"'",'t go that way.',0
dc.b 'going up...',0
dc.b 'the plaque reads: you will pay for your freedom...',0
dc.b 'the plaque reads: one item.',0
Hunk3:
;Special Maze Blocks Bank (offset)
; Nb Special Maze Blocks
dc.b $0C,$00
; Special Maze Blocks List:
dc.b $F6,$01,$A8,$00,_0002-Hunk2,(_0002-Hunk2)/$100 ; dc.b $02,$00
dc.b $D2,$03,$A8,$00,_0081-Hunk2,(_0081-Hunk2)/$100 ; dc.b $81,$00
dc.b $11,$03,$A8,$00,_0100-Hunk2,(_0100-Hunk2)/$100 ; dc.b $00,$01
dc.b $C5,$03,$A8,$00,_012F-Hunk2,(_012F-Hunk2)/$100 ; dc.b $2F,$01
dc.b $A4,$01,$00,$00,_0151-Hunk2,(_0151-Hunk2)/$100 ; dc.b $51,$01
dc.b $21,$02,$00,$00,_0157-Hunk2,(_0157-Hunk2)/$100 ; dc.b $57,$01
dc.b $41,$02,$00,$00,_015D-Hunk2,(_015D-Hunk2)/$100 ; dc.b $5D,$01
dc.b $65,$02,$A8,$00,_0185-Hunk2,(_0185-Hunk2)/$100 ; dc.b $85,$01
dc.b $0F,$01,$00,$00,_01A8-Hunk2,(_01A8-Hunk2)/$100 ; dc.b $A8,$01
dc.b $4D,$00,$78,$00,_01BF-Hunk2,(_01BF-Hunk2)/$100 ; dc.b $BF,$01
dc.b $01,$00,$00,$00,_0236-Hunk2,(_0236-Hunk2)/$100 ; dc.b $36,$02
dc.b $4F,$00,$A8,$00,_025C-Hunk2,(_025C-Hunk2)/$100 ; dc.b $5C,$02
END
</pre>

Eye of the Beholder Maze Information Format

2014-12-12T20:23:53Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

'''General'''
Each maze consist of a .maz file and an accompaning .inf file. This document describes the .inf file and how it relates to the .maz files.
The .inf files are standard CPS files. However the german and spanish versions are uncompressed. This document assumes that you've depacked the .inf files using for instance uncps.exe.

'''Header'''
<pre>
struct Monster
{
unsigned char index;
unsigned char levelType;
unsigned short pos;
unsigned char subpos;
unsigned char direction;
unsigned char type;
unsigned char picture;
unsigned char phase;
unsigned char pause;
unsigned short weapon;
unsigned short pocket_item;
}
</pre>

Position gives the x and y values. It's lower 5 bits are the y coordinate value and the next 5 bits are the x coordinate value.
<pre>
x_pos = (pos >> 5) & 0x1F;
y_pos = pos & 0x1F;
</pre>

Values sign must be confirmed.
<pre>
struct Inf
{
unsigned short triggersOffset;
char mazeName[12];
char vmpVcnName[12];
char paletteName[12];
unsigned char unknown[9];
unsigned char monster1CompressionMethod;
unsigned char monster1Name[12];
unsigned char monster2CompressionMethod;
unsigned char monster2Name[12];
unsigned char unknown[5];
Monster monsters[30];
unsigned short nbrDecCommands;
DecCommand commands[nbrDecCommands];
}
</pre>

'''Decoration data'''
After the header comes the decoration data. It's loaded as a command sequence. The first unsigned short determines number of commands to execute. After that follows the first command code. Each command code is one byte.

Command codes
<pre>
0xec (Load overlay image picture + overlay image rectangle data)

graphics data name, 12 bytes containing a null terminated string. Points to a .cps file containg wall graphics data.
rectangles data name, 12 bytes containing a null terminated string. Points to a .dat file containing rectangular data that point into the graphics data.

0xfb (Define wall mapping)

struct WallMapping
{
unsigned char wallMappingIndex; /* This is the index used by the .maz file. */
unsigned char wallType; /* Index to what backdrop wall type that is being used. */
unsigned char decorationID; /* Index to and optional overlay decoration image in
the DecorationData.decorations array in the
[[eob.dat|.dat]] files. */
unsigned char unknownFlags1;
unsigned char unknownFlags2;
};
</pre>

'''Event data'''
After the decoration data comes a sequence of event data. It's also loaded as a command sequence. Each command code is one byte.
<pre>
Command codes

0xff (Set wall)
0xfe (Change wall)
0xfd (Open door)
0xfc (Close coor)
0xfb (Create monster)
0xfa (Teleport)
0xf9 (Steal small item)
0xf8 (Message)
0xf7 (Set flag)
0xf6 (Sound)
0xf5 (Clear flag)
0xf4 (Heal)
0xf3 (Damage)
0xf2 (Jump)
0xf1 (End code)
0xf0 (Return)
0xef (Call)
0xee (Conditions)
0xed (Item consume)
0xec (Change level)
0xeb (Give experience)
0xea (New item)
0xe9 (Launcher)
0xe8 (Turn)
0xe7 (Identify all items)
0xe6 (Encounters)
0xe5 (Wait)
0xe4 (Update screen)
0xe3 (Text menu)
0xe2 (Special window pictures)
</pre>

Each command code is executed using a parsing function for that specific code. Number of bytes following each code is very specific to what command it is.
<pre>
0xff (Set wall)

unsigned char subcode=nextUnsignedChar();

switch (subcode)
{
case 0xf7: // Set complete maze block (all four walls)
unsigned short position=nextUnsignedShort();
unsigned char wallMappingIndex=nextUnsignedChar();
for (int i=0; i<4; i++)
maze[position][i]=wallMappingIndex;
break;

case 0xe9; // Change one wall
unsigned short position=nextUnsignedShort();
unsigned char wallMappingIndex=nextUnsignedChar();
unsigned char direction=nextUnsignedChar();
maze[position][direction]=wallMappingIndex;
break;

case 0xed; // Turn party
Party.facing = nextUnsignedChar();
};

0xfe (Change wall)

unsigned char subcode=nextUnsignedChar();

switch (subcode)
{
case 0xf7: //Flip four sides
unsigned short position=nextUnsignedShort();
unsigned char sourceWallMappingIndex=nextUnsignedChar();
unsigned char destinationWallMappingIndex=nextUnsignedChar();
for (int i=0; i<4; i++)
{
if (maze[position][i] == sourceWallMappingIndex)
maze[position][i] = destinationWallMappingIndex;
}
break;

case 0xe9;// Change one wall
unsigned short position=nextUnsignedShort();
unsigned char direction=nextUnsignedChar();
unsigned char sourceWallMappingIndex=nextUnsignedChar();
unsigned char destinationWallMappingIndex=nextUnsignedChar();
if (maze[position][direction] == sourceWallMappingIndex)
maze[position][direction] = destinationWallMappingIndex;
break;

case 0xea; // Unknown
unsigned short unknown=nextUnsigndShort();
break;
};

0xfb (Monster Creation)

char MoNo;
char MoTime;
short int position;
char subpos;
char facing;
char type;
char pic;
char phase;
char pause;
short int weapon; /* Item Number */
short int pocket; /* Dropped on Monster killed */

0xf6 (Sound)

char SoundId;
short int position;

0xf6 (Sound) in the demo version of the EOB1

char SoundId;
</pre>

All other commands, except 0xf6, are identical in all EOB1 versions.

Far from all command codes have been documented here, however most of it have already been reverse engineered. Feel free to check the source code for the script decompiler: Script Decompiler 2 at the tools section.

<pre>
.inf dump with comments
EOB1 INF file resourced for assembler 68000 (To See here for all the INF files
EOB-InfFile-Asm.lha
EOB-InfFile-Asm.lha

Details
Download
91 KB

BOPT uo+
BOPT ue-
BOPT ua+
OUTPUT LEVEL1.INF.dec
;Source Created by "EOB Langage File ReSourcerINF" Beta
;A Tool done by CFou! on June 2006
Start
Hunk0:
dc.b Hunk3-Start,(Hunk3-Start)/$100 ; dc.w $B10A
; Maze name
dc.b 'level1.maz',0,0
; VCN/VMP name
dc.b 'brick',0,'.maz',0,0
; Palette name
dc.b 'brick',0,'.maz',0,0
_0026:
; Nb of doors and doorknobs
dc.w $0000,$FF03
_002A:
; Max monster / tdiff etc
dc.b $00,$00,$00,$00,$00
_002F:
; Number of procedure for extraction of monster picture
dc.b $01
; Name Of Monster pic CPS file
dc.b 'kobold',0,'maz',0,0
_003C:
; Number of procedure for extraction of monster picture
dc.b $00
; Name Of Monster pic CPS file
dc.b 'leech',0,0,'maz',0,0
_0049:
; Timer0 | Timer 1| Timerdiff (in Ticks)
dc.b $00,$19
; Timer0 | Timer 1| Timerdiff
dc.b $01,$23
; End of Timer
dc.b $FF
_004E:
; Monster Description X 30: Start point and so on
dc.b $01,$00,$14,$01,$04,$02,$00,$00,$06,$00,$04,$00,$00,$00
dc.b $02,$00,$F4,$00,$04,$02,$00,$00,$06,$00,$00,$00,$04,$00
dc.b $03,$00,$15,$01,$04,$02,$00,$00,$06,$00,$04,$00,$00,$00
dc.b $04,$00,$F5,$00,$04,$02,$00,$00,$06,$00,$04,$00,$37,$00
dc.b $05,$00,$B4,$01,$00,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $06,$00,$B4,$01,$01,$00,$00,$00,$04,$00,$00,$00,$04,$00
dc.b $07,$00,$B4,$01,$02,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $08,$00,$B4,$01,$03,$00,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $09,$00,$4A,$02,$04,$01,$00,$00,$05,$00,$00,$00,$04,$00
dc.b $0A,$00,$4B,$02,$04,$03,$00,$00,$05,$00,$04,$00,$00,$00
dc.b $0B,$00,$4C,$02,$04,$01,$00,$00,$05,$00,$04,$00,$00,$00
dc.b $0C,$00,$2C,$03,$02,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $0D,$00,$2C,$03,$03,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $0E,$00,$59,$02,$02,$02,$00,$00,$04,$00,$00,$00,$04,$00
dc.b $0F,$00,$59,$02,$03,$02,$00,$00,$04,$00,$04,$00,$00,$00
dc.b $10,$00,$6B,$02,$04,$01,$00,$00,$06,$00,$04,$00,$3B,$00
dc.b $11,$00,$2C,$02,$04,$02,$00,$00,$06,$00,$00,$00,$00,$00
dc.b $12,$00,$8F,$01,$04,$02,$00,$00,$01,$00,$00,$00,$00,$00
dc.b $13,$01,$86,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $14,$01,$66,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $15,$01,$45,$03,$04,$01,$01,$01,$05,$00,$00,$00,$00,$00
dc.b $16,$01,$2A,$03,$04,$00,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $17,$01,$E8,$02,$04,$01,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $18,$01,$EF,$02,$04,$03,$01,$01,$01,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
dc.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
_01F2:
Hunk1:
; Nb of $EC & $FB command Hunk 1
dc.w $1B00
; Command $EC & $FB
dc.b $EC
dc.b 'brick1',0,'maz',0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$27,$01,$00,$03,$04
dc.b $FB,$28,$01,$01,$04,$04
dc.b $FB,$3E,$01,$17,$02,$04
dc.b $FB,$2B,$01,$28,$02,$04
dc.b $FB,$3F,$01,$16,$02,$04
dc.b $FB,$32,$01,$04,$02,$04
dc.b $FB,$41,$01,$1A,$02,$04
dc.b $FB,$2F,$01,$30,$02,$04
dc.b $FB,$2C,$01,$2F,$02,$04
dc.b $FB,$2A,$01,$31,$02,$04
dc.b $EC
dc.b 'brick2',0,'at',0,0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$1A,$00,$1C,$00,$03
dc.b $FB,$17,$04,$21,$00,$05
dc.b $FB,$18,$05,$22,$00,$05
dc.b $FB,$1C,$00,$1D,$00,$03
dc.b $FB,$19,$00,$FF,$00,$07
dc.b $FB,$3C,$01,$24,$03,$04
dc.b $FB,$3D,$01,$25,$04,$04
dc.b $FB,$37,$01,$1E,$03,$04
dc.b $FB,$38,$01,$1F,$04,$04
dc.b $FB,$1D,$01,$20,$0A,$84
dc.b $FB,$33,$01,$26,$02,$04
dc.b $FB,$3A,$01,$23,$00,$04
dc.b $EC
dc.b 'brick3',0,'at',0,0,0
dc.b 'brick.dat',0,0,0
dc.b $FB,$45,$00,$27,$02,$04
dc.b $FB,$31,$00,$2D,$02,$04
;$1B Command Resourced
Hunk2:
; New Section
_02CF: dc.b $EE,$E0,$01
_02D2: dc.b $FF,$EE,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_02D6: dc.b $EE,$ED,$01
_02D9: dc.b $FF,$EE,_0308-Start,(_0308-Start)/$100 ; dc.b $08,$03
_02DD: dc.b $EE,$EF,$1F,$00
_02E1: dc.b $FF,$EE,_02EA-Start,(_02EA-Start)/$100 ; dc.b $EA,$02
_02E5: dc.b $E6,$0A
_02E7: dc.b $F7,$EF,$1F
_02EA: dc.b $F8,"going down...",0,$05,$00
_02FB: dc.b $F6,$4F,$00,$00
_02FF: dc.b $EC,$E5,$02,$F3,$02,$01
_0305: dc.b $F2,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_0308: dc.b $F8,"you can't go that way.",0,$0F,$00
_0322: dc.b $F6,$1D,$00,$00
_0326: dc.b $EE,$01,$00
_0329: dc.b $FF,$EE,_0333-Start,(_0333-Start)/$100 ; dc.b $33,$03
_032D: dc.b $FA,$E8,$00,$00,$12,$03
_0333: dc.b $EE,$01,$01
_0336: dc.b $FF,$EE,_0340-Start,(_0340-Start)/$100 ; dc.b $40,$03
_033A: dc.b $FA,$E8,$00,$00,$F1,$02
_0340: dc.b $EE,$01,$02
_0343: dc.b $FF,$EE,_034D-Start,(_034D-Start)/$100 ; dc.b $4D,$03
_0347: dc.b $FA,$E8,$00,$00,$D2,$02
_034D: dc.b $EE,$01,$03
_0350: dc.b $FF,$EE,_035A-Start,(_035A-Start)/$100 ; dc.b $5A,$03
_0354: dc.b $FA,$E8,$00,$00,$F3,$02
_035A: dc.b $EE,$E0,$04
_035D: dc.b $FF,$EE,_0395-Start,(_0395-Start)/$100 ; dc.b $95,$03
_0361: dc.b $EE,$01,$00
_0364: dc.b $FF,$EE,_036E-Start,(_036E-Start)/$100 ; dc.b $6E,$03
_0368: dc.b $FA,$F5,$F2,$02,$12,$03
_036E: dc.b $EE,$01,$01
_0371: dc.b $FF,$EE,_037B-Start,(_037B-Start)/$100 ; dc.b $7B,$03
_0375: dc.b $FA,$F5,$F2,$02,$F1,$02
_037B: dc.b $EE,$01,$02
_037E: dc.b $FF,$EE,_0388-Start,(_0388-Start)/$100 ; dc.b $88,$03
_0382: dc.b $FA,$F5,$F2,$02,$D2,$02
_0388: dc.b $EE,$01,$03
_038B: dc.b $FF,$EE,_0395-Start,(_0395-Start)/$100 ; dc.b $95,$03
_038F: dc.b $FA,$F5,$F2,$02,$F3,$02
_0395:
dc.b $F1
_0396: dc.b $EE,$EF,$0A,$00
_039A: dc.b $FF,$EE,_03A5-Start,(_03A5-Start)/$100 ; dc.b $A5,$03
_039E: dc.b $EB,$E2,$40,$06
_03A2: dc.b $F7,$EF,$0A
_03A5:
dc.b $F1
_03A6: dc.b $EB,$E2,$10,$27
_03AA:
dc.b $F1
_03AB: dc.b $EE,$EF,$08,$00
_03AF: dc.b $FF,$EE,_03BA-Start,(_03BA-Start)/$100 ; dc.b $BA,$03
_03B3: dc.b $EB,$E2,$40,$06
_03B7: dc.b $F7,$EF,$08
_03BA:
dc.b $F1
_03BB: dc.b $EE,$EF,$04,$00
_03BF: dc.b $FF,$EE,_03CA-Start,(_03CA-Start)/$100 ; dc.b $CA,$03
_03C3: dc.b $EB,$E2,$90,$01
_03C7: dc.b $F7,$EF,$04
_03CA:
dc.b $F1
_03CB: dc.b $F6,$01,$AD,$01
_03CF: dc.b $FE,$EA,$AE,$01
_03D3: dc.b $EE,$EF,$01,$00
_03D7: dc.b $FF,$EE,_03E2-Start,(_03E2-Start)/$100 ; dc.b $E2,$03
_03DB: dc.b $EB,$E2,$20,$03
_03DF: dc.b $F7,$EF,$01
_03E2:
dc.b $F1
_03E3: dc.b $EE,$F7,$75,$01,$01
_03E8: dc.b $FE,$EE,_03F6-Start,(_03F6-Start)/$100 ; dc.b $F6,$03
_03EC: dc.b $FF,$F7,$11,$02,$01
_03F1: dc.b $FF,$F7,$2E,$03,$01
_03F6: dc.b $EE,$EF,$02,$00
_03FA: dc.b $FF,$EE,_0405-Start,(_0405-Start)/$100 ; dc.b $05,$04
_03FE: dc.b $EB,$E2,$90,$01
_0402: dc.b $F7,$EF,$02
_0405:
dc.b $F1
_0406: dc.b $EE,$F7,$11,$02,$01
_040B: dc.b $FE,$EE,_041F-Start,(_041F-Start)/$100 ; dc.b $1F,$04
_040F: dc.b $FF,$E9,$C9,$02,$00,$01
_0415: dc.b $FF,$F7,$75,$01,$01
_041A: dc.b $FF,$F7,$4D,$03,$01
_041F: dc.b $F7,$EF,$02
_0422:
dc.b $F1
_0423: dc.b $EE,$E9,$00,$B7,$01,$01
_0429: dc.b $FE,$EE,_0444-Start,(_0444-Start)/$100 ; dc.b $44,$04
_042D: dc.b $F6,$07,$B7,$01
_0431: dc.b $FE,$EA,$B6,$01
_0435: dc.b $EE,$EF,$05,$00
_0439: dc.b $FF,$EE,_0444-Start,(_0444-Start)/$100 ; dc.b $44,$04
_043D: dc.b $EB,$E2,$20,$03
_0441: dc.b $F7,$EF,$05
_0444:
dc.b $F1
_0445: dc.b $EE,$F7,$D6,$01,$1C
_044A: dc.b $FF,$EE,_0465-Start,(_0465-Start)/$100 ; dc.b $65,$04
_044E: dc.b $F6,$0C,$D6,$01
_0452: dc.b $FE,$EA,$B6,$01
_0456: dc.b $EE,$EF,$07,$00
_045A: dc.b $FF,$EE,_0465-Start,(_0465-Start)/$100 ; dc.b $65,$04
_045E: dc.b $EB,$E2,$20,$03
_0462: dc.b $F7,$EF,$07
_0465:
dc.b $F1
_0466: dc.b $EE,$E0,$01
_0469: dc.b $FF,$F5,$FF,$36,$02,$00
_046F: dc.b $FF,$F9,$E0,$04,$FF
_0474: dc.b $F5,$FF,$36,$02,$01
_0479: dc.b $FF,$F9,$F1,$36,$02,$00
_047F: dc.b $FF,$F9,$F8,$EE,_048C-Start,(_048C-Start)/$100 ; dc.b $8C,$04
_0485: dc.b $F6,$0C,$36,$02
_0489: dc.b $FD,$76,$02
_048C: dc.b $EE,$E0,$02
_048F: dc.b $FF,$F5,$FF,$36,$02,$00
_0495: dc.b $FF,$F9,$E0,$08,$FF
_049A: dc.b $F5,$FF,$36,$02,$00
_049F: dc.b $FF,$F9,$F1,$36,$02,$00
_04A5: dc.b $FF,$F9,$F8,$EE,_04B2-Start,(_04B2-Start)/$100 ; dc.b $B2,$04
_04AB: dc.b $F6,$0C,$36,$02
_04AF: dc.b $FC,$76,$02
_04B2:
dc.b $F1
_04B3: dc.b $F6,$01,$52,$02
_04B7: dc.b $FE,$EA,$53,$02
_04BB:
dc.b $F1
_04BC: dc.b $EE,$E9,$01,$6E,$02,$01
_04C2: dc.b $FE,$EE,_04DD-Start,(_04DD-Start)/$100 ; dc.b $DD,$04
_04C6: dc.b $F6,$07,$6E,$02
_04CA: dc.b $FE,$EA,$4E,$02
_04CE: dc.b $EE,$EF,$05,$00
_04D2: dc.b $FF,$EE,_04DD-Start,(_04DD-Start)/$100 ; dc.b $DD,$04
_04D6: dc.b $EB,$E2,$20,$03
_04DA: dc.b $F7,$EF,$05
_04DD:
dc.b $F1
_04DE: dc.b $EE,$F7,$4D,$02,$1C
_04E3: dc.b $FF,$EE,_04FE-Start,(_04FE-Start)/$100 ; dc.b $FE,$04
_04E7: dc.b $F6,$0C,$4D,$02
_04EB: dc.b $FE,$EA,$4E,$02
_04EF: dc.b $EE,$EF,$07,$00
_04F3: dc.b $FF,$EE,_04FE-Start,(_04FE-Start)/$100 ; dc.b $FE,$04
_04F7: dc.b $EB,$E2,$20,$03
_04FB: dc.b $F7,$EF,$07
_04FE:
dc.b $F1
_04FF: dc.b $F6,$07,$B2,$02
_0503: dc.b $F6,$0D,$93,$02
_0507: dc.b $FE,$F7,$93,$02,$00,$01
_050D: dc.b $FA,$F3,$93,$02,$73,$02
_0513: dc.b $EE,$EF,$06,$00
_0517: dc.b $FF,$EE,_0522-Start,(_0522-Start)/$100 ; dc.b $22,$05
_051B: dc.b $EB,$E2,$40,$06
_051F: dc.b $F7,$EF,$06
_0522:
dc.b $F1
_0523: dc.b $F6,$07,$BA,$02
_0527: dc.b $FA,$F3,$99,$02,$79,$02
_052D: dc.b $F6,$0D,$99,$02
_0531: dc.b $FE,$F7,$99,$02,$00,$01
_0537: dc.b $EE,$EF,$06,$00
_053B: dc.b $FF,$EE,_0546-Start,(_0546-Start)/$100 ; dc.b $46,$05
_053F: dc.b $EB,$E2,$40,$06
_0543: dc.b $F7,$EF,$06
_0546:
dc.b $F1
_0547: dc.b $EE,$E9,$01,$E7,$02,$01
_054D: dc.b $FE,$EE,_0568-Start,(_0568-Start)/$100 ; dc.b $68,$05
_0551: dc.b $F6,$07,$E7,$02
_0555: dc.b $FE,$EA,$C8,$02
_0559: dc.b $EE,$EF,$05,$00
_055D: dc.b $FF,$EE,_0568-Start,(_0568-Start)/$100 ; dc.b $68,$05
_0561: dc.b $EB,$E2,$20,$03
_0565: dc.b $F7,$EF,$05
_0568:
dc.b $F1
_0569: dc.b $F6,$07,$C9,$02
_056D: dc.b $EE,$E9,$00,$C9,$02,$01
_0573: dc.b $FE,$EE,_0590-Start,(_0590-Start)/$100 ; dc.b $90,$05
_0577: dc.b $FE,$EA,$C8,$02
_057B: dc.b $FF,$E9,$E7,$02,$01,$01
_0581: dc.b $EE,$EF,$05,$00
_0585: dc.b $FF,$EE,_0590-Start,(_0590-Start)/$100 ; dc.b $90,$05
_0589: dc.b $EB,$E2,$20,$03
_058D: dc.b $F7,$EF,$05
_0590:
dc.b $F1
_0591: dc.b $F6,$0C,$11,$03
_0595: dc.b $FD,$F1,$02
_0598:
dc.b $F1
_0599: dc.b $EE,$E0,$01
_059C: dc.b $FF,$F5,$FF,$F0,$02,$00
_05A2: dc.b $FF,$F9,$EE,_05AE-Start,(_05AE-Start)/$100 ; dc.b $AE,$05
_05A7: dc.b $F6,$0C,$F0,$02
_05AB: dc.b $FC,$F1,$02
_05AE: dc.b $EE,$E0,$04
_05B1: dc.b $FF,$F1,$F0,$02,$00
_05B6: dc.b $FF,$F5,$FF,$F0,$02,$02
_05BC: dc.b $FD,$F9,$F9,$EE,_05C9-Start,(_05C9-Start)/$100 ; dc.b $C9,$05
_05C2: dc.b $F6,$0C,$F0,$02
_05C6: dc.b $FC,$F1,$02
_05C9:
dc.b $F1
_05CA: dc.b $EE,$EF,$00,$00
_05CE: dc.b $FF,$EE,_05F1-Start,(_05F1-Start)/$100 ; dc.b $F1,$05
_05D2: dc.b $F8,"it smells terrible here.",0,$02,$00
_05EE: dc.b $F7,$EF,$00
_05F1:
dc.b $F1
_05F2: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_0624: dc.b $EE,$EF,$03,$00
_0628: dc.b $FF,$EE,_0633-Start,(_0633-Start)/$100 ; dc.b $33,$06
_062C: dc.b $EB,$E2,$20,$03
_0630: dc.b $F7,$EF,$03
_0633:
dc.b $F1
_0634: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_0657: dc.b $EE,$EF,$03,$00
_065B: dc.b $FF,$EE,_0666-Start,(_0666-Start)/$100 ; dc.b $66,$06
_065F: dc.b $EB,$E2,$20,$03
_0663: dc.b $F7,$EF,$03
_0666: dc.b $EE,$E7,$F5,$00
_066A: dc.b $FF,$EF,$01,$00
_066E: dc.b $FF,$F9,$EE,_067C-Start,(_067C-Start)/$100 ; dc.b $7C,$06
_0673: dc.b $EA,$3A,$00,$FF,$FF,$00
_0679: dc.b $F7,$EF,$01
_067C:
dc.b $F1
_067D: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_06AF: dc.b $EE,$EF,$03,$00
_06B3: dc.b $FF,$EE,_06BE-Start,(_06BE-Start)/$100 ; dc.b $BE,$06
_06B7: dc.b $EB,$E2,$20,$03
_06BB: dc.b $F7,$EF,$03
_06BE:
dc.b $F1
_06BF: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_06E2: dc.b $EE,$EF,$03,$00
_06E6: dc.b $FF,$EE,_06F1-Start,(_06F1-Start)/$100 ; dc.b $F1,$06
_06EA: dc.b $EB,$E2,$20,$03
_06EE: dc.b $F7,$EF,$03
_06F1:
dc.b $F1
_06F2: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_0715: dc.b $EE,$EF,$03,$00
_0719: dc.b $FF,$EE,_0724-Start,(_0724-Start)/$100 ; dc.b $24,$07
_071D: dc.b $EB,$E2,$20,$03
_0721: dc.b $F7,$EF,$03
_0724:
dc.b $F1
_0725: dc.b $EE,$EF,$03,$00
_0729: dc.b $FF,$EE,_0734-Start,(_0734-Start)/$100 ; dc.b $34,$07
_072D: dc.b $EB,$E2,$20,$03
_0731: dc.b $F7,$EF,$03
_0734: dc.b $EE,$F1,$CE,$01,$01
_0739: dc.b $FF,$EE,_07AF-Start,(_07AF-Start)/$100 ; dc.b $AF,$07
_073D: dc.b $EE,$E9,$03,$CF,$01,$2C
_0743: dc.b $FF,$EE,_0789-Start,(_0789-Start)/$100 ; dc.b $89,$07
_0747: dc.b $F8,"something scurries deeper into the floor drain.",0,$02,$00
_077A: dc.b $FF,$E9,$CF,$01,$03,$3E
_0780: dc.b $FF,$E9,$CF,$01,$01,$2C
_0786: dc.b $F2,_07AC-Start,(_07AC-Start)/$100 ; dc.b $AC,$07
_0789: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_07AC: dc.b $F2,_081E-Start,(_081E-Start)/$100 ; dc.b $1E,$08
_07AF: dc.b $EE,$E9,$01,$CF,$01,$2C
_07B5: dc.b $FF,$EE,_07FB-Start,(_07FB-Start)/$100 ; dc.b $FB,$07
_07B9: dc.b $F8,"something scurries deeper into the floor drain.",0,$02,$00
_07EC: dc.b $FF,$E9,$CF,$01,$01,$3E
_07F2: dc.b $FF,$E9,$CF,$01,$03,$2C
_07F8: dc.b $F2,_081E-Start,(_081E-Start)/$100 ; dc.b $1E,$08
_07FB: dc.b $F8,"there is a drainage grate here.",0,$02,$00
_081E:
dc.b $F1
_081F: dc.b $FF,$E9,$CF,$01,$03,$2C
_0825: dc.b $FF,$E9,$CF,$01,$01,$2C
_082B:
dc.b $F1
_082C: dc.b $F8,"this slimy, smelly drain pipe reveals nothing.",0,$02,$00
_085E: dc.b $EE,$EF,$03,$00
_0862: dc.b $FF,$EE,_086D-Start,(_086D-Start)/$100 ; dc.b $6D,$08
_0866: dc.b $EB,$E2,$20,$03
_086A: dc.b $F7,$EF,$03
_086D:
dc.b $F1
_086E: dc.b $EE,$EF,$03,$00
_0872: dc.b $FF,$EE,_087D-Start,(_087D-Start)/$100 ; dc.b $7D,$08
_0876: dc.b $EB,$E2,$20,$03
_087A: dc.b $F7,$EF,$03
_087D: dc.b $EE,$DD,$04,$01
_0881: dc.b $FF,$EE,_08A7-Start,(_08A7-Start)/$100 ; dc.b $A7,$08
_0885: dc.b $F8,"kobold rune for 'entrance'.",0,$02,$00
_08A4: dc.b $F2,_08C5-Start,(_08C5-Start)/$100 ; dc.b $C5,$08
_08A7: dc.b $F8,"this rune is unrecognized.",0,$02,$00
_08C5:
dc.b $F1
_08C6: dc.b $EE,$EF,$03,$00
_08CA: dc.b $FF,$EE,_08D5-Start,(_08D5-Start)/$100 ; dc.b $D5,$08
_08CE: dc.b $EB,$E2,$20,$03
_08D2: dc.b $F7,$EF,$03
_08D5: dc.b $EE,$DD,$04,$01
_08D9: dc.b $FF,$EE,_08FF-Start,(_08FF-Start)/$100 ; dc.b $FF,$08
_08DD: dc.b $F8,"kobold rune for 'entrance'.",0,$02,$00
_08FC: dc.b $F2,_091D-Start,(_091D-Start)/$100 ; dc.b $1D,$09
_08FF: dc.b $F8,"this rune is unrecognized.",0,$02,$00
_091D:
dc.b $F1
_091E: dc.b $EE,$F5,$05,$0C,$03,$00
_0924: dc.b $FB,$F0,$01,$00
_0928: dc.b $FF,$F9,$EE,_0962-Start,(_0962-Start)/$100 ; dc.b $62,$09
_092D: dc.b $F8,"special quest for this level!",0,$03,$00
_094E: dc.b $F6,$1C,$00,$00
_0952: dc.b $F7,$F0,$01
_0955: dc.b $ED,$05,$0C,$03
_0959: dc.b $EA,$31,$00,$0C,$03,$08
_095F: dc.b $F7,$F0,$01
_0962: dc.b $EE,$EF,$09,$00
_0966: dc.b $FF,$EE,_0971-Start,(_0971-Start)/$100 ; dc.b $71,$09
_096A: dc.b $EB,$E2,$90,$01
_096E: dc.b $F7,$EF,$09
_0971:
dc.b $F1
_0972: dc.b $F8,"fallen rocks block the way.",0,$02,$00
_0991:
dc.b $F1
_0992: dc.b $FF,$E9,$CA,$01,$02,$31
_0998:
dc.b $F1
_0999: dc.b $FF,$E9,$CA,$01,$02,$45
_099F:
dc.b $F1
_09A0: dc.b $EE,$E9,$03,$62,$00,$08
_09A6: dc.b $FF,$EE,_0A86-Start,(_0A86-Start)/$100 ; dc.b $86,$0A
_09AA: dc.b $EE,$E7,$E1,$26
_09AE: dc.b $FF,$E7,$F6,$01
_09B2: dc.b $FF,$F9,$EE,_09C3-Start,(_09C3-Start)/$100 ; dc.b $C3,$09
_09B7: dc.b $F6,$0E,$81,$00
_09BB: dc.b $FD,$62,$00
_09BE: dc.b $ED,$FF
_09C0: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_09C3: dc.b $EE,$E7,$E1,$26
_09C7: dc.b $FF,$EE,_09E5-Start,(_09E5-Start)/$100 ; dc.b $E5,$09
_09CB: dc.b $F8,"it doesn't fit.",0,$06,$00
_09DE: dc.b $F6,$51,$81,$00
_09E2: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_09E5: dc.b $EE,$E7,$E1,$1C
_09E9: dc.b $FF,$EE,_0A66-Start,(_0A66-Start)/$100 ; dc.b $66,$0A
_09ED: dc.b $EE,$DC,$08,$01
_09F1: dc.b $FF,$EE,_0A43-Start,(_0A43-Start)/$100 ; dc.b $43,$0A
_09F5: dc.b $F6,$51,$81,$00
_09F9: dc.b $F8,"failed lock pick attempt.",0,$05,$00
_0A16: dc.b $EE,$DB,$01,$64,$00,$01
_0A1C: dc.b $FF,$EE,_0A40-Start,(_0A40-Start)/$100 ; dc.b $40,$0A
_0A20: dc.b $F6,$52,$00,$00
_0A24: dc.b $F8,"the lock picks break!.",0,$06,$00
_0A3E: dc.b $ED,$FF
_0A40: dc.b $F2,_0A63-Start,(_0A63-Start)/$100 ; dc.b $63,$0A
_0A43: dc.b $F8,"only a thief can pick locks.",0,$06,$00
_0A63: dc.b $F2,_0A83-Start,(_0A83-Start)/$100 ; dc.b $83,$0A
_0A66: dc.b $F8,"this lock requires a key.",0,$0F,$00
_0A83: dc.b $F2,_0AA2-Start,(_0AA2-Start)/$100 ; dc.b $A2,$0A
_0A86: dc.b $F8,"the lock appears jammed.",0,$06,$00
_0AA2:
dc.b $F1
_0AA3: dc.b $FF,$E9,$22,$00,$03,$31
_0AA9:
dc.b $F1
_0AAA: dc.b $FF,$E9,$22,$00,$03,$45
_0AB0:
dc.b $F1
_0AB1:
Hunk3:
; Nb reloc info
dc.b $26,$00
dc.b $F2,$02,$A8,_02CF-Start,(_02CF-Start)/$100 ; dc.b $CF,$02
dc.b $F1,$02,$08,_0396-Start,(_0396-Start)/$100 ; dc.b $96,$03
dc.b $AA,$01,$08,_03A6-Start,(_03A6-Start)/$100 ; dc.b $A6,$03
dc.b $96,$02,$08,_03AB-Start,(_03AB-Start)/$100 ; dc.b $AB,$03
dc.b $CE,$01,$60,_03BB-Start,(_03BB-Start)/$100 ; dc.b $BB,$03
dc.b $AD,$01,$00,_03CB-Start,(_03CB-Start)/$100 ; dc.b $CB,$03
dc.b $50,$01,$08,_03E3-Start,(_03E3-Start)/$100 ; dc.b $E3,$03
dc.b $91,$01,$08,_0406-Start,(_0406-Start)/$100 ; dc.b $06,$04
dc.b $B7,$01,$00,_0423-Start,(_0423-Start)/$100 ; dc.b $23,$04
dc.b $D6,$01,$08,_0445-Start,(_0445-Start)/$100 ; dc.b $45,$04
dc.b $36,$02,$78,_0466-Start,(_0466-Start)/$100 ; dc.b $66,$04
dc.b $52,$02,$00,_04B3-Start,(_04B3-Start)/$100 ; dc.b $B3,$04
dc.b $6E,$02,$00,_04BC-Start,(_04BC-Start)/$100 ; dc.b $BC,$04
dc.b $4D,$02,$08,_04DE-Start,(_04DE-Start)/$100 ; dc.b $DE,$04
dc.b $B2,$02,$00,_04FF-Start,(_04FF-Start)/$100 ; dc.b $FF,$04
dc.b $BA,$02,$00,_0523-Start,(_0523-Start)/$100 ; dc.b $23,$05
dc.b $E7,$02,$00,_0547-Start,(_0547-Start)/$100 ; dc.b $47,$05
dc.b $C9,$02,$00,_0569-Start,(_0569-Start)/$100 ; dc.b $69,$05
dc.b $11,$03,$00,_0591-Start,(_0591-Start)/$100 ; dc.b $91,$05
dc.b $F0,$02,$28,_0599-Start,(_0599-Start)/$100 ; dc.b $99,$05
dc.b $79,$02,$08,_05CA-Start,(_05CA-Start)/$100 ; dc.b $CA,$05
dc.b $07,$03,$00,_05F2-Start,(_05F2-Start)/$100 ; dc.b $F2,$05
dc.b $CD,$02,$00,_0634-Start,(_0634-Start)/$100 ; dc.b $34,$06
dc.b $14,$03,$00,_067D-Start,(_067D-Start)/$100 ; dc.b $7D,$06
dc.b $B8,$02,$00,_06BF-Start,(_06BF-Start)/$100 ; dc.b $BF,$06
dc.b $32,$02,$00,_06F2-Start,(_06F2-Start)/$100 ; dc.b $F2,$06
dc.b $CF,$01,$00,_0725-Start,(_0725-Start)/$100 ; dc.b $25,$07
dc.b $8E,$01,$08,_081F-Start,(_081F-Start)/$100 ; dc.b $1F,$08
dc.b $94,$01,$00,_082C-Start,(_082C-Start)/$100 ; dc.b $2C,$08
dc.b $93,$01,$00,_086E-Start,(_086E-Start)/$100 ; dc.b $6E,$08
dc.b $CF,$02,$00,_08C6-Start,(_08C6-Start)/$100 ; dc.b $C6,$08
dc.b $0C,$03,$60,_091E-Start,(_091E-Start)/$100 ; dc.b $1E,$09
dc.b $CA,$01,$00,_0972-Start,(_0972-Start)/$100 ; dc.b $72,$09
dc.b $EB,$01,$08,_0992-Start,(_0992-Start)/$100 ; dc.b $92,$09
dc.b $EA,$01,$08,_0999-Start,(_0999-Start)/$100 ; dc.b $99,$09
dc.b $81,$00,$00,_09A0-Start,(_09A0-Start)/$100 ; dc.b $A0,$09
dc.b $41,$00,$08,_0AA3-Start,(_0AA3-Start)/$100 ; dc.b $A3,$0A
dc.b $21,$00,$08,_0AAA-Start,(_0AAA-Start)/$100 ; dc.b $AA,$0A
END
</pre>

<pre>
Eye of the Beholder 2

The .inf file structure and data is somewhat different from its predecessor.

All offsets here are 16bit. All strings are null terminated c-strings. Filenames have usually 13 byte (8 letters + dot + 3 letters + null)

There are different data blocks:

Beginning of .inf file:
#x0000 offset to block_B
#x0002 block_A

block_A:
{
subblocks belong to different sublevels:
sub_block_A1:
{
#x0000 offset (relative to start of block_A) to sub_block_A2
#x0002 control byte, when = #xEC then this block follows:
#x0003:
{
#x0000: maze file name string usually "levelx.maz"; length: 13 byte
#x000D: file name string without extention: used to load .vmp .pal; length: 13 byte
#x001A: usually 0xFF, if not then the next 13 byte are again a string
without extention and used to load .pal
}
next: file name string without extention for sound file .adl or .snd
-> depends on game configuration;length: 13 byte
next: 2 bytes -> each my have the value #xEC or #xEA

more to follow here (monster and decoration data)
}
the following blocks are optional: [
sub_block_A2:
{
#x0000 offset to sub_block_A3
...
}

sub_block_A3
{
...
} ]
} end of block_A

block_B:
{
#x0000 offset to block_C after the scripting data
#x0002 control byte, if #xEC then this block follows:
{
(control byte | data byte) sequence;
first control byte = #xFF is already next data structure
}
here follows: 30*monster data structure, each with length 30 byte
after that: scripting data block:
{
#x0000 offset (relative to scripting data block) of the first string
next: events
next: strings
}
} end of block_B

block_C:
{
#x0000 number of special blocks wich follow; these link maze
fields to scripting data and contain flags; each 6 bytes long
#x0002 maze special 1
#x0008 maze special 2
#x000E maze special 3
...
} end of block_C

----

a maze special block has the following structure:
{
uint16: number of block in maze (0...1023)
uint16: flag
uint16: offset to scripting data (relative to scripting data block)
}

More Eye of the beholder 2 info, nothing new here. but nice to show the data storage.

struct sMonsterGFX
{
bool used;
int loadProg;
int unk0;
u8 unk1;
char* label;
};
struct sDice
{
u8 count;
u8 dice;
u8 plus;
};

struct sMonsterType
{
u8 idx; // 0
u8 unk0; //1
u8 THAC0; //2
u8 unk1; //3

sDice HPDice; //4
u8 numberOfAttacks; // 7
sDice attackDice[3]; // 16
unsigned short specialAttackFlag; //18
unsigned short AbilitiesFlag; // 20
unsigned short unk2; //22
unsigned short EXPGain; //24

u8 size;
u8 attackSound;
u8 moveSound;
u8 unk3;
// optional
bool isAttack2;
u8 distantAttack;
u8 MaxAttkCnt;
u8 attackList[4];

u8 turnUndead;
u8 unk4;
u8 unk5[3];

};

struct sMonster
{
u8 MoNo;
u8 MoTime;
short position;
u8 subpos;
u8 facing;
u8 type;
u8 pic;
u8 phase;
u8 pause;
short weapon; /* Item Number */
short pocket; /* Dropped on Monster killed */
};

struct sWallMapping
{
u8 idx;
u8 WallType;
u8 DecorationID;
u8 FileIndex; // index number in DecorationFNames
u8 unk0;
u8 unk1;
};

struct sDecorationFName
{
char GFXName[13];
char DECName[13];
};

struct sRectangle
{
short x;
short y;
short w;
short h;
};

struct sDoorInfo
{
u8 cmd;
u8 idx;
u8 typ;
u8 knob;
char GFXfile[13];

sRectangle doorRect[3];
sRectangle buttionRect[2];
u8 buttonPos[2][2];

};

.inf EOB2 dump with comments
EOB2 INF resourced fro assembler 68000 (To See here for all the INF files
EOB2-GB-FilesToTranslate.lha
EOB2-GB-FilesToTranslate.lha

Details
Download
170 KB

BOPT uo+
BOPT ue-
BOPT ua+
OUTPUT LEVEL10.INF.dec
;Source Created by "EOB2 Language File ReSourcerINF V2" Beta
;A Tool done by CFou! on Nov 2006
Start
Hunk0:
dc.b Hunk1-Start,(Hunk1-Start)/$100 ; dc.b $E9,$00
SubHunk0:
dc.b SubHunk1-Start-2,(SubHunk1-Start-2)/$100 ; dc.b $E7,$00
dc.b $EC
;Maze name
dc.b 'level10.maz',0,0
;VCN/VMP File name
dc.b 'mezz',0,'10.maz',0,0
;Palette File name
dc.b $01
dc.b 'azure',0,'0.maz',0,0
;Sound File name
dc.b 'azure',0,'0.maz',0,0
;Door name & Positions + offset
dc.b $EC
dc.b 'door2',0,'0.maz',0,0
dc.b $00,$00,$00,$14,$00,$47,$00,$09,$00,$46,$00,$09,$00,$8F,$00,$07
dc.b $00,$2F,$00,$10,$00,$58,$00,$04,$00,$1D,$00,$10,$00,$B3,$00,$01
dc.b $00,$0A,$00,$7E,$00,$28,$00,$11,$00,$B3,$00,$01,$00,$06,$00,$72
dc.b $00,$2A,$00
;Door name & Positions + offset
dc.b $FF

;Max nb Monster ????
dc.b $00,$00
;Monster file name
dc.b $FF
;Monster file name
dc.b $FF
;Monster Struct
dc.b $FF
;Decorate Structure
dc.b $EC
; Nb Decorate Block
dc.b $0C,$00
dc.b $EC
; Decorate file name
dc.b 'azure1',0,'.maz',0,0
; Decorate file name
dc.b 'azure.dec',0,'z',0,0
; Decorate Positions/offsets
dc.b $FB,$1B,$01,$11,$03,$04
dc.b $FB,$1C,$01,$12,$04,$04
dc.b $FB,$23,$00,$07,$00,$03
dc.b $FB,$24,$00,$09,$00,$03
dc.b $FB,$25,$00,$0D,$00,$03
dc.b $FB,$29,$01,$05,$00,$04
dc.b $FB,$28,$01,$03,$02,$04
dc.b $FB,$2C,$00,$FF,$00,$07
dc.b $FB,$2D,$01,$0B,$0A,$84
dc.b $FB,$2E,$01,$FF,$00,$07
dc.b $FB,$4A,$00,$FF,$00,$04
dc.b $01,$00
dc.b $03,$00
dc.b $FF,$FF,$FF,$FF
SubHunk1:
Hunk1:
dc.b Hunk3-Start,(Hunk3-Start)/$100 ; dc.b $F5,$03
dc.b $FF
Hunk2:
;TextBank Offset
dc.b TextBank-Hunk2,(TextBank-Hunk2)/$100 ; dc.b $89,$02
;Game script
_0002: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0007: dc.b $FF,$EE,_0077-Hunk2,(_0077-Hunk2)/$100 ; ->Condition branch/case
_000B: dc.b $EE,$ED,$D2,$02,$00 ; -> Condition Test
_0010: dc.b $FF,$EE,_0027-Hunk2,(_0027-Hunk2)/$100 ; ->Condition branch/case
_0014: dc.b $F8,$00,$00,$05,$00 ; FCT: Display Message
_0019: dc.b $F6,$4F,$00,$00 ; FCT: Sound
_001D: dc.b $EC,$E5,$06,$00,$16,$02,$02 ; FCT: Change Level
_0024: dc.b $F2,_0074-Hunk2,(_0074-Hunk2)/$100 ; FCT: Jump Code
_0027: dc.b $F8,$01,$00,$0F,$00 ; FCT: Display Message
_002C: dc.b $F6,$1D,$00,$00 ; FCT: Sound
_0030: dc.b $EE,$D2,$02,$00,$D2,$00,$00 ; -> Condition Test
_0037: dc.b $FF,$EE,_0041-Hunk2,(_0041-Hunk2)/$100 ; ->Condition branch/case
_003B: dc.b $FA,$E8,$00,$00,$16,$02 ; FCT: Teleport????
_0041: dc.b $EE,$D2,$02,$00,$D2,$01,$00 ; -> Condition Test
_0048: dc.b $FF,$EE,_0052-Hunk2,(_0052-Hunk2)/$100 ; ->Condition branch/case
_004C: dc.b $FA,$E8,$00,$00,$F5,$01 ; FCT: Teleport????
_0052: dc.b $EE,$D2,$02,$00,$D2,$02,$00 ; -> Condition Test
_0059: dc.b $FF,$EE,_0063-Hunk2,(_0063-Hunk2)/$100 ; ->Condition branch/case
_005D: dc.b $FA,$E8,$00,$00,$D6,$01 ; FCT: Teleport????
_0063: dc.b $EE,$D2,$02,$00,$D2,$03,$00 ; -> Condition Test
_006A: dc.b $FF,$EE,_0074-Hunk2,(_0074-Hunk2)/$100 ; ->Condition branch/case
_006E: dc.b $FA,$E8,$00,$00,$F7,$01 ; FCT: Teleport????
_0074: dc.b $F2,_0080-Hunk2,(_0080-Hunk2)/$100 ; FCT: Jump Code
_0077: dc.b $FA,$F5 ; FCT: Teleport????
_0079: dc.b $EB,$F6,$01 ; FCT: Give Experience
_007C: dc.b $E5,$06,$16,$02 ; FCT: Wait
_0080: dc.b $F1 ; FCT: End Code
_0081: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0086: dc.b $FF,$EE,_00F6-Hunk2,(_00F6-Hunk2)/$100 ; ->Condition branch/case
_008A: dc.b $EE,$ED,$D2,$03,$00 ; -> Condition Test
_008F: dc.b $FF,$EE,_00A6-Hunk2,(_00A6-Hunk2)/$100 ; ->Condition branch/case
_0093: dc.b $F8,$02,$00,$05,$00 ; FCT: Display Message
_0098: dc.b $F6,$4F,$00,$00 ; FCT: Sound
_009C: dc.b $EC,$E5,$0B,$00,$D1,$03,$03 ; FCT: Change Level
_00A3: dc.b $F2,_00F3-Hunk2,(_00F3-Hunk2)/$100 ; FCT: Jump Code
_00A6: dc.b $F8,$01,$00,$0F,$00 ; FCT: Display Message
_00AB: dc.b $F6,$1D,$00,$00 ; FCT: Sound
_00AF: dc.b $EE,$D2,$03,$00,$D2,$00,$00 ; -> Condition Test
_00B6: dc.b $FF,$EE,_00C0-Hunk2,(_00C0-Hunk2)/$100 ; ->Condition branch/case
_00BA: dc.b $FA,$E8,$00,$00,$F2,$03 ; FCT: Teleport????
_00C0: dc.b $EE,$D2,$03,$00,$D2,$01,$00 ; -> Condition Test
_00C7: dc.b $FF,$EE,_00D1-Hunk2,(_00D1-Hunk2)/$100 ; ->Condition branch/case
_00CB: dc.b $FA,$E8,$00,$00,$D1,$03 ; FCT: Teleport????
_00D1: dc.b $EE,$D2,$03,$00,$D2,$02,$00 ; -> Condition Test
_00D8: dc.b $FF,$EE,_00E2-Hunk2,(_00E2-Hunk2)/$100 ; ->Condition branch/case
_00DC: dc.b $FA,$E8,$00,$00,$B2,$03 ; FCT: Teleport????
_00E2: dc.b $EE,$D2,$03,$00,$D2,$03,$00 ; -> Condition Test
_00E9: dc.b $FF,$EE,_00F3-Hunk2,(_00F3-Hunk2)/$100 ; ->Condition branch/case
_00ED: dc.b $FA,$E8,$00,$00,$D3,$03 ; FCT: Teleport????
_00F3: dc.b $F2,_00FF-Hunk2,(_00FF-Hunk2)/$100 ; FCT: Jump Code
_00F6: dc.b $FA,$F5 ; FCT: Teleport????
_00F8: dc.b $EB,$D2,$03 ; FCT: Give Experience
_00FB: dc.b $E5,$0B,$D1,$03 ; FCT: Wait
_00FF: dc.b $F1 ; FCT: End Code
_0100: dc.b $EE,$E7,$F6,$D2,$FF,$FF ; -> Condition Test
_0106: dc.b $FF,$EE,_010D-Hunk2,(_010D-Hunk2)/$100 ; ->Condition branch/case
_010A: dc.b $FF,$ED,$03 ; ->Condition branch/case
_010D: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0112: dc.b $FF,$EE,_0126-Hunk2,(_0126-Hunk2)/$100 ; ->Condition branch/case
_0116: dc.b $F6,$0F,$11,$03 ; FCT: Sound
_011A: dc.b $FF,$ED,$01 ; ->Condition branch/case
_011D: dc.b $FA,$E8,$00,$00,$01,$03 ; FCT: Teleport????
_0123: dc.b $F2,_012E-Hunk2,(_012E-Hunk2)/$100 ; FCT: Jump Code
_0126: dc.b $FA,$F5 ; FCT: Teleport????
_0128: dc.b $EB,$11,$03 ; FCT: Give Experience
_012B: dc.b $EB,$01,$03 ; FCT: Give Experience
_012E: dc.b $F1 ; FCT: End Code
_012F: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_0134: dc.b $FF,$EE,_0148-Hunk2,(_0148-Hunk2)/$100 ; ->Condition branch/case
_0138: dc.b $F6,$0F,$C5,$03 ; FCT: Sound
_013C: dc.b $FF,$ED,$01 ; ->Condition branch/case
_013F: dc.b $FA,$E8,$00,$00,$CC,$02 ; FCT: Teleport????
_0145: dc.b $F2,_0150-Hunk2,(_0150-Hunk2)/$100 ; FCT: Jump Code
_0148: dc.b $FA,$F5 ; FCT: Teleport????
_014A: dc.b $EB,$C5,$03 ; FCT: Give Experience
_014D: dc.b $EB,$CC,$02 ; FCT: Give Experience
_0150: dc.b $F1 ; FCT: End Code
_0151: dc.b $F8,$03,$00,$01,$00 ; FCT: Display Message
_0156: dc.b $F1 ; FCT: End Code
_0157: dc.b $F8,$04,$00,$01,$00 ; FCT: Display Message
_015C: dc.b $F1 ; FCT: End Code
_015D: dc.b $EE,$E9,$03,$43,$02,$D2,$08,$00 ; -> Condition Test
_0165: dc.b $FF,$F5,$01,$FF,$62,$02,$D2,$00,$00 ; ->Condition branch/case
_016E: dc.b $FB,$F9,$EE,$84,$01
_0173: dc.b $ED,$FE,$62,$02 ; FCT: Item Consume
_0177: dc.b $FD,$43,$02 ; FCT:Open Door
_017A: dc.b $E4 ; FCT: Update Screen
_017B: dc.b $E5,$01,$00 ; FCT: Wait
_017E: dc.b $FF,$E9,$41,$02,$01,$1B ; ->Condition branch/case
_0184: dc.b $F1 ; FCT: End Code
_0185: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_018A: dc.b $FF,$EE,_019F-Hunk2,(_019F-Hunk2)/$100 ; ->Condition branch/case
_018E: dc.b $F6,$0F,$65,$02 ; FCT: Sound
_0192: dc.b $FC,$43,$02 ; FCT: Close Door
_0195: dc.b $FF,$ED,$01 ; ->Condition branch/case
_0198: dc.b $FA,$E8,$00,$00,$2C,$03 ; FCT: Teleport????
_019E: dc.b $F0 ; FCT: Return
_019F: dc.b $FA,$F5 ; FCT: Teleport????
_01A1: dc.b $EB,$65,$02 ; FCT: Give Experience
_01A4: dc.b $EB,$2C,$03 ; FCT: Give Experience
_01A7: dc.b $F1 ; FCT: End Code
_01A8: dc.b $F6,$01,$0F,$01 ; FCT: Sound
_01AC: dc.b $E4 ; FCT: Update Screen
_01AD: dc.b $E5,$01,$00 ; FCT: Wait
_01B0: dc.b $FF,$E9,$0F,$01,$00,$1B ; ->Condition branch/case
_01B6: dc.b $FF,$F7,$4F,$00,$2C ; ->Condition branch/case
_01BB: dc.b $F7,$EF,$01 ; FCT: Set Flag
_01BE: dc.b $F1 ; FCT: End Code
_01BF: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_01C4: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_01CD: dc.b $FF,$F9,$E0,$D2,$04,$00 ; ->Condition branch/case
_01D3: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$01,$00 ; ->Condition branch/case
_01DC: dc.b $FF,$F9,$F1,$F1,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_01E5: dc.b $FF,$F9,$F8,$EE,_01FA-Hunk2,(_01FA-Hunk2)/$100 ; ->Condition branch/case
_01EB: dc.b $FF,$F7,$4D,$00,$24 ; ->Condition branch/case
_01F0: dc.b $F6,$0C,$4D,$00 ; FCT: Sound
_01F4: dc.b $FF,$E9,$0F,$01,$00,$1B ; ->Condition branch/case
_01FA: dc.b $EE,$E0,$D2,$02,$00 ; -> Condition Test
_01FF: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0208: dc.b $FF,$F9,$E0,$D2,$08,$00 ; ->Condition branch/case
_020E: dc.b $FF,$F5,$00,$FF,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0217: dc.b $FF,$F9,$F1,$F1,$4D,$00,$D2,$00,$00 ; ->Condition branch/case
_0220: dc.b $FF,$F9,$F8,$EE,_0235-Hunk2,(_0235-Hunk2)/$100 ; ->Condition branch/case
_0226: dc.b $FF,$F7,$4D,$00,$23 ; ->Condition branch/case
_022B: dc.b $F6,$0C,$4D,$00 ; FCT: Sound
_022F: dc.b $FF,$E9,$0F,$01,$00,$01 ; ->Condition branch/case
_0235: dc.b $F1 ; FCT: End Code
_0236: dc.b $EE,$EF,$01,$D2,$01,$00 ; -> Condition Test
_023C: dc.b $FF,$EE,_025B-Hunk2,(_025B-Hunk2)/$100 ; ->Condition branch/case
_0240: dc.b $EE,$EF,$02,$D2,$01,$00 ; -> Condition Test
_0246: dc.b $FF,$EE,_0258-Hunk2,(_0258-Hunk2)/$100 ; ->Condition branch/case
_024A: dc.b $FF,$F7,$4F,$00,$00 ; ->Condition branch/case
_024F: dc.b $F5,$EF,$01 ; FCT: Clear Flag
_0252: dc.b $F5,$EF,$02 ; FCT: Clear Flag
_0255: dc.b $F2,_025B-Hunk2,(_025B-Hunk2)/$100 ; FCT: Jump Code
_0258: dc.b $F7,$EF,$02 ; FCT: Set Flag
_025B: dc.b $F1 ; FCT: End Code
_025C: dc.b $EE,$F7,$4F,$00,$D2,$2C,$00 ; -> Condition Test
_0263: dc.b $FF,$EE,_0288-Hunk2,(_0288-Hunk2)/$100 ; ->Condition branch/case
_0267: dc.b $EE,$E0,$D2,$01,$00 ; -> Condition Test
_026C: dc.b $FF,$EE,_0280-Hunk2,(_0280-Hunk2)/$100 ; ->Condition branch/case
_0270: dc.b $F6,$0F,$4F,$00 ; FCT: Sound
_0274: dc.b $FF,$ED,$01 ; ->Condition branch/case
_0277: dc.b $FA,$E8,$00,$00,$2C,$03 ; FCT: Teleport????
_027D: dc.b $F2,_0288-Hunk2,(_0288-Hunk2)/$100 ; FCT: Jump Code
_0280: dc.b $FA,$F5 ; FCT: Teleport????
_0282: dc.b $EB,$6F,$02 ; FCT: Give Experience
_0285: dc.b $EB,$2C,$03 ; FCT: Give Experience
_0288: dc.b $F1 ; FCT: End Code

;TextBank
TextBank:
dc.b 'going down...',0
dc.b 'you can',"'",'t go that way.',0
dc.b 'going up...',0
dc.b 'the plaque reads: you will pay for your freedom...',0
dc.b 'the plaque reads: one item.',0
Hunk3:
;Special Maze Blocks Bank (offset)
; Nb Special Maze Blocks
dc.b $0C,$00
; Special Maze Blocks List:
dc.b $F6,$01,$A8,$00,_0002-Hunk2,(_0002-Hunk2)/$100 ; dc.b $02,$00
dc.b $D2,$03,$A8,$00,_0081-Hunk2,(_0081-Hunk2)/$100 ; dc.b $81,$00
dc.b $11,$03,$A8,$00,_0100-Hunk2,(_0100-Hunk2)/$100 ; dc.b $00,$01
dc.b $C5,$03,$A8,$00,_012F-Hunk2,(_012F-Hunk2)/$100 ; dc.b $2F,$01
dc.b $A4,$01,$00,$00,_0151-Hunk2,(_0151-Hunk2)/$100 ; dc.b $51,$01
dc.b $21,$02,$00,$00,_0157-Hunk2,(_0157-Hunk2)/$100 ; dc.b $57,$01
dc.b $41,$02,$00,$00,_015D-Hunk2,(_015D-Hunk2)/$100 ; dc.b $5D,$01
dc.b $65,$02,$A8,$00,_0185-Hunk2,(_0185-Hunk2)/$100 ; dc.b $85,$01
dc.b $0F,$01,$00,$00,_01A8-Hunk2,(_01A8-Hunk2)/$100 ; dc.b $A8,$01
dc.b $4D,$00,$78,$00,_01BF-Hunk2,(_01BF-Hunk2)/$100 ; dc.b $BF,$01
dc.b $01,$00,$00,$00,_0236-Hunk2,(_0236-Hunk2)/$100 ; dc.b $36,$02
dc.b $4F,$00,$A8,$00,_025C-Hunk2,(_025C-Hunk2)/$100 ; dc.b $5C,$02
END
</pre>

Eye of the Beholder

2014-12-12T20:19:58Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.dat, *.dec
| Format = [[Eye of the Beholder decorations Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.fnt
| Format = [[Eye of the Beholder bitmap font Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.inf
| Format = [[Eye of the Beholder maze information Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Westwood Font Format v2

2014-12-12T20:13:51Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

Contains bit-map for the fonts.

'''HEADER'''
<pre>
short int fsize; // Size of the file
short int unknown1; // Unknown entry (always 0x0500 or 0x0002)
short int unknown2; // Unknown entry (always 0x000e)
short int unknown3; // Unknown entry (always 0x0014)
short int wpos; // Offset of char. widths array (abs. from beg. of file)
short int cdata; // Offset of char. graphics data (abs. from beg. of file)
short int hpos; // Offset of char. heights array (abs. from beg. of file)
short int unknown4; // Unknown entry (always 0x1012 or 0x1011) maybe a file version??
unsigned char zero; //zero value
unsigned char nchars; // Number of characters in font minus 1
unsigned char maxh; // Font height
unsigned char maxw; // Max. character width
</pre>

'''EOB 1 (PC) - Fixed Font'''
File Format

<pre>
typedef struct {
short int filesize; // the size of the file
short int charoffset[128]; // the offset of the pixel data from the beginning
// of the file, the index is the ascii value
unsigned char width; // the width of a character in pixel
unsigned char height; // the height of a character in pixel
unsigned char data[128][height]; // the pixel data, one byte per line
} TFIXEDFONT;
</pre>

'''Rendering'''

To render a character from the font, you could use something like the following code:

<pre>
TFIXEDFONT fnt; // assume this is loaded and initialized
int x, y; // position to draw the character
int color; // color of the text
char c; // the character to be drawn

for (int h = 0; h < fnt.height; h++) {
unsigned char line = fnt.data[c][h];
unsigned char bit = 0x80;
for (int w = 0; w < fnt.width; w++) {
if ((line & bit) == bit)
DrawPixel(x + w, y + h, color);
bit = bit >> 1;
}
}
</pre>

Eye of the Beholder

2014-12-12T20:11:50Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.dat, *.dec
| Format = [[Eye of the Beholder decorations Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = eob.fnt
| Format = [[Eye of the Beholder bitmap font Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Eye of the Beholder Decorations Format

2014-12-12T20:09:14Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

This document describes the decoration rectangle data files (.dat) that are bundled with each decoration image file.
In EOB2 they have the filename extension .dec

All unsigned short are big endian! They are little endian in the PC version.

'''File Format'''
<pre>
struct Decoration
{
unsigned short nbrDecorations;
struct Decoration decorations[nbrDecorations]; /* Indexed into by the WallMapping in the [[eob.inf|.inf]] file. */
unsigned short nbrDecorationRectangles;
struct DecorationRectangle rectangles[nbrDecorationRectangles];
};
</pre>

'''Sub structures'''

<pre>
struct Decoration
{
unsigned char rectangleIndices[10]; /* indices into DecorationData.rectangles */
unsigned char linkToNextDecoration; /* index into DecorationData.decorations */
unsigned char flags;
unsigned short xCoords[10]; /* coordinate in the game view, where to render the overlay */
unsigned short yCoords[10];
};
</pre>

If rectangle index is 0xFF, there isn't a decoration for that view position.
Each of these 10 indices in the arrays corresponds to the 10 possible overlay graphics positions in the viewport.
TODO: Describe linkToNextDecoration, flags and the coordinate system. (JackAsser will fix this)

<pre>
struct DecorationRectangle
{
unsigned short x; /* Multiply by 8 to get actual screen coord */
unsigned short y;
unsigned short w; /* Multiply by 8 to get actual width */
unsigned short h;
};
</pre>

Each rectangle describes an area in the .cps graphics file stated by the 0xec command code in the .inf file.

Drawing a decoration + Pseudocode(EOB2)
(what about EOB1?)
<pre>
decoration wall positions (0..9):

9 7 3 7 9
8 6 2 6 8
8 5 1 5 8
4 0 4
^=party pos.

</pre>

The following table contains drawing information for each view position:
xflip: for side walls: 0=left, 1=right
wall: decoration position number, -1=none available for this position
xdelta: horizontal shift (decoration on wall only) in render window for this wall position (multiply with 8)
<pre>
CDecPos: array [0 .. 25] of TPos = (
(XFlip: 0; Wall: -1; XDelta: 0),
(XFlip: 0; Wall: 9; XDelta: 0),
(XFlip: 0; Wall: 7; XDelta: 0),

(XFlip: 1; Wall: 7; XDelta: 0),
(XFlip: 1; Wall: 9; XDelta: 0),
(XFlip: 0; Wall: -1; XDelta: 0),

(XFlip: 0; Wall: 3; XDelta: -12),
(XFlip: 0; Wall: 3; XDelta: -6),
(XFlip: 0; Wall: 3; XDelta: 12),
(XFlip: 0; Wall: 3; XDelta: 6),
(XFlip: 0; Wall: 3; XDelta: 0), //middle front wall

(XFlip: 0; Wall: 8; XDelta: 0),
(XFlip: 0; Wall: 6; XDelta: 0),

(XFlip: 1; Wall: 6; XDelta: 0),
(XFlip: 1; Wall: 8; XDelta: 0),

(XFlip: 0; Wall: 2; XDelta: -10),
(XFlip: 0; Wall: 2; XDelta: 10),
(XFlip: 0; Wall: 2; XDelta: 0), //middle front wall

(XFlip: 0; Wall: 5; XDelta: 0),

(XFlip: 1; Wall: 5; XDelta: 0),

(XFlip: 0; Wall: 1; XDelta: -16),
(XFlip: 0; Wall: 1; XDelta: 16),
(XFlip: 0; Wall: 1; XDelta: 0), //middle front wall

(XFlip: 0; Wall: 4; XDelta: 0),

(XFlip: 1; Wall: 4; XDelta: 0),
(XFlip: 0; Wall: 0; XDelta: 0)
);
</pre>
Decorations can consist of more than one rectangle, which are drawn together.
They are given as a list:
<pre>
procedure DrawCompleteDecoration(GFXIndex, DecNumber, Position:longint; isAtWall:boolean);
begin
repeat
DrawDecorationPart(GFXIndex, DecNumber, Position, isAtWall); // draw a part of the decoration
DecNumber:= Decoration[DecNumber].NextDecoration; // go to next part
until DecNumber = 0;
end;
</pre>

GFXIndex points to the data file where the decoration resides: for example mezz2.cps
DecNumber is the number of the Decoration.
Position (range 0..25) is the wall position (side and front walls).
isAtWall tells if the decoration is at a wall, this is true if the walltype in the
decoration mapping definition in the .inf file is unequal zero.

<pre>
procedure DrawDecorationPart(GFXIndex, DecNumber, Position:longint; isAtWall:boolean);

var
i,j, //pos in cps graphics
s,t:longint; //pos on screen
q:byte;
dx,pos : longint;
mirrored : boolean;
begin

//get the horizontal shift for the decoration according to its position.
//if the decoration is drawn at a wall, we use the table above.
//otherwise the decoration is placed in the middle of a field,
// for example a pit or pressure plate...
dx := 0;
if isAtWall then
dx := 8*CDecPos[Position].XDelta
else
case Position of
6 : dx := -88;
7 : dx := -40;
8 : dx := 88;
9 : dx := 40;

15 : dx := -59;
16 : dx := 59;

20 : dx := -98;
21 : dx := 98;
end;

//translate view positions (0..25) to decoration view position (0..9)
pos := CDecPos[Position].Wall;

if pos >= 0 then
begin

//get the number of the decoration rectangle for the corresponding view position
q := Decoration[DecNumber].RectangleIndices[pos];

//if rectangle index is $FF, then there doesn't exist a decoration for this view position
if q <> $FF then
begin

//Bit 0 in Flags: for front walls (and not for side walls):
// for example, a decoration consists of two parts,
// and the second part is the first one, but mirrored..
mirrored := false;
case Position of
6..10, 15..17, 20..22, 25: mirrored := boolean(Decoration[DecNumber].Flags and $01);
end;

t:= Decoration[DecNumber].YCoords[pos];

for j:= Rectangles[q].y to Rectangles[q].y+Rectangles[q].Height-1 do
begin

if mirrored then
s := 22*8 - Decoration[DecNumber].XCoords[pos] - 1
else
s := Decoration[DecNumber].XCoords[pos];

for i := Rectangles[q].x*8 to Rectangles[q].x*8+Rectangles[q].Width*8-1 do
begin

if mirrored then
begin
PutPixel(s+dx, t, Graphics[GFXIndex][320*j + i]);
Dec(s);
end else
begin
if CDecPos[Position].XFlip = 0 then
PutPixel(s+dx, t, Graphics[GFXIndex][320*j + i]) //left side walls; front walls
else
PutPixel(22*8-(s+dx), t, Graphics[GFXIndex][320*j + i]); //right side walls only
Inc(s);
end;

end; //for i

Inc(t);
end; //for j

end; // q<>$FF

end; //pos>0

end;
</pre>

Eye of the Beholder

2014-12-12T20:05:38Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = *.dat, *.dec
| Format = [[Eye of the Beholder decorations Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Eye of the Beholder text.dat Format

2014-12-12T20:04:13Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

<pre>
2b absolute file offset to string
... string offsets table
first string null terminated
... strings table

Note - String special char:
00 end string
0D new line
20 space
06 xx change color. xx is one of the 16 color vga standard (09=light cyan, 06=White, etc.)
01 page break
</pre>

Eye of the Beholder

2014-12-12T19:56:08Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = text.dat
| Format = [[Eye of the Beholder text.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Eye of the Beholder itemtype.dat Format

2014-12-12T19:52:46Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

<pre>
short int NumberOfItems;
ItemType Items[NumberOfItems];
</pre>

<pre>
struct Dice {
unsigned char rolls; // F.e. 4
unsigned char sides; // F.e. T6
unsigned char base; // F.e. +7
// = 4T6+7
};
</pre>

<pre>
struct ItemType {
unsigned short invbits; // At which position in inventory it is allowed to be put. See INVENTORY_USAGE_* above.
short int handbits; // In which hand it can be used
char acadd; // Adds to armor class
unsigned char profallowed; // Allowed for this profession. See CLASS_USAGE_* above.
unsigned char handallowed; // Allowed for this hand

/* Damage versus small */
Dice damageVsSmall;

/* Damage versus big */
Dice damageVsBig;

char unknown1; // Always 0 in EotB 1
char unknown2; // Always 0 in EotB 2
char unknown3;
};
</pre>

<pre>
typedef enum {
INVENTORY_USAGE_NONE = 0,
INVENTORY_USAGE_QUIVER = 1 << 0,
INVENTORY_USAGE_ARMOUR = 1 << 1,
INVENTORY_USAGE_BRACERS = 1 << 2,
INVENTORY_USAGE_BACKPACK = 1 << 3,
INVENTORY_USAGE_BOOTS = 1 << 4,
INVENTORY_USAGE_HELMET = 1 << 5,
INVENTORY_USAGE_NECKLACE = 1 << 6,
INVENTORY_USAGE_BELT = 1 << 7,
INVENTORY_USAGE_RING = 1 << 8
} InventoryUsage;
</pre>

<pre>
typedef enum {
CLASS_USAGE_NONE = 0,
CLASS_USAGE_FIGHTER = 1 << 0,
CLASS_USAGE_MAGE = 1 << 1,
CLASS_USAGE_CLERIC = 1 << 2,
CLASS_USAGE_THIEF = 1 << 3,
} ClassUsage;
<pre>

Eye of the Beholder

2014-12-12T19:50:54Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

[[Eye of the Beholder]] is a role-playing video game for computers and video game consoles developed by Westwood Studios. It was published by Strategic Simulations, Inc. in 1991 for the MS-DOS operating system and later ported to the Amiga, the Sega CD, Game Boy Advance and the SNES. The Sega CD version features an exclusive soundtrack composed by Yuzo Koshiro

{{BeginGameFileList}}
{{GameFile
| Name = *.adl
| Format = [[ADL Format]]
| KnownFormat = Yes
| Desc = Sound
}}

{{GameFile
| Name = *.cps
| Format = [[Westwood CPS Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.cmp
| Format = [[Westwood CMP Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.ega
| Format = [[Westwood EGA Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.col
| Format = [[Westwood COL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = *.pal
| Format = [[Westwood PAL Format]]
| KnownFormat = Yes
| Desc = Image
}}

{{GameFile
| Name = item.dat
| Format = [[Eye of the Beholder item.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{GameFile
| Name = itemtype.dat
| Format = [[Eye of the Beholder itemtype.dat Format]]
| KnownFormat = Yes
| Desc = Items
}}

{{EndGameFileList}}

[[Category:Westwood]]
[[Category:3D dungeon]]

Eye of the Beholder item.dat Format

2014-12-12T19:49:22Z

The coder: Saving now defunt EOB wiki

<pre>

short int NumberOfItems;
struct Item {

char unid; /* Number of name string, if not identified */
char id; /* Number of name string if identified */
char bits; /* Magic and so on */
/* 0x80 = Bit = GlowMagic */
/* 0x40 = Bit = IsIdentified */
/* 0x20 = Bit = IsCursed */
/* 0x08 = Bit = Sucks damage points from */
/* target to attacker */
char pic; /* Number of icon picture */
char type; /* Axe, Long Sword etc. see below */
char subpos; /* Where the item lies at position */
/* In Maze: */
/* 0..3-> Bottom */
/* 4..7-> Wall (N,E,S,W) */
/* For EotB I: 0..3-> Floor NW,NE,SW,SE */
/* 8-> Compartment */
/* If in inventory: */
/* 0..26-> Position in Inventory */
short int pos; /* Position in maze x+y*32 */
/* <= 0: Consumed */
short int next; /* Number of next item in list (position) */
short int prev; /* Number of previous item in list (pos) */
/* New: Single linked list */
char level; /* Level, where the item lies, <= no level */
char value; /* The value of item, -1 if consumed */
/* Kind of keys/potions/wands */

} [NumberOfItems];

short int NumberOfItemName;
char ItemName[NumberOfItemName][35];

</pre>

item '''type''' correspondance
<pre>
0: "Axe" / 'Drow Cleaver'
1: "Long Sword" / Adamantite Long Sword /
2: "Short Sword"
3: "Orb of Power"
4: ???
5: "Dagger" / 'Guinsoo' / 'Backstabber'
6: "Potion" / Dwarfen Healing Potion
7: "Bow"
8: ???
9: "Spear"
10: "Halberd"
11: "Mace"
12: "Flail" ; ( Geissel )
13: "Staff" / Staff
14: "Sling"
15: "Dart" / Adamantite Dart
16: "Arrow"
17: ???
18: "Rock" / Igneous Rock
19: ???
20: "Chainmail"
21: "Helmet" / Dwarf Helmet
22: "Leather armor"
23: ???
24: "Plate Mail"
25: "Scale Mail"
26: ???
27: "Shield"
28: "Lock Picks"
29: "Spellbook"
30: "Holy Symbol" / Cleric Holy Symbol / Paladin Holy Symbol
31: "Food" / Iron Rations
32: "Boots" / Leather Boots
33: "Bones" / Dwarf Bones / Halfling Bones /
34: "Mage Scroll" / Scroll
35: "Cleric Scroll" / Scroll /
36: "Text Scroll" / Commission and Letter of Marquee
37: "Stone" / Stone Item
Stone Holy Symbol (1) / Stone Necklace (2) /
Stone Orb (3) / Stone Dagger (4) / Medaillon (5) /
Stone Scepter (6) / Stone Ring (7) /
38: "Key"
Silver Key (1) / Gold Key (2) / Dwarfen Key (3)/
Key (4) / Skull Key (5) / Drow Key (6) /
Jeweled Key (7) / Ruby Key (8)
39: "Potion"
40: "Gem"
41: "Robe" / Fancy Robe /
42: "Ring of Protection +2"
43: "Bracers"
44: "Necklace" / Medaillon
45: ????
46: "Medaillon" Luck Stone Medaillon (1)
47: "Ring"
48: "Wand" / Wand of Slivias
49: "Kenku Egg"
;--
50: ??? -> Usename 1
;---------------
; Handspell-Itemtypes
51:
52:
53:
54:
55:
56:
</pre>

User talk:The coder

2014-12-07T09:27:16Z

The coder: answer

Hi The coder - any chance you can reupload [[:File:Eye of the Beholder.gif]] as a 320x200 .png? Then it will match all the other title screens and show up on the game's page automatically. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 13:09, 6 December 2014
[[User:The coder|The coder]] ([[User talk:The coder|talk]]) I just can't figure out how to do this correctly :(

File:Eye of the Beholder.png

2014-12-07T09:25:27Z

The coder: Eye of the Beholder title screen

Eye of the Beholder title screen

Westwood CPS Format

2014-12-02T17:01:31Z

The coder: Saving of now defunct eob.wikispaces.com

This kind of file contains images. Usually are 320x200 pixel in size, 256 colors for PC version, 32 colors for Amiga version.
The images can be compressed with different compression method. They may or may not contain a palette. The palette in case that it exist is placed just after the header. The image data is placed after the header and the palette.

It start with an header, with is the same used for compressed file

struct FHeader {
unsigned short FileSize;
unsigned short CompressionType;
unsigned int UncompressedSize;
unsigned short PaletteSize;
}

FileSize
<Size of file with Header> for compression method 1, 2 and 3.
<Size of file with Header>-02h for compression method 0 and 4.

Compression Type
Indicate the compression method used to store the image.

0000h uncompressed
0001h [[Crunch-1]]
0002h [[Westwood Compression Method 2]]
0003h [[Westwood Compression Method 3]]
0004h [[Westwood Format-80 Compression]]

Uncompressed size
Size of uncompressed file without header.
Usually is 64000, that is right 320x200

Palette size
Is the size of the palette.
0000h palette not present
0300h 256 colors palette (Lands Of Lore)
0040h 1 palette of 32 Colors for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
0080h 2 palettes of 32 Colors for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
00C0h 3 palettes of 32 Colors palettes for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
0100h 4 palettes of 32 Colors palettes for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')

PC: Once decompressed, the image is in standard VGA format 320x200 pixel, where 1 byte is 1 pixel.
AMIGA: Once decompressed, the image is in standard 5 bimaps 320x200 screen (32 colors).

for EOB2 Amiga it can have 1 to 4 inside palettes of 16 colors for multiscreen CPS files as SCOUx.CPS

For EOB1 Amiga palette can be found at the end of decompressed datas (offset $1f40*5 to see after)

AMIGA SPEC

After image decompression the size is either 40000 bytes or 40064 bytes in size (EOB1).

The first 40000 bytes contain five 320x200 bitplanes. Each bitplane is 320x200/8 (8000) bytes big. This is standard amiga graphics data, please consult your nearest amiga reference for information.

Palette data
The optional 64 bytes are palette data. Each palette entry is 16 bits in the following format:

111111
Bit 5432109876543210
____RRRRGGGGBBBB

In other words, 12 bit RGB in _RGB pixel format.

In total there are 32 palette entries, consistent with 5 bitplanes (32 colors).

Image data
The resolution of the images are the same as in the PC version. However, since we only use 32 colors a pixel only need 5 bit each.
The pixels are arranged as follows:

byte 0 byte 1 byte 2 ... 40 bytes per line (40*8=320 pixels)
plane 0: .......x ........ ........
plane 1: x
plane 2: x
plane 3: x
plane 4: x

Each byte consists of 8 pixels. Each bit plane consists of 320*200 pixels = 320*200/8 bytes.
The color of each pixel is made up of the corresponding bits down the same bit position in the bitplanes. This gives each pixels a 5-bit value which is an index into the 32-color palette. In the example above the pixel at position (0,7) is described.

Pseudo code for a planar to chunky implementation

unsigned char bitPlanes[5][8000];
int bytePos=x/8+y*40;
int bitPos=7-x&7;
unsigned char colorIndex=((!!(bitPlanes[0][bytePos]&(1<<bitPos)))<<0) |
((!!(bitPlanes[1][bytePos]&(1<<bitPos)))<<1) |
((!!(bitPlanes[2][bytePos]&(1<<bitPos)))<<2) |
((!!(bitPlanes[3][bytePos]&(1<<bitPos)))<<3) |
((!!(bitPlanes[4][bytePos]&(1<<bitPos)))<<4);
unsigned short paletteValue=palette[colorIndex];

The above code can seem a bit unreadable to the untrained C-eye. !! simply turns a non zero value to 1, zero stays zero. It's actually a double negation, but I'd like to call it a normalize operator.

Westwood CPS Format

2014-12-02T16:57:31Z

The coder: Saving of now defunct eob.wikispaces.com

This kind of file contains images. Usually are 320x200 pixel in size, 256 colors for PC version, 32 colors for Amiga version.
The images can be compressed with different compression method. They may or may not contain a palette. The palette in case that it exist is placed just after the header. The image data is placed after the header and the palette.

It start with an header, with is the same used for compressed file

struct FHeader {
unsigned short FileSize;
unsigned short CompressionType;
unsigned int UncompressedSize;
unsigned short PaletteSize;
}

FileSize
<Size of file with Header> for compression method 1, 2 and 3.
<Size of file with Header>-02h for compression method 0 and 4.

Compression Type
Indicate the compression method used to store the image.
0000h uncompressed
0001h [Crunch 1]
0002h [Format 2]
0003h [Format 3]
0004h [Format 80]

Uncompressed size
Size of uncompressed file without header.
Usually is 64000, that is right 320x200

Palette size
Is the size of the palette.
0000h palette not present
0300h 256 colors palette (Lands Of Lore)
0040h 1 palette of 32 Colors for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
0080h 2 palettes of 32 Colors for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
00C0h 3 palettes of 32 Colors palettes for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')
0100h 4 palettes of 32 Colors palettes for EOB2 AMIGA (Muli window screens CPS as ' SCOUx.CPS')

PC: Once decompressed, the image is in standard VGA format 320x200 pixel, where 1 byte is 1 pixel.
AMIGA: Once decompressed, the image is in standard 5 bimaps 320x200 screen (32 colors).

for EOB2 Amiga it can have 1 to 4 inside palettes of 16 colors for multiscreen CPS files as SCOUx.CPS

For EOB1 Amiga palette can be found at the end of decompressed datas (offset $1f40*5 to see after)

AMIGA SPEC

After image decompression the size is either 40000 bytes or 40064 bytes in size (EOB1).

The first 40000 bytes contain five 320x200 bitplanes. Each bitplane is 320x200/8 (8000) bytes big. This is standard amiga graphics data, please consult your nearest amiga reference for information.

Palette data
The optional 64 bytes are palette data. Each palette entry is 16 bits in the following format:

111111
Bit 5432109876543210
____RRRRGGGGBBBB

In other words, 12 bit RGB in _RGB pixel format.

In total there are 32 palette entries, consistent with 5 bitplanes (32 colors).

Image data
The resolution of the images are the same as in the PC version. However, since we only use 32 colors a pixel only need 5 bit each.
The pixels are arranged as follows:

byte 0 byte 1 byte 2 ... 40 bytes per line (40*8=320 pixels)
plane 0: .......x ........ ........
plane 1: x
plane 2: x
plane 3: x
plane 4: x

Each byte consists of 8 pixels. Each bit plane consists of 320*200 pixels = 320*200/8 bytes.
The color of each pixel is made up of the corresponding bits down the same bit position in the bitplanes. This gives each pixels a 5-bit value which is an index into the 32-color palette. In the example above the pixel at position (0,7) is described.

Pseudo code for a planar to chunky implementation

unsigned char bitPlanes[5][8000];
int bytePos=x/8+y*40;
int bitPos=7-x&7;
unsigned char colorIndex=((!!(bitPlanes[0][bytePos]&(1<<bitPos)))<<0) |
((!!(bitPlanes[1][bytePos]&(1<<bitPos)))<<1) |
((!!(bitPlanes[2][bytePos]&(1<<bitPos)))<<2) |
((!!(bitPlanes[3][bytePos]&(1<<bitPos)))<<3) |
((!!(bitPlanes[4][bytePos]&(1<<bitPos)))<<4);
unsigned short paletteValue=palette[colorIndex];

The above code can seem a bit unreadable to the untrained C-eye. !! simply turns a non zero value to 1, zero stays zero. It's actually a double negation, but I'd like to call it a normalize operator.

Category:Eye of the Beholder

2014-12-02T16:42:20Z

The coder: partial submit

ADL Format

2014-12-02T16:32:18Z

The coder: Saving of now defunct eob.wikispaces.com

ADL files are used in the PC-DOS version of EOB1&2 to play sound through an adlib compatible sound card.

For EOB2:
Offset:
#x0000: 120 bytes which are indices for the following pointer array
#x0078: 250*16bit pointers for sound/music tracks
#x026C: start of configuration data for adlib instruments
#x????: tracks

EOB1 ADL files are adlib.dat and sound.dat. The difference to EOB2 is the size of the pointer array for tracks which is here 300 bytes instead of 500.

Category:Eye of the Beholder

2014-12-02T16:28:54Z

The coder: Saving of now defunct eob.wikispaces.com

Westwood XOR Delta

2014-11-20T20:13:43Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

Format40
----------

As I said before the images in Format40 must be xor-ed over a previous image,
or against a black screen (as in the .WSA format).
It is used when there are only minor changes between an image and a following
one.

Here I'll assume that the old image is in Dest, and that the Dest pointer is
set to the beginning of that buffer.

As for the Format80, there are many commands:

(1) 1 byte
byte
+---+---+---+---+---+---+---+---+
| 1 | | | | | | | |
+---+---+---+---+---+---+---+---+
\___________________________/
|
Count

Skip count bytes in Dest (move the pointer forward).

(2) 3 bytes
byte word
+---+---+---+---+---+---+---+---+ +---+-----+-------+
| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | ... | |
+---+---+---+---+---+---+---+---+ +---+-----+-------+
\_____________/
|
Count

Skip count bytes.

(3) 3 bytes
byte word
+---+---+---+---+---+---+---+---+ +---+---+-----+-------+
| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 0 | ... | |
+---+---+---+---+---+---+---+---+ +---+---+-----+-------+
\_____________/
|
Count

Xor next count bytes. That means xor count bytes from Source with bytes in Dest.

(4) 4 bytes
byte word byte
+---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+
| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 1 | ... | | | |
+---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+
\_____________/ value
|
Count

Xor next count bytes in Dest with value.

5) 1 byte
byte
+---+---+---+---+---+---+---+---+
| 0 | | | | | | | |
+---+---+---+---+---+---+---+---+
\___________________________/
|
Count

Xor next count bytes from source with dest.

6) 3 bytes
byte byte byte
+---+---+---+---+---+---+---+---+ +-------+ +-------+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | |
+---+---+---+---+---+---+---+---+ +-------+ +-------+
Count Value

Xor next count bytes with value.

All images end with a 80h 00h 00h command.

I think these are all the commands, but there might be some other.
If you find anything new, please add them.

As before here's some code :

DP = destination pointer
SP = source pointer
Source is buffer containing the Format40 data
Dest is the buffer containing the image over which the second has
to be xor-ed

SP:=0;
DP:=0;
repeat
Com:=Source[SP];
Inc(SP);

if (Com and $80)<>0 then {if bit 7 set}
begin
if Com<>$80 then {small skip command (1)}
begin
Count:=Com and $7F;
Inc(DP,Count);
end
else {Big commands}
begin
Count:=Word(Source[SP]);
if Count=0 then break;
Inc(SP,2);

Tc:=(Count and $C000) shr 14; {Tc=two topmost bits of count}

case Tc of
0,1 : begin {Big skip (2)}
Inc(DP,Count);
end;
2 : begin {big xor (3)}
Count:=Count and $3FFF;
for i:=1 to Count do
begin
Dest[DP]:=Dest[DP] xor Source[SP];
Inc(DP);
Inc(SP);
end;
end;
3 : begin {big repeated xor (4)}
Count:=Count and $3FFF;
b:=Source[SP];
Inc(SP);
for i:=1 to Count do
begin
Dest[DP]:=Dest[DP] xor b;
Inc(DP);
end;
end;
end;
end;
end else {xor command}
begin
Count:=Com;
if Count=0 then
begin {repeated xor (6)}
Count:=Source[SP];
Inc(SP);
b:=Source[SP];
Inc(SP);
for i:=1 to Count do
begin
Dest[DP]:=Dest[DP] xor b;
Inc(DP);
end;
end else {copy xor (5)}
for i:=1 to Count do
begin
Dest[DP]:=Dest[DP] xor Source[SP];
Inc(DP);
Inc(SP);
end;
end;
until false;

[[Category:File Formats]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Lands Of Lore]]
[[Category:Eye of the Beholder]]

Westwood RLE

2014-11-20T20:11:40Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

Format 3
----------

I called this method "compression 3", since there are 3 different commands to draw an image. Here I will explain that decompression method.

As I said before, we have 3 different commands; to find which command to execute, we have to read a byte from the file, and we must read it as a signed one:

Command 0: copy

1 signed byte
[x|x|x|x|x|x|x|x] > 0
count

command : Copy next _count_ pixels from source buffer to dest buffer.

Command 1: fill (1)

1 signed byte
[0|0|0|0|0|0|0|0]

We have to read the next word (2 bytes) from src buffer (And swap bytes inside that word if we are working on a little endian machine (x86, for example)); that value will be "count".
Then we read another byte, which is the "code".
command: Fill _count_ pixels with _code_ color.

Command 2: fill (2)

1 signed byte
[x|x|x|x|x|x|x|x] < 0

This byte, after we subtract it from 0, is "count".
We then read another byte, which will be "code".
command : Fill _count_ pixels with _code_ color.

Example decompression code

Notice that is actually uses Signed bytes for the command, the other code didn't and I think that was the main issue.

int cps_rle(unsigned char *src, unsigned char *dest, int len, bool swapWord) // Source data, Dest Data, and source size.
{

s8 com; // s8 is a signed byte
s16 count;// signed word or short.
u8 col, debug;
int DP, SP, i;
DP=0;
SP=0;

while( SP< len)
{
com = src[SP];
SP++;
if (com > 0) // Copy command
{
for(i=0;i<com; i++)
{
dest[DP] = src[SP];
DP++; SP++;
}

}else
{
if(com < 0 ) //Command 2 < fill 2
{
count = -com; // invert the count to make it a positive number.

}else // Other wise, Command 1 Fill 1
{
// This fixes beholde1.cps for the amiga EOB1
if( swapWord == true)
count = (src[SP+1] * 256 )+ src[SP];
else
count = (src[SP] * 256 )+ src[SP+1];

SP +=2;

}

col = src[SP]; // Grab the colour to fill with.
SP++;

for(i=0;i<count; i++)
{
dest[DP] = col;
DP++;
}
}

}
return DP; // This should be 64000.
}

[[Category:File Formats]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Lands Of Lore]]
[[Category:Eye of the Beholder]]

Westwood LZW-14

2014-11-20T20:07:33Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

Westwood compression method two

----

As with compression method one this method has been seen in the game BattleTech: The Crescent Hawk's Revenge. But also in the demo version of Eye of the Beholder, the first game in the series.

Compressed structure

The limitation of 4095 indexes in method one has been overcome by increasing the bit length of the groups in method two. Other than that the compression is almost identical.
The groups are thus 14 bits in length throughout the compressed data stream. The last group is set to 0x3fff and is used as the end marker. Finally the stream ends with 8 bits set to zero for files with even length.

Byte group
000000 cccccccc - When the first six bits are set to zero the following eight
bits represents a byte to store in the decompressed data stream.

Index group
xxxxxx yyyyyyyy - When the first six bits are not set to zero the whole group
represents an index value which points to a previous group in
the compressed data stream.
To get the correct index value you first need to decrease the
first six bits by one.

Other than that the decompression should work the same as with [[Westwood Compression Method One]].

/ Linus Kalliope

[[Category:File Formats]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Lands Of Lore]]
[[Category:Eye of the Beholder]]

Westwood LZW-12

2014-11-20T20:03:37Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

Westwood compression method one

----

This compression method was used by Westwood in PC games such as BattleTech: The Crescent Hawk's Revenge and the first game in the Eye of the Beholder series.

Compressed structure
The compressed data stream is made up of groups which are 12 bits long each. The last group is set to 0xfff and should only be treated as an end marker. Finally the stream ends with 8 bits set to zero for files with even length or 12 bits for files with uneven length.
The contents of the groups have two functions.

Byte group
0000 cccc cccc - When the first four bits are set to zero the following eight
bits represents a byte to store in the decompressed data stream.

Index group
xxxx yyyy yyyy - When the first four bits are not set to zero the whole group
represents an index value which points to a previous group in
the compressed data stream.
To get the correct index value you first need to decrease the
first four bits by one.

Decompression explained
When processing a byte group its byte value is simply stored as is into the decompressed data stream.
Index groups on the other hand will always store at least two bytes. First the byte value retrieved from where the index pointed to. Secondly the byte value from the group next to where we got the first byte value.
Since index groups may point to other index groups we have to travel through the index tree until we end up at a byte group to know which byte we can store. Thus for each extra jump in the index tree we will store one byte value next to each traveled index group.

Decompression illustrated
To better explain how this works, here is the first part of one of the files from the PC version of the first game in the Eye of the Beholder series.

BlUE.EGA
»
7a 36 01 00 00 fa 00 00 00 00 00 01 00 10 00 08
00 60 08 10 51 01 10 7. .. .. .. .. .. .. .. ..

And here is the compressed data formed in 12 bit groups.

Index Group Description Decompressed data
0 000 Byte group
* Store byte value 0 0
1 100 Index group
* Jump to group index 0
* Store byte value 0 0
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
2 100 Index group
* Jump to group index 0
* Store byte value 0 0
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
3 008 Byte group
* Store byte value 8 8
4 006 Byte group
* Store byte value 6 6
5 008 Byte group
* Store byte value 8 8
6 105 Index group
* Jump to group index 5
* Store byte value 8 8
* Advance to next group
* Jump to group index 5
* Store byte value 8 8
7 101 Index group
* Jump to group index 1
* Jump to group index 0
* Store byte value 0 0
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
* Return to group index 1
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
8 107 Index group
* Jump to group index 7
* Jump to group index 1
* Jump to group index 0
* Store byte value 0 0
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
* Return to group index 1
* Advance to next group
* Jump to group index 0
* Store byte value 0 0
* Return to group index 7
* Advance to next group
* Jump to group index 7
* Jump to group index 1
* Jump to group index 0
* Store byte value 0 0

Decompression sample code
Here is a working sample code which was the result of the compressed data pattern analysis.

private byte[] Decompress1(Content c)
{
Header h = GetHeader(c.data);
byte[] data = new byte[h.originalSize];
int a = 10 + h.paletteSize, b = 0;
bool low = false;
byte[] tribbles = new byte[(c.data.Length - (a + 1)) * 2 / 3 * 2];
if (c.data[c.data.Length - 1] != 0x00) return null;
while (true)
{
if (a >= c.data.Length - 1) return null;
byte[] nibbles = new byte[3];
for (int n = 0; n != 3; n++)
{
if (low == false)
{
nibbles[n] = (byte)(c.data[a] >> 4);
low = true;
}
else
{
nibbles[n] = (byte)(c.data[a] & 0x0f);
low = false;
a++;
}
}
if (b + 1 >= tribbles.Length) return null;
tribbles[b] = nibbles[0];
tribbles[b + 1] = (byte)((nibbles[1] << 4) | nibbles[2]);
if (tribbles[b] == 0x0f && tribbles[b + 1] == 0xff) break;
b += 2;
}
if (a + 1 != c.data.Length && a + 2 != c.data.Length && b + 2 != tribbles.Length) return null;
for (a = 0, b = 0; a != tribbles.Length - 2; a += 2)
{
int offset = a;
int count = 0;
while (tribbles[offset] != 0x00)
{
offset = (((tribbles[offset] - 1) << 8) | tribbles[offset + 1]) * 2;
if (offset >= a) return null;
count++;
}
if (b == data.Length) return null;
data[b] = tribbles[offset + 1];
b++;
if (count == 0) continue;
while (count != 0)
{
offset += 2;
int o = offset;
while (tribbles[offset] != 0x00)
{
offset = (((tribbles[offset] - 1) << 8) | tribbles[offset + 1]) * 2;
if (offset >= o) return null;
}
if (b == data.Length) return null;
data[b] = tribbles[offset + 1];
b++;
count--;
offset = a;
int counter = 0;
while (counter != count)
{
offset = (((tribbles[offset] - 1) << 8) | tribbles[offset + 1]) * 2;
if (offset >= a) return null;
counter++;
}
}
}
return data;
}

/ Linus Kalliope
[[Category:File Formats]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Eye of the Beholder]]

Westwood LCW

2014-11-20T19:40:14Z

The coder: Trying to save pages from now defunct Eye of the Beholder Wiki (eob.wikispaces.com)

----------
Format80
----------

Basically, it's part of RLE family.

There are several different commands, with different sizes : form 1 to 5
bytes.
The positions mentioned below always refer to the destination buffer (i.e.
the uncompressed image). The relative positions are relative to the current
position in the destination buffer, which is one byte beyond the last written
byte.
I will give some sample code at the end.

(1) 1 byte
+---+---+---+---+---+---+---+---+
| 1 | 0 | | | | | | |
+---+---+---+---+---+---+---+---+
\_______________________/
|
Count

This one means : copy next Count bytes as is from Source to Dest.

(2) 2 bytes
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
\___________/\__________________________________________________/
| |
Count-3 Relative Pos.

This means copy Count bytes from Dest at Current Pos.-Rel. Pos. to
Current position.
Note that you have to add 3 to the number you find in the bits 4-6 of the
first byte to obtain the Count.
Note that if the Rel. Pos. is 1, that means repeat Count times the previous
byte.

(3) 3 bytes
+---+---+---+---+---+---+---+---+ +---------------+---------------+
| 1 | 1 | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---------------+---------------+
\_______________________/ Pos
|
Count-3

Copy Count bytes from Pos, where Pos is absolute from the start of the
destination buffer. (Pos is a word, that means that the images can't be
larger than 64K)

(4) 4 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
Count Color

Write Color Count times.
(Count is a word, color is a byte)

(5) 5 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
Count Pos

Copy Count bytes from Dest. starting at Pos. Pos is absolute from the start
of the Destination buffer.
Both Count and Pos are words.

These are all the commands I found out. Maybe there are other ones, but I
haven't seen them yet.
All the images end with a 80h command.

To make things more clearer here's a piece of code that will uncompress the
image.
DP = destination pointer
SP = source pointer
Source and Dest are the two buffers

SP:=0;
DP:=0;
repeat
Com:=Source[SP];
inc(SP);
b7:=Com shr 7; {b7 is bit 7 of Com}
case b7 of
0 : begin {copy command (2)}
{Count is bits 4-6 + 3}
Count:=(Com and $7F) shr 4 + 3;
{Position is bits 0-3, with bits 0-7 of next byte}
Posit:=(Com and $0F) shl 8+Source[SP];
Inc(SP);
{Starting pos=Cur pos. - calculated value}
Posit:=DP-Posit;
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end;
1 : begin
{Check bit 6 of Com}
b6:=(Com and $40) shr 6;
case b6 of
0 : begin {Copy as is command (1)}
Count:=Com and $3F; {mask 2 topmost bits}
if Count=0 then break; {EOF marker}
for i:=1 to Count do
begin
Dest[DP]:=Source[SP];
Inc(DP);
Inc(SP);
end;
end;
1 : begin {large copy, very large copy and fill commands}
{Count = (bits 0-5 of Com) +3}
{if Com=FEh then fill, if Com=FFh then very large copy}
Count:=Com and $3F;
if Count<$3E then {large copy (3)}
begin
Inc(Count,3);
{Next word = pos. from start of image}
Posit:=Word(Source[SP]);
Inc(SP,2);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end
else if Count=$3F then {very large copy (5)}
begin
{next 2 words are Count and Pos}
Count:=Word(Source[SP]);
Posit:=Word(Source[SP+2]);
Inc(SP,4);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end else
begin {Count=$3E, fill (4)}
{Next word is count, the byte after is color}
Count:=Word(Source[SP]);
Inc(SP,2);
b:=Source[SP];
Inc(SP);
for i:=0 to Count-1 do
begin
Dest[DP]:=b;
inc(DP);
end;
end;
end;
end;
end;
end;
until false;

Note that you won't be able to compile this code, because the typecasting
won't work. (But I'm sure you'll be able to fix it).

(C) Vladan Bato

[[Category:File Formats]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Lands Of Lore]]
[[Category:Eye of the Beholder]]

ModdingWiki:Community portal

2014-10-28T13:42:21Z

The coder: added archived version link for Rewiki (the site is down)

== Discussion ==

* [http://www.classicdosgames.com/forum/viewforum.php?f=25 RGB Classic Games modding forum] (any/all DOS games)
* [http://www.keenmodding.org Keen:Modding] (Commander Keen and others sharing the same engine)
* [http://forum.xentax.com Xentax forum] Reverse engineering discussion, with a focus on archive file formats and more modern games

== Other resources ==

* [http://rewiki.regengedanken.de REWiki] [https://web.archive.org/web/20140910044440/http://rewiki.regengedanken.de/wiki/Main_Page (archived version)] - reverse engineering wiki (similar to this wiki but not restricted to DOS games)
* [http://wiki.xentax.com/ Xentax game wiki] - game archive format documentation, with more of a focus on modern games and also game consoles
* [http://oezmen.eu/gameresources/ Deniz Özmen's game resources] - quite a few unpackers for various games

User talk:TheAlmightyGuru

2014-10-28T13:32:12Z

The coder:

Hi,
please see this viewer http://oezmen.eu/gameresources/files/holmes.zip
[[User:The coder|The coder]] ([[User talk:The coder|talk]]) 12:49, 28 October 2014 (UTC)

Thank you, that saves me some time; now I just have to translate Pascal! :-) --[[User:TheAlmightyGuru|TheAlmightyGuru]] ([[User talk:TheAlmightyGuru|talk]]) 13:18, 28 October 2014 (UTC)

Better then nothing :) [[User:The coder|The coder]] ([[User talk:The coder|talk]]) 13:32, 28 October 2014 (UTC)

User talk:TheAlmightyGuru

2014-10-28T12:49:50Z

The coder: The lost files of the Sherlock Holmes

Hi,
please see this viewer http://oezmen.eu/gameresources/files/holmes.zip
[[User:The coder|The coder]] ([[User talk:The coder|talk]]) 12:49, 28 October 2014 (UTC)

GameMaps Format

2014-08-10T17:56:58Z

The coder: /* Utilities */

{{Map Infobox
| Type = 2D tile-based
| Layers = 3
| Viewport = ''Varies by game''
| Game1 = Bio Menace
| Game2 = Blake Stone
| Game3 = Catacomb 3-D
| Game4 = Catacomb Abyss
| Game5 = Commander Keen
| Game6 = Corridor 7 Alien Invasion
| Game7 = Dangerous Dave 3
| Game8 = Dangerous Dave 4
| Game9 = Noah's Ark 3D
| Game10 = Operation Body Count
| Game11 = Spear of Destiny
| Game12 = Wolfenstein 3D
}}

The GameMaps format is how the levels in a number of [[Id Software]] games is stored. The filenames and compression varies somewhat across different games but all files stored in this format were produced by the program [[TED5]] or a close analogue.

There are three main varieties of the GameMaps format, uncompressed, [[Carmack compression|carmackized]], and [[Huffman Compression|huffman compressed]]. Each variation has its own file naming scheme and pattern of external\internal files.

There are two main components to the format, the game maps proper, which contain the game level data and the map headers, which contain both the locations of the start of level data in the game maps file and the tile info for the game.

== Structure of uncompressed data ==

The uncompressed format is used by several games including [[Bio Menace]] and [[Wolfenstein 3D]]. In this format map data is stored in <tt>MAPTEMP.xxx</tt> and map headers in <tt>MAPTHEAD.xxx</tt> this is the format saved by [[TED5]] when maps are being edited and can be directly accessed and edited by this utility, allowing changes to be made to the game.

Note that filenames differ and that Wolfenstein 3D uses <tt>GAMEMAPS.WLx</tt> and <tt>MAPHEAD.xxx</tt> files to store data. The main indicator of this format being used is that in the unaltered game the map header file is external.

Only the latest Id Software games lacked compression, when file size was no longer an issue.

=== Map headers ===

0 2 Magic word Magic word for [[RLEW compression]]
2 400 Level ptr 100 4-byte pointers to start of level 0-99 data in game maps file
402 ??? Tileinfo Tileinfo data

The map header file is of varying length and contains three main types of data. The first is the magic word or flag used for RLEW compression, it is always $ABCD. The second is 100 level pointers which give the location of the start of level data in the game maps file, relative to the start of that file. A value of 0 indicates no level. The third is the tileinfo data, tile properties for each tile used in level creation. (These are masked and unmasked and either 8x8, 16x16 or 32x32)

Many programs treat the tileinfo as a separate file from the maphead and it is possible to modify a game in this manner. Indeed, some games, such as Wolfenstein 3D do not have any tileinfo data at all in the map header file (Giving a total file length of 402 bytes.) However TED5 works with any tileinfo data in the maphead.

=== Game maps ===

The game maps file consists of the string 'TED5v1.0.' and a number of RLEW compressed chunks of varying length. Each level in GameMaps will have from two to four chunks (usually four), depending on game, with all levels in a given game having the same number of chunks. These are the level header and 1-3 planes (Foreground, background and sprite or info.) The chunks are in no particular order and it is possible to read through the entire file decompressing chunks as they're found.

Chunks are ordered by the map header file, which will point to the level header chunks which in turn contain pointers to the other chunks used by that level. It is possible the string at the start of the file is to avoid the possibility of a level header at the start of the file which would be read as not existing.

All data in game maps file is in the form of words (Or in the case of pointers, dwords.)

=== Level headers ===

The header for each level that is pointed to by MAPHEAD is 42 bytes long and RLEW compressed, though this is difficult to see since the data is so short and nonrepetitive. For the offsets to level planes a value of 0 indicates the plane does not exist.

Plane 1 is background using unmasked tiles, plane 2 is foreground and uses masked tiles. Plane 3 is sprite or info. Levels must contain c background plane and usually an infoplane.

0 4 Offset in GAMEMAPS to beginning of compressed plane 0 data
4 4 Offset in GAMEMAPS to beginning of compressed plane 1 data
8 4 Offset in GAMEMAPS to beginning of compressed plane 2 data
12 2 Length of compressed plane 0 data (in bytes)
14 2 Length of compressed plane 1 data (in bytes)
16 2 Length of compressed plane 2 data (in bytes)
18 2 Width of level (in tiles)
20 2 Height of level (in tiles)
22 16 Internal name for level (used only by editor, not displayed in-game. null-terminated)

== Carmack compression ==

[[Carmack compression]] is the method used to compress later Id Software games, when file size was an issue. It is the most efficient and complex compression method and was created specifically to work with the word structure of the game maps file. The compression is detailed on its [[Carmack compression|own page.]]

Carmackized game maps files are external <tt>GAMEMAPS.xxx</tt> files and the map header is stored internally in the executable. The map header must be extracted and the game maps decompressed before TED5 can access them. TED5 itself can produce carmackized files and external <tt>MAPHEAD.xxx</tt> files. Carmackization does not replace the RLEW compression used in uncompressed data, but compresses this data, that is, the data is doubly compressed.

== Huffman compression ==

Huffman compression was used by earlier versions of TED5 (possibly not TED5 at all.) before carmackization was created. It uses the same method to compress its data as is used by Id Software games to compress their graphics and sounds. Again this compression method works with RLEW compressed data and has its [[Huffman Compression|own page.]]

Huffman compression is easily detected since it works on the bit level and thus disrupts the word structure of the game data. This is easily seen in a hex editor. Compressed data will not contain the string $00 $00 or indeed even $00 very often (In contrast even carmackized data contains both strings hundreds of times.)

There will be two internal files for this format, the map header and the huffman dictionary (which is always the first dictionary in the executable.) The map header format is also slightly different, being 502 bytes long, the extra 100 bytes being the length of the compressed level headers in the game maps data (These can be ignored when decompressing since huffman data can be read until the decompressed level header's fixed size is reached.)

== Location of internal files ==

Game maps are always external, but in the case of compression the map header file is stored internally in the executable. Executables are themselves compressed wither with LZEXE or PKLite. Once decompressed it is a trivial task to find the map header file as it will start with the word $ABCD For level editing purposes only the first 402 (or 502) bytes of the file needs to be extracted, though it is possible to read the maphead file to calculate its length.

The following addresses are in the locations in the [[UNLZEXE|decompressed]] executables for the start of the Map header files. Values are different for different versions.

TODO: Add all known versions of all games.

External files
Biomenace
Blake Stone 2: Planet Strike
Corridor 7 Demo
Noahs Ark 3D
Operation Body Count
Spear of Destiny
Wolfenstein 3D

Internal files:
Catacomb 3-D (1.00): $1C570 from start of file CAT3D.EXE (after file is UNLZEXE)
Catacomb 4 Abyss (1.13): $1C510 from start of file CATABYSS.EXE (after file is UNLZEXE)
Catacomb 5 Armageddon (1.01a): $1D900 from start of file CATARMA.EXE (after file is UNLZEXE)
Catacomb 6 Apocalypse (1.00b): $1DD50 from start of file CATAPOC.EXE (after file is UNLZEXE)
Corridor 7 CD (): $30D50 from start of file CORR7CD.EXE (file is not compressed)
Corridor 7 Floppy (): $24BF0 from start of file C7.EXE (file is not compressed)
Keen 4 (Special Demo): (file is PKLite compressed)
Keen 4 (1.4): $24830
Keen 5 (1.4): $25990
Keen 6 (1.4): $25080
(Keen D (1.13): $1FA50)

== Utilities ==

[[TED5]] This program can edit the <tt>GAMEMAPS</tt> format of any games that use it. It is the original editor used to create these files.

== Notes ==

This format was reverse engineered by Andrew Durdin (adurdin).