(20 replies, posted in Sinclair)

Well, Octode XL used in Rain is not really a pin pulse method, not in the usual sense of the word, because pins are at least as wide as the period of discretization loop (and are often wider). Squeeker method is also a funny mixture of two other mixing approaches. I got behind your recent work on new engines (you make too many of them, mate!!! smile ), but I think that the overall question of which mixing method would be more suitable for in-game music is still very much open in my mind.

I.e., the principles I covered in my write-up have nothing to do with the method of mixing. OK, I based Rain on Octode XL because it has low discretization frequency, which made it easier to interleave audio and video codes at high frequency. You can probably make similar claim about the Squeeker engine. I do not think we have any other guidance in this case, do we?


(20 replies, posted in Sinclair)

utz wrote:

I don't think there is any code for the method Shiru describes, because nobody has implemented it. The idea for continuous sound would be not to call the sound generator through an ISR (because 50 Hz is too slow to make anything but the lowest audible tones), but to interleave it with the multicolour code at regular intervals. The usual restrictions with contention apply there, so it would still be quite tricky.

Actually, I have implemented exactly this idea in my 1K intro "Splash" (2014). The beeper engine there is very simplistic, single voice, but this is purely due to the size limitations I was dealing with.

In fact, I think that it won't be a large overstatement to say that most of my beeper experiments were about trying to push the envelope of how beeper sound can be combined with other things.

Shiru's methods 1 and 2 can be found in quite a few old games with beeper music. I never liked the resulting sound, so I did not do much research on it. Hence, I am not sure if e.g. Manic Miner uses method 1 or method 2 (method 1 seems more likely, given the lack of vsync in the game). My beeper scroller in "Dat Fuzz" (2014) is using, I guess, a variation of the method 2, with one modification: the visuals occupy small fixed time remaining after playing something like 2.5 frames of sound. So, improving the quality of sound is easy - just ensure that the sound does not get interrupted much.

Like I said, method 3 in Shiru's list can be found in "Splash" (2014). At the same time, outside of beeper, I am pretty sure that at least some demos with digital sound use a similar approach (e.g. "Scroller" (2010) or "Atarin" (2018)). In fact, I'd say that the devil is in the implementation detail: visuals usually require v-sync, while beeper (or digi) need +- constant rate of updating, which does not fit well with updating visuals synchronized to vsync or, more generally, doing any non-trivial logic. Specific solutions of this clash of needs can be different and varied; what I did in Splash does not make me happy and I am currently experimenting with another approaches.

A good way to think about all these methods is to think about code responsible for visuals as something that "distorts" sound. Then your strategy to improve the sound quality would always be about something that reduces the distortion. The larger proportion of time you can spend on making the sound, the better sound quality you'd get. This applies to all three of Shiru's methods.

However, there are other methods for reducing the distortion. Instead of trying to reduce the "amplitude" of the distortion ("amplitude" in the PWM sense would be the duration of anything that is not generating sounds), you can change the dominant frequency with which distortion occurs. E.g. the scroller in "Dat Fuzz" operates on the basis of one scroll every 3 frames only partly because this was the only way to significantly change the proportion of time between the work of the beeper engine and the work of the visual code. It is also important that the base frequency of the resulting distortion becomes 18.5Hz (which cannot be heard) instead of the pretty obvious 50Hz produced by engines operating on the basis of single frames logic. If taken to the extreme, some games do all drawing between the rows in the beeper engine, which tends to mask quite well even pretty significant interruptions in sound. Of course, from the point of view of visuals extremely slow updates do not work very well.

My demo "Rain" (2016) was an attempt to see what happens at the other end of the spectrum. What would happen with the sound if the distortion was to operate at very high frequency? In "Rain", the visual code occupies every 4th iteration of the sound loop running at something like 12kHz. It does distort the sound, but the nature of the distortion is such as to create "spacey" sound, which seems a lot more acceptable that what methods 1 or 2 can provide you with. Of course, the type of code you need to write for this mindset is not very vsync-friendly and, in fact, is not very visual-effects friendly. However, you do get surprising amount of time for doing useful work beyond making the sound, so definitely consider this approach too.


(12 replies, posted in General Discussion)

For this particular track the second recording sounds exactly like my mod on ZX Spectrum. (Is it a ZX Spectrum version actually?) The first version sounds a bit strange, possibly slightly detuned.


(12 replies, posted in General Discussion)

xxl wrote:

can I get this .xm to convert music to Atari?

I've got permission from the author; so, drop me an email at zxintrospec@gmail.com and I'll reply with the .xm.


(12 replies, posted in General Discussion)

I compiled this track using a modded version of Tritone, with significanlty reduced row transition noise.
It was written in .xm, and compiled using a custom version of the converter by Shiru.

This mod was, partly, inspired by xxl's Tritone player for Atari - I could not tolerate the fact that Atari sounds so much cleaner smile


(1 replies, posted in Atari)

I should have written this a long time ago, but I was not around for a while.

XXL, congratulations on great conversions of the sound engines. I am especially impressed with your port of the Tritone - the row transition noise is all but eliminated. Amazing work! We've got to catch up on ZX Spectrum...

I am so totally not surprised by this revelation smile

