Search options (Page 11 of 21)

I'm doing a really niche stuff that is barely getting any feedback, and it is a truly demotivating thing. Moving to a niche platform with much lesser user base, especially of the target audience (music producers), that is also happens to have no money to offer (zero job offers for desktop *nix in two decades for me), is a sure way to kill any and all remaining desire to do anything at all. x64 support is just a necessary evil to keep it up now, and it is relatively easy to do.

A true story: in 2002 or so I had to break any interaction with a friend, because he moved to Linux completely (he's a web designer, so GIMP and a text editor was all he needed) and developed a habit of calling me even so often and spend long hours simply repeatedly telling me that I should drop Windows ASAP, and start to program for Linux, because Linux is the new greatest thing in universe and Windows is shit and going to die out soon anyway. This kind of advertising worked very well in alienating me from this stuff up to this day.

No, if I had something, I sure would publish it already. At the moment, the only game I can think of that kind of used this approach was Sea Dragon port, where I did beeper effects. It used very crude sample-like effects, like every so often during rendering a frame the game just read a bit from an array and outputted it. As it was 50 hz targeted, rendering speed was relatively steady, thus 'sample rate' was steady enough too. I don't have this code around, and can't really recall how many times per frame the routine was called. I think it was the least possible number, to avoid introducing slowdowns. Maybe 8-16 updates per frame.

It is possible to modify, but this sound effect approach specifically designed to be called repeatedly each interrupt or each game loop - to play sounds alongside the gameplay, in trade for (relatively) poor sound quality.

A shameless plug, you can use my BeepFX routines that is capable to much more sophisticated effects, but stop action while they're playing. As far as I know, it was hooked up to z88dk already: https://github.com/z88dk/z88dk/wiki/beepfx

Thanks for report. Will take a look and figure it out whenever I'll get time to do another chunk of updates.

Reaper PCSPE export works like a log recorder. You start export, start playing music like usual, plugin catches in realtime all it receives from MIDI tracks and writes down all the data that it produces and that goes into emulated PC Speaker registers. That's the same way some YM2612 plugins work. Once you got BIN or other file format, you can make a simple player program that will just send the pre-recorded data to actual PC Speaker port. There is an example of QBasic program alongside PCSPE that does just that. If anyone needs, I sure can provide help with implementing player in other language or for other needs.

As far as I remember, SDCC assembler simply does not allow 'current address', because it gets calculated at linking time only. So the second approach should help, i.e. ld (var+1),sp.

1tracker follows pattern-less design. It is possible to add patterns support into engine, not too difficult, but you would have to prepare data manually somehow, as 1tracker won't split it into patterns automatically (engine script can do this potentially, but that's not an easy way).

You don't need to edit assembly code in order to use loop (if it is supported by an engine). Use Ctrl+Home to mark loop start, Ctrl+End to mark loop end.

This piece of code

begin:
    ld hl,music_data
    rlca
    add a,b   
    call play
    ret

is totally not correct, the other one is. Probably some bug, the engine is very fresh and wasn't tested much, if at all.

Thank you, guys.

Should note that this was a side step related to the original intents. I did not use any software 1-bit synthesis in this demo, it is just the plain single channel 8253 music (very much like classic PC Speaker), created with PCSPE. Truly 1-bit and truly monophonic, though.

Still going to do a music sequencing, or a performing software perhaps, using this platform, with a custom 1-bit engine.

Also thinking on creating a cut down replica version of the schematics, omiting all phone line related stuff, and a PCB layout, so more people can get the thing without relying on buying old hardware overseas. The device is quite easy to assemble, and does not need rare parts (the obscure single piece LED display obviously has to be replaced with some modern ones).

Another fun fact gained by the means of digital archeology. I was messing up with the firmwares that featured the sampled speech stuff, attempting to make a sample decoder. They use different formats, I did only one (4-bit samples at 5000 Hz), other ones is well distorted, but recognizeable. I learned that there was the first version to feature voice, it had male voice that only spelled a few numbers and short messages, then there was the second one (Selena), it had best quality female voice. Latter has been ripped, downgraded, and reused all across other firmwares. Derivative versions has varying sample set, some say tens and hundreds, and extra messages, some not.

The fun fact is that one of the firmwares, the only one (of those I checked so far, at least) that features good quality female voice, also has an angry male voice clip in the middle of the data: FUCK OFF! (in Russian)

That made me remember that an urban legend circulated at the time, that if you enter some secret code, you can blacklist a number with such a message played to the caller. Turns out it wasn't really a legend.

At this moment I'm on the 'make it work' part, before 'make it pretty'. I need to figure out lots of details to create faithful emulation that is useful for new developments. VCL just helps me to speed this process up, as I know VCL very well, while I don't know anything about CLX (yet). Sure, eventually I'll put some time to make it more accessible and useful.