On Sun, 28 Jun 2020, BALATON Zoltan wrote:
SCREAMER: ### AUDIO WRITE! 0 / 11104 - 11104
Unassigned mem write f3011190 = 0x900
Unassigned mem write f3011190 = 0xb00
Unassigned mem write f3011190 = 0x900
Unassigned mem write f3011190 = 0x900
With increasing screamer buffer size (you may want to fix this and
prevent buffer overflows, maybe should allocate it dynamically based on
what the guest programs?):
diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index 75f1853a7b..05b289e086 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -108,7
On Sun, 28 Jun 2020, BALATON Zoltan wrote:
Here it is with --enable-debug and additional screamer debug:
SCREAMER: screamer_read: addr -> 0
SCREAMER: screamer_write: addr val 11
SCREAMER: screamer_control_write: val 17
SCREAMER: basic rate: 44100
DBDMA[10]:
Here it is with --enable-debug and additional screamer debug:
SCREAMER: screamer_read: addr -> 0
SCREAMER: screamer_write: addr val 11
SCREAMER: screamer_control_write: val 17
SCREAMER: basic rate: 44100
DBDMA[10]: writel 0x080c <= 0x0010
On Fri, 26 Jun 2020, Mark Cave-Ayland wrote:
Again I'm wary of adding empty devices here as the main issue around the
screamer
code (and why it has not been submitted upstream) is that it can cause random
hangs
for MacOS on startup. Does it regress any MacOS 9 through 10.5 boot tests?
FWIW
On 16/06/2020 14:47, BALATON Zoltan wrote:
> The only thing this returns is an idle status so the firmware
> continues, otherwise just ignores and logs access for debugging. This
> is a stop gap until proper implementation of this device lands.
>
> Signed-off-by: BALATON Zoltan
> ---
>
The only thing this returns is an idle status so the firmware
continues, otherwise just ignores and logs access for debugging. This
is a stop gap until proper implementation of this device lands.
Signed-off-by: BALATON Zoltan
---
hw/misc/macio/macio.c | 34 ++
1
