mw8080bw: new netlist audio implementation for gunfight
Another reason why newer versions of MAME are worth the upgrade since old external audio samples are no longer needed when using newer versions of MAME. Only reason audio sample should be kept around is for anyone using older versions of MAME. iirc I thought former MAMEdev Derrick Renaud had edited the old Boot Hill external audio samples to play only the sound effects that were used with Gun Fight sometime between 2006 to 2009 when he did updates with Midway 8080 hardware. That is what I recall.
- New netlist-based audio implementation for gunfight (Gun Fight, 1975), derived from Midway audio schematics. Sound checked against several YouTube videos and seems to match, apart from acoustic effects of cabinet. (Sorry, I don't have a Gun Fight machine of my own to check.
Removed the old sample-based sound, which is no longer necessary. (The samples for that version were actually from the newer game Boot Hill and didn't match Gun Fight's sound hardware; they even included Boot Hill's funeral march tune!)
Although the netlist version has much greater overhead, performance is still acceptable on modern hardware.
* mw8080bw: remove unnecessary trampolines from gunfight netlist audio --
Informative details about the Gun Fight audio components used for generating the sound effects.
iirc when someone had asked Derrick Renaud about why Gun Fight audio wasn't going to be worked on after Boot Hill was done, was the audio components with Gun Fight would be far more involved compared to Boot Hill. This was when Derrick was trying to cover as many games as possible that work could be duplicated in several games such as Atari auto racing games that utilized same 'crash' sound effects. MAME users were fortunate that Derrick had time to work on games back then especially the Atari Asteroids audio sounds that almost all the users had been complaining about from years 2001 to 2004 until Derrick Renaud fixed Asteroids audio around 2004 or 2005. Asteroids audio was the second biggest gripe/complaints while first biggest gripe was Aaron's Sega changes to popular Sega games Outrun, Hangon, etc that started in fall of 2000 and was not completed until spring 2006 after Charles/Guru/Aaron/Nicola/dwidel and many others figured out MC8123, FD 1089 and FD 1094 hardware used with some of the Sega games.
Good to see Gun Fight get netlist work. I won't be surprised with Midway Sea Wolf analog audio being last Midway 8080 game to be worked on because Sea Wolf also uses a truckload of components compared to other Midway 8080 hardware games.
mw8080bw: new netlist audio implementation for 280zzzap
New netlist-based audio implementation for 280zzzap (280-ZZZAP, 1976), derived from Midway game logic board schematic.
This netlist, with some modifications for differences in components and circuits, should also be able to support Laguna Racer and Super Speed Race. -
While lurking/visiting Bannister's shoutbox...
Colin Howell: speaking of PCB photos, are there any good photos of Midway's 280-ZZZAP game logic board (the one with the sound circuits)? It seems hard to find good-quality PCB photos online, but maybe people hide them to deter eBay scammers and suchlike... Colin Howell: (it would also be nice if a copy of the game's parts catalog could be scanned and made available, so as to compare the PCB physical layout schematic with the functional schematic and check for discrepancies. Colin Howell: I know such a catalog exists, but even though the game logic board functional schematic has been scanned, the full catalog apparently never has.
....and for those that have time to forward info over to Bannister's forum.
Those glossy 1970s era Midway parts catalog only have the cab parts and pieces. The pcb components pages are usually on separate letter size paper, stapled together with listing components and indicating what each component is on the pcb and then resistors, capacitors, xtal....etc
Andy Welburn's site and business store and it appears Andy has everything for that particular Midway 8080 product.
> While lurking/visiting Bannister's shoutbox... > [snip] > > ....and for those that have time to forward info over to Bannister's forum.
Heh, you're lurking, I'm lurking. Saw your postings about my recent contributions. Thanks for the support.
Also, I see you've sent me a bunch of PMs. Sorry for not responding, but this is the first time I've logged in to this account in quite some time. I had been lurking without logging in, so I had no clue I was getting PMs.
> Those glossy 1970s era Midway parts catalog only have the cab parts and pieces. The > pcb components pages are usually on separate letter size paper, stapled together with > listing components and indicating what each component is on the pcb and then > resistors, capacitors, xtal....etc
I realize that might be the case. However, the Laguna Racer parts catalog scan at arcarc.xmission.com, from 1977, does include PCB layout schematics. Only the functional schematics are separate. 280-ZZZAP, being a year older, might be different, but I figured it's worth a shot. It's a bit odd that no scan of its parts catalog is available, even though the functional schematic of the game logic board has been scanned.
> Andy Welburn's site and business store and it appears Andy has everything for that > particular Midway 8080 product.
Noted. Do you think I should contact him, or what?
>you're lurking, I'm lurking. Saw your postings about my recent contributions. Thanks for >the support.
Antny and I are fans of the work since he and I are/were old enough to have played the Midway 8080 games back during 1970s decade when they were at arcades and places back then. There would be others if they were still around following emulation.
>I see you've sent me a bunch of PMs. Sorry for not responding, but this is the first time >I've logged in to this account in quite some time. I had been lurking without logging in, >so I had no clue I was getting PMs.
Nah. I figured that would be the case.
>I realize that might be the case. However, the Laguna Racer parts catalog scan at >arcarc.xmission.com, from 1977, does include PCB layout schematics. Only the functional >schematics are separate. 280-ZZZAP, being a year older, might be different, but I figured >it's worth a shot. It's a bit odd that no scan of its parts catalog is available, even >though the functional schematic of the game logic board has been scanned.
As for distributed paperwork, I agree there were some changes over the 1970s years for the Midway paperwork. I am not sure what 280-ZZZAP would exactly consist of compared to say Midway Clowns paperwork or Midway SI paperwork. One would be lucky if they had all the paperwork intact. As decades go by, a lot of the stuff disappears or lost over time so it is usually just the glossy cover parts catalog remains while all the other specific paperwork is gone. Fortunately Andy appears to have all the 280-ZZZAP stuff.
>> Andy Welburn's site and business store and it appears Andy has everything for that >> particular Midway 8080 product.
>Noted. Do you think I should contact him, or what?
Andy has contributed over the years so hopefully he has a pcb components list page on hand.
Colin, I wanted to personally thank you also. I'm sure reading, interpreting and then converting schematics to net-list is probably tedious at best. I look forward to the next release to finally hear sounds in 280 Zzzap. Greg & I are very close in age so we have a lot of the same memories. Fortunately he will always be older than me He's is my brother from another mother and we discuss the whole net-list thingy often.
It's nice to see poor courriersud get some help (along with Aaron and MG). I know the net-list process is more than just programming. Knowledge of electronic components is a must to make this happen. The scale of the whole thing is mind boggling.
Keep up the great work. I look forward to anything else you contribute.
> I'm sure reading, interpreting and then converting schematics to net-list is probably tedious at best.
Actually, that's not the worst part of the process. Yeah, I suppose it can get a little tedious, but it tends to be straightforward once the parts in question have been described, and you can learn about the functioning of the circuit as you go. Plus you don't have to do it all at once; you can focus on a portion of the circuit, get that working, and then concentrate on a different section.
The real source of potential heartache and frustration is when you have completed the netlist and then find that it won't emulate at reasonable speeds without serious work. Much of the trouble I had with 280-ZZZAP was due to this. Several of the oscillator circuits are numerically unstable, and it was hard to get the solution process to work without making it so slow as to be useless. We also had to figure out how to emulate LM3900 op-amps more efficiently; they are a bit peculiar. There was a lot of trial and error involved.
> I know the net-list process is more than just programming. Knowledge of electronic components is a must to make this happen.
Indeed, I had to learn a lot about analog electronics even to get to the point where I could do this, and I've been learning still more in the process.
> Keep up the great work. I look forward to anything else you contribute. > > Thanks again
>Greg & I are very close in age so we have a lot of the same memories. Fortunately he will >always be older than me. He's is my brother from another mother and we discuss the whole >net-list thingy often.
>Several of the oscillator circuits are numerically unstable, and it was hard to get the >solution process to work without making it so slow as to be useless. We also had to figure >out how to emulate LM3900 op-amps more efficiently; they are a bit peculiar.
You also had the issue of the datasheet misprint in one of the parts books and had to search an earlier issue of a catalog to get exact values or connections iirc in order to begin creating components before working on the Midway game. This is what Derrick Renaud had predicted in his 2004 MW post when he gave his view of what issues might be involved of emulating non-cpu games back at the time. Fortunate that this work will enable other Midway 8080 racing games to have analog audio later.
> > Several of the oscillator circuits are numerically unstable, and it was hard to get the > > solution process to work without making it so slow as to be useless. We also had to figure > > out how to emulate LM3900 op-amps more efficiently; they are a bit peculiar. > > You also had the issue of the datasheet misprint in one of the parts books and had > to search an earlier issue of a catalog to get exact values or connections iirc in > order to begin creating components before working on the Midway game. This is what > Derrick Renaud had predicted in his 2004 MW post when he gave his view of what issues > might be involved of emulating non-cpu games back at the time. Fortunate that this > work will enable other Midway 8080 racing games to have analog audio later.
Yes, the Motorola MC3340, where the new schematic had component values but a missing connection, while the old one had no values but correct connections (and also a couple extra diodes, one of which later turned out to make a difference in the chip's control response).
Incidentally, I think it's a good idea in general to check all the datasheet/manual versions of a part or system that you can, because you never know when you might come across discrepancies or changes like this.
Always good to see some fine tuning when necessary for the games that use analog audio hardware for generating the audio sound effects. It is interesting that maybe some of the pcbs had been repaired using different components which could be why some sound effects have a different pitch frequency etc. That was one of the things that Gyrovision (Chris L.) had mentioned to me when he was working on his Congo Bongo pcb and had noticed that previous/prior pcb work from a pcb owner had used wrong parts when repairing Congo Bongo pcb. Gyrovision repaired the Congo Bongo pcb to parts shown on Congo Bongo service manual. After the repair work was completed, the game sounded the way he recalled it should sound since this was a game he liked himself. He then made audio recordings for external audio samples and sent to MAMEdev. This was many years earlier between 2006 to 2009 iirc.
*from Bannisters* -- Colin Howell: ok, some weirdness... Colin Howell: I was looking over Gun Fight again, after doing the 280-ZZZAP work, to see if I might want to do any tweaks (for example, a proper emulation of its noise generator using netlist's new Zener and noise modules) Colin Howell: and I checked over the transistor models again (Vas had remarked that I didn't pick a specific BJT type, and I'd replied that the actual type used was kind of obscure) Colin Howell: So I looked at that transistor again, the Amperex A-138, and the small amount of info I have on it. Colin Howell: It seems like the BC548C would be an OK substitute; from the parameters for the A-138 I do have, the BC548C comes pretty close. Colin Howell: Here's the thing... Colin Howell: The default NPN I was using has a current gain of 100 (collector current is 100 x base current). Colin Howell: The BC548C model has a gain of 466. Colin Howell: For actual transistors, the gain is a range; it varies from one device to another. For the A-138, max gain of 650 is listed. Min is not, but the next lower grade (A-137) has a max of 415, so A-138's min should be around 400. Colin Howell: Turns out, if you use transistors of gain 400-500 in the Gun Fight circuits, it doesn't just boost sound effect volume, as you might guess. It significantly changes the shot sounds. Colin Howell: Because when a shot sound starts, its amplifying transistor first *saturates* for the initial attack, when the switch is on. You get a pulse, then silence as the transistor output is forced low. Colin Howell: Then, when the switch goes off and the current drops a bit, the transistor leaves saturation and returns to the linear forward-active region... Colin Howell: ... and then it starts amplifying normally, so now you hear amplified noise. R. Belmont: interesting, and it makes sense once you explain it. Colin Howell: The effect is an initial crack, a momentary pause, and then a noise burst that decays. Colin Howell: For a while I was thinking I'd found some sort of modeling bug, but I got the same effect simulating the circuit in LTspice. Colin Howell: But this only happens when you use high-gain transistors (say, 400-500). Low-gain ones (say, 100-200) won't do this. R. Belmont: It's good that LTspice confirmed our behavior. Colin Howell: Which makes me wonder if some people who've repaired their Gun Fight sound boards and replaced the hard-to-find A-138s might have changed their shot sounds without knowing it. Colin Howell: Because when I check videos, I think I hear this effect in some but not in others. Colin Howell: (it seems pronounced in my simulation but hard to catch in the videos.) R. Belmont: Colin: part of that is that most videos are micing a cabinet, which can do weird things to the frequency response. Colin Howell: yup. I'm thinking of asking on the arcade-museum forums to see if anyone there with a Gun Fight can comment. Colin Howell: also, since it seems BJTs can lose gain over time, could Gun Fights with their original transistors lose this effect as they age... R. Belmont: Absolutely. Plus old capacitors get leakier over time and can short, and at least some kinds of resistors will drift (usually upwards) -
>I see you caught that. I was thinking of mentioning that issue over here if you didn't bring it up first.
I never know when the topics scroll off shoutbox feed. I didn't want to chance it. When Augusto used to post on Bannisters shoutbox, a lot of the stuff would scroll off within a matter of minutes.
The Gun Fight parts discussion brought back memories with Gyrovision and his repair work with Congo Bongo pcb and I used Congo Bongo as a past example.
* Posting this on old thread since it is netlist (analog audio) related *
Thanks to everyone [Aaron, couriersud, Frank Palazzolo, other contributors/cab owners?] for making this a reality.
Hard to believe it was maybe close to twenty years earlier when the server that hosted Retrocade stopped working and then Retrocade emulator was gone and the fans of Cinematronics Armor Attack were bemoaning the loss of audio sounds of Armor Attack as similar as if it were an artifact that could never be replaced. Thankfully that sentiment was gone since it would eventually be known that the analog audio schematics info was printed on Cinematronic Armor Attack service manuals. Those old discussions had to have been on Gridle's old MAME.net forum back in 2001 and 2002 years so at least folks knew that things were not lost. Eventually new external audio samples would be added over the past several years to existing source code so the various Cinematronic and Vector Beam games would still have external audio samples......until the 'real thing' would come along and replace external audio sample recordings.
Nice to know this is finally what happened and what it would require to get things correct regarding Cinematronics and Vector Beam games analog audio outputs.
Added netlist-based audio to early Cinematronics vector games (#6979)
Added netlist simulations for the following games: Space War, Barrier, Star Hawk, Speed Freak, Star Castle, War of the Worlds, Sundance, Tail Gunner, Rip Off, Armor Attack, Warrior, Solar Quest, Boxing Bugs. Removed previous samples-based sound. [Aaron Giles, Couriersud] -
It will be great to have Cinematronics Star Hawk to finally have the 'laser' high score sound effect finally be played correctly. Back in early 1980s when Cinematronics games were at arcades and maybe a working Star Hawk cab was in the arcade, I would recognize that particular sound effect when maybe at a distance of 25 to 50 yards away and would know that a working Star Hawk cab was nearby. There are particular coinop games sound effects that are easily memorable even if a long time has gone by. Great to have MAME finally have the Cinematronics and Vector Beam analog audio being 'run' correctly (no external audio samples).
For the younger generation or new visitors, this Cinematronics work is the road map of what will need to be done for Sega VIC DUAL hardware games because the particular Sega games also make use of an extra add-on audio board that generates analog audio sound effects just like what Cinematronics and Vector Beam cabs use.
Hey now that is exciting news! I may just have to get myself a nightly build.
btw: Star Hawk samples were updated by me several years ago to fill in for the sounds you mentioned. Did you miss out all these years? I had intended to update Solar Quest but, no need now.
Incredible work by the team. To say it is monumental is be an understatement. Thank you to all involved with the net-list progress. There is nothing more satisfying than hearing a silent game come to life.
Does anyone know of a list of schematics that are "on hand" and ones that are needed?
Is there a net-list dev wish list for schematics?
I wonder where we are with the whole NL picture. Is the "framework" pretty much done?
It's great to see courriersud's vision come to life.
And finally Aaron 28748 lines of code? What a slacker
Does anyone (website) still do that these days? I can see simple single driver regular builds by users, but a nightly full compile build? I give credit if someone is still doing daily full compile builds. Maybe once per week, but on a daily basis.
>btw: Star Hawk samples were updated by me several years ago to fill in for the sounds you >mentioned. Did you miss out all these years?
I would have enjoyed that [using Star Hawk audio], but my 2003 Sony Vaio computer was just barely able to run games that used external audio samples let alone Aaron's great video rendering rewrite from 2006. Even running Midway Amazing Maze with Derrick Renaud's discrete audio work for the game in 2007 made the computer crawl when trying to play the game back then. Only times I might try and test/run MAME on very rare occasion was when Pong and Breakout were added. The latest version that my computer could run is .179 and that is it.
If the high score 'laser' sound effect from Star Hawk was playable in MAME, that is impressive because I didn't believe that sound effect could be supported as an external audio sample.
>I had intended to update Solar Quest but, no need now.
Moe, Larry, and Curly can't sleep because they are spooked the ghost they see that really is a bird with scull on it's body.
>Does anyone know of a list of schematics that are "on hand" and ones that are needed? >Is there a net-list dev wish list for schematics?
Unfortunately it is more than schematics by themselves because of possible misprints in some of the drawings. Access to actual hardware needed as well to verify/test such as what Colin had to do with Midway 280zzzap analog audio. And there were odd examples such as when Chris L./Gyrovision had to repair actual Congo Bongo pcbs in 2009 in order to undo a previous piss poor repair job with the Congo Bongo pcbs just to get pcb in working shape to do audio recording for external audio samples of the game.
Leaving out non-cpu games and only games with analog audio, start with Exidy, Midway, Ramtek, Meadows, Sega vicdual and Atari and anything from 8080bw.cpp and that will be a list by itself.
>I wonder where we are with the whole NL picture. Is the "framework" pretty much done?
Unsure about the 'foundation/framework' core code, but the device components list has to still be lengthy by itself.
> > And finally Aaron 28748 lines of code? What a slacker > > *Moe Howard slaps Antny on back of head*: "Hey. Wake up and go to sleep again."
To be fair, most of that is from src/lib/netlist/generated/static_solvers.cpp, which is a machine-generated file to allow the solvers for the circuit equations to be compiled in advance rather than generated at runtime; that makes the solver run quite a bit faster. On the other hand, if I'm reading this pull request report right, Antny's total seems to have missed some major chunks of human-written code, so it looks like Aaron really did write nearly 10,000 lines for this. Wow. Just, wow.
> > Does anyone know of a list of schematics that are "on hand" and ones that are needed? > > Is there a net-list dev wish list for schematics? > > Unfortunately it is more than schematics by themselves because of possible misprints > in some of the drawings. Access to actual hardware needed as well to verify/test such > as what Colin had to do with Midway 280zzzap analog audio.
But having schematics is a hell of a lot better than working without them. They should be verified and may have to be corrected, sure, but trying to do this strictly from photographing and tracing boards? Yikes!
> > I wonder where we are with the whole NL picture. Is the "framework" pretty much done? > > Unsure about the 'foundation/framework' core code, but the device components list > has to still be lengthy by itself.
Basic framework is clearly done enough to use, but couriersud still has plenty of ideas for improvements and expansion.
Thanks for your recent improvements Colin. I cannot wrap my brain around how you can take voltage, current flow, resistance, etc. and put it in code form and then create accurate sounds on a computer. Mind boggling I tell ya. Maybe we really are in The Matrix.
Can the current state of the net-list code support video also or is that a totally different animal?
Keep up the great work. I look forward to whatever you tackle next.
> Thanks for your recent improvements Colin. I cannot wrap my brain around how you can > take voltage, current flow, resistance, etc. and put it in code form and then create > accurate sounds on a computer. Mind boggling I tell ya. Maybe we really are in The > Matrix.
I don't want to be facing any dudes in sunglasses with attitude problems.
couriersud did the real work to make this possible; I'm just exploiting what he built. Which is as he intended--the idea of netlist is to allow programmers who aren't deeply experienced in simulating analog circuits to simply create a representation of the circuit to be simulated and let netlist's circuit-solving engine do the rest.
The computing techniques behind this actually go back to the 1970s at least, with the development of programs like Berkeley's SPICE (still in use today in improved forms) for simulating the detailed operation of electronic circuits. It's just taken a while for computers to advance to the point where relatively complex circuits like you might find in a 1970s or 1980s game machine could potentially be simulated as fast as they operated in reality.
Hell, if you want to trace the idea back further, it goes all the way back to ENIAC of 1945, built to calculate exactly where artillery shells would land when fired, and able to calculate a shell's trajectory faster than the real shell itself would fly--an amazing feat in 1945.
> Can the current state of the net-list code support video also or is that a totally > different animal?
Yes, and that is how MAME currently handles a few games, like Pong and Breakout, which are implemented entirely in TTL logic without a CPU. It's probably the only way to accurately emulate such games. Video is a lot harder, as you might imagine, because the circuits must work much faster. I don't really know the details of how MAME handles such netlists, only that they use the same system.
> Keep up the great work. I look forward to whatever you tackle next.
> > I may just have to get myself a nightly build. > > Does anyone (website) still do that these days? I can see simple single driver > regular builds by users, but a nightly full compile build? I give credit if someone > is still doing daily full compile builds. Maybe once per week, but on a daily basis.
We've also been working on adding more continuous integration through Github Actions or maybe Azure Pipeline, in addition/replacement of Travis-CI and Appveyor. If we can get it to complete the build during their respective time limitations, and also if we can get it to build the complete build and not a scaled down version, then those builds -might- be end-user accessible going forward. We'll see. I've seen these sort of test builds become accessible on other projects before.
But all that is really intended more for checking whether a new contribution will break the build though, and we really don't want casual users experimenting with highly untested pre-release builds.
>> Can the current state of the net-list code support video also or is that a totally >> different animal?
>Yes, and that is how MAME currently handles a few games, like Pong and Breakout, which are >implemented entirely in TTL logic without a CPU. It's probably the only way to accurately >emulate such games. Video is a lot harder, as you might imagine, because the circuits must >work much faster. I don't really know the details of how MAME handles such netlists, only >that they use the same system.
Interesting odd case example is back in Oct. 2016 when a computer system was being worked on. The computer system uses a cpu while the video board required components to be added in order to support video. Moogly eventually worked on Atari Stunt Cycle a bit later in 2016. Some of the Hazeltine 1500 components work eventually made its way to netlist section as source code shows.
>To be fair, most of that is from src/lib/netlist/generated/static_solvers.cpp, which is a >machine-generated file to allow the solvers for the circuit equations to be compiled in >advance rather than generated at runtime; that makes the solver run quite a bit faster.
I was wondering what that feature was for, but had not yet asked about it.
>On the other hand, if I'm reading this pull request report right, Antny's total seems to >have missed some major chunks of human-written code,
Antny and I exchange 'unfunny/sarcasm' bits here and there....but...
>so it looks like Aaron really did write nearly 10,000 lines for this.
...yep...definitely many lines of code updates involved to get almost all the games analog audio updated. If the similar arrangement (all games done at once instead of piecemeal) is done for games in src/drivers/vicdual.cpp imagine how many extra lines of code being manually added for all of the vicdual hardware games. That would be for analog audio work only, but then add along maybe some video rewrites for some of the games and then further video update/improvements for games like N-Sub. I am guessing analog audio specific work first if and when that ever happens.
>> Unfortunately it is more than schematics by themselves because of possible misprints >> in some of the drawings. Access to actual hardware needed as well to verify/test such >> as what Colin had to do with Midway 280zzzap analog audio.
>But having schematics is a hell of a lot better than working without them. They should be >verified and may have to be corrected, sure, but trying to do this strictly from >photographing and tracing boards? Yikes!
Back around 2007 or 2008, Frank Palazzolo had dumped proms from a Ramtek Trivia pcb even though it is a non-cpu game. Frank considered maybe looking into adding preliminary non-cpu support of MAME running non-cpu games back at the time, but Ramtek Trivia logic schematics would be needed. iirc this was around same time that Aaron and many others involved of rewriting MAME core code to treat CPUs as just as if the cpu were an add-on component just like ttl chips etc (somewhat similar to idea of pcb being a blank drawing canvas) and getting components added to pcb whether a cpu was used or not.
The guess regarding Ramtek Trivia logic schematics is maybe Ramtek Trivia would not be as complicated compared to Pong emulation. The logic schematics for Ramtek Trivia was three or four sheets and it looks even scarier compared to Pong schematics. I need to get that scanned and online like what was done with For Play games schematics and Meadows Bombs Away back in 2018.
iirc I mailed copies of that along with other copies of other Ramtek schematics of other Ramtek games to Frank back around maybe 2010 or 2011. I wasn't sure when non-cpu emulation would happen, but I am glad 'siftware' had been able to dump many of the roms and proms from non-cpu games when he and I met back in years 2006 to 2009.
> "but trying to do this strictly from photographing and tracing boards? Yikes!"
This is what had to be done just for analog audio from a Spiders pcb back around years 2007 to 2009. There were hardly any decent logic schematics for Spiders audio. One of the contributors bought a Spiders pcb, then traced analog audio circuits to create handdrawn logic schematics for audio output. Mailed the handrawn logic schematics to Hans Andersson in Sweden and Hans did the analog audio work for Spiders to be in MAME back then.
As for non-cpu video games the tracing work might have to be done for pong clone Bailey's Fun Four (uses proms that have been already dumped and documented in MAME source). I am guessing most will say not worth the time even if it is a pong clone.
> As for non-cpu video games the tracing work might have to be done for pong clone > Bailey's Fun Four (uses proms that have been already dumped and documented in MAME > source). I am guessing most will say not worth the time even if it is a pong clone.
I have this board, harness, and the rest of the hardware out of a rotted cocktail, although I'm not sure if it works (the monitor was dead, and it didn't play blind, unless the speaker was shot). It's a bit more than just a standard Pong clone, having four different games, and I'm a bit intrigued by the Targets game. I thought of wiring it up to a standard CRT TV, but it uses the monitor regulation (which IS good on the monitor) to supply the 5v that the board needs. No isolation transformer in this one. I'll have to see if there's high voltage present at the flyback (there is neck glow), and replace the HV diode if so, IF I can find one...
"One of these days, I'm going to cut you into little pieces!"- Nick Mason, Pink Floyd
>> As for non-cpu video games the tracing work might have to be done for pong clone >> Bailey's Fun Four (uses proms that have been already dumped and documented in MAME >> source). I am guessing most will say not worth the time even if it is a pong clone.
My bad. It was the first product that came to mind as an example since I haven't found anything else other than the main pcb. iirc I purchased pcb from a seller in Lawndale, CA along with another item. The seller thought he had the instructions plate, but couldn't find them. The cocktail table was missing when he bought those items a few years earlier from another seller.
>I have this board, harness, and the rest of the hardware out of a rotted cocktail,
If that still has instructions plate on the side, I can see a need of that being scanned in the future.
>although I'm not sure if it works (the monitor was dead, and it didn't play blind, unless >the speaker was shot). It's a bit more than just a standard Pong clone, having four >different games, and I'm a bit intrigued by the Targets game. I thought of wiring it up >to a standard CRT TV, but it uses the monitor regulation (which IS good on the monitor) >to supply the 5v that the board needs. No isolation transformer in this one. I'll have to >see if there's high voltage present at the flyback (there is neck glow), and replace the >HV diode if so, IF I can find one...
Does this use some add-on pcb to send signals to main pcb of what selections the player had chosen such as what game, size of paddles, number of players etc? Another of the multi games uses such a pcb for setting up the game options that a player selects before game begins.
src/mame/drivers/bailey.cpp is missing a lot of hardware info. Hopefully that can be filled up over time.
> Colin or others, > > Are there any resources online, youtube videos or documentation detailing the step by > step process of how this is done?
I feel bad for having to give an answer like this, but there really isn't much, except for some basic documentation mixed with the netlist source code and some netlist example files (many of which have gotten stale and will need some tinkering to run). Of course, there are the existing MAME netlists to follow--look for nl_*.cpp files in src/mame/audio and src/mame/machine. But the learning curve is still quite steep--you have to be willing to go with the barest of guidance, get your hands dirty and experiment.
Experience with other circuit simulators, such as one of the SPICE versions, can be useful. SPICE's learning curve is even steeper than netlist, but it has been heavily documented over the years. Paul Falstad's neat little online Javascript simulator (http://www.falstad.com/circuit/ or http://lushprojects.com/circuitjs/) is an excellent way to help learn about how these things work, as long as you keep its limitations in mind.
> I would really like to better understand how this works and if it doesn’t hurt my > brain to much, contribute. > > TrevEB
I am so very impressed to hear Boxing Bugs! I have tried to get the sound samples for this title for ages but my friend's machine has been down for years. No need anymore. Amazing!
Solar Quest: I had made recordings but hadn't gotten around to cleaning them up. Also played blind so I was just guessing. Awesome!
Star Hawk: There is a rhythmic boom boom boom boom that I have never heard before. Going to have to see what the real cabinet has to say about that. I have no doubt it is there. Just never heard it before when playing at Rye Playland all those years ago
Speed Freak: Oh really, so there are more sounds than just sreech! Nice!
> >> As for non-cpu video games the tracing work might have to be done for pong clone > >> Bailey's Fun Four (uses proms that have been already dumped and documented in MAME > >> source). I am guessing most will say not worth the time even if it is a pong > clone. > > > It's a bit more than just a standard Pong clone, > > Flyer links > > https://www.flyerfever.com/search/bailey > > https://www.flyerfever.com/post/98368107788/fun-four > > My bad. It was the first product that came to mind as an example since I haven't > found anything else other than the main pcb. iirc I purchased pcb from a seller in > Lawndale, CA along with another item. The seller thought he had the instructions > plate, but couldn't find them. The cocktail table was missing when he bought those > items a few years earlier from another seller.
> If that still has instructions plate on the side, I can see a need of that being > scanned in the future.
Yep... mine still has the plate, with all of the buttons, rocker switches, and printing intact.
> Does this use some add-on pcb to send signals to main pcb of what selections the > player had chosen such as what game, size of paddles, number of players etc? Another > of the multi games uses such a pcb for setting up the game options that a player > selects before game begins.
Nope. The game selector just an 8-position pot, of which the last four selections are jumpered to the first four. The options are chosen by individual rocker switches for bat size per player, bat size, and Player vs Player/Player Vs Machine. There's also a start button. My cabinet currently has a 19" TV in it, with a PCB running the AY-3-8500-1 IC; the PCB of which I had fabricated from a French design. I didn't modify the control panel at all, but replaced the pots (which are tested bad) with 1M pots for my PCB, and wired the control panel to my PCB, with the reset line hooked up to a coin switch. The cabinet doesn't move from its spot in my game room, as it would probably crumble if I moved it again.
I have pictures if needed, and I kept all of the hardware and harness from the original game. Here's one of the control panel from an angle, post-mod, but before I printed new identifying vinyl labels for the switches for my mod. I can remove the vinyl and take more pics if needed.
Here's the rear of the control panel. the four player pots are in each corner of the cabinet, so you won't see them here:
Here are the PCB and jumper block wiring for my mod, with termite and water damage in the cabinet in tow:
> The cabinet doesn't move from its spot in my game room, as it would probably crumble if > I moved it again.
Aaaghh. Gotta keep that sucker bolted down. At least until lots of photos and measurements and all that good stuff is first completed.
>I have pictures if needed, and I kept all of the hardware and harness from the original > game. Here's one of the control panel from an angle, post-mod, but before I printed new > identifying vinyl labels for the switches for my mod. I can remove the vinyl and take >more pics if needed.
Photos of all sides of the table, interior too, interior wiring hookups, monitor itself, since that table is a rareity in this day and age, but you already have a good start with these photos.
I forgot that 'fever' created an entry for Bailey a long time ago so that is a good place as any to document the table although in MAME source code just as well.
>> If that still has instructions plate on the side, I can see a need of that being >> scanned in the future.
>Yep... mine still has the plate, with all of the buttons, rocker switches, and printing >intact.
Definitely either a scan of the plate or a high quality photo of it would be useful whenever that can be done later.
>> Does this use some add-on pcb to send signals to main pcb of what selections the >> player had chosen such as what game, size of paddles, number of players etc? Another >> of the multi games uses such a pcb for setting up the game options that a player >> selects before game begins.
>Nope. The game selector just an 8-position pot, of which the last four selections are >jumpered to the first four. The options are chosen by individual rocker switches for bat > size per player, bat size, and Player vs Player/Player Vs Machine. There's also a start > button. My cabinet currently has a 19" TV in it, with a PCB running the AY-3-8500-1 IC; > the PCB of which I had fabricated from a French design. I didn't modify the control > panel at all, but replaced the pots (which are tested bad) with 1M pots for my PCB, and > wired the control panel to my PCB, with the reset line hooked up to a coin switch.
Good info there and definitely worth putting in Bailey source code.
It was these that I recall posting here on MW a long time ago. The old posts are long gone. I have the logic schematics for some of the models. With MAME all combined with MESS these days, the URL products could fit in one source file even though one uses coin credits and the other is home model (no coin inputs).
>Star Hawk: >There is a rhythmic boom boom boom boom that I have never heard before. >Going to have to see what the real cabinet has to say about that. I have no doubt it is >there. Just never heard it before when playing at Rye Playland all those years ago
*envious.....while typing on extremely out-of-date 2003 Sony computer that used to be able to run MAME*
But the enemy ships never fire. Is this just a one off event? Is there a score that must be achieved before this happens or is it just high score for the day? Or do 2 people have to play?
>But the enemy ships never fire. Is this just a one off event? >Is there a score that must be achieved before this happens or is it just high score for the >day? Or do 2 people have to play?
I was corrected and informed about video clip which I thought came from an actual Star Hawk cab, but was emulation.
-- As far as Starhawk is concerned, in my quick checking of your video which is clearly a version of MAME using samples against current build, I notice nothing missing with sound effects. -
[MAME emulation] of Star Hawk (1979) by Cinematronics
-- From what I can tell the comment in the nl_starhawk.cpp file is old (to be deleted). A prom is loaded in the ROM_START of the driver file and is not labeled bad dump - so I assume all is well. -
And then got the Ashton Kutcher "Punked" treatment with a supposed out-of-date comment from the source file src/mame/audio/nl_starhawk.cpp getting the best of me.
And with tv character Emily Litella's statement of "...they'll play guitar and bongo drums...."
here are some 'bitchn' musical pieces (Bachi and also Guarabe) from Clare Fischer - Salsa Picante (Discovery, 1980) Full Album [Latin Jazz] with drummers and best damn bongo players ever: Poncho Sanchez and Alex Acuna.
Namco's "Tank Battalion" now has netlist audio as well.
The sample support for it was particularly bad, since the engine sound was implemented as a looping sample, and the sample itself didn't loop cleanly, so there was a subtle 'pop' every time it looped back again. No more of that.
Thanks MG. I compared the net-list stuff to the samples and there is a huge difference. The net-list stuff sounds so smooth and fluid (for lack of better words).
I applaud you for stepping out of the traditional emulation zone and tackling the net-list stuff, vey impressive.
>Namco's "Tank Battalion" now has netlist audio as well.
>The sample support for it was particularly bad, since the engine sound was implemented as a >looping sample, and the sample itself didn't loop cleanly,
Good teamwork with your audio work and AJR's partial rewrite of late 1990s era code to get the game emulation updated to .22x standards.
And also to Colin's Midway 280zzap 'engine noise' fix/update.
As for already emulated cpu controlled Exidy games, although Car Polo is the ultimate Exidy analog audio challenge, I can see either Star Fire, Fire One, or Circus getting applause if any are able to be fixed. Of those Exidy games, I remember playing the cabs/cockpits of Star Fire and Circus. I believe Disneyland (Anaheim,CA) had a Exidy Car Polo cab on upper level of Star Cade arcade in late 1970s (never played it). I don't recall ever seeing a Exidy Fire One cab.
Good luck with whichever game gets next analog audio work updated.
I was wondering about Star Cruiser status and now see why the game still has Imperfect sound status. Still an improvement compared to relying on external audio sample recordings.
- -starcrus: Added netlist sound
audio/nl_starcrus.cpp
Netlist for Star Cruiser
+// Derived from the schematics in the Star Cruiser manual. +// Known problems/issues: +// * Uses HLE noise due to abusing a 2N4124 in breakdown as a noise source. -
Oh, Star Cruiser should sound effectively identical to real hardware, I just forgot to remove the flag at the time. But since it does use HLE noise, I think I'll leave it.
Getting there. Those gaps in the playfield seem to correspond exactly to when PFLD should be pulsed. I suspect I'm not using a small enough minimum dynamic timestep, so by the time the R/C pulse generator connected to 32H has time to spike, we've missed a couple of pixels. -
And Aaron doing analog audio sounds for soccer game Dribbling.