trunk/docs/config.txt
| r245592 | r245593 | |
|---|
| 294 | 294 | Displays a list of all devices known to be hooked up to a game. The ":" |
| 295 | 295 | is considered the game itself with the devices list being attached to give |
| 296 | 296 | the user a better understanding of what the emulation is using. |
| 297 | | |
| 297 | |
| 298 | 298 | -listslots [<gamename|wildcard>] |
| 299 | 299 | |
| 300 | 300 | Show available slots and options for each slot (if available). Primarily |
| 301 | 301 | used for MESS to allow control over internal plug-in cards, much like PC's |
| 302 | 302 | needing video, sound and other cards. |
| 303 | | |
| 303 | |
| 304 | 304 | -listmedia / -lm [<gamename|wildcard>] |
| 305 | | |
| 305 | |
| 306 | 306 | List available media that the chosen game or system allows to be used. This |
| 307 | 307 | includes media types (cartridge, cassette, diskette and more) as well as |
| 308 | 308 | common file extentions which are supported. |
| 309 | 309 | |
| 310 | 310 | -listsoftware [<gamename|wildcard>] |
| 311 | | |
| 311 | |
| 312 | 312 | Posts to screen all software lists which can be used by the entered gamename |
| 313 | 313 | or system. Notice, this is simply a copy/paste of the .XML file which reside |
| 314 | 314 | in the HASH folder which are allowed to be used. |
| r245592 | r245593 | |
|---|
| 331 | 331 | softwarelistname. By default, all drivers that have valid ZIP files or directories |
| 332 | 332 | in the rompath are verified; however, you can limit this list by specifying a |
| 333 | 333 | specific softwarelistname (without .XML) after the -verifysoftlist command. |
| 334 | | |
| 334 | |
| 335 | 335 | -listmidi |
| 336 | 336 | |
| 337 | 337 | Create a list of list available MIDI I/O devices for use with emulation. |
| 338 | 338 | |
| 339 | | |
| 340 | 339 | |
| 340 | |
| 341 | 341 | Configuration options |
| 342 | 342 | --------------------- |
| 343 | 343 | |
| r245592 | r245593 | |
|---|
| 570 | 570 | find the next empty value for %i and use that for a filename. The |
| 571 | 571 | default is %g/%i, which creates a separate folder for each game, |
| 572 | 572 | and names the snapshots under it starting with 0000 and increasing |
| 573 | | from there. In addition to the above, for drivers using different |
| 574 | | media, like carts or floppy disks, you can also use the %d_[media] |
| 573 | from there. In addition to the above, for drivers using different |
| 574 | media, like carts or floppy disks, you can also use the %d_[media] |
| 575 | 575 | indicator. Replace [media] with the media switch you want to use. |
| 576 | | A few examples: if you use 'mame robby -snapname foo/%g%i' snapshots |
| 576 | A few examples: if you use 'mame robby -snapname foo/%g%i' snapshots |
| 577 | 577 | will be saved as 'snaps\foo\robby0000.png' , 'snaps\foo\robby0001.png' |
| 578 | | and so on ; if you use 'mess nes -cart robby -snapname %g/%d_cart' |
| 579 | | snapshots will be saved as 'snaps\nes\robby.png' ; if you use |
| 580 | | 'mess c64 -flop1 robby -snapname %g/%d_flop1/%i' snapshots will be |
| 578 | and so on ; if you use 'mess nes -cart robby -snapname %g/%d_cart' |
| 579 | snapshots will be saved as 'snaps\nes\robby.png' ; if you use |
| 580 | 'mess c64 -flop1 robby -snapname %g/%d_flop1/%i' snapshots will be |
| 581 | 581 | saved as 'snaps\c64\robby\0000.png'. |
| 582 | 582 | |
| 583 | 583 | -snapsize <width>x<height> |
| r245592 | r245593 | |
|---|
| 607 | 607 | -statename <name> |
| 608 | 608 | |
| 609 | 609 | Describes how MAME should store save state files, relative to the |
| 610 | | state_directory path. <name> is a string that provides a template that |
| 611 | | is used to generate a relative path. Two simple substitutions are |
| 612 | | provided: the / character represents the path separator on any target |
| 613 | | platform (even Windows); the string %g represents the driver name of |
| 614 | | the current game. The default is %g, which creates a separate folder for |
| 615 | | each game. In addition to the above, for drivers using different |
| 616 | | media, like carts or floppy disks, you can also use the %d_[media] |
| 610 | state_directory path. <name> is a string that provides a template that |
| 611 | is used to generate a relative path. Two simple substitutions are |
| 612 | provided: the / character represents the path separator on any target |
| 613 | platform (even Windows); the string %g represents the driver name of |
| 614 | the current game. The default is %g, which creates a separate folder for |
| 615 | each game. In addition to the above, for drivers using different |
| 616 | media, like carts or floppy disks, you can also use the %d_[media] |
| 617 | 617 | indicator. Replace [media] with the media switch you want to use. |
| 618 | | A few examples: if you use 'mame robby -statename foo/%g' save states |
| 619 | | will be stored inside 'sta\foo\robby\' ; if you use 'mess nes -cart |
| 620 | | robby -statename %g/%d_cart' save states will be stored inside |
| 621 | | 'sta\nes\robby\' ; if you use 'mess c64 -flop1 robby -statename |
| 618 | A few examples: if you use 'mame robby -statename foo/%g' save states |
| 619 | will be stored inside 'sta\foo\robby\' ; if you use 'mess nes -cart |
| 620 | robby -statename %g/%d_cart' save states will be stored inside |
| 621 | 'sta\nes\robby\' ; if you use 'mess c64 -flop1 robby -statename |
| 622 | 622 | %g/%d_flop1' save states will be stored inside 'sta\c64\robby\'. |
| 623 | 623 | |
| 624 | 624 | -[no]burnin |
| 625 | 625 | |
| 626 | | Tracks brightness of the screen during play and at the end of |
| 626 | Tracks brightness of the screen during play and at the end of |
| 627 | 627 | emulation generates a PNG that can be used to simulate burn-in |
| 628 | 628 | effects on other games. The resulting PNG is created such that the |
| 629 | | least used-areas of the screen are fully white (since burned-in areas |
| 629 | least used-areas of the screen are fully white (since burned-in areas |
| 630 | 630 | are darker, all other areas of the screen must be lightened a touch). |
| 631 | 631 | The intention is that this PNG can be loaded via an artwork file with |
| 632 | 632 | a low alpha (e.g, 0.1-0.2 seems to work well) and blended over the |
| 633 | | entire screen. The PNG files are saved in the snap directory under |
| 633 | entire screen. The PNG files are saved in the snap directory under |
| 634 | 634 | the gamename/burnin-<screen.name>.png. The default is OFF (-noburnin). |
| 635 | 635 | |
| 636 | 636 | |
| r245592 | r245593 | |
|---|
| 1122 | 1122 | |
| 1123 | 1123 | A special 'internal' debugger for debugging. Activated when used along |
| 1124 | 1124 | with -debug. The default if OFF (-nodebug_internal). |
| 1125 | | |
| 1126 | 1125 | |
| 1127 | 1126 | |
| 1127 | |
| 1128 | 1128 | Core misc options |
| 1129 | 1129 | ----------------- |
| 1130 | 1130 | |
| r245592 | r245593 | |
|---|
| 1149 | 1149 | Specifies the name of a font file to use for the UI font. If this font |
| 1150 | 1150 | cannot be found or cannot be loaded, the system will fall back to its |
| 1151 | 1151 | built-in UI font. On some platforms 'fontname' can be a system font |
| 1152 | | name (TTF) instead of a (BDF) font file. The default is 'default' (use |
| 1152 | name (TTF) instead of a (BDF) font file. The default is 'default' (use |
| 1153 | 1153 | the OSD-determined default font). |
| 1154 | 1154 | |
| 1155 | 1155 | -ramsize [n] |
trunk/docs/imgtool.txt
| r245592 | r245593 | |
|---|
| 81 | 81 | only extraction supported |
| 82 | 82 | not heavily tested |
| 83 | 83 | |
| 84 | | Lynx archivs could and should be handled in a c64 emulation |
| 84 | Lynx archivs could and should be handled in a c64 emulation |
| 85 | 85 | with the native lynx tool |
| 86 | 86 | |
| 87 | 87 | |
| r245592 | r245593 | |
|---|
| 128 | 128 | type 7: 3 1/2 inch, enhanced density, DS, 2.88mb: sectors 36, heads 2, tracks 80 |
| 129 | 129 | |
| 130 | 130 | unix with bash: use |
| 131 | | dd if=/dev/zero of=<name.dsk> bs=512 count=$((9*2*40)) |
| 131 | dd if=/dev/zero of=<name.dsk> bs=512 count=$((9*2*40)) |
| 132 | 132 | to generate standard blank 360kb image |
| 133 | 133 | |
| 134 | 134 | |
| r245592 | r245593 | |
|---|
| 145 | 145 | type 0: 20mb standard pc/xt harddisk: 17 sectors, 4 heads, 615 cylinders |
| 146 | 146 | |
| 147 | 147 | unix with bash: use |
| 148 | | dd if=/dev/zero of=<name.dsk> bs=512 count=$((17*4*615)) |
| 148 | dd if=/dev/zero of=<name.dsk> bs=512 count=$((17*4*615)) |
| 149 | 149 | to generate standard blank 20mb pc xt harddisk image |
| 150 | 150 | |
| 151 | 151 | |
| 152 | 152 | Virtual MSX tape archive |
| 153 | 153 | ------------------------ |
| 154 | 154 | Converts .tap files from Virtual MSX 1.x to .cas files. It is not |
| 155 | | fault-tolerant. |
| 155 | fault-tolerant. |
| 156 | 156 | |
| 157 | 157 | |
| 158 | 158 | Virtual MSX Game Master 2 SRAM file |
| r245592 | r245593 | |
|---|
| 161 | 161 | SRAM of Konami's Game Master 2 in "gmaster2.ram". To convert this to something |
| 162 | 162 | useful with MESS and other MSX emulators, go: |
| 163 | 163 | |
| 164 | | imgtool getall vmsx_gm2 gmaster2.ram |
| 164 | imgtool getall vmsx_gm2 gmaster2.ram |
| 165 | 165 | |
| 166 | 166 | You'll get a file called gmaster2.mem, which must place in the correct directory |
| 167 | 167 | of mess to use (MESS\MEMCARD\GameMaster2 if your Game Master 2 .rom file is |
| r245592 | r245593 | |
|---|
| 174 | 174 | so you don't have to convert them. You can use it to export files to a real |
| 175 | 175 | MSX. Connect the MSX to the line out of your computer. Give the apropriate |
| 176 | 176 | command on the MSX (BLOAD "CAS:",R for example) and then play the .wav file |
| 177 | | on your computer. |
| 177 | on your computer. |
| 178 | 178 | |
| 179 | 179 | imgtool dir fmsx_cas file.cas |
| 180 | 180 | imgtool getall fmsx_cas file.cas |
| r245592 | r245593 | |
|---|
| 185 | 185 | ----------------------- |
| 186 | 186 | |
| 187 | 187 | The XelaSoft Archive is a compressed file. It can only contain one |
| 188 | | file. Although it can contain any file, it's always used for MSX disk |
| 188 | file. Although it can contain any file, it's always used for MSX disk |
| 189 | 189 | images. The were programs written by XelaSoft which made a dump |
| 190 | 190 | of a disk, and compressing them at the same time. Very useful to store |
| 191 | 191 | a disk dump on another disk. zip/gzip offer much better compression and |
| r245592 | r245593 | |
|---|
| 205 | 205 | filetype converts them all to .dsk format. |
| 206 | 206 | |
| 207 | 207 | msx_img are disk images with an extra byte at the beginning. It' 1 (0x01) |
| 208 | | for single-sided images and 2 (0x02) for double-side images. These |
| 208 | for single-sided images and 2 (0x02) for double-side images. These |
| 209 | 209 | files are at: ftp://ftp.funet.fi/pub/msx/. The extension is .img |
| 210 | 210 | |
| 211 | 211 | msx_ddi are DiskDupe 5.12 disk images. There is a 0x1800 bytes header |
| r245592 | r245593 | |
|---|
| 215 | 215 | msx_msx are disk images with a weird sector order. You can find them |
| 216 | 216 | at: ftp://jazz.snu.ac.kr/pub/msx/. The extension is .msx |
| 217 | 217 | |
| 218 | | msx_mul are "multi disk" images, used by fmsx-dos 1.6. It is simply |
| 218 | msx_mul are "multi disk" images, used by fmsx-dos 1.6. It is simply |
| 219 | 219 | more than one .dsk image appended to one another. The extension is |
| 220 | | still .dsk, but the file is larger than 720kB (actually always a |
| 220 | still .dsk, but the file is larger than 720kB (actually always a |
| 221 | 221 | multiple of 720kB. |
| 222 | 222 | |
| 223 | 223 | |
| r245592 | r245593 | |
|---|
| 235 | 235 | The maximum card size is 1mb, and maximum file size is 64k. |
| 236 | 236 | (Files will be cut at 64k if they are larger - e.g. when putting a large file) |
| 237 | 237 | |
| 238 | | As far as I know there is no directory system, however there is always a |
| 238 | As far as I know there is no directory system, however there is always a |
| 239 | 239 | system "NC100" directory which points to the root directory. (Like the DOS "." |
| 240 | 240 | directory). |
| 241 | 241 | |
trunk/src/emu/sound/pokey.txt
| r245592 | r245593 | |
|---|
| 4 | 4 | 31 Jan 97 |
| 5 | 5 | |
| 6 | 6 | The PokeySound Chip Emulator is designed to emulate the functionality of the |
| 7 | | Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to |
| 8 | | produce sounds which are essentially identical to the original POKEY chip, |
| 9 | | including the exact distortions and pitches. |
| 7 | Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to |
| 8 | produce sounds which are essentially identical to the original POKEY chip, |
| 9 | including the exact distortions and pitches. |
| 10 | 10 | |
| 11 | 11 | The emulator is designed to run in a 32-bit environment. Though it can be |
| 12 | | compiled and run in a 16-bit environment, it is slow. |
| 12 | compiled and run in a 16-bit environment, it is slow. |
| 13 | 13 | |
| 14 | 14 | I would like to give special thanks to Neil Bradley. He provided excellent |
| 15 | 15 | testing support and was also the driving force behind the multiple POKEY |
| r245592 | r245593 | |
|---|
| 26 | 26 | 2) An adjustable gain. The previous releases had a built-in gain of 64. |
| 27 | 27 | |
| 28 | 28 | 3) A clipping option. Depending on the number of chips emulated and the |
| 29 | | configured gain, it is possible for the output to exceed 8-bits. |
| 29 | configured gain, it is possible for the output to exceed 8-bits. |
| 30 | 30 | Clipping can be enabled to prevent this, though it does increase the |
| 31 | | processing time. |
| 31 | processing time. |
| 32 | 32 | |
| 33 | 33 | |
| 34 | 34 | Standard Features: |
| r245592 | r245593 | |
|---|
| 36 | 36 | |
| 37 | 37 | The 'PokeySound' emulator supports the following functions: |
| 38 | 38 | |
| 39 | | 1) All polynomial sound generators: |
| 39 | 1) All polynomial sound generators: |
| 40 | 40 | a) 4-bit poly - actual bit pattern determined from sampled sound |
| 41 | 41 | b) 5-bit poly - actual bit pattern determined from sampled sound |
| 42 | 42 | c) 17-bit poly - simulated random bit pattern |
| 43 | 43 | d) 9-bit poly - derived from simulated 17-bit poly |
| 44 | | |
| 44 | |
| 45 | 45 | 2) Full support of all 'Divide by N' counter clocks: |
| 46 | 46 | a) 1.79 MHz (high limited to playback sample rate) |
| 47 | 47 | b) 64 KHz (high limited to playback sample rate) |
| r245592 | r245593 | |
|---|
| 51 | 51 | a) 8-bit - single channel |
| 52 | 52 | b) 16-bit - double channel |
| 53 | 53 | |
| 54 | | 4) Full support of all distortions |
| 54 | 4) Full support of all distortions |
| 55 | 55 | a) 5-bit poly, then 17-bit poly |
| 56 | 56 | b) 5-bit poly only |
| 57 | 57 | c) 5-bit poly, then 4-bit poly |
| r245592 | r245593 | |
|---|
| 59 | 59 | e) no poly counters (pure tone) |
| 60 | 60 | f) 5-bit poly only |
| 61 | 61 | |
| 62 | | 5) Full support of volume control |
| 62 | 5) Full support of volume control |
| 63 | 63 | |
| 64 | 64 | 6) Full support of all pitches - distortions will vary exactly as the |
| 65 | 65 | original Atari based on different pitches |
| r245592 | r245593 | |
|---|
| 84 | 84 | left in for reference. If you would still like to see the non-optimized |
| 85 | 85 | version, it's available in the 1.2 release. |
| 86 | 86 | |
| 87 | | One of the unique features of the emulator is that the processing time varies |
| 88 | | based on the frequency. Since the routine only calculates new output values |
| 89 | | when a change is sensed, the lower frequencies (which change less frequently) |
| 87 | One of the unique features of the emulator is that the processing time varies |
| 88 | based on the frequency. Since the routine only calculates new output values |
| 89 | when a change is sensed, the lower frequencies (which change less frequently) |
| 90 | 90 | will require less processing time. |
| 91 | 91 | |
| 92 | 92 | |
| 93 | 93 | Differences Between the Emulator and the Actual POKEY Chip: |
| 94 | | ----------------------------------------------------------- |
| 94 | ----------------------------------------------------------- |
| 95 | 95 | |
| 96 | | The biggest difference between the emulator and the original hardware is |
| 97 | | that the emulator emulates an 'ideal' POKEY chip. All output from the |
| 96 | The biggest difference between the emulator and the original hardware is |
| 97 | that the emulator emulates an 'ideal' POKEY chip. All output from the |
| 98 | 98 | emulator is a based on a precise square wave, whereas the output from the |
| 99 | 99 | original chip has decay. Though the output is slightly different, I |
| 100 | 100 | don't believe this difference is easily discernible. |
| 101 | 101 | |
| 102 | 102 | Another slight difference is the 17-bit/9-bit poly. Since the polynomial |
| 103 | 103 | is large (2^17 bits), I choose to create the sample using a random number |
| 104 | | generator rather than a table. I don't believe this difference is |
| 104 | generator rather than a table. I don't believe this difference is |
| 105 | 105 | significant. |
| 106 | 106 | |
| 107 | 107 | There are also a few differences which are introduced by aliasing. This is |
| 108 | 108 | a direct result of using an output sampling rate which is not identical to |
| 109 | | the original sound rate. It is most evident with high frequencies. |
| 109 | the original sound rate. It is most evident with high frequencies. |
| 110 | 110 | |
| 111 | | A final difference is the lack of support for the High-Pass Filter |
| 111 | A final difference is the lack of support for the High-Pass Filter |
| 112 | 112 | functionality. I plan to add this in a future release if necessary. |
| 113 | 113 | |
| 114 | 114 | |
| 115 | 115 | Sample/Test Application: |
| 116 | 116 | ------------------------ |
| 117 | 117 | |
| 118 | | The test program I've distributed is a 16-bit DOS application created with |
| 119 | | the Borland 'C' compiler. The only reason I used 16-bit was because I |
| 118 | The test program I've distributed is a 16-bit DOS application created with |
| 119 | the Borland 'C' compiler. The only reason I used 16-bit was because I |
| 120 | 120 | already had a set of working SB drivers in 16-bit. Since the test system |
| 121 | 121 | is dedicated to generating sounds, the performance in 16-bit is more than |
| 122 | 122 | adequate. |
| r245592 | r245593 | |
|---|
| 125 | 125 | POKEY.C |
| 126 | 126 | ======= |
| 127 | 127 | |
| 128 | | The POKEY.C file is the heart of the PokeySound Emulation program. |
| 128 | The POKEY.C file is the heart of the PokeySound Emulation program. |
| 129 | 129 | Although the routines in the file must work together, no other files are |
| 130 | | modules are required for operation. A header file, 'POKEY.H', has |
| 131 | | been included for use in other modules, and provides the necessary |
| 130 | modules are required for operation. A header file, 'POKEY.H', has |
| 131 | been included for use in other modules, and provides the necessary |
| 132 | 132 | function prototypes. I've attempted to make the routines as portable as |
| 133 | 133 | possible, so the file should compile on almost any compiler with little |
| 134 | | or no modification. |
| 134 | or no modification. |
| 135 | 135 | |
| 136 | 136 | I have made some attempts at optimizing the routines, though I am sure |
| 137 | 137 | more optimization can be done. They are currently only available in 'C'. |
| 138 | | I'll be happy to convert them to assembly language if desired. Please feel |
| 138 | I'll be happy to convert them to assembly language if desired. Please feel |
| 139 | 139 | free to send me e-mail at rfries@tcmail.frco.com. |
| 140 | 140 | |
| 141 | | The routines are easy to use. Detailed descriptions on the function calls |
| 141 | The routines are easy to use. Detailed descriptions on the function calls |
| 142 | 142 | are listed below. |
| 143 | 143 | |
| 144 | 144 | The POKEY.C module can be compiled in a 32-bit or 16-bit environment. |
| r245592 | r245593 | |
|---|
| 150 | 150 | GENERAL OVERVIEW |
| 151 | 151 | ---------------- |
| 152 | 152 | |
| 153 | | On start-up of the system, a single call should be made to Pokey_sound_init. |
| 153 | On start-up of the system, a single call should be made to Pokey_sound_init. |
| 154 | 154 | This routine will prepare the structures for sound output. This routine |
| 155 | 155 | can be called again if necessary during warm-start or other reset. |
| 156 | 156 | |
| 157 | | Once in the main loop, there are two other functions that will be used. |
| 157 | Once in the main loop, there are two other functions that will be used. |
| 158 | 158 | Whenever the system needs to write to either the AUDC or AUDF values, |
| 159 | | a call should be made to the Update_pokey_sound routine. This routine will |
| 159 | a call should be made to the Update_pokey_sound routine. This routine will |
| 160 | 160 | take care of updating the internal registers. It will pre-calculate several |
| 161 | 161 | values to help with optimization. |
| 162 | 162 | |
| 163 | | The only other routine that is called is the Pokey_process function. This |
| 163 | The only other routine that is called is the Pokey_process function. This |
| 164 | 164 | function will fill a audio buffer with a specified number of bytes. This |
| 165 | 165 | function should be called whenever a new audio buffer is required. |
| 166 | 166 | |
| r245592 | r245593 | |
|---|
| 176 | 176 | ----------------------------------------------------------------------- |
| 177 | 177 | |
| 178 | 178 | This function initializes the structures used by the PokeySound routines. |
| 179 | | This function takes three parameters: the main clock frequency, the |
| 179 | This function takes three parameters: the main clock frequency, the |
| 180 | 180 | playback frequency and the number of POKEY chips to emulate. |
| 181 | 181 | |
| 182 | 182 | The maximum number of POKEY chips emulated is configured at compile time. |
| 183 | | Though the maximum number of chips can be configured as one, the PokeySound |
| 184 | | 1.2 routines are recommended if only a single chip is to be emulated since |
| 185 | | they have will provide better performance. |
| 183 | Though the maximum number of chips can be configured as one, the PokeySound |
| 184 | 1.2 routines are recommended if only a single chip is to be emulated since |
| 185 | they have will provide better performance. |
| 186 | 186 | |
| 187 | | The main clock frequency is the frequency of the 1.79MHz source clock. |
| 188 | | To provide exact results, freq17 should be set equal to 1789790 Hz. As an |
| 189 | | alternative, freq17 can be set to an approximate frequency of 1787520 Hz. |
| 190 | | Using this approximate frequency will reduce aliasing and thus produce a |
| 187 | The main clock frequency is the frequency of the 1.79MHz source clock. |
| 188 | To provide exact results, freq17 should be set equal to 1789790 Hz. As an |
| 189 | alternative, freq17 can be set to an approximate frequency of 1787520 Hz. |
| 190 | Using this approximate frequency will reduce aliasing and thus produce a |
| 191 | 191 | clearer output signal. |
| 192 | 192 | |
| 193 | 193 | A constant has been defined for both of these values for your convenience. |
| 194 | 194 | The names are FREQ_17_EXACT and FREQ_17_APPROX. |
| 195 | 195 | |
| 196 | | The playback frequency is the frequency of the sound playback (the frequency |
| 197 | | used by the sound card). For best results, the playback frequency should |
| 196 | The playback frequency is the frequency of the sound playback (the frequency |
| 197 | used by the sound card). For best results, the playback frequency should |
| 198 | 198 | be an even division of the main clock frequency. Since most of the sounds |
| 199 | | will be generated using the 64kHz clock, I also recommend making the |
| 199 | will be generated using the 64kHz clock, I also recommend making the |
| 200 | 200 | playback frequency an even division of the 64kHz clock. |
| 201 | 201 | |
| 202 | 202 | The 64kHz clock is exactly equal to the main clock divided by 28. For |
| 203 | 203 | the playback frequency, I recommend one of the following values: |
| 204 | 204 | |
| 205 | | 1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound |
| 205 | 1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound |
| 206 | 206 | cards can't reproduce this frequency. |
| 207 | 207 | |
| 208 | 208 | 2) FREQ_17_APPROX / (28*2), which is equal to 31920. All of the newer cards |
| 209 | | will support this frequency. |
| 209 | will support this frequency. |
| 210 | 210 | |
| 211 | | 3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB |
| 211 | 3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB |
| 212 | 212 | compatibles should support this frequency. |
| 213 | 213 | |
| 214 | 214 | 4) FREQ_17_APPROX / (28*4), which is equal to 15960. This may be the |
| 215 | 215 | best choice, as it offers good sound reproduction with good performance. |
| 216 | | |
| 216 | |
| 217 | 217 | Of course, these options also assume you are using the approximate |
| 218 | 218 | frequency for the main clock as well. Any of these choices will offer the |
| 219 | 219 | best results when the main 64kHz clock is used, reasonable results when the |
| r245592 | r245593 | |
|---|
| 231 | 231 | |
| 232 | 232 | This function should be called each time an AUDC, AUDF or AUDCTL value |
| 233 | 233 | changes. This function takes four parameters: the address to change, |
| 234 | | the new value, the chip to be updated, and the gain to be used. |
| 234 | the new value, the chip to be updated, and the gain to be used. |
| 235 | 235 | The lower four bits of the address should be one of the following values: |
| 236 | 236 | |
| 237 | 237 | Addr Description |
| r245592 | r245593 | |
|---|
| 250 | 250 | the address are used. Note that this routine can no longer be called with |
| 251 | 251 | any address as it will affect the operation of the specified chip. |
| 252 | 252 | |
| 253 | | The routine pre-calculates several values that are needed by the |
| 253 | The routine pre-calculates several values that are needed by the |
| 254 | 254 | processing function. This is done to optimize performance. |
| 255 | 255 | |
| 256 | | The output will be amplified (multiplied) by gain/16 (previous releases had |
| 257 | | a built in multiplier of 4, which calculates to a gain value of 64). If the |
| 258 | | output exceeds the maximum value after then gain and clipping is enabled, |
| 256 | The output will be amplified (multiplied) by gain/16 (previous releases had |
| 257 | a built in multiplier of 4, which calculates to a gain value of 64). If the |
| 258 | output exceeds the maximum value after then gain and clipping is enabled, |
| 259 | 259 | the output will be limited to reduce distortion. |
| 260 | 260 | |
| 261 | 261 | The best value for the gain depends on the number of POKEYs emulated and |
| 262 | | the maximum volume used. The maximum possible output for each channel is 15, |
| 263 | | making the maximum possible output for a single chip to be 60. Assuming all |
| 264 | | four channels on the chip are used at full volume, a gain of 64 can be used |
| 265 | | without distortion. If 4 POKEY chips are emulated and all 16 channels are |
| 266 | | used at full volume, the gain must be no more than 16 to prevent distortion. |
| 267 | | Of course, if only a few of the 16 channels are used or not all channels are |
| 262 | the maximum volume used. The maximum possible output for each channel is 15, |
| 263 | making the maximum possible output for a single chip to be 60. Assuming all |
| 264 | four channels on the chip are used at full volume, a gain of 64 can be used |
| 265 | without distortion. If 4 POKEY chips are emulated and all 16 channels are |
| 266 | used at full volume, the gain must be no more than 16 to prevent distortion. |
| 267 | Of course, if only a few of the 16 channels are used or not all channels are |
| 268 | 268 | used at full volume, a larger gain can be used. |
| 269 | 269 | |
| 270 | 270 | To enable clipping, define the logical CLIP before compiling. This is the |
| 271 | 271 | default mode of operation as it has already been included in the POKEY.H file. |
| 272 | | Note that this is only recommended if clipping is necessary since it will |
| 272 | Note that this is only recommended if clipping is necessary since it will |
| 273 | 273 | impact the performance. |
| 274 | 274 | |
| 275 | 275 | This function has no return value (void). |
| r245592 | r245593 | |
|---|
| 280 | 280 | |
| 281 | 281 | This function calculates and fills a buffer with unsigned 8-bit mono audio. |
| 282 | 282 | This function takes two parameters: a pointer to the buffer to fill and |
| 283 | | the size of the buffer (limited to 65535). This function fills the |
| 283 | the size of the buffer (limited to 65535). This function fills the |
| 284 | 284 | buffer based on the requested size and returns. It automatically |
| 285 | 285 | updates the pointers for the next call, so subsequent calls to this function |
| 286 | 286 | will provide a continuous stream of data. |
| r245592 | r245593 | |
|---|
| 292 | 292 | |
| 293 | 293 | Selecting the correct buffer size is a careful balance. Selecting a buffer |
| 294 | 294 | size that is too small will produce noticeable clicks in the output, though |
| 295 | | selecting a size that is too large will cause a poor response time and |
| 295 | selecting a size that is too large will cause a poor response time and |
| 296 | 296 | possible delays in the system when the new buffer is filled. |
| 297 | 297 | |
| 298 | 298 | This function has no return value (void). |
| r245592 | r245593 | |
|---|
| 303 | 303 | |
| 304 | 304 | PokeySound is Copyright(c) 1996-1997 by Ron Fries |
| 305 | 305 | |
| 306 | | This library is free software; you can redistribute it and/or modify it under |
| 307 | | the terms of version 2 of the GNU Library General Public License as published |
| 306 | This library is free software; you can redistribute it and/or modify it under |
| 307 | the terms of version 2 of the GNU Library General Public License as published |
| 308 | 308 | by the Free Software Foundation. |
| 309 | 309 | |
| 310 | | This library is distributed in the hope that it will be useful, but WITHOUT |
| 311 | | ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS |
| 312 | | FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more |
| 310 | This library is distributed in the hope that it will be useful, but WITHOUT |
| 311 | ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS |
| 312 | FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more |
| 313 | 313 | details. |
| 314 | 314 | |
| 315 | | To obtain a copy of the GNU Library General Public License, write to the Free |
| 315 | To obtain a copy of the GNU Library General Public License, write to the Free |
| 316 | 316 | Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| 317 | 317 | |
| 318 | | Any permitted reproduction of these routines, in whole or in part, must bear |
| 319 | | this legend. |
| 318 | Any permitted reproduction of these routines, in whole or in part, must bear |
| 319 | this legend. |