Gallag "strange" problem

The main CPU does indeed need to be the 4 mhz version. I've got an original Gallaga board here that refuses to boot with anything other than NEC CPU's. It's very common to see Gallag's converted to Galaga's with a simple rom swap, I've done it plenty of times myself.

 

I wouldn't rule out the buffers for the switch issue also I've seen weird switch behavior caused by a bad 74ls28 on the cpu board. Bootlegs tend to use the 74ls28 where as on the originals they use a 74ls128 which I've never found a source for. I've used the ls28's on originals and they work fine.

Thanks for the suggestions! I don't have a NEC upD780C-1, I've tried other Z80A (ST, Sharp) where the D780C-1 is supposed to live, but symptoms remains always the same. I'm sure this board was populated with the 4 x D780C originally, they are all from the same batch and with a 1982 date code, matching most of the other chip's date codes.

It's still a mistery why only one CPU needs to be a 4 MHz one when all run at 3 MHz :) I guess the designers knew something I don't :)

I'll check that 74LS28 too.

Still I can't figure out how all switches appear to function normally when in test mode (albeit only two of them have a special purpose for what I understand, to switch back and forth between different sounds).

I have a big checklist of things to check, but I'm going first to reverse engineer some parts of the circuit, like the /WAIT generators for all the CPUs and the enable signals for the common bus latch+transceivers.

Do I really need to source a D780C-1 anyway?

Frank

If you look around you'll find 2 schematics for Gallag - one for the blue boardset and one for the green. You might not need to roll your own.

- - - Updated - - -

I had these in my manual and schematics repository... it's only 8.95GB of files. :)

Gallag-Blue-Schematic.pdf

Gallag-Green-Schematic-missing-page3.pdf

If you look around you'll find 2 schematics for Gallag - one for the blue boardset and one for the green. You might not need to roll your own.

 

- - - Updated - - -

 

I had these in my manual and schematics repository... it's only 8.95GB of files. :)

 

https://www.aussiearcade.com/attachment.php?attachmentid=155698

https://www.aussiearcade.com/attachment.php?attachmentid=155699

Yep, of course I did find both of them.

Gallag-blue is incomplete, there's at least one half of the CPU board missing.

Gallag-green is quite complete (but I haven't checked the video board so far, since mine is probably fine).

Both have so poor quality that I find sometimes easier to probe the actual tracks and reverse engineer the connections.

Thanks

Frank

Ok, some more headscratching...

1) The 74LS28 seems to be ok, if that part of the schematic is correct, it seems only involved into the reset/watchdog reset circuit. The gates look all working (though a couple of them just sit idle after the power on reset). I'm not sure if there're more LS28 around, I didn't look too carefully.

2) On one of the gallag schematics on the net, looks like if the /WAIT pin of the "added Z80" (the one running ROM 6 and having 2 x 2114 RAMs) should be connected to a LS244, however, in my board this pin is just tied to a pullup resistor (together with pins 25 and 16 of another Z80, same pullup resistor) so I think it's not meant to be driven low at any time. All other /WAITs pins are being driven low at some time.

I'll be trying to piggyback those two 2114 on the added Z80, I've never had luck with SRAM piggybacking (50% luck with DRAMs instead), but you never know... I'm still having no clue and keeping on recreating the schematic albeit very slowly.

Frank IZ8DWF

Again replying to myself, just keeping track of what I'm finding.

1) On this PCB, the D780C-1 is silkscreened on a different "position" as the original Galaga board, of course if I'm understanding the schematic(s) correctly. The Galaga schematic seems to imply that the 4 MHz CPU must be the one getting the Power On Reset (/POR) signal and the other CPUs get a /RESET signal out of a LS259 addressable latch. The "main" CPU raises the /RESET signal sometimes during the end of the boot process and it then stays high "forever".

In my bootleg PCB however, the D780C-1 socket is one of the "slave" CPUs, the main one (getting /POR and not /RESET on pin 26) is marked as a D780C. I fitted another Z80A in this socket but it didn't make any difference anyway (but I had to try).

2) Now the audio somewhat is broken. The only sound that can be heard both on service mode and in normal game mode is the ship explosion (sound 17), all other sounds can be selected during service mode but don't produce any output. I guess something gave up the ghost and it's probably a good thing since I can concentrate in the sound area to find the problem (hoping it was related to the original fault).

Frank

Turns out that the sound issue must have been caused by some probe slip/short or something like that, without me realizing it. I've found a lifted and burned track and the MB7052 PROM had one output stuck high. Now, I don't have a suitable programmer for these 256x4 PROM, so I must ask around in some EU forums for someone to send me a programmed part :/

I've jumpered the track and now without the PROM I can hear the clickety-click sounds in place of the real ones , so I think a new PROM will restore all the sounds. The other issue remains, but I think I'll spend some days completing a good reverse-engineering of the schematic, since probing around "blindly" has proven unsuccessful.

Can someone please point me the the right dump of the sound prom? I will look in the MAME dump anyway, I just don't want to send the wrong file to be programmed.

Does the MB7052 have other equivalent parts? It seems I could use an 82S1xx one too, but it might be another mistery "must be exactly that" like the Z80 vs Z80A mistery...

Frank

Ok, still no progress, but I've filled 6 kicad pages of reverse engineered schematic. Maybe it's just me, but the fault looks so subtle.

I have a few questions for Galaga owners (the real one or a bootleg, it shouldn't matter), I hope someone can take a little time to answer some questions:

1) If you flip the service/test switch in the middle of a game, does it go in test mode immediately or does it go after the current game ends (both players if it's a two player game)?

2) In service mode, is there any input that instead of playing a sound (or moving up/down to different sounds) displays a string of "9" and "." (something like 999.99.99999. ) on the bottom of the test screen?

3) Only if you have a decent analog scope (50-200 MHz, mine is a 250 MHz analog): can you see a very short pulse to 0V on pin 1 of 1M or 1N (these are chip position in the real Galaga, on a bootleg the position may vary but it's simple to find with a multimeter)?

These are LS367 address bus drivers for the master CPU. This pulse is after the correct "large" enable pulse, The correct enable pulse is large about 325ns.

I haven't found any real problem with this short pulse, it seems isn't conflicting with other CPUs bus times, but I didn't find a similar one on the other two CPUs, so I just wonder if I have to chase its origin (no, it's not a trivial one it seems).

Thanks

Frank

Ok, still no progress, but I've filled 6 kicad pages of reverse engineered schematic. Maybe it's just me, but the fault looks so subtle.

I have a few questions for Galaga owners (the real one or a bootleg, it shouldn't matter), I hope someone can take a little time to answer some questions:

1) If you flip the service/test switch in the middle of a game, does it go in test mode immediately or does it go after the current game ends (both players if it's a two player game)?

2) In service mode, is there any input that instead of playing a sound (or moving up/down to different sounds) displays a string of "9" and "." (something like 999.99.99999. ) on the bottom of the test screen?

I could answer these running my ROMs into MAME (again).

Yes, the test mode starts immediately (it resets the game and goes in the service screen) even during a game.

Yes, there's an input labeled "Service1" that doesn't trigger a sound but just displays that string on bottom of the screen.

Still I would like very much if anyone could get some signal shots out of a working board.

I started disassembling and commenting ROM n.6, still I can't see anything different from what it should be...

Frank

A little update,

I've re-drawn almost all the CPU board's schematic into kicad (and made a video about how the cpus share a common bus and communicate, not going too deeply of course).

I strongly suspect that the circuit that generates /NMI1 and /NMI4 isn't producing the correct signals but I see no volunteers that can record the correct signals on a working Galaga or any bootleg :)

However, I think I'm going to simulate it to be sure, since if it's faulty, the root problem isn't evident at all.

In short: CPU4 (the Fujitsu microcontroller on the original Galaga, or the added Z80 in the bootlegs) reads the inputs on every VBLANK and saves them into internal RAM. At one point, CPU1 decides it wants to read the inputs and program another custom chip (or a really messy stateful logic on the bootleg) to generate a sequence of interrupts for the microcontroller (NMI4 on the bootleg) and a sequence of NMI1. Each sequence should be 3 or 4 pulses (that's one thing I don't yet know) and they should have the same number of pulses.

On NMI4 (or INT on Galaga) the microcontroller writes a byte on a shared latch, on NMI1 the main CPU reads the same latch.

On my board, there're 4 NMI4 pulses and 3 NMI1 pulses, so a posted byte goes lost.

Also both pulse sequences end with a shorter than 50 us pulse, all other pulses are a bit less than 100 us. However, the short pulse is more than enough to trigger the CPUs.

So, again, if someone can take a picture, of a signal on a couple of pins on a real Galaga or any bootleg, I can save some time needed to simulate this circuit :)

Thanks

Frank IZ8DWF

Nah, I am wrong again... I've just simulated the NMI1,NMI4 circuit generator and it looks like the master CPU just stops the NMI sequence in the middle of the last one by resetting the proper latch. NMI4 correctly is the first asserted, then the master CPU reads the common 8 bits latch before the input's CPU writes it again (after the first NMI4 pulse, the following NMI1 and NMI4 happen together).

So, again no clue.

Frank

This is over finally!

With almost all the complete schematic, I could find that most of the times, the U5F Z80 would stop reading one of the input buffers during the game (hm, how can we play if it doesn't check the inputs?). Since there's nothing really wrong with all U5F logic glue, and I had verified all ROMs, I decided it must be a RAM problem, since this CPU has private RAM (2 x 2114) and this RAM isn't tested by the main CPU (it can't address it anyway), I was quite sure it must be it. However, I was wrong too many times with this board, so I decided to write some diagnostic code that could run in place of ROM-6 which is U5F's own code and that confirmed that the high nibble had bad bits. Replacing the 2114 in U5C solved the problems.

It's interesting to note that when toggling the service switch, U5F would actually start working again enough to allow the service mode to recognize the inputs. That's because the service switch is connected to the other input buffer (the one at 3000H that was always been read, the one being skipped is mapped at 2000H) and U5F's firmware reacts to the service switch toggling by re-initializing some memory buffers and pointers, getting ready for service mode.

The 2114 at U5C was anyway working enough to not completely trash the whole behaviour of the CPU.

However, it has been good to learn this whole much just to find a bad chip :)

I'll post a video in the next week(s) about this diagnostic code and troubleshooting.

Frank IZ8DWF

What a marathon! Good work and thanks for sharing.

We don't see many repair logs these days.

I will definitely get the PCBs of a few of the "important" arcade of my younger years, so there'll be more logs in the future :)

I'm also planning on making "scaled" down cabinets (suitable for 14" CRTs) for all of them, but I need some help for the woodwork. I'm only good

on things that can be made with a soldering iron :D