Excellent write-up. Glad to see it is generating quite some attention, too.


(84 replies, posted in Sinclair)

I finally found a way of consistently reproducing the "Engine not provide any data" bug that I mentioned above.

To reproduce:

1) load the attached .1tm
2) F5 to play, F5 to stop again
3) Move cursor to last column, press 1

I don't know if it is reproducible under Windows, if not then probably some memory is not being initialized to 0.

Some more info: Bug happens regardless of the engine used. As mentioned, it almost always happens when trying to enter something at the beginning of a block. Once it occurs, it is persistent, ie no data that would trigger a row play can be entered at this position anymore regardless of any further actions taken.

Waaaaaah! It may be just a day old, but to me it's already legendary. I would never have believed that it's possible to push monophonic stuff this far.
Also, there goes my hard earned paypal money. Damn you.

Glad to hear that. Could you tell me what exactly you had to do to get it working in the end? Generally TiLP+Win10 seems to be rather wonkey, so it might be a good idea to document user's findings in the manual.

Just hard-set everything in the "Change Device" dialogue. So cable = SilverLink, port is #1 (usually), calc is TI-82, of course. I think TiLP doesn't auto-detect the 82. Or do everything via command line
tilp ti82 SilverLink CRASH.82B
which usually gives more useful error messages anyway.

You need to force USB driver installation with Zadig. See the TiLP Windows readme for details. If that doesn't work, then yeah maybe it's easier to use that Linux netbook. Anyway, let me know if you have any success with the Zadig thing, so I can perhaps add a note to the HT manual about this.

Hi, I need some more info. Which transferrer software are you using and what OS are you on?
Also, plug a sound cable into your calc and confirm that you are getting a low humming noise on both stereo channels.


(87 replies, posted in Sinclair)

Some Thoughts on Note Data Encoding

On ZX beeper, note data is commonly encoded based on one of the following principles:

  1. 8-bit frequency dividers or countdown values, stored directly.

  2. 8-bit indices into a lookup table holding 16-bit frequency dividers.

  3. 16-bit frequency dividers, stored directly.

  4. 12-bit frequency dividers, stored directly (as 16-bits).

Method A is efficient in terms of data size, but has well-known limitations of note range and detune. Method B is also size-efficient, but table lookup is inevitably slow, which is a problem for pulse-interleaving engines because of row transition noise. Also it requires an additional register for parsing. Method C is size-inefficient, but allows for fast and efficient parsing. Method D has similar constraints as method C, but is slightly more size-efficient as additional information can be stored in the upper 4 bits.

I have been using method D in several of my later engines, and generally regard it as a good compromise except of course in cases where higher precision is needed. However, the question is if there is a better solution.

First of all, it is safe to say that the most significant bit of a 12/16-bit dividers is hardly significant at all. The relevant notes are in a range that not only isn't very useful musically, but also cannot reproduced accurately by most existing beeper engines.

More importantly though, it should be noted that for higher notes, precision actually becomes less important for a number of reasons. One of which is psychoacoustics: humans are naturally bad at distinguishing high frequencies. The key reason is of a more technical nature, though. Imagine we have determined the frequency divider of an arbitrarily chosen reference note A-9 to be 0x7a23. That means the divider for A-8 is 0x3d11, A-7 gives 0x1e88, and so forth, until we arrive at a divider value of 0x7a for A-1. And here comes the funny part. We know that of course for each octave, frequencies will double. So if A-1 is 0x7a, then A-2 is 0xf4, A-3 is 0x1e8... A-9 is 0x7a00. Wait, what? Didn't we just determine that A-9 is 0x7a23? Well, depends on how you look at it. Musically speaking, 0x7a23 may be the correct value when thinking about a system where A-4 = 440 Hz. However, in our magic little beeper world, 0x7a00 is just as correct, as it perfectly satisfies the requirement that frequencies should double with each octave. Hence we can conclude that for A-9, we actually don't need the precision of the lower 8 bits, so we could just store the higher 8 bits and ignore the lower byte altogether. However, for A-1, we very much do need those lower bits. So the point is that either way, 8 bits of precision (or even 7 bits, as demonstrated in the above example) is sufficient for encoding a large range of note frequencies. We just need to be flexible in what these 8 bits represent. Sounds like a use case for a floating point format to you? Well, it sure does to me.

However, the problem is that decoding a real floating point format would be even slower than doing a table lookup. So that's no good. Instead I propose we cheat a little (like so often in 1-bit). We need something that uses 8 bits, is fast to decode, but still gives us some floating point like behaviour. Considering an engine using 12-bit dividers, I propose the following 8-bit note data format:

Bit 7 is the "exponent". If it is reset, then remaining bits are assumed to represent bits 1..7 of the actual 12-bit divider, all other bits being 0. If the "exponent" is set, then the remaining bits are assumed to represent bit 3..9 of the actual divider. As discussed, we don't actually care about the highest bit of the divider, and for practical reasons we will ignore the second most significant bit as well. The choice of what bit 7 represents is of course arbitrary, if it suits your implementation better then there are no drawbacks to inverting the meaning whatsoever.

Now, the nice thing is that we do not need to fully decode our "el cheapo" floating point format during parsing, as it costs just 8 cycles to decode it just-in-time. What's even better though, doing so saves a precious register!

        ld a,b
        add a,c
        ld b,a
        sbc a,a
        add a,d             ;self-mod: add a,d | xor a,d
        ld d,a
        out (#fe),a

Where B is our accumulator, C is our note value that has previously been left-shifted if it signifies bit 1..7, or has bit 7 masked otherwise, and D is the "extended accumulator" that will be used either to accumulate the overflow from the 8-bit add (if note value signifies bit 1..7 of the divider), or will serve as extended bit (if the note value signifies bit 3..9).

Attached to this post, you will find the full source code, an example note table, and a demo. At this point, there are 3 major issues that need to be addressed.

  1. Middle E is detuned. This can probably be rectified by shifting the note table a little, though this method is bound to produce some slight detune around where the "upper" table section starts.

  2. Parsing is quite ugly atm. I'm sure it can be made more efficient, but haven't found a good method yet.

  3. The current way of calculating the output state gets into the way of applying other effects. I believe basic duty control should be possible (via the "phase offset" method), but other things like duty sweeps might be more difficult. My hope here is that instead this opens up the possibility for other tricks that I might not have thought about yet.

Well, that's basically all I wanted to share for now. It's probably possible to do something similar for 16-bit dividers, but most likely it won't work just-in-time. Other than that, I'm very curious to hear your thoughts on this. Is it useful at all? Any cool tricks that we can do with this? Any improvements for the implementation? Please let me know.

Yep, good stuff! The "graphical sound" technique was actually pretty widespread back in the day.
Here's another example from SU: https://www.youtube.com/watch?v=Z7Zb4rso82M
Another famous name is Norman McLaren.
Also, Daphne Oram: https://en.wikipedia.org/wiki/Oramics
Also the Solaris soundtrack was made using a similar technique.


(0 replies, posted in Sinclair)

As of today, individual downloads for my Speccy engines are no longer available from the github repo. You can now grab all the converters etc. as a single download on the Releases page.

The reason for this change is that I intend to use the github repo as a submodule for MDAL/Bintracker at some point, and having a large number of binary files in the repo is somewhat counter-productive in that respect. My apologies for any inconvenience caused.


(76 replies, posted in Sinclair)

Yeah, 2 downvotes already! I'm famous woohooo big_smile


(76 replies, posted in Sinclair)

Thanks, Shiru. I'm not terribly proud of this one, actually. Except for the ghost notes in the section starting at 0:45, really like how those turned out. Think your track is great, too, classic Shiru style. Wanted to send another track, but same problem: not enough time to finish it.

Of course I've already told you a few times that this is a fantastic album but... Awesome album is awesome. It not only shows how far we've come in terms of beeper sound, but even more importantly it shows how far you've come as a composer since (the already outstanding) 1-bit Mechanistic. Well done, mate.


(3 replies, posted in Sinclair)

Thanks you guys! After playing with this engine some more I think it needs more polish, but I'm still glad it works at all. And yes, it's surprisingly cheap even with realtime low pass, but of course banked buffers open up even more possibilities, like emulating attack transient variations (StringKS can do it but there are no built-in buffers for it so they currently need to be prepared by the user). I'm also wondering if this could be a candidate for Jan Deak style "ahead-of-time" buffer generation. In general I have a strong feeling that his method might be useful for something other than just generating loads of pulse trains, but still searching...


(87 replies, posted in Sinclair)

Seems that biggest mistake in many of my newer engines is not to mask bit 3. Worked wonders for the KS thing in any case.

I tried some simple 1-bit mixing on Gameboy a while back, so I can confirm it generally works. On the other hand I currently don't have a machine with AY so I have less of a motivation to try it. Maybe when I get my Next hur hur... Tried to make a combined AY+Beeper engine but it turns out that volume difference is huge and also varies alot between models, so I haven't investigated further into this direction either.

Currently I'm looking a lot into data encoding. I have a sort of el cheapo floating point format now which allows me to encode 12-bit frequency dividers in 8 bits. Costs 8 additional cycles in sound loop, but saves a register. Something similar should be doable for 16-bit dividers. Also I'm experimenting with a new song data format that isn't based on pattern/sequence structure but rather on dictionary based approach. Parsing such data has a small overhead compared to seq/ptn data (needs an additional register pair for decoding and is slightly slower than just popping values from stack), but first tests are promising: on average 10-30% smaller data than the traditional approach. However, I need to test it with more data to be sure. Thinking about grabbing a large set of files from modarchive and build test material from that. Anyway, will of course post more on that once it's progressed a bit further.


(76 replies, posted in Sinclair)

Yes! Thanks for the reminder, Vinnny. I'll try to make something but can't promise.


(3 replies, posted in Sinclair)

Wow, appearantly it's been almost a year since I published a new beeper engine. So it was about time for some good ol' t-state squeezing.

StringKS is an experimental engine that implements Karplus-Strong inspired string synthesis. It's more a proof-of-concept than an actually useful engine (hence no converter is provided), however it does prove that physical modelling is possible in 1-bit, and I think it's worth exploring this concept further.

Synthesis is done by creating an initial ring buffer from various sources (at the moment, ROM noise, rectangle wave with variable duty, and saw wave are supported), and then continually running a simple low-pass filter over the buffer. The size of the buffer determines the pitch. It is also possible to source from user-created data (so theoretically one can start from a pre-filtered buffer to create softer attack transients). Additionally, I threw in PWM sample playback on one of the channels, and regular rectangle wave playback (also on one channel only). There's also a (rather brutal) overdrive mode. All synth methods except the saw wave one support a somewhat crude 3-bit volume control.

source code
An extremely uninspired demo tune is attached.

- 8-bit frequency counters only, so the available note range is rather limited.
- At higher notes, tones will fade out very quickly.

I believe it's possible to rectify these issues, but more research is needed. One possible approach I experimented with was to generate data on the fly with the usual add-and-compare method while keeping track of the low-pass cutoff. It works but so far sound quality is worse than with the buffered approach. Another way might be to pre-scale the speed of buffer iteration to reach lower frequencies (e.g. update buffer pointer only every other sound loop iteration), and to slow down decay by only running the filter on every other buffer iteration. Still need to find some free t-states for that, though. Perhaps splitting updates so only one channel gets updated per sound loop iteration might be doable. Well, I'm open to ideas, of course wink

Thumbs up wink
A small note about Huby, using Beepola/1tracker is strictly optional for transcriptions. You can also generate music data directly from the imported MIDI data in OpenMPT by using the Huby XM converter. However, the best option is always to ask a chiptune musician to do a cover for you, rather than converting from MIDI data wink

Thx wink Yes, sound and video examples were not recorded for copyright reasons, but you can find all the examples over at the 1-bit timeline post (which I've been updating quite a bit lately).


(1 replies, posted in Sinclair)

Ha, neat!

I think anteater has some flaws (namely incorrect tuning due to insufficient frequency divider size). On the other hand, looking back it was probably not that bad for a first (well, probably second or third) attempt big_smile


(9 replies, posted in Sinclair)

As much as I'd advocate trying some of the newer beeper engines, the most convenient for you would be to use Tritone, as it's natively supported in z88dk.

Also, don't worry too much about size. Once you use compression (and only unpack into a buffer when you need it), data size doesn't really matter that much. I think z88dk has zx7 compressor build in, which works fairly well on music data.

I don't know what would be the equivalent in SDCC syntax, might be as simple as

oldSP = $+1

Generally, what this pseudo-op construct means is: "assign a label (oldSP) to the current address ($) + 1". So in this example, oldSP will point to the address immediately after the "ld sp,nnnn" instruction, which happens to be the "nnnn" part. There is some other part in the code (usually in the init part) that writes the value of SP at that point in time to the location of oldSP. The snippet "ld sp,old_value" is then usually called on exit, to restore SP to it's proper value, as many beeper engines mess with the stack a lot.

Anyway, the point is that if you don't have any form of "label equ $+x" available, you can also simply locate all points in the code that write to 'label' (in case of the SP backup there'll usually just be one such location). That write op will look something like

  ld (oldSP),sp

which you can change to

  ld (oldSP + 1),sp

and then change the "oldSP equ $+1" to simply "oldSP".

Did a talk about music on mainframes 1949-1965 at the Vintage Computing Festival Berlin last weekend. Nothing new if you've been keeping an eye on the 1-bit timeline post, but anyway, here you go:

https://media.ccc.de/v/vcfb18_-_90_-_en … ames_-_utz


(9 replies, posted in Sinclair)

Your music_data should simply contain the pattern pointers, the extra "patterndata" structure is not needed. So

   defw pattern1
   defw pattern2
   defw 0

The 0-word at the end of the music_data block marks the end of that block, in the same way that the 0-byte at the end of a pattern marks the pattern end.

However, I don't know if Ear Shaver supports this kind of sequence/pattern structure out of the box, perhaps some adjustments to the data loader are needed.

Yep, use synth drums instead of the digi ones, and you should be fine.
Also, song data generally compresses well with zx7, apack, exomizer etc.