12 October 2019, 17:54 | #41 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,038
|
Quote:
|
|
12 October 2019, 21:52 | #42 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
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. |
|
13 October 2019, 11:50 | #43 |
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? |
13 October 2019, 12:41 | #44 | |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
Quote:
|
|
13 October 2019, 21:34 | #45 | ||
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
Quote:
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 |
||
04 November 2019, 00:08 | #46 |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
OK, seems I'm having a bit of an "issue" with
Code:
__attribute__((section("tut.MEMF_CHIP"))) 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 }; Copperlist is copied into chipmem via: Code:
UBYTE *clptr = AllocMem(sizeof(copperlist), MEMF_CHIP); CopyMem(copperlist, clptr, sizeof(copperlist)); 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! |
04 November 2019, 00:26 | #47 |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Oh, stop the press.
Looking at the asm output, I've just noticed it's moved Code:
move.b d1,2559 <spr+0x1> 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 00:46. |
04 November 2019, 06:30 | #48 | |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
Quote:
Last edited by deimos; 04 November 2019 at 08:06. |
|
04 November 2019, 10:48 | #49 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,637
|
Quote:
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 11:27. |
|
04 November 2019, 10:54 | #50 | |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
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. |
|
04 November 2019, 11:15 | #51 | |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
That's how I had it originally. |
|
04 November 2019, 13:25 | #52 |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
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. |
04 November 2019, 13:31 | #53 | |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
Quote:
|
|
04 November 2019, 13:37 | #54 |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
(Have you forgotten to commit gcc8_a_support.s?)
|
04 November 2019, 13:46 | #55 |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
|
04 November 2019, 13:51 | #56 |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
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?
|
04 November 2019, 13:54 | #57 |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Nope, that's it. It's tutorial 9 from scoopex YouTube tutorial. Link in comment on top of c file.
|
04 November 2019, 14:04 | #58 |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
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?
Last edited by deimos; 21 November 2021 at 11:31. |
04 November 2019, 14:08 | #59 | |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
Either way, thanks for taking the time to look. |
|
04 November 2019, 14:12 | #60 | |
It's coming back!
Join Date: Jul 2018
Location: comp.sys.amiga
Posts: 762
|
Quote:
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 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 |
|
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 | 342 | 15 December 2023 21:22 |
Visual Studio Code Blitz Basic extension | earok | Coders. Blitz Basic | 29 | 16 July 2019 17:59 |
very basic C/ASM/Visual Studio hand holding | Sephnroth | Coders. C/C++ | 2 | 08 March 2016 20:15 |
Profiling WinUAE with Visual Studio 2013 | mark_k | support.WinUAE | 3 | 14 January 2014 20:26 |
|
|