User GIBO over on the Aussie Arcade Pinball Forum has posted that he has a mod available for Stern Pinball machines purchased from the USA to be used in other countries and machines bought from other countries to be used within the USA.
The mod is made for the Spike2 system and from the looks of the image, there is no soldering required which is a real bonus for those who do not have the best soldering skills.
GIBO also has pictures of another mod in the same thread which he says will work with the Spike1 and SAM systems.
The first time I put this board onto the workbench to have a look at it, there was a bit of corrosion on a few ICs. So before starting I gave the board a wash with SafeWash and then rinsed it off with Electronic Board Cleaner dried if off thoroughly. This removed the bulk of the corrosion and cleaned all the dirt and grime from the board.
Next I moved onto removing the ICs which had corrosion on them and replaced them. This included replacing G12, G13, G19 and F10.
With the corrosion taken care of, I moved onto the eproms and checked them in the programmer. The IC at E24 tested fine, but the IC in C24 was not even from Aliens. So I pulled out a new 27C010 and programmed a new eprom and installed it.
Powering up the system resulted in a constant reset loop. I tested the voltage at some of the ICs and found that I was only getting about 4.7 volts. The Jamma connector on the board was very badly worn, so I increased the voltage on the bench power supply until I had close to 5v at the logic ICs.
Increasing the voltage stopped the board from resetting so rapidly, which was being caused by the power watchdog built into the 051550 module. However it was still rebooting. So it was time to start at the beginning and ensure that the system clock was running.
Firing up the CRO I was happy to see a steady 24MHz at pin 6 and 8 of IC G11. Next I checked around the 74245 at G19 to see if there was data between the CPU, SRAM and ROMs. Both sides of the 245 appeared to be quite active, so it was time to move onto the SRAM IC at locations G21 and G23 respectively.
The SRAM at G21 appeared to be working fine, but checking around G23 with the logic probe showed no activity at all on any of the data lines. I piggybacked G23 with a new SRAM and probed the data lines again, and this time there was plenty of activity. So I removed the faulty IC and installed the replacement.
After powering up the board again I was greeted with the garbled screen with colour. It appeared as though the board was trying to run, but the video was bad. So I checked around the video SRAM at E14 and E15 and found the ram at E15 to have a number of dead data lines. I replaced the 16kb SRAM and fired up the board once again. This time the board came up with the test screen showing all the RAM and ROMs as being OK. I turned dip switch 3 on bank 3 to off and power cycled the board again and this time I was greeted with the game.
Letting the game run a bit and turning on sound in attract mode I noticed that there appeared to be some sounds missing. So I programmed a new IC for position D5 and replaced the original mask rom and the final issue was resolved.
When I first got this board onto the bench and powered it up all I got was a chirp from the speakers every second or so as the board was stuck in a reset loop.
Starting at the beginning, I checked that I had a working clock and that I have 5v at the logic chips. They both checked out ok, so I started to probe around the buffers and rams and found a lot of floating pins on the video ram at locations F14 and F15. These chips were removed and tested and confirmed to be dead. So new rams were installed and the board was powered on again.
As expected this did not change the actual fault, but now I was getting a screen flash up each time the board reset. I checked the other rams and found that the one at position F3 was also showing a lot of floating pins.
I removed this ram and tested it in the programmer and it too was dead. So a new chip was installed and the board powered up again. This time the fault changed to a ROM check screen showing that chips K06 and K07 (locations K13 and K19 respectively) were bad. Great I was making progress.
I started checking around those roms and noticed that they were addressed by the custom IC 052109. I also noted that there was two SRAMs which also went to the same custom IC. Checking around the rams showed that I had a number of inactive data lines on the rams. I traced the data lines between the ram and the custom IC and found there was 2 lines which were open circuit. Once again corrosion had eaten through some vias. Unfortunately they were both directly underneath this custom chip.
Although I do no like having to remove these custom chips, it was either remove it and repair the vias, or run fairly long wires to the custom chip which I do not think looks very good from a repair stand point.
So off the chip came and now I was able to see just how bad these vias were. There was almost no copper left, even inside the hole itself. So I cleaned up the holes and removed the solder mask on the tracks on the top and bottom of the board and ran some new copper track through the holes and soldered them in place.
Finally putting some new solder mask over the repair to protect it from corroding again.
Before reinstalling the custom IC, I decided it prudent to check all the connections from the 120 pin custom IC to ensure there was no more broken vias. It took a couple of hours to go around all the pins and trace them out, but it was time well spent as I did find another couple of corroded vias which were no longer connected. Repairing these final couple of vias I was ready to reinstall the custom IC.
I reinstalled the custom IC and fitted sockets for the mask roms at K13 and K19 and prepared to power up the board again and see if my repairs had been successful. Powering it on again, I was greeted with a rom test screen showing me that the roms were ok.
Success! I turned off the test dip switch and power cycled the board expecting to be greeted with yet more faults, but low and behold, the game was working.
There was no sound, so turning on dip switch 8 on bank 2 and powering up the board again confirmed that the audio was also working. However there was quite a bit of hum in the audio. These old boards have a habit of having the 12v filter capacitors damaged during handling and storing. So I replaced the capacitor and fired it up again, and this time the hum was gone. Another successful repair and thanks to taking that extra bit of time and effort, the board still looks like its hardly been worked on.
The first time I powered up the system it was totally dead. No video and the CPU would try to start then halt.
I removed and checked the main EPROMs 18E, 18G, 8E and 8G and was happy to find that they all verified ok, but all of them had bent legs which had missed the socket and folded up underneath the IC. Luckily the legs did not break off when straightening them out and reinserting them into their respective sockets.
Unfortunately someone had attempted a repair in the video section and had removed the SRAM and buffers at 11D, 12D, 13D and 14D. When removing those ICs they had damaged a number of traces. They had attempted to repair the traces, however their repair was far from successful as they had connected traces to the wrong locations.
I removed all these ICs again and repaired all the traces and installed IC sockets. I also tested the SRAM and the buffers and found that one of each of was faulty, which was not at all surprising seeing as they were Fujitsu branded, so I replaced them with new ICs.
Happy that the previous repair attempt was now fixed, I moved to looking at the reason it was not booting. Checking the buffers at 13F and 14F showed data on the inputs but all the output lines were totally dead. Once again, they were Fujitsu, I removed and tested these buffers and they were both dead, so I replaced them and the system now booted, coming up with an error on the screen “EEPROM BIT CHECK BAD”.
I checked the serial eeprom at 15B and found that there was no activity so whatever was meant to be reading it was not working. Referring to the schematic shows that the eeprom is addressed by the 74273 at location 15C.
I piggy backed the 273 and checked around the eeprom again with the logic probe and this time I had a clock on pin 6, but other lines were still inactive. Not really all that surprising, so I removed and replaced the Fujitsu 74273 and then system booted past the eeprom bit check bad error and gave me a new error to investigate.
At first I was greeted with a checking eeprom screen. At this point I was thinking I had been lucky and the board was fixed, but that was not to be the case.
After about 10 seconds another screen saying eeprom initialize complete displayed.
Then finally I was greeted with an error message saying that the test switch was still on.
A quick check of the schematic shows that the test switch goes into pin 13 of IC 18C and the data line goes out on pin 12.
Probing those lines showed that the input was working fine, but the output had no activity. Time to replace another faulty Fujitsu IC.
This time around the board booted to display the rom and ram check screen. Unfortunately it showed 2G and 3G were bad.
I began probing around those suspected bad SRAMs with the logic probe and found almost no activity whatsoever. Unfortunately the schematic I had did not show these SRAMs so I was unsure of where they went. However I had a hunch that two buffers at locations 8J and 8K probably had something to do with them and that they were likely to be faulty seeing as they were yet again, you guessed it, Fujitsu. So I piggy backed these two ICs, and this time I was greeted with a game screen. I replaced the buffers and turned the system back on and this time, I had no green or blue. It turned out that a number of 7407s at locations 8C, 9C, 10C, 11C and 12C had failed while I had been performing the repair. Not all that surprising given that they are all also Fujitsu. Rather than replacing just the faulty ones, I just replaced all of them which gave me back all the colours.
Now the game was running, but I could see there was still another fault. On certain screens there was a black bar.
Now the game was working I could go into the menu and test the mask roms to see if that was the problem. Unfortunately that was not to be. When pressing the test button, I could get into test, but the start button would not work. You guessed it, time to replace more Fujitsu ICs. After replacing most of the 74253 and 74257 ICs at locations 13B, 14B, 16C, 17C and 19C I was finally able to run the mask rom test and was surprised when it returned ok for all the roms.
Given the roms were all testing ok, I decided to review the schematic again and this time I notice the 74164 at location 16D, a serial in, parallel out shift register, of which output pin 11 goes to pin 7 on all three colour modules through a 7407.
I put the logic probe onto pin 11 of IC 16D and found it to be totally dead. Checking the inputs on pin 1 and 2 showed plenty of activity. So I removed the ic and tested it in the programmer and sure enough it was completely dead. Replacing the 74164 with a new one, I powered up the system once again and this time it was working properly.
I have reproduced the Konami modules for the below games. Replacing these modules has become a must as the original modules are covered in a conformal coating and the surface mount electrolytic capacitors are failing and corroding the very thin tracks away. Left for long enough they will even damage the game board that they are installed in.
The modules do not come with the DAC or the ASIC chips, they need to be taken off the old module and installed onto the new one, so being comfortable with surface mount rework is a must to successfully change this module.
These reproduction boards have been designed so that all components are located on the top side of the board, unlike the original board and some of the other reproductions out there which has components on both the top and bottom of the board. Our modules use only Tantalum capacitors which eliminates the possibility of capacitors leaking corrosive materials in the event of failure.
Did I really just deliberately quote Monty Python in the title for this post? Yes, I certainly did. I use the quote to deliberately highlight that actual facts are the real casualty when it comes to the world wide main stream coverage of Climate Change.
The blame is being targeted squarely at CO2, a gas which cant be seen, tasted or smelt, yet is required for life to exist. A fact which I do not think I have ever seen reported is that there has been much higher levels of CO2 in the atmosphere in the earth's history. According to information on Wikipedia, levels have been as high as 6000 - 7000ppmv. Was mankind the cause of the increase in CO2 previously or was it simply the earth's ecosystem doing what it does and has continued to do for millions of years?
This page will contain links to actual information which is publicly available, yet is not reported by the main stream media. Whether this failure to report is due to them not wanting to go against some political agenda, an unwillingness to check the information is actually factual or some other reason I do not know and I am not going to speculate. I will likely be labelled as a climate denier, working for the oil companies or some how being associated or funded by the fossil fuel industry for posting this information.
One really good video which everyone should watch is by Physicists Willie Soon and Elliott Bloom. They talk extensively about many different aspects of Climate Change and the misinformation being reported.
A very interesting video is on the Youtube channel Conversations That Matter with Dr Patrick Moore where Dr Moore talks about the Carbon Dioxide. He discusses that over the previous 600 million years, for which we have a reasonable record, the earth reached a level of only 180ppmv which is just 30ppmv above the death of plants.
According to Michael Mann and his hockey stick graph, which is widely used by the IPCC and main stream media in general, the earth has been in an incredible major heating event for many years. Yet an investigation by Climate Discussion Nexus Hide The Decline has revealed many discrepancies and omissions along with what could only really be called fraudulent behaviour.
Further to the investigation on the Mann hockey stick graph, the Climate Discussion Nexus also did an investigation into the saying 97% of the workds scientists agree on the science.
Professor Roy Spencer spoke at a conference in July 2019. He talks about the actual recorded data and the dependencies between the climate models and the observed data from the troposphere. He discusses that the climate models show that the warming should be higher in the troposphere than anywhere else. Over the 40 years of recordings, the data shows a 0.13C rise per decade, or a faction of a hundredth of a degree per year.
Below is a slide from Professor Roy Spencer's talk which shows tha actual observations recorded, being the thicker red and blue lines and the thick green line being the reanalysis of all the observable data, versus the climate models with an average of all 102 models being the thick black line.
An informative talk about Climate Change is by Steven F. Hayward, Pepperdine University He talks extensively about the realities of what would be have to be achieved to actually meet the targets which are being pushed onto us.
Sir Richard Attenborough is very well known for his wildlife and planet documentaries and most people would not think there was a need to fact check anything which he says, yet a recent video shows the many failures of the Sir Richard Attenborough and his team to check the facts about what he is narrating and is well worth a watch. After seeing the errors and traumatising images shown in some of these documentaries, its not surprising there are so many children with the so called eco-aniexty, and are so brainwashed into believing the narrative which is being fed to them by main stream media and even the education system. Critical thinking used to be taught as a good thing, yet now you are not permitted to question Climate Change in the classroom. I used to have a lot of respect for Sir David Attenborough, but that respect has diminished over recent years due to the factually incorrect information which he is spreading and continues to push to the public in general.
This page is dedicated to listing any equivalent or replacement components which I come across. Like the post dedicated to the DAP008 which turns out to be a perfect replacement for the LD7575 pwm. If there is a datasheet available, you will be able to click the part number to view it.
I recently had a job which required me to utilise a bunch of Microchip's MCP23017 16-Bit I/O Expander with Serial Interface. I needed to use a web interface to control the I/O ports, and after spending a bit of time looking around online, I found quite a number of Python modules and a few written in C, but not a lot for php. Dont get me wrong, there are a few around, but most of the ones I found are integrated into other systems and I gave up looking at splitting the code out and ended up writing my own. I decided to post the code to GitHub under the GPL3 license for others to use for free if they choose to.
The module uses the i2c-tools. The README.md file on GitHub provides details on how to install these tools, and how to add the apache webserver to the i2c group so it has permission to read and write from the i2c bus.
Over the weekend we were notified that our Windows DNS servers were being used in a "Open recursive resolver used for an attack". This is really a mistake on our part for putting the authoritative and recursive services on the internet facing systems, something we will have to change. Also because Windows DNS does not have ACL's like those that exist in Bind and PowerDNS etc, its not a simple case of adding the authorised ranges to the ACL allow recursion.
What I ended up doing was to write a couple of IPS rules to match requests with the DNS Query Flags of 0x0100. I also check for more than 5 requests per minute per source IP and when I get a match to both, I quarantine the source IP for a period of time. Since implementing this it has been working extremely well. I have only applied this rule to the rules pointing to our Windows DNS Servers and not our Linux DNS Servers.
This is the flags of a recursive DNS query.
Here is how its done from the command line. Note this is on FortiOS Version 5.0 patch12
config ips custom
set action block
set comment ''
set severity info
set signature "F-SBID( --attack_id 8976; --name \"MS.DNS.Recursion.Requested\"; --ipver 4; --protocol udp; --service DNS; --pattern |0100|; --distance 2,packet; --flow from_client; --rate 5,60; --within 2,packet; --track src_ip; --log dns_query;)"
set action block
set comment ''
set severity info
set signature "F-SBID( --attack_id 7731; --name \"MS.DNS.Recursion.Requested.V6\"; --ipver 6; --protocol udp; --service DNS; --pattern |0100|; --distance 2,packet; --flow from_client; --rate 5,60;--within 2,packet; --track src_ip; --log dns_query;)"
Now to add the IPS Sensor rule.
config ips sensor
edit "Windows DNS Servers"
set comment "Block clients that are not authorised for DNS queries"
set action block
set log-packet enable
set quarantine attacker
set quarantine-expiry 60
set rule 8976 7731
set status enable
set action block
set log-packet enable
set protocol DNS
set quarantine attacker
set quarantine-expiry 30
set severity medium high critical
set status enable
set protocol DNS
set severity info low
Finally the Firewall rule.
config firewall policy
set srcintf "wan1"
set dstintf "LACP1"
set srcaddr "all"
set dstaddr "Windows DNS" set action accept
set schedule "always"
set service "DNS"
set utm-status enable
set ips-sensor "Windows DNS Servers"
set profile-protocol-options "default"