mirror of
https://github.com/holub/mame
synced 2025-04-20 23:42:22 +03:00
Tidy whitespace in plain text files
This commit is contained in:
Zoë Blade
parent
a2ac952299
commit
4cc89fb552
17
docs/SDL.txt
17
docs/SDL.txt
@ -13,7 +13,7 @@ Debugging options
|
||||
|
||||
-[no]oslog
|
||||
|
||||
Outputs the error.log data to the stderr TTY channel (usually the
|
||||
Outputs the error.log data to the stderr TTY channel (usually the
|
||||
command line window MAME was started in). This can be used at
|
||||
the same time as -log to output the log data to both targets as well.
|
||||
Default is OFF (-nooslog).
|
||||
@ -34,20 +34,19 @@ Performance options
|
||||
|
||||
-[no]multithreading / -[no]mt
|
||||
|
||||
Enables multithreading for the final drawing operation. This can help
|
||||
Enables multithreading for the final drawing operation. This can help
|
||||
performance on multicore/hyperthreaded systems with slow video cards,
|
||||
but may cause undesired behavior in some games.
|
||||
Note that some drivers in MAME and MESS will use multiple threads even
|
||||
when this is set to OFF, assuming -numprocessors allows it.
|
||||
The default is OFF (-nomultithreading).
|
||||
|
||||
|
||||
-numprocessors <auto|value> / -np <auto|value>
|
||||
|
||||
Specify the number of processors to use for work queues. Specifying
|
||||
"auto" will use the value reported by the system or environment
|
||||
"auto" will use the value reported by the system or environment
|
||||
variable OSDPROCESSORS. To avoid abuse, this value is internally limited
|
||||
to 4 times the number of processors reported by the system.
|
||||
to 4 times the number of processors reported by the system.
|
||||
The default is "auto".
|
||||
|
||||
-sdlvideofps
|
||||
@ -68,8 +67,8 @@ Video options
|
||||
|
||||
-video <soft|opengl|none>
|
||||
|
||||
Specifies which video subsystem to use for drawing. The default for
|
||||
Mac OS X is 'opengl' because OS X is guaranteed to have a compliant
|
||||
Specifies which video subsystem to use for drawing. The default for
|
||||
Mac OS X is 'opengl' because OS X is guaranteed to have a compliant
|
||||
OpenGL stack. The default on all other systems is 'soft'.
|
||||
|
||||
-numscreens <count>
|
||||
@ -188,7 +187,7 @@ Video OpenGL-specific options
|
||||
-[no]gl_pbo Enable OpenGL PBO, if available (default on)
|
||||
|
||||
These 4 options are for compatibility in -video opengl. If you report
|
||||
rendering artifacts you may be asked to try messing with them by the
|
||||
rendering artifacts you may be asked to try messing with them by the
|
||||
devs, but normally they should be left at their defaults which results
|
||||
in the best possible video performance.
|
||||
|
||||
@ -363,7 +362,7 @@ SDL Joystick Mapping
|
||||
-joy_idx6 Name of joystick mapped to joystick #6, default is auto.
|
||||
-joy_idx7 Name of joystick mapped to joystick #7, default is auto.
|
||||
-joy_idx8 Name of joystick mapped to joystick #8, default is auto.
|
||||
-sixaxis Use special handling for PS3 Sixaxis controllers.
|
||||
-sixaxis Use special handling for PS3 Sixaxis controllers.
|
||||
Default is OFF (-nosixaxis)
|
||||
|
||||
|
||||
|
||||
@ -294,21 +294,21 @@ of your command:
|
||||
Displays a list of all devices known to be hooked up to a game. The ":"
|
||||
is considered the game itself with the devices list being attached to give
|
||||
the user a better understanding of what the emulation is using.
|
||||
|
||||
|
||||
-listslots [<gamename|wildcard>]
|
||||
|
||||
Show available slots and options for each slot (if available). Primarily
|
||||
used for MESS to allow control over internal plug-in cards, much like PC's
|
||||
needing video, sound and other cards.
|
||||
|
||||
|
||||
-listmedia / -lm [<gamename|wildcard>]
|
||||
|
||||
|
||||
List available media that the chosen game or system allows to be used. This
|
||||
includes media types (cartridge, cassette, diskette and more) as well as
|
||||
common file extentions which are supported.
|
||||
|
||||
-listsoftware [<gamename|wildcard>]
|
||||
|
||||
|
||||
Posts to screen all software lists which can be used by the entered gamename
|
||||
or system. Notice, this is simply a copy/paste of the .XML file which reside
|
||||
in the HASH folder which are allowed to be used.
|
||||
@ -331,12 +331,12 @@ of your command:
|
||||
softwarelistname. By default, all drivers that have valid ZIP files or directories
|
||||
in the rompath are verified; however, you can limit this list by specifying a
|
||||
specific softwarelistname (without .XML) after the -verifysoftlist command.
|
||||
|
||||
|
||||
-listmidi
|
||||
|
||||
Create a list of list available MIDI I/O devices for use with emulation.
|
||||
|
||||
|
||||
|
||||
|
||||
Configuration options
|
||||
---------------------
|
||||
@ -570,14 +570,14 @@ Core state/playback options
|
||||
find the next empty value for %i and use that for a filename. The
|
||||
default is %g/%i, which creates a separate folder for each game,
|
||||
and names the snapshots under it starting with 0000 and increasing
|
||||
from there. In addition to the above, for drivers using different
|
||||
media, like carts or floppy disks, you can also use the %d_[media]
|
||||
from there. In addition to the above, for drivers using different
|
||||
media, like carts or floppy disks, you can also use the %d_[media]
|
||||
indicator. Replace [media] with the media switch you want to use.
|
||||
A few examples: if you use 'mame robby -snapname foo/%g%i' snapshots
|
||||
A few examples: if you use 'mame robby -snapname foo/%g%i' snapshots
|
||||
will be saved as 'snaps\foo\robby0000.png' , 'snaps\foo\robby0001.png'
|
||||
and so on ; if you use 'mess nes -cart robby -snapname %g/%d_cart'
|
||||
snapshots will be saved as 'snaps\nes\robby.png' ; if you use
|
||||
'mess c64 -flop1 robby -snapname %g/%d_flop1/%i' snapshots will be
|
||||
and so on ; if you use 'mess nes -cart robby -snapname %g/%d_cart'
|
||||
snapshots will be saved as 'snaps\nes\robby.png' ; if you use
|
||||
'mess c64 -flop1 robby -snapname %g/%d_flop1/%i' snapshots will be
|
||||
saved as 'snaps\c64\robby\0000.png'.
|
||||
|
||||
-snapsize <width>x<height>
|
||||
@ -607,30 +607,30 @@ Core state/playback options
|
||||
-statename <name>
|
||||
|
||||
Describes how MAME should store save state files, relative to the
|
||||
state_directory path. <name> is a string that provides a template that
|
||||
is used to generate a relative path. Two simple substitutions are
|
||||
provided: the / character represents the path separator on any target
|
||||
platform (even Windows); the string %g represents the driver name of
|
||||
the current game. The default is %g, which creates a separate folder for
|
||||
each game. In addition to the above, for drivers using different
|
||||
media, like carts or floppy disks, you can also use the %d_[media]
|
||||
state_directory path. <name> is a string that provides a template that
|
||||
is used to generate a relative path. Two simple substitutions are
|
||||
provided: the / character represents the path separator on any target
|
||||
platform (even Windows); the string %g represents the driver name of
|
||||
the current game. The default is %g, which creates a separate folder for
|
||||
each game. In addition to the above, for drivers using different
|
||||
media, like carts or floppy disks, you can also use the %d_[media]
|
||||
indicator. Replace [media] with the media switch you want to use.
|
||||
A few examples: if you use 'mame robby -statename foo/%g' save states
|
||||
will be stored inside 'sta\foo\robby\' ; if you use 'mess nes -cart
|
||||
robby -statename %g/%d_cart' save states will be stored inside
|
||||
'sta\nes\robby\' ; if you use 'mess c64 -flop1 robby -statename
|
||||
A few examples: if you use 'mame robby -statename foo/%g' save states
|
||||
will be stored inside 'sta\foo\robby\' ; if you use 'mess nes -cart
|
||||
robby -statename %g/%d_cart' save states will be stored inside
|
||||
'sta\nes\robby\' ; if you use 'mess c64 -flop1 robby -statename
|
||||
%g/%d_flop1' save states will be stored inside 'sta\c64\robby\'.
|
||||
|
||||
-[no]burnin
|
||||
|
||||
Tracks brightness of the screen during play and at the end of
|
||||
Tracks brightness of the screen during play and at the end of
|
||||
emulation generates a PNG that can be used to simulate burn-in
|
||||
effects on other games. The resulting PNG is created such that the
|
||||
least used-areas of the screen are fully white (since burned-in areas
|
||||
least used-areas of the screen are fully white (since burned-in areas
|
||||
are darker, all other areas of the screen must be lightened a touch).
|
||||
The intention is that this PNG can be loaded via an artwork file with
|
||||
a low alpha (e.g, 0.1-0.2 seems to work well) and blended over the
|
||||
entire screen. The PNG files are saved in the snap directory under
|
||||
entire screen. The PNG files are saved in the snap directory under
|
||||
the gamename/burnin-<screen.name>.png. The default is OFF (-noburnin).
|
||||
|
||||
|
||||
@ -1122,7 +1122,7 @@ Debugging options
|
||||
|
||||
A special 'internal' debugger for debugging. Activated when used along
|
||||
with -debug. The default if OFF (-nodebug_internal).
|
||||
|
||||
|
||||
|
||||
|
||||
Core misc options
|
||||
@ -1149,7 +1149,7 @@ Core misc options
|
||||
Specifies the name of a font file to use for the UI font. If this font
|
||||
cannot be found or cannot be loaded, the system will fall back to its
|
||||
built-in UI font. On some platforms 'fontname' can be a system font
|
||||
name (TTF) instead of a (BDF) font file. The default is 'default' (use
|
||||
name (TTF) instead of a (BDF) font file. The default is 'default' (use
|
||||
the OSD-determined default font).
|
||||
|
||||
-ramsize [n]
|
||||
|
||||
@ -369,7 +369,7 @@ The track is finished with a stream of MFM-encoded 0x4e.
|
||||
|
||||
The 250KHz pulse trains are used to lock the PLL to the signal
|
||||
correctly. The cell pattern 4489 does not appear in normal
|
||||
MFM-encoded data and is used for clock/data separation.
|
||||
MFM-encoded data and is used for clock/data separation.
|
||||
|
||||
As for FM, the Western Digital-based controllers usually get rid of
|
||||
everything but some 0x4e before the first sector and allow a better
|
||||
@ -392,7 +392,7 @@ Similarly two write splices are created when a sector is written at
|
||||
the start and end of the data block part. They're not supposed to
|
||||
happen on a mastered disk though, even if there are some rare
|
||||
exceptions.
|
||||
|
||||
|
||||
|
||||
3 The new implementation
|
||||
3.1 Floppy disk representation
|
||||
|
||||
@ -42,7 +42,7 @@ converge_y [r,g,b] Convergence in screen-relative Y directi
|
||||
radial_converge_x [r,g,b] Radial convergence in screen-relative X direction.
|
||||
radial_converge_y [r,g,b] Radial convergence in screen-relative Y direction.
|
||||
Allowed values for convergence: -150 to 150 for each color.
|
||||
red_ratio [r,g,b] These parameters define a 3x3 matrix which is multiplied
|
||||
red_ratio [r,g,b] These parameters define a 3x3 matrix which is multiplied
|
||||
grn_ratio [r,g,b] by the incoming RGB signal. This can be used for any
|
||||
blu_ratio [r,g,b] standard matrix convolution, including H/S/V or simply
|
||||
affecting the TV-style tint.
|
||||
@ -109,4 +109,4 @@ bloom_lvl6_weight 0.13 Bloom level 6 (.) weight. (0.00-1.00)
|
||||
bloom_lvl7_weight 0.12 Bloom level 7 (.) weight. (0.00-1.00)
|
||||
bloom_lvl8_weight 0.11 Bloom level 8 (.) weight. (0.00-1.00)
|
||||
bloom_lvl9_weight 0.10 Bloom level 9 (.) weight. (0.00-1.00)
|
||||
bloom_lvl10_weight 0.09 Bloom level 10 (1x1 target) weight. (0.00-1.00)
|
||||
bloom_lvl10_weight 0.09 Bloom level 10 (1x1 target) weight. (0.00-1.00)
|
||||
|
||||
@ -81,7 +81,7 @@ only for early revisions of lynx archivs
|
||||
only extraction supported
|
||||
not heavily tested
|
||||
|
||||
Lynx archivs could and should be handled in a c64 emulation
|
||||
Lynx archivs could and should be handled in a c64 emulation
|
||||
with the native lynx tool
|
||||
|
||||
|
||||
@ -128,7 +128,7 @@ special disk controller necessary for enhanced density
|
||||
type 7: 3 1/2 inch, enhanced density, DS, 2.88mb: sectors 36, heads 2, tracks 80
|
||||
|
||||
unix with bash: use
|
||||
dd if=/dev/zero of=<name.dsk> bs=512 count=$((9*2*40))
|
||||
dd if=/dev/zero of=<name.dsk> bs=512 count=$((9*2*40))
|
||||
to generate standard blank 360kb image
|
||||
|
||||
|
||||
@ -145,14 +145,14 @@ standard parameter for common disk formats:
|
||||
type 0: 20mb standard pc/xt harddisk: 17 sectors, 4 heads, 615 cylinders
|
||||
|
||||
unix with bash: use
|
||||
dd if=/dev/zero of=<name.dsk> bs=512 count=$((17*4*615))
|
||||
dd if=/dev/zero of=<name.dsk> bs=512 count=$((17*4*615))
|
||||
to generate standard blank 20mb pc xt harddisk image
|
||||
|
||||
|
||||
Virtual MSX tape archive
|
||||
------------------------
|
||||
Converts .tap files from Virtual MSX 1.x to .cas files. It is not
|
||||
fault-tolerant.
|
||||
fault-tolerant.
|
||||
|
||||
|
||||
Virtual MSX Game Master 2 SRAM file
|
||||
@ -161,7 +161,7 @@ Very simple, not overly useful but some might want it. Virtual MSX stored the
|
||||
SRAM of Konami's Game Master 2 in "gmaster2.ram". To convert this to something
|
||||
useful with MESS and other MSX emulators, go:
|
||||
|
||||
imgtool getall vmsx_gm2 gmaster2.ram
|
||||
imgtool getall vmsx_gm2 gmaster2.ram
|
||||
|
||||
You'll get a file called gmaster2.mem, which must place in the correct directory
|
||||
of mess to use (MESS\MEMCARD\GameMaster2 if your Game Master 2 .rom file is
|
||||
@ -174,7 +174,7 @@ Converts .cas files to .wav files. The MSX driver can use .cas files directly
|
||||
so you don't have to convert them. You can use it to export files to a real
|
||||
MSX. Connect the MSX to the line out of your computer. Give the apropriate
|
||||
command on the MSX (BLOAD "CAS:",R for example) and then play the .wav file
|
||||
on your computer.
|
||||
on your computer.
|
||||
|
||||
imgtool dir fmsx_cas file.cas
|
||||
imgtool getall fmsx_cas file.cas
|
||||
@ -185,7 +185,7 @@ XelaSoft Archive (.xsa)
|
||||
-----------------------
|
||||
|
||||
The XelaSoft Archive is a compressed file. It can only contain one
|
||||
file. Although it can contain any file, it's always used for MSX disk
|
||||
file. Although it can contain any file, it's always used for MSX disk
|
||||
images. The were programs written by XelaSoft which made a dump
|
||||
of a disk, and compressing them at the same time. Very useful to store
|
||||
a disk dump on another disk. zip/gzip offer much better compression and
|
||||
@ -205,7 +205,7 @@ emulators, is .dsk (a plain dump without any header information). This
|
||||
filetype converts them all to .dsk format.
|
||||
|
||||
msx_img are disk images with an extra byte at the beginning. It' 1 (0x01)
|
||||
for single-sided images and 2 (0x02) for double-side images. These
|
||||
for single-sided images and 2 (0x02) for double-side images. These
|
||||
files are at: ftp://ftp.funet.fi/pub/msx/. The extension is .img
|
||||
|
||||
msx_ddi are DiskDupe 5.12 disk images. There is a 0x1800 bytes header
|
||||
@ -215,9 +215,9 @@ often contain garbage so it's simply stripped. The extension is .ddi
|
||||
msx_msx are disk images with a weird sector order. You can find them
|
||||
at: ftp://jazz.snu.ac.kr/pub/msx/. The extension is .msx
|
||||
|
||||
msx_mul are "multi disk" images, used by fmsx-dos 1.6. It is simply
|
||||
msx_mul are "multi disk" images, used by fmsx-dos 1.6. It is simply
|
||||
more than one .dsk image appended to one another. The extension is
|
||||
still .dsk, but the file is larger than 720kB (actually always a
|
||||
still .dsk, but the file is larger than 720kB (actually always a
|
||||
multiple of 720kB.
|
||||
|
||||
|
||||
@ -235,7 +235,7 @@ The card filesystem is similar to FAT, but not identical.
|
||||
The maximum card size is 1mb, and maximum file size is 64k.
|
||||
(Files will be cut at 64k if they are larger - e.g. when putting a large file)
|
||||
|
||||
As far as I know there is no directory system, however there is always a
|
||||
As far as I know there is no directory system, however there is always a
|
||||
system "NC100" directory which points to the root directory. (Like the DOS "."
|
||||
directory).
|
||||
|
||||
|
||||
@ -34,11 +34,11 @@ tree. The final class hierarchy is this:
|
||||
|
|
||||
+------+--------+--+--+-------+-------+
|
||||
| | | | | |
|
||||
6510 deco16 6504 6509 n2a03 65c02
|
||||
6510 deco16 6504 6509 n2a03 65c02
|
||||
| |
|
||||
+-----+-----+ r65c02
|
||||
| | | |
|
||||
6510t 7501 8502 +---+---+
|
||||
6510t 7501 8502 +---+---+
|
||||
| |
|
||||
65ce02 65sc02
|
||||
|
|
||||
|
||||
@ -30,12 +30,12 @@ Windows debugging options
|
||||
|
||||
Specifies the name of the font to use for debugger windows. By default,
|
||||
the font is Lucida Console.
|
||||
|
||||
|
||||
-debugger_font_size <points> / -dfontsize <points>
|
||||
|
||||
Specifies the size of the font to use for debugger windows, in points.
|
||||
By default, this is set to 9pt.
|
||||
|
||||
|
||||
|
||||
|
||||
Windows performance options
|
||||
@ -54,13 +54,13 @@ Windows performance options
|
||||
window and all DirectDraw/Direct3D code to execute on a second thread,
|
||||
which can improve performance on hyperthreaded and multicore systems.
|
||||
The default is OFF (-nomultithreading).
|
||||
|
||||
|
||||
-numprocessors <auto|value> / -np <auto|value>
|
||||
|
||||
Specify the number of processors to use for work queues. Specifying
|
||||
"auto" will use the value reported by the system or environment
|
||||
"auto" will use the value reported by the system or environment
|
||||
variable OSDPROCESSORS. To avoid abuse, this value is internally limited
|
||||
to 4 times the number of processors reported by the system.
|
||||
to 4 times the number of processors reported by the system.
|
||||
The default is "auto".
|
||||
|
||||
-profile [n]
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
intel 8086 and compatibles
|
||||
--------------------------
|
||||
|
||||
this info is here,
|
||||
this info is here,
|
||||
to list and give some remarks on all 8086 compatible processors
|
||||
|
||||
excellent info in Hamarsoft's 86BUGS list
|
||||
@ -12,13 +12,13 @@ excellent info in Hamarsoft's 86BUGS list
|
||||
20 bit address bus, 16 bit data bus and registers
|
||||
many 8080 assembler sources should be compilable/reusable
|
||||
|
||||
8086
|
||||
8086
|
||||
----
|
||||
6 bytes prefetch queue
|
||||
|
||||
8088
|
||||
----
|
||||
8086 with 8 bit data bus,
|
||||
8086 with 8 bit data bus,
|
||||
prefetch queue only 4 byte, and refilled when 1 byte empty
|
||||
|
||||
early 8086/8088 revisions bug
|
||||
@ -93,7 +93,7 @@ v30? emulation mode (without 8080 emulation mode)
|
||||
80286
|
||||
-----
|
||||
80186 with additional instructions
|
||||
24 bit address bus,
|
||||
24 bit address bus,
|
||||
protected mode
|
||||
|
||||
80386 and later
|
||||
@ -106,6 +106,6 @@ mathematical coprocessors
|
||||
|
||||
weitek, iit variants
|
||||
|
||||
in 80486 coprocessor integrated
|
||||
in 80486 coprocessor integrated
|
||||
(except 80486sx and several clones)
|
||||
80487: 80486 with other pinout
|
||||
|
||||
@ -4,12 +4,12 @@
|
||||
31 Jan 97
|
||||
|
||||
The PokeySound Chip Emulator is designed to emulate the functionality of the
|
||||
Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to
|
||||
produce sounds which are essentially identical to the original POKEY chip,
|
||||
including the exact distortions and pitches.
|
||||
Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to
|
||||
produce sounds which are essentially identical to the original POKEY chip,
|
||||
including the exact distortions and pitches.
|
||||
|
||||
The emulator is designed to run in a 32-bit environment. Though it can be
|
||||
compiled and run in a 16-bit environment, it is slow.
|
||||
compiled and run in a 16-bit environment, it is slow.
|
||||
|
||||
I would like to give special thanks to Neil Bradley. He provided excellent
|
||||
testing support and was also the driving force behind the multiple POKEY
|
||||
@ -26,9 +26,9 @@ Version 2.0 of the 'PokeySound' adds the following features:
|
||||
2) An adjustable gain. The previous releases had a built-in gain of 64.
|
||||
|
||||
3) A clipping option. Depending on the number of chips emulated and the
|
||||
configured gain, it is possible for the output to exceed 8-bits.
|
||||
configured gain, it is possible for the output to exceed 8-bits.
|
||||
Clipping can be enabled to prevent this, though it does increase the
|
||||
processing time.
|
||||
processing time.
|
||||
|
||||
|
||||
Standard Features:
|
||||
@ -36,12 +36,12 @@ Standard Features:
|
||||
|
||||
The 'PokeySound' emulator supports the following functions:
|
||||
|
||||
1) All polynomial sound generators:
|
||||
1) All polynomial sound generators:
|
||||
a) 4-bit poly - actual bit pattern determined from sampled sound
|
||||
b) 5-bit poly - actual bit pattern determined from sampled sound
|
||||
c) 17-bit poly - simulated random bit pattern
|
||||
d) 9-bit poly - derived from simulated 17-bit poly
|
||||
|
||||
|
||||
2) Full support of all 'Divide by N' counter clocks:
|
||||
a) 1.79 MHz (high limited to playback sample rate)
|
||||
b) 64 KHz (high limited to playback sample rate)
|
||||
@ -51,7 +51,7 @@ The 'PokeySound' emulator supports the following functions:
|
||||
a) 8-bit - single channel
|
||||
b) 16-bit - double channel
|
||||
|
||||
4) Full support of all distortions
|
||||
4) Full support of all distortions
|
||||
a) 5-bit poly, then 17-bit poly
|
||||
b) 5-bit poly only
|
||||
c) 5-bit poly, then 4-bit poly
|
||||
@ -59,7 +59,7 @@ The 'PokeySound' emulator supports the following functions:
|
||||
e) no poly counters (pure tone)
|
||||
f) 5-bit poly only
|
||||
|
||||
5) Full support of volume control
|
||||
5) Full support of volume control
|
||||
|
||||
6) Full support of all pitches - distortions will vary exactly as the
|
||||
original Atari based on different pitches
|
||||
@ -84,39 +84,39 @@ In the 2.0 release, I've removed the non-optimized vrersion. It was only
|
||||
left in for reference. If you would still like to see the non-optimized
|
||||
version, it's available in the 1.2 release.
|
||||
|
||||
One of the unique features of the emulator is that the processing time varies
|
||||
based on the frequency. Since the routine only calculates new output values
|
||||
when a change is sensed, the lower frequencies (which change less frequently)
|
||||
One of the unique features of the emulator is that the processing time varies
|
||||
based on the frequency. Since the routine only calculates new output values
|
||||
when a change is sensed, the lower frequencies (which change less frequently)
|
||||
will require less processing time.
|
||||
|
||||
|
||||
Differences Between the Emulator and the Actual POKEY Chip:
|
||||
-----------------------------------------------------------
|
||||
-----------------------------------------------------------
|
||||
|
||||
The biggest difference between the emulator and the original hardware is
|
||||
that the emulator emulates an 'ideal' POKEY chip. All output from the
|
||||
The biggest difference between the emulator and the original hardware is
|
||||
that the emulator emulates an 'ideal' POKEY chip. All output from the
|
||||
emulator is a based on a precise square wave, whereas the output from the
|
||||
original chip has decay. Though the output is slightly different, I
|
||||
don't believe this difference is easily discernible.
|
||||
|
||||
Another slight difference is the 17-bit/9-bit poly. Since the polynomial
|
||||
is large (2^17 bits), I choose to create the sample using a random number
|
||||
generator rather than a table. I don't believe this difference is
|
||||
generator rather than a table. I don't believe this difference is
|
||||
significant.
|
||||
|
||||
There are also a few differences which are introduced by aliasing. This is
|
||||
a direct result of using an output sampling rate which is not identical to
|
||||
the original sound rate. It is most evident with high frequencies.
|
||||
the original sound rate. It is most evident with high frequencies.
|
||||
|
||||
A final difference is the lack of support for the High-Pass Filter
|
||||
A final difference is the lack of support for the High-Pass Filter
|
||||
functionality. I plan to add this in a future release if necessary.
|
||||
|
||||
|
||||
Sample/Test Application:
|
||||
------------------------
|
||||
|
||||
The test program I've distributed is a 16-bit DOS application created with
|
||||
the Borland 'C' compiler. The only reason I used 16-bit was because I
|
||||
The test program I've distributed is a 16-bit DOS application created with
|
||||
the Borland 'C' compiler. The only reason I used 16-bit was because I
|
||||
already had a set of working SB drivers in 16-bit. Since the test system
|
||||
is dedicated to generating sounds, the performance in 16-bit is more than
|
||||
adequate.
|
||||
@ -125,20 +125,20 @@ adequate.
|
||||
POKEY.C
|
||||
=======
|
||||
|
||||
The POKEY.C file is the heart of the PokeySound Emulation program.
|
||||
The POKEY.C file is the heart of the PokeySound Emulation program.
|
||||
Although the routines in the file must work together, no other files are
|
||||
modules are required for operation. A header file, 'POKEY.H', has
|
||||
been included for use in other modules, and provides the necessary
|
||||
modules are required for operation. A header file, 'POKEY.H', has
|
||||
been included for use in other modules, and provides the necessary
|
||||
function prototypes. I've attempted to make the routines as portable as
|
||||
possible, so the file should compile on almost any compiler with little
|
||||
or no modification.
|
||||
or no modification.
|
||||
|
||||
I have made some attempts at optimizing the routines, though I am sure
|
||||
more optimization can be done. They are currently only available in 'C'.
|
||||
I'll be happy to convert them to assembly language if desired. Please feel
|
||||
I'll be happy to convert them to assembly language if desired. Please feel
|
||||
free to send me e-mail at rfries@tcmail.frco.com.
|
||||
|
||||
The routines are easy to use. Detailed descriptions on the function calls
|
||||
The routines are easy to use. Detailed descriptions on the function calls
|
||||
are listed below.
|
||||
|
||||
The POKEY.C module can be compiled in a 32-bit or 16-bit environment.
|
||||
@ -150,17 +150,17 @@ the variable COMP16.
|
||||
GENERAL OVERVIEW
|
||||
----------------
|
||||
|
||||
On start-up of the system, a single call should be made to Pokey_sound_init.
|
||||
On start-up of the system, a single call should be made to Pokey_sound_init.
|
||||
This routine will prepare the structures for sound output. This routine
|
||||
can be called again if necessary during warm-start or other reset.
|
||||
|
||||
Once in the main loop, there are two other functions that will be used.
|
||||
Once in the main loop, there are two other functions that will be used.
|
||||
Whenever the system needs to write to either the AUDC or AUDF values,
|
||||
a call should be made to the Update_pokey_sound routine. This routine will
|
||||
a call should be made to the Update_pokey_sound routine. This routine will
|
||||
take care of updating the internal registers. It will pre-calculate several
|
||||
values to help with optimization.
|
||||
|
||||
The only other routine that is called is the Pokey_process function. This
|
||||
The only other routine that is called is the Pokey_process function. This
|
||||
function will fill a audio buffer with a specified number of bytes. This
|
||||
function should be called whenever a new audio buffer is required.
|
||||
|
||||
@ -176,44 +176,44 @@ Pokey_sound_init(uint32 freq17, uint16 playback_freq, uint8 num_pokeys)
|
||||
-----------------------------------------------------------------------
|
||||
|
||||
This function initializes the structures used by the PokeySound routines.
|
||||
This function takes three parameters: the main clock frequency, the
|
||||
This function takes three parameters: the main clock frequency, the
|
||||
playback frequency and the number of POKEY chips to emulate.
|
||||
|
||||
The maximum number of POKEY chips emulated is configured at compile time.
|
||||
Though the maximum number of chips can be configured as one, the PokeySound
|
||||
1.2 routines are recommended if only a single chip is to be emulated since
|
||||
they have will provide better performance.
|
||||
Though the maximum number of chips can be configured as one, the PokeySound
|
||||
1.2 routines are recommended if only a single chip is to be emulated since
|
||||
they have will provide better performance.
|
||||
|
||||
The main clock frequency is the frequency of the 1.79MHz source clock.
|
||||
To provide exact results, freq17 should be set equal to 1789790 Hz. As an
|
||||
alternative, freq17 can be set to an approximate frequency of 1787520 Hz.
|
||||
Using this approximate frequency will reduce aliasing and thus produce a
|
||||
The main clock frequency is the frequency of the 1.79MHz source clock.
|
||||
To provide exact results, freq17 should be set equal to 1789790 Hz. As an
|
||||
alternative, freq17 can be set to an approximate frequency of 1787520 Hz.
|
||||
Using this approximate frequency will reduce aliasing and thus produce a
|
||||
clearer output signal.
|
||||
|
||||
A constant has been defined for both of these values for your convenience.
|
||||
The names are FREQ_17_EXACT and FREQ_17_APPROX.
|
||||
|
||||
The playback frequency is the frequency of the sound playback (the frequency
|
||||
used by the sound card). For best results, the playback frequency should
|
||||
The playback frequency is the frequency of the sound playback (the frequency
|
||||
used by the sound card). For best results, the playback frequency should
|
||||
be an even division of the main clock frequency. Since most of the sounds
|
||||
will be generated using the 64kHz clock, I also recommend making the
|
||||
will be generated using the 64kHz clock, I also recommend making the
|
||||
playback frequency an even division of the 64kHz clock.
|
||||
|
||||
The 64kHz clock is exactly equal to the main clock divided by 28. For
|
||||
the playback frequency, I recommend one of the following values:
|
||||
|
||||
1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound
|
||||
1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound
|
||||
cards can't reproduce this frequency.
|
||||
|
||||
2) FREQ_17_APPROX / (28*2), which is equal to 31920. All of the newer cards
|
||||
will support this frequency.
|
||||
will support this frequency.
|
||||
|
||||
3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB
|
||||
3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB
|
||||
compatibles should support this frequency.
|
||||
|
||||
4) FREQ_17_APPROX / (28*4), which is equal to 15960. This may be the
|
||||
best choice, as it offers good sound reproduction with good performance.
|
||||
|
||||
|
||||
Of course, these options also assume you are using the approximate
|
||||
frequency for the main clock as well. Any of these choices will offer the
|
||||
best results when the main 64kHz clock is used, reasonable results when the
|
||||
@ -231,7 +231,7 @@ Update_pokey_sound (uint16 addr, uint8 val, uint8 chip, uint8 gain)
|
||||
|
||||
This function should be called each time an AUDC, AUDF or AUDCTL value
|
||||
changes. This function takes four parameters: the address to change,
|
||||
the new value, the chip to be updated, and the gain to be used.
|
||||
the new value, the chip to be updated, and the gain to be used.
|
||||
The lower four bits of the address should be one of the following values:
|
||||
|
||||
Addr Description
|
||||
@ -250,26 +250,26 @@ In order to support multiple POKEY chips, only the lower four bits of
|
||||
the address are used. Note that this routine can no longer be called with
|
||||
any address as it will affect the operation of the specified chip.
|
||||
|
||||
The routine pre-calculates several values that are needed by the
|
||||
The routine pre-calculates several values that are needed by the
|
||||
processing function. This is done to optimize performance.
|
||||
|
||||
The output will be amplified (multiplied) by gain/16 (previous releases had
|
||||
a built in multiplier of 4, which calculates to a gain value of 64). If the
|
||||
output exceeds the maximum value after then gain and clipping is enabled,
|
||||
The output will be amplified (multiplied) by gain/16 (previous releases had
|
||||
a built in multiplier of 4, which calculates to a gain value of 64). If the
|
||||
output exceeds the maximum value after then gain and clipping is enabled,
|
||||
the output will be limited to reduce distortion.
|
||||
|
||||
The best value for the gain depends on the number of POKEYs emulated and
|
||||
the maximum volume used. The maximum possible output for each channel is 15,
|
||||
making the maximum possible output for a single chip to be 60. Assuming all
|
||||
four channels on the chip are used at full volume, a gain of 64 can be used
|
||||
without distortion. If 4 POKEY chips are emulated and all 16 channels are
|
||||
used at full volume, the gain must be no more than 16 to prevent distortion.
|
||||
Of course, if only a few of the 16 channels are used or not all channels are
|
||||
the maximum volume used. The maximum possible output for each channel is 15,
|
||||
making the maximum possible output for a single chip to be 60. Assuming all
|
||||
four channels on the chip are used at full volume, a gain of 64 can be used
|
||||
without distortion. If 4 POKEY chips are emulated and all 16 channels are
|
||||
used at full volume, the gain must be no more than 16 to prevent distortion.
|
||||
Of course, if only a few of the 16 channels are used or not all channels are
|
||||
used at full volume, a larger gain can be used.
|
||||
|
||||
To enable clipping, define the logical CLIP before compiling. This is the
|
||||
default mode of operation as it has already been included in the POKEY.H file.
|
||||
Note that this is only recommended if clipping is necessary since it will
|
||||
Note that this is only recommended if clipping is necessary since it will
|
||||
impact the performance.
|
||||
|
||||
This function has no return value (void).
|
||||
@ -280,7 +280,7 @@ Pokey_process (uint8 *buffer, uint16 n)
|
||||
|
||||
This function calculates and fills a buffer with unsigned 8-bit mono audio.
|
||||
This function takes two parameters: a pointer to the buffer to fill and
|
||||
the size of the buffer (limited to 65535). This function fills the
|
||||
the size of the buffer (limited to 65535). This function fills the
|
||||
buffer based on the requested size and returns. It automatically
|
||||
updates the pointers for the next call, so subsequent calls to this function
|
||||
will provide a continuous stream of data.
|
||||
@ -292,7 +292,7 @@ system and emulator performance.
|
||||
|
||||
Selecting the correct buffer size is a careful balance. Selecting a buffer
|
||||
size that is too small will produce noticeable clicks in the output, though
|
||||
selecting a size that is too large will cause a poor response time and
|
||||
selecting a size that is too large will cause a poor response time and
|
||||
possible delays in the system when the new buffer is filled.
|
||||
|
||||
This function has no return value (void).
|
||||
@ -303,17 +303,17 @@ License Information and Copyright Notice
|
||||
|
||||
PokeySound is Copyright(c) 1996-1997 by Ron Fries
|
||||
|
||||
This library is free software; you can redistribute it and/or modify it under
|
||||
the terms of version 2 of the GNU Library General Public License as published
|
||||
This library is free software; you can redistribute it and/or modify it under
|
||||
the terms of version 2 of the GNU Library General Public License as published
|
||||
by the Free Software Foundation.
|
||||
|
||||
This library is distributed in the hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
||||
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
|
||||
This library is distributed in the hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
||||
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
|
||||
details.
|
||||
|
||||
To obtain a copy of the GNU Library General Public License, write to the Free
|
||||
To obtain a copy of the GNU Library General Public License, write to the Free
|
||||
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
Any permitted reproduction of these routines, in whole or in part, must bear
|
||||
this legend.
|
||||
Any permitted reproduction of these routines, in whole or in part, must bear
|
||||
this legend.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
The template family tree is an attempt to ease the pain to write CPUs/drivers/devices
|
||||
from scratch (especially for smaller projects).
|
||||
The template family tree is an attempt to ease the pain to write CPUs/drivers/devices
|
||||
from scratch (especially for smaller projects).
|
||||
|
||||
===
|
||||
Usage:
|
||||
|
||||
@ -17,15 +17,15 @@ Known bugs:
|
||||
* SDL2.0: sdlvideofps does not take -numscreens>1 into account.
|
||||
* SDL1.3/WIN32: crashes with -rd d3d
|
||||
* SDL1.3/WIN32: resizing does not work
|
||||
|
||||
|
||||
Build SDL 2.0 from HG
|
||||
======================
|
||||
|
||||
Pull 2.0 from hg. Than
|
||||
Pull 2.0 from hg. Than
|
||||
|
||||
sh autogen.sh
|
||||
./configure --prefix=/usr/local/sdl13/ --disable-video-svga --enable-video-directfb --enable-fusionsound
|
||||
make
|
||||
make
|
||||
[sudo] make install
|
||||
|
||||
You may leave away the last two enables, if you do not want to play around with directfb - although it is lightning fast now :-)
|
||||
@ -66,15 +66,15 @@ The following modes are working:
|
||||
SDL13
|
||||
=====
|
||||
|
||||
This is driver using SDL texture and line drawing support. It supports
|
||||
-prescale, -filter and -waitvsync. The driver determines which pixel
|
||||
formats perform best and converts textures to these pixel formats and at
|
||||
the same time performs any necessary rotation.
|
||||
This is driver using SDL texture and line drawing support. It supports
|
||||
-prescale, -filter and -waitvsync. The driver determines which pixel
|
||||
formats perform best and converts textures to these pixel formats and at
|
||||
the same time performs any necessary rotation.
|
||||
|
||||
Basic usage examples:
|
||||
|
||||
X11/opengl: ./mamed -video sdl13 -rd opengl mario
|
||||
DFB/DFB: ./mamed -video sdl13 -vd directfb -rd directfb mario
|
||||
X11/opengl: ./mamed -video sdl13 -rd opengl mario
|
||||
DFB/DFB: ./mamed -video sdl13 -vd directfb -rd directfb mario
|
||||
|
||||
The performance of the directfb driver depends on the combined
|
||||
support of the kernel framebuffer driver and the directfb driver.
|
||||
@ -93,7 +93,7 @@ Soft:
|
||||
OpenGL:
|
||||
=======
|
||||
|
||||
Plain opengl does work. Anything more advanced like pbo, fbo or glsl will
|
||||
Plain opengl does work. Anything more advanced like pbo, fbo or glsl will
|
||||
most probably not work with more than one screen.
|
||||
|
||||
./mamed -mt -video opengl mario -nogl_pbo -nogl_vbo -nogl_glsl -numscreens 2
|
||||
@ -106,8 +106,8 @@ YUV - modes:
|
||||
Using DirectFB, the following should get you going
|
||||
|
||||
./mamed -mt -video soft -sm yuy2 -vd directfb -rd directfb mario
|
||||
|
||||
for accelerated blitting on the framebuffer - provided directfb supports it.
|
||||
|
||||
for accelerated blitting on the framebuffer - provided directfb supports it.
|
||||
At least my Radeon R480 is supported.
|
||||
|
||||
-video soft and -scale_mode (-sm)
|
||||
@ -121,12 +121,10 @@ hwblit: Rendering in software/scaling with hardware (if supported)
|
||||
|
||||
hwbest: Rendering in software/antialiased scaling with hardware (if supported)
|
||||
|
||||
yv12, yv12x2, yuy2, yuy2x2:
|
||||
yv12, yv12x2, yuy2, yuy2x2:
|
||||
Rendering in software / scaling with hardware (if supported)
|
||||
|
||||
Whether these are actually hardware accelerated depends on the SDL driver
|
||||
and the hardware. The SDL directfb driver supports all above if the hardware
|
||||
supports it. However, only one YUV-texture per display is supported.
|
||||
and the hardware. The SDL directfb driver supports all above if the hardware
|
||||
supports it. However, only one YUV-texture per display is supported.
|
||||
The second window consequently will get "software" YUV blitting.
|
||||
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Keymap file for a swiss keyboard (Linux)
|
||||
#
|
||||
#
|
||||
#
|
||||
ITEM_ID_MINUS SDLK_QUOTE 0x14 0x27 '
|
||||
ITEM_ID_EQUALS SDLK_CARET 0x15 0x0 ^
|
||||
ITEM_ID_Y SDLK_z 0x1d 0x7a z
|
||||
|
||||
@ -1,23 +1,23 @@
|
||||
# Keymap for French AZERTY keyboard (Linux)
|
||||
ITEM_ID_TILDE SDLK_WORLD_18 0x31 0xb2 ²
|
||||
ITEM_ID_1 SDLK_AMPERSAND 0xa 0x26 &
|
||||
ITEM_ID_2 SDLK_WORLD_73 0xb 0xe9 é
|
||||
ITEM_ID_3 SDLK_QUOTEDBL 0xc 0x22 "
|
||||
ITEM_ID_4 SDLK_QUOTE 0xd 0x27 '
|
||||
ITEM_ID_5 SDLK_LEFTPAREN 0xe 0x28 (
|
||||
ITEM_ID_6 SDLK_MINUS 0xf 0x2d -
|
||||
ITEM_ID_7 SDLK_WORLD_72 0x10 0xe8 è
|
||||
ITEM_ID_8 SDLK_UNDERSCORE 0x11 0x5f _
|
||||
ITEM_ID_9 SDLK_WORLD_71 0x12 0xe7 ç
|
||||
ITEM_ID_0 SDLK_WORLD_64 0x13 0xe0 à
|
||||
ITEM_ID_MINUS SDLK_RIGHTPAREN 0x14 0x29 )
|
||||
ITEM_ID_EQUALS SDLK_EQUALS 0x15 0x3d =
|
||||
ITEM_ID_TILDE SDLK_WORLD_18 0x31 0xb2 ²
|
||||
ITEM_ID_1 SDLK_AMPERSAND 0xa 0x26 &
|
||||
ITEM_ID_2 SDLK_WORLD_73 0xb 0xe9 é
|
||||
ITEM_ID_3 SDLK_QUOTEDBL 0xc 0x22 "
|
||||
ITEM_ID_4 SDLK_QUOTE 0xd 0x27 '
|
||||
ITEM_ID_5 SDLK_LEFTPAREN 0xe 0x28 (
|
||||
ITEM_ID_6 SDLK_MINUS 0xf 0x2d -
|
||||
ITEM_ID_7 SDLK_WORLD_72 0x10 0xe8 è
|
||||
ITEM_ID_8 SDLK_UNDERSCORE 0x11 0x5f _
|
||||
ITEM_ID_9 SDLK_WORLD_71 0x12 0xe7 ç
|
||||
ITEM_ID_0 SDLK_WORLD_64 0x13 0xe0 à
|
||||
ITEM_ID_MINUS SDLK_RIGHTPAREN 0x14 0x29 )
|
||||
ITEM_ID_EQUALS SDLK_EQUALS 0x15 0x3d =
|
||||
ITEM_ID_OPENBRACE SDLK_CARET 0x22 0x0
|
||||
ITEM_ID_CLOSEBRACE SDLK_DOLLAR 0x23 0x0
|
||||
ITEM_ID_COMMA SDLK_COMMA 0x3a 0x2c ,
|
||||
ITEM_ID_STOP SDLK_SEMICOLON 0x3b 0x3b ;
|
||||
ITEM_ID_SLASH SDLK_COLON 0x3c 0x3a :
|
||||
ITEM_ID_COLON SDLK_WORLD_89 0x30 0xf9 ù
|
||||
ITEM_ID_QUOTE SDLK_ASTERISK 0x33 0x2a *
|
||||
ITEM_ID_BACKSLASH SDLK_EXCLAIM 0x3d 0x21 !
|
||||
ITEM_ID_COMMA SDLK_COMMA 0x3a 0x2c ,
|
||||
ITEM_ID_STOP SDLK_SEMICOLON 0x3b 0x3b ;
|
||||
ITEM_ID_SLASH SDLK_COLON 0x3c 0x3a :
|
||||
ITEM_ID_COLON SDLK_WORLD_89 0x30 0xf9 ù
|
||||
ITEM_ID_QUOTE SDLK_ASTERISK 0x33 0x2a *
|
||||
ITEM_ID_BACKSLASH SDLK_EXCLAIM 0x3d 0x21 !
|
||||
ITEM_ID_BACKSLASH2 SDLK_LESS 0x5e 0x3c <
|
||||
|
||||
Loading…
Reference in New Issue
Block a user