Search options (Page 27 of 39)

Haha, words can't describe what a massive pain in the a*** this was.
I didn't follow your suggestion of including some samples/instruments after all, because hopefully it should just work with any random sample out there now. Even random MOD imports should theoretically be reasonably safe now.

Updated the xm2zbmod converter. Fixing the relative sample offset bug was one of the hardest things I've done in recent times, certainly more difficult than the zbmod engine itself.

The new converter brings some changes, namely:

- 16-bit samples are now supported.
- Relative sample offsets other than F-6 (+29) are correctly handled now, as long as they're positive (ie C-4 or higher).
- The note range is no longer fixed. It's still 4 octaves, but the lower and upper limits will vary slightly (at most +/- 1 octave). You can run xm2zbmod with the new option "-r" to see what the actual range for each used sample is.
- You can now supply the option "-i <filename>" to convert a module that isn't named "music.xm".

I doubt the converter will be free of bugs yet, but I'd say it's at least ready for some beta testing.
Download is at https://github.com/utz82/ZX-Spectrum-1- … p?raw=true as usual.

Alright, fixed the floating links. Not the most elegant solution but I've had enough fiddeling for today.
Ok then, I'll keep the background for now, and we can decide later if we stick with it for good or not.

So I've finally managed to implement this header image. Thanks again to PROTODOME for the awesome design!

Hope it works ok for everyone, It was quite a hassle to fiddle this into the layout. I'm not entirely happy with it yet. For one, I would like to bring back the sub-heading text ("complex music from simple devices"), preferably without adding it to the image itself. Also, for the future I think styling the forum a bit more appropriately would indeed be nice. Not sure if a tiled b/w background wouldn't be too busy, but I'm gonna try some things once I  find the motivation to fight with the forum css again.

Not sure about the motivation behind that. I assume it's because Speccy demosceners are aware that the challenge lies in masking the effect. Also, because having those stripes in the border might distract from the actual design of the demo (or game). In the end, it's a matter of taste methinks.

Nice, thanks!

Ah ok, gotcha. Yes, wav2smp.pl takes raw headerless 8-bit, it doesn't really care about sample rate iirc. But I faintly remember there was a problem with that script, so it possibly produces incorrect results. I'll look into it if I can find some free time. You might as well write your own replacement. It's also possible to directly use raw wav (with the usual limitation of volume resolution), all you need to do is change the INCLUDE statements in samples.asm to INCBIN statements.

As far as textures go, I think besides basic waveforms, some simple percussion instruments (kicks, hi-hats) should also be possible to pull off. For anything more complex the 256b limit and especially the low volume resolution will probably prevent any recognizable results.

Samples for qaop must be exactly 256 bytes long. So simple waveforms will work best.
Also, volume range is limited to 6 steps in total (ie for both channels combined). You can overdrive up to 12 levels, if this limit is exceeded the player will malfunction. Nominal sample rate is 15625 Hz.

Ah yes, found the mp3. It does indeed sound quite noisy Some of that might be from the emulator, though.
But I do see room for optimizations.

   ld (Save_RegA),a
   ld a,_LOW
   ld ($1800),a         ;du son à Hector !
   ld ($1800),a         ;du son à Hector !
   ld a,(Save_RegA) 

should at least be

   ld (Save_RegA),a
   ld a,_LOW
   ld ($1800),a         ;du son à Hector ! - why twice? once should be enough?
Save_RegA equ $+1
   ld a,0

and since BC is unused, in most cases even

   ld c,_LOW         ;outside of sound loop
   ;...
   ld b,a
   ld a,c
   ld ($1800),a         ;du son à Hector ! - why twice? once should be enough?
Save_RegA equ $+1
   ld a,b

should do.

system-cfg.com seems like a nice place, I'll think about signing up. Though my French is really too crap for holding a proper conversation.

Excellent news, thanks for sharing. And of course, my respects to the author!
I'll have to see if I can get emulation going somehow, very curious how this sounds. I'm afraid adapting the code to memory-mapped IO might not have had the best impact on those tight timings.

Well, they *should* emulate the mic port. But in reality it seems the majority of emulator authors chose to emulate the beeper by ear (and I mean an actual human ear, not the socket) . The ear port behaviour is actually not very well understood, and there are currently no emulators which emulate it accurately afaik. The ear port has a high latency (meaning it can take a few thousand cycles before output to the mic socket can be detected on ear), and this latency seems to vary quite a lot between models and board revisions.

There is indeed also the possibility to use the ear port directly for sound, but the results are rather unpredictable (see http://problemkaputt.de/zxdocs.htm#spectrumsound). Hence my conclusion is that it's not worth using it, except perhaps to give a little extra overall volume boost. Alone Coder does that in his engines. I usually stick to outputting 0x10 (just mic), but for example Beepertoy uses 0x18 (mic+ear) in a rather unsuccessful attempt to boost the click drum volume.