Phoenix From Start to End
This tutorial provides a comprehensive guide to creating a discrete sound emulation for the Phoenix game. It covers the steps required to interface the discrete sound code with the driver and how to transcribe the schematic into discrete code, accompanied by numerous illustrative images. The content is relevant as of MAME 104, and additional code can be found in the files referenced throughout the tutorial. However, only discrete programming-related content will be addressed. The game driver is located in the srcdrivers folder, which contains the foundational structure that connects all components, including CPU memory maps, ROM information, and details regarding the system's configuration for video, sound, and inputs. All game sound code should be placed in the srcsndhrdw folder, while various sound components utilized by the game's sound hardware are stored in the srcsound folder. The game’s sound driver resides in srcsndhrdw and accesses routines from srcsound. A header file should also be created in the srcheaders directory for the game, including declarations for routines, data, and defines used across various files.
To begin, the sound driver basics must be established by creating a file named phoenix.c in the srcsndhrdw directory. The discrete system must be initiated with a reference name, "phoenix_discrete_interface." It is essential to include necessary headers at the start of the file and to add the interface name to the includes in phoenix.h for external access. The discrete header should also be included to provide the necessary information for discrete functions. The DISCRETE_SOUND_START macro initializes an array of type "discrete_sound_block," with each node in the discrete sound emulation representing a member of this array. The initial setup includes defining a single speaker, as Phoenix utilized only one. The sound system is informed about the connection to a DISCRETE system labeled "discrete," with a clock speed set to 120,000 samples per second. If this value is set to zero, the clock will operate at the designated audio sample rate, determining how frequently electrical voltages are updated. While real-world electronics can have an infinite sample rate, simulation requires a balance between sample rate and speed. For Phoenix, a higher sample rate is necessary to enhance accuracy and minimize waveform aliasing due to significant voltage modulation. The sound system is then instructed to configure the phoenix_discrete_interface, with outputs from the discrete system processed by a gain of 0.6 and routed to the defined mono speaker, ensuring sound levels match other Phoenix sound effects.
Once the fundamental sound system is established, the next step is to interface the CPU with the discrete system through DISCRETE_INPUT modules. To facilitate this, schematics are required, outlining the various sound circuits into functional blocks. The amplifier stage is not a concern as it is emulated by the MDRV_SPEAKER_STANDARD_MONO within the game driver, nor is the music circuit, which is handled by the phoenix_tms36xx_interface. Input nodes for the discrete system and final sound effect nodes should be named for clarity, rather than using generic NODE_xx identifiers. This enhances readability and comprehension when connecting memory handlers that link the CPU to the discrete system.Time to learn by example. This tutorial will take you through all steps in creating a discrete sound emulation for Phoenix. You will learn how to interface the discrete sound code to the driver, and how the schematic is transcribed into discrete code. With lots of pretty pictures along the way. This is current as of MAME 104. You will find other c ode in the files mentioned in this tutorial. But if it has nothing to do with discrete programming, it will be ignored. You should also view the actual source files mentioned to get a better idea how it all fits together as a completed file. Well then, lets get started. The start of the game driver is in the srcdrivers folder. The driver file contains the basic structure linking all parts together. It contains the CPU memory maps, ROM info and information on how the rest of the system is hooked up.
Such as video, sound, inputs etc. All game sound code should be put in the srcsndhrdw folder. There is also a srcsound folder. This is for the various sound components used by a game`s sound hardware. So the game`s sound driver goes in srcsndhrdw but it will access routines from srcsound. You also should make a header file in the srcheaders directory for your game. In the header you will put declarations for routines, data and defines that will be used between the various files. First lets start the sound driver basics. We need to create the file in srcsndhrdw. We will call it phoenix. c. Then we need to start and end the discrete system. Also a name is needed to reference the discrete system. In this case "phoenix_discrete_interface". Don`t forget the includes at the start of the file. We need to add the interface name to the includesphoenix. h file so it can be accessed externally. We will also include the discrete header here so it will add the needed information for the discrete functions.
The DISCRETE_SOUND_START macro is really just setting up an array of type "discrete_sound_block". That is why it is declared that type in the header. Each node listed in a discrete sound emulation is just a member of the array. From the above code we can see that we start off with a speaker. Phoenix only had one. Then we tell the sound system we are hooking up a DISCRETE system called "discrete". The clock speed is set to 120000 samples per second. If this value is set to 0, the clock will run at the specified audio sample rate. This specifies how many times a second the electrical voltages are updated. Real world electronics has an infinite sample rate. But in simulation, more samples mean slower speed. In practice the audio sample rate is good enough for most discrete simulations. Except where a lot of voltages modulate against each other or frequency modulate other nodes. This is the case with Phoenix. So a higher sample rate is needed to increase accuracy and reduce waveform aliasing. Then we tell the sound system to configure our phoenix_discrete_interface. Finally any outputs from the discrete system are factored by a gain of 0. 6 and routed to the "mono" speaker we first defined. The 0. 6 gain helps to match the sounds to other Phoenix sound effects not shown. Now that the basics of the sound system are hooked up and talking to each other, we need to interface the CPU to the discrete system. This is done using the DISCRETE_INPUT modules. Now we start to need the schematics. The following schematic has the different sound circuits outlined into functional blocks. The amp stage is not really a concern. It is emulated by the MDRV_SPEAKER_STANDARD_MONO in the game driver. We also will not concern ourselves with the music circuit. This is a doorbell IC and it is emulated by the phoenix_tms36xx_interface. Time to name the input nodes to the discrete system and the final sound effect nodes. We could just use NODE_xx, but it is more readable to use names. If the memory handlers that connect the CPU to the discrete system were in se 🔗 External reference
To begin, the sound driver basics must be established by creating a file named phoenix.c in the srcsndhrdw directory. The discrete system must be initiated with a reference name, "phoenix_discrete_interface." It is essential to include necessary headers at the start of the file and to add the interface name to the includes in phoenix.h for external access. The discrete header should also be included to provide the necessary information for discrete functions. The DISCRETE_SOUND_START macro initializes an array of type "discrete_sound_block," with each node in the discrete sound emulation representing a member of this array. The initial setup includes defining a single speaker, as Phoenix utilized only one. The sound system is informed about the connection to a DISCRETE system labeled "discrete," with a clock speed set to 120,000 samples per second. If this value is set to zero, the clock will operate at the designated audio sample rate, determining how frequently electrical voltages are updated. While real-world electronics can have an infinite sample rate, simulation requires a balance between sample rate and speed. For Phoenix, a higher sample rate is necessary to enhance accuracy and minimize waveform aliasing due to significant voltage modulation. The sound system is then instructed to configure the phoenix_discrete_interface, with outputs from the discrete system processed by a gain of 0.6 and routed to the defined mono speaker, ensuring sound levels match other Phoenix sound effects.
Once the fundamental sound system is established, the next step is to interface the CPU with the discrete system through DISCRETE_INPUT modules. To facilitate this, schematics are required, outlining the various sound circuits into functional blocks. The amplifier stage is not a concern as it is emulated by the MDRV_SPEAKER_STANDARD_MONO within the game driver, nor is the music circuit, which is handled by the phoenix_tms36xx_interface. Input nodes for the discrete system and final sound effect nodes should be named for clarity, rather than using generic NODE_xx identifiers. This enhances readability and comprehension when connecting memory handlers that link the CPU to the discrete system.Time to learn by example. This tutorial will take you through all steps in creating a discrete sound emulation for Phoenix. You will learn how to interface the discrete sound code to the driver, and how the schematic is transcribed into discrete code. With lots of pretty pictures along the way. This is current as of MAME 104. You will find other c ode in the files mentioned in this tutorial. But if it has nothing to do with discrete programming, it will be ignored. You should also view the actual source files mentioned to get a better idea how it all fits together as a completed file. Well then, lets get started. The start of the game driver is in the srcdrivers folder. The driver file contains the basic structure linking all parts together. It contains the CPU memory maps, ROM info and information on how the rest of the system is hooked up.
Such as video, sound, inputs etc. All game sound code should be put in the srcsndhrdw folder. There is also a srcsound folder. This is for the various sound components used by a game`s sound hardware. So the game`s sound driver goes in srcsndhrdw but it will access routines from srcsound. You also should make a header file in the srcheaders directory for your game. In the header you will put declarations for routines, data and defines that will be used between the various files. First lets start the sound driver basics. We need to create the file in srcsndhrdw. We will call it phoenix. c. Then we need to start and end the discrete system. Also a name is needed to reference the discrete system. In this case "phoenix_discrete_interface". Don`t forget the includes at the start of the file. We need to add the interface name to the includesphoenix. h file so it can be accessed externally. We will also include the discrete header here so it will add the needed information for the discrete functions.
The DISCRETE_SOUND_START macro is really just setting up an array of type "discrete_sound_block". That is why it is declared that type in the header. Each node listed in a discrete sound emulation is just a member of the array. From the above code we can see that we start off with a speaker. Phoenix only had one. Then we tell the sound system we are hooking up a DISCRETE system called "discrete". The clock speed is set to 120000 samples per second. If this value is set to 0, the clock will run at the specified audio sample rate. This specifies how many times a second the electrical voltages are updated. Real world electronics has an infinite sample rate. But in simulation, more samples mean slower speed. In practice the audio sample rate is good enough for most discrete simulations. Except where a lot of voltages modulate against each other or frequency modulate other nodes. This is the case with Phoenix. So a higher sample rate is needed to increase accuracy and reduce waveform aliasing. Then we tell the sound system to configure our phoenix_discrete_interface. Finally any outputs from the discrete system are factored by a gain of 0. 6 and routed to the "mono" speaker we first defined. The 0. 6 gain helps to match the sounds to other Phoenix sound effects not shown. Now that the basics of the sound system are hooked up and talking to each other, we need to interface the CPU to the discrete system. This is done using the DISCRETE_INPUT modules. Now we start to need the schematics. The following schematic has the different sound circuits outlined into functional blocks. The amp stage is not really a concern. It is emulated by the MDRV_SPEAKER_STANDARD_MONO in the game driver. We also will not concern ourselves with the music circuit. This is a doorbell IC and it is emulated by the phoenix_tms36xx_interface. Time to name the input nodes to the discrete system and the final sound effect nodes. We could just use NODE_xx, but it is more readable to use names. If the memory handlers that connect the CPU to the discrete system were in se 🔗 External reference
Related Circuits
Face Through attendance is the world's first embedded facial recognition machine, with an error rate of less than one in one hundred thousand and a rejection rate of less than one percent. In the field of biometrics, this device...
To generate and maintain the endocochlear potential (EP), perilymphatic potassium ions (K+) enter fibrocytes (F) through the Na+/K+-ATPase and Na-K-Cl cotransporter. Gap junction networks connect fibrocytes to strial basal (SB) and intermediate (SI) cells, allowing ions to enter the...
The circuit is complete, and the bulb is ON. To turn OFF the bulb from the upper switch at the top of the stairs, simply turn OFF the switch, which will break the circuit and turn the bulb OFF....
Originally posted by Pano: "Like putting milk and sugar in your coffee. Next time by, your Turkish coffee comes with no sugar, Dave." The provided text appears to be an informal comment comparing the addition of sugar and milk to...
This circuit transforms a tape recorder into a fully automatic device for recording telephone conversations without requiring an external power source. The voltage at the switch terminals of the tape recorder is applied to a pair of Darlington-connected transistors,...
The GPS is based on 24 satellites located in six orbital planes at a height of 20,200 km and circle the Earth every 12 h. Each plane is inclined at 55 to the Earth’s equator and contains four satellites....