01 September 2012, 20:44 | #1 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,645
|
Compiling Protracker woes
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! Last edited by Amiga1992; 01 September 2012 at 21:20. |
01 September 2012, 20:53 | #2 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 511
|
Remove those ›33;7m and ›0m
|
01 September 2012, 21:17 | #3 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,645
|
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 |
01 September 2012, 21:40 | #4 |
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 Code:
btst #11-8,$dff01e Also, add this to the top of the code: Code:
opt nocase PS: You assemble assembly code, you don't compile it - sorry, just couldn't resist |
01 September 2012, 22:09 | #5 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 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 |
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 |
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, 14:35 | #17 |
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 Code:
move.l #font,ax |
02 September 2012, 18:02 | #18 |
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 |
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 |
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) | |
Thread Tools | |
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 |
|
|