Echo 1.5

Talk about development tools here

Moderator: BigEvilCorporation

Post Reply
User avatar
Sik
Very interested
Posts: 579
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Echo 1.5

Post by Sik » Sun Jul 23, 2017 6:37 am

Here comes another upgrade ( ゚-゚) (amusingly, the blob is smaller than 1.4)
https://github.com/sikthehedgehog/echo

WARNING IF YOU WERE USING ECHO 1.4: the ABI for Echo_SetVolumeEx has been changed to expect 16 bytes instead of 13. Currently the extra bytes are ignored anyway, but you should consider updating your code (just fill the extra bytes with zeroes).

And now for the updates:

Pausing music

It only took seven years! :v

Echo_PauseBGM will pause the BGM stream, Echo_ResumeBGM will resume it (d'oh). And this time it works. Note that only BGM is affected: the SFX and direct streams will keep playing as usual.

Synchronization flags

New to Echo 1.5 are flags that can be used to synchronize between the 68000 and music (since timing isn't 100% precise and it's just better to insert clues into music instead of hardcoding them). Two new events ($FAxx and $FBxx) are used to change the flags from the Z80 side, while three new functions (Echo_GetFlags, Echo_SetFlags, Echo_ClearFlags) are used to manipulate them from the 68000 side.

Looping SFXs

Now sound effects can loop. Dunno, it was requested. If you play such a sound effect then you need to stop it manually (either directly with Echo_StopSFX or indirectly by calling Echo_PlaySFX again).

Another command slot

Now the 68000 can send up to two commands (instead of one) before having to wait for Echo to process them. Probably useful for when you want to send a BGM and a SFX command at the same time, though it's up to you. Note that direct streams have their own mechanism so they aren't affected by any of this.
Sik is pronounced as "seek", not as "sick".

User avatar
Sik
Very interested
Posts: 579
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Echo 1.5

Post by Sik » Tue Jul 25, 2017 7:08 am

Minor update to 1.51.

The change is in Echo_GetStatus (and its C counterpart): the returned status will take into account any pending commands (i.e. that were just sent but still not processed by the Z80), so if you e.g. call Echo_PlayBGM then Echo_GetStatus, it'll show up as BGM playing even if the Z80 didn't get to it yet. This is cheating, but lines up more closely with programmer expectations, and should make things easier.


Technical explanation

We're going straight into hardcore multithreading territory here.

When the 68000 sends a command to Echo, it won't be executed immediately, but rather whenever the Z80 is free (more specifically, once it's done processing the current tick for all streams). If you tell it to play or stop a stream, the status flags will be updated accordingly once Echo gets to processing the commands. The problem is if the 68000 tries to retrieve the status right after sending such a command, since it's likely the status won't have updated yet, and this catches programmers off guard since they don't realize that they need to wait for Echo to handle it.

What this patch does is change Echo_GetStatus to look ahead at any pending commands (i.e. commands that haven't been processed by Echo yet) and guess what the status would be if Echo had already processed them (i.e. if a play BGM command was pending, it'll set the BGM playing flag), and then return this new guessed status instead of the real one. This way game code doesn't have to explicitly handle waiting for Echo to process commands.

tl;dr it's trying to predict the future =P
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2466
Joined: Fri Aug 17, 2007 9:33 pm

Re: Echo 1.5

Post by Chilly Willy » Tue Jul 25, 2017 2:36 pm

Or you could define a busy flag that is returned by status until the command is processed. That would let the 68000 know that it needs to call status again later. Setting the command would set the status to busy, and the z80 would change it to the real status when it got around to processing the command. Then you no longer have to predict the future! :D

User avatar
Sik
Very interested
Posts: 579
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Echo 1.5

Post by Sik » Wed Jul 26, 2017 2:33 am

The idea is precisely to not have to wait on the Z80, since it could easily take up a good chunk (even most) of a frame depending on how unlucky is your timing. You don't want to risk a game being halted for a whole frame every time a sound plays just because you sent a command to Echo and need to monitor whether sounds are playing or not.

For the record, there's already a "busy" flag (bit 15), albeit it tells you whether sending a new command would risk the 68000 being forced to wait or not (i.e. the scenario mentioned above). Now that it's possible to send multiple commands at a time maybe there should be a separate "commands pending" flags (i.e. if any command is pending, regardless of whether more can be queued yet).


EDIT: by the way thinking about this more, what you mentioned is indeed the way Echo used to work. And that still caught programmers off guard, because Echo is opaque to them and they just think everything is instantaneous =P This is literally cheating for the sake of convenience.
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2466
Joined: Fri Aug 17, 2007 9:33 pm

Re: Echo 1.5

Post by Chilly Willy » Wed Jul 26, 2017 2:42 pm

:D

Yeah, sometimes you just have to expect people to do the WRONG thing and work around it. :?

When I talked about having a busy flag that you could check, I meant you'd check it and if busy GO DO SOMETHING ELSE, then check it again. But I do imagine idiots would simply sit in a loop checking until it wasn't busy. :lol:

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest