English Amiga Board


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

 
 
Thread Tools
Old 08 July 2019, 11:20   #61
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 308
That's incredibly helpful - thanks phx. I'll give it a go and report back...
clebin is online now  
Old 08 July 2019, 20:03   #62
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 308
I'm Using SAS\C at the moment (next time I'll cross-compile...)

ptplayer.asm didn't want to compile with SAS\C's 'asm' assembler - I got loads of errors: "data generation must occur in reloc section"

I compiled it using vasm instead:

Code:
vasmm68k_mot -Fhunk ptplayer.asm
I included that in the makefile and everything compiles and runs ok except for the "mt_Enable = 1" line, which gives me this error:

Code:
_mt_Enable symbol - Near reference to data item not in near data section

  First Reference in Unit main.c at offset 00000010 in file ‘o/main.o’
  To Unit put-layer at offset 00000010 in file ‘o/ptplayer.o’
Am I going about this the right way and is it something I can fix? Sorry if this is a noob question..
clebin is online now  
Old 08 July 2019, 20:14   #63
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 490
Don't have ptplayer.h but I'd assume that mt_Enable is declared there.

Try adding __far keyword right after type and before the name (mt_Enable)
alkis is offline  
Old 08 July 2019, 22:02   #64
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 308
Quote:
Originally Posted by alkis View Post
Don't have ptplayer.h but I'd assume that mt_Enable is declared there.

Try adding __far keyword right after type and before the name (mt_Enable)
Crikey, never heard of near and far pointers before - something else to read up on. I modified the 'ptplayer.h' that comes with PTPlayer to add the __far keyword and the module plays fine:

Code:
extern __far UBYTE mt_Enable;
Thanks for the help!
clebin is online now  
Old 09 July 2019, 01:42   #65
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 490
Quote:
Originally Posted by clebin View Post
Crikey, never heard of near and far pointers before - something else to read up on. I modified the 'ptplayer.h' that comes with PTPlayer to add the __far keyword and the module plays fine:

Code:
extern __far UBYTE mt_Enable;
Thanks for the help!
You are welcome. I am glad it worked!
alkis is offline  
Old 09 July 2019, 17:52   #66
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,378
Quote:
Originally Posted by clebin View Post
Code:
_mt_Enable symbol - Near reference to data item not in near data section
SAS/C defaults to small data? Then you should also use small data for ptplayer.asm. Assemble it with "SDATA" defined:
vasmm68k_mot -Fhunk -DSDATA -o ptplayer.o ptplayer.asm

I'm using small data in all of my game projects.
phx is offline  
Old 09 July 2019, 23:51   #67
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,138
This is widely off-topic (apologies for that!) but could someone point me in the right direction to actually get this whole small data/large data (plus the whole near/far) thing explained in a clear manner?

Because I'm still not sure I understand it or how to use it
roondar is offline  
Old 10 July 2019, 21:48   #68
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,378
Small data means that you are accessing all data in a section via a base register (usually A4). On program startup the base register is loaded with the section's base address + 32766, which enables you to read and write a region of up to 64K.

The advantage is shorter code, less relocations in the executable and faster data access (hmm, perhaps not on 68040).

You can always make your own kind of small data, by defining some memory region which you access via any base register. For example with the BASEREG directive or just an RS-structure. But here I am talking about the standard method, how all Amiga compilers are doing it and which makes sense to adapt in your assembler code as well.

Small data also means in most cases that you will use a Data-Bss section for it, i.e. a data section which has a greater size defined in the executables's header than it actually has. The extra size is allocated as uninitialized (Kick 1.x) or cleared (V36+) memory, doesn't occupy any space in the executable and is used for the BSS part. For Kickstart 1.x you should better clear this area during startup.

The linker supports small data in several ways. It will automatically merge small data sections and makes sure that all initialized small data sections come first and then all uninitialized ones (allowing Data-Bss in the output). Small data sections are either detected by the appropriate relocations or references to it, or by name. Sections named as __MERGED will be automatically merged as Data-Bss sections.

The linker also defines useful linker-symbols which help you to set up small data in the startup code. For example _LinkerDB always points to the small data section's base + 32766. Small data relocs are resolved with this value in mind. With __BSSBAS and __BSSLEN you can clear the unitialized part of that section.

The C-attribute __far can be used to enforce absolute 32-bit access to data, even when your program was compiled in small data mode. Also worth mentioning is the __saveds attribute in this context, because it sets up the base register for the function with it (and saves/restores the previous contents). Useful for interrupt handlers, callback-functions, etc., which are called from a not-small-data-aware context.

In assembler you have even more options and your code can be small and large data at the same time. Put all your small objects into the small data section and all large objects into other sections. Then these 64K will always be sufficient.

I'm using small data in all my assembler projects and most C projects.
phx is offline  
Old 10 July 2019, 22:32   #69
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,138
Thanks for the explanation!

I'll read it carefully a few more times. Seems it's a clever way to get the advantages of PC relative code without needing to actually code 'PC relative' (though register relative is kind of the same thing). Moving the offset so far ahead also allows for 64K, which is pretty neat.

I might consider it for new projects, just to see how it works. In my experience trying stuff is always the best way to get to grips with it. As is, I try to write almost all code as PC relative as I can make it, so it shouldn't be that much of a change.
roondar is offline  
Old 11 July 2019, 00:01   #70
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 386
Very similar to how I used to do it in the 1990's with my games... A6 would always point to $dff000 and A5 would point to my variables.. so every var was accessed off A5

I like that +32766 idea though to give a full 64k range
DanScott is offline  
Old 11 July 2019, 01:20   #71
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,782
You can also see some compiler that use Hunk reloc for a real full 64k (32768*2 ).

Like:
Code:
	SECTION code,code
	lea	DT,A4
	lea	-$8000(a4),a0	; buffer


	SECTION small_data,data
buffer	ds.b 32768
DT	ds.b 32768
ross is offline  
Old 11 July 2019, 12:09   #72
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 308
Great explanation. - thanks again phx. I've added this page to my reading list to digest it properly.
clebin is online now  
Old 13 July 2019, 10:30   #73
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 545
Possible to add xm support?

Or is there xm player like this ?

Last edited by arti; 13 July 2019 at 11:13.
arti is offline  
Old 13 July 2019, 12:17   #74
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,378
Implementing XM-support on the Amiga is quite CPU-intensive. As ptplayer is primarily intended for games this makes no sense at all (unless you're doing a text-adventure ).
phx is offline  
Old 13 July 2019, 17:00   #75
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 545
I mean for games for stronger Amigas 060+.
arti is offline  
Old 13 July 2019, 18:34   #76
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,378
Major enhancements of the player, like XM, are driven by my personal demand. And I have no plans to make games for 060+.
phx is offline  
Old 13 July 2019, 19:06   #77
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,288
XM and any other formats that are multi channel is at the end "only" mixed by CPU to a stereo stream. So I think a XM player would be much different to phx's player (uses the default Amiga 4 hardware channels as far as I know. no mixing). How difficult it is to mix the music stream (xm for example) with sound fx samples I don't know. At least there is no need for the technique that phx used to "mix" music with sound fx samples. So, my guess is that for such a 060+ multichannel player you need some else if exists.
daxb is offline  
Old 13 July 2019, 19:12   #78
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,138
Quote:
Originally Posted by daxb View Post
XM and any other formats that are multi channel is at the end "only" mixed by CPU to a stereo stream. So I think a XM player would be much different to phx's player (uses the default Amiga 4 hardware channels as far as I know. no mixing). How difficult it is to mix the music stream (xm for example) with sound fx samples I don't know. At least there is no need for the technique that phx used to "mix" music with sound fx samples. So, my guess is that for such a 060+ multichannel player you need some else if exists.
Seems one does indeed exist (XM player that is): http://aminet.net/package/dev/asm/xmplay-lib

However, there's just something about 4 channel Protracker modules... I've always found them quite nice (assuming they're properly made). Some of them sound really good, so maybe XM playback is not quite needed.

Anyway, PHX's player is pretty awesome by itself. I can highly recommend using it: I found it easy to integrate in my code and it works really well. Not found a module it doesn't play yet.
roondar is offline  
Old 13 July 2019, 20:39   #79
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 545
That thing is f*cking slow even on WinUAE. I don't know how author used this.

I have found ten times faster C player, just need it a bit more optimised for my needs.

Last edited by arti; 13 July 2019 at 20:47.
arti is offline  
Old 13 July 2019, 23:19   #80
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,005
One thing i miss on mod that i have in xm is indipendent timeline volume; so maybe a cut down version of the xm player for four-channel only XM to play directly in paula might give more control?
saimon69 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
MOD-player with external sound effects phx Coders. Asm / Hardware 14 18 June 2012 10:41
Amiga Forever&Protracker bad sound moriez support.WinUAE 14 06 January 2009 01:26
What was the first Amiga tracker to support external midi instruments Kola Amiga scene 3 09 December 2008 19:20
Sound/Protracker package Dunny request.Apps 3 23 July 2008 19:17
Sampled sound player? cdoty Coders. General 7 25 August 2007 16:21

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 22:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09271 seconds with 16 queries