I did 100% the same thing when I was working on my old Tank Battle game - I had no time to create an editor for my engine, so I modelled my data format (and engine to some extent) around WHAM and got a friend to write some music in WHAM, which was then trivially converted by hand and played back using my own beeper engine.

3) utz, it is actually Lyndon Sharp's engine (just wait for the drums to kick in).


(129 replies, posted in Sinclair)

@xxl, apart from being a great composition, this is also a modded Tritone engine, with reduced row-to-row transition noise and removed I/O contention noise.


(21 replies, posted in Sinclair)

Returning back to the topic: utz, I always knew that beeper was more rock'n'roll than AY, but massive thank you for providing plenty of convincing evidence recently.

I always thought that beeper must be good for emulating overdriven instruments.


(13 replies, posted in Sinclair)

utz wrote:

introspec, so basically like a reverse Tim Follin player? big_smile

No, not really, Tim Follin's player is not a real inspiration. This one is: http://zxart.ee/eng/authors/j/jonathan- … -beeper-1/

Of course, we can do better nowadays. Much better in fact.


(13 replies, posted in Sinclair)

I am currently working on something slightly similar, AY+Beeper mixed driver. Beeper will be used for digital drums.


(20 replies, posted in Sinclair)

This is just amazing, mate! Really, really good.


(4 replies, posted in Sinclair)

Good idea and it makes a lot of sense too given the limitations of the format.


(135 replies, posted in Sinclair)

I only modulated my "main wave" using another wave with the period that was exact multiple of the period. So only the duty cycle was a bit wobbly. Hence, I did not have any aliasing problems at all, and I did not need low-pass either, because I could do low-pass type sounds with the FM itself smile


(15 replies, posted in General Discussion)

4/180 ~ 1/45, i.e. about 2.2%. My guess is that one of them emulates contention, whereas the other does not.
This is why we need headers actually saying what configuration your measured time corresponds to.


(15 replies, posted in General Discussion)

FrankT, the website is using ZXTune to render .AY into web-friendly formats.
Hence, you can just read documentation for ZXTune or simply use it directly to establish accurate timings.
The problem of course is that if ZXTune will be replaced by another renderer in the future, all your hard work will be in vein.


(15 replies, posted in General Discussion)

FrankT, .AY players do not get store the configuration information in .AY headers. Hence, the players are allowed to play as if they were uncontended 48K models, or contended models, or models with various numbers of t-states per frame. You just get no guarantees whatsoever. Frankly, .AY needs to be re-designed to take configurations into account, otherwise timings will never be spot on. Abarimal proposed a way to smuggle configuration information via some non-standard interpretation of less useful standard fields, but I always felt that this is not the proper way to do it.


(14 replies, posted in Sinclair)

On uncontended machines most timings are aligned perfectly or nearly perfectly (I did have to cut some corners for the sake of keeping my sanity smile ). On the contended machines, depends on the particular scene. Some of the effects do not interact with the slow memory much, so should sound a bit better. The rain does work with the screen memory rather heavily, but I do not think it is very obvious from the point of view of the sound quality.

So, yeah, it all sounds a bit flimsy and dangerous. This is why before I started work on the demo I, firstly, made sure that interlacing the soundloop with empty cycles does not bring the quality down too much. I actually made tests and established what I can get away with in several parts of the beeper engine, e.g. between rows, between patterns, etc. Secondly, I wrote the rain effect and made sure that it looks like rain and once again, that it does not spoil the sound quality too much.


(14 replies, posted in Sinclair)

utz, I pretty much ignored contention for the graphics part of the sound loop. It is only one iteration in 4, so it is nowhere near as dramatic compared with the usual contention noise. Otherwise, I think this would become unbearable to code.

There is no synchronization per se in this demo. Everything is just a massive beeper engine. In fact, it was easier for me to code each scene as a separate beeper engine, which made it repetitive and well-compressible.

AtariTufty, yes, the stock Octode XL drums are a little bit lacking, so I thought that adding AY drum makes it sound a bit better.


(14 replies, posted in Sinclair)

The effects are integrated into the sound core. Basically, out of each 4 iterations of the sound core, one is spent doing something visual. This has to be done using a special protocol (only a few registers are available) and making sure that the timing is fixed. More complex effects, e.g. rain itself, would not fit into a single iteration of the sound loop, so they have to be done using state machines.

It gives you surprisingly large amount of time for effects. In most scenes (excluding rain) I have to introduce various types of delays and time-wasting cycles, so that the thing does not rush too much.

I reckon this trick would work with any pin-based engine. In the case of "Octode XL", because we do regular Octode XL for three iterations of the loop and then do something else, it basically modulates all sounds at a frequency of few kilohertz. This makes it sound a little bit less "solid", but it also gives it a "space-y" feeling, almost as if the sound went through some sort of reverberator.


(14 replies, posted in Sinclair)

Thank you very much!


(14 replies, posted in Sinclair)

My original design was much darker (a bit like early skrju demos, I suppose). So dark in fact I did not want to make it. sq^skrju came up with an alternative "story" which made it lighter and, ultimately, better in my opinion.

Otherwise, yes, it is mostly my design.


(135 replies, posted in Sinclair)

Nope, one beeper demo per year is enough, thank you very much smile


(14 replies, posted in Sinclair)

We did hire half the skrju to work for us, to be fair! smile