476

(2 replies, posted in Sinclair)

Ok, here's one for the lulz.

nanobeep2 is a tiny sound engine for the ZX Spectrum beeper. Unlike the original
nanobeep, the design goal was not to make the player as small as possible, but
to cram in as much features as possible in less than 100 bytes. 

In it's most basic form, the player takes up 64 bytes of memory. A range of 
additional features can be activated via assembler switches, increasing the size
of the player up to a maximum of 99 bytes.

Core (minimal) player features:

- 2 square wave channels
- global 8-bit tempo resolution
- 8-bit note dividers (~4 octaves, lowest notes may be detuned)
- limited keyboard checking (checks only Space, A, L, Q)

Additional features:

- border masking
- full keyboard checking
- PWM sweep sound
- click drum
- per-pattern tempo setting
- increased note range (6 octaves)

No XM converter, it's just a proof-of-concept at the moment.

source
download

Lame 380 byte demo tune is attached.

477

(22 replies, posted in Sinclair)

If I'm not mistaken, it's basically a matter of resetting prm and Kp to their default values. Looks like it's 256 for prm, and 64 for Kp.
Seems like the doc is wrong, too - Kp should be in bit 8..13, obviously. My bad wink

478

(164 replies, posted in Sinclair)

In theory, what would be the options for play position tracking (aside from approximation via playtime, which is not viable I think)? Is there a possible to have GME do a callback at given breakpoints?

479

(37 replies, posted in Other Platforms)

Well, let's just say everybody has their own goals and methods, alright? For my part, I'm quite interested to hear about yours, chupo_cro (even though I'm personally more interested in coding AVR asm than C). Either way, probably best to continue this discussion in a new thread.

chupo_cro wrote:

Something that might be interesting - my song data format is not tracker-like (patterns of tones/commands) but is rather an array of tone[|CMD], duration[,command][, parameter] per channel (array of uint8_t) so it is quite easy to enter the song by looking at the musical scores and typing the data. Some commands can be specified just by OR-ing the tone with the command and some need to be specified by using CMD flag and the additional byte as command specifier and maybe one more byte as a parameter. The durations are specified as t1 (a whole note), t2 (a half note), t4 (a quarter note), t8, t16 or as the combination - for example t4+t8 is a quarter note with the dot.

Now, while I see your reasoning behind it, I think this approach has some drawbacks. The main issue is that you will find few people who are willing to write music for your engine in a text-based format. While music markup languages have some fans (even around here wink), the vast majority of users prefer trackers nowadays. And this kind of sheet-music oriented format does not lend itself well to a tracker implementation, since trackers don't care about note lengths. It might be worth considering to "inverse" the length format, so that t1 would be the smallest unit (ie. semi-quaver). This way, it'd be still relatively convenient for transcribing sheet music, while at the same time making tracker support a little easier. The other thing you have to worry about is row transition length. The more complex the data format, the more time you need to decode it - time that you can't spend on synthesis. It's normally not such a big issue with PFM-based synthesis, but once you get into pulse-interleaving/volume faking, you will notice a significant impact on the sound quality. Of course, with something like 10 channels, you have to start worrying about data size as well (so it would make sense to have patterns per channel instead of one pattern for all channels). But for 2 channels, I find split patterns aren't worth it in most cases.

480

(37 replies, posted in Other Platforms)

Now that's what I call an introductory post wink Welcome to the 1-bit forum, and thanks for all the info.

chupo_cro wrote:

And one more thing, I did a 2 channel 1-bit sound routine (using PWM and waveform tables) with portamento and decay envelope which runs on ATmega 8 with 8 MHz internal oscillator and the results are quite good, some of the sounds could be compared with low end keyboards.

Sound example or it didn't happen xD

481

(164 replies, posted in Sinclair)

Agreed, it's probably easier to make a new one from scratch.

Shiru wrote:

We can have fun and do an AY-3-8910 alternative, too. People were asking if it possible to do something like that for years.

Hmm, shouldn't be that difficult to implement on any soundchip, easier than sample/MOD playback imo. I wonder why nobody has done it yet. Seems like Atari SoftSynth is indeed the only program like this on 8-bit machines, and it's from f*cking 1985. The only other one I know is AHX, and that was on Amiga of course. Also Dragon 32 and maybe Thomson TO had something like it on the 6-bit DAC, though far less advanced.

482

(164 replies, posted in Sinclair)

You know what I'd really love to see in 1tracker? The Atari 8-bit SoftSynth engine. Though that's most likely a ton of work - I don't think it has ever been reverse-engineered.

Hey gang!

A bunch of friends and me are running a little TI calculator graphics
competition. And of course, you're all invited to participate!


THE TASK

Draw a picture in the standard graphics format of monochrome, Z80-based TI graphing calculators (TI-82, TI-83, TI-83 Plus, TI-84 Plus, and compatible models)!

DEADLINE

Sunday, August 20th, 2017 23:59 GMT


RESTRICTIONS

Works should be original - converted images (found on the internet or elsewhere) are taboo.


VOTING

A jury will pick the winners until September 3rd.


PRIZES

Nothing, just ethernal fame wink Aside from that, the first 3 places will receive a printed diploma by mail.


SUBMITTING

Send your works to 1bitforum at posteo dot net until August 20th. Please include the following information:

- name of your work
- artist name
- your real name and address, in case you wish to receive your diploma by mail

Works should be submitted as 96x64 pixel, 2-color (black/white) .bmp. Entries will be converted to TI format by the compo organizers.

There is a maximum of two works per author. In case of a high number of entries, there will be a pre-selection by the compo organizers.

A few weeks ago, we received official blessing from Lyndon Sharp to use his beeper routine, so the long-standing legal questions surrounding this unique engine have finally been answered.

For this occasion, Shiru proposed that we get together for a little tribute compilation. The release will be a .tap image for the ZX Spectrum (+ possible mp3 release, if I get bored enough).

Of course you're all invited to join! All you have to do is compose an LSengine track, either with 1tracker or with the XM converter. Send your works (preferably as .asm, .1tm or .xm is also ok) to 1bitforum at posteo dot net before August 13th, 2017.

In the unlikely case of a large number of submissions, we may have to do a pre-selection, since there's only so much you can cram into 48K of RAM.

485

(3 replies, posted in Sinclair)

Cheers guys wink It's probably not the most useful engine, more a tech-demo, really. The vibrato technique is certainly not ideal, need to explore further. Well, it's a start, at least.

486

(164 replies, posted in Sinclair)

Excellent, thanks a lot! Good idea about caching the engine info, it was indeed getting super slow (several seconds on my T60, in fact).

487

(3 replies, posted in Sinclair)

Special offer... Vibratos, everyone, fresh vibratos... Now two channels with vibrato for the price of one!

Vibra is a ZX Spectrum beeper music engine with two tone channels and a 
dedicated noise channel. The tone channels support customizable vibrato and
slide effects. The vibrato effect has 7 speed settings, and 255 depth levels. 
Effective vibrato speed depends on the note frequency used. Tone channels are 
unbalanced, that means the second channel will play at approx. 80% volume of the
first channel.

The noise channel supports 255 pitch levels, and 127 volume levels. Noise 
generator is only updated if there is enough free CPU time, so data reads etc.
may affect the noise timbre.

The usual interrupting click drums are absent from this engine, as the available
effects should be sufficient to create drum sounds.

The engine reloads song data on the fly during playback, thus mitigating the
common problem of row transition noises for the most part.

Technical details:

- 12-bit note frequency dividers
- 8-bit noise pitch dividers
- 7-bit noise volume
- 3-bit vibrato speed (relative to note frequency)
- 8-bit vibrato depth
- 8-bit slide speed
- mixing at 7812.5 Hz

download
source (with more detailed comments this time)

No XM converter, sorry. I'll see about getting support for this into MDAL, but I'll probably need to make some adjustments first.

Anyway, aside from the vibrato technique (which is exactly as explained here, the most interesting part might be the use of two (fake) threads, based on Alone Coder's counter-skipping trick. The first updates the channel counters like usual, but also generates "tasks" depending on the state of the counters etc. Tasks are pushed to the stack (if nothing else needs to be done, an "idle" task is pushed). The second thread is switched to with a RET, so it'll execute whatever task is on top of the stack. This can be updating the vibrato/slides, updating the timer, or loading new data. If a given task cannot be completed within the available time frame, another task will be issued (eg. data loading can take up to 6 tasks depending on the situation).

The pitchable noise generator is based on Shiru's noise code, using my el-cheapo, HL-only XOR shift however. Noise quality is a bit weak due to the low mixing rate. There are also some other limitations, namely 1) invalid data can crash the engine and 2) vibratos may cause detune in some (rare) circumstances. Also, a general problem is that the vibrato speed is tied to the note frequency; this makes it impossible to have consistent vibratos across the note range.

Either way, this engine was a major pain in the a*** to write. Been busy with it for almost a whole week, and there's probably still a bug or two in there. Enjoy big_smile

Shiru wrote:

For oldest PCs that runs pure DOS, like XT/AT/386 maybe, the usual timed code approach may be viable, with a delay in the main loop that automatically gets adjusted at startup by measuring actual CPU speed.

There's a hacked(?) version of Music Construction Set that does exactly that. I can probably find it somewhere in my collection if you want to reverse-engineer that.

There's also 8088 MPH of course, had some great multi-channel msx in the last section. There's a detailed write-up on the engine tech, which includes a link to the source code of said engine.

Also, luckily archive.org has a copy of my lost pc speaker article. It's quite outdated now, but still there's a few items that are missing in your list wink

489

(7 replies, posted in Other Platforms)

Thanks Shiru, that'll come in handy some time.

490

(43 replies, posted in Atari)

Ha, I wish! I know only a few basic phrases in Polish, this one is courtesy of my friend Google Translate big_smile

491

(43 replies, posted in Atari)

Sillyventure 2k17 will have a GTIA compo again. Deadline is December 1st, and the usual rules apply.

I for one think it would be nice to have an original GTIA engine for this, not just the usual ports from Spectrum. XXL, czy możesz napisać nowy (oryginalny) engine dla GTIA?

492

(7 replies, posted in Other Platforms)

Radio-86RK does indeed sound scary.
Another thing that used to give me a good headache are those devices that output a fixed (preferably high-pitched) frequency (Channel F, or the Sharp Pocket thingies, for example). Thankfully, Zilog's squeeker algo is great at overriding those. Might be also a good candidate for Radio-86RK, since it doesn't seem to require exact timing.

I actually did write a sound routine for the VIC20 once. Couldn't find anything on how to create a 16-bit pointer, so I wrote some really ugly self-modifying code... then later, I looked it up and realized that I'd written it exactly like it's supposed to be done. I have to admit that kind of shaped my experience with MOS products big_smile Aside from VIC20, one machine I really want to tackle though is the Atari VCS, so I guess I'll have to wrap my head around 6502 (or 6507, in this case) at some point.

493

(135 replies, posted in Sinclair)

Damn, seems it's the week of failed experiments for me. In the last days, I tried to implement a very ambitious concept, basically an improved, multi-threaded Squeeker type engine that will calculate optimal wavelength ahead of time, so it's possible to mix two waves with 50% duty with just one output. After trying for 3 days to get it stable, I finally got fed up and put it aside.
So then today I tried to mix 15 square wave channels. Works, but it's... not great. Hear for yourselves.

Love the demo tune!

495

(7 replies, posted in Other Platforms)

From our forum member krüe: http://krue.net/stitch/ wink
Seriously, I think the Apple II has one of the worst 1-bit setups. Not being able to "set" the 1-bit state directly is a major hassle.
... hmm, one day when I have too much free time I might learn 65xx asm big_smile

Hah, that's a great idea!

497

(20 replies, posted in Sinclair)

PhaserX source
Proper editor is not public yet, for now there is support via MDAL reference compiler: https://github.com/utz82/MDAL

498

(20 replies, posted in Sinclair)

Results are in: http://events.retroscene.org/dh2017/ZX_Beeper_Music

Pity about temporal sad

499

(20 replies, posted in Sinclair)

Entries are online: http://events.retroscene.org/dh2017/ZX_Beeper_Music

500

(135 replies, posted in Sinclair)

Been thinking about the Earth Shaker method again. As far as I understand, it can essentially be implemented like this:

    di
    ld sp,#292        ;freq divider ch1
    ld bc,#1b7        ;freq divider ch2
;    ld hl,0            ;accu ch1
;    ld de,0            ;comparator/accu ch2

loop
    add hl,sp    ;11
    ex de,hl     ;4
    add hl,bc    ;11
    ex de,hl     ;4
    ld a,l       ;4    ;cp hl,de
    add a,e      ;4
    ld a,h       ;4
    adc a,d      ;4
    sbc a,a      ;4
    out (#fe),a  ;11
    ld a,0       ;7    ;timing
    jr loop      ;12
                 ;80

What I don't understand is how to reliably control the pitch. Usual note dividers often don't seem to work as intended. Is this just a limitation of the algorithm, or is do the dividers need to be adjusted depending on the desired harmonic relation?

Btw using the same divider for both channels with a slight offset gives a sweet phasing effect that I haven't come across earlier, see attachment.

Edit Also tried it with short (12-bit) counters. Turned out pretty lame (no nice detune fx possible either), and the time savings are minimal, just 8t. So it's not worth continuing in that direction, I think.