(Topic ID: 222797)

NEW! Williams System 3-7 In-Game Test ROMs


By pincoder

1 year ago



Topic Stats

  • 196 posts
  • 29 Pinsiders participating
  • Latest reply 11 days ago by kevinclark
  • Topic is favorited by 49 Pinsiders

You

Linked Games

Topic Gallery

There have been 21 images uploaded to this topic. (View topic image gallery).

SST39SF0x0 (resized).png
CERDIP-PINS (resized).png
512 (resized).PNG
28c512 (resized).PNG
wang (resized).jpg
25616 (resized).jpg
2e3f85951413d05e56ae1fe9aee7d8d99408b7a7-1-1-1-1-1-1-1.jpg
2816-MPU (resized).png
new (resized).jpg
s1 (resized).jpg
sip (resized).jpg
bot (resized).jpg
top (resized).jpg
20190509_011625.jpg
Captsaure (resized).PNG
IMG_20190406_160625475 (resized).jpg

You're currently viewing posts by Pinsider pincoder.
Click here to go back to viewing the entire thread.

18
#1 1 year ago

Hi,

I've written some ROMs for Williams System 3-7 pinball machines that are very simple to use, and can be used in-game, so you don't need any test fixtures.

Install and power up each ROM in order to quickly help you identify problems with your entire machine.

They have been tested on a GORGAR (system 6) and Black Knight (system 7) machine and work great!

System 7 games:
Barracora
Black Knight
Cosmic Gunfight
Defender
Firepower II
Hyperball *
Joust
Jungle Lord
Laser Cue
Pharaoh
Solar Fire
Time Fantasy
Varkon
Warlok

System 6a games:
Algar
Alien Poker

System 6 games:

Tri Zone
Time Warp
Gorgar
Laser Ball
Firepower
Blackout
Scorpion

System 4 games:

Pokerino
Phoenix
Flash
Stellar Wars

System 3 games:

Hot Tip
Lucky Seven
World Cup
Contact
Disco Fever

* NOTE: Hyperball is not fully supported in this version. Specifically, the displays ROM does not test the alphanumeric display in the playfield. I am still looking for a working hyperball machine and when I find one I'll make an update. If you have a lead on a working hyperball feel free to send me a message on pinside.com (pincoder).

The Pincoder software download contains 2K and 4K ROM files that can be used in your game:

- 2K ROM images (system3-7) can be used in 2716 EPROMs and 2816 EEPROMs.
- 4K ROM images (system 7) can be used in 2532 and 2732 EPROMS.

You can get them all in a single zip file here: http://pincoder.ca

Hope this helps!

Craig

#4 1 year ago
Quoted from barakandl:

Some of these look very handy. Great work. I am going to play with the sound test to explore the noises in each sound ROM. The CMOS clear is useful for a system 7 board running older software and NVRAM as switching between games leaves you no easy way to clear the RAM on the board.
Since there is sixteen 2716 images one could build a 27256 EPROM board with a 4 position dip and pullup resistors to bank switch between each test rom.

That would be a handy board to have. I've thought about putting them all in one ROM and making them selectable via DIP switches, but that would require functioning RAM (as well as other resources) and would render the entire ROM useless if one of those resources were faulty.

The ideal solution (if you want to spend the $300 US) is to use the Pocket Romulator. Then you don't need to program any chips at all, and you can select the ROM image you want by uploading it via USB/serial from your laptop.

#5 1 year ago
Quoted from 2manypins:

Thank you for your work.

You're welcome! Let me know what you think after trying them out

#7 1 year ago
Quoted from zacaj:

..why would that require ram?

Because writing code with subroutines requires the use of the stack (to call the subroutine), which is located in RAM.

ROMs 01-LEDs through 06-ram3 are written without using any RAM or subroutines, so that they will function regardless of any working RAM installed.

This means that 03-cmos through 06-ram3 are then able to test 100% of the RAM/CMOS address space without clobbering themselves and causing the test to crash.

#10 1 year ago
Quoted from eh97ac:

Are you planning on writing anything similar for Bally/Stern MPU's?

I wouldn't say it's out of the question, but I've no experience yet with those games. From what I understand, they use the same CPU and PIA chips so I'd just need to get familiar with them first..

#12 1 year ago
Quoted from SteveNZ:

Nice work, I have some weird problems on a System 6 board. I'll get some more 2716 ROMS and do some testing. My board is modified to run the Firepower Combo ROM. will these tests still work?

Yes. The Firepower Combo ROM modification only changes access to the GAMEROM (IC14) side of things, and the test ROMs run in the GREEN2 flipper (IC17) socket. They should work just fine. Please let me know how you make out with it

#19 1 year ago
Quoted from barakandl:

The blank PCBs shouldnt be expensive to have made. Perhaps I can upload the gerber file to a site people can order from or just have some made the next time I order blank PCBs.
[quoted image][quoted image][quoted image][quoted image]
The four upper most address bits are attached to a dip switch bank. When the dip switch bank is closed it is a zero, grounded. When dip switch bank is open it is pulled up by 10K sip resistor to make a one. That should split the 256K EPROM into sixteen 16K chunks.

