Search options (Page 6 of 41)

Yep, I'm using Print, and it's called twice here. Ehhh... well, it's not causing any major issue, so I'd say let's just walk away from this one.

Also found the bug that causes peskysoundzx to segfault. It seems that Angelscript does not like implicit type conversions in conditionals. The following changes to peskysoundzx.1te will fix the problem:

line 542:

    if(row<int(songLoopStart))//start before loop

line 549:

    if(row<int(songLoopEnd))//start inside loop

line 748:

    if(takeLoop==1) if(row>=int(songLoopEnd)) row=int(songLoopStart);

Spent some time trying to tackle the notorious "Z80Ass error: label already defined!" error again. I still don't know what exactly is going wrong here. The .loop label is indeed set twice under some circumstances (at the start of a block, in any case). So for esex, it will output this:

.song
.loop
    db #68,#00,#82,#e4,#82,#e4
.loop
    db #01,#01,#01
    db #00
    dw .loop

Anyway, I found a possible fix. In the affected engines, you usually have something like this near the beginning of the Compile function:

    row=startRow;
    takeLoop=0;

    if(oneShot==1)
    {
        len=1;
    }
    else
    {
        len=songLength-row;
        loopRow=-1;

        ...

Initializing loopRow to -1 before the conditional instead (so it affects both branches) prevents the error from occuring. Not sure if it causes any problems further down the line. I haven't noticed any yet.

Btw it seems the assembler always runs twice. Is this intentional?

Whoa, a wild garvalf appears! Good to see you're still around, mate.

Btw, I think I know what you mean re: maths now. It's often kinda tricky to know what the resulting perceived tonal frequency will be.

I think that generally, pre-calc is a viable option. The number of unique notes in a song is usually not that high, so size-wise it's probably ok. More broadly speaking, pre-calc could open up quite a few new paths for beeper. We'd just need an editor that supports that *cough cough*

The alternative would be to, well, use a suitable modulator, which boils down to having one or more additional counters/oscs. Which is what lead me to the "scheduler" design I described above. The whole scheduling part is actually not that important. The core idea is to unroll the sound loop, say, 8 or 16 times, updating the main counters on each iteration and spreading out the more expensive computations across the various iterations. When using a 12-bit main counter, updating an auxilliary 8-bit counter every 16 sound loop iterations should give sufficient precision and speed.

My last, failed experiment uses something along those lines. It's running off 32 byte wavetables (which, in conjunction with an 8-bit main counter, gives a reasonable frequency range). When the aux counter overflows, a variable offset is added to the wavetable pointer, and the offset itself is negated. The problem is that my usual 16-32-64-112t PCM renderer is too noisy, so I would need to rewrite the whole thing using multi-core (ie, one copy of the sound loop for each volume level). It should be possible without duplicating all the "expensive calculation" versions of the sound loop, but eh... it's still a lot of tedious work.

Neat idea, don't think we've used that anywhere yet.

I wonder if it could be pushed even further. Like, instead of every frame, add the offset at a variable rate. That could perhaps turn into a sort of 1-bit FM, without the use of PCM emulation trickery. (Sorry for hijacking your idea immediately, but I recently tried to implement actual FM again, and came to the same conclusion as last time: It's possible to do the necessary calculations fast enough, but the output is too noisy for reasons not entirely clear to me.)

TOO QUIET!

Ha, I thought Tufty's unce track was going to win, since it was so well received at the party.

Cosmic Puppy is indeed an excellent track. AER really re-invented himself with that. Though I think Noise In My Head is the best in terms of composition. Stellar work on the drums and those Shiru™ delays. Both your tracks are Earth Shaker EX, right Shiru?

Anyway, I think this was the strongest compo we've had in years. Good times for beeper.

Thanks! The bad news is that eliminating row noise in this way is tedious as hell. 0/10, would not do it again. Even zbmod with its 20something cloned cores was more fun to write.

Btw, forgot to mention, the engine breaks Fuse. A work-around is to go "Media"->"Tape"->"Clear" after starting the tune.

As I was looking for an alternative, I surveyed a few other emulators running on Linux on their beeper capabilities. Results were mixed.

• Mame: Still the same. Passable beeper emulation, but not as good as Fuse's. Also, no auto-load capabilities.

• jsspeccy: Very noisy beeper emulation. Not usable.

• ZEsarUX: Errr, no. Just no. With "real beeper" mode enabled, the sound is muffled as if it came from under a pillow. Turn "real" mode off and you're left with a screeching, grinding noise that bears 0 resemblence to the actual sound.

• Xpeccy: I remember this having rather bad beeper emulation, but apparently it's improved quite a lot. It's a bit too clean, but definitely usable. I would consider switching (also because of the fantastic debugger), but unfortunately graphics render with extreme tearing. Also, no key combo to exit the program AND ignoring SIGTERM? Come on.

So, all in all, let's hope Fuse will fix this problem. Submitted a bug report, but no response yet.

Thanks. Planning to submit but don't have anything yet.