08 July 2019, 11:20 | #61 |
Registered User
Join Date: Apr 2012
Location: Cardiff
Posts: 407
|
That's incredibly helpful - thanks phx. I'll give it a go and report back...
|
08 July 2019, 20:03 | #62 |
Registered User
Join Date: Apr 2012
Location: Cardiff
Posts: 407
|
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 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’ |
08 July 2019, 20:14 | #63 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 724
|
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) |
08 July 2019, 22:02 | #64 | |
Registered User
Join Date: Apr 2012
Location: Cardiff
Posts: 407
|
Quote:
Code:
extern __far UBYTE mt_Enable; |
|
09 July 2019, 01:42 | #65 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 724
|
You are welcome. I am glad it worked!
|
09 July 2019, 17:52 | #66 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,549
|
Quote:
vasmm68k_mot -Fhunk -DSDATA -o ptplayer.o ptplayer.asm I'm using small data in all of my game projects. |
|
09 July 2019, 23:51 | #67 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
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 |
10 July 2019, 21:48 | #68 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,549
|
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. |
10 July 2019, 22:32 | #69 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
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. |
11 July 2019, 00:01 | #70 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,213
|
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 |
11 July 2019, 01:20 | #71 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
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 |
11 July 2019, 12:09 | #72 |
Registered User
Join Date: Apr 2012
Location: Cardiff
Posts: 407
|
Great explanation. - thanks again phx. I've added this page to my reading list to digest it properly.
|
13 July 2019, 10:30 | #73 |
Registered User
Join Date: Jul 2008
Location: Poland
Posts: 665
|
Possible to add xm support?
Or is there xm player like this ? Last edited by arti; 13 July 2019 at 11:13. |
13 July 2019, 12:17 | #74 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,549
|
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 ).
|
13 July 2019, 17:00 | #75 |
Registered User
Join Date: Jul 2008
Location: Poland
Posts: 665
|
I mean for games for stronger Amigas 060+.
|
13 July 2019, 18:34 | #76 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,549
|
Major enhancements of the player, like XM, are driven by my personal demand. And I have no plans to make games for 060+.
|
13 July 2019, 19:06 | #77 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,310
|
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.
|
13 July 2019, 19:12 | #78 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
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. |
|
13 July 2019, 20:39 | #79 |
Registered User
Join Date: Jul 2008
Location: Poland
Posts: 665
|
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. |
13 July 2019, 23:19 | #80 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,604
|
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?
|
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 |
|
|