Jump to content

kliepatsch

Members
  • Posts

    185
  • Joined

  • Last visited

  • Days Won

    1

kliepatsch last won the day on May 31 2021

kliepatsch had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kliepatsch's Achievements

  1. BTW the screen capture looks quite nice And it's interesting to see the CPU consumption go up and down with appearing and disappearing objects.
  2. I think you are on the right track. You have got 8 million / 60 cycles per frame, that would be 133.333. When doing such estimates, I usually counted cycles, not instructions. As soon as you know what kind of game logic you want to do for every object, you can start prototyping the most costly algorithms that are required for these updates, and count the cycles that are required for these algorithms. Add a bit of extra, depending on how much logic you intend to have, and you have got yourself a first rough estimate of how many cycles you need to update an object. For example, suppose you find that you cannot get around doing two multiplications while updating an object. Start prototyping the multiplication routine. Let's say it uses 200 cycles on average, so that you have 400 cycles for the two multiplications needed for each object. Let's say you need a fair bit of extra logic/code for the object update, so let's assume 250 more cycles. So your total estimate would be 650 cycles per object. This lets me arrive at 133333/650 = 205 objects.
  3. I cannot follow the whole calculation. I agree on the 1600000 instructions per second, or 26667 instructions per frame. If you update 40 objects each frame, that would be 667 instructions per object and frame. As far as I know, there are hblank and vblank intervals, so the instructions per scan line computation is not as straightforward as it seems. I know this because of the box16 emulator, which has a CPU activity visualization with scan line overlay, and if I remember correctly, there were those hblank and vblank periods. Anyway, you would get less than 2 instructions per scan line and object. So it is not possible to update every object on every scan line. But then again, I don't think that this is necessary. One update per frame should be enough, shouldn't it?
  4. Thanks to all the new managers and moderators! And thanks to the old ones! Your efforts are much appreciated
  5. The red block in the top right corner typically indicates disk activity, and if it persists, some disk operation has probably gone wrong. Some load routines don't work with SD card and there have been known bugs for a long time (ironically, other functions don't work without an SD card image). So I conclude that BRIXX probably makes use of some Loading functionality that's broken when used with an SD card image. But I would have to try this out myself to be sure
  6. I like the approach of setting a pointer and say "go". I'd also think that doing some simple control of playback speed would be possible. But I'd be careful with that as that is moving away from lightweight (in terms of CPU) player more into synthesizer territory. Volume control is definitely out-of-scope, I think, since that requires too much CPU power. Honestly, I think the PCM functionality should just provide play a sample at given sample rate, address and length (perhaps an option to loop the sound). That way, PCM will be useful for drum sounds and sound-effects without consuming too much CPU. But I doubt it would be sensible to use it for melodic instruments, given the YM and PSG.
  7. The big question to me seems how you pass the audio data. Do you support a limited amount of samples that can be reused all the time like in mod files, or do you want to stick to the streaming paradigm even for PCM?
  8. Wow, with the stars in the background it's starting to look really beautiful.
  9. Definitely. If you're new to FM synthesis, I too would recommend getting access to some FM synthesizer other than using assembly or C on the CX16. I haven't tried Deflemask, but from what I have seen in Matt's video, it seems to be a good fit for that.
  10. The FM synthesis on the YM2151 works pretty much the same way it works in the Yamaha DX7. The biggest difference is that the DX7 has 6 operators whereas the YM2151 has only 4. But 4 operators is still plenty of material to work with. Both modulators and carriers are "operators", and both can either modulate or output sound. In "connection" 7, all operators output sound directly, in "connection" 0, only the operator 4 outputs sound, whereas the other three are modulators. I disagree with how the YM2151's manual calls the operators modulator or carrier regardless of what they are actually doing (which depends on the "connection", or "algorithm" in terms of DX7 language). I learned FM synthesis by simply seeing examples of what can be done with FM synths and how it is done, and then trying them out by myself. And a lot of messing around and trying stuff out (making educated guesses). You could start with these two tutorials, and then search other DX7 tutorials. The YM2151 does not have all the features of a DX7, but most things can be applied to the YM2151 as well. I should mention one pitfall that has confused me when I started working with the YM2151: the total level (TL) in the YM2151 is attenuation! TL=0 means max level. TL=127 means no output. The same goes for the decay level IIRC (D1L). If you want to hear something, the attack rate (AR) should be non-zero. Maybe set it to 10 or so. Higher values make it faster, low values slower. I am sure things will change slightly. The envelopes are indeed slightly slower with 3.5 MHz clock. But I am not worrying about that right now. Any patches can be adapted as soon as the official emulator moves on.
  11. I think I got that program working with R38. I used the YM2151 in my recent music demo, alongside the VERA PSG. The bass, hihats, kick drum and melody are done with the YM2151. The supersaw and the noise effects are done with the PSG. Concerto can be tried out in the Web Emulator: Concerto lets you program sounds that combine the VERA PSG and the YM2151, but of course you can simply deactivate the PSG by reducign the number of (PSG) oscillators to zero. This is done under "Global" -> "N. OSCS". After that, the YM2151 is the only sound source. You can program the different parameters on the right side of the Concerto UI. Use your keyboard to play notes to hear what it sounds like. Some parameters are not available though, e.g. the LFO. The YM2151 SYNTH UI program mentioned by Ender can be used to learn about those.
  12. You are right: the overall volume of the emulator is very low. There's nothing you can do about it from inside a program that runs on the X16. (One could, however, recompile the emulator with increased output volume)
  13. Thanks for the clarification. I missed that part So you're doing 60 Hz playback with two different methods, one with and one without prior conversion of the music data to 60 Hz. Gotcha
  14. That's an interesting result! How did you set up the timing of 44100 Hz? And how is the CPU time being measured?
  15. Found the reason behind this: for some reason, the YM starts an octave with C#, not C (see Fig. 2.4 in the manual of the YM). That explains why I have to subtract not 2 but 3 to get from the MIDI note to the YM's note value (and then after that still do this weird 0...11 to 0...15 range conversion)
×
×
  • Create New...

Important Information

Please review our Terms of Use