Search options (Page 3 of 40)

Ah, great, it's a binary. 1990s called, they want their file formats back. Even after decompressing it, I can't make much sense of it.

Meanwhile, massaged the engine a bit so it does 60Hz updates (at a sample rate of 9114Hz, can't go faster anyway). Now I'm wondering what to do with the drums. Documentation says they're pitchable 1-bit PCM drums up to a max length of 2048 samples running at a rate of 54420 Hz. Not sure why you would want to do it this way, but ok. I'd use PWM drums in any case, but 54420Hz comes down to about 63t, which I don't think is enough to decode either 1-bit PCM or PWM AND calculate pitch. Might have to cut some corners here.

That actually looks quite workable, for a start. I think it could be compressed well enough by first condensing each row so that duplicate data is omitted and presence/absence of entries is marked with some control byte, then adding each unique row to a dictionary and constructing a sequence of pointers to the dictionary.

The question would be what to do with those 60Hz updates. Could be implemented as such in the engine, at the cost of lowering the sample rate and sacrificing accuracy in the time domain (ie. updates would be applied on consecutive loop iterations instead of all at once), or one could recalculate any effects for a lower update rate. In any case effects would need to be flattened/precalculated.

Some things in this dump are a mystery to me as well though. 4: NOTE_ON 24 2 might be a trigger for the interrupting PWM channel, but then where's the sample data and what defines the playback length of the sample?

Edit: Another problem with the stream dump format is that it does not seem to distinguish actual triggers from notes continued from the previous row. Also, where is the instrument information (eg duty)?

quad tone is the Furnace one afaik

Congrats AER A well-deserved win.

If there is a new engine with not-too-difficult data format, I can add it to Bintracker. If game_music_emu supports GTIA then 1tracker would also be an option.

I don't think the SampleTracker engine will sound too great on GTIA. It's pretty bad on ZX beeper as well from what I remember. I think Shiru added that more with AY/Covox in mind.

Yay, Beep'em all VI! Great collection.

Wow, massive collection, pretty neat. I'd love to also see some demo songs from old PC Speaker editors like Music Construction Kit, Note Baron, VMusic, etc.

Yesss!

To be honest I completely lost track of what is available on GTIA nowadays. Could you post a list of currently available engines?

Alright, got it working. Quick'n'dirty test doodle attached.
The SDL number keys seem a bit wonky, sometimes returning the "last entry" instead of the actual number of the key pressed. Other than that I couldn't spot any issues on my quick try-out.

Very pleasant sound, indeed. Btw, when you have things ready for linux, I can help with testing the build, at least.

Found a new el-cheapo PRNG/noise generator. It's a bit slower than the usual add hl,de; rlc h variations, but needs only 1 register pair instead of 2. It also sounds a bit different.

  ld a,MAGIC_NUM
  add a,e
  rrca
  xor d
  ld e,a
  inc d

For MAGIC_NUM, most values do pretty much the same, except some that are straight metallic beeps and a few that sound more rumbly.
test.tap plays through all possible values.

The main downside is that we can't smc-hotswap this with regular tone channel code. What could work though is to hotswap it on an 8-bit divider and use a separate 8-bit pre-scale on this. Pre-scale would pitch the noise as well. Unfortunately the perceived pitch of the noise is quite a bit lower than using add hl,de; rlc h. Not sure if it's actually much of an improvement over just lazily reading from ROM:

  ld a,(de)
  inc de

I thought that hardware support was supposed to be added/extended in 0.6, but it seems indeed that hasn't happened yet. I trust they'll get around to it at some point, though.

Never mind the low notes, seems there's variable duty as well. I suppose it's not interrupt-driven, then? Anyway, I have my doubts about this. I mean for PET emulator support can't really be trusted. If they can get it to work on hw then that's awesome, though.