Jump to content
Due to a large amount of spamers, accounts will now have to be approved by the Admins so please be patient. ×
IGNORED

Williams SS sound board synth


Recommended Posts

Hi there, i am currently playing around with some Williams Sys 4-7 sound boards and various ROMS all with the idea of turning them into some sort of 8 bit synthesizer. Not sure if this is the place to post this, or even if theres any interest in this, so I will just put a pic here and if anyone's curious then I can post some more.

ta,

kapGo

2card-breadboard.thumb.jpg.bcaef358dd463358c177785afc69e750.jpg

Link to comment
Share on other sites

Well i got interested in this from the Williams sounds that came out of the classic arcade games of the E. Jarvis era. So i been looking into the assembly and trying to figure out the synth routines used and hopefully one day being able to expose the parameters externally. From what i can figure there are 9 vector table synth subroutines that can be feed parameter(s) which drive all the sounds coming from the 2716 sized roms. Getting a pukka 6802 compiler working correctly on my PC is taking a while too but i have an editor version and a runnable version. But I really like the sound board (and mpc) design and capabilities from this era.

 

With the boards only capable of making one sound at a time (single voice) I have figured that 4 boards together would make an interesting musical instrument of sorts. Plus, I don't know if anyone is aware but these boards have a knock out sound. I demoed 2 boards at a chip tune gig a couple of months ago (using the Defender pin ROM and pinball ROM 1) and the sound was described as "punchy", which is just how i like my audio.

 

So along the way I am building a python controller running on a Raspberry Pi and a hardware controller with 3 banks of switch matrices. When this all works i intend to get back into the assembly side of things again especially now that i have rom burning sorted out.

 

Heres a pic of figuring out how to trigger the sounds: each byte sent only uses 5 bits to generate a specific trigger. I havent yet connected up the last pin. The RaspPi is connected to an MCP23008 i/o expander which then addresses a nand/and gate that grounds which ever pin combination desired.

1card-test-breadboard.thumb.jpg.0bb00e12ff5b9d7eb516c2d41776b6f2.jpg

Link to comment
Share on other sites

With the Pi controlling the multiplexer and grounding pins when a particular byte is sent, I needed some useful way to control event triggering (I won't say musical...) and it seems that most libraries for the Pi are either in C or python. I've never programmed python before so I figured it would be a good chance to learn. So with the libs python-rtmidi, GPIO and tkinter a midi interface of sorts is possible. Each midi note is assigned a hex value that corresponds to a particular pin combination (byte). Ideally control change messages will be assignable to parameters and one to overall volume would be nice as some sounds are quite loud compared to others. All sounds are basically one shot hits that play out until they are finished or interrupted by another sound, except in the case of several later ROMs there are 1 or 2 sounds that are continuous.

 

So far on all the ROMs I been using they have 11000100 (0x23) as a reset/stop all sounds. This is useful for the sounds that are used in some pinballs where they have a continuous but evolving sound, such as in Blackout that has a heartbeat type sound that increases in frequency with each successive trigger. On this ROM there is another background sound that evolves and also requires 0x23 to stop it - I describe this sound as "2 tone osc low endless multi-tap speed up" which if anything demonstrates how hard it is to meaningfully describe sound with words.

1card-midi-kybrd.thumb.jpg.e7c5aa27807efb9594515cbddda364ee.jpg

Link to comment
Share on other sites

This is just a little post about the python controller. The Rasp Pi uses the SCL, SDA lines to address each mcp23008 IC that is for a given sound board. These in turn are connected to two CD4066B gates that AND the common ground to the pin trigger selected. Its probably a bus speed thing but the controller works best (ie the sound is triggered cleanly) when a 0x00 is sent prior to the pin select, such as:

for card in CARD_ENUM:

bus.write_byte_data(card, gpio_register, 0x00)

bus.write_byte_data(card, gpio_register, pinHex)

 

but it may be that the pinball/game ROMs include this as well, will have to look into that later.

 

I did try to get a tracker like interface going but the gui lib used seems to not like the way i implemented it, so instead of a playhead that advances per tick that shows the pin hex triggered, it just has a long list of the triggers. Tempo is controlled by a crappy timer that is just a tick with a sleep: not the best at all but it works for now. The 680x mpu on the sound card is plenty fast enough to keep up with the Pi, i think its clocked at just under 1 mHz, but it would be nice to get a better and MIDI equivalent clock running soon. Programming currently takes place via a win 7 laptop running an Xming server and piping geany and the controller windows to the laptop via ssh. The pic is of the dev version of the controller as I explored getting all the bits working together and profiling the performance.

Pi-python-controller.thumb.jpg.2b93d6e9ea9b065fa033e8504c34ddf7.jpg

Link to comment
Share on other sites

After testing the various ICs on the breadboards it is time to make a controller card out of some pcb experimenter's boards from jaycar. I tried to place everything logically and reasonably close but with enough room to probe and get fingers in to remove various components. The mcp23008 is socketed on the left of the pic, with power, ground, SCL,SDA and address lines visible. The other 2 sockets are for the CD4066B gates that will be connected to the pins on the sound board. The middle two connectors on row 25 are distributing the ground from the sound board to various inputs on the gates that, depending on the state, form a connection with one of the sound board pins. Row 7,8 have the serial bus lines that have a second connector so that other controller cards can be daisy chained, 5v power is also distributed in this way. Presently the Pi header for 5v and ground are being used to power the cards.

 

The second pic is of the solder side and is there to show the way i connected everything and also how fugly the solder slubs look. I dont know if they are called slubs but i have always called them that - that technique of forming a solder line from point to point. But mainly, in future i will try not to use this trick :)

 

controller-card-component-side.thumb.jpg.84b949b6a1362a08ae1aa709efd0077c.jpg

 

controller-card-solder-side.thumb.jpg.8065d131eb3beff23472e181c7292cb7.jpg

Link to comment
Share on other sites

Thanks, BIG Trev, everything i do is a prototype ;)

 

The solder all held well but i did notice the pin connectors are not the best and sometimes you have to re-check the cable join to the pin head, but other than that the cards all worked well. next thing is to put them all in to something that could be taken to a gig and i followed the process of a previous sound project i built and got a cheap suitcase from the local market (Vic market) for about twenty bucks and an indifferent thanks. Two sound boards, two controller cards, Raspberry Pi and the DC +12v, -12v and GND terminal block. A separate 5v line was plugged in via an ATX power supply unit that provides all the voltages at more than enough amps (i hope...) for multiple sound cards.

 

The entire 2 board assembly is seen in the pic below. The bulky square PSU has no place in the suitcase so i figured i just place it on stage somewhere nearby... yeah no problem.

One thing that drove this assembly was ensuring i had some method of either running a meter or re-wiring on the fly if needed. This is only from experience a couple of years ago when i had 2x 12v SLA batts running in series and they undervolted a motherboard during a performance, so i whipped out the pliers and stanley knife to rewire them in parallel (probably the other way around, i was nervous onstage and cant remember) for a bit of performance art.

 

2card-demo-case.thumb.jpg.fbadb21ed03655e80accad0e9f821d82.jpg

Link to comment
Share on other sites

After hooking up all the boards and cards and checking they all work via the xming'd laptop, i needed to figure on how to translate this mess into a live performance kit. Well the Pi has an s-video out (should make things suitably lo-fi) so after running a few scripts so that things autorun at boot I now have an XCFE desktop with big icons pointing to the executable python script that runs the controller. Control of this is via a usb mouse held to my leg, while standing, as a mousepad. Yeah this will also go well on stage...

 

The tracker like controller was running with a movable playhead but either TKinter is not very optimised or my lack of python mojo is detrimental, but it dropped the tick counter to a slow dirge like march. So now it just has a playhead strip at the top that just prints to screen whatever sequence line it is up to. Not very tracker like and ultimately will have to be scrapped and replaced with something written in C probably. I don't really know much about the Pi but I think there is pretty good C support.

 

I should note that I have used both 0x23 and 0x0 within sequences, where 0x23 is the stop all sounds trigger and 0x0 seems to work as a sort of debouncer/skip tick trigger. This note is mainly cos I'm going to have to revisit this when it comes to the hardware controller build.

 

Second note is that the mixer shown in the pic below is flipping fantastic, during the performance i was sending speaker level audio to it and it mixed it ok as long as i didnt move the faders, look at it, prayed to the Luddite gods etc, etc. Yep. This problem has been rectified.

 

2card-demo-case-lcd-mixer.thumb.jpg.0275c5b9944c96bd0351fc90652ec55c.jpg

Link to comment
Share on other sites

A short interlude while i try and figure out why the GQ 4x4 ROM programmer is not enumerating... Neither win7, linux or osx recognise the device. This is annoying. Opening up the programmer allowed a bit of first pass testing which indicated that all the ICs are getting the required voltages to power them but mainly I think the problem will be with the USB peripheral controller IC (CY7C68013A). For some reason Win7 (both 32 and 64 bit) report it as a bluetooth device - which is nuts but its something. All attempts to re-install software and drivers in various orders and versions has also failed to rectify the problem so i'm going to assume theres something hardware related on the programmer or maybe even the firmware. I have a JTAG card but its made for XMOS chips so im not sure if I can progress troubleshooting much further other than checking some components, shaking it, hitting it with a rubber mallet or saving up for a proper microscope.

 

rom-burner-no.thumb.jpg.6b22cdc275b8395938642ead9749c492.jpg

 

Meanwhile back in 8bit land, one of the sound boards (type 1) has a stuck PIA pin. From what I can tell this IRQ pin is tripped when a sound pin combo is triggered and is then passed onto the MPU (6802) as a hardware interrupt that makes the code jump to a different sub routine depending on the values held in the 4050 buffers. In the pic below you can see the original manufacturers IC, a 6341 prom that held the code for a shuffle alley game. I had to replace the 6821 on this card.

 

pia_irqb-stuck.thumb.jpg.a464eac48c69c77b83599676c6dc2dca.jpg

Link to comment
Share on other sites

Heres a little sidestep to organise some sample dumps of Williams ROMs. At the moment I can't (temporarily) burn new ROMs so Im stuck with the ones I already have for a bit. They are Defender (pin), Pinball ROM 1, Blackout and a few proms that I havent really identified but they seem to contain variations of the main Pinball ROM 1 code.

 

