Search options (Page 4 of 40)

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.

Musical talent is overrated

Can confirm. Prints

Warning: trying to read song data row -1145383 column 4

repeatedly with increasingly large negative offsets, effectively freezing the program.

Thanks for spotting and reporting these! I've corrected No. 2 and 3.

I'm inclined to leave the part on Pulse Interleaving as is. You are of course correct in that moving the ld a,ixh/l up would save 8t here, but I'm concerned that it might make it harder to see the connection with the pseudo-code on the left. In the end a proper player should not be written like this anyway, because you'd still end up with an all-too-large, 10t timing difference between the skip-taken and skip-not-taken paths.

Thanks for the hard work, Shiru.

To compile with GCC/Clang, two small changes are needed. makefile:103 should read

playplayer/playplayer.o: playlayer/playlayer.cpp

and playplayer/playplayer.h must #include <cstddef> to make size_t available.

Sorry for the late reply. Shiru had already posted this, so let's continue the discussion there:
http://randomflux.info/1bit/viewtopic.php?id=332

Amazing release! Great compositions and lovely sound all around. Love how, in a way, it sounds very "classical beeper", while at the same time utilizing a massive array of state-of-the-art tech.

Ah, that's a fascinating rabbit hole. Was not aware of this composer at all. Great finds, thanks a lot. And yup, GE-115 is a mainframe for sure: https://archive.org/details/TNM_General … e/mode/2up One of the last ones GE made, if I'm not mistaken.