This is great. If you upload the gerber files I'll also post them on the main pincoder page, and I'll compile a single 27256 image to go with them, so each test would be selectable by the DIPs.

Also, correct me if I'm wrong, but this board will work with 2764 and 27128 (albeit with smaller chunks) correct?

EDIT: The latest version of ROMs now includes "27256.bin". This file is a concatenation of all 16 ROMs into one, so each test should be accessible by setting the DIP switches. Please try this image on your board and let me know how it goes.. http://pincoder.reversion.ca

#22 1 year ago
Quoted from zacaj:

That was the original discussion, I think? Most of the roms probably don't need the full 2kb or anything even. Should be possible to read the mpu dip switches, jump to one of the tests, repeat.

It is possible, absolutely (In terms of the original discussion: MPU DIPs). I hesitate though, because if that PIA is bad, then it's possible none of the other test images will be accessible, making them useless.

As for using DIPs on a board such as barakandl suggests, I think it covers all needs quite nicely. Each 2K ROM image is independent of the others and so simplifies diagnostics, and also allows for a single, newer chip to be utilized, saving time and money.

Speaking of which, barakandl, let me know if I need to re-arrange the order of the ROMs in the 27256.bin image to agree with DIP switch settings.

While we're at it, what's the highest (and most available) chip to use? with a 27512 or higher there's room for future 2K test ROMs.

Also, what about static RAM chips? Since the board allows us the freedom of any chip's pinout, maybe static RAMs are better, even if they're much larger than we'd ever need..

Thoughts?

2 weeks later
#29 1 year ago
Quoted from uofmer:

Hey - just downloaded your images - I have a FLASH game that isn't booting I fail the first test - leds don't flash, so it's time to start removing ICs. Bummer! All the signals (looking with a scope) look good - the uP is running. Some of the databus lines look questionable so it could be the RAM or the PIA. Neither is in a socket... It would be nice if there was some alternate signal you could toggle besides the LEDs so I could isolate it between the PIA or the databus... Anyway - glad you are doing this - it's been hard to find the previous testroms (Andre/Leon) and their instructions on the web.

1) Check that CA2 on PIA1 is high while this test is running. Without it IC2 will not do anything with the LEDs. Also check that pin 15 on IC2 is low enough to be a logic 0 and that SW2 is open.

2) Are you seeing the toggles on PA4 and PA5?

3) What about VMA on IC1? You should be seeing toggles there as well as IC8 (14,13,3).

4) Have you tried 02-blanking? It just toggles the PA2 to keep the blanking circuit happy and would give you another signal to test.

You're right, it would be a bummer if the data lines are being bogged down by some other chip(s). I could write a ROM that does NOPs so that the address and data lines are not being accessed, which might allow you to look for non-floating address/data lines. I've never tried it but would imagine the CPU to behave that way when running NOPs forever. If the data lines are being bogged down, PIA1 could never be initialized properly and so PIA1 just might be okay.

#30 1 year ago
Quoted from uofmer:

looking at Mouser and Digikey - the mainstream EEPROM are now the 1Mb parts. the 28C256 parts are ~$6 while the 39SF010 (1Mb) is ~$1.37. However, the 1Mb part is a 32 pin dip. While $5 isn't much, it might be better to change the layout to support the 32pin footprint to future proof the design? The UV 27x256 parts are, however, all over ebay between $2 and $10 bucks, but since I don't have a UV eraser, I like the EE parts better... just a thought.

Thanks for your input. I agree, eliminating the UV eraser is the way to go I'll look into the 39SF010 as they are still an active product.

#31 1 year ago

