676

(129 replies, posted in Sinclair)

Thanks for the reminder, Vinnny! I still haven't prepared anything, but I hope I'll find some time this week.

677

(4 replies, posted in Other Platforms)

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.

678

(4 replies, posted in Sinclair)

Hehe, thanks mate wink

Well, I have one more crazy idea that I need to put into practise, but after that I should really take a break from this stuff. Going totally nuts on it.

679

(17 replies, posted in Sinclair)

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) hmm. 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.

680

(17 replies, posted in Sinclair)

Why of course, you should always use the mic socket wink

Yes, overall volume is quite low unfortunately. One could probably get a little more volume by properly maximizing all samples, but overall there's not much that can be done about it, I'm afraid. Still experimenting though wink

681

(4 replies, posted in Sinclair)

Alright, one last engine before I'm going to take a couple of weeks off. This one is quite a beast, but the bad news is: there won't be an XM converter for this one. For details, I'll just quote the readme, I guess:

BEEPERTOY is a multi-paradigm sound routine for the ZX Spectrum beeper. It 
generates sound through a number of different methods, including pulse frequency
modulation, pulse interleaving, and wavetable synthesis. It also features some
advanced effects such as low- and high-pass filters, and a simple reverb.

Beepertoy is made up of a number of different "cores", each providing a 
different configuration. The user can switch between cores at any time between
two notes.

The available configurations as of version 0.1 are:

1) SQUEEKER EMULATOR: 4 channels of short pulse with configurable width
2) 4x PIN: 4 channels of pin pulse
3) TRITONE EMULATOR: 3 channels of square wave with configurable duty, with 
      various noise/glitch modes
4) OCTODE EMULATOR: 8 channels of pin pulse
5) 3x WAVETABLE + FILTERS: 3 channels of wavetable synthesis (256B tables), 
      optional global lo/hi-pass 
6) 2x SQUARE + FILTERS + VOLUME + FX: 2 channels of square wave with 
      configurable duty cycle, volume control, reverb or fixed-pitch sample, 
      optional global lo-pass, one of the channels can play noise
7) ROM NOISE: simple noise generator
      
All configurations provide additional support for configurable click drums.

There's explicit versioning on this one, because I intend to further expand and improve it in the future. For the time being, I have no specific plans other than adding a "mute" core which will output silence for a given length (so you don't have to waste too many bytes on this), and increasing drum volume a bit. But there's still lots of free memory available, hoping to fill that up with more features later on.

download
source
demo tune

Ace! Very intricate composition, I like how the various melody bits meet and diverge again at times.

683

(17 replies, posted in Sinclair)

Well, I use fuse for development, so it'd be rather odd if the taps wouldn't work (except the CMOS one, which will give no sound except on Pentagon and such). Does the NMOS version work properly on your FPGA machine, or does it have the high-pitched beep like in fuse?

Test tune XM is attached. I'd rather not publish the one for booom, but I'll mail it to you if you like.

684

(17 replies, posted in Sinclair)

Already made this a couple of months ago, but didn't release it earlier because I wanted to "troll" the next best beeper compo with it first. de:coded provided the opportunity (not sure if I was successful because the results file is still not released), so here we go.

zbmod is a 3-channel mod player, meaning it plays PCM WAV samples of arbitrary length, like SampleTracker. It has a few advantages over the latter, though.

- better sound (still plenty of noise of course, but still a massive improvement over ST's replayer methinks)
- better note range
- possibility to use looped samples

On the technical side, the mixdown runs at about 9 KHz, with 21 relative volume levels. The routine uses the undocumented "OUT (C),0" instruction, so there different versions for NMOS and CMOS are required. I was too lazy to add CPU detection again, sorry wink

I also tried some things which were only moderately successful. Firstly, reloading data is done during the sound loop. This was a major p.i.t.a. to code, and ultimately didn't reduce noise as much as I had hoped, so I'm still not sure if it was worth the hassle.
Secondly, sound generation is done in a way so the beeper will always stay afloat* (ie it won't retract completely). This works reasonably well on hardware, but on emulators, a high-pitched parasite tone will be introduced. I've included a special emulator version which reduced the parasite tone somewhat, albeit at the cost of a lowered overall sound quality.


Anway, long story short, here are the usual links:
download (includes XM converter)
source
demo tune

*Ok, some words about the reasons behind this. zbmod switches the state of port #FE with 8 t-state precision. However, this is a problem if one wants the beeper to be "on" for exactly 8 t-states (= rel. volume level 1), because the fastest switch would still take 11t (out (#fe),a). The 3t difference would be neglicable, but switching after 11t would introduce a lot of noise because of IO contention. So the earliest moment to switch state would in fact be after 16t, at which point we've already reached volume level 2. How to solve this? zbmod simply pretends that 16t uptime is volume level 0. Works fine on hardware, but unfortunately it fails on emulators. I assume this is due to errors introduced by the quantization of the beeper output, so it's not something that can be easily fixed with better emulation. So this approach is ultimately a bad idea considering a lot of beeper fans don't have access to real hardware.

685

(164 replies, posted in Sinclair)

With a lot of fiddeling, I finally got 1tracker 0.23 to run on Linux.

Steps to take:

1. Replace makefile and main.cpp with the ones attached
2. In angelscript_jit/as_jit.cpp, replace all occurances of "../source" with "../angelscript/source"
3. Delete contents of angelscript/lib
4. Get http://www.angelcode.com/angelscript/sd … 2.31.0.zip , unpack, copy folder angelscript/projects to angelscript folder in 1tracker source
5. make in 1tracker_src/angelscript/projects/gnuc
6. make in 1tracker_src
7. copy contents of angelscript/lib to your system library directory (usually /lib)
8. copy 1tracker binary to 1tracker folder

Yeah, it's pretty akward and I don't understand half of what's going on. Also, the filebrowser is kinda broken, it can't leave the 1tracker folder. But at least it runs.

686

(4 replies, posted in Sinclair)

Just spend several hours writing an engine to investigate my theory about volume ramping. Findings:
- Volume ramping does happen, but it can't be the only culprit.
- Volume ramping seems nearly impossible to control in a meaningful way. The effects are pretty random, certainly not the nice AY buzzer effect I was hoping for. Also, it glitches all over the place which is something I didn't expect. Perhaps I have some bugs in my engine, but I actually calculated the timings several times now and can't find any errors. So, I'm giving up on this for the time being.

Uh, sure. I have absolutely no clue about this stuff though, so if possible pull a backup from time to time in case I break something.

688

(4 replies, posted in Sinclair)

Thx guys wink Barely any post-production, just a tad of added bass (+3 db). For me, fuse adds quite a bit of distortion when 7 or 8 channels are active. There is some distortion on hw, but it's less intrusive and more irregular. Fuse makes the bass sound like a YM buzzer in saw mode, on hw it's more of a muddy, fuzzy kind of sound. Oddly enough with fluidcore it's the other way around - fuse sounds rather clean, whereas hw has random clicks and pops and a nasty buzz when going into higher volume levels. In any case it's surprising, since normally fuse's beeper emulation is quite excellent. Guess I should eventually talk to fred about this, but I first want to investigate a bit more myself.

Also, the more important question for me is what causes these distortions in the first place. At the moment, I have two theories.
1) Full speaker expansion is reached before the sound loop is completed, hence the sound is clipping. However, if that was the case, pulse-interleaving engines should also have that problem, but generally they don't exhibit these symptoms.
2) Speaker cone response is non-linear, ie the cone starts to expand slowly and then gradually moves faster. I think this is more likely, so I'll be looking into this.

