Search options (Page 16 of 40)

Wow, excellent song! Not much of a Musical guy myself, but that's certainly some very solid work.

Very curious about that demo. Let us know if you need help with anything.

As far as beeper/tape-out is concerned, I've heard a lot of good things about the +3, though I don't own one so I have to take other people's words for it. Only ever used the rubber 48K myself, works just fine Wouldn't go for a 128K unless I wanted to use AY. 128K has different contention timings which may have some newer beeper engines end up sounding less clean than they should. +3 doesn't have this problem because there's no I/O contention on that machine.

Plogue has support for P824x sound, but it only supports the default stuff. And of course Plogue is closed source so it's not that useful. David was kind enough to publish some info, though: https://ploguechipsounds.blogspot.nl/20 … p824x.html
Think I have to pass on this one for the time being, even though I'd be very interested to code on the 8048. But I've got too many hobbies already at the moment

Well, we did have ED in 1tracker at some point, made by krüe: http://krue.net/1tracker/
However he said the plugin doesn't work in recent 1tracker versions anymore.

Regarding sound emulation, one thing I've been considering is generic emulation by recreating the engine algorithms in C/C++. Abandoned the idea because it obviously inefficient and involves copious amounts of work, but taking into account also the recent discussion about handhelds/watches etc, it might actually be the most sensible route.

Regarding the "missing roots", there may or may not be a direct link. Only Mark Alexander would know, obviously. The history of 1-bit music as we know it now is full of interesting links (for example I'm pretty sure there's some continuity from Whirlwind I -> IBM AN/FSQ-7 -> TX-0), however there has been an equal amount of "re-inventing the wheel".

Regarding low clock speed, I think part of the secret may be overtones. A piezo will cut the low range anyway, so you can generate tones at the very low end of the audible spectrum, and the piezo will "magically" transpose up. Afaik some of the LCD games also had hardware PWM to handle sound.

In any case, I agree, it's a very interesting field.

Uh wrong thread I guess but yeah, consider me interested. Got any links?
Btw if you wanted to post your stuff on here I could make a sub-board for it. As you can tell this place isn't all that active but maybe that'd attract some others as well...

Don't know of anything ready-made as such, but a Squeeker type generator would be trivial to implement. What language is your game written in? Simple (if slightly unsafe) C++ example:

uint16_t suma = 0;
uint16_t fdiva = 0;
uint16_t sumb = 0;
uint16_t fdivb = 0;

int16_t generate_pcm_sample() {
    suma += fdiva;
    sumb += fdivb;
    return ((suma | sumb) < 0x2000) ? 0x7000 : 0;
}

You'd just call this repeatedly to fill your sound buffer.

On the other hand, why not simply use some ZX Spectrum music? With an engine like Huby, you'd get some pretty authentic sound.
Example: https://irrlichtproject.bandcamp.com/tr … ny-fingers
I'd even make a track for you, though we'd need to talk about the budget in case you're planning for a commercial or ad-supported release.

Or you could use Shiru's PCSPE VSTi and whip up something in FL or Ableton.

Hi there!

Well, in order to be totally authentic, you'd need to implement an SM-510 emulator, and write your own player. In that case you're looking at quite a bit of work, obviously. It's not impossible, though MAME has some SM-510 emulation code, and it's even BSD licensed, yay!
https://github.com/mamedev/mame/blob/ma … 10/sm510.h
And there is an SM-5 series assembler, written in Java:
https://web.archive.org/web/20160112051 … arpasm.zip
as well as an emulator, from the same guy, though I'm not sure how useful it is or if it even does sound:
https://web.archive.org/web/20160112051 … tchman.zip

The problem is that the SM-510 is slow af, so you're not going to get really advanced stuff out of it. However if I understand correctly it actually has 4 bit output so maybe that's enough to mix two voices.

I have yet to find a full instruction set of that thing, though. However, appearantly it's similar to the TMS-1100... hmmm... also no idea what this "melody module" thing is all about.

The other, slightly less authentic route would be to implement a generic piezo emulator, and write a player for that. As neither PFM nor pulse interleaving will work on an actual piezo, I'd go for a Squeeker-type player. See here  for a technical discussion. Basically you generate pulse waves with reasonably low duties (say, 10-25 %) and OR them together for the final output.

In any case, please keep me up to date about this project, and let me know if I can help in any way.

Maybe 8253 emulation code from GPMD85 emulator could be of help?
https://github.com/mborik/GPMD85Emulator

Awesome, thanks Shiru!

Forgot to mention, I did apply a few changes to the source last  time. All of them cosmetic, but Clang will have a fit about these.

gui.h:9
int put_str(int x,int y,char* str,unsigned char col) =>
int put_str(int x,int y,const char* str,unsigned char col)

gui.h:42
void put_str_file(int x,int y,char* str,unsigned char col) =>
void put_str_file(int x,int y,const char* str,unsigned char col)

main.cpp:641
int put_str(int x,int y,char* str,unsigned char col); =>
int put_str(int x,int y,const char* str,unsigned char col);

select_engine.h:34, 104
if (dp = opendir(engineDirectory)) =>
if ((dp = opendir(engineDirectory)))

Also added -fPIC flag in makefile. Position-independant executables are now the default on most Linux distros, but the Angelscript JIT compiler doesn't like that idea, it seems.

More critically, since a few versions there is still a bug that will cause random "engine provided no data" errors. I cannot get a reliable way of reproducing it though. It mostly happens after applying a marker and then entering something on the first row of the new block. Though sometimes it will happen in the middle of a block as well. Usually the problem starts occuring only after editing for a while (though it will then persist through restarts), but I've occasionally had it happen on an almost blank tune as well.

Hi, this makes me think, since you're not the first to report this "ringing" problem. I think what might be happening is that there could be an unhealthy clash between HT's sample rate and the sample rate of the recording device. Though I see you already recorded at 48 KHz, which in theory should be enough to mitigate such issues. Still, try to record at 44.1 KHz just to see what happens.
Also, the usual advice - a fresh set of batteries will improve the sound. Furthermore, it appears that some mixers/recording devices are too "noisy" (ie. they leak too much phantom voltage) whichwill cause slowdown on some calcs. Does your calc appear to play faster with headphones plugged in vs. your line-in?

Thanks, seems simple enough. Will credit you once I add it to bintracker of course. It may take a while before I get around to it, though.