It is confusing :) - so, what's really input ?

---edit
Wait, you actually expect the output file to have the extension "p61" !. wow.
Anyway, the music linked here hangs the prog : http://janeway.exotica.org.uk/release.php?id=58387
Possibly due to unused patterns ?

Thanks for testing!

Sorry about that. Copy-pasted error message. Fixed now - the tool now assumes that output file format should be P61A, even if doesn't start with 'p61.' 'p61a.' or end with '.p61' or '.p61a'

You're right. Unused patterns were not fully supported. Feature added in V0.2 (attached).

The file seems to play alright using P61Con on Amiga.

In case this is of use to anyone, please find attached P61AConv.exe V0.3

This version generates identical binaries to the original P61Con on Amiga for the modules I've tested (mainly the ones from P6112.lha). It also generates the usecode.

Generating identical binaries wasn't really necessary but I wanted to make sure I hadn't missed any important features, and it was a fun process...

By debugging P61Con with mod.Dolphins-Dreamquest in WinUAE wrt to the original source code, at label 'eienaa', it can be seen that the length in bytes of the match 'bestreallength' is calculated incorrectly. This can be thought of as "scoring" the match. At the point it is calculated, the search end pos (in A0) has been advanced by the size of the last chunk *which did not match* (if another chunk actually followed). The code then proceeds to incorrectly and unconditionally subtract #3 saying "Taken up by dummy note,length and 8-bit offset", when the size of the last chunk could be anything between 1 and 6 bytes (1-3 control bytes + 0-3 compression bytes), or there might not actually have been a last chunk if it was end-of-stream.

In the case in hand for P61.Dolphins-Dreamquest Pattern 3 channel 0 row 00 the search string is "F3 23 07 F3 23 07" but the compressed pattern data search window starts with "F3 23 07 F3 23 07 F3 23 07 B2 39 C2 01" which is 3 identical chunks "F3 23 07" of length 3 followed by a chunk "B2 39 C2 01" of length 4. Because of the mistake in the algorithm the tool favours the match starting at 0x3 over the one starting at 0x0 because on the second iteration the search pointer has advanced by an extra byte.

There's also another minor off-by-two error when calculating the score. It always subtracts 1 if offset >= 256 but doesn't factor in the size of the compression chunk into the offset. This means that 16-bit jumps can be favoured over 8-bit jumps in some situations (I think).

Neither of these bugs are dangerous at all, they can just result in slightly different (and occasionally, fractionally larger) binaries.

I'll try to release the source for this when it's feature complete and converted to pure portable C. The current big missing feature is sample compression.

Does anyone know how to read diskfiles while player is running?

We are using macro to read diskfiles... it works if triggered prior to player, but once the player is active, reading a diskfile stalls the machine... I suspect IRQsetting or maybe player overwrites d0-d3 constantly?

You have to use the P61 in one of the system friendly modes, so it uses system interrupt handlers instead of taking over the interrupts completely.
Basically, set p61system and p61exec to 1 when assembling the player. Note that this affects the performance.
Custom solutions are possible, but you'd have to write some "tricky" code.

Great thanks :), seems to be working: P61mode=1 .. split4=1 .. p61system=1 .. p61exec=1 .. p61bigjtab=0 .. p61cia=1 .. lev6=1 .. dupedec=1 .. splitchans=1. We also deleted 2 lines with IRQ settings: "disable IRQs .. enable IRQs, lev6, no copper IRQ".

However, when we use P61con and "pack samples" it fails to load the module, is there a fix to this or is it better to compress P61 module inside the ASM compiled binary?

IIRC, pack samples reduces sample quality slightly so I've never used that.
It also requires a change in initialization, pointer to packed samples should be passed in a2. edit: It's sample buffer in a2, probably where to unpack the samples.

OK, Thanks... We will use Shrinkler, seems to be very good compression of ASM and binary.

You could also try to delta the samples, it typically results in better compression.
Instead of d0, d1, d2, d3... you have d0, d1-d0, d2-d1, d3-d2...
Then after decompression, you undelta them back to d0, d1, d2, d3...