| recording speaker timings [message #394369] |
Fri, 08 May 2020 11:50  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Hello
I was working on replicating some sound effects from some games.
With AppleWin I can do this by putting a debug memory trap on $C030
and noting the elapsed cycle count between accesses. This is slow
to do manually though.
Do any emulators automate this? Where you could write out the speaker
access patterns, possibly so you could run the results through a player?
Vince
|
|
|
|
|
|
| Re: recording speaker timings [message #394384 is a reply to message #394369] |
Fri, 08 May 2020 19:57  |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 9 May 2020 01:50:09 UTC+10, vi...@pianoman.cluster.toy wrote:
> With AppleWin I can do this by putting a debug memory trap on $C030
> and noting the elapsed cycle count between accesses. This is slow
> to do manually though.
It's a shame the cycles isn't logged in a trace file (type help tf).
I would log an issue asking for this. Then you can grep it for C030.
Cheers,
Nick.
|
|
|
|
| Re: recording speaker timings [message #394398 is a reply to message #394384] |
Sat, 09 May 2020 09:28 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 9 May 2020 00:57:17 UTC+1, Nick Westgate wrote:
> On Saturday, 9 May 2020 01:50:09 UTC+10, vi...@pianoman.cluster.toy wrote:
>> With AppleWin I can do this by putting a debug memory trap on $C030
>> and noting the elapsed cycle count between accesses. This is slow
>> to do manually though.
>
> It's a shame the cycles isn't logged in a trace file (type help tf).
>
> I would log an issue asking for this. Then you can grep it for C030.
>
> Cheers,
> Nick.
I agree - the abs cycle count should be traced-out by the 'tf' (trace-file) cmd.
Taking this 'tf' cmd a bit further, it could be extended to only trace-out an opcode when a breakpoint/watchpoint is hit. Similar to Visual Studio's Tracepoint feature (but without the conditional support).
So in this mode, the "hit" wouldn't stop execution, but it would just emit a trace line for this opcode.
You could use this to create just a trace of $C030 accesses, or $C0En (for Disk II) or $C4nn (eg, for Mockingboard).
I guess you'd need a special "end tf" breakpoint too, or perhaps each breakpoint/watchpoint could have an extra attribute saying whether it behaves as a normal "break execution and enter debugger" or as a Tracepoint.
I'll have a think about the best way to add this, but personally I can see a use for this.
Tom
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
