tendril
Well-known member
Ok, trying to repair this board that has no schematics available, and I've gone pretty hardcore on it I think and my conclusion is the CPU is dead but I hate to admit defeat in bringing it back to life so I'm open to ideas or someone pointing out where I may gone wrong!
The board initially showed no signs of life with most TTL on the board not active at all. Digging deeper showed there would be tiny pulses of activity then nothing for a few seconds, then repeat, so it seemed a watchdog was constantly trying to reset the CPU. This was confirmed on the /RESET line of the CPU which was being pulled low for a period then released high as expected. Voltage to the CPU was good, as are the clock signals (the TMS34020 takes two clocks, one regular CPU, one 'video' clock).
The first thing the CPU is meant to do on reset is to fetch the reset vector from program ROM so it can start executing code. So examining the program ROMs showed the address lines were all pulsing at reset as if the CPU was trying to read, but the ROMs never output any data. The reason why no data was output is because the /OE (output enable) line is never set.
Time to go deep.. Program ROM /OE is driven from pin 19 of the programmable GAL chip at U144. I dumped the GAL to equations, and also did the same with the MAME dump - both match so I can rule out the GAL itself being bad. The equations are:
/o21 = i7 * i8 * /i9
/o20 = i23 * i7 * /f17 * i8 * i9 * /i10 * i14 * /i11
/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11
f17 = i3 * /i4
o16 = vcc
/o15 = i7 * /f17 * i8 * i9
The overall main function of this GAL is to implement the CPU memory map. So the output on pin 19 (/o19) is a function of 9 different inputs. Ouch. Without knowing what they do yet, I can see that all except i10 pulse after reset. I've traced where they all go, which was very time consuming with the tiny traces on this board.
i7-i9 are effectively bits 29-31 of the CPU address bus (they get latched into the LS373@U139 first). It makes sense these bits are involved, because if we reference the memory map from MAME - those top 3 bits are used to identify each 'section'.
static ADDRESS_MAP_START( main_map, AS_PROGRAM, 16, btoads_state )
AM_RANGE(0x00000000, 0x003fffff) AM_RAM
AM_RANGE(0x20000380, 0x200003ff) AM_READWRITE(main_sound_r, main_sound_w) AM_RANGE(0x20000400, 0x2000047f) AM_WRITE(misc_control_w)
AM_RANGE(0x40000000, 0x4000000f) AM_WRITENOP*** /* watchdog? */
AM_RANGE(0x60000000, 0x6003ffff) AM_RAM AM_SHARE("nvram")
AM_RANGE(0xa0000000, 0xa03fffff) AM_READWRITE(vram_fg_display_r, vram_fg_display_w) AM_SHARE("vram_fg0")
AM_RANGE(0xa4000000, 0xa43fffff) AM_READWRITE(vram_fg_draw_r, vram_fg_draw_w) AM_SHARE("vram_fg1")
AM_RANGE(0xa8000000, 0xa87fffff) AM_RAM AM_SHARE("vram_fg_data")
AM_RANGE(0xa8800000, 0xa8ffffff) AM_WRITENOP AM_RANGE(0xb0000000, 0xb03fffff) AM_READWRITE(vram_bg0_r, vram_bg0_w) AM_SHARE("vram_bg0")
AM_RANGE(0xb4000000, 0xb43fffff) AM_READWRITE(vram_bg1_r, vram_bg1_w) AM_SHARE("vram_bg1")
AM_RANGE(0xc0000000, 0xc00003ff) AM_DEVREADWRITE("maincpu", tms34020_device, io_register_r, io_register_w)
AM_RANGE(0xfc000000, 0xffffffff) AM_ROM AM_REGION("user1", 0)
ADDRESS_MAP_END
As an example you can see output 21 on the GAL has this equation:
/o21 = i7 * i8 * /i9
So if i7 is set (0x20000000) and i8 is set (0x40000000) but i9 is NOT set (0x80000000) then the resulting address is 0x60000000 which means 'nvram' is being accessed in the map.
Back to output pin 19.. i3 and i4 are effectively address bus bits 2 & 3 (latched via ls373@u7). i11 goes straight to pin 8 on the CPU which is /RAS. i10 goes to CPU pin 133 which is '/TR /QE'. So if we refer back to the equation:
/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11
For /o19 to be low (and enable the program ROM) we need the address lines to be correct, /i11 (RAS) to be low which it always is, but also '/TR /QE' to be low, which always measures as high. The manual describes '/TR /QE' as 'Transfer/output-enable. During a local-memory read cycle, TR/QE functions as an active-low output-enable to gate from memory to LAD0–LAD31.'. So it makes sense it's involved, it's part of the cycle of reading, but why is it stuck? My best guess so far is that the CPU has just failed internally - I've checked that there is no bus fault (BUSFLT pin) and it's not stuck in host mode (HCS pin), the manual seems to suggest TR/QE should be active with the address lines during a read cycle. I've also isolated the TR/QE line, so I know nothing else is driving it high, it's definitely only driven from the CPU.
So, any ideas? Is my logic flawed somewhere?
The board initially showed no signs of life with most TTL on the board not active at all. Digging deeper showed there would be tiny pulses of activity then nothing for a few seconds, then repeat, so it seemed a watchdog was constantly trying to reset the CPU. This was confirmed on the /RESET line of the CPU which was being pulled low for a period then released high as expected. Voltage to the CPU was good, as are the clock signals (the TMS34020 takes two clocks, one regular CPU, one 'video' clock).
The first thing the CPU is meant to do on reset is to fetch the reset vector from program ROM so it can start executing code. So examining the program ROMs showed the address lines were all pulsing at reset as if the CPU was trying to read, but the ROMs never output any data. The reason why no data was output is because the /OE (output enable) line is never set.
Time to go deep.. Program ROM /OE is driven from pin 19 of the programmable GAL chip at U144. I dumped the GAL to equations, and also did the same with the MAME dump - both match so I can rule out the GAL itself being bad. The equations are:
/o21 = i7 * i8 * /i9
/o20 = i23 * i7 * /f17 * i8 * i9 * /i10 * i14 * /i11
/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11
f17 = i3 * /i4
o16 = vcc
/o15 = i7 * /f17 * i8 * i9
The overall main function of this GAL is to implement the CPU memory map. So the output on pin 19 (/o19) is a function of 9 different inputs. Ouch. Without knowing what they do yet, I can see that all except i10 pulse after reset. I've traced where they all go, which was very time consuming with the tiny traces on this board.
i7-i9 are effectively bits 29-31 of the CPU address bus (they get latched into the LS373@U139 first). It makes sense these bits are involved, because if we reference the memory map from MAME - those top 3 bits are used to identify each 'section'.
static ADDRESS_MAP_START( main_map, AS_PROGRAM, 16, btoads_state )
AM_RANGE(0x00000000, 0x003fffff) AM_RAM
AM_RANGE(0x20000380, 0x200003ff) AM_READWRITE(main_sound_r, main_sound_w) AM_RANGE(0x20000400, 0x2000047f) AM_WRITE(misc_control_w)
AM_RANGE(0x40000000, 0x4000000f) AM_WRITENOP*** /* watchdog? */
AM_RANGE(0x60000000, 0x6003ffff) AM_RAM AM_SHARE("nvram")
AM_RANGE(0xa0000000, 0xa03fffff) AM_READWRITE(vram_fg_display_r, vram_fg_display_w) AM_SHARE("vram_fg0")
AM_RANGE(0xa4000000, 0xa43fffff) AM_READWRITE(vram_fg_draw_r, vram_fg_draw_w) AM_SHARE("vram_fg1")
AM_RANGE(0xa8000000, 0xa87fffff) AM_RAM AM_SHARE("vram_fg_data")
AM_RANGE(0xa8800000, 0xa8ffffff) AM_WRITENOP AM_RANGE(0xb0000000, 0xb03fffff) AM_READWRITE(vram_bg0_r, vram_bg0_w) AM_SHARE("vram_bg0")
AM_RANGE(0xb4000000, 0xb43fffff) AM_READWRITE(vram_bg1_r, vram_bg1_w) AM_SHARE("vram_bg1")
AM_RANGE(0xc0000000, 0xc00003ff) AM_DEVREADWRITE("maincpu", tms34020_device, io_register_r, io_register_w)
AM_RANGE(0xfc000000, 0xffffffff) AM_ROM AM_REGION("user1", 0)
ADDRESS_MAP_END
As an example you can see output 21 on the GAL has this equation:
/o21 = i7 * i8 * /i9
So if i7 is set (0x20000000) and i8 is set (0x40000000) but i9 is NOT set (0x80000000) then the resulting address is 0x60000000 which means 'nvram' is being accessed in the map.
Back to output pin 19.. i3 and i4 are effectively address bus bits 2 & 3 (latched via ls373@u7). i11 goes straight to pin 8 on the CPU which is /RAS. i10 goes to CPU pin 133 which is '/TR /QE'. So if we refer back to the equation:
/o19 = i23 * i7 * /f17 * i8 * i9 * /i10 * /i11
For /o19 to be low (and enable the program ROM) we need the address lines to be correct, /i11 (RAS) to be low which it always is, but also '/TR /QE' to be low, which always measures as high. The manual describes '/TR /QE' as 'Transfer/output-enable. During a local-memory read cycle, TR/QE functions as an active-low output-enable to gate from memory to LAD0–LAD31.'. So it makes sense it's involved, it's part of the cycle of reading, but why is it stuck? My best guess so far is that the CPU has just failed internally - I've checked that there is no bus fault (BUSFLT pin) and it's not stuck in host mode (HCS pin), the manual seems to suggest TR/QE should be active with the address lines during a read cycle. I've also isolated the TR/QE line, so I know nothing else is driving it high, it's definitely only driven from the CPU.
So, any ideas? Is my logic flawed somewhere?

