From 4cc89fb55209346b433e3334e3962c967fffae8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zoe=CC=88=20Blade?= Date: Wed, 8 Apr 2015 15:27:15 +0100 Subject: [PATCH] Tidy whitespace in plain text files --- docs/SDL.txt | 17 ++-- docs/config.txt | 56 ++++++------- docs/floppy.txt | 4 +- docs/hlsl.txt | 4 +- docs/imgtool.txt | 22 ++--- docs/m6502.txt | 4 +- docs/windows.txt | 10 +-- src/emu/cpu/i86/i86.txt | 10 +-- src/emu/sound/pokey.txt | 136 +++++++++++++++---------------- src/mame/etc/template_readme.txt | 4 +- src/osd/sdl/README_SDL20.txt | 32 ++++---- src/osd/sdl/keymaps/km-ch.txt | 2 +- src/osd/sdl/keymaps/km-fr.txt | 38 ++++----- 13 files changed, 168 insertions(+), 171 deletions(-) diff --git a/docs/SDL.txt b/docs/SDL.txt index e755819f4da..5361c7e4e39 100644 --- a/docs/SDL.txt +++ b/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 / -np 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 - 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 @@ -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) diff --git a/docs/config.txt b/docs/config.txt index 2d780d6b777..1189c773508 100644 --- a/docs/config.txt +++ b/docs/config.txt @@ -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 [] 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 [] - + 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 [] - + 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 x @@ -607,30 +607,30 @@ Core state/playback options -statename Describes how MAME should store save state files, relative to the - state_directory path. 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. 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-.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] diff --git a/docs/floppy.txt b/docs/floppy.txt index 13439ff475b..7fc2331d4f6 100644 --- a/docs/floppy.txt +++ b/docs/floppy.txt @@ -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 diff --git a/docs/hlsl.txt b/docs/hlsl.txt index a2d5f652b2b..50283bd365c 100644 --- a/docs/hlsl.txt +++ b/docs/hlsl.txt @@ -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) \ No newline at end of file +bloom_lvl10_weight 0.09 Bloom level 10 (1x1 target) weight. (0.00-1.00) diff --git a/docs/imgtool.txt b/docs/imgtool.txt index d770eccbaeb..c9ac101d514 100644 --- a/docs/imgtool.txt +++ b/docs/imgtool.txt @@ -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= bs=512 count=$((9*2*40)) +dd if=/dev/zero of= 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= bs=512 count=$((17*4*615)) +dd if=/dev/zero of= 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). diff --git a/docs/m6502.txt b/docs/m6502.txt index 2a45a3e172e..33d2bbdcec0 100644 --- a/docs/m6502.txt +++ b/docs/m6502.txt @@ -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 | diff --git a/docs/windows.txt b/docs/windows.txt index 4e31f7baf32..bbd14a19359 100644 --- a/docs/windows.txt +++ b/docs/windows.txt @@ -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 / -dfontsize 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 / -np 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] diff --git a/src/emu/cpu/i86/i86.txt b/src/emu/cpu/i86/i86.txt index ecf17e0e424..39b54d6a8d0 100644 --- a/src/emu/cpu/i86/i86.txt +++ b/src/emu/cpu/i86/i86.txt @@ -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 diff --git a/src/emu/sound/pokey.txt b/src/emu/sound/pokey.txt index 04a12ec48da..e0a30094893 100644 --- a/src/emu/sound/pokey.txt +++ b/src/emu/sound/pokey.txt @@ -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. diff --git a/src/mame/etc/template_readme.txt b/src/mame/etc/template_readme.txt index fdbc8f8df9e..59c68e132e3 100644 --- a/src/mame/etc/template_readme.txt +++ b/src/mame/etc/template_readme.txt @@ -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: diff --git a/src/osd/sdl/README_SDL20.txt b/src/osd/sdl/README_SDL20.txt index 1dd0e1c1990..715e9e6d595 100644 --- a/src/osd/sdl/README_SDL20.txt +++ b/src/osd/sdl/README_SDL20.txt @@ -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. - - diff --git a/src/osd/sdl/keymaps/km-ch.txt b/src/osd/sdl/keymaps/km-ch.txt index 8359ec6af83..a23545bf5c8 100644 --- a/src/osd/sdl/keymaps/km-ch.txt +++ b/src/osd/sdl/keymaps/km-ch.txt @@ -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 diff --git a/src/osd/sdl/keymaps/km-fr.txt b/src/osd/sdl/keymaps/km-fr.txt index c42799095ec..f68948295da 100644 --- a/src/osd/sdl/keymaps/km-fr.txt +++ b/src/osd/sdl/keymaps/km-fr.txt @@ -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 <