Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02691 Sound Minor Always Nov 29, 2008, 14:19 Dec 4, 2008, 09:26
Tester Kekule View Status Public Platform MAME (Unofficial Binary)
Assigned To aaron Resolution Fixed OS Windows XP/Vista 32-bit
Status [?] Resolved Driver
Version 0.128u4 Fixed in Version 0.128u5 Build Normal
Fixed in Git Commit Github Pull Request #
Summary 02691: Some drivers with z80/ay8910 Audio: Audio tempo has changed
Description In some drivers - music tempo has increased. In others, decreased.
=Listed in Additional Information=
Steps To Reproduce
Additional Information Audio Speed Increase:
pandoras.c (02669)
timeplt.c

Audio Speed Decrease:
gyruss.c
jack.c
junofrst.c
megazone.c
nemesis.c
pooyan.c
rallyx.c (all sets but rally x sets)
rocnrope.c
tutankhm.c
Github Commit
Flags
Regression Version 0.128u4
Affected Sets / Systems Some drivers with z80/ay8910 Audio
Attached Files
 
Relationships
related to 02669Resolvedaaron  pandoras: music tempo is too fast 
Notes
7
User avatar
No.03158
Tafoid
Administrator
Nov 29, 2008, 19:04
edited on: Nov 30, 2008, 01:36
There was another 02669 that also affected music tempo being increased. Likely related. If anyone else finds sets/driver which have a noticeably increased music/effect tempo, please post a note here.
User avatar
No.03160
Luigi30
Tester
Nov 29, 2008, 22:25
edited on: Nov 29, 2008, 22:26
diff -Nru src-old/mame/audio/timeplt.c src/mame/audio/timeplt.c
--- src-old/mame/audio/timeplt.c 2008-08-10 16:32:08.000000000 -0700
+++ src/mame/audio/timeplt.c 2008-11-14 08:43:46.000000000 -0800
@@ -65,7 +65,7 @@
  {
  0x00, 0x10, 0x20, 0x30, 0x40, 0x90, 0xa0, 0xb0, 0xa0, 0xd0
  };
- return timeplt_timer[(activecpu_gettotalcycles() / 512) % 10];
+ return timeplt_timer[(cpu_get_total_cycles(space->cpu) / 512) % 10];
 }
 
 
@@ -109,7 +109,7 @@
  if (timeplt_last_irq_state == 0 && data)
  {
  /* setting bit 0 low then high triggers IRQ on the sound CPU */
- cpunum_set_input_line_and_vector(machine, 1,0,HOLD_LINE,0xff);
+ cpu_set_input_line_and_vector(space->machine->cpu[1],0,HOLD_LINE,0xff);
  }
 
  timeplt_last_irq_state = data;
diff -Nru src-old/mame/audio/toaplan2.c src/mame/audio/toaplan2.c

Did this break IRQ triggering?
User avatar
No.03161
Luigi30
Tester
Nov 29, 2008, 22:38
Sound is too slow in all drivers that use audio/timeplt.c for their sound (pooyan.c, locomotn.c, tutankhm.c, rocnrope.c) except for timeplt.c, where it's too fast.
User avatar
No.03168
Tafoid
Administrator
Nov 30, 2008, 01:31
Actually, it's rallyx.c (rather than locomotn.c) as strange as that might sound - but I can confirm those drivers have an issue.

I've found several other drivers too that have decreased audio tempo (some less pronounced than others):
gyruss.c
jack.c
junofrst.c
megazone.c
nemesis.c

Updating report with findings.
User avatar
No.03171
Luigi30
Tester
Nov 30, 2008, 03:31
edited on: Nov 30, 2008, 03:31
return timeplt_timer[(cpu_get_total_cycles(space->cpu) / 512) % 10];

Playing with the 512 in that adjusts the audio tempo, but the 512 is confirmed against schematics according to the driver. So it's a cycle timing issue?
User avatar
No.03190
couriersud
Developer
Nov 30, 2008, 23:46
Note for myself:

The code should not depend on cycles. It should use a timer to advance an offset counter.
User avatar
No.03204
aaron
Developer
Dec 3, 2008, 06:08
Note to couriersud:

attotime_to_ticks() is probably a useful function for this. Or it can be fixed to use the correct CPU's cycles.