uofmer Download the latest images (http://pincoder.reversion.ca). I've added a "00-bus" test that might help in showing which address/data bus lines might be bogging down the bus (by ensuring the CPU ignores interrupts and is in a WAIT state). Take a look at the notes (00-bus.txt) give it a try in your Flash, and let me know if it helps you at all.

Also, I've updated 06-ram3 to test the additional RAM space on a system 7 board (04-ram1 and 05-ram2 still need to be run to fully test RAM on system 7).

#34 1 year ago
Quoted from uofmer:

Here's the testing...

on PIA1, on pins 1 - 20, only 1 and 18 are low and the rest are high (steady state). on the other side of the IC, all the pins are toggling - 21-24 are fast toggles (looks correct), 25 clock is ok, 26-33 looks like the databus, 34 high (reset), 35-36 looks like the address bus and 37/38 high and 39/40 low

no, but.... if I press SW 1 (diag) I can get the those pins (and therefor the LED) to turn on or off. The only change when I press the button (not all the time ~20% of the time) and usually they sequence top on, both on, both off... Since that is just toggling the NMI, is there something in the code executing ???

yes VMA looks good at the processor and the address buffers, chipselect logic etc

no difference, however, depressing SW1 doesn't change the LEDS (both on) - PA2 stays high

The NMI switch and IC2 circuits will light the LEDs at the same time all by the hardware, so what you're seeing is normal, and is not a function of software.

Seems like the CPU is running but PIA1 is not responding to anything it's given. Is it in a socket? Can you swap it with a known good one?

Since PIA1 controls the LEDs, displays and switches, the only other test you could run that would show you a working CPU without using displays or switches is 12-solenoids. It requires input from switches to fire solenoids and uses displays , but it also enables the flipper relay at startup, so you only need to power it on and check that the flipper relay is energized. Of course you can also hit the flipper buttons and the flippers should move.

If you can do that then the address and data buses are fine, and the problem is quite likely PIA1

#38 1 year ago

Interesting. So even back then they were selling chips that didn’t make the cut as lower quality chips having limited features. Some things never change!

2 weeks later
#43 1 year ago
Quoted from SteveNZ:

@barakandl Thanks for the board info above. I built a board based on your drawings, just on a perf board not a PCB. It all tests OK with a continuity etc. I burnt the combined image onto a 27C256 and installed the chip. I then tested the board in my Rom burner, reading every option for the 4 dips back into the Rom burner. All work exactly as expected, except for when all 4 select dips are set to ON, this should select image 0 - Bus, but it selects image 4 - RAM1. It seems like dip3 is not turning ON, but it is, otherwise I couldn't select 11 lamps, 10 timer etc. Any idea what is going wrong?

Great to hear you're trying this out. Let us know how it goes!

#46 1 year ago
Quoted from SteveNZ:

I checked all 4 lines that are connected to the dips, I get 4.98v when the dip is open and 0v when the dip is closed. I also checked the image in the 27C256 and it looks to me that ROM 0 is the first one in the list. I did this in case ROM 4 was accidentally written to the 27C256.
Is there any chance that when all 4 addresses are low it does not select the first chunk, as in should it be some other combination of address pins?

After thinking about it, I realized that the 27256.bin file was too long. It had 17 ROM images instead of 16. Perhaps the burning software you're using got confused by the extra bytes and wrote the image wrong. So I've removed 16-edit_cmos from the 27256.bin image. You can still find the edit_cmos test in the zip file as a standalone 2K image if you want to use it.

Please download the latest version and try again.

Quoted from SteveNZ:

Unfortunately I can't report back on very much yet. I have 2 System 6 boards that will not pass the LED test, so I am stuck at the BUS (ROM 0) test. given my issue above with selecting ROM 0, I burnt a 2716 with ROM 0 for testing.
While I'm here, I should check some things:
I understand that these test ROMs are designed to be used with the boards in the game. Can I use the ROMS with the boards on the test bench instead?
Do the ROMs, including the BUS ROM, only work correctly if the driver board is connected?
On 1 of my boards Pin34 on the CPU is high but J1 is installed and R4 is removed and a 6808 is installed - so I need to figure out what is going wrong there.
On both System 6 boards I have some address lines that are not as per your expected conditions. I'll look to trace those lines through the board to see where the problem lies.

You should be able to use the ROMS out of the game and on the bench. However, without any of the displays and switches etc you will not be able to do much with the latter tests. Since the earlier ones dont require any input from the user and results are only displayed on the LEDs they can be of use while on the bench.

00-bus does not initialize any PIAs and should run without the driver board connected. The rest of the tests each initialize all PIAs and technically should require the driver board, but I dont think the CPU will lock up trying to write to a PIA that isn't there so you should be able to get away with leaving the driver board disconnected. I will put an MPU board on the bench and verify.

For Boards with 6808 processor (J1 Installed and R4 Removed) you will require a RAM chip in IC13 for for normal game operation. Test ROMS 00-bus through 06-ram3 do not require any RAM or CMOS whatsoever (aside from the obvious RAM/CMOS they are testing). So as far as software goes, it shouldn't matter what pin 34 is doing, or what CPU chip you have, or whether you have any RAM installled at all. The test ROMs should still run.

The CPU chip itself may have something else to say about that. I'll see if I have a 6808 around and put it in a benched board without any ram and see if it can still run the tests.

#49 1 year ago
Quoted from eh97ac:

pincoder
I cannot find the gerber files on your site. Can you post a direct link?

Sorry, there are no gerber files at this point though barakandl has posted PCB images in this thread.

#50 1 year ago
Quoted from pincoder:

After thinking about it, I realized that the 27256.bin file was too long. It had 17 ROM images instead of 16. Perhaps the burning software you're using got confused by the extra bytes and wrote the image wrong. So I've removed 16-edit_cmos from the 27256.bin image. You can still find the edit_cmos test in the zip file as a standalone 2K image if you want to use it.
Please download the latest version and try again.

You should be able to use the ROMS out of the game and on the bench. However, without any of the displays and switches etc you will not be able to do much with the latter tests. Since the earlier ones dont require any input from the user and results are only displayed on the LEDs they can be of use while on the bench.
00-bus does not initialize any PIAs and should run without the driver board connected. The rest of the tests each initialize all PIAs and technically should require the driver board, but I dont think the CPU will lock up trying to write to a PIA that isn't there so you should be able to get away with leaving the driver board disconnected. I will put an MPU board on the bench and verify.
For Boards with 6808 processor (J1 Installed and R4 Removed) you will require a RAM chip in IC13 for for normal game operation. Test ROMS 00-bus through 06-ram3 do not require any RAM or CMOS whatsoever (aside from the obvious RAM/CMOS they are testing). So as far as software goes, it shouldn't matter what pin 34 is doing, or what CPU chip you have, or whether you have any RAM installled at all. The test ROMs should still run.
The CPU chip itself may have something else to say about that. I'll see if I have a 6808 around and put it in a benched board without any ram and see if it can still run the tests.

Update: Just did some testing on the bench:

1) You can run the ROMs on a bench without the driver board connected. The CPU doesn't lock up when it tries to write to PIAs that aren't there.

