451

(51 replies, posted in Sinclair)

Wow. I mean 4.8 isn't exactly fresh, but one would expect that they'd be done implementing the C++11 standard at that point.
Ok, if it's just sound_emul.cpp:85 giving you trouble, you can replace that line with

audioBuffer.str("");

452

(51 replies, posted in Sinclair)

garvalf: That's very odd, can't wrap my head around it. I just pushed some changes though, could you try to 'git clone https://github.com/utz82/bintracker.git' and compile that again? Btw -no-pie is only needed on new GCC, to force it to produce actual executables.

Shiru: Ok, tried some things. Could you check if this version still creates a zombie on your machine: https://irrlichtproject.de/transfer/bin … .1.0.1.exe

453

(51 replies, posted in Sinclair)

That's an odd one. I assume that on your system, bintracker.exe fails to be registered as non-console app. Which Windows are you on? Does the error also occur when you start bintracker via console?

Edit: nevermind, I've been able to reproduce the issue. Though I have no clue how to fix it atm...

There's also an issue with the exit confirmation on unsaved changes, message box will show a single "OK" button instead of the 3 custom ones it should show. This is a problem with the gfx lib, working on a work-around atm.

454

(51 replies, posted in Sinclair)

So the time has come to drop this, I guess...

bintracker is here. It's a new beeper music editor (and in the future, possibly more than just beeper), inspired heavily by both 1tracker and Beepola. At this point, it supports betaphase, PhaserX, PhaseSqueek, and Pytha. Bintracker runs on Windows and Linux. It should be possible to build it on MacOS, but I haven't tested that.

DOWNLOAD (source + win32 .exe)

Bintracker runs libmdal as a backend, so in theory it can support any engine that is supported by MDAL. However, at the moment, bintracker only implements ZX Spectrum 48K support. Also, MDAL/libmdal is still in it's infancy, and will have to undergo some major changes before moving forward.

Bintracker is currently in a very early beta stage, so bugs will be a common occurance. Please report them here, or (preferably) hrough the github issue tracker.

Currently known issues:
- Sound emulation is not very accurate (in fact, emulator will have to be rewritten completely)
- Display may glitch after loading a tune or starting a new one (need help finding out why and when exactly this happens)
- Keyhandler may occasionally destabilize and register accidental keypresses (again, any help on this is appreciated)


Massive thanks go out to Shiru, who got me started by tossing around the idea of having "some sort of an MML compiler for beeper". Also, bintracker would never have been possible without the amazing 1tracker, which will, without a doubt, remain my favourite tracker.

Another big thanks goes to Chris Cowley for all the work he's done to almost single-handedly kicked beeper music into the 21st century with Beepola.

And of course, big thanks to all beeper fans, 1-bit musicians, and especially beeper engine authors!

Update 17/09/21 - v0.1.1 released

455

(7 replies, posted in Sinclair)

Sure, no prob about the instagram thingy. Hope to do some more works with this engine as well because it rocks!

Shiru, one feature request, would it be possible to automatically detect&cut silence at the end of samples for the 1tracker import?

456

(7 replies, posted in Sinclair)

Sorry, I'm keeping that under wraps till my new Spectrum album comes out (probably in Spring 2018 as things stand now). I'll send you the .tap, though, if you like wink

Holy moly, what a massive Frankenstein of a board! So finally it's all coming together, eh? Congratulations mate, this is a great achievement. And I guess it was quite some work despite you claiming to "just reuse code and parts from other projects" big_smile

458

(22 replies, posted in Sinclair)

That's a lovely tune, Garvalf!

459

(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.

460

(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

461

(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?

462

(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.

463

(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

464

(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.

465

(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.

468

(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.

469

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

470

(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

472

(7 replies, posted in Other Platforms)

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

473

(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

474

(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?

475

(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.