02884: kopunch: CPU is specified as a 4 MHz 8080 when it should be a 4 MHz Z80.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
02884	Original Reference	Typo	Always	Jan 28, 2009, 03:24	Feb 2, 2009, 17:40

Tester	chowell	View Status	Public	Platform	MAME (Official Binary)
Assigned To	dox	Resolution	Fixed	OS	Windows XP/Vista 32-bit
Status [?]	Resolved			Driver	sega/kopunch.cpp
Version	0.129u2	Fixed in Version	0.129u3	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	02884: kopunch: CPU is specified as a 4 MHz 8080 when it should be a 4 MHz Z80.
Description	The source code for the kopunch.c driver specifies the CPU as: MDRV_CPU_ADD("main", 8080, 4000000) /* 4 MHz ???? uses 8080 instructions, not z80 */ However, the pcbinfo file for the board says: Main CPU : Z80 Xtal : 4.000 Mhz A 4 MHz clock speed would certainly imply a Z80, since no 8080 versions were ever rated faster than 3 MHz. If the CPU used was a Z80, especially with a 4 MHz clock speed, the driver should say so. There's no problem in remarking that only 8080 instructions are used, but that doesn't mean that the CPU should be treated as an 8080. It's more likely that the game code was ported from existing 8080 code or written by someone only familiar with the 8080, and that the Z80 chip was chosen because it could run faster while still being backward-compatible (and possibly for other features, such as its built-in DRAM refresh or a lower price).
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	kopunch

Attached Files

No.03665 Haze Senior Tester Jan 28, 2009, 07:29 edited on: Jan 28, 2009, 07:29	it was changed to an 8080 because it uses 8080 specific instructions, which aren't present on a z80 iirc... so the PCB info might be wrong (or the dumps are bad?)
No.03666 chowell Developer Jan 28, 2009, 09:25	Sorry to argue, but I would be interested to know what those 8080-specific instructions are, because I'm pretty sure that the Z80 was designed to be completely binary-compatible with the 8080. Anyway, as I said originally, 4 MHz is too fast for an 8080.
No.03669 Fujix Administrator Jan 28, 2009, 12:38	As seen on some examples that Haze has pointed out, I think it would be risky to use the PCB info as foundation for the MAME development. There are many cases that the actual work is different from those written materials.
No.03672 chowell Developer Jan 28, 2009, 13:30	OK. The pcbinfo file was all I had to go on, and it did offer an explanation for why a supposedly 8080-based system would have an unreasonably high clock speed. (4 MHz was a very common Z80 speed; it was the rated speed for the Z80A.) Mainly I wanted to record that a discrepancy exists which should be rectified.
No.03677 Haze Senior Tester Jan 28, 2009, 21:21	<dox\|> z80 ver <dox\|> 0113: F3 di <dox\|> 0114: 31 CB 22 ld sp,$22CB <dox\|> 0117: 3E 18 ld a,$18 <dox\|> 0119: 30 FB jr nc,$0116 <dox\|> 011B: 06 28 ld b,$28 <dox\|> and it hangs there , at jr nc,116 (jump into middle of prev instruction) <dox\|> 8080 ver <dox\|> 0113: F3 di <dox\|> 0114: 31 CB 22 lxi sp,$22cb <dox\|> 0117: 3E 18 mvi a,$18 <dox\|> 0119: 30 sim <dox\|> 011A: FB ei <dox\|> 011B: 06 28 mvi b,$28 <dox\|> it sets interrupts mask iirc with sim, and enables interrupts <dox\|> so it;s 8080 imho ..
No.03678 hap Developer Jan 28, 2009, 21:36	8080 doesn't have SIM, 8085 does (and can be 4mhz)
No.03679 Haze Senior Tester Jan 28, 2009, 21:39	well the MAME cores should be fixed then....
No.03680 hap Developer Jan 28, 2009, 21:49	From a glance at the source, the core looks alright: if it's set to 8080, it'll do an undocumented NOP instead.
No.03681 M.A.S.H. Senior Tester Jan 29, 2009, 00:52	If you replaced the 8080 CPU with a 8085A, the speed of the boxer movement goes slower and it looks better. The CPU must be a 8085A ! Hope someone can hook up input and dipswitches and the dump is correct.
No.03688 aaron Developer Jan 29, 2009, 09:04	Clearly it's an 8085A. SIM is not an 8080 opcode.
No.03710 Justin Kerk Developer Feb 1, 2009, 08:35	Is that a bug in the 8080 dasm then?
No.03715 Luigi30 Tester Feb 2, 2009, 17:40 edited on: Feb 2, 2009, 17:41	Negatory. The problem actually seems to be that the 8080 uses the 8085A disassembler. I checked this by changing "sim" to "simba" in 8085dasm.c, set safarir back to 8080, and ran a dasm. I got a disassembly full of simbas.