English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. C/C++ (http://eab.abime.net/forumdisplay.php?f=118)
-   -   Amiga GCC 8.3+gdb extension for Visual Studio Code (http://eab.abime.net/showthread.php?t=98525)

Don_Adan 12 October 2019 18:54

Quote:

Originally Posted by deimos (Post 1350742)
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.

bebbo 12 October 2019 22:52

Quote:

Originally Posted by Spec-Chum (Post 1350725)
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.

Martin Piper 13 October 2019 12:50

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?

deimos 13 October 2019 13:41

Quote:

Originally Posted by Martin Piper (Post 1350911)
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.

Spec-Chum 13 October 2019 22:34

Quote:

Originally Posted by Martin Piper (Post 1350911)
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 (Post 1350920)
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 04 November 2019 01:08

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 04 November 2019 01:26

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

deimos 04 November 2019 07:30

Quote:

Originally Posted by Spec-Chum (Post 1356377)
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?

hooverphonique 04 November 2019 11:48

Quote:

Originally Posted by Spec-Chum (Post 1356384)
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).

Spec-Chum 04 November 2019 11:54

Quote:

Originally Posted by deimos (Post 1356402)
Could you attach tut9.c? And your makefile?

Quote:

Originally Posted by hooverphonique (Post 1356429)
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 04 November 2019 12:15

Quote:

Originally Posted by hooverphonique (Post 1356429)
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 04 November 2019 14:25

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.

deimos 04 November 2019 14:31

Quote:

Originally Posted by Spec-Chum (Post 1356430)
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 04 November 2019 14:37

(Have you forgotten to commit gcc8_a_support.s?)

Spec-Chum 04 November 2019 14:46

Quote:

Originally Posted by deimos (Post 1356470)
(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.

deimos 04 November 2019 14:51

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?

Spec-Chum 04 November 2019 14:54

Quote:

Originally Posted by deimos (Post 1356475)
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.

deimos 04 November 2019 15:04

1 Attachment(s)
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?

Spec-Chum 04 November 2019 15:08

Quote:

Originally Posted by deimos (Post 1356480)
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.

deimos 04 November 2019 15:12

Quote:

Originally Posted by Spec-Chum (Post 1356482)
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.


All times are GMT +2. The time now is 18:00.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04920 seconds with 11 queries