Jump to content

Womble

Veteran
  • Posts

    5,632
  • Joined

  • Last visited

  • Days Won

    5

Womble last won the day on December 7 2020

Womble had the most liked content!

Personal Information

  • State
    Victoria
  • Machines in your collection
    Atari Paperboy
    Atari Vindicators
    Atari Star Wars Cockpit
    LAI Generic JAMMA Cab

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Womble's Achievements

Pinball Wizard

Pinball Wizard (16/17)

  • First Post
  • Posting Machine Rare
  • Collaborator
  • Conversation Starter
  • Reacting Well Rare

Recent Badges

9.2k

Reputation

1

Community Answers

  1. That's just a coil, looks pretty normal. Check that the video ground connection between the PCB and the monitor is still good. Normally its far worse than this if it is missing but if it is hanging on by a thread you can get weird effects.
  2. Looks like the degauss loop is continuously energised. With the cabinet powered off and unplugged from the wall, take a look at the monitor chassis and find the posistor like in this picture. Next to it will be the degauss coil connector, a 2 pin plug that goes to a stiff wire loop strung around the back of the screen. Unplug that and make sure it is secured somewhere. Then power up and see if the screen shaking is cured. They can be quite stiff but it's just pushed onto two pins on the board. Be very careful your hand doesn't bash into the neck when it finally lets go or you risk trashing the tube.
  3. It's been a while since I have done a write up, mainly because they can take as long as the actual repair to put together, plus most aren't that interesting as write-ups, but this one was bit fruity - a Super Hang On PCB set from a cabinet restoration that another AAer is doing. I got some detailed photos of the boards condition beforehand as Sega boards can be riddled with track rot and unfixable, but this one was pretty mint. The usual suspect on Sega PCBs from this era is the big black Hitachi module in the master CPU socket, often a FD1094A, or a FD1089B in this case. These are the infamous suicide modules, a form of 1980s copy protection, to stop operators from upgrading to a newer game by burning a different set of EPROMs. While you could copy the ROMs from one game to another you'd need a decryption module with the right key in it to actually get the game to boot. Putting in a standard 68000 CPU was no better than putting in an FD1094 bock with the wrong encryption key, unless you had a way to decrypt the code. So the only way to get the latest game was to buy the official board from Sega as even if you could get hold of a spare module you'd still need the right encryption key and a way to load it into the module. Eventually the keys were reverse engineered (in the mid 1990s), but only very recently (2018) have the modules themselves been reverse engineered, to the extent that a dead FD1089 can be revived and reprogrammed with a new key. Check out the blog post by a guy called Arcade Hacker if you want to know what's inside these blocks, its hardcore stuff. Anyway, along with lots of photos of the boards there was also a spare 68000 CPU and a set of 4 EPROMs... ...which is a de-suicide kit for the board, EPROMs containing the unencrypted game code, and a normal 68000 CPU to replace the FD1089. As it looked like these had never been fitted the owner swapped them into the board along with the 68000, to check if that was the only problem, but the board was still dead. So it arrived on the bench for some TLC. The 1089B module has a lid that's easily unclipped, unlike the FD1094 which has a metal plate glued on, but both are much the same inside, space for 3 batteries but only ever one used, and wires disappearing into the block. In this one the date code on the battery was January 1987... … so no surprise it was dead, with volts so low that this would have died a long time ago. A few things to note on first inspection, firstly a lone 27c256 EPROM in at location at IC56. This doesn't belong on the board, if it did there would need to be another ROM in the empty socket to the right, at IC74. These 6 sockets are the program code for the main CPU and each of these ROMs contributes 8 bits of data towards the 16 bits on data bus, so only having one makes no sense. It does contain code that is part of the Super Hang-On ROM set, but I'm pretty sure it for another board configuration. In fact the MAME ROM set "SHANGON" is a bit of a tangle, with all sorts of files that don't make sense for this board. It wouldn't be the cause of a dead board as the program code doesn't address the space where those ROM sockets would sit in the address space. Some good news is the board doesn't have the hugely problematic TMM2063 64KB SRAMs anywhere, instead using ASAHI brand, which gave more hope this wasn't dead due to galloping RAM failures. There were also only 3 Fujitsu TTLs on the board, again very good news from a future reliability perspective. With low numbers of Fujitsu TTLs I opt to just replace them all, dead or not. The only other oddity was a single TTL IC in a socket at IC105, socketed TTL which is usually a sign that someone has been trying to fix the board before, but this was totally original, and a handy way to disable the watchdog circuit without resorting to desoldering one end of the zero ohm resistor R5. With my power and video harness hooked up I flicked the switch and yes it was pretty dead, but not totally, the board would give very brief flashes of white lines on the screen on a regular basis. (Yep the toyroom is a mess, it's always a mess) This is the sign of a Sega board trying to reboot itself due to the watchdog circuit firing. The watchdog is a timer circuit that the game code has to constantly reset every few milliseconds or it will pull the master reset line to logic low which will reset all the CPUs on board. It's there to allow the board to recover from a game crash without needing a human to power-cycle the entire cabinet, otherwise the game sit there in a wedged state unable to slurp up players coins. For a random crash this works well, but a faulty board it will sit there constantly resetting for ever. First step was to go over the board with the oscilloscope looking at the usual suspects, but aside from a dead 74LS109 in the road section I couldn't find anything by cruising around. There are two 74LS109 on the board and neither should break the boards ability to boot, you'd get weird faults like a static road if IC102 is bad, or a road that is totally missing if IC7 bad, but the main CPU doesn't care about either of those so that wasn't the main fault I was chasing. Super Hang-On uses the same CPU board as Outrun, just paired with a simpler video board, as the game doesn't have as much sprite or object data. For some reason I ended up with 6 Outrun board sets last year in quick succession so I got to know the CPU board quite well. One major difference between Outrun and Super Hang-On is that Outrun actually draws two roads, as there are two carriageways on screen that merge into one 6 lane highway, and then diverge at the end of the level where you get to choose the left or right track. Super Hang-On only draws one road, so the left half of the road logic on the board is unused, which is why there only one road ROM and an empty socket where the left road ROM would be on an Outrun board. By swapping the Super Hang-On CPU roms to the Outrun test ROMs, and plugging it into my own Outrun video board I could quickly test the CPU board, both CPU buses, all the bus transceivers and line drivers that the CPU board uses to talk to the graphics board, basically a tonne of stuff in one go. The board passed with flying colours, mostly. The ROAD LSB and MSB errors (least and most significant bit) were just from the fault I'd already found in the road section due to the dead 74LS109, but that wasn't the fault that had downed the board. Usually you find these boards will loads of RAM errors in the Main, Sub or Palette sections, but this was all clear. This suggested that the fault was on the video board, but converting an Outrun CPU PCB to Super Hang-On and pairing it with the Super Hang On video board got me a working Super Hang-On board set. So I had just proved that the CPU board was OK and that the video board was also OK but putting them back together gave me a dead board set again. Weird! I'd already eye-balled the pins in the board interconnects as squashed or missing pins can happen, but all the connector pins were there and with no signs of corrosion. It's possible but unlikely that the Outrun code somehow doesn't touch all the areas that Super Hang-On does, especially as Outrun is much more complex, so in theory gives the hardware more of a workout. Time to wheel out the big gun, the Fluke 9010A and a 68000 pod from 1982. This is pure overkill for a lot of board repair, but for a PCB that won't boot and gives no clues as to why it is the weapon of choice. On any PCB the CPU can only execute the instructions that it can fetch from the ROMs via the PCB tracks, sockets and control logic ICs. These instructions are all very low level operations like fetching a byte, or a word in the case of the 68000 and doing something with it, such as moving things in and out or registers, reading and writing from RAM, or doing mathematical operations on numbers that the instructions have pulled in. If these instructions make sense and keep up with the housekeeping, like maintaining the stack, then the CPU will just keep working away. If the instructions don't make sense then the CPU will just crash, and end up in a hung state unable to do anything, often with the address and data lines doing odd things. On a faulty board you probably only have a few milliseconds before the crash, and then a few milliseconds of quiet time before the watchdog restarts it all, leaving you with a twitching system thrashing around in a mess, very hard to work on when using a scope or logic probe. The CPU has no choice in what it will or won't do, it just ploughs blindly on, but the Fluke 9010a lets you become the CPU and have that free will. With that control you can perform all sorts of operations with no way to lock yourself out, and run a load of built in tests, if you know the memory map for the board. You can also ignore all the things which would stop a normal CPU in its tracks, like the the watchdog pulling the /RESET line low, or the other CPUs on the board asserting the /HALT line if they see a bus error. The main benefit is that you can test exactly what a real CPU would be able to do from the actual socket it would be sat in, proving everything from the socket itself all the way through the glue logic to the RAM and ROM blocks out in the memory space. On complex boards there is a tonne of logic that controls the addressing logic, read/write modes, and output enables, where any fault can easily brick a board and being able to validate all that quickly is really useful. So I pulled out the 9010A and the 68000 CPU interface pod and ran straight into the first problem, the 315-5195 Memory Mapper IC. The problem is that these boards are software configurable, and first thing the CPU does when the board boots is to run a short piece of code in ROM that write values into certain registers within the 315-5195 to configure the board. That sets up the board so the later stages of the program can access all the blocks of RAM and ROM that aren't connected before the mapper is programmed. So if a board is so bricked that it can't run any code then it can't configure itself to the point where you could use a Fluke 9010 to test the RAM and ROM areas that a CPU on a fully working board would see. While this looks like another bear-trap for bootleggers I suspect it was an attempt by Sega to future-proof the platform, potentially make software development easier, but mainly to make the PCBs far cheaper to manufacture. Basically it is an implementation of virtual memory, allowing the CPU to think it has it's full memory space available, but in fact the mapper IC is intercepting what the CPU asks for and silently diverts it off to the right hardware, leaving the CPU unaware that most of the memory space it thinks it has doesn't actually exist in hardware. The 68000 CPU has a whopping 16MB of address space defined by the 24 pins of the address bus. Games like Outrun and SHO don't need anywhere near that amount of space, but I suspect Sega had plans to use the platform for many more titles than the four that were ever actually released for it, with future games using up more space. On System 16B hardware the logical layout is apparently divided into multiple regions, and it is probably the same for the Outrun family of boards. Region 0 - Program ROM Region 1 and 2 can be used for additional program ROMs or other hardware. Region 3 - 68000 work RAM Region 4 - Text/tile RAM Region 5 - Object RAM Region 6 - Color RAM Region 7 - I/O area So, the memory mapper IC is hooked up to the full 24 address lines and the CPU control signals, and is used to convert it into 16 bit bus and a load of chip select lines which head off to the various slabs of RAM and ROM on the board. This seems like a lot of hard work but as a 24 bit bus needs 24 address lines, and 3 of whatever octal logic is used on the bus (e.g. transceivers, line drivers, latches) a 1/3 reduction in lines and chip count is a significant saving on PCB layout and parts costs. PCB production at the time was incredibly expensive so it would have been insane to physically layout 16MB of address space, especially for a game that used less than 2MB all up. Production costs, and additional PCB layers were certainly avoided but it presented me with a problem. I had no way to know if the board was able to configure the memory mapper before crashing and the watchdog jumping in, which also resets the mapper IC. In retrospect, knowing the actual fault I'd say the board probably was able to do this, and I probably could have used the Fluke to run the board as if it was a normal CPU and let it crash. I could probably have manually taken over leaving the mapper registers intact, but I would have had to have disabled the watchdog circuit on the board. At the time I had set the Fluke up to ignore the watchdog, but the mapper IC would have been reset instantly, losing the board config. I opted to go down the rabbit hole, to dig into how the mapper sets up the board. MAME would look like a logical place to start, but I'm not sure it bothers with emulating the mapper as it solves a hardware problem which doesn't exist when the whole thing is emulated in software, especially when you have a million times more RAM than a 68000 dream of in 1987, its simpler to give it 16MB of RAM and not worry about the big gaps. Hats off to Charles Macdonald who wrote the System 16 hardware notes, cmonkey and the late Zabanitu from Italy who did document their efforts on UKVAC to understand the mapper, and what it was actually doing, their notes on UKVAC were really useful in getting my head round it. Ultimately you can work out the bytes being written to the mapper IC (if you know where the mapper physically sits in the address space) by disassembling the 68K code and looking for the section which pumps data into the registers at the mapper location, before then branching off somewhere else, to start the actual game code. In the case of SHO the mapper initialisation code is this, which is a for/next loop counting down from 15 to 0, pumping the byte pairs held in ROM at 00153e and upwards into increasing register addresses starting at $ffff20, which is where the mapper sits on the SHO/Outrun CPU board. L_001000: moveq #$0, D0 ; clear D0 moveq #$f, D1 ; initialise the loop counter lea L_00153e.l, A0 ; address of data to send to mapper registers into A0 lea $ff20.w, A1 ; address of the memory mapper configuration registers .1: move.b (A0)+, D0 ; get a byte of data and post-increment data pointer move.w D0, (A1)+ ; move a word of data to mapper registers dbra D1, .1 ; loop L_00153e: dc.b 2,0 ; map $10000 to $3ffff to main cpu EPROMs dc.b $0d,$10 ; map $100000 to $11ffff to tile/text ram dc.b 0,$12 ; map $120000 to $12ffff to palette ram dc.b 0,$13 ; map $130000 to $13ffff to sprite ram dc.b 0,$14 ; map $140000 to $14ffff to unknown?? dc.b $0f,$20 ; map sub-cpu program to $200000 to $23ffff and maps work ram dc.b 0,0 ; does nothing dc.b 0,0 ; does nothing Machine code never was my thing, but working through this did give the clue I needed to break the mystery of why two working boards couldn't work together. I didn't need to set up the full memory mapper config, just to set it up enough to get access to the main system RAM. The first two passes through the loop above write h0002 to $FFFF20 and 0000 to $FFF22, which set up the board to have 128KB of ROM (at boot it only has 64KB) and it sets the base address of Region 0 to 00000. This seems to unlock the higher addressing where the RAM sits too. After poking those values in at those locations I could then read the full 128KB of ROM space and the RAM partially appeared in the memory map at 60000-63FFE and the NVRAM at addresses 64000-67FFE. I say partially because while the Fluke has built in test scripts for exercising RAM these instantly failed when I tried to run them on the RAM space, but writing a bit pattern to the first address location and reading it back showed what the fault actually was. When the SHO CPU board and the SHO video board were connected I only had an 8 working bits on the data bus, not the full 16. The fluke is great but the strobe on the vacuum fluorescent display makes it hard to photograph... Writing 5555 at memory location 0x60000 should allow me to read it back out again. But reading the data back from 0x60000 got me 5500 instead of 5555. With the CPU board powered up solo, with no video board I had a fully working 16 bit bus, and the RAMs on the top board passed their tests, but when the boards were connected again the lower byte of the pair was unusable. Pointing the scope at the RAM chips themselves showed the /WR (write enable) signal on pin 27 of IC115 and IC114 was held high, i.e. never write enabled. I could read them fine, but I couldn't ever get them to store any data, so the CPU would have had the same issue. When reading back the lower byte would always be zeros leading to the crash. The stuck write enable line for the lower RAMs is called LWR on the schematic, while the equivalent upper byte write signal UWR was working fine. With the Fluke set up to continually write to address 60000 I could track the issue to the edge connector (which is referenced by the signals going to page 7/7). The UWR on pin 13 was active... ...but LWR on pin 15 is stuck high... ... and when the boards were powered up separately the LWR was active again. Separating the boards while powered up is a great way to blow all the line driver ICs so I didn't even attempt that test. This initially looked like a fault on the video board jamming the LWR signal high, but is actually turned out to be a line driver problem on the CPU board. All ICs have a drive capacity, in terms of how many downstream gates their output pin is able to pull low. The default logic level is high, and a drive transistor in the output stage within an IC will conduct and pull that line down to ground via current limiting resistors to prevent a dead short and magic smoke. In this case the 74LS244 at IC123 on the CPU board had a weak output drive on pin 12 and didn't have the ability to sink the enough current to drive the LWR line when it had all the gates and pull-ups on the video board connected up. Piggy backing a new IC on top of the old one gave enough drive to the line, enabled the lower /WE line and the board could finally boot! It's alive! As to why this CPU board was happy with the Outrun PCB but not its own video board, it would come down to how many gates are hanging off the LWR line. I suspect that because Outrun has a much more complicated video board it has a buffer on this line to take over some of the load, so as far as the 74LS244 chip was concern Outrun is an easier board to drive on pin 12 than the SHO video board. So it looks like the video output is clean, and the sprite system appears to be working perfectly, but I have no road, corruption in the background, and a lot of pink. Oh and no sound at all. The 7th rule of board repair is to take any help the board offers, so if it has a test mode you should use it. The 8th rule is don't trust the 7th too much, as the built-in tests can be misleading and are usually far too quick to be doing any in-depth testing, but to get to this test menu I needed some inputs to mimic the accelerator pedal and some switches. The I/O on Sega boards of this era don't share the same power supply as the rest of the PCB, so you'll find them powered down unless you pick up power from the board and feed it into the right pins on the edge connector. Word is they did this to avoid the problem of people getting free credits using a piezo clicker to shock the board as the input section is only optically connected to the actual game system. With the power plumbed in, three wires off to a potentiometer robbed from a TV chassis and two wires for Test and Start... ... I could get into the test menu. By the way, the pinout of SHO is very different to Outrun, connecting an Outrun harness to SHO will cause no end of damage. The CRT check ruled out any issues with the video output stage as all three colour channels were there and white is white, not impacted by the pink... and the RAM test... ...shows all passes except these 4 road SRAMs. Not surprising really as the the dead 74LS109 I found earlier at IC7 will break the boards ability to see those. One trip to Jaycar later for a pair of 109s... ... and a piggy backed one lit up the disconnected outputs. Piggy backing doesn't always work, but Fujitsu TTLs often lose their internal connection to their output legs, so it is as if the on-board chip isn't there. As long as it isn't shorted on its other pins a piggy backed chip will take over the work with no issue. At nearly $5 each, Jaycar is pretty expensive per chip, as an online fake will set you back about 20cents, but you can't beat instant gratification and I still find it impressive that I can walk down the road and buy a spare part for a 1986 arcade machine. Now it looked a lot better, the pink is gone... the scene has the road now drawn, just very glitchy and with aspects of the road scattered around. Hard to catch on camera but you can see some pixels scattered either side of the central rider.. This quickly got worse, probably because the new 74ls109 was driving a section of the circuit that had been disabled up to this point. Repeating the ROM and RAM test now gave the results in bright green, with a white smear down the screen, and showed only 1 RAM as bad. But it kept changing its mind as to whether that was 21 or 39. The question now was whether 21 or 39 are actually bad, or whether it is something in the tangle of 244s that make up the road logic. During attract mode, or when showing the test menu the road circuit should be quiet, as no road is needed, this is controlled by two signals /ROAD, which is buffered into /REN (Road Enable), which drives the /G pin on about a dozen LS245s and a signal called /SRD which controls the direction of the multiplexers, and feeds an LS138 which controls the /WE pin determining whether the 4x SRAM is in read or write mode. Between these two they control whether the road cicruit is active, and whether the RAMs are being loaded with the stage data, or whether they are in output mode streaming the road data outwards. I suspect /SRD means speed road as it seems to determine how fast the road is rolling. When the road is deselected the whole system should be quiet, except D3 (pin 15) on IC21 there was a very rapid uniform signal... and on IC39 a slower signal that looked much more normal for a data output pin. As these two chips are supposed to be interleaved I'd suspect the faulty one is the noisy one i.e. IC21, and IC39 is resisting it. If the two signals clash while the board is trying to read from either then it would confuse the RAM test but it could be both or neither if that signal is coming from somewhere else, the only way to find out is to remove and test it off board. It failed! With the chip off the board I fired it up and went into the diagnostics again. The RAM/ROM test gave me this.. IC39 shows as bad, and IC21 shows good, despite IC21 being an empty location now, so the testing code has the RAM location labels reversed, which is not that uncommon as I doubt the coders ever saw what the final PCB looked like. The colours look much better, but unfortunately dull green was what Sega chose for the menu system, the sky blue is only temporary. With new 6116 SRAM fitted at IC21 it looks a lot better... ...but there is still some corruption in the road. It looks minor in a still photo but this was a flickering mess in real life. Suspecting there may be more RAM faults in the bank of four RAMs I hooked the Fluke up again and ran both the short and long tests on the road ram which is mapped between 0x68000-0x68FFF in the address space. Despite the fact the road is run by the sub CPU the memory space is shared so it is testable through the main CPU socket, and the road RAM passed even the very intensive long test. While I had the Fluke connected I ran through all the address spaces I could find, had some issues with the Sprite RAM but I suspect that was down to the sprite custom IC's taking control and doing their thing while I was trying to run my tests. Read writes kept flipping between pass and fail, but as the sprites are perfect there isn't a real fault here. I suspect there are some registers I could poke to disable the sprite custom IC access, but if there are I don't know them. Cool effect when long testing the text SRAM memory bank... All the RAM tests passed but the odd tearing in the road and the column over the splash screen was starting to become a permanent fixture. This looks suspiciously like the base road, when it inst stretched for perspective purposes, without the horizon applied and when the kerb isn't chopped up into the stripes. Especially as after the attract mode has shown a desert stage the column changes to the same colour as the sandy road. This took a while as the fault would come and go, but it never happened when the board has just been power cycled. The first splash screen was always perfect, and the issue would appear after the first attract mode cycle. To make it more annoying the fault would sometimes just vanish as soon as I touched a certain pin on an IC. I've met faults before where the additional load of the scope probe annoys the issue but this was rather too clean, but was ultimately pure coincidence. As the RAM tests fine even when the fault is present the issue has to be on the read-out section of the road system, that takes data out of the ROMs and passes it off to the video system for inclusion in the final image. For a while I was stepping around the road circuit waiting for the attract mode to cycle through and hoping that the fault would symptoms would be strong when it did, but I was chasing ghosts getting nowhere. The fault then suddenly vanished, for days, with both cold and warm restarts. I'd leave the board running for hours while I was working and I'd catch the odd flicker out of the corner of my eye but nothing I could catch with the scope. Thankfully the problem finally came back in a major way after 3 days, with the column of crap starting to appear as a few sparkly lines before gradually getting worse to the extent the stripe was nearly filled in fully. With the fault now present all the time the issue was easier to find with the scope... ...output pin 4 on the 74LS257 multiplexer at IC46 had turned to crap. Intermittent faults like this are pain, as when the image was fine this chip was behaving normally, and until it failed again there was no way to track it down. Shot-gunning a board this size isn't viable, plus desoldering on Sega boards is a bit of a fight sometimes, the power and ground planes are massive heat-sinks. With all the graphics bugs finally squashed the road finally looks mint! The last fault was the complete lack of sound. First port of call was the Z80 work RAM, the TMM2015 at IC87... ...whose outputs looked pretty horrific on the scope. Off it came... ..and surprisingly enough it passed an off-board test, and when fitted back to the board in a socket the sound was fine. Suspicious that the heat treatment from desoldering had revived the IC so it was retired and one from my stock went in. The last of the piggy-backed chips got replaced, the remaining two Fujitsu TTLs (the other 74ls109 and a 74S04 at IC85) were replaced with non-Fujitsu chips, and it spent a few days on soak test to ensure nothing else was about to die. All up the guilty culprits were these. With them now retired to the bin I'm calling the board fix complete!
  4. Hi Pete Probably the simplest thing to try is to remove and reseat the 3way connector board that links all the PCBs together. That can chase away intermittent issues. Eyeball the contacts when you put it back on to ensure the contacts are properly lined up. The smaller of the three boards is the sound board. If you still have issues after that the next stage is to use the audio test mode. Star Wars uses four POKEY chips for the audio, two for the music, two for the sound effects , so losing one can take out certain SFX or leave the music sounding a bit odd if one of the music ones has gone. You'll need to pull the PCB out so you have easy access to the sound board and a short alligator clip test lead. On the inner edge of the sound board you need to find 2 test points, labelled "TP11 GND" and "TP7 SELF TEST". Connect one end of the alligator test lead to the TP11 GND test point on the sound board, make sure the other end isn't touching anything yet. 1) Flip the test mode switch above the coin box 2) Power up the machine 3) Using the Yoke controller to step through to to the Switch Test on the screen 4) Connect the other end of the alligator test lead to the SELF TEST tag on the sound board The board will then start to play through the audio test, and will test each POKEY by playing a pattern of tones POKEY #1 - Single Beep x4 POKEY #2 - Double Beep x4 Slight Pause POKEY #3 - Triple Beep x4 POKEY #4 -Quad Beep x4 If you are missing one of them then you either have a bad POKEY IC, or it is in a bad socket. It will then go onto the speech clips, and will eventually step through the music clips. If you heave the lead connected it will only play a short bit of each tune before moving on, but you can disconnect the lead and every time you tap the test point it will progress to the next item in the test list. That should tell you if everything is working fine or not. Bad sockets or logic faults are also fairly common, as are dead 6502 CPUs or PIAs, but the fact it works partially means there isn't anything major wrong. Hopefully its not a bad POKEY, those are getting expensive.
  5. Theres a few simple things to check. Check what the 12volts is doing at the board, bad connections at the edge connector may make the 12v come and go, the only thing that uses the 12V is the audio amplifier, so a 12v feed that is intermittent will make the audio vanish, and it will be very sensitive to touch. Check the solder joints under the large amplifier chip on the heatsink, cracked joints there can make things come and go. Also does the heatsink get very hot?
  6. Your best bet is to take it out of the machine, trying to ID the board from a partial photo will be tough. You also may find some ID label on the underside.
  7. You may not have a board fault after all. Your voltage is far too low at the board, if that is a valid measurement I am surprised the board works at all. TLL logic based systems expect 5 volts, if the voltage is too low then crazy things will start to happen (like you are seeing), usually anything below 4.75v means it will barely boot at all. You also have major voltage drop in your wiring, if the PSU is putting out 5V and the board is only getting 4.6 then the issue is almost certainly that your power wiring is too thin between the PSU and the JAMMA connector. Can you post a photo of the JAMMA connector.
  8. This fault has nothing to do with grounding issues or where the video ground connects. All grounds are common on the vast majority of arcade boards, including these ones, by moving the video ground you are still connected to the same part of the circuit, just moving it slightly to the left. It is possible, but highly unlikely to be related to a voltage level either, but that’s always the first thing to check, as borderline low voltage can cause odd effects. I’d bet this is actually a RAM failure or damage to one of the mask ROMs. A failure to the A custom is always a concern on these too. There’s no reason why adjusting the volume should cause damage, unless you were holding a static charge and gave the board a tickle when you reached in.
  9. Yep, start with the 5V measurement at the board, don't measure it at the PSU as you won't see what the board gets after any voltage drop in the wiring and connectors. 12V won't matter on this board, it only feeds the audio amplifier.
  10. No, that’s actually a plastic cap on top of the capacitor.If you’ll find it is quite springy then its fine.
  11. Happy to do a zoom call if you'd like, much easier than ping pong posts. Drop me a PM.
  12. It's pretty unlikely to be related to the 6401 PROM if I'm reading the schematics correctly. What is the address that the DCD Error references? It should say DCD Err @ somewhere, bit 7
  13. Yes, that’s a dead short. Start by separating the board stack and measuring between 5v and ground on each. The short will likely only exist on one of the three boards. visually inspect each board separately, something sinking that much current may well be obvious once the boards are apart. Also eyeball the pins of the board interconnect connectors, I’ve met boards before with pins mashed together and crushed flat inside those.
  14. Great write up! Glad you're keeping the PSU original, in general switch mode PSUs are actually a downgrade, their main benefits are they are cheaper to make and are a lot lighter, but they are a lot noisier, especially the modern "every cent saved" versions.
×
×
  • Create New...