In choosing a chip, you should stick to 8 bit chips (Chips with D0-D7) as using higher width chips such as 16 bit chips (D0-D15) will be wasteful, in terms of usable storage. Remember, this era of pinball machines are only 8 bits wide and so the excess data pins on the wider chip will go unused.

You also need to think about timing/response time and handshaking signals of the chip you choose. They must match the 2716 and 2732 chip specification and be at least as fast as that.

No matter the size of the chip, they will always break down into 2K chunks using A0-A10. 4K chunks would need A0-A11. 8K chunks A0-A12, etc. Any extra address lines on the chip you choose should each be routed (in order) to a DIP switch.

The bigger the chip, the more chunks you get. System 7 boards (in system 7 mode) need 4K chunks. A system 7 board in system 6 or earlier mode will need 2K chunks. System 6,4,3 also need 2K chunks.

For those that don't quite know how to decide, I'm likely going with an SST39SF040 (512k x 8 bits) when I do start putting some pre-programmed adapter boards up for sale. In the mean time, if you decide on a different chip that works please feel free to chime in, and post your design for others if you like.

SST39SF0x0 (resized).png

Here's where you can get the 39SF040 from digikey (digikey part# SST39SF040-70-4C-PHE-ND) in Canada:

https://www.digikey.ca/products/en/integrated-circuits-ics/memory/774?k=sst39sf040&k=&pkeyword=sst39sf040&sv=0&pv1291=3756&sf=0&FV=ffe00306&quantity=&ColumnSort=0&page=1&pageSize=25

Don't forget to use a chip that your chip programmer supports, and use a socket on your adapter board - you'll need to quickly remove the chip to program it with newer versions of ROMs HINT: Make your life easy and use a ZIF socket!

Actually, you can also go by the upside-down-and-backward-F that is showing on the 7 segment display. Not sure what that character is supposed to be, but if your board is flashing that character it also means a pass. Thanks for posting that video @cheddar. Are you able to post a video or picture of what the 7 segment looks like when a fail is indicated? I don't have my system 7 machine anymore.. if you have a socketed RAM or CMOS chip you could pull it out and run the test to get the failure.

Awesome thank you!!

The init-cmos ROM has only ever been verified to run on Gorgar and Black Knight. It's possible that other games have slightly different settings and slamming Gorgar settings into another sys3-6 game or slamming Black Knight settings into another sys 7 is technically invalid. This could be causing the 8 to flash.

So for you I'd say run the clear-cmos and then boot the game normally and see if it's happy. Since the CMOS test ROM runs fine you don't need a new CMOS (5101) chip.

On another note, in order for the init_cmos ROM to work on a different game I'd need someone to send the me default settings for that game. To do this you would run the clear_cmos ROM, then the Williams ROM twice with the door open. Once the game is in attract mode the CMOS chip would contain the actual default values for that game. From there you would power down (with batteries installed) and then run the edit_cmos ROM.

Once the edit_cmos ROM is running you would step through all of the addresses in the CMOS chip and look at the value stored in that address. If it's non-zero write the address and value down and move on to the next address.

When writing them down I specify them in sets of two. This is because they are actually 4 bit values and so the GAME ROMs need two addresses to store a single 8-bit value).

So for example, here is what the sys7 init_cmos ROM uses to initialize the CMOS chip (remember, these values are taken from Black Knight):

ENT_103 .db 2,0
ENT_125 .db 11,2
ENT_127 .db 10,5
ENT_129 .db 2,5 ; Default 2,5 # HSTD (2,500,000)
ENT_131 .db 1,1 ; Default 1,0 # replay 1 (1,100,000) - setting 14 in Williams ROM
ENT_133 .db 2,2 ; Default 2,0 # replay 2 (2,200,000) - setting 15 in Williams ROM
ENT_135 .db 3,3 ; Default 0,0 # replay 3 (3,300,000) - setting 16 in Williams ROM
ENT_137 .db 4,4 ; Default 0,0 # replay 4 (4,400,000) - setting 16 in Williams ROM
ENT_145 .db 0,3
ENT_147 .db 0,5
ENT_149 .db 0,5
ENT_151 .db 0,0
ENT_153 .db 0,3
ENT_155 .db 3,0
ENT_157 .db 0,1
ENT_163 .db 0,1
ENT_165 .db 0,1
ENT_167 .db 0,3
ENT_169 .db 0,4
ENT_171 .db 0,0 ; Default 3,0 # MAX_CREDITS (00) - setting 18 in Williams ROM
ENT_173 .db 0,1
ENT_175 .db 0,1
ENT_177 .db 0,4
ENT_179 .db 0,1
ENT_181 .db 0,2
ENT_183 .db 0,4

This basically says:

- Addresses 0 thru 102 are zero.
- Addresses 103 and 104 have a value of 2 and 0 respectively.
- Addresses 125 and 126 have a value of 11 and 2 respectively.
.
.
- Addresses 183 and 184 have a value of 0 and 4 respectively.
- Addresses 185 and up are zero.

FORMAT: The values after the .db are the values that init-cmos writes to the CMOS chip. When I've changed them to a non-default value I include a comment and state the default value. So for example to place the game into free-play mode I set a new default value for MAX_CREDITS by setting 171 and 172 from 3 and 0 (thirty) to 0 and 0 (zero).

If anyone wants to take the time to do this for their game and send me the results I'd be happy to make an init-CMOS ROM specifically for that game. Don't worry about having to decipher what the values in each address means just send me the numbers and I'll make the ROM stick to the defaults. If you want to take the time to verify what each address is used for (like I did for 129-138 and 171-172) that would be a bonus! (edit the value and reboot into the GAME to look for a change in behavior). Alternatively you could write the default numbers down then boot into the game, change one of the settings or insert a coin, power down, run the edit_cmos again and take note of the changes.

EDIT: The only difference between the init_cmos ROM and the clear_cmos ROM is that:

- clear_cmos sets ALL the values in the CMOS chip to zero (causing the Williams ROM to set its default values on the first boot)

while:

- init_cmos does that too and then sets some non-zero values (effectively setting defaults so you dont have to boot the game with the door open twice).

Let me know if you need more clarification

Interesting. Keep me posted.

Yes, each game would end up storing "who knows what" values in the CMOS so you can't go strictly by the settings in the manuals. Those are limited to what they want you to see and/or modify. So you are right, the sure-fire way to go back to playing a non-gorgar/blackknight game is to use clear_cmos and let the first boot of the Williams ROMs write what it needs to the CMOS and be done with it.

The init_cmos essentially restores the entire contents of the CMOS to what Gorgar or Black Knight would have written on a first boot. What it's handy for (if you happen to have a Gorgar or Black Knight) is that using it instead of clear_cmos allows you to skip the first boot and instantly set your game up with defaults. the init_cmos.txt file shows what defaults are changed from williams defaults.

Really, init_cmos is more of a personal-use kind of ROM for me. It saves a lot of time when I'm modifying and testing a ROM image a few hundred times before releasing it.

The idea of having one for each game out there might prove to be useful for others. Not having to go back and set free-play mode could be every time could be one of them..

First of all, that's a nice board you made! Nice and clean..

Secondly, that's extremely weird behaviour! (but you already knew that).

IC34 is responsible for choosing how to arrange the segments given the input from IC33, which then traces back to PIA1. Oddly, it chooses the numbers 'backwards' from the input. Basically:

PIA1 = SEGMENT DISPLAY
-----------------------------
F = 0
E = 1
D = 2
C = 3
B = 4
A = 5
9 = 6
8 = 7
7 = 8
6 = 9

So the test ROM actually counts backwards from F to 6 on PIA1 in order to display 0 to 9. Anything below 6 on PIA1 causes the segment display to show other predefined characters not used by Williams (search for the PDF of IC34 for details). In your case it appears that the mapping in IC34 is not actually backwards like the test ROM expects it to be, which is why it appears to count down instead of up, and also includes the other predefined characters.

Perhaps your board has a different IC34 chip than what I had in my black knight when I wrote that ROM. ie: maybe at some point Williams did a hardware revision change and made up for it in software.. Can you tell me what your IC34 chip is? Mine was a DM7447.

This part of the circuitry on the board has *almost* nothing to do with the rest of the board. The fact that it is counting backwards on the display doesn't worry me too much, but what are the other symptoms of the board?

Try the rest of the ROMs and see what you get.. You may have to pull a good RAM or CMOS chip and run the respective test to prove whether "top led" and "bottom led" are really the top and bottom LEDs (bottom LED is the one that flashes when the chip is pulled, forcing a failed result).

Awesome, nice work! Glad the ROMs were of use to you

Thanks for sharing all of your valuable feedback. I'm glad you made good progress too! It's not always easy from here to help troubleshoot so posting your results helps me too.

Can't wait to see the videos you make, that's awesome thank you!

Cool. You're not so Shakey by my standards. When I shoot videos they look like outtakes from Blair Witch!

Thanks for adding them!

BETA RELEASE:

I finally got my hands on a working Hyperball set so I'll be working on updating the ROM set to support it over the next while..

I did just put out a new beta version of ROMS available here: http://pincoder.ca/ccn/roms/pincoder_roms_2019.08.28.2031_beta.zip

A few small tweaks, and added a second sounds test. This test doesn't require the use of switches so you can also run it on the bench. Essentially it does the same thing as the first sounds test ROM but sends the sounds out automatically a few moments after boot up.

Cheers!

Another Beta release: http://pincoder.ca/ccn/roms/pincoder_roms_2019.10.03.1703_beta.zip

Rewrote the documentation for "01b-bus" adding more about troubleshooting power and the reset circuit. The ROM remains the same.

Is that when the clips are connected to 1J2 or floating? At 4.1v it may boot but once it starts using all of the circuitry on the board that voltage may drop below an acceptable level.

For what it's worth, the values below are from using an actual power supply from a williams pinball machine on the bench (transformer, power supply board, rectifiers, the whole lot).

While floating (1J2 disconnected, 3J6 disconnected) I'm seeing:
5.19 volts across the 5V and GND pins of 3J6

After reconnecting 3J6 I'm seeing:
5.10 volts across the 5V and GND wires on the end of my power supply wires (cable side of 1J2).

While 1J2 and 3J6 are connected, I also see 5.1 volts across each of:
TP9 and TP10 of MPU board
VCC1 and GND1 of IC1
VCC2 and GND2 of IC1

I'd say your wires with the alligator clips are an issue (0.7v drop seems too much). Power supply wires should be of a decent guage. If the wire is too thin it will not be able to carry the required current draw from the circuit boards. This can also cause the board to malfunction.

You shouldn't see a voltage drop of more than 0.01 volts anywhere you look on the 5v rail. Disconnect the alligator clip and see if the drop is on that wire.

You understand perfectly Glad you found them!