2018-07-12 07:33:33 +00:00
|
|
|
.TH OPL3 1
|
|
|
|
|
.SH NAME
|
|
|
|
|
opl3 \- OPL3 chip emulator
|
|
|
|
|
.SH SYNOPSIS
|
|
|
|
|
.B opl3
|
|
|
|
|
[
|
2021-04-27 07:48:14 +00:00
|
|
|
.B -r
|
2018-07-12 07:33:33 +00:00
|
|
|
.I rate
|
|
|
|
|
] [
|
|
|
|
|
.I file
|
|
|
|
|
]
|
|
|
|
|
.SH DESCRIPTION
|
|
|
|
|
.I Opl3
|
|
|
|
|
is an emulator of a single Yamaha 262 chip, also known as
|
|
|
|
|
.SM OPL3.
|
|
|
|
|
.PP
|
|
|
|
|
The emulated chip is programmed by a stream of commands either from
|
|
|
|
|
.I file
|
|
|
|
|
or from standard in.
|
games/opl3: use correct sampling rate
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
2021-05-05 14:57:19 +00:00
|
|
|
It then synthesizes stereo 16-bit little-endian PCM samples
|
|
|
|
|
at the chip's sampling rate, 49.716 kHz,
|
|
|
|
|
resamples them to
|
|
|
|
|
.IR audio (3)'s
|
|
|
|
|
default 44.1 kHz rate,
|
2018-07-12 07:33:33 +00:00
|
|
|
and writes them to standard out.
|
|
|
|
|
.PP
|
|
|
|
|
Commands are 5 bytes wide, in little-endian byte order:
|
|
|
|
|
.PP
|
|
|
|
|
.RS
|
|
|
|
|
.IR register [2]
|
|
|
|
|
.IR value [1]
|
|
|
|
|
.IR delay [2]
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
Each command specifies a
|
|
|
|
|
.I value
|
|
|
|
|
to be written to an
|
|
|
|
|
.SM OPL3
|
|
|
|
|
chip
|
|
|
|
|
.IR register ,
|
|
|
|
|
modifying its internal state.
|
|
|
|
|
.PP
|
|
|
|
|
The
|
|
|
|
|
.I delay
|
|
|
|
|
field provides timing.
|
|
|
|
|
It is a multiple of a command period, during which the
|
|
|
|
|
.SM OPL3
|
|
|
|
|
chip may be sampled before processing the next command.
|
games/opl3: use correct sampling rate
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
2021-05-05 14:57:19 +00:00
|
|
|
The period itself is the inverse of the input stream's sampling rate,
|
|
|
|
|
by default the same as the chip's output sampling rate.
|
|
|
|
|
The
|
2021-04-27 07:48:14 +00:00
|
|
|
.B -r
|
games/opl3: use correct sampling rate
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
2021-05-05 14:57:19 +00:00
|
|
|
parameter
|
|
|
|
|
sets the input sampling rate.
|
2018-07-12 07:33:33 +00:00
|
|
|
.SH SOURCE
|
|
|
|
|
.B /sys/src/games/opl3
|
|
|
|
|
.SH "SEE ALSO"
|
|
|
|
|
.IR audio (3)
|
games/opl3: use correct sampling rate
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
2021-05-05 14:57:19 +00:00
|
|
|
.PP
|
|
|
|
|
Yamaha
|
|
|
|
|
``YMF262 Manual'',
|
|
|
|
|
1994.
|
|
|
|
|
.PP
|
|
|
|
|
V. Arnost
|
|
|
|
|
``Programmer's Guide to Yamaha YMF 262/OPL3 FM Music Synthesizer'',
|
|
|
|
|
version 1.12 dated Nov. 23rd 2000.
|
2018-07-12 07:33:33 +00:00
|
|
|
.SH HISTORY
|
|
|
|
|
.I Opl3
|
|
|
|
|
first appeared in 9front (July, 2018), based on
|
|
|
|
|
.I ymf262.c
|
|
|
|
|
from the Multiple Arcade Machine Emulator (
|
|
|
|
|
.SM MAME
|
|
|
|
|
).
|