Optimized Player 6.1 Playroutine 'p6107.lha'

[Asle]

E:\Amiga\UAE\Decrunch>P61AConv.exe Deadlock-Musicdisk-3.mod Deadlock-Musicdisk-3.p61a
P61AConv V0.1 Copyright(C) 2022 Hop
ERROR: Unable to determine file type for input file 'Deadlock-Musicdisk-3.p61a'

E:\Amiga\UAE\Decrunch>P61AConv.exe
P61AConv V0.1 Copyright(C) 2022 Hop
Usage: P61AConv [OPTIONS] <inputfile> <outputfile>

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 ?

[hop]

Thanks for testing!

Originally Posted by Asle

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

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'

Originally Posted by Asle

Anyway, the music linked here hangs the prog : http://janeway.exotica.org.uk/release.php?id=58387
Possibly due to unused patterns ?

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

C:\temp>P61AConv.exe MOD.beyond_music P61.beyond_music
P61AConv V0.2 Copyright(C) 2022 Hop
Loading mod from file: MOD.beyond_music
Module loaded.
Converting mod to P61A...
Conversion succeeded
Wrote P61A to file: P61.beyond_music

Summary
=======

File size:
  Uncompressed: 432158 0x6981E bytes
  Compressed:   372258 0x5AE22 bytes
  Bytes saved:  59900 0xE9FC
  Compression ratio: 1.16
  Space saving: 13.9%

Metadata:
  Uncompressed: 1084 0x43C bytes
  Compressed:   473 0x1D9 bytes
  Bytes saved:  611 0x263
  Compression ratio: 2.29
  Space saving: 56.4%

Pattern data:
  Uncompressed: 38912 0x9800 bytes
  Compressed:   9689 0x25D9 bytes
  Bytes saved:  29223 0x7227
  Compression ratio: 4.02
  Space saving: 75.1%

Sample data:
  Uncompressed: 392162 0x5FBE2 bytes
  Compressed:   362096 0x58670 bytes
  Bytes saved:  30066 0x7572
  Compression ratio: 1.08
  Space saving: 7.7%

The file seems to play alright using P61Con on Amiga.

[hop]

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.

[REAKTOR BEAR]

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?

readfile macro
	move.l	dosbase,a1		;dosbase
	move.l	\1,d1			;file path
	move.l	#modeold,d2		;mode = old file
	jsr	open(a1)		;call open-function
	move.l	d0,filehandle		;save pointer to filehandle
	move.l	d0,d1		
	move.l	\2,d2			;destination in memory
	move.l	\3,d3			;bytes to read
	jsr	read(a1)		;call read-function
	move.l	filehandle,d1
	jsr	close(a1)		;call close-function
	endm


	*** THE PLAYER USES THIS IRQ SETTING ***
	move	#$7fff,intena(a6)	;disable IRQs
	move	#$e000,intena(a6)	;enable IRQs, lev6, no copper IRQ

[a/b]

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.

[REAKTOR BEAR]

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?

[a/b]

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.

[REAKTOR BEAR]

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

[a/b]

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...