ProTracker 2.3F - Page 3

4mat_ · 21 January 2016, 19:26

Quote:

Originally Posted by 8bitbubsy

Just change ASL.W #1,D3 with ASL.L #1,D3 (or ADD.L D3,D3 which I think is faster?) in the "PlayVoice" routine in the replayer/PT code. That's it. Nothing more to it. The PT2.3E MOD format is still identical to the other ones.

If that's all that changes then no worries, the post sounded more like some sort of PT3.x nightmare was on the cards.

HanSolo · 21 January 2016, 20:44

Why 2.3 got support ?? Is something wrong with 3.62 ?

daxb · 21 January 2016, 21:02

Quote:

Originally Posted by 8bitbubsy

Ah I see the problem. I think it's because of the dot (".") in the directory. I'll try to look into it. Weird stuff...

Please don`t waste your time with this. At least if you cannot reproduce it.

Quote:

128kB sample support was fixed in PT3.62. I don't know if it could properly load 128kB samples, but it could at least load MODs with 128kB samples and you could see all of it and set loop points and stuff. The replayer could also play loop points above the 64k barrier. PT3.15 and older versions had severe problems with 128kB samples.

I`m using PT3.62 and mean it hasn`t full support of 128kB samples handling. Yes, it can load modules containing large samples but it cannot load or record 128kb samples. Hence, I belive they are seldom used. I myself just used it in around 2 modules. You need to build samples >64k in the sample editor. Also only the first 64k are shown in the editor, so you cannot set loop points this way or edit it like 64k samples.

Amiga1992 · 21 January 2016, 21:19

Quote:

Originally Posted by HanSolo

Why 2.3 got support ?? Is something wrong with 3.62 ?

Everything is wrong with 3.x

8bitbubsy · 22 January 2016, 00:38

Quote:

Originally Posted by daxb

Please don`t waste your time with this. At least if you cannot reproduce it.

Sorry, but I'm actually a robot and I have to fix every bug that people point out. I *did* reproduce your problem today, but I still don't know what part of the code is bugged. PT2.3D has the same problem. I will definitely find out at some point - probably tomorrow (today).

I fixed another "bug" (rather a bad program design thing) right now. Whenever you change the Disk Op. path and you press ENTER, it will automatically refresh the file list. On PT2.3D, you had to click LOAD MODULE (or some other button) to refresh the file list after you changed the path.
Also fixed the "FREE" number in Disk Op. Instead of overflowing and showing nonsense numbers, it will show "TOO MUCH" if the free space is more than 99MB.
The updated PT2.3E is in the same URL in the first post of this thread, as always.

Quote:

Originally Posted by Akira

Everything is wrong with 3.x

Finally someone who understands. :-)

Quote:

Originally Posted by Toni Galvez

I was asking for a custom format 8bitbubsy, we want something better for our developments, we do not want to interfere wit Protracker, but a *custom* tracker, based on Protracker, but with 64 samples and some more stuff.

Yes I know that you asked for a custom tracker and format, but it won't happen anytime soon... Maybe one day after I feel satisfied with releasing a stable PT2.3E.

TjLaZer · 22 January 2016, 08:16

I tried it on my A1200 with Blizzard 1260 and it would not work. Rebooted and tried again, and it loaded. But then crashed. Any trick to get it working with an 060?

hooverphonique · 22 January 2016, 11:39

Quote:

Originally Posted by daxb

The guru happens when I start PT from WB, quit it, start it again and quit. When I start it somewhere early at startup-sequence time no guru happens. So maybe something running here could cause it. I`m not so interested in find out the causer. Checked 2.3d and the same guru happens just after start/quit it from WB. Seems my system environment doesn`t like it.

If you or someone else don`t get the error you should ignore this.

Code:

Error : 0100000C (Recoverable)
By    : ExecLibrary
Cause : Sanity check on memory list failed during AvailMem(MEMF_LARGEST)

This hints at memory corruption (i.e. someone writing over the boundaries of allocated memory).. It does not have to be PT, of course, but if the problem occurs specifically when using that, I'd say it has something to do with it.

8bitbubsy · 22 January 2016, 14:40

Quote:

Originally Posted by TjLaZer

I tried it on my A1200 with Blizzard 1260 and it would not work. Rebooted and tried again, and it loaded. But then crashed. Any trick to get it working with an 060?

It works beautifully here on my 060 A4000T...

Anyways I fixed some more bugs. I gave up on the "dot in filename" bug for now, so I just renamed the PT2.3E folder to PT23E in the LHA archive.

daxb · 22 January 2016, 15:14

@8bitbubsy:
Nice to hear that you could reproduce it and I`m not alone.

