English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 12 October 2019, 18:54   #41
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,156
Quote:
Originally Posted by deimos View Post
I don't believe you can because the elf format has no concept of chip ram. At the moment I'm just using a CopyToChipMem function that allocates chip memory and copies data over. Not ideal. I think the only way round this would be to rework the link step so that your chip memory data can be done as amiga hunks, possibly from assembler, but I'm not sure it's possible without losing too many of the advantages this environment gives. There's another thread that talks about possible approaches somewhere. I've just decided to not worry about it until I have too much chip memory data to hold two copies of.
You can edit Amiga exe file header and manually change from $00 to $40 bytes(s) for necessary chip hunks. Easy enough, if you know Amiga exe file formats.
Don_Adan is offline  
Old 12 October 2019, 22:52   #42
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 427
Quote:
Originally Posted by Spec-Chum View Post
Awesome work.

Had a quick play and converted my asm takeover code to C and it worked

One snag, however, I couldn't figure out how to put the copperlist array into chip mem? I tried
Code:
__chip
but it didn't work. Using attributes didn't work either as it just says they're disabled.

Any idea how to specify something needs to be in chip mem?


...

you need a compiler/tool-chain which supports different data segments with chip/fast attributes aka Amiga hunk files



With elf you have to use workarounds.
bebbo is offline  
Old 13 October 2019, 12:50   #43
Martin Piper
Registered User

 
Join Date: Oct 2019
Location: Singapore
Posts: 2
Looking at the source for elf2hunk https://github.com/BartmanAbyss/vsco...nk.c#L841-L842

It seems to look at the section for .MEMF_CHIP

So some experimentation there might help?
Martin Piper is offline  
Old 13 October 2019, 13:41   #44
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Quote:
Originally Posted by Martin Piper View Post
Looking at the source for elf2hunk https://github.com/BartmanAbyss/vsco...nk.c#L841-L842

It seems to look at the section for .MEMF_CHIP

So some experimentation there might help?
Well spotted. Googling along those lines got me to this page, http://www.pouet.net/topic.php?which=11781 , at the bottom of which is an example of how to do this.
deimos is offline  
Old 13 October 2019, 22:34   #45
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by Martin Piper View Post
Looking at the source for elf2hunk https://github.com/BartmanAbyss/vsco...nk.c#L841-L842

It seems to look at the section for .MEMF_CHIP

So some experimentation there might help?
Quote:
Originally Posted by deimos View Post
Well spotted. Googling along those lines got me to this page, http://www.pouet.net/topic.php?which=11781 , at the bottom of which is an example of how to do this.
Cool, worked, thanks for getting to the bottom of that one

Oddly enough, I found that thread on Pouet but didn't read it all after Bartman said he didn't believe it was possible lol
Spec-Chum is offline  
Old 04 November 2019, 01:08   #46
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
OK, seems I'm having a bit of an "issue" with
Code:
__attribute__((section("tut.MEMF_CHIP")))
On some occasions it seems to set the section as read-only as I can't update data in it, whereas on other occasions it works fine.

It's weird.

Example from tut9.c:
Code:
__attribute__((section("tut.MEMF_CHIP"))) UWORD spr[] =
{
	0x2c40, 0x3c00, // Vstart.b,Hstart/2.b,Vstop.b,%A0000SEH

	0b0000011111000000, 0b0000000000000000,
	0b0001111111110000, 0b0000000000000000,
	0b0011111111111000, 0b0000000000000000,
	0b0111111111111100, 0b0000000000000000,
	0b0110011111001100, 0b0001100000110000,
	0b1110011111001110, 0b0001100000110000,
	0b1111111111111110, 0b0000000000000000,
	0b1111111111111110, 0b0000000000000000,
	0b1111111111111110, 0b0010000000001000,
	0b1111111111111110, 0b0001100000110000,
	0b0111111111111100, 0b0000011111000000,
	0b0111111111111100, 0b0000000000000000,
	0b0011111111111000, 0b0000000000000000,
	0b0001111111110000, 0b0000000000000000,
	0b0000011111000000, 0b0000000000000000,
	0b0000000000000000, 0b0000000000000000,

	0, 0
};

__attribute__((section("tut.MEMF_CHIP"))) UWORD nullSpr[] =
{
	0x2a20, 0x2b00,
	0, 0,
	0, 0
};

/*	__attribute__((section("tut.MEMF_CHIP")))	
	seems to set the section as readonly	*/
UWORD copperlist[] =
{
	CMOVE(FMODE, 0),			// set FMODE to slow for AGA
	CMOVE(BPLCON0, 0x0200),		// no bitplanes, but need color burst

	CMOVE(DIWSTRT, 0x2c81),
	CMOVE(DIWSTOP, 0x2cc1),

	CMOVE(DDFSTRT, 0x38),
	CMOVE(DDFSTOP, 0xd0),

	CMOVE(BPL1MOD, 0),
	CMOVE(BPL2MOD, 0),

	CMOVE(BPLCON1, 0),

	CMOVE(COLOR17, 0xe22),
	CMOVE(COLOR18, 0xff0),
	CMOVE(COLOR19, 0xfff),

//SprP:
	CMOVE(SPR0PTH, 0),
	CMOVE(SPR0PTL, 0),
        
	CMOVE(SPR1PTH, 0),
	CMOVE(SPR1PTL, 0),
        
	CMOVE(SPR2PTH, 0),
	CMOVE(SPR2PTL, 0),
        
	CMOVE(SPR3PTH, 0),
	CMOVE(SPR3PTL, 0),
        
	CMOVE(SPR4PTH, 0),
	CMOVE(SPR4PTL, 0),
        
	CMOVE(SPR5PTH, 0),
	CMOVE(SPR5PTL, 0),
        
	CMOVE(SPR6PTH, 0),
	CMOVE(SPR6PTL, 0),
        
	CMOVE(SPR7PTH, 0),
	CMOVE(SPR7PTL, 0),

//CopBpLP:
	CMOVE(BPL1PTH, SCREEN >> 16),
	CMOVE(BPL1PTL, SCREEN & 0xffff),

	CMOVE(COLOR00,0x349),

	CWAIT(0x2b07,0xfffe),
	CMOVE(COLOR00,0x56c),

	CWAIT(0x2c07,0xfffe),	
	CMOVE(COLOR00,0x113),

	CMOVE(BPLCON0,0x1200),
	CMOVE(COLOR01,0x349),		// pixel colour

// waitras1:
	CWAIT(0x8007, 0xfffe),
	CMOVE(COLOR00, 0x055),

// waitras2:
	CWAIT(0x8107, 0xfffe),
	CMOVE(COLOR00, 0x0aa),

// waitras3:
	CWAIT(0x8207, 0xfffe),
	CMOVE(COLOR00, 0x0ff),

// waitras4:
	CWAIT(0x8307, 0xfffe),
	CMOVE(COLOR00, 0x0aa),

// waitras5:
	CWAIT(0x8407, 0xfffe),
	CMOVE(COLOR00, 0x055),

// waitras6:
	CWAIT(0x8507, 0xfffe),
	CMOVE(COLOR00, 0x113),

	CWAIT(0xffdf, 0xfffe),
	CWAIT(0x2c07, 0xfffe),
	CMOVE(COLOR00, 0x56c),

	CWAIT(0x2d07, 0xfffe),
	CMOVE(COLOR00, 0x349),

	CEND		
};
As it stands, the code above works, I can update copperlist[] and spr[] from my code, all good.

Copperlist is copied into chipmem via:
Code:
UBYTE *clptr = AllocMem(sizeof(copperlist), MEMF_CHIP);
	CopyMem(copperlist, clptr, sizeof(copperlist));
However, if I then set copperlist to attribute chipmem as well, I can still update copperlist[] but can't update the spr[], which I could before.

Any idea what's going on?

Obviously I may not have explained this too well, so please ask away any questions to clarify anything.

TIA!
Spec-Chum is offline  
Old 04 November 2019, 01:26   #47
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Oh, stop the press.

Looking at the asm output, I've just noticed it's moved
Code:
move.b d1,2559 <spr+0x1>
outside of the loop, so it's never executed.

Will investigate more...

EDIT: moving the code to another place in the loop didn't help, the move.b is still outside.

EDIT2: changed from -ofast to -O2 - code has changed a bit but the move.b for the sprite pos now middle of nowehere lol, it's actually now before the loop (?!)

EDIT3: Ah, success, of sorts. -O1 works, sprite now moves but rest of code is...shall we say, more complex, now. It's certainly turned loads of optimisations off.

EDIT4: Actually, I take that back, the code isn't that bad, it's just in a completely different order than -Ofast

Last edited by Spec-Chum; 04 November 2019 at 01:46.
Spec-Chum is offline  
Old 04 November 2019, 07:30   #48
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Quote:
Originally Posted by Spec-Chum View Post
OK, seems I'm having a bit of an "issue" with
Code:
__attribute__((section("tut.MEMF_CHIP")))
On some occasions it seems to set the section as read-only as I can't update data in it, whereas on other occasions it works fine.

...

Any idea what's going on?

Obviously I may not have explained this too well, so please ask away any questions to clarify anything.

TIA!
Could you attach tut9.c? And your makefile?

Last edited by deimos; 04 November 2019 at 09:06.
deimos is offline  
Old 04 November 2019, 11:48   #49
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 988
Quote:
Originally Posted by Spec-Chum View Post
Oh, stop the press.

Looking at the asm output, I've just noticed it's moved
Code:
move.b d1,2559 <spr+0x1>
outside of the loop, so it's never executed.

Is <spr+0x1> something fetched by dma? Then it has to be volatile in order for the compiler to understand that it may be read by "something else" (in this case dma, but could be another task, interrupt, a hardware register, etc).

Last edited by hooverphonique; 04 November 2019 at 12:27.
hooverphonique is offline  
Old 04 November 2019, 11:54   #50
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by deimos View Post
Could you attach tut9.c? And your makefile?
Quote:
Originally Posted by hooverphonique View Post
Is <spr+0x1> something fetched by dma? Then it has to be volatile in order for the compiler to understand that it may read by "something else" (in this case dma, but could be another task, interrupt, a hardware register, etc).
https://github.com/spec-chum/Amiga-S...ee/master/tut9

Thanks both, files on github. Sorry for brief reply, site blocked at work so I'm on phone.

I tried volatile and that didn't help.

-O1 does work, the move is put into the loop, but - O2 and above doesn't.
Spec-Chum is offline  
Old 04 November 2019, 12:15   #51
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by hooverphonique View Post
Is <spr+0x1> something fetched by dma? Then it has to be volatile in order for the compiler to understand that it may read by "something else" (in this case dma, but could be another task, interrupt, a hardware register, etc).
Plus, if I allocate copperlist via AllocMem instead, which doesn't touch spr[] at all, the code works.

That's how I had it originally.
Spec-Chum is offline  
Old 04 November 2019, 14:25   #52
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Just thought.

I mentioned I've tried setting the spr array to volatile and it didn't work, but I'm literally casting away the volatile when increasing the sprites position!

Something to try tonight when I get home.
Spec-Chum is offline  
Old 04 November 2019, 14:31   #53
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Quote:
Originally Posted by Spec-Chum View Post
https://github.com/spec-chum/Amiga-S...ee/master/tut9

Thanks both, files on github. Sorry for brief reply, site blocked at work so I'm on phone.

I tried volatile and that didn't help.

-O1 does work, the move is put into the loop, but - O2 and above doesn't.
You might want to check that -fwhole-program flag. particularly as the documentation says that -flto and -fwhole-program should not be used together. Probably won't help, but an easy check to do.
deimos is offline  
Old 04 November 2019, 14:37   #54
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
(Have you forgotten to commit gcc8_a_support.s?)
deimos is offline  
Old 04 November 2019, 14:46   #55
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by deimos View Post
(Have you forgotten to commit gcc8_a_support.s?)
Not on purpose, but that gets created by the extension when you init the (empty) folder.

All the files in support and .vscode do.
Spec-Chum is offline  
Old 04 November 2019, 14:51   #56
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Ok, dumb question time: What is the code supposed to do? I get a red smiley face moving across the top of the screen and a bouncing horizontal line. Is there more to it?
deimos is offline  
Old 04 November 2019, 14:54   #57
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by deimos View Post
Ok, dumb question time: What is the code supposed to do? I get a red smiley face moving across the top of the screen and a bounding horizontal line. Is there more to it?
Nope, that's it. It's tutorial 9 from scoopex YouTube tutorial. Link in comment on top of c file.
Spec-Chum is offline  
Old 04 November 2019, 15:04   #58
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Anyway, I've attached a screenshot of what I see when I run your code. I can't see anything that makes me think that it's not doing what is intended?
Attached Thumbnails
Click image for larger version

Name:	like-this.png
Views:	21
Size:	22.6 KB
ID:	65089  
deimos is offline  
Old 04 November 2019, 15:08   #59
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 85
Quote:
Originally Posted by deimos View Post
Anyway, I've attached a screenshot of what I see when I run your code. I can't see anything that makes me think that it's not doing what is intended?
I pushed the makefile with -O1, did you try this with -O2 or -Ofast at all?

Either way, thanks for taking the time to look.
Spec-Chum is offline  
Old 04 November 2019, 15:12   #60
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 440
Quote:
Originally Posted by Spec-Chum View Post
I pushed the makefile with -O1, did you try this with -O2 or -Ofast at all?

Either way, thanks for taking the time to look.
I've not touched anything yet, so my makefile looks like:

Code:
CCFLAGS = -g -MP -MMD -m68000 -O1 -nostdlib -Wall -Wno-pointer-sign -Wno-unused-function -Wno-volatile-register-var -Wno-discarded-qualifiers -fomit-frame-pointer -fno-tree-loop-distribution -flto -fwhole-program
I will try to change that and hopefully reproduce your problem.

EDIT:

Yes, problem confirmed with the default of:

Code:
CCFLAGS = -g -MP -MMD -m68000 -Ofast -nostdlib -Wall -Wno-pointer-sign -Wno-unused-function -Wno-volatile-register-var -Wno-discarded-qualifiers -fomit-frame-pointer -fno-tree-loop-distribution -flto -fwhole-program
The sprite doesn't move.
deimos 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
Amiga Assembly extension for Visual Studio Code prb28 Coders. Asm / Hardware 147 16 November 2019 21:52
Visual Studio Code Blitz Basic extension earok Coders. Blitz Basic 29 16 July 2019 18:59
very basic C/ASM/Visual Studio hand holding Sephnroth Coders. C/C++ 2 08 March 2016 21:15
Profiling WinUAE with Visual Studio 2013 mark_k support.WinUAE 3 14 January 2014 21:26

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 15:20.


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