Optimized Player 6.1 Playroutine 'p6107.lha'

[Leffmann]

I didn't know I was the only one who had the sources, I'll upload them to Aminet right away.

[TheDarkCoder]

Yes, please!

Back when I did some coding, I would have payed a resonable amount for such sources!

[xxxxx]

just out of curiosity, have you guys made any more progress on the conversion to C or separation of converter and GUI?

[TheDarkCoder]

Originally Posted by Leffmann

I didn't know I was the only one who had the sources, I'll upload them to Aminet right away.

I leffman, have you uploaded the sources of p61con ?

[Leffmann]

Yep, they've been on Aminet since 6 months:

http://aminet.net/package/dev/src/theplayerconsrc

If you can't get anywhere with The Player, try Hitchhikr's PtPack, it has a finished command line tool for converting modules.

[TheDarkCoder]

Originally Posted by Leffmann

Yep, they've been on Aminet since 6 months:

http://aminet.net/package/dev/src/theplayerconsrc

If you can't get anywhere with The Player, try Hitchhikr's PtPack, it has a finished command line tool for converting modules.

ooops !

I searched for it, but not with the right name!

thanks

[Photon]

I've updated The Player (P61) playroutine since this post - The latest version, P6112 is available from Aminet. It's easier to use and the source has been made compatible with many different Assemblers.

[daxb]

Thanks for update!

[tolkien]

Will try to use it with vbcc. Looks good.

Looks like even the cmdline options of the p61con are completely broken. If I try to use it with cmdline options from the amiga shell, I always get a Guru Mediation.

[REAKTOR BEAR]

It says in the player code that the actual "music play" routine, uses d0-d7 and a0-a7.

How do we make any democoding if the player is pulling on all the temporary system registers?

[DanScott]

Originally Posted by REAKTOR BEAR

It says in the player code that the actual "music play" routine, uses d0-d7 and a0-a7.

How do we make any democoding if the player is pulling on all the temporary system registers?

you stack your registers before calling the play function

movem.l d0-d7/a0-a6,-(sp)

and unstack them after

movem.l (sp)+,d0-d7/a0-a6



But really you can arrange your code so that it doesn't rely on the contents of the registers after returning from the play routine

[REAKTOR BEAR]

Thanks...
How about timing demo FX to the module? Can we check for curent pattern / play postion?

[StingRay]

Originally Posted by REAKTOR BEAR

Thanks...
How about timing demo FX to the module? Can we check for curent pattern / play postion?

Sure. Just check the player code, the relevant variables containing pattern/pattern row etc. are easy to find.

[REAKTOR BEAR]

Yeah we found all those vars... but we've had no luck getting to the actual values in those vars... what ASM code can be used to poke those player vars?

[a/b]

If you load the player (not the module, just in case) to address X then, for example, the current row index is at address X+P61_Row. P61_Pattern is inverted, goes 63 to 0, P61_Position is pattern index within a song, etc.

	structure Player_Header,0
	ulong P61_InitOffset
	ulong P61_MusicOffset
	ulong P61_EndOffset
	ulong P61_SetRepeatOffset
	ulong P61_SetPositionOffset
	uword P61_MasterVolume
	uword P61_UseTempo
	uword P61_PlayFlag
	uword P61_E8_info
	aptr P61_UseVBR
	uword P61_Position
	uword P61_Pattern
	uword P61_Row
	aptr P61_Cha0Offset
	aptr P61_Cha1Offset
	aptr P61_Cha2Offset
	aptr P61_Cha3Offset
	label Player_Header_SIZE

And those are actually (internally) these (starting at label P61B), a few pages down in the source:

...
P61_Master:
	dc.w 64
P61_Tempo:
	dc.w 1
P61_Play:
	dc.w 1
P61_E8:
	dc.w 0
P61_VBR:
	dc.l 0
P61_Pos:
	dc.w 0
P61_Patt:
	dc.w 0
P61_CRow:
	dc.w 0
...

So you can see how they are handled internally and determine if they are what you want or not...

[hop]

I've just come across modpack, which looks like a portable mod to P61 converter which could be used on host (PC) as part of the build process. This looks very promising, but I haven't had a chance to evaluate it yet. I couldn't see a mention of it anywhere on the forums. Has anyone used this?

[hop]

Originally Posted by hop

I've just come across modpack, which looks like a portable mod to P61 converter which could be used on host (PC) as part of the build process. This looks very promising, but I haven't had a chance to evaluate it yet. I couldn't see a mention of it anywhere on the forums. Has anyone used this?

Got it building on Windows with some minor fix-up. Seems to work nicely. Producing slightly larger binary for my test case than P61Con on Amiga, but might just be the options (compression maybe). Might dig in a little deeper.

[Photon]

Some information

P6107 added optimization
P6108 added lots of optimization spreading decompression work over multiple frames, ruling out F01/F02/etc and added some options, see notes
P6112 is mostly P6108 with fixes and support many/all assemblers, see notes

Original P6106 already has lots of compiler directives and can be difficult for a human to parse if you're not used to it, I have through the versions tried to keep all of this intact and provided "directive option groups" simplified to 4 modes, the directives themselves have not been changed other than to make it compatible with more assemblers.

I have added a few peeks/pokes to make syncing easier, but as Stingray says you must look at the code to see where to read positions etc. Positions are still same despite the spreading out of work across frames.

It is still recommended, for P6106/7/12 to verify playback with the musician to catch effect errors in P6106+. I have not changed any effect code, check playback inside P61Con, and some effects possible in Protracker are not possible in P61, e.g. jump around inside a not fully decompressed track (decompressing the whole track to allow this would cause a huge lag in one frame).

Every version is still very compatible with tracks not specifically produced to display advanced technical prowess in music compos (this requires playing from inside exact tracker version UI).

[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