[hop]

Thanks for the info. It's a great file format and it's great that the player source is so easy to integrate.

I think I have misunderstood the workflow really. Mod to P61A conversion should really be a manual export step performed by the musician rather than a build time step performed by the coder. This allows the final P61A binary to be tested on target before it is distributed.

I was looking for a portable converter and realised modpacker was not complete so for fun I have written a custom mod to P61 converter in minimal C++ (the odd reference and array new here and there).

Pattern encoding ("pass 1") and compression ("pass 2") now implemented. It produces identical binaries to P61Con for mod.amegas, sowhat-intro and new_ditty. Currently ironing out the last few bytes of diffs in DolphinsDreamquest (current bug: P61Con does not seem to match two chunk's worth of encoded pattern data at offset 0 but will match at offset 3, however it will match 3 chunks of data at offset 0. Not a big thing because end result is the same, but would like the output to be binary identical). No sample compression support yet.

I have a couple of questions that those with more 68k experience than me might be able to answer:

Does the P6112 player support shared track data i.e. > 1 pattern offset with same value? I haven't come across this yet but might be quite common.

I'm very impressed by the original p61 implementation. The run-length encoding pattern compression is very LZ77-lite. I can't help wondering if more space could be saved if the compressor and player supported matching and playing repeated blocks in pass 2. There is no persistent decoded stream so the usual length > distance technique would not work but a tiny bit more player logic should allow looping of repeated sections N times. Unfortunately there is no obvious way to encode the new compression type without changing the format. It would be interesting to run a theoretical test on a few mods to see if the file size saving is worth it.

I think that jump to row commands could be implemented either (i) partial support at conversion time, by inspection of the sequence and converting row index to offset [and ensuring that destination rows are treated like track start rows], or (ii) a similar process at init time. It might fall over for sequences that jump a given pattern into > 1 dest pattern though.

Very interesting stuff!

EDIT: Attached V0.1 Win64 executable