Capcom 1943 (US Version) Main CPU Interrupt Pin Stuck Low

Thank you @HudsonArcade. Just to make sure I understand - you are referring to RD (CPU Pin 21) and WR (CPU Pin 22)? Which CPU pin would correspond to Enable?

Maybe I am misinterpreting, but are you saying that these LO pulses are a result of the CPU waiting for a response on those pins - but not receiving one? This is intriguing because as best we can tell, the two nearby 27256 PROMs (Device 13D and 14D) are never being powered up and enabled. The Chip Enable (CE) signals, and Vpp (+5V), for those two PROMs are coming in on the BANK 0, BANK 1 and BANK 2 lines from the 74LS273 (Device 5B) - which is also tied to the same Data Bus in question. Not having access to the boards at the moment - I am wondering if the 74LS273 is bad?

This definitely gives us a new perspective with which to proceed.

Thanks again.
 
Last edited:
Hi, if the game plays some sounds in the right place, shows the title screen (even if bad), starts a game, stops a game, etc, then the CPU is almost certainly good*. In fact the CPU address and data bus is quite isolated from the rest of the board (via the LS245 at 10E, 14B, 14C), so any weird pulses on the CPU side on that bus can almost certainly be ignored as you know the program is running ok.

So why would graphics be bad? These systems are kind of asynchronous to the CPU - let's take the text layer as an example. The CPU just writes the text it wants to display to the RAM at 6D, and then the graphics text hardware reads the RAM and displays it. If the CPU stopped for example, the text hardware would keep going and still show whatever is in that RAM. So if some text is missing you can classify three scenarios:

1: The CPU did not properly write the data into the RAM.
2: The RAM is bad
3: The text hardware cannot properly read the data out of the RAM or has a further downstream problem.

* But I'm not sure you said the game actually plays blind and loops properly. You said it seemed to start ok with bad graphics, but does it seem like it is still playing even though you can't see it? (So eventually when you run out of lives it would return to the title screen). Unfortunately 1943 has a security microcontroller which could also be involved here and could cause the CPU to do unexpected things and stop gameplay (7K)
 
Thank you @tendril and @HudsonArcade - your explanations and examples are helpful and much appreciated.

I might be using the phrase "plays blind" in an improper context. It will display the intro screen pretty consistently and accurately. The only notable issue on this screen is some of the playing field (water, clouds and islands) "spill in" periodically at the left edge of the screen.

When we ground Edge Connector Pin 16 (to simulate a coin-up), it chirps audibly, what little sound is playing stops completely, and then most of the playing field background (ocean, islands and a few ships) begins scrolling past - as one would expect. There are partial segments of a bomber, as well as complete some ships, visible from time to time. We have not waited long enough to see what it does when all lives are lost - but will do that as a point of reference.

We have been concerned all along about the security chip (7K), but have become more optimistic as time goes on since we seem to be gaining more functionality. We now have some sound and graphics - versus essentially nothing when we started. It sounds as though we're being overly optimistic and the security chip could still be a bad actor in all of this - at which time I assume we cannot hope to make additional progress.

One minor thing we neglected to mention - several days ago, not long after we first installed new CPU RAM, it played about 10 seconds of the introductory music. However, it has not happened again since that one and only occurrence.

As silly as it sounds, the most puzzling thing at this point is why we have such a limited number of sounds. I expected we would be able to get the complete sound library up and going, and then we'd move on to the graphics. Much to our surprise, the graphics seem to be coming around sooner than the sound.
 
Last edited:
Limited sounds is indeed puzzling... if you don't know the theory of operations, it's kind of this... The main CPU writes an 8 bit value into a latch (4H) and then sends an interrupt to the sound CPU (2K) to say 'hey, new command available'. The sound CPU then reads the latch and stores that into its command list.

So if you have a probe or scope, you should see the INT line at the 2K Z80 pulse low on every sound command (coin insert, firing, etc). If you see it stick low then you know the sound Z80 has crashed and not accepted the command.

So one reason for limited sounds could be a failure in the 4H latch itself - if some of the output bits were stuck low for example, then only a limited set of commands could be sent.
 
Progress Update:
(@tendril @HudsonArcade @SCUBA King)

Here are two videos of the latest screen and audio output. I have included some other info. in the video descriptions, so please read those first, as they list other observations.

- Broken Attract Mode Video
- Broken Gameplay Video

We have not had an opportunity to investigate possible issues with 4H yet, but will do so and should have replacements soon.
Thanks again!
 
Not sure if this will help:

 
Ok, gameplay is definitely broken! It looks like it's just scrolling through all the tilemaps - I think it's actually running the scroll self test of all things... So CPU execution is definitely incorrect.

Should have mentioned this before but this game has some self tests - try setting dip 1 switch 1 to ON (or maybe switch 8 - might be reversed) - should get a test menu with some rom and ram checks that might be useful.
 