Oh yes, the good old free space number bug. I`ll miss that.

@TjLaZer:
Boot without S-S, start PT2.3E and see if that works or not.

@hooverphonique:
I think/thought similar but that is just guessing. However, I did some tests with MuGuardianAngel running and got a hit (see below). Saw graphics and VisualPrefs there and after booting without VisualPrefs no hit occur. Because of PT and VP are more or less a bit hacky I wouldn`t say one of it is the causer. They just don`t like each other.

Code:

MuGuardianAngel hit! Bad program!
22-Jan-16   14:30:25
Rear Mung-wall at 00050c30 is damaged.
PC  : 00fc9bde  USP: 019b02d8 ( )( )  Name: ProTracker v2.3E
----> 00fc9bde - "ROM - graphics 40.24 (18.5.93)"  Hunk 0 Offset 00004726
PCa : 00fc9b38  Name: ProTracker v2.3E
----> 00fc9b38 - "ROM - graphics 40.24 (18.5.93)"  Hunk 0 Offset 00004680
By  : AllocMem(000003c0,00010002)
Data: 000003c0 abadf00d 00000000 000003c0 019a43a8 0000ffff 0000ffff 0000ffff
Addr: 019b0bd4 00050c30 019b0be0 010a4a04 015cce28 019b03d0 SysBase  --------
----> 015cce28 - "System:C/VisualPrefs"  Hunk 3 Offset 00000000
Stck: 00000008 00fa827e 019a43a8 01087eec 00fc9c6e 019b0bd4 00fc0a1a 010a4a04
Stck: 00fa9c10 019b0bd4 019b03ca 019a43a8 010a4a04 00fa9f86 019a43a8 019a43d4
Stck: 019a43a8 019a43d4 010a4a26 019a43a8 019b03ca 019a43a8 010a4a04 00fb02e6
Stck: 019a43a8 00faf304 019a43a8 00fa827e 010a4a04 00fb003c 015cce28 00fb0972
Stck: 00000019 019a43a8 019b0394 010a4a04 00faefc8 00faeee8 019b0394 010a4a04
Stck: 019a457e 00faedce 019b0394 019a43a8 00000005 00000000 019b912c 01995858
----> 00fa827e - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 000001a6
----> 00fc9c6e - "ROM - graphics 40.24 (18.5.93)"  Hunk 0 Offset 000047b6
----> 00fc0a1a - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00018942
----> 00fa9c10 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00001b38
----> 00fa9f86 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00001eae
----> 00fb02e6 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 0000820e
----> 00faf304 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 0000722c
----> 00fa827e - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 000001a6
----> 00fb003c - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00007f64
----> 015cce28 - "System:C/VisualPrefs"  Hunk 3 Offset 00000000
----> 00fb0972 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 0000889a
----> 00faefc8 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00006ef0
----> 00faeee8 - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00006e10
----> 00faedce - "ROM - intuition 40.85 (5.5.93)"  Hunk 0 Offset 00006cf6
----> 01995858 - "System:C/MuGuardianAngel"  Hunk 2 Offset 00000068
PC-8: 805c0006 66027401 2c6e01a4 3610c6e8 000245e8 00086008 225a2003 4eaeff2e
PC *: 51cafff6 4cdf440c 4e7548e7 1800b6bc 00000100 646a48e7 c002b0fc 00006712
00fc9bbe :  805c                       or.w (a4)+,d0
00fc9bc0 :  0006 6602                  ori.b #$2,d6
00fc9bc4 :  7401                       moveq.l #$1,d2
00fc9bc6 :  2c6e 01a4                  movea.l $1a4(a6),a6
00fc9bca :  3610                       move.w (a0),d3
00fc9bcc :  c6e8 0002                  mulu.w $2(a0),d3
00fc9bd0 :  45e8 0008                  lea.l $8(a0),a2
00fc9bd4 :  6008                       bra.s $fc9bde
00fc9bd6 :  225a                       movea.l (a2)+,a1
00fc9bd8 :  2003                       move.l d3,d0
00fc9bda :  4eae ff2e                  jsr -$d2(a6)
00fc9bde : *51ca fff6                  dbra d2,$fc9bd6
00fc9be2 :  4cdf 440c                  movem.l (a7)+,d2-d3/a2/a6
00fc9be6 :  4e75                       rts
00fc9be8 :  48e7 1800                  movem.l d3-d4,-(a7)
00fc9bec :  b6bc 0000 0100             cmp.l #$100,d3
00fc9bf2 :  646a                       bcc.s $fc9c5e
00fc9bf4 :  48e7 c002                  movem.l d0-d1/a6,-(a7)
00fc9bf8 :  b0fc 0000                  cmpa.w #$0,a0
00fc9bfc :  6712                       beq.s $fc9c10
W:00050ff0 c1<>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051000     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051010     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051020     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051030     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051040     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051050     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051060     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051070     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051080     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00051090     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................
  000510a0     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................
  000510b0     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................
  000510c0     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................
  000510d0     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................
  000510e0     c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 ................

8bitbubsy · 22 January 2016, 17:50

Hmm still weird, seems to be some incompatibility with VisualPrefs indeed. It's most likely some code in PT that is evil.

EDIT: I fixed a major sample loading bug right now that would mess up things in mysterious ways.

hukka · 24 January 2016, 03:47

Major thumbs up for doing this!

I didn't yet test all of the new changes, I only did some small tweaks to a tune using the new version, but there was one problem (which I already had with 2.3D, and might not necessarily be a PT bug anyway since this is a somewhat tweaked Workbench (ClassicWB on an Amiga 1200)):

I multitask with PT by pressing the key above tab to switch back to Workbench. Whenever I return to PT by clicking the topright button in WB to switch screens, mouse clicks aren't handled properly in PT. All clicks in PT seem to get processed by BOTH ProTracker and Workbench, in that order, and since the mouse cursor is still located on top of the "screen switch" button in Workbench, this means that every left click inside PT now switches me back to Workbench. Keyboard works fine though. Anyway, I would love to have a fix for that, if possible!

8bitbubsy · 24 January 2016, 16:10

Hmm I can't reproduce that problem. Nonetheless I don't have the knowledge needed to fix it, it's probably related to some 'WB process' routines.

daxb · 25 January 2016, 16:25

I tried the new version a bit and it seems that the guru I got with previous version is gone. At least so far I tried.

Btw. it would be nice if you can include history text file in the archive. And what about a version string in your source?

You may use another string for "too much" (disk free) because someone can think something goes wrong.

Instead something like ">99MB" or "enough". Or you replace/change it to MB values if the max bytes value is reached?

While playing some mods I noticed some small interrupts. After returning to WB I saw sashimi window showed some MuForce hits what seems to the reaseon for the interrupts. However, for the record here only the first hit because it is always the same:

Code:

WORD READ from 00000000                        PC: 01C15F86
USP : 017F3FBE SR: 2600  (S6)(-)(-)  TCB: 017EC260
Data: 000000BB 000026E8 000610E0 00000000 0000010E 0000001E 00000005 0000000A
Addr: 01D69144 01C2A73E 01D690C0 01D68D14 00000000 00DFF0B0 01C28792 01082668
Stck: 0000017F 40100000 001F00FE DF200000 FFFF0000 00000000 00000000 00080000
Stck: FFFF0180 3B4C0000 0005005F D014017F 4050017F 4084010A 7A7C0108 0E46017F
Stck: 40510000 00000000 00000162 7B340000 0000454E 563A00FE C6CA00FE C6BE0000
Stck: 000F00FE BC38017E C2D4017E C2D00556 017F4038 03EFFFFF FFFF017F 40240156
Stck: 81FC0000 000FFFFF FFFF017F 405800FF 03100445 4E563A00 000F017F 40CC0000
Stck: 0008017F 40840000 11000180 3B4C0000 00050154 6B5E015C 02E20180 3B5C015C
----> 01C15F86 - "Ram:PT23E/PT2.3E"  Hunk 0001 Offset 0000146E
----> 0005005F - "Ram:PT23E/PT2.3E"  Hunk 0002 Offset 0000105F
----> 00050154 - "Ram:PT23E/PT2.3E"  Hunk 0002 Offset 00001154
PC-8: 43F901C2 A83C7E16 700030C0 32C051CF FFFA4E75 48E7F080 7400342E 00026010
PC *: 4A546700 F12648E7 F0807400 142E0013 4A3901C1 6072667C 50F901C1 60724A02
01c15f66 :  43f9 01c2 a83c             lea.l $1c2a83c,a1
01c15f6c :  7e16                       moveq.l #$16,d7
01c15f6e :  7000                       moveq.l #$0,d0
01c15f70 :  30c0                       move.w d0,(a0)+
01c15f72 :  32c0                       move.w d0,(a1)+
01c15f74 :  51cf fffa                  dbra d7,$1c15f70
01c15f78 :  4e75                       rts
01c15f7a :  48e7 f080                  movem.l d0-d3/a0,-(a7)
01c15f7e :  7400                       moveq.l #$0,d2
01c15f80 :  342e 0002                  move.w $2(a6),d2
01c15f84 :  6010                       bra.s $1c15f96
01c15f86 : *4a54                       tst.w (a4)
01c15f88 :  6700 f126                  beq $1c150b0
01c15f8c :  48e7 f080                  movem.l d0-d3/a0,-(a7)
01c15f90 :  7400                       moveq.l #$0,d2
01c15f92 :  142e 0013                  move.b $13(a6),d2
01c15f96 :  4a39 01c1 6072             tst.b $1c16072
01c15f9c :  667c                       bne.s $1c1601a
01c15f9e :  50f9 01c1 6072             st.b $1c16072
01c15fa4 :  4a02                       tst.b d2
Name: "Processor Interrupt Level 6"

8bitbubsy · 26 January 2016, 21:41

Oh wow, A4 was not correctly set before calling SpectrumAnalyzer in some parts of the code... Thanks a lot for pointing this out. I fixed it already, please refetch the archive.

EDIT: Forgot the "TOO MUCH" string in Disk Op. - I changed it to "A LOT...".

ReadOnlyCat · 27 January 2016, 04:21

Congratulations for this great effort! This looks like it must have required lots of energy and perseverance so thanks for this investment.

I seem to recall that Photon had published a much optimized version of the ProTracker replay routine some time (year?) ago, do you have any idea whether it should be compatible with the format that your new version outputs?

Also, is the output format documented somewhere? I suspect that the code is the documentation?

8bitbubsy · 27 January 2016, 11:47

Thanks to all for the kind words, it helps me get more motivated!

ReadOnlyCat:
Yeah, Photon has been the main (?) coder on 'The Player 6.x' the last couple of years... With all respect to The Player, I still think that it's too inaccurate in some situations, but I might be crazy about small details. Not sure if it can do 128K samples properly.

PT2.3E's .MOD format is identical to that of PT2.3D and older PT versions. You can find the PT1.x MOD format documentation all over the net.
I haven't changed anything in the format structure, though I have fixed one bug in the module replayer so that sample loop points above the 64K barrier play correctly in the voice handler. This means that if you were to use such loop points on a >64K sample in a PT2.3E/PT3.62 MOD, it will not play correctly in PT1.x/2.x/3.15! PT3.62 had this fixed, so this is not the first PT version to have that replayer difference.

It was sad having to touch the replayer code, but I felt that it was an essential compromise because I've fixed probably all 128K sample bugs in the whole program (non-replayer stuff). Having 128K samples is already possible in the PT MOD format without hacking it: sample loop points and lengths are stored as words (for directly feeding them to the Paula regs I guess), not bytes, so 0xFFFF would result in 0x1FFFE bytes.

daxb · 27 January 2016, 17:02

Unfortunately, the guru is back (this time when quit PT). Maybe some code section alignment?

8bitbubsy · 27 January 2016, 18:06

Sounds like an out of boundary memory read/write then. Maybe sometimes it doesn't guru the system because the data after the allocated memory part is "safe" to use... Does it guru if you just open PT, do nothing, then quit it?

daxb · 27 January 2016, 23:11

Quote:

Originally Posted by 8bitbubsy

Does it guru if you just open PT, do nothing, then quit it?

Yes.

8bitbubsy · 27 January 2016, 23:54

Hmm ok... Anyways I fixed some small bugs today. Also spent hours reconstructing (changing label names and stuff) more of the raw diassembly parts of the PT2.3D code, I hope I didn't introduce any new bugs. The whole code is like 95% re-sourced now or something.

22 January 2016, 17:50	#50
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Hmm still weird, seems to be some incompatibility with VisualPrefs indeed. It's most likely some code in PT that is evil. EDIT: I fixed a major sample loading bug right now that would mess up things in mysterious ways. Last edited by 8bitbubsy; 22 January 2016 at 17:56.

26 January 2016, 21:41	#54
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Oh wow, A4 was not correctly set before calling SpectrumAnalyzer in some parts of the code... Thanks a lot for pointing this out. I fixed it already, please refetch the archive. EDIT: Forgot the "TOO MUCH" string in Disk Op. - I changed it to "A LOT...". Last edited by 8bitbubsy; 26 January 2016 at 22:09.

27 January 2016, 11:47	#56
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Thanks to all for the kind words, it helps me get more motivated! ReadOnlyCat: Yeah, Photon has been the main (?) coder on 'The Player 6.x' the last couple of years... With all respect to The Player, I still think that it's too inaccurate in some situations, but I might be crazy about small details. Not sure if it can do 128K samples properly. PT2.3E's .MOD format is identical to that of PT2.3D and older PT versions. You can find the PT1.x MOD format documentation all over the net. I haven't changed anything in the format structure, though I have fixed one bug in the module replayer so that sample loop points above the 64K barrier play correctly in the voice handler. This means that if you were to use such loop points on a >64K sample in a PT2.3E/PT3.62 MOD, it will not play correctly in PT1.x/2.x/3.15! PT3.62 had this fixed, so this is not the first PT version to have that replayer difference. It was sad having to touch the replayer code, but I felt that it was an essential compromise because I've fixed probably all 128K sample bugs in the whole program (non-replayer stuff). Having 128K samples is already possible in the PT MOD format without hacking it: sample loop points and lengths are stored as words (for directly feeding them to the Paula regs I guess), not bytes, so 0xFFFF would result in 0x1FFFE bytes. Last edited by 8bitbubsy; 27 January 2016 at 12:09.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
a little help on Protracker	pulselooper	Amiga scene	41	05 May 2021 19:34
ProTracker Question.	Overlord	Amiga scene	4	05 May 2018 16:42
Protracker v1.3b	Strages	support.Apps	4	08 December 2013 19:59
Protracker 5?	Whitesnake	request.Music	2	25 March 2012 12:58
Protracker Tutorial	Paradise Decay	Amiga scene	2	16 January 2005 13:15

21 January 2016, 20:44	#42
HanSolo Registered User Join Date: Aug 2014 Location: Gdynia/Poland Posts: 162	Why 2.3 got support ?? Is something wrong with 3.62 ?

22 January 2016, 08:16	#46
TjLaZer Registered User Join Date: Sep 2004 Location: Tacoma, WA USA Age: 52 Posts: 1,915	I tried it on my A1200 with Blizzard 1260 and it would not work. Rebooted and tried again, and it loaded. But then crashed. Any trick to get it working with an 060?

24 January 2016, 03:47	#51
hukka Wolf-bear thing Join Date: Jan 2014 Location: Finland Age: 41 Posts: 56	Major thumbs up for doing this! I didn't yet test all of the new changes, I only did some small tweaks to a tune using the new version, but there was one problem (which I already had with 2.3D, and might not necessarily be a PT bug anyway since this is a somewhat tweaked Workbench (ClassicWB on an Amiga 1200)): I multitask with PT by pressing the key above tab to switch back to Workbench. Whenever I return to PT by clicking the topright button in WB to switch screens, mouse clicks aren't handled properly in PT. All clicks in PT seem to get processed by BOTH ProTracker and Workbench, in that order, and since the mouse cursor is still located on top of the "screen switch" button in Workbench, this means that every left click inside PT now switches me back to Workbench. Keyboard works fine though. Anyway, I would love to have a fix for that, if possible!

24 January 2016, 16:10	#52
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Hmm I can't reproduce that problem. Nonetheless I don't have the knowledge needed to fix it, it's probably related to some 'WB process' routines.

27 January 2016, 04:21	#55
ReadOnlyCat Code Kitten Join Date: Aug 2015 Location: Montreal/Canadia Age: 52 Posts: 1,178	Congratulations for this great effort! This looks like it must have required lots of energy and perseverance so thanks for this investment. I seem to recall that Photon had published a much optimized version of the ProTracker replay routine some time (year?) ago, do you have any idea whether it should be compatible with the format that your new version outputs? Also, is the output format documented somewhere? I suspect that the code is the documentation?

27 January 2016, 17:02	#57
daxb Registered User Join Date: Oct 2009 Location: Germany Posts: 3,303	Unfortunately, the guru is back (this time when quit PT). Maybe some code section alignment?

27 January 2016, 18:06	#58
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Sounds like an out of boundary memory read/write then. Maybe sometimes it doesn't guru the system because the data after the allocated memory part is "safe" to use... Does it guru if you just open PT, do nothing, then quit it?

27 January 2016, 23:54	#60
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,710	Hmm ok... Anyways I fixed some small bugs today. Also spent hours reconstructing (changing label names and stuff) more of the raw diassembly parts of the PT2.3D code, I hope I didn't introduce any new bugs. The whole code is like 95% re-sourced now or something.

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