0.63 [Tomasz Slanina]

WIP:
- 0.146u3: Andrew Welburn, The Dumping Union and Charles MacDonald added clone Free Kick (NS6201-A 1987.9). Changed parent description to 'Free Kick (NS6201-A 1987.10)'. Renamed (freekickb) to (freekickb1).
- 7th July 2012: Charles MacDonald - I've dumped an alternate version of Free Kick and Exciting Black Jack. Free Kick was an older version (1987.9) which the two bootlegs were derived from, so all known version of the game are now dumped. Exciting Black Jack utilized the custom CPU module in new ways that lead to the discovery of more memory mode quirks and an external memory mode select. I've updated my notes about it here: http://cgfm2.emuviews.com/txt/freekick.txt. All that's left to dump are Counter Run and Lucky 74, both of which are already in the possession of other MAME developers.
- 0.143u5: Charles MacDonald and The Dumping Union fixed Free Kick - Game now playable. Added maincpu rom (ns6201-a_1987.10_free_kick.cpu - 52k).
- 8th October 2011: Charles MacDonald - I've been running a lot of tests on Free Kick to understand how various functions of the NS6201 security module work. Here's a complete description of it: http://cgfm2.emuviews.com/txt/freekick.txt
- 5th September 2011: Charles MacDonald - Free Kick dumped: I ran Free Kick in single-step mode up until a point where the stack pointer was initialized to a known value, than triggered repeated NMIs to push the stack pointer down past zero, wrapping around the address space into the external memory area. This is the only place where activity on the Z80 bus can be monitored. The NMI routine was allowed to finish instead of being interrupted again. At a point where it calls a leaf function, the return address was modified to point to a fragment of the IRQ handler which pops several registers off the stack before returning. This let BC, DE, and HL to be set to user-specified values, followed by another modified return address that pointed to a single LDIR instruction. A block transfer was performed that copied the internal RAM data to the external memory area in 4K chunks, and the process was automated to dump the entire content of security module correctly. It's satisfying to have this game dumped after working on it for quite some time, and this outcome certainly justified the time spent developing the Z80 analysis board. Here's hoping Counter Run can be dumped in a similar way. Does anyone have an original (non-bootleg) version of Counter Run they could lend for attempted dumping?
- 20th June 2010: Charles MacDonald - I've been investigating Free Kick, an arcade game that uses a security module in place of the CPU. Currently the bootleg version is emulated in MAME. Photos of a disassembled module show four, possibly five chip dies on one side and what is likely a Fujitsu MB3771 on the other side. One of the dies has an exceptionally high pin count and connects directly to the Z80 related pins, so it may be a Z180 (HD647180). Because of these direct connections there are probably no buffers in place to isolate internal bus activity from the outside world. However monitoring the data and control bus has not yielded any clear results. The module has an internal CR2032 battery that powers some SRAM which contains the game's program code. If the battery dies the module still functions and will print a "PROGRAM ERROR" message, so there must be internal ROM (the HD647180 has 16K of built-in ROM) that contains a start-up program which validates the SRAM before passing control to it. Typically for high score retention, the work RAM of a game is powered by a battery. Free Kick has such a battery, but it only connects to the module and not to any of the RAMs. If you consider that the bootleg games replace the security module with a daughterboard that has an EPROM for the program code and a 8Kx8 RAM, it seems likely that the work RAM is inside the module and is powered by the external battery. Since the power supplies are split across two batteries, I don't think the work RAM and program code RAM are the same chip but are two separate ones. When the module is removed from the board a number of pins have measureable voltages on them. These pins may have pull-up resistors to the internal battery. RSTOUT# is the output of the MB3771 which resets the 82C255 and a '259 latch on the PCB. The PCB has a RC reset circuit which connects to the reset input of the module. The MB3771 is probably used to disable the write inputs of the work RAM (and program RAM) when no +5V source is supplied. All Z80 address and data pins as well as RD#, WR#, MREQ#, and what I believe is IORQ# measure 0.009V which could be due to some kind of leakage, say from the program code RAM through the ESD protection diodes of the Z180 data and address bus. The pin that should be M1# is used to directly set a flip-flop which triggers the 120 Hz video interrupt. If this signal was a combination of IORQ# and M1# then that would indicate an interrupt acknowledge cycle and this connection would make sense. If it is just M1# directly then the interrupt acknowledge won't work as intended, instead any opcode fetch after the interrupt flip-flop has been set will clear it. It's hard to tell if that is intentional or not. For some reason one bootleg drives this same signal when a specific memory range is read or written which does not seem like compatible behavior. I made a circuit that requested the bus using the BUSREQ# and BUSACK# pins, and was able to halt the CPU while it ran the internal ROM program. In addition the WAIT# input is usable as it connects to the four SN76489s on the main board to cause wait states to lengthen PSG writes. I think these can be used to probe the internal memory space of the module, or if that failed, log internal bus activity. I'm developing some hardare to assist with that but it is still at an early phase. Assistance needed: If anybody has a bootleg of Free Kick or Counter Run with a daughterboard, I need to get some connections verified by using the continuity test function of a multimeter. It doesn't matter if the game works or not, and you don't have to power it up. Any bootleg will work, there are several different types. Please contact me if you can help.
- 0.136u3: Renamed (freekcb2) to (freekickb2) and (freekckb) to (freekickb).
- 0.126u5: David Haywood added clone Free Kick (bootleg set 2). Changed description of clone '(bootleg)' to 'Free Kick (bootleg set 1)'.
- 0.126u3: Brian Troha verified Free Kick PROMs and improved documentation. Fixed proms names.
- 0.105u5: Added 2nd button.
- 8th February 2005: f205v dumped Free Kick (bootleg set 2).
- 0.63: Tomasz Slanina added Free Kick (Nihon System 1987 (Sega license)) and clone (bootleg). NOTES: Currently only the freekick bootleg roms are included the Free Kick bootleg roms are the same as one of the other sets + an extra 64k ram dump from protection device. The main program rom is unused, is it a dummy or just something to active the protection device? The sound ROM contains a Z80 program, but there isn't a sound CPU and that program isn't executed. Instead, the main CPU reads the sound program through an 8255 PPI and plays sounds directly.
- 28th December 2002: Nicola Salmoria added sound and fixed inputs and flip screen in Free Kick.
- 23rd December 2002: Tomasz Slanina added a bootleg of Free Kick that works unlike the original which is missing some program code.
- 21st February 1999: Malcor dumped Free Kick.



Romset: 182 kb / 14 files / 62.8 zip