- --
Viewing Issue Advanced Details
[ Jump to Notes ]
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
Notes
7
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. |
---|---|
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? |
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. |
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. |
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? |
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. |
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. |