Thank you @SCUBA King and @tendril - we appreciate the feedback.

Recapping just a bit - when we first began working with this set of boards, we discovered that 21 of the 25 28-pin PROMs were bad. We're not sure what happened to them, but the Vpp pins were shorted to ground and they were pulling the +5V rail to ground. We are currently running with 21 new MAME-flashed 27256C EPROMs and four (4) of the original PROMs - which yielded passing checksums when verified on our BP Microsystems BP-1200 device programmer. Now, based on the link shared in the previous post - I am wondering if any of the four original PROMs are misbehaving - even though they give a passing checksum. They were exposed to the same conditions that killed the other 21 PROMS - so perhaps the remaining originals should be considered suspect and also replaced?

With regard to trying to power up in Self Test Mode - that was one of the last things we tried in the wee hours of the morning before calling it quits to get some sleep. Oddly enough, it did nothing - absolutely no video output (black screen) and no sound. We didn't attempt to scope the main CPU to see if it was running - as it was getting so late. Will try again later today and see what, if any, CPU activity is detectable when powering up in Test Mode.
 
Any updates on your progress? Came across my 1943 board last night and it reminded me of this thread...

Thank you @SCUBA King for checking on us. Lots of hours have been spent, but unfortunately little tangible progress has been made. Since our last update, we have worked on the following areas:
- New Line Buffer 1 & 2 RAM, new CPU RAM, & new latch at 4H.
- Address Encoding & Decoding (LS245 , LS138 , & LS139)
- Timing Generation Section (LS367 Buffer & Associated Components, LS10 , LS161 , & LS163)

The latest discovery is AC Voltage (approx. 2.1 VAC) on several components on the AUX PCB - most notably the 86S105 Custom IC. We plan to install new ceramic filter caps on all ICs which appear to have unusually high levels of AC ripple.

Assuming we do not find anything else obvious, and the filter caps do not have any appreciable effect, that leaves us suspecting a bad Intel 8751 Security IC and/or a bad 86S105 Custom IC. To our knowledge, this leaves us with no further options as far as repairing these boards - unless a KLOV expert is able to offer suggestions or other options.

Thank you.
 
Thank you @SamWhiskey for the PSU suggestion. Previous testing has shown no more than 60 mV of AC at the PSU output. Just for clarification, the PSU is a JAMMA switcher (with -5V , +5V , +12V and DC Ground).

All voltages on the CPU Board (Main CPU, Sound CPU, RAMs, Yamaha 2203 Sound Chips and all supporting LSxxx devices) have negligible AC Voltage on their rail pins. It seems that the AC Voltages are only present on the AUX (Video) Board.

Thanks again.
 
Thank you for the suggestion @SamWhiskey . We went back and looked carefully at AC Voltages and were unable to repeat the results seen previously. Perhaps it was due to too many late nights and/or inadvertently misinterpreting the meter display. In any case, it appears that chasing the AC Voltage was a false lead.

We decided to take the 3 Main CPU PROMs (positions 12D, 13D, & 14D) from our set of working bootleg boards and transplant them to the Capcom boards. The Intel 8751 Security Chip was removed and power applied. The results can be seen in this video:
1943 with Broken Sprites Video

Aside from the obvious text appearing in Japanese, the only glaring omissions are the sprites. It is also worth noting that we are now able to boot into test mode. The Object Test results are not as expected, in that we are not able to get the selected object in the target box. When performing the Scroll Test, we do see the various tile maps scrolling past.

At this point, we are very confident that we have a bad 8751 Security Chip and reasonably confident that the 86S105 Custom Graphics IC is also bad. We are hoping @caius would be kind enough to view the video and offer his opinion with regard to the condition of the 86S105.

We will try our luck with a WTB on these two items.

Thanks for all of the suggestions and advice that everyone has provided. (@SCUBA King @tendril @HudsonArcade)
 
We are pleased to report that our 1943 (US Version) boards are fully operational. It was a rewarding (and sometimes frustrating), 6-month-long learning experience – with plenty of dead ends, mistakes and lessons learned along the way.

Rather than try to exhaustively convey all the trials and tribulations that took place, we thought it best to summarize:


Highlights:
  • The EPROM contents of the Intel 8751 Security Chip (location 7K) were successfully dumped by Team-Europe in 2019. We were able to purchase several used Intel 8751 MCUs, flash them and confirm their functionality. Prior to our experience with this device, and based on a KLOV forum search, it seems as though this development (successful 7K onboard EPROM dump) is not widely known in the gaming community. This is good news for anyone needing a replacement 8751 security chip for their 1943-based Capcom game.
  • We were relieved to discover that our 86S105 Custom Graphics IC (Sprite Engine) was fully functional. Early troubleshooting and sprite behavior initially led us to believe we had a dead or damaged 86S105. Much later we discovered that several bad components pertaining to the Object Timing Section (74LS08, Location 3C; 74LS157, Location 3D; and 74LS74, Location 4C) were severely impacting sprite formation and causing them to appear as vertical lines of pixels strewn across the screen.