The recording method is to use the ROM in a type 2 card (square), trigger the sound and record it directly after the D/A-amp path into a PC line in via a cable with a ground loop isolator on it (or in it... with it... whatever). Its recorded with Audacity. All samples are recorded at the same level to allow some headroom for some sounds that are a bit louder and punchy compared to others. I only really cut up to the start of the waveform but left a little space so if they are to be looped then they will need editing. Also the endpoint has a bit of space because some samples seem to keep the A/D going for a bit even after it would seem that the sound has been zeroed. So again, editing is required for looping.

 

Most of the sounds seem to be composed for one-shot or multi-triggers. Oh and the background sounds (heart beat and a 2 tone wave) are sampled for the beginning bit only. The pitch change from re-triggers will have to be requested :)

 

The naming convention is "pinball_name-00.wav" where 00 is the number of the sample using the 8 bit counting sequence. Note there is no sample-19.wav (11000100) as that is the reset/halt all sounds trigger. Bits 5,7 and 8 are never used in the ROMs I have looked at so far.

 

The file is 17.8 MB, the samples are 32 bit wav stereo.

lets see if this free file host works...

http://s000.tinyupload.com/?file_id=90658400772470827606

 

kapGo

Link to comment
Share on other sites

Well, they worked perfectly.

 

I uploaded the zip folder from Tinyupload.

 

Unzipped it using Winrar and that gave me I think it is 32 .wav files.

 

I then used VLC player and selected "play all".

 

VLC then went through all 32 .wav files and played all the sounds perfectly.

 

Do you have any other sound rom content?.

 

Thank you, sir.

Link to comment
Share on other sites

This morning I got the rom programmer to work after rolling back the windoze drivers. It seemed that win 7 "updated" the drivers to a non-functioning sys32 version for some reason, maybe just a default for usb enumerated devices. The drivers from the manufacturer are not signed, so theres probably an automatic behaviour to seek out signed versions...?

 

So then i got the Warlok rom programmed and had a test of it. Some nice sounds that seem to dupe the generic Pinball ROM 1. btw im getting the roms from ipdb.org so I assume they are pukka for each machine. Also noticed that the 2 tone oscillator background sustained sound triggered from 0x22 (01000100) can be re-triggered by bitshifting minus 1 to allow one tone to pitch up while the other pitches down. Previously I had thought that some values don't trigger anything but now it seems that some of the code includes triggers that are essentially controllers/parameters - well im excited anyway :)

 

I will try and get a rar together of this rom today and up it to tinyuploader but i gotta job interview later this arvo so i may run out of time.

 

Autosteve, for other roms i got a bunch of empty but unchecked, HN462716G chips that i can use so if you have a suggestion im open to burning some more, preferably if I havent already got the sound set on a previous rom.

 

type2-tester.thumb.jpg.80f7116b13a0e62365194f76e43c8da0.jpg

Link to comment
Share on other sites

I must be getting quicker at this, heres the Warlok file:

http://s000.tinyupload.com/index.php?file_id=64238214091707291111

 

just over 14.1 MB

 

again, recorded directly from the sound board, some samples have a definitive pop at the end, the sample and hold sound (#16) needed to be manually stopped so not sure how looping would go with it.Also the right channel seems to be a bit louder so maybe theres an issue with the mixer but they are created in mono so maybe a convert to mono in Audacity? Some of the longer sounds have a retrigger at the end only because i havent gotten around to making a hardware debounce circuit yet (i was reading the thread in this forum, handy stuff). Sample #20 is endless (maybe, probably, i dunno i couldnt wait to find out) so it got the trigger bounce too.

lemme know if you want any re-sampled.

ta

kapgo

Edited by kapGo
Link to comment
Share on other sites

Yes, you made a comment on your previous post saying a couple of the sounds didn't work.

 

Quote....The naming convention is "pinball_name-00.wav" where 00 is the number of the sample using the 8 bit counting sequence. Note there is no sample-19.wav (11000100) as that is the reset/halt all sounds trigger. Bits 5,7 and 8 are never used in the ROMs I have looked at so far.

 

 

They worked fine using VLC player all 31 of them have a sound.

 

As read here Warlok was a "futuristic version" of Blackout which probably explains why the sounds are similar.

http://mirror2.ipdb.org/images/2754/image-5.jpg

 

I actually recognise a lot of the sounds from early Williams machines like Stellar Wars, Lazer Ball but each game does have a couple of changes.

 

Interesting you are getting the sounds from ipdb. When I try to use these sound rom files, I get a collection of unplayable 716 files.

 

I guess I would need to run them through a sound board like you are.

 

William's Solar Fire has some interesting sounds but like all these machines up to Star Light, they all use a lot of the earlier sounds on all the machines.

Link to comment
Share on other sites

Thanks BIG Trev, i think it went OK, but who can ever tell....

 

Re the no sound triggers, I will definitely have to go back over some of the ROMs and try to find out if they are actually retriggers for other sounds. It kinda makes sense that given the constraints of the hardware there would not be any wasted space in the code. I have been reading up a bit on Eugene Jarvis and in an interview he talked about how they organised blocks of code into modules that had defined memory locations in a table for use with jump vectors. From disassembling the sound rom code its possible to locate the modules and the different types of methods used to generate sounds and the waveform tables for sine,tri, square etc. An example taken from the .716 ipdb rom for the boot sound is below:

 

ORG $F800 ;origin

FCB $FF ;form constant byte

RESET SEI ;disable interrupts,set interrupt mask

LDS #$007F ;load stack pointer to top of RAM

LDX #$0400 ;load index reg with PIA (DAC)

CLR $01,X ;clear, index x, switch to DDR

CLR $03,X ;clear, index x, and for 2nd port

LDAA #$FF ;load A with data

STAA $00,X ;all outputs on chn A

CLR $02,X ;all inputs on chn B

LDAA #$37 ;CB2 is output, output reg selected

STAA $03,X ;IRQB on low to hi, enabled

LDAA #$3C ;CA2 is output, output reg selected

STAA $01,X ;IRQA on hi to low, disabled

STAA <$09 ;store accum A

CLRA ;clear accum A

STAA <$07 ;store accum A into addr

STAA <$04

STAA <$05

STAA <$06

STAA <$08

CLI ;enable interrupts

BRA $F828 ;F828, wait for interrupt

;

TAB ;F82A, SYNTH1(boot), transfer accums

ASLA ;shift left A

ASLA ;shift left A

ASLA ;A x 8

ABA ;add accums, A x 8 + A = 9A

LDX #$0013 ;load 19 in X

STX <$0f ;store in zero page

LDX #$FD76 ;load table addr

JSR CALCOS ;FD21,calcs X + A -> X

LDAB #$09 ;put 9 in B

JMP $FB0A ;jumps below

;

PSHA ;FB0A, SUBRTN, push data

LDAA $00,X ;FB0B,load from X

STX <$0D ;store index

LDX <$0F ;

STAA $00,X ;

INX ;

STX <$0F ;

LDX <$0D ;

INX ;

DECB ;

BNE $FB0B ;branch above if != 0

PULA ;pull data

RTS ;FB1D, return

 

CALCOS STX <$0D ;FD21, SUBRTN, unsigned offset of A + X, val in X

ADDA <$0E ;add A to LSB of index base value

STAA <$0E ;store it

BCC $FD2C ;branch below if Carry clear

INC >$000D ;inc MSB of index base value

LDX <$0D ;FD2C, load value

RTS ;return

 

I have been adding remarks and trying to get the code to compile in various different 680x emulators but its all a bit wobbly. But you can see the module layout (sub routines). So this is why its easy to imagine they reused a lot of the sounds in various different games, plus the sound themselves were amazing, still are. For me the defined the era, there was nothing like walking into an arcade and hearing the Defender player start sound.

 

For other roms i have been thinking of burning SolarFire, Firepower and maybe that odd Varkon. Each of those has most of the basic sounds derived from William's Gwave synth but add a few unique ones that would be nice to have a play with. I'd really like to find a speech board as well so i can get some of the speech roms tested but I have yet to find one on ebeige. I really should spend some time getting back into assembly instead of playing kerbal space program...

 

- - - Updated - - -

 

Meanwhile back in sound hardware land, one of the most common problems I have had with these boards is the volume pot (on revision b type 1 and type 2 boards) being flaky, which is a technical term meaning mostly crap. The pots would invariably jump rapidly in values resulting in their use being limited to basically off and still a bit noisy to on and my ears hurt. So that gets replaced with a similar valued one. Also theres a 1 mfd tantalum cap just prior to the TDA 2002 amp ic which according to my expert knowledge (ie google searches...) is more than likely to crap out after all these years, so a replacement would be good idea. Also according to all the TNT Amusement vids i been watching all the caps should get replaced but so far i havent noticed the need. and of course all the "sah-der reflowed" but i havent done that either...

 

board-volpot-tantalum_cap.thumb.jpg.2de9e05950d15cb5715c36181768e0f7.jpg

Link to comment
Share on other sites

Aight, going to try get some asm into this forum post with the whitespaces retained, as i like things to be clearly organised.

 

This is the current state of me trying to figure out the Defender pinball rom code, for this post i will paste the boot sound which i have labeled as SYNTH1. Any block of code that outputs to the DAC ($0400) has been labeled a SYNTH by me and so far there are 9 with the 9th getting a bit messy. I figure if i can isolate the synth blocks of code I may be able to figure out what they are doing. They all also either BSR (branch sub routine and return) or JSR (jump sub routine and return) into blocks of code that change various values, so I've called those PARAM (after parameters).

 

Different interrupts can call the same SYNTH but with differing parameters inputted into that synth. Also there is a table of different waveforms as FCB (form constant byte) that can be inputted into a SYNTH as well. At the moment I have labeled some blocks as UTIL but i think they may be effects to have the synth generated bytes to be effected just prior to sending to the DAC.

 

There are a few uncertainties with the disassembler im using but mostly it seems to provide a good starting point for understanding how the code works. One such uncertainty is the following:

JSR $EFFA ;jump sub ?, was Label 79D0

 

This is a jump sub routine call to either the value held at a memory location (which is problematic as locations $F800 - $FFFF are for the ROM), or as a different pass in the disassembler found it was Label 79D0. Not very helpful :)

 

anyway, the boot code is below:

 

SYNTH1  LDAA <$1B	    ;F83F, SYNTH1 (boot), vol (always $FF)
DAC1    STAA >$0400        ;DAC output
LOOP1   LDAA <$13	    ;F844, load accum A, MAIN LOOP START
       STAA <$1C	    ;store accum A
       LDAA <$14	    ;load accum A
       STAA <$1D	    ;store accum A
       LDX <$18              ;F84C, load index, SUB LOOP 1
       LDAA <$1C	    ;F84E, load accum A, alt 0-255, variable delay, SUB LOOP 2
DAC2    COM >$0400	    ;complement DAC, invert
       DEX	                    ;F853, decrement index, SUB LOOP 3
       BEQ $F866	    ;branch below if = 0, goto SUB LOOP 5
       DECA		    ;decr A
       BNE $F853	    ;branch above if != 0, goto SUB LOOP 3
DAC3    COM >$0400	    ;complement DAC, invert
       LDAA <$1D	    ;F85E, load accum A, SUB LOOP 4
       DEX		            ;decrement index
       BEQ $F866	    ;branch below if = 0, goto SUB LOOP
       DECA		    ;decr A
       BNE $F85E	    ;branch above != 0, goto SUB LOOP 4
       BRA $F84E	    ;branch above always, goto SUB LOOP 2
DAC4    LDAA >$0400        ;F866, load accum DAC, SUB LOOP 5
       BMI $F86C	    ;branch below if minus
       COMA		    ;complement A
       ADDA #$00	    ;F86C, add 0 to A
       STAA >$0400	    ;DAC invert
       LDAA <$1C	    ;load accum A with value at location 1C
       ADDA <$15	    ;add A
       STAA <$1C	    ;store accum A
       LDAA <$1D	    ;load accum A
       ADDA <$16	    ;add A
       STAA <$1D	    ;store accum A
       CMPA <$17	    ;compare A
       BNE $F84C	    ;branch above if != 0, goto SUB LOOP 1
       LDAA <$1A	    ;load accum A
       BEQ EXIT1	            ;branch below if = 0, goto EXIT1, F88B
       ADDA <$13	    ;add A
       STAA <$13	    ;store A
       BNE LOOP1	    ;branch above, F844, if != 0, goto MAIN LOOP
EXIT1   RTS	            ;F88B, return, EXIT1

 

well, close enuough :0

 

and some of the waveform code ( i cant remember where i found the label names but i kept them in ) the def rom only uses the first 3 named waveforms but they could still be buried at the bottom of the rom file where i have yet to really figure out whats going on with waveforms and the like being all FCBs or FDBs:

SAW     FCB $40,$01,$00,$10,$E1,$00,$80,$FF,$FF ; FD76
FOSHIT  FCB $28,$01,$00,$08,$81,$02,$00,$FF,$FF ; FD7F
QUASAR  FCB $28,$81,$00,$FC,$01,$02,$00,$FC,$FF ; FD88
CABSHK  FCB $FF,$01,$00,$18,$41,$04,$80,$00,$FF ; FD91
CSCALE  FCB $00,$FF,$08,$FF,$68,$04,$80,$00,$FF ; FD9A
MOSQTO  FCB $28,$81,$00,$FC,$01,$02,$00,$FC,$FF ; FDA3, dupe QUASAR
VARBG1  FCB $60,$01,$57,$08,$E1,$02,$00,$FE,$80 ; FDAC

Link to comment
Share on other sites

There is a gig coming up for the Melbourne Fringe Festival via Clan Analogue, due to take place on the 15th Sept at Bar 303 in Northcote, hopefully everything will be working :)

 

I finished the first pass into the emulator of the defender rom code i have figured, but unfortunately the emulator im using doesnt recognise the opcode for FCB or FDB which is how all the waveforms are stored. so that kinda breaks that attempt. I have a few sounds boards coming so maybe i can turn one into a programmer of sorts...

 

Anyway a third type 1 board has been checked out and is ready for use in the live kit. The case im using however needs to be reconfigured to fit the new board, so theres a bit of whittling of mdf to be done ;)

 

Heres a pic of the test for the 3rd board breaking out of the suitcase:

 

old-demo-case-3rd-card.thumb.jpg.1a91a41dc6c23494b4f349b85176ea74.jpg

 

and then after a rebuild the cheapo suitcase now has 3 boards mounted vertically with room for the 3 controllers, Raspberry Pi (which will also be mounted vertically) and maybe the PSU...

 

3card-demo-case.thumb.jpg.9b3c7ae48928e646adf73a5fd47966bd.jpg

Link to comment
Share on other sites

This is as far as i can get with the emulator so far. I stepped the defender rom to watch the registers and memory locations to try and figure out whether I have got the routines correctly identified. For this run I org'd it to $0500 so that the ram and dac locations were free to be written to as the program runs. There are rem'd BRA to self places, etc, where the program would just sit and wait for an interrupt but this is cos i can't yet emulate an IRQ with an associated address that would make the code jump to the correct sound routine. Sadly this emulator won't jump to a location, only set breakpoints that can never be reached cos the code is basically a series of self contained routines that will never step all the way through. And the other emulator i tried doesnt work on a 64 bit PC and even when running on a 32 bit is flaky.

 

heres a pic of the emulator window showing the RAM location writes (the x20 values) and the register states after running from the Boot up sound start to the ending BRA to self statement.

 

def-rom-registers-boot.JPG.bef3fe02d1f79cd03ce290053431781d.JPG

 

below is an attempt to map out the register changes as i stepped through the code (hopefully the columns are retained within the code/code tags):

 A   | B   | X     |   NOTES
---------------------------------
   added ORG 0500 to get RAM, PIA, DAC, etc locations free for simulator to write to (should be ORG $F800)
 xFF         0400      <- START (DAC output)
 x37
 x3C
 x00
                       <- PARAM1
             FD76      (SAW wave start, $40 - 64)
                       <- CALCOS
 x76
                       <- PARAM1
       x09
                       <- UTIL1
 x20
             0013      write to mem location value (x20, 32 dec) in accum A (RAM mem locations $0000 - $007F):
             0014        STAA $00,X
             FD76      ($40 - 64)
             FD77      ($01 - 1)
       x08
             0014      
             0015      
             FD77      ($01 - 1)
             FD78      ($00 - 0)
       x07
             0015      
             0016      
             FD78      ($00 - 0)
             FD79      ($10 - 16)
       x06
             0016      
             0017      
             FD79      ($10 - 16)
             FD7A      ($E1 - 225)
       x05
             0017      
             0018      
             FD7A      ($E1 - 225)
             FD7B      ($00 - 0)
       x04
             0018      
             0019      
             FD7B      ($00 - 0)
             FD7C      ($80 - 128)
       x03
             0019      
             001A      
             FD7C      ($80 - 128)
             FD7D      ($FF - 255)
       x02
             001A      
             001B      
             FD7D      ($FF - 255)
             FD7E      ($FF - 255)
       x01
             001B      
             001C      
             FD7E      ($FF - 255)
             FD7F      ($28 - 40)
       x00           <- BNE
 x76                 <- PULA
                     <- RTS
 

 

This shows the jumps to the subroutines from the START where various locations and values are set/reset. Then it goes to a routine i named PARAM1 under the assumption that it sets specific parameters to be used with a SYNTH routine. In this instance it loads the starting address for a waveform assumed to be the sawtooth., Then it moves to the routine CALCOS (or calculate offset) then back to PARAM1 where accumulator B is set. This appears to works as a counter. Then its off to UTIL1 (which may need to be renamed, but i assume its a generic routine to modify a given waveform so it could be an effect). Here the routine loops with a BNE with writes to the global addresses for the RAM (locations within the 6802 MPU) the values of accumulator A (x20) and loads in the FDBs of the waveform starting at FD76 to FD7F. The decimal equivalents are written next to them above, so the waveform (without the RAM values "x" which i havent been able to access yet) goes x,x,64,1,x,x,1,0,x,x,0,16,x,x,16,225,x,x,225,0,x,x,0,128,x,x,128,255,x,x,255,255,x,x,255,40

 

well im sure everyones really fascinated :P

 

From a software engineering perspective this stuff is interesting as they are using highly modularised, self contained routines in assembly in a manner similar to object oriented. By using labels for the routines they can move in/around and edit various sound routines without affecting the remaining program.

Link to comment
Share on other sites

Well this is becoming a bit of an archival project as well as restoration and home brew/make a thing. I will get back to the hardware side of things next, but in the meantime this is another post on the software following the disassembly with the DASMx. The below is a function/routine map as far as i can tell from adding my own labels and reading the code/stepping through it etc. This is basically a way of me trying to figure out how the code jumps around to various routines. Anything named SYNTH has a DAC output. All the subloops modify the registers in some way and count down to 0 usually.

 

DEF rom routine map:

[ROUTINE]/tab[sUB-ROUTINE]/tab[CONDITIONAL]/tab[TARGET]
example:
[sYNTH1][s1LP3][bEQ][DAC4]

naming convention: S1LP3 == synth1, subloop 3

RESET
 STDBY   
   BRA STDBY
 
PARAM1
   (LDX	#$FD76 	;VVECT wave)
   JSR CALCOS
   JMP UTIL1

SYNTH1
 DAC1
 LOOP1
 S1LP1
 S1LP2
 DAC2
 S1LP3
   BEQ		DAC4
   BNE		S1LP3
 DAC3
 DAC4
   BMI		S1LP5
 S1LP5
   BNE		S1LP1
   BEQ		EXIT1
   BNE		LOOP1
 EXIT1   
   RTS

PARAM2
   BRA		S2LP2
 
SYNTH2  
   BRA		S2LP2
 S2LP2
 DAC5
 LOOP2
 S2LP1
   BCC		S2LP3
 DAC6
 S2LP3
 S2LP4
   BNE		S2LP4
   BNE		S2LP1
   BNE		LOOP2
 EXIT2	
   RTS

SYNTH3
   BRA		S3LP2
 S3LP2
 LOOP3
 S3LP1
 S3LP3
   BCC		DAC7
 DAC7
 S3LP4
   BNE		S3LP4
   BNE		S3LP3
   BEQ		EXIT3
   BEQ		S3LP1
   BRA		LOOP3
 EXIT3	
   RTS
 
PARAM3
   BRA		SYNTH4
 
PARAM4
   BRA		SYNTH4
   
PARAM5
   BRA		SYNTH4
   
SYNTH4
 LOOP4
 DAC8
 S4LP1
   BEQ		S4LP6
 S4LP6
   BHI		S4LP3
 S4LP2
   BEQ		S4LP5
 DAC9
   BCS		S4LP4
   BLS		S4LP2
   BRA		S4LP4
 S4LP3
   BEQ		S4LP5
 DAC10
   BCS		S4LP4
   BHI		S4LP3
 S4LP4
 DAC11
   BRA		S4LP1
 S4LP5
   BNE		LOOP4
   BNE		LOOP4
 EXIT4	
   RTS
 
SYNTH5
 LOOP5
   BCS		S5LP2
   BRA		S5LP1
 S5LP1	
   BRA		S5LP3
 S5LP2
   BEQ		EXIT5
 S5LP3
 DAC12
   BRA		LOOP5
 EXIT5	
   RTS
 
SYNTH6
 DAC13
 LOOP6
 S6LP1
   BNE		S6LP2
 DAC14
 S6LP2
 S6LP3
   BNE		S6LP3
   BPL		S6LP1
 DAC15
   BPL		LOOP6
 EXIT6	
   RTS
 
SYNTH7
 S7LP1
   BNE		S7LP1
 LOOP7
 S7LP2
   BPL		S7LP3
 S7LP3
   BNE		S7LP2
 DAC16
   BNE		LOOP7
 S7LP4
   BEQ		S7LP6
   BNE		S7LP5
 S7LP5
 S7LP6
   BNE		S7LP4
   BNE		LOOP7
 EXIT7	
   RTS
 
PARAM6
   RTS
 
PARAM7
   (LDX	#$FDAA	;VVECT wave)
 P7LP1
   BEQ		P7LP4
   BEQ		P7LP2
   JSR		CALCOS
   BRA		P7LP1
 P7LP2
   JSR		CALCOS
 P7LP3
   BSR		S8LP3
   BNE		P7LP3
 P7LP4
   JMP		IRQ2
 
PARAM8
   RTS
 
PARAM9
   BEQ		SYNTH8
 STDBY2	
   BRA		STDBY2

SYNTH8
   BLS		S8LP1
 S8LP1
   (LDX	#$FE41	;VVECT wave)
   JSR		CALCOS
   BSR		S8LP3
 S8LP2
   BSR		S8LP7
   BRA		S8LP2
 S8LP3
 S8LP4
   BEQ		S8LP6
   BEQ		S8LP5
   BRA		S8LP4
 S8LP5
 S8LP6
 S8LP7
 DAC17
   BEQ		EXIT8
   JMP		$0016	;?
 EXIT8	
   RTS
 
UTIL1
 ULP1
   BNE		ULP1
   RTS
 
PARAM10
   RTS
 
PARAM11
   BNE		P11LP1
 P11LP1
   RTS
 
UTIL2
   JSR		P13LP2
   JSR		P14LP2
 U2LP1
   JSR		P14LP3
   BRA		U2LP1

PARAM12
   JSR		PARAM1
   BNE		P12LP1
 P12LP1
 P12LP2
   BRA		P12LP2
 P12LP3
   BNE		P12LP3
 P12LP4
   JSR		SYNTH1
   BRA		P12LP4
   
PARAM13
   BNE		P13LP1
   BSR		P13LP2
   BRA		SYNTH9
 P13LP1	
   JMP		P14LP1
 P13LP2
   (LDX	#$FEEC	;VVECT wave)
   JSR		CALCOS
   (LDX	#$FE4D	;VVECT wave)
 P13LP3
   BMI		P13LP4
   JSR		CALCOS
   BRA		P13LP3
 P13LP4
   JSR		PARAM18
   JSR		PARAM19
   (LDX	#$FF55	;VVECT wave)
   JSR		CALCOS
   JSR		CALCOS
   RTS

SYNTH9
 S9LP1
   BEQ		PARAM14
 LOOP9
 S9LP2
 S9LP3
   BNE		S9LP3
 DAC18
   BNE		S9LP2
   BRA		LOOP9
 
PARAM14
   BSR		PARAM19
   BNE		S9LP1
   BNE		P17EXIT
 P14LP1
   BEQ		P17EXIT
   BEQ		P17EXIT
 P14LP2
 P14LP3
 P14LP4
   BMI		PARAM15
   BCS		P15LP1
   BRA		PARAM16
 
PARAM15
   BEQ		P15LP1
   BCS		PARAM16
 P15LP1
   BEQ		P16LP1
   BRA		PARAM17
 
PARAM16
   BNE		P16LP1
 P16LP1
   BNE		P14LP4
   BNE		PARAM17
   RTS
 
PARAM17
   BEQ		P17LP1
   BSR		PARAM18
   BSR		PARAM19
 P17LP1	
   JMP		SYNTH9
 P17EXIT	
   RTS
   
PARAM18
   JSR		UTIL1
   RTS

PARAM19
   BEQ		EXIT9
 LOOP10
 P19LP1
   BNE		P19LP1
   BNE		LOOP10
 EXIT9	
   RTS
   
IRQ
   BEQ		IR1LP2
   BPL		IR1LP1
   JSR		PARAM7
 IR1LP1
   JSR		PARAM9
 IR1LP2
   BEQ		IR1LP3
 IR1LP3
   BEQ		IR1LP4
 IR1LP4
   BNE		IR1LP7
   JSR		$EFFD	;?label
 IR1LP7
   BEQ		IRQ2
   BHI		IR1LP5
   JSR		P13LP2
   JSR		SYNTH9
   BRA		IRQ2
 IR1LP5
   BHI		IR1LP6
   (LDX	#$FD58	;VWTAB)
   BSR		CALCOS
   BRA		IRQ2
 IR1LP6
   JSR		PARAM1
   JSR		SYNTH1
   
IRQ2
 IR2LP1
   BEQ		IR2LP1
   BEQ		IR2LP2
   JMP		SYNTH4
 IR2LP2
   JMP		UTIL2
   
CALCOS
   BCC		CLP1
 CLP1
   RTS
   
NMI
 N1LP1
   BNE		N1LP1
   BEQ		N1LP2
 N1LP2
   JSR		PARAM1
   JSR		SYNTH1
   BNE		NMI
   JSR		$EFFA	;?label
   BRA		NMI
   
VWTAB   ;jump table FD58 to FD74. eg:
   FDB   $FB49

VVECT   ;waveforms for pwm synth FD76 to FFF7?. eg: 
   FCB   $40,$01,$00,$10,$E1,$00,$80,$FF,$FF

MVECT   ;motorola vector table. eg:
   FDB   IRQ     ;FFF8: FC B6
   FDB   RESET   ;FFFA: F8 01, Software Interrupt
   FDB   NMI     ;FFFC: FD 2F
   FDB   RESET   ;FFFE: F8 01, Hardware Interrupt    
 
NOTES::
-waveforms 4-64 bytes
-frequency table 10-20 bytes
-parametrically driven pwm synth
- need to find the frequency table, possibly after VVECT  
- priority system for incidental over background sounds
- save state for background sounds

 

this is from a rom named def12.716 which i assume is the pinball rom not Video Rom 1. I read a pinside forum post on how there may be different versions of roms for a given pinball and that its possible in some instances to use the "wrong" rom for a given pin, so i've started to make notes of the checksums. this rom is :

;File: SOUND12.716

;

;Size: 2048 bytes

;Checksum: AF3F

;CRC-32: CABAEC58

 

with all the labels in use the programmers are free to locate any routine anywhere in memory and simply change the address that points to it in the VWTAB jump table.

 

Its kind of easy to imagine that a given pin could have its sounds changed relatively easily by simply changing either the waveform bytes or parameter bytes. Assuming that the Synths are standard in some way, they could play a given waveform with a given set of parameters and sound completely different. If I get around to it id like to make a detailed comparison with rom from a different pin but same generation and see if that theory holds up. Plus id like to get the ram mapped/emulated somehow too.

Link to comment
Share on other sites

The next part of this project is to build a hardware controller that can be used to test ROMs and boards out as well as possibly be used to play live. The idea on paper is to have three banks of 5 switches that can be triggered independently of each other. This isn't going to be a pretty build, but it should be functional. Firstly is to test out the switching idea with a bread board and a type 2 sound board:

 

type-2-switch-test.jpg.70377f3f466b4ee10a2191c39fa212b0.jpg

 

There are two ground buses and a 5 volt bus. One ground is connected to the sound selector pins on the sound board and the other is connected to common and is used for the LED. And there had to be a big arcade button somewhere too.

 

This mockup was then committed to MDF and lots of short wires and soldering. Im trying to get better at connecting components by using wires and not big long blobs of solder, so an example of this is using the prongs of the LEDs to form the bus.

 

triggerbox-switch-start.jpg.c5b70afff0977e436f9b0d1d870f4aa1.jpg

 

and completed to this stage it looks like this:

 

triggerbox-switch-bus-fin.jpg.d8825a11fd0b1f601ec4a7e0d2f154ad.jpg

 

with all the sound select wires then going to a little matrix circuit that will eventually be connected the sound board itself, and the 5v, GND will go through this as well.

 

triggerbox-switch-distro.jpg.3209161a56a47b4ce91e5079252ba304.jpg

Link to comment
Share on other sites

Programmed a new rom for the pinball called Varkon, which is an odd but interesting looking game being built into an upright cabinet. The sounds for this are amazing and quite different from the earlier pins, with more emphasis placed on sounds with echo or delay effects added. Also of note is that this is the first rom ive listened to that does not use 0x23 for a reset/stop all sounds. instead it triggers off a longish oscillating pulse sound. The reset is moved to 0x25 and 0x26. I couldnt find any background sounds in this rom either, and so no modifier is used either, such as in Warlok. There are about 4 or 5 "standard" type sounds that are found on earlier pins but most seem to be specifically programmed for this pin. Several sounds seemed to be paired where the same sound plays but with a reversed direction of pitch change. Also they have added to the defender type blaster and explosion sounds by making them loop for longer with more of a pronounced degradation of sound to almost a white noise. Sounds great!

 

the checks are :

; File: varkon.716

;

; Size: 2048 bytes

; Checksum: A694

; CRC-32: D13DB2BB

;

; CPU: Motorola 6802 (6800/6802/6808 family)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...