Search options (Page 8 of 40)

I remember seeing that article before somewhere. Like the video, too, very detailed and thorough, just like the article. I'd have some small complaints about some of the more in-depth bits on code and such, but overall it's very solid.

Excellent, thanks a lot. I'm also glad to report that this version compiles out-of-the-box on Linux.

What about using Padauk PMS150c? Might make for a circuitry small enough to fit into an actual gift card.

Next DiHalt is coming up! Jan 6th-8th, with beeper compo as usual.

Ha, I always wondered how those work. Nice read indeed, thanks for sharing!
The part about using LSFR to produce frequencies is most interesting. I tried to implement this idea in a ZX beeper engine once but didn't manage to reduce the overhead from needing to implement the LSFR in software down to a level where it would offer any advantage over just using 16-bit counters.

I think the only demoparty with 1-bit music this year was DiHalt Lite. I also played 2 live shows this year, but nothing about them has shown up online so far. Still waiting for some videos for one of them.

Haha, no, I can't take any credit for that discovery, you figured that out by yourself!

I've done some experimenting with using bit 3 for reverb. However, volume levels for bit 3 vary considerably between 48K board revisions (not to mention different models), so it's not really useful. Generally speaking, the output from bit 3 is low enough that it can be ignored for practical purposes. (It does cause problems for engines with a high volume resolution, but that's another story.) Anyway, the main reason you'll see bit 3 being used is because it costs additional cycles to mask it out. Povver is a typical example of this: Use of bit 3 is by no means intentional, but there is at least one location where I couldn't find enough cycles to mask it. Aside from that, some PFM-based engines use bit 3 in sync with bit 4 for a little extra volume boost. Alone Coder's BeepTracker engines do this, for example.

It's totally unclear to me what's going on here. Let's wait for Noel.

Ah, crap. Here you go.

I see. Very strange indeed. Yes, sounds like it's running in contended RAM, but then it seems to run at pretty much the same speed as the 48K version!?! Well, let's first rule out contention issues. Could you export an .asm file from 1tracker, and post it here? (Or, if you want, assemble it yourself at 0xc000 and try it out. 1tracker's asm output works with sjasmplus.)

Also, have you tried with any other engines?

The problem on Speccy isn't so much one of finding some free cycles to update graphics. In fact, in PFM and Phaser type engines, you can actually waste quite a few cycles with barely any drawbacks. However, on Speccy we have this thing called memory contention. Very simply said, if you write to or read from certain memory locations on the Speccy, additional wait states will be introduced. While it is possible to predict when those wait states occur, actually writing an engine that will work around these limitations is extremely challenging, so basically nobody bothers. AMP16 is currently about as good as it gets when it comes to running 1-bit code in contended memory.