Log in with to leave a comment.

I tried to call sound effects from assembler but no luck, it keeps silent.

* My game has disabled the kernal und the zeropages FD-FF is not used

* I exported the sound prg file to $e000

* In my program I set the volume to 15

* I called once: 

  lda $0   // effect

  ldy $0  // channel

  jsr $0e4a

* I used my own raster routine and called jsr $e2a9

Any idea?

(6 edits)

lda    $0 : loads the content of the location 0 in A  [A = PEEK(0)]
lda #$0 : loads the number 0 in A  [A = 0]

(idem for ldy $0)

You must use the second form (#$0). Please, double check these instructions.

P.S.: $0e4a is a typo, right? The correct address should be: $e04a

Let me know.


Please excuse my assembly skills, lda $0 is differnet than lda #$0... I embedded the sounds effects already in my game written in TRSE (Turbo Rascal) and now it works well. My game will be released soon and I would like to mention your tool in the credits if you don'nt mind. The game will be released as "FIZZ", I think also in

(1 edit)

I'm happy to know it works. For sure you can mention my tool, I'm looking forward to try your game. Thanks.

so my Game is out:

Ciao from a fellow Italian :)

This is quite an interesting utility, which at first I was going to use in my game, but then decided otherwise.

The main reason lies in the Export feature: while it makes sense to export a binary PRG file for BASIC users, it's quite limiting for Assembly coders.

In addition to providing the ability to export a binary file for BASIC programs, your utility should also be able to export an Assembly source file, with all memory addresses involved expressed with labels, not hardwired values.
This way, an Assembly programmer can easily incorporate your sound routine (and its data) into their source code, leaving their Assembler to correctly relocate the routine and its data.
This would also apply to the addresses in the zero page: they should be easily modified by directly editing the source file.

Not being able to do that made me abandon the idea of using your utility, such a pity.

Speaking of the Export feature: the part of the text concerning the Assembly folks shows some example code for the IRQ setup, the IRQ routine and how to play a sound. The first two pieces of code are actually redundant, as they are both included in the exported binary.
On the other hand, the callable routine to stop a sound, or the addresses to check if a sound has stopped playing, are not mentioned (one has to look in the BASIC section of the text to learn that).

Finally, a couple of minor bug reports:

  • The UI has a problem when opened in high DPI screens: some of the values are truncated (a workaround to this is to force the DPI compatibility to be handled by the System instead of the Application, which makes the whole text less readable but fully displayed):

  • Contrary to what is stated on the button, pressing ESC does not stop the sound, it just shifts the window focus to the Stop button (and then, even pressing the space bar doesn't stop the sound), so you are forced to use the mouse to do that.

I hope you'll take all that as constructive criticism, as I really like this tool, otherwise I wouldn't have spent more than an hour typing all this :)


(3 edits)

Ciao, thanks for the comment.

The export typically takes place by specifying a memory address and possibly other parameters such as the locations to be used in page zero: this is what the most famous music trackers (such as Goat Tracker) do and if you are using one, you certainly already had to reserve a memory area for the music (moreover aligned to 256 bytes, a limit that my tool does not have). Honestly, I don't think it's a big deal.

Yes, it's true that the IRQ routine is already present in the exported code, but it's more useful for those who use it in BASIC. The goal of the displayed assembly code is to show how to put the play routine inside your IRQ code (usually you just want to add the sound effects to an already existing IRQ routine). And yes, not all the addresses for the other routines were showed, but again the goal was just to show an example of use in assembly.

I didn't notice the stop button bug, I'll fix it.

As for the problem with high density screens, I've never noticed this because my screen is full-hd. I need to find a way to test it on my low definition monitor.

I'm sorry you see it that way, I'm sure doing as I suggested would have made the whole thing more flexible to use.

My screen is full-HD as well, it's not a resolution issue but a DPI one, and you can easily test it by setting an higher DPI value to something like 125% or 150% and then you should see the problem.


Any chance for a Linux version?

(1 edit)

Could someone confirm if this works on Windows 7?

It should work (I can't test it). Remember to run VC_redist.x86.exe to install any missing dependencies.

(1 edit)

Yes, I installed VC_redist.x86.exe, but Sid Sfx Editor does not work.

Did you install SP1 in Windows 7? Try installing all OS updates, I don't see any other reason why it shouldn't work with it.

(1 edit)

Yes, I have SP1 and all OS updates. I'd like to find out if anyone else with Windows 7 is having this problem?

What year Visual C++  are you using?

Will this run on x64 Windows?


How about Windows 7?


Looks interesting, one suggestion, why not let the user set the ZP addresses in the routine before export?


Good idea, I'll update the editor.

(2 edits) (+2)

Ok, I've added this functionality and also a tool to generate random sound effects.


Very nice tool!