Ape Cosplay
Professional
Hi everyone and Happy New Year 2025.
For a long time it wasn't possible to replace the Z180 (HD647180) MCUs used on some Toaplan boards because their internal ROM wasn't dumped.
Then in late 2016 CapsOff took care of that:
https://caps0ff.blogspot.com/2016/12/hd647180-19-58-102-terrific-toaplan.html
That was great news but in pratical terms there were still some hurdles:
1) Where to find blank replacement chips
I had the most difficulties finding those chips in QFP80 as used on Toaplan boards. But PLCC84 ones were quite common. That's how I decided to design a small adapter, from QFP80 to PLCC84.
2) How to program them
This is where it gets... interesting (or desperating to be honest).
First, following the available documentation I made an adapter to program them (converts the pinout to a standard 27256 EPROM).
(Yes the first guy I used it for was called Jade
)
Then I made several orders from different sellers, some a bit expensive (around $30/pc with shipping), and albeit they all claimed to be NOS, backed up with pictures of the chips in their original trays, they unfortunately all came already programmed...
What is important to know is, those chips contain a good old UVPROM on their die, although lacking a window to erase them.
Only one solution from there, exposing the die.
I used a small CNC to carve a pocket above the die, leaving around 0.1/0.2mm of package above it (don't ask me how I know).
Then used hot nitric acid (@ 90°C) to finally reveal the die and UV erase it.
That worked very well BUT, that's a dangerous process I hated.
A "better" (aka safe) way had to be found.
I noticed Vimana used a shared RAM between the main CPU (68k) and the sound MCU (Z180) and realised the latter was actually configured in expanded mode 2 (internal ROM but external data and address lines) to do so.
That's the beginning of something since we now had access to data and address lines outside of the chip.
But in expanded mode 2 some of the data/address lines have a double function and revert to their original port mode when accessing the internal ROM. I carefully checked in MAME that none of those ports were actually used by the code and they weren't! That meant we could safely force the chip in expanded mode 1 (external ROM), yeah!
I hand built a small adapter that fit on the shared RAM socket, connecting all the signals to an external ROM but the CE line from the RAM.
Since the internal code was 16KB we need 3 more address lines: A11, A12 and A13, not used by the original board (pads aren't connected to anything) so I ran wires directly to the MCU.
The last needed signal was the CE one for the external ROM, since we still wanted it to be in the first 16KB of the CPU range, that corresponded to both A15 and A14 to be low, coupled with the memory access signal (!CE_ROM = !MREQ & !A15 & !A14).
I was prepared to recreate that signal with a standard TTL chip but got curious how the one for the RAM was generated. Turned out it came from a nearby LS139 that already had the signal we needed for the ROM on one of its outputs (but again not connected to anything on the original board since in that region is the internal ROM).
With those 4 patch wires game booted without any error, sound and controls (also handled by the Z180) were fully functional!
I call that a victory (ugly but still), not having to use chemicals that burn your lungs in one breathe is a gigantic plus in my book.
The last step was to redesign the adapter board to add pads for easy address signals tapping.
And also a neater daugherboard, with pads too.
Not as discrete as the first solution but getting to see my kids growing is priceless.
P.S.: Those MCUs have 2 protection bits, one to prevent reading of the internal code, one to prevent mode change. The second method only works if the mode prohibition bit isn't set.
For a long time it wasn't possible to replace the Z180 (HD647180) MCUs used on some Toaplan boards because their internal ROM wasn't dumped.
Then in late 2016 CapsOff took care of that:
https://caps0ff.blogspot.com/2016/12/hd647180-19-58-102-terrific-toaplan.html
That was great news but in pratical terms there were still some hurdles:
1) Where to find blank replacement chips
I had the most difficulties finding those chips in QFP80 as used on Toaplan boards. But PLCC84 ones were quite common. That's how I decided to design a small adapter, from QFP80 to PLCC84.
2) How to program them
This is where it gets... interesting (or desperating to be honest).
First, following the available documentation I made an adapter to program them (converts the pinout to a standard 27256 EPROM).
(Yes the first guy I used it for was called Jade
)Then I made several orders from different sellers, some a bit expensive (around $30/pc with shipping), and albeit they all claimed to be NOS, backed up with pictures of the chips in their original trays, they unfortunately all came already programmed...
What is important to know is, those chips contain a good old UVPROM on their die, although lacking a window to erase them.
Only one solution from there, exposing the die.
I used a small CNC to carve a pocket above the die, leaving around 0.1/0.2mm of package above it (don't ask me how I know).
Then used hot nitric acid (@ 90°C) to finally reveal the die and UV erase it.
That worked very well BUT, that's a dangerous process I hated.
A "better" (aka safe) way had to be found.
I noticed Vimana used a shared RAM between the main CPU (68k) and the sound MCU (Z180) and realised the latter was actually configured in expanded mode 2 (internal ROM but external data and address lines) to do so.
That's the beginning of something since we now had access to data and address lines outside of the chip.
But in expanded mode 2 some of the data/address lines have a double function and revert to their original port mode when accessing the internal ROM. I carefully checked in MAME that none of those ports were actually used by the code and they weren't! That meant we could safely force the chip in expanded mode 1 (external ROM), yeah!
I hand built a small adapter that fit on the shared RAM socket, connecting all the signals to an external ROM but the CE line from the RAM.
Since the internal code was 16KB we need 3 more address lines: A11, A12 and A13, not used by the original board (pads aren't connected to anything) so I ran wires directly to the MCU.
The last needed signal was the CE one for the external ROM, since we still wanted it to be in the first 16KB of the CPU range, that corresponded to both A15 and A14 to be low, coupled with the memory access signal (!CE_ROM = !MREQ & !A15 & !A14).
I was prepared to recreate that signal with a standard TTL chip but got curious how the one for the RAM was generated. Turned out it came from a nearby LS139 that already had the signal we needed for the ROM on one of its outputs (but again not connected to anything on the original board since in that region is the internal ROM).
With those 4 patch wires game booted without any error, sound and controls (also handled by the Z180) were fully functional!
I call that a victory (ugly but still), not having to use chemicals that burn your lungs in one breathe is a gigantic plus in my book.
The last step was to redesign the adapter board to add pads for easy address signals tapping.
And also a neater daugherboard, with pads too.
Not as discrete as the first solution but getting to see my kids growing is priceless.
P.S.: Those MCUs have 2 protection bits, one to prevent reading of the internal code, one to prevent mode change. The second method only works if the mode prohibition bit isn't set.
Last edited:
