Compiling Protracker woes

Amiga1992 · 01 September 2012, 20:44

OK you will have to excuse my noobness here, but I am trying to compile Protracker as found on these sources:
http://www.pouet.net/prod.php?which=13414

And all I get are errors. There are some file include errors that i understand, probably need to relocate some files, but there are other errors I don't, like:

Code:

Error: bit number should be 0-7 for byte at line 14996 in file PT2.0.asm
14996 02.0000CBF4 0839000B00DFF01E             BTST    #11›33;7m,›0m$DFF01E ;intreqr
Error: bit number should be 0-7 for byte at line 16976 in file PT2.0.asm
16976 02.0000E50A 0839000E00DFF002     blitrdy BTST    #14›33;7m,›0m$DFF002 ; DMACONR
Error: absolute expression MUST evaluate at line 19031 in file PT2.0.asm
19031 03.00000000                      TopMenusPos     EQU     BitPlaneData+55›33;7m ›0m
Error: absolute expression MUST evaluate at line 19032 in file PT2.0.asm
19032 03.00000000                      SpectrumAnaPos  EQU     BitPlaneData+1815›33;7m 
›0mError: absolute expression MUST evaluate at line 19033 in file PT2.0.asm
19033 03.00000000                      FormatBoxPos    EQU     BitPlaneData+2090›33;7m 
›0mError: absolute expression MUST evaluate at line 19034 in file PT2.0.asm
19034 03.00000000                      SureBoxPos      EQU     BitPlaneData+2100›33;7m 
›0mError: absolute expression MUST evaluate at line 19035 in file PT2.0.asm
19035 03.00000000                      SamScrPos       EQU     BitPlaneData+4880›33;7m 
›0mError: absolute expression MUST evaluate at line 19036 in file PT2.0.asm
19036 03.00000000                      VolBoxPos       EQU     BitPlaneData+6209›33;7m

Now, I didn't touch a SINGLE line of code here, I just loaded into Devpac 3 2.0 and hit "check" or "assemble".

Did anybody ever compile ProTracker and knows what the hell I am doing wrong? We are making some modifications to teh source with a friend, but if this doesn't compile as it comes defacto, we're not getting anywhere.

Somewhere on Internet was suggested that I should compile with Devpac 2, but this makes absolutely no practical sense. Should I be using ASMPro or something?

Thanks!

hitchhikr · 01 September 2012, 20:53

Remove those ›33;7m and ›0m

Amiga1992 · 01 September 2012, 21:17

Hmm I am not getting any of that now, I managed to compile version 1.2 on Devpac 2 but version 2.0 is still giving me errors like this:

Code:

Error: bit number should be 0-7 for byte at line 14996 in file PT2.0.asm
14996 02.0000CBF4 0839000B00DFF01E             BTST    #11,$DFF01E ;intreqr
Error: bit number should be 0-7 for byte at line 16976 in file PT2.0.asm
16976 02.0000E50A 0839000E00DFF002     blitrdy BTST    #14,$DFF002 ; DMACONR
Error: absolute expression MUST evaluate at line 19031 in file PT2.0.asm
19031 03.00005008                      TopMenusPos     EQU     BitPlaneData+55 
Error: absolute expression MUST evaluate at line 19032 in file PT2.0.asm
19032 03.00005008                      SpectrumAnaPos  EQU     BitPlaneData+1815 
Error: absolute expression MUST evaluate at line 19033 in file PT2.0.asm
19033 03.00005008                      FormatBoxPos    EQU     BitPlaneData+2090 
Error: absolute expression MUST evaluate at line 19034 in file PT2.0.asm
19034 03.00005008                      SureBoxPos      EQU     BitPlaneData+2100 
Error: absolute expression MUST evaluate at line 19035 in file PT2.0.asm
19035 03.00005008                      SamScrPos       EQU     BitPlaneData+4880 
Error: absolute expression MUST evaluate at line 19036 in file PT2.0.asm
19036 03.00005008                      VolBoxPos       EQU     BitPlaneData+6209

This doesnt have those funky characters which I dont know where they came from, I think from my text editor on the PC when I tried to paste here.

pmc · 01 September 2012, 21:40

The problem you have with those errors is that (for non data register destinations) btst tests the bits of byte values so any number above 7 will give an error.

So, to solve it - do this: add a -8 to any numbers above 7 and all will be OK.

For example, change:

Code:

                    btst                #11,$dff01e

to:

Code:

                    btst                #11-8,$dff01e

and the code will work as intended and assemble correctly

Also, add this to the top of the code:

Code:

	opt	nocase

to turn off case sensitivity which will most likely fix those equ errors and make the non-evaluating expressions evaluate

PS: You assemble assembly code, you don't compile it - sorry, just couldn't resist

Amiga1992 · 01 September 2012, 22:09

pmc: thanks for your help, you rock! And don't worry, you are right, the software even says "assemble"

I will see where this leads. We're making some super useful modifications to ProTracker. Well, I am just giving the ideas, my friend is checking out the code, I am a useless bastard when it comes to assembler xD But I can modify the graphics so it looks nice

pmc · 01 September 2012, 22:14

Nah, no worries man - you're more than welcome

And I'll look forward to your PT-deluxe too

Amiga1992 · 01 September 2012, 22:18

It's not deluxe, rather, more apt for live performance.
I gathered a lot of input on how to do it when making this video:
[ Show youtube player ]

And we are really happy to work on this and put it out when it's ready, specially if we work out the more complex ideas I have

pmc · 01 September 2012, 22:21

Watching that vid now - whoahhh - that's f*cking cool

Amiga1992 · 01 September 2012, 23:58

It would be better if I didn't trainwreck so much, and thanks to my friends modifications, I think I will make it better soon. Who needs Technics 1200s?

Amiga1992 · 02 September 2012, 04:32

Another thing: the source comes with a bunch of files in RAW format, like the font. How can I edit those? I tried to look for a converter to IFF to no avail.

pmc · 02 September 2012, 09:02

RAW data is just graphics data with no other formatting information included.

You'll need to look at the code that manipulates those graphics which will give you some clues about how tall, wide and deep the graphics data is.

Basically look at the code and make educated guesses. It can be done - I've done it myself several times to extract RAW graphics back into a usable format.

Amiga1992 · 02 September 2012, 13:31

Hmm but dpaint wouldn't read the raw data, neither would grafx2. Any clues? Is there any program that can inject an IFF header to this after i found out the values? I'm tired of that font :P modifying the graphics is complicated enough as it is but it's working fine so far and the default font just makes things ugly!

pmc · 02 September 2012, 13:50

No, an IFF paint program like DPaint won't read that data directly.

You could potentially load the RAW data into something like Kefrens IFF converter but you would need to supply the height, width and bitplane depths yourself to then get the data to display correctly before you could save the graphics out again.

Like I say, working out the height, width and depth to use for RAW data requires looking at the code and some educated guessing.

There's a chance I could have a go at getting the font data out and into a usable form - I'd be happy to have a look if you want to send the raw font data to me on email or something. Can't promise I'll be successful obviously.

Amiga1992 · 02 September 2012, 13:51

Well I found where it's including the raw data, but after that there's a "FontSize" variable and it says:

Code:

=*- FontData
cnop 0,2

I don't think this is what I am looking for.
I really appreciate the help! But it's probably best if I learn myself to do this, don't you agree?

What do you think I should be looking for? Any specific instruction or something?

One more question! Do you think doing an INCBIN for IFF instead of RAW data would work or will there be a problem? I don't see the reason of using RAW data at all. Version 2.0 also has some PAK data that I do not understand at all. According to docs, RLE encoded, so I guess I can't mess with them, which makes this much less fun.

pmc · 02 September 2012, 14:12

That fontsize variable is calculating the size of the font as a whole by getting the assembler to do a calculation like this:

end_of_font minus start_of_font equals size of the font in bytes

That's a good start cos using that variable you know the size of the font as a whole. You could probably then have a guess at the height (in lines) and width (in pixels) of the font characters and then you'd have a rough idea how many characters of that size would fit into a font of x bytes size.

Amiga1992 · 02 September 2012, 14:20

So I am on the right track! I realized this instruction is applied to all RAW data that the software loads too.

So that equals the size of the file? It's an 8x8 font according to the comments.
I'm not really sure about how to guess how that is distributed horizontally and vertically though. Should I assume it uses as max width 320 pixels? And how many bytes does one pixel weight? I am not sure if this is using 2 colors or 4 as everything else (that should give me number of bitplanes, right?)

I am really impressed at me being able to figure shit out on my own, I already have made some modifications to the code on my own without my friends'help and am starting to understand how assembler works, before this I never have touched a line of assembler in my life. Your help is greatly appreciated on this, I am really happy to be learning this.

pmc · 02 September 2012, 14:35

Heh heh - good stuff

8x8 is most likely I would've thought, yes.

Look for anywhere in the code where font or fontsize is used and then it should be pretty straightforward to find the routine that draws font characters onto the screen. In that routine will be the numbers needed to work out height and width of the font bitmap.

Look for things like:

Code:

                    lea                 font,ax

or

Code:

                    move.l              #font,ax

where, obviously, x = 0 to 6

daxb · 02 September 2012, 18:02

You might have a look into PT4 source archive. There are some gfx (raw and iff) from different pt versions.

Copy/paste link so don`t know if it still work: http://www.silent-dreams.de/arc/pt4src.lzh

Amiga1992 · 02 September 2012, 18:14

Well the version I am modifying has most of the screens available in IFF and it includes them from that. But still it is importing RAWs for other bits like the font, and I don't think I can go and just replace the include for an IFF file.

Also, PT4 is quite different, UI wise, to PT1.x/2.x

Amiga1992 · 03 September 2012, 01:41

Alright, I am having some issues reading keys.
I am trying to make some keys do some stuff on the interface.
Problem is this: first I tried using the "-_" and "+=" keys, and while -_ worked fine, += needed LSHIFT to be recognized.

Now we changed it to use [ and ], and same problem again, both are only registering if I press LSHIFT and not on their own.

What is the logic behind this? I really don't get it. I am using the keycodes provided by the Reference Manual, but the same manual does not say how to work with shifted/non shifted keys (or I didn't understand it).

01 September 2012, 21:40	#4
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	The problem you have with those errors is that (for non data register destinations) btst tests the bits of byte values so any number above 7 will give an error. So, to solve it - do this: add a -8 to any numbers above 7 and all will be OK. For example, change: Code: btst #11,$dff01e to: Code: btst #11-8,$dff01e and the code will work as intended and assemble correctly Also, add this to the top of the code: Code: opt nocase to turn off case sensitivity which will most likely fix those equ errors and make the non-evaluating expressions evaluate PS: You assemble assembly code, you don't compile it - sorry, just couldn't resist

02 September 2012, 14:35	#17
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Heh heh - good stuff 8x8 is most likely I would've thought, yes. Look for anywhere in the code where font or fontsize is used and then it should be pretty straightforward to find the routine that draws font characters onto the screen. In that routine will be the numbers needed to work out height and width of the font bitmap. Look for things like: Code: lea font,ax or Code: move.l #font,ax where, obviously, x = 0 to 6

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Compiling WinUAE 2.1.0	rotacak	support.WinUAE	8	06 May 2010 17:09
Help compiling winuaesrc1530	AAG	support.WinUAE	2	08 January 2009 11:45
Compiling 1.3.4	rotacak	support.WinUAE	70	22 January 2007 08:13
Compiling WinUAE 1.3.2	rotacak	support.WinUAE	1	06 October 2006 20:34
Slowly compiling	stainy	Nostalgia & memories	4	10 September 2002 01:28

01 September 2012, 20:53	#2
hitchhikr Registered User Join Date: Jun 2008 Location: somewhere else Posts: 511	Remove those ›33;7m and ›0m

01 September 2012, 22:09	#5
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	pmc: thanks for your help, you rock! And don't worry, you are right, the software even says "assemble" I will see where this leads. We're making some super useful modifications to ProTracker. Well, I am just giving the ideas, my friend is checking out the code, I am a useless bastard when it comes to assembler xD But I can modify the graphics so it looks nice

01 September 2012, 22:14	#6
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Nah, no worries man - you're more than welcome And I'll look forward to your PT-deluxe too

01 September 2012, 22:18	#7
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	It's not deluxe, rather, more apt for live performance. I gathered a lot of input on how to do it when making this video: [ Show youtube player ] And we are really happy to work on this and put it out when it's ready, specially if we work out the more complex ideas I have

01 September 2012, 22:21	#8
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Watching that vid now - whoahhh - that's f*cking cool

01 September 2012, 23:58	#9
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	It would be better if I didn't trainwreck so much, and thanks to my friends modifications, I think I will make it better soon. Who needs Technics 1200s?

02 September 2012, 04:32	#10
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	Another thing: the source comes with a bunch of files in RAW format, like the font. How can I edit those? I tried to look for a converter to IFF to no avail.

02 September 2012, 09:02	#11
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	RAW data is just graphics data with no other formatting information included. You'll need to look at the code that manipulates those graphics which will give you some clues about how tall, wide and deep the graphics data is. Basically look at the code and make educated guesses. It can be done - I've done it myself several times to extract RAW graphics back into a usable format.

02 September 2012, 13:31	#12
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	Hmm but dpaint wouldn't read the raw data, neither would grafx2. Any clues? Is there any program that can inject an IFF header to this after i found out the values? I'm tired of that font :P modifying the graphics is complicated enough as it is but it's working fine so far and the default font just makes things ugly!

02 September 2012, 13:50	#13
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	No, an IFF paint program like DPaint won't read that data directly. You could potentially load the RAW data into something like Kefrens IFF converter but you would need to supply the height, width and bitplane depths yourself to then get the data to display correctly before you could save the graphics out again. Like I say, working out the height, width and depth to use for RAW data requires looking at the code and some educated guessing. There's a chance I could have a go at getting the font data out and into a usable form - I'd be happy to have a look if you want to send the raw font data to me on email or something. Can't promise I'll be successful obviously.

02 September 2012, 13:51	#14
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	Well I found where it's including the raw data, but after that there's a "FontSize" variable and it says: Code: =- FontData cnop 0,2 I don't think this is what I am looking for. I really appreciate the help! But it's probably best if I learn myself to do this, don't you agree? What do you think I should be looking for? Any specific instruction or something? One more question! Do you think doing an INCBIN for IFF instead of RAW data would work or will there be a problem? I don't see the reason of using RAW data at all. Version 2.0 also has some PAK data that I do not understand at all. According to docs, RLE encoded, so I guess I can't mess with them, which makes this much less fun. Last edited by Amiga1992; 02 September 2012 at 14:11.*

02 September 2012, 14:12	#15
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	That fontsize variable is calculating the size of the font as a whole by getting the assembler to do a calculation like this: end_of_font minus start_of_font equals size of the font in bytes That's a good start cos using that variable you know the size of the font as a whole. You could probably then have a guess at the height (in lines) and width (in pixels) of the font characters and then you'd have a rough idea how many characters of that size would fit into a font of x bytes size.

02 September 2012, 14:20	#16
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	So I am on the right track! I realized this instruction is applied to all RAW data that the software loads too. So that equals the size of the file? It's an 8x8 font according to the comments. I'm not really sure about how to guess how that is distributed horizontally and vertically though. Should I assume it uses as max width 320 pixels? And how many bytes does one pixel weight? I am not sure if this is using 2 colors or 4 as everything else (that should give me number of bitplanes, right?) I am really impressed at me being able to figure shit out on my own, I already have made some modifications to the code on my own without my friends'help and am starting to understand how assembler works, before this I never have touched a line of assembler in my life. Your help is greatly appreciated on this, I am really happy to be learning this.

02 September 2012, 18:02	#18
daxb Registered User Join Date: Oct 2009 Location: Germany Posts: 3,303	You might have a look into PT4 source archive. There are some gfx (raw and iff) from different pt versions. Copy/paste link so don`t know if it still work: http://www.silent-dreams.de/arc/pt4src.lzh

02 September 2012, 18:14	#19
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	Well the version I am modifying has most of the screens available in IFF and it includes them from that. But still it is importing RAWs for other bits like the font, and I don't think I can go and just replace the include for an IFF file. Also, PT4 is quite different, UI wise, to PT1.x/2.x

03 September 2012, 01:41	#20
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	Alright, I am having some issues reading keys. I am trying to make some keys do some stuff on the interface. Problem is this: first I tried using the "-_" and "+=" keys, and while -_ worked fine, += needed LSHIFT to be recognized. Now we changed it to use [ and ], and same problem again, both are only registering if I press LSHIFT and not on their own. What is the logic behind this? I really don't get it. I am using the keycodes provided by the Reference Manual, but the same manual does not say how to work with shifted/non shifted keys (or I didn't understand it).

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