Lessons Learned:
  • As stated many times by seasoned KLOV repair veterans, always purchase components from a reputable source (i.e. Peter at Arcade Parts & Repair, Digi-Key or Mouser). Replacing suspect original components with a new (but unknowingly BAD) component results in lots of wasted time, doubt and confusion.

  • It is easy to get lost in the weeds and overlook critical details – such as the fact that one cannot ignore subtle differences in components with the same part number, but different manufacturers. As an example, in the case of the BMP Micro BP-1200 programmer we used, it is important to select the correct manufacturer when dumping, verifying and programming PROMS / EPROMS. The programmer needs to know whether the 27256 EPROM is manufactured by Texas Instruments, AMD, Atmel, etc. While the programmer is able to read and write data based on generic component designations, it is possible to capture and write hex files that contain subtle errors rooted in manufacturer-specific device read / write protocols.

  • When possible, having access to a working set of boards (or at least known good components) is invaluable. While this is not always feasible, it can speed up the troubleshooting process and help build confidence when deciphering schematics, tracing logic flows, verifying behavior, etc.

  • In the absence of a fully-equipped test bench (with video Test Pattern Generator, Fluke 9010A, etc.) – plugging in to the cabinet and allowing the boards to run in their native habitat is very useful. Additionally, if even the slightest video output is present, having a couple cans of freeze spray (we inverted cans of "Canned Air" duster) and a small heat gun are helpful for zeroing in on a faulty component or area of the PCB that has issues. Look and listen for changes as a component (or group of components) is heated or cooled. Note: This plug & pray approach is not recommended for Vector games as bad X and Y outputs can damage a good CRT chassis and tube.

  • Not surprisingly, test equipment accuracy and the validity of results can vary significantly based on manufacturer and cost. Our old Tektronix TDS 744A Oscilloscope was rock solid, but the Chinese-made Digital IC Tester produced varying results. Most of the time it was capable of distinguishing between good and bad devices (such as 74LS74, 74LS138, 74LS139, 74LS244 and 74LS245). However, it consistently failed to provide reliable results for Binary Counters (74LS161, 74LS163), Tri-State Hex Buffers (74LS367) and Octal D-Type Edge-Triggered Flip-Flops (74LS374). This is a case of having something is better than having nothing (aforementioned Digital IC Tester) – but one must be aware of its shortcomings. It is also advisable to implement redundant verification of a device if results are contradictory or inconclusive – such as piggybacking devices to see what (if any) changes are noted, or when possible – swapping in a known good device.


Due to inexperience and the occasional lapse in good judgement, we ended up removing, testing and / or replacing more components than actually necessary. That being said – here are the components whose replacement verifiably contributed to restoring functionality:


  • CPU EPROM BM1 - (Original was a Mitsubishi M5L27512K – replaced with AMD AM27256): Position 12D
  • PROMs 4 – 25 – (Originals were Mitsubishi M5M27256P, Replaced with Texas Instruments 27C256 EPROM): Positions 5H, 4K, 10A, 11A, 12A, 14A, 10C, 11C, 12C, 14C, 5F, 10F, 11F, 12F, 14F, 10J, 11J, 12J, 14J, 8K, 14K, 14L
  • B12 Bipolar PROM – (Original was an 82S129N, Replaced with a like 82S129N): Position 12M
  • Main CPU RAM – (Original was a TMM 2063P-10, Replaced with TMM 2063P-10 e-Bay takeout): Position 12D
  • Sound RAM – (Original was a TMM 2015BP-10, Replaced with 6116P-70); Position 1K
  • Character RAM – (Original was a TMM 2015BP-10, Replaced with 6116P-70); Position 6D
  • Line Buffer 1 RAM – (Original was a Sony CXK5814P-45L TMM 2018, Replaced with 6116P-70): Position 7D
  • Line Buffer 2 RAM – (Original was a Sony CXK5814P-45L TMM 2018, Replaced with 6116P-70): Position 12D
  • 74LS08 in Object Timing Section: Location 3C
  • 74LS157 in Object Timing Section: Location 3D
  • 74LS74 Feeding Timing Signals from 86S105 Custom Graphics IC to Object Timing Section: Location 4C
  • Multiple 74LS245 Octal Bus Transceivers across both PCBs
  • Multiple 74LS138 3-to-8 Address Decoders across both PCBs
  • Multiple 74LS139 2-to-4 Address Decoders across both PCBs

Last, but certainly not least, thank you also to the kind members of KLOV who provided suggestions, feedback and encouragement along the way!

If anyone has questions, please feel free to DM as this post is already longer than most are willing to read.
 
Back
Top Bottom