Taito JC System¶
Taito's 3D platform (1995-1997): Dangerous Curves, Landing Gear, Side by Side 1 and 2. A 68040 backed by a DSP and five Taito customs — whose exact roles MAME itself does not know. And a board that will not run on just any monitor.
Identification¶
| Field | Value |
|---|---|
| Manufacturer | Taito |
| Years | 1995-1997 |
| Main CPU | Motorola MC68040RC25 @ 20 MHz (10 MHz crystal ×2 via a CY7C991) |
| MCU | MC68HC11M0 @ 8 MHz (16 MHz crystal ÷ 2) |
| Sound CPU | MC68EC000 |
| DSP | TMS320C51 (QFP132) |
| Sound | Ensoniq ES5505 |
| Scan rate | ~25 kHz / ~55.7 Hz — ⚠️ medium resolution, see below |
| PCB format | Taito proprietary — motherboard + daughterboard |
This is not a 15 kHz board
The JC System outputs around 25 kHz, not the standard 15 kHz. It therefore needs a monitor that accepts medium resolution — a 15 kHz-only chassis will show nothing. That is the first thing to check before calling it a fault. → Modernising a cabinet
The five Taito customs¶
The MAME driver lists them with its own question marks, and it is honest to carry those over: the exact role of several is not established.
| Custom | Role, per MAME |
|---|---|
| TC0640FIO (QFP120) | I/O |
| TC0770CMU | maths co-processor ? |
| TC0780FPA ×2 | polygon / texture renderer ? |
| TC0840GLU | 2D graphics ? |
| TC0870HVP | vertex processor ? |
Why keep the question marks
These chips have no replacement. Knowing that a custom is “probably the renderer” rather than “the renderer” changes what you do: you diagnose by comparison with a good board, not by trusting an assumed role.
The crystals, and their misleading labels¶
This is a quirk of the board, recorded in MAME's notes:
- X1 is labelled “54/33.333MHz” on the MOTHER PCB-C, but only the 54 MHz appears to be used.
- X3 is labelled “30.47610MHz” on the board and “30.4762MHz” on at least one actual crystal. Both values are likely rounded from the 30.47618 MHz used with the same Ensoniq chips on other Taito boards.
→ In other words: the silkscreened label does not always give the real frequency. On this board a few tens of hertz on a counter is not drift.
Expected clocks — measurement table ✅¶
| Component | Expected clock | Role |
|---|---|---|
| MC68040 | 20 MHz | Main CPU |
| MC68HC11M0 | 8 MHz | MCU |
The MCU could run twice as fast
MAME records that the fitted part is an MC68HC11M0CFU4, “which could run twice as fast”. It is therefore clocked below its capability — that is not a defect.
The scan rate, and what remains uncertain¶
MAME sets the display at 54 MHz ÷ 3 = 18 MHz pixel clock, 720 dots per line, 449 lines (512 × 400 visible). That gives ~25.0 kHz horizontal and ~55.7 Hz vertical.
The vertical is measured, the horizontal is doubted
The driver says so itself: the current parameters match a vsync measurement, but the author suspects the hsync measurement was inaccurate.
The ~55.7 Hz is therefore solid; the ~25.0 kHz should be taken as an order of magnitude. What stays certain in practice: this is medium resolution, not 15 kHz.
Notable games¶
Dangerous Curves (1995) · Landing Gear (1995) · Side by Side (1996) · Side by Side 2 (1997).
Common faults¶
| Symptom | Probable cause | Next step |
|---|---|---|
| No picture on a 15 kHz chassis | nothing — the board outputs 25 kHz | A medium-resolution monitor is required |
| No 3D, rest displays | TMS320C51 or the rendering customs | Diagnose by comparison: these chips have no replacement |
| Silent board | 68040, 10 MHz crystal, CY7C991 | The CY7C991 is the CPU's clock source |
| Controls dead | TC0640FIO or wiring | Proprietary I/O, not JAMMA |
| No sound | MC68EC000 or the ES5505 | Two separate stages |
| Erratic behaviour | the daughterboard's MC68HC11M0 | The MCU lives on the game board, not the motherboard |
Repair (technician)¶
- Check the monitor first. A JC System on a 15 kHz chassis will show nothing, and that is not a fault.
- Two boards: the motherboard carries the 68040 and the customs, the daughterboard carries the game ROMs, the communication devices and the MC68HC11. Separate the two before probing.
- No custom has a replacement: TC0640FIO, TC0770CMU, TC0780FPA, TC0840GLU and TC0870HVP are diagnosed by comparison, never by substitution.
→ Methods: PCB diagnosis · Recap
Procedure — a dead board, step by step ✅¶
What this adds
The general method lives in PCB diagnosis. This is its application to this platform: the same order, but with the values actually expected here, so you do not have to go back and forth.
Tools: multimeter, oscilloscope (or frequency counter), current-limited bench supply, desoldering braid. → Tooling
If the board is still in a cabinet
A CRT holds its charge with the machine unplugged. → CRT safety
1. Inspection, power off. Corrosion, cut tracks, oxidised EPROM legs, leaking SMD capacitors, dubious earlier repairs.
2. The connector, before anything else. A large share of "dead boards" are a contact problem, not a fault. Clean the contacts with isopropyl alcohol and reseat — not with an abrasive eraser on a gold edge, which takes the plating off and brings the problem back worse. It costs two minutes and settles the question.
3. Power, measured on the board. Aim for +5.0 V measured as close as possible to where power reaches the board — not at the PSU output: the drop is in the loom, and that is exactly what makes a board boot on the bench and not in the cabinet. Where you probe depends on this board's connector — JAMMA edge, JVS loom or a proprietary harness — plenty of makers kept one long after JAMMA arrived — see Identification above. → Wiring Check −5 V and +12 V too if the sound stage uses them. Suspected short: bring it up current-limited and find the hot spot.
4. /RESET. It must release after power-up. Held low = the CPU never starts. A 1–2 Hz loop is not the reset circuit, it is the watchdog: the CPU is crashing at boot, so look at the bus, not at the reset.
5. Clocks — the values expected on this platform.
- MC68040 → 20 MHz (Main CPU)
- MC68HC11M0 → 8 MHz (MCU)
No clock on the MC68040 (20 MHz) and there is no point measuring anything else: the fault is the crystal, the divider, or the chip itself. That single measurement splits a dead board in two.
6. Bus. Activity on the main CPU's address lines tells you whether it is running or frozen. Frozen with good clocks and good reset → work RAM, bus buffers, ROMs.
7. It boots but the picture or the sound is wrong — that is another job: see Common faults on this page, then signal tracing.
Modernisation & mods¶
- No suicide: no battery-backed protection documented.
- Scan rate 📺: medium resolution (~25 kHz) — see tri-sync and upscalers.
- ⚠️ Do not host ROMs — method only.
Emulation & FPGA¶
MAME covers the platform (taito/taitojc.cpp), with limits the driver flags itself:
- the games run at the wrong speed compared with recordings from a real board — clearly audible on Side by Side;
- Dangerous Curves's DSP program crashes very early, so no 3D is shown. The driver wonders whether an undumped ROM is to blame — without settling it.
A board worth imaging
That doubt over a possibly missing Dangerous Curves ROM makes this board an interesting one to archive if you come across it.
Photos / assets¶
(To take: the motherboard with its PGA 68040 and the five customs, the daughterboard with the MC68HC11, and the X1 and X3 crystal labels — they are misleading, and a photograph beats a transcription.)
Sources & attribution¶
Text (synthesised here; sources listed for attribution):
- MAME —
src/mame/taito/taitojc.cpp(LGPL-2.1+, Ville Linde, Angelo Salese, hap, from David Haywood's preliminary driver): MC68040 at 20 MHz (10 MHz ×2, clock source CY7C991), MC68HC11M0 at 8 MHz with the note “MCU is a MC68HC11M0CFU4 which could run twice as fast”, MC68EC000, TMS320C51, ES5505; the list of the five Taito customs with their question marks (TC0640FIO, TC0770CMU, TC0780FPA ×2, TC0840GLU, TC0870HVP); the misleading crystal labels on X1 and X3; the screen timing 54 ÷ 3, 720 × 449 (512 × 400 visible) with the explicit caveat “current params match vsync measurement, I suspect hsync measurement was inaccurate”; and the emulation limits — wrong game speed against board recordings, and Dangerous Curves's DSP crashing, possibly because of an undumped ROM — https://github.com/mamedev/mame/blob/master/src/mame/taito/taitojc.cpp
Review & corrections
How this space is used
Spotted a wrong value, an outdated procedure, a chip reference that does not match your board? Say so here, with what you observed (model, board revision, serial number, measurement). Every report is cross-checked against a source before anything changes — an unverifiable correction is published as “reported by …, not cross-checked” rather than silently applied.
Reading is open to everyone; posting requires signing in with Discord. Reports from the wiki's declared reviewers are handled first; anyone else's are read too, but go through a human before anything is changed.