Edit: I think I've figured it out. Third, much more logical hypothesis:

3) The problem is that I'm only looking at speaker cone expansion, but not at contraction. Now, when a string of several high volume samples is played, the speaker cone has no time contract inbetween, hence the volume starts to ramp up. For pulse-interleaving engines this is rarely a problem because there, on and off states are alternating most of the time, preventing volume ramping. But fluidcore, wtfx, and Octode 2k16 only toggle the state once or twice within a sound loop frame, so I need to add another mechanism to prevent volume ramping.

This also gives me another idea - perhaps the volume ramping phenomenon can actually used on purpose to simulate the AY buzzer effect. Hmmm... exiting days for beeper.

689

(4 replies, posted in Sinclair)

Nothing special really, just some practise so my asm skills don't get rusty during all that C++ learning I'm doing recently.

Octode 2k16 is basically a rewrite of Octode PWM with better sound and an increased frequency range. Variable duty cycles have been axed in this version, instead you get some limited volume control on the 3 available click drums. Code is rather sloppy and there are quite a few cycles left, so perhaps I'll add some more features later on. Also, Octode 2k16 uses the OUT (C),0 instruction, so like with fluidcore, there are two different versions for NMOS (regular ZX, emulators) and CMOS (Pentagon, Eva, etc.) CPUs. I was too lazy to add CPU detection code, so for now just select the version you need.

download (XM converter included)
source
test tune

Test tune is recorded from 48K hardware. It's interesting to see how emulators fail to handle this fast switching code properly (same with fluidcore), even though it's very similar to regular pulse interleaving.

Awesome, thanks! Glad things went ok.

As far as I can tell, the header image should be in /img, and then some changes in style_cs.css are required:
- in section #brd-head, add "background-image:url(img/header.gif);"
- in sections #brd-title and #brd-desc, add "display: none;" to disable the text (I should probably add the description text to the header image, but let's see if this works at all first)

Alright, let's adopt the one from post 21, then.
d0x10, would you be so kind to try integrating it?

Damn, was gonna make a joke with the pointy m poking through an ay chip with some splatter, but gimp botched the render.

Anyway, I like kinda like the pointy things, they look a bit like a chip pins, no?

Yeah, I'd vote for #2. Or #1, but then with a shorter dash. Perhaps also flipped vertically and maintaining the 2px spacing from the rest of the chars.

edit: uhhmm, like this perhaps?

http://irrlichtproject.de/transfer/1bitforum5.gif

Arrrghh... and I just persuaded PROTODOME to remove the dash/spacing.

Excellent, thanks a lot mate. I think #2 looks best.

Yes, awesome. Just one last thing, I think the "m" still looks a bit heavy/solid compared to the rest. Do you think that could be helped somehow? I tried breaking up the horizontal line with another triangle but that looked rather silly.

Oh yes, looking sweet! I'd like to suggest a few tweaks to improve the readability though. What do you think about making it read "1bitforum", ie. something like this:

idea

Not so happy with the "1" yet, though. Perhaps it should also be more solid, like the "u" and "m"?

698

(11 replies, posted in General Discussion)

Aww yis, ZX Spectrum Orchestra! They are pretty big nowadays with their follow-up project: http://www.modifiedtoyorchestra.com

699

(2 replies, posted in Sinclair)

Can't help with that, sorry. I have a WinXP install just for running Beepola and some legacy tools yikes Other than that, blaming pulseaudio would have been my first response as well big_smile

It should be possible to increase the buffer size through ALSA. Looked it up a while ago when somebody was having troubles with something on cm.org, but forgot all about it. Worth doing some digging in that direction though.

That's a very reasonable concern wink However, I believe we're on a version that proved to be, uh, not so successful, and was quickly replaced with another one. 1.4.4 on the other hand hasn't been updated in over half a year, so I assume it should be reasonably stable.