From 89f4df576017bad8ff7456760edf089d533a06f5 Mon Sep 17 00:00:00 2001 From: hap Date: Wed, 27 Mar 2024 14:53:39 +0100 Subject: swp00: fix m_global_step array out of bounds error --- src/devices/sound/swp00.cpp | 4 ++-- src/mame/skeleton/sterz80.cpp | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/devices/sound/swp00.cpp b/src/devices/sound/swp00.cpp index 781bdadeded..119099526b3 100644 --- a/src/devices/sound/swp00.cpp +++ b/src/devices/sound/swp00.cpp @@ -343,7 +343,7 @@ void swp00_device::device_start() save_item(NAME(m_dpcm_next)); save_item(NAME(m_dpcm_address)); - for(int i=0; i != 128; i++) { + for(int i=0; i<128; i++) { u32 v = 0; switch(i >> 3) { default: v = ((i & 7) + 8) << (1 + (i >> 3)); break; @@ -1393,7 +1393,7 @@ void swp00_device::sound_stream_update(sound_stream &stream, std::vector> 1); + m_lpf_done[chan] = istep(m_lpf_timer[chan], 0, m_global_step[m_lpf_speed[chan] & 0x7f] >> 1); else m_lpf_done[chan] = istep(m_lpf_value[chan], m_lpf_target_value[chan], m_global_step[m_lpf_speed[chan]] >> 1); diff --git a/src/mame/skeleton/sterz80.cpp b/src/mame/skeleton/sterz80.cpp index bf90bbf7251..db0cdb1c5eb 100644 --- a/src/mame/skeleton/sterz80.cpp +++ b/src/mame/skeleton/sterz80.cpp @@ -48,7 +48,7 @@ Notes: being highly likely that the program is encrypted. 29F002 - AMD AM29F002 PLCC32 (surface-mounted) EEPROM. This is connected to the OKI chip and holds the audio samples. DS12B887.U12 - Dallas DS12B887 Real Time Clock Module. This looks suspiciously like it's used for protection data? The PCB contains a battery - (for game settings or high scores?) and a 93C46 EEPROM (for game settings or high scores?). No other data needs to be sorted + (for game settings or high scores?) and a 93C46 EEPROM (for game settings or high scores?). No other data needs to be stored anywhere. The DS12B887 is connected to the EPM7192 chip. It's possible it might just be for time/bookkeeping. The chip (dated 9614) is dumped but I'd be surprised if the battery inside was still alive and the data is good, although the data isn't just garbage and reads the same each time so by some miracle it might be ok. -- cgit v1.2.3