English Amiga Board

Go Back   English Amiga Board > Coders > Coders. General > Coders. Releases

Thread Tools
Old 19 July 2022, 21:41   #61
Registered User
Join Date: May 2006
Location: Paris/France
Age: 51
Posts: 511
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'

P61AConv V0.1 Copyright(C) 2022 Hop
Usage: P61AConv [OPTIONS] <inputfile> <outputfile>
It is confusing - so, what's really input ?

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 ?

Last edited by Asle; 19 July 2022 at 22:28.
Asle is offline  
Old 20 July 2022, 14:41   #62
Registered User

Join Date: Apr 2019
Location: UK
Posts: 96
Thanks for testing!

Originally Posted by Asle View Post
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 View Post
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


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

  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.
Attached Files
File Type: 7z P61AConv0.2_win64.7z (17.2 KB, 16 views)
hop is offline  
Old 30 July 2022, 01:40   #63
Registered User

Join Date: Apr 2019
Location: UK
Posts: 96
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.
Attached Files
File Type: 7z P61AConv.7z (19.9 KB, 18 views)

Last edited by hop; 30 July 2022 at 01:44. Reason: clarification
hop is offline  

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Super Optimized P6108.lha playroutine :) Photon Coders. General 15 07 November 2013 19:15
Looking for ArtOfNoise Playroutine (68k assembler) Herpes Coders. Asm / Hardware 5 05 September 2012 01:10
Tracker/Playroutine to play tubular.mod Photon Coders. General 15 10 March 2006 22:09
Optimized Protracker playroutine? Photon Coders. General 10 11 June 2005 01:54

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 10:03.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.
Page generated in 0.10700 seconds with 17 queries