2) You can run ROMs 00-bus through 06-ram3 without any RAM or CMOS installed (except for the obvious chips each of them test).

2) The docs for 00-bus had you looking at IC1 pin 34 as the RE line. This was incorrect. The correct RE pin is 36. Thanks to stevenz for pointing this out. I'll revise the doc and put out a new release.

#52 1 year ago
Quoted from stangbat:

Craig, you have the link wrong for the new version of the file (or the file name is wrong). You have it pointing to version 2015 and it should be 2051. Correct link:
http://pincoder.reversion.ca/ccn/ROMS/pincoder_roms-2716_2018-09-26_2051.zip

Ha! Fixed. Thanks

#54 1 year ago
Quoted from SteveNZ:

In the end there is nothing wrong with the 27C256 image or the schematics for the adapter board, i was just misreading the information from my ROM burner. So have confidence with burning a 27C256 chip and making an adapter board.

Nice! and thanks for the update Have you tried all of the ROMs yet?

#56 1 year ago
Quoted from SteveNZ:

I haven't tested any of the ROMS other than 00. I'm stuck at the 00 Bus ROM ROM. neither of my boards will run the 01 LED ROM.
With 00 ROM I have all the correct signals at IC1 (CPU) except for pin 9 A0, which is low, and should be high. I can't find a short of any kind and there is continuity from pin 9 to the buffer chip and from the buffer chip to the IC17 ROM.
I am testing on a workbench and if I detach the driver board all the datalines are low, I don't know if this is normal or if it is a clue.
Tonight, I will test with Leon's test chip, I have already tested with Marco's and I get 1 long flash then a locked LED, if I am interpreting correctly it means that the first ROM is not testing correctly, but replacing the ROM makes no difference.

What if you take out ALL the roms, and as many socketed chips as you can? (including the CPU) and power it up. I'll try mine and see what kind of results I get on the address and data lines. I would think that without a CPU chip installed the lines would be Hi-Z.

#63 1 year ago
Quoted from SteveNZ:

I didn't have a chance to do more testing, the board just started to work again, there must be an intermittent connection or short on the board. Hard to find now, so I'll just wait until it fails again.
I have another board with a similar problem, but I am fairly sure the issue is caused by previous battery damage that was not cleaned up fully.

It drives me crazy when problems just go away like that, but I'm glad its at least working for now, and that you are finding the test ROMs useful.

Quoted from SteveNZ:

The title of this thread suggests the ROMs are for System 3, 4 and 6, but in the documents there is reference to System 7.
Can I use these ROMs for System 7? Which IC socket on the System 7 board should I insert the ROM into?

IC17 is normally a 2732 chip so yes, it would go there and the image would need to be doubled up on the chip.

I recently tested the ROMs on a system 7 Pharaoh. The MPU board had been modified to use a 2716 in the IC17 socket. Pharaoh also has 7 digit displays. Not sure if all 7's have seven digit displays. Anyway, I noticed a few irregularities. For one, the LEDs on the MPU board are flipped (so bottom is top and top is bottom). The 7 segment LED does some weird but harmless dancing around, and the 7 digit display signals are not compatible with the six digit. Numbers are jumbled up. So all of the ROMs that use displays are pretty much useless. The machine I was on had it's own issues and so I could not be certain the ROMs were functioning properly.

I really need to get a hold of a working system 7 board and go through the ROMs with a fine tooth comb. Then I could change the title of this thread

#65 1 year ago

The source code is not available for download.

2 weeks later
#73 1 year ago
Quoted from Theonlylilo:

Hi! Just simple questions: I have a 27256 rom, I can create the adapter, but I cannot understand how to select the specific test rom via dip switch
Then, I'm trying these amazing software (thanks Pincoder!!! ) on a partially working sys6 board. Test 01-Led is ok, also the test 02-Blanking but with 00-BUS I noticed that pin 9 (address A0) is LOW instead HIGH as it should be.. What can cause this wrong signal?
Thanks

The different tests can be accessed by setting the DIP switches to their binary value ie:

0000 = 00-bus
0001 = 01-leds
0010 = 02-blanking
0011 = 03-cmos
0100 = 04-ram1
0101 = 05-ram2
0110 = 06-ram3
0111 = 07-displays
1000 = 08-switches
1001 = 09-interrupts
1010 = 10-timer
1011 = 11-lamps
1100 = 12-solenoids
1101 = 13-sounds
1110 = 14-clear_cmos
1111 = 15-init_cmos

Note that 16-edit_cmos cannot be accessed since the 27256 chip can only hold 16 x 2K images

I still have no explanation for the LOW address lines on the 00-bus test. I had two lines that were low on my board and it works just fine. You would think it would be safe to assume that all boards should test the same here but clearly they do not.

You only need to run the 00-bus test if 01-leds fails. If that one passes, skip the 00-bus test and move on to 02-blanking and keep moving ahead.

2 weeks later
#74 11 months ago

Hi everyone, there's a new version of ROMs available:

http://pincoder.reversion.ca

This version adds two new ROMs: 17-transceivers and 18-bounce.

Craig

#76 11 months ago
Quoted from Stretch7:

Nice to see this being updated.... ill be trying this out in the near future

Nice to see people trying them out!

#78 11 months ago

Hi again!

Although not ALL of the ROMs have been ported to System 7, there are some available in the new beta version if anyone wants to use them. Mostly just the basics, RAM and CMOS tests etc, and are available in 2K (2716) and 4K (2732/2532) sizes.

I'll update the title of this thread once all of the system 7 ROMs are available in a standard release.

The beta version of the zip file contains support for system 7 as well as 3,4, 6.

You can find RELEASE and BETA versions here: http://pincoder.reversion.ca

Craig

3 months later
#86 8 months ago
Quoted from uofmer:

Hey Pincoder.... I finally got a chance to continue working on my dead MPU board for Flash and finally (with the help of your ROMs) I found the issue. The 7410 that decodes the read/write for the data buffers had one input not working, so when doing a read, it was OK, but on the write, the data transceivers were not being enabled at the right time so I would always write 0's . Never been so happy as seeing the LED blink!!! It wasn't an obvious failure - the IC wasn't hot, and the input pin was toggling correctly. Anyway, that was the only issue keeping the game from booting - now to do fix the drop targets and rebuild the flippers and I'll be a happy camper!
it made it nice to run the RAM and Light tests w/o enabling everything else at first with the Game ROMs.

That's freaking awesome!! Nice going on finding the problem!! I'm glad the ROMs came to be of some help! That was a pretty peculiar issue. Thanks for giving me some feedback on what kind of chip you needed

1 month later
#88 6 months ago

I'm glad you're putting these ROMs to use, and thanks for posting the video!

The LEDs should be flashing one at a time, top.. bottom..top..bottom.. etc.

From the looks of things the test ROM isn't actually being executed at all. The two LEDs come on simultaneously upon power up, and the test ROM then shuts them off and begins the test. Also, the sound you're hearing is from an uninitialized PIA on the driver board. When the ROM runs, it also initializes all of the PIAs right away.

So, from the looks of it, the MPU board is not even getting to the point where it starts to run code.

Things to test:

1 - Check for 4.9-5.2 Volts coming in to the MPU board (TP9-5V and TP10-GND).

2 - Ensure that the reset circuit is working. TP8 should go HIGH about 1 second after power up and stay that way. If it bounces up and down (continues to reset) both LEDs will probably flash each time (Though I've never had a bouncy reset signal so I'm guessing as to the outcome).

3 - Ensure the test ROM has been programmed correctly. If you look at the first page of bytes in each ROM image you will see the name of the ROM etc.

4 - Ensure the test ROM is in the IC17 socket, correctly inserted (notch end down) and all pins are inserted correctly, etc.

Let me know what you find

#90 6 months ago

Hmm. First off, when you switch the game on you should ALWAYS get power across TP9 and TP10. If you're not, then you need to look at the power supply. There are plenty of threads on this forum for that and I think you should start at verifying connectors, solder joints, and wiring associated with the power supply. The ROMs can be of no use if they can't be run in the first place. There is also a 12V supply coming into the MPU board. Check TP1 for that. It's unregulated so it could be higher than 12V.

Once you have consistent and reliable power then you can try running the LEDs test again. If it still doesnt run properly then take a second look at the reset circuit.

Secondly, the picture of the ROM dump you gave seems a little odd to me (incorrect/missing bytes perhaps?). I could be wrong, but to be sure load the original .bin file and look at it with the same viewer to see if it looks exactly the same. If so you're good to go.

I'll be releasing an updated version of ROMs in the next day or two but the ones you're using now are okay to use.

#91 6 months ago

Hi everyone, I've released a new version of pincoder ROMs that include support for System 7. I've also shortened the website URL.

Please head over to http://pincoder.ca and take a look. Your feedback is appreciated!

Thanks!

#93 6 months ago
Quoted from hailrazer:

Your site is not responding. Is it down?

It's up.. try again?

Also, note the URL change. It was http://pincoder.reversion.ca and now its http://pincoder.ca both should work, though the former will go away in a few months..

#95 6 months ago
Quoted from CanadianPinball:

You remind me of "Lindsey" and funny enough, he was from Alberta too!

Oh? Who's Lindsey?

#97 6 months ago

Cool! I'll check it out. Thanks!

#99 6 months ago
Quoted from EvanDickson:

Protip is that ROMs are ROMs, not BINs. Rewrote the chip as a rom and it passes test 1 with flying colors. Now the chips are all in the uv bath so I can rewrite the rest.

Interesting. What software and hardware are you using to program the chips? Typically BIN implies a straight copy and not some sort of translation. Did you have to rename the files to .rom or anything?

#103 6 months ago

Nice. Glad you figured it out. Have you gone through all the ROMs yet? It would be great if you could send me some feedback on your experience with the whole process of using them, and your thoughts on the documentation files.. do they make sense etc. Its always good to get a fresh set of eyes on things. Any comments you or anyone else has on using them is certainly appreciated and will help make them easier to use.

#105 6 months ago

Sure, a PM would be great! Glad you find the ROMs useful. I had fun writing them!

#106 6 months ago

Just ran a small update.. edits to documentation.. new version is 2019.04.07.1941

4 weeks later
#112 5 months ago

Thanks for the detailed information and positive feedback!

Before I can give you any detailed answers I'll need to know which game and system board are you running this on, and which schematics you are looking at.

To get you started in the right direction, the blanking signal should be showing up on PIA1 (PIA at address 2800) pin PA2 and waits for 3 clock cycles before toggling the pin.

#115 5 months ago
Quoted from Nusilor:

Just started making a diy selectable rom board, hopefully will finish tomorrow, off to bed for now.
Them 28c16 were never able to be programed on my 866ii plus. Received a 28c256 and worked first go
[quoted image]

Sweet! Let us know how it turns out!

#119 5 months ago

Actually the 2K-adapter.bin requires a 64K chip (32 chunks of 2K) and the 4K-adapter.bin requires a 128K chip (32 chunks of 4K).

Since you are using a 32K chip you will only get the first half of the 2K-adapter.bin image loaded onto it, or the first 1/4 of the 4K-adapter.bin image.

Of course, you can selectively pack your own image file using a concatenation of the single .bin files you want to use. Then Just write that file to your chip. If you don't end up filling all of the chunks just fill them with FFs.

Let me know if you need help creating your own file

#122 5 months ago
Quoted from Nusilor:

No i only have a 4 pos dip. 16 combinatons. I have a 28c256 that will get broken in to 16k chunks 256k÷16=16k
Would need a 5 pos dip for 32, but i only have a 4 pin.
Also whats the method to this madness
1000
1100
1110
1111
0111
0011
0001
1010
0101
1011
1101
0100
0010
0110
1001
0000
How do i figure out what selects what chunk
I think i should be fine making the file. Will i be fine putting in about 1-2k in, cant imagine it would select bang on every 16k. What im saying is will it read if there is a blank at the start.

The 28C256 is a 256k *bit* chip so you have to divide by 8 which gives you 32768 addresses of 8 bits each. Dividing 32K into 16 chunks means each chunk is 2K. You will have room on that chip for 16 images.

The numbers you listed (although not sorted) are binary 0-15 and would correspond to which 2K chunk you want to address in the chip. Depending on how you wire the DIP switches to the chip of course.

The purpose of the board you are making is to trick the MPU into thinking there is a single 2716/2816 chip in the socket you are plugging into. Setting the DIP switches means it will show a different 2K portion of the bigger chip to the MPU board. The MPU board will only ever be able to see one portion/chunk at a time.

So, any of the 2K chunks can contain nothing. But, if you select that chunk and turn on the game, it won't have anything to boot from. Selecting a chunk that contains a valid test ROM image will cause the MPU board to run the code contained in that chunk.

#123 5 months ago
Quoted from uncivil_engineer:

Since you have gotten these programs to work on a system 7 board, is there any reason why they won’t work on a System 9?

They might work as-is, but I doubt it. I am currently in the market for a system 9 game so that I can create a set for system 9. How quickly I'm able to adapt the existing code to system 9 depends on how much they actually changed on the board (mainly addresses, sizes, and quantities of PIAs, RAM, CMOS, etc). I believe they went into alphanumeric displays too, so I'd have to write a driver for that.

Is it okay to assume you have a sys9 game? If so, what do you think of the onboard diagnostics? If they're better than these ROMs there might not be any point to keep expanding this project.. Thoughts anyone?

#126 5 months ago
Quoted from uncivil_engineer:

Right now I am dealing with a dead system 9 Sorcerer. I think I may have a reset issue on the board. The onboard diagnostics work ok, unless you are like me and have a locked up board.
I don't think there was a whole lot of difference between the system 7 setup and the system 9 boards in terms of the PIA interface (both use 3). I think the biggest difference is in the memory size, CMOS, and obviously the sound section. However, if you get it to work with system 9, it will also work on System 11. You can actually use a System 11 board in a System 9 game in a pinch.

That's good to know thank you. Does an 11 board require any jumper changes to run a 9 game?

#127 5 months ago
Quoted from pincoder:

That's good to know thank you. Does an 11 board require any jumper changes to run a 9 game?

I'll take a look at the schematics for 9 and see about making a set of ROMs.

#129 5 months ago
Quoted from Nusilor:

ill do some reading on address lines. This seems to be the config,
dip 4 a11
dip 3 a12
dip 2 a13
dip 1 we
5v a14

Not quite..

The image I've attached is from a system 6 schematic showing the pinout of the IC17 socket. Pin 21 (WE) is tied to ground and pin 20 (CS1) is used to select the chip.

So:

- Pin 20 from the IC17 socket should be connected to the output enable of whatever chip you decide to use.

- You then tie A0 through A10 to the new chip.

- A11 and up on the new chip should each be tied to a DIP switch. A11 to rightmost DIP, A12 to the left of that.. until you have no more address lines to connect on the new chip. If you have more address lines than DIP switches you CAN tie them to ground, but that would be a waste. Get more DIP switches.

- 5V pin on the new chip should be connected to pin 24 on the IC17 socket. Ground to connected to pin 12 on the IC17 socket.

- Data lines are straight forward and connect one for one.

Hope that clears things up
2816-MPU (resized).png

#132 5 months ago
Quoted from Nusilor:

sweet. it actually reads in my rom burner.

Nice going!

#136 5 months ago
Quoted from stangbat:

Crap, I made a board based on the original picture. Haven't tried it yet. So you're saying I need to re-wire it based on your corrections?

I have no idea myself, on either board as I didn't create them and not all of the information is available based on the pictures.

But, if you follow the design outline I gave in my previous message, you ought to be able to make a board with any chip size from 4k to 64k bytes. nusilor can you post any other connection details I missed? Ie the tie up/down resistors and what to do with the extra chip selects of the new chip, if any?

If I get some time down the road I'll write a how to and provide a 64k board sample. I may even build a batch and put them up for sale, preloaded with the adapter image..

Oh and thanks nusilor for providing the details in how you did your board!

#138 5 months ago
Quoted from Nusilor:

pincoder You explained it perfect
stangbat Heres a pinout of both chips from the respective data sheets so you can picture what we are talking about, and come to your own conclusion.
As you can see if you line the pins up from the bottom, and let the top 4 pins hang out on the 256:
WE(lines up with a11) and VCC(+5v(lines up with a13) don't line up, so jumpers need to be run.
Then the address lines 11,12,13,14 need to be put on the dips for selection. weather it is pulled up(+5v(1) or down(GND(0) makes the selection
Im sure that the 512Kbit(64k) chip would be as simple as adding a15(probably) to the pull up resistor network. on another dip switch[quoted image]

I'm not certain this is quite right either. Specifically, we, or, and ce should be connected to their respective pins on the new chip.

@nusilor can you verify the board in your chip programmer as a 2716 and use the dips to select each image?

#141 5 months ago

Awesome. That's much clearer

You shouldnt have to add numbers to the ROM images though to test this part.. Each image has it's name written into the header.. Should be visible in an ascii viewer.

Thanks for clarifying and posting your work. I'm glad you got it working!

#147 5 months ago
Quoted from Nusilor:

also how do you make the socket divide in to 4k chunks

2^12=4096

Since address lines start at A0 (and not 1) you untie A11 from the DIP switches and connect it to a socket that has A11 (ie a socket for a 2732/2532 (4k) chip).

#148 5 months ago
Quoted from denoument:

I'm working on a project pin and these roms are helping out a lot. I think the blanking.txt calls out the wrong pins. Instead of "IC7 pin 6" it should be "IC7 pin 8". Instead of "IC12 Pin12" it should be "IC23 pin 12".

You are correct for system 4 boards. Thanks for pointing it out. There is a small difference in the blanking circuit between system 6 and system 4.

Here is a revised paragraph for 02-blanking.txt:

Check for pulsing signals on (in this order):

* PIA1 Pin4 - If not pulsing then replace PIA1 (oscilloscope users: pulses at 120hz)

* System 6: IC7 Pin6 - If not pulsing then replace IC7

* System 4: IC7 Pin10, Pin9, Pin8 - If not pulsing then replace IC7

* IC23 Pin12 - If not pulsing then replace Q5

Sorry about the confusion. The paragraph has been updated for the next release.

#150 5 months ago
Quoted from Nusilor:

So if i put a 4k chip in a system 6. its only going to be using
the last 2k since it runs a11 to to 5v. pin 23. Which is the same
as fliping a dip 1

Correct. But for a 2732 it's pin 21 not 23. Here's the pinouts for 2716 (2K) and up:
CERDIP-PINS (resized).png

Note that Pin numbers change for 2764 and up, since they have more pins..

#159 5 months ago
Quoted from Nusilor:

Sorry was just looking at the data sheet for a 27c1024. they are 16x64kbit 16 address pins(including a0). So will only break down in to 8K(64kbit)chunks. That is in a 4k slot. I believe it will break down in to 32 in a 2k

In choosing a chip, you should stick to 8 bit chips (Chips with D0-D8) 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!

1 month later
#168 3 months ago

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.

#171 3 months ago

Awesome thank you!!

1 week later
#174 3 months ago
Quoted from Cheddar:

Hey guys, I have a results question. With 2 sets of verified roms (barracora) I get the following results:
Boots to 0, goes out, 8 shows on the LED, then 0 stays on
Press the diagnostic and I get a 5
The displays do not come on.
After doing the CMOS Test I did the CMOS init. Could the 8 be not having a battery pack attached?
I have tested the CMOS ram several times with the pincoder test and it passes every time.
Is the next step to replace the 5101 ram?

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

#176 3 months ago
Quoted from Cheddar:

I ran the clear cmos rom and still get the same result.
I've put it aside while I do more research. I am working on another sys7 (I have 2 that don't work) board that boots just fine except it doesn't start the attract mode. I can enter diagnostics so clearly it's running. I can execute the tests. Still looking into this one too.

Interesting. Keep me posted.

#179 3 months ago
Quoted from SYS6:

Another way to check for the same default cmos values to just read the manuals and compare values for each of the setting numbers. A quick look over a few games eg say comparing Gorgar and Firepower shows they are quite different in the game specific ones, say from location #30 onwards.
edit: Thinking about this, unless I'm missing something, I don't get how this can be practical as each cmos setting file must be different for each game as the first setting is the game ID. Isn't it easier to use the clear cmos test then boot to the game to reload defaults for the game you have or use the edit_cmos routine.

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..

1 week later
#181 3 months ago

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).

#186 3 months ago
Quoted from dextrose42:

This board had a bad address driver (bottom right corner, N8T97N) and apparently there was an issue with the socket. I reflowed the socket and it appears to be working now.
Thank you for providing the test roms.

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

#187 3 months ago
Quoted from Cheddar:

2 posts in 1:
1. pincoder thanks for making these ROMs. When you announced them I couldn't understand why anyone would want to burn so many ROMs. Now that I have used them to fix a board set I completely understand. The ability to jump to a specific rom and diagnose a specific issue was perfect!
2. I had a particular problem to solve. I have 3 sys 7 machines, 1 working board set, 3 non-working system 7 sets and a RD mpu327. The RD allowed me to get Barracora up and running but left my time fantasy and my buddies laser cue down until I could get another working set.
Things I learned:
1. Don't even try without a known working driver board
2. ROMs may burn and verify but that's not a guarantee. When in doubt try another. The PC test ROMs were invaluable here
3. Verify the jumpers on the board. 3 system 7 boards, 3 different jumper configs!
4. I'd still like to find a theory of operations for this board. The 1 thing I was certain of on all these boards is they were resetting correctly. It difficult to know what to expect between reset and attract.
Whew that was a lot. I have 2 more boards to fix. I'm going to make some videos of the test ROMs in use to share as thanks.

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!

#189 88 days ago
Quoted from Cheddar:

Here is the first set of short videos. I have a couple missing I need to redo and then another half dozen I haven't done because I didn't need those roms for my last board. I'll work on adding those to the playlist as I make them.
https://www.youtube.com/playlist?list=PLtGB2hX0oWQT_eIL4mvQg1mNrVZWnpJz5
also I have a clamp on camera mount coming that should remove the shakycam

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

Thanks for adding them!

1 month later
#190 55 days ago

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!

1 month later
#191 19 days ago

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.

1 week later
#193 12 days ago
Quoted from kevinclark:

pincoder The docs on 01b-bus look very clear now. I'm curious about the voltage you say you expect though. I'm seeing ~4.8V on the 5V terminal on my PSU breakout board without it connected to anything. If I measure the voltage against the alligator clips on the IJ2 ground pin and 5v I'm seeing 4.1V. Board seems to boot ok, but I'm wondering where the 0.7V are going. Possible that's just crappy wires, or should I suspect something else?

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.

#194 11 days ago
Quoted from kevinclark:

pincoder The docs on 01b-bus look very clear now. I'm curious about the voltage you say you expect though. I'm seeing ~4.8V on the 5V terminal on my PSU breakout board without it connected to anything. If I measure the voltage against the alligator clips on the IJ2 ground pin and 5v I'm seeing 4.1V. Board seems to boot ok, but I'm wondering where the 0.7V are going. Possible that's just crappy wires, or should I suspect something else?

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.

Promoted items from the Pinside Marketplace
750 (OBO)
Machine - For Sale
Louisville, KY
$ 79.95
Cabinet - Shooter Rods
Super Skill Shot Shop
$ 79.95
Cabinet - Shooter Rods
Super Skill Shot Shop
$ 5,799.00
Pinball Machine
Operation Pinball
1,100
Machine - For Sale
Rockford, IL

You're currently viewing posts by Pinsider pincoder.
Click here to go back to viewing the entire thread.

Hey there! Got a moment?

Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside