I might actually finish this one

Page 6/6
1 | 2 | 3 | 4 | 5 |

By Bengalack

Master (192)

Bengalack's picture

27-09-2020, 22:23

@santionanon and @Grauw - that's really some impressive numbers.

By Bengalack

Master (192)

Bengalack's picture

29-09-2020, 19:08

Thank you all so much for the positive feedback on this. Greatly appreciated! Big smile

By salutte

Expert (108)

salutte's picture

30-09-2020, 15:35

It looks really cool Bengalack!! Looking forward to see its progress!

By Bengalack

Master (192)

Bengalack's picture

18-10-2020, 13:53

Bengalack wrote:

I see that it can be downloaded here at msx.org, as well as some sample files, so I can probably test it for performance myself.

I have downloaded Moonblaster 1.4. I had to spend some time understanding it all, as the replayer didn't just work out of the box. No sample/demo. Also, when I finally got it to work, I only got it to work on an emulator. Didn't work on my physical machine :-(

Anyways here are some timings (cycles counted from the tcl-profile-script for openmsx):

http://abyssmsx.com/vscreen-doc.htm (Vscreen tune)
Moonblaster says "MSX-MUSIC chn: 6"
avg: ~6000 max: 11505 (msx-music) / 13522(msx-music + msx-audio)

https://www.msx.org/downloads/music/moonblaster/adrs-theme-11
Moonblaster editor says "MSX-MUSIC chn: 9"
avg: ~7000 max: 14121 (msx-music)

https://www.msx.org/downloads/music/moonblaster/ancient-ways
Crashed

https://www.msx.org/downloads/music/moonblaster/anormal-acti...
Moonblaster says "MSX-MUSIC chn: 6"
avg: ~7000 max: 11888 (msx-music)

https://www.msx.org/downloads/music/moonblaster/final-future...
Moonblaster editor says "MSX-MUSIC chn: 6"
avg: ~7500 max: 11541 (msx-music) / 13527(msx-music + msx-audio)

NYYRIKKI's mbm-files from his post here:
https://www.msx.org/downloads/music/trackers/moonblaster-14
Crashes the replayer (code overwrites itself).

CONCLUSION:
I will likely pursue another replayer. I just need to find something where there is an acceptable pipeline from a solid composer-program and down to the replayer-data. Hopefully I don't have to write everything myself (which is often the case). Currently Grauw's tile² seems very interesting :-) And it is also very interesting to see what comes from Metalion down the line.

By Manuel

Ascended (16978)

Manuel's picture

18-10-2020, 14:02

The advantage of Moonblaster is that many people have used it and it's probably one of the easiest to use composer programs that run natively on the MSX2. There is a lot of material around and many tweaks on the original replayer code exist.

Especially if you want to support both MSX-MUSIC and MSX-AUDIO it's useful.

The downside is that it doesn't use make use of all features of the chips.

The 6 vs 9 means whether it's using RHYTHM mode or not of the MSX-MUSIC. With that mode you get 6 FM channels and 5 drum channels (see YM2413 docs). Without it you just have 9 FM channels.

By Bengalack

Master (192)

Bengalack's picture

18-10-2020, 20:15

Manuel wrote:

The advantage of Moonblaster is that many people have used it and it's probably one of the easiest to use composer programs that run natively on the MSX2. There is a lot of material around and many tweaks on the original replayer code exist.

Yes. So, if the replayer-tweaks can get the cycle-use down, then it is as interesting as Tile²'s player. Otherwise it seems like Moonblaster (editor) can still be used for composing and then be "replayed" as vgm'ish files. I haven't read up fully on VGM yet. But from the outset it seems like there are possibly a little too big files(?). 44100hz and wide support seems "big". But I reckon, if the recording is done on 60Hz and replayed on 60Hz, the file size is much smaller. Also if you can take the original recorded VGM-files and trim or target one specific chip for output, and pack the data too, things should shrink quite a bit. Maybe we can get to a nice compromise, Moonblaster editor and VGM-output? That said, I am really curious of the file sizes one can expect from a nice MBM-tune converted to VGM. But, I need to read up on that.

By Manuel

Ascended (16978)

Manuel's picture

18-10-2020, 21:40

VGM is nothing but recording the writes to the sound chip registers. Not sure what 44100 has to do with it.

By Grauw

Ascended (9342)

Grauw's picture

18-10-2020, 22:16

The 44100 Hz refers to the timing resolution of the VGM file format. It is a bit arbitrary. In an MSX-specific format for replaying purposes, you’ll quantise it down to 60 Hz, or 300 Hz if you’d want to equalise between 50 Hz and 60 Hz interrupt frequencies.

As for the data size, indeed quantizing, targeting a single chip and generating a command format optimised for the target chips will reduce the data size significantly.

I’m also investigating compression at the moment. The compressor side of things is a bit complex. I’m posting my results in the Assembler Optimizer thread for the time being (given its applicability to size optimisation of source code), and will report my final results in the Tile² thread when I’m done.

The benefit of the type of compression I’m using is that it doesn’t need a RAM buffer to decompress to. It puts “call” and “jump” commands in the stream to reduce duplication. But of course traditional LZ77-based compression can also be used as long as you have sufficient RAM. Compression and decompression code for those are more readily available.

And lastly if size is not a big restriction, such as in a MegaROM, you can just keep it uncompressed. In the context of the current Tile² code there’s an 8 kB size limit (bank size), however that can be overcome by introducing a jump-to-next-bank command when the end of each 8 kB block is reached. Doing it like that is more efficient than checking for bank end at each data read.

By Bengalack

Master (192)

Bengalack's picture

18-10-2020, 23:26

Super-interresting. I'll try to read up on these things, and try out a bit.

By Grauw

Ascended (9342)

Grauw's picture

19-10-2020, 01:17

Grauw wrote:

As for the data size, indeed quantizing, targeting a single chip and generating a command format optimised for the target chips will reduce the data size significantly.

To give a few examples of what kind of size reduction to expect from a specialised format, taken from from the Ghosts ’n Goblins files… A 10.741 byte VGM (0:33) was reduced to 3.899 bytes. Another 13148 byte VGM (0:39) was reduced to 4683 bytes. And a 18822 byte VGM (0:31) shrunk to 7475 bytes.

Page 6/6
1 | 2 | 3 | 4 | 5 |