Amiga GCC 8.3+gdb extension for Visual Studio Code

[Don_Adan]

Originally Posted by deimos

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]

Originally Posted by Spec-Chum

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

__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]

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]

Originally Posted by Martin Piper

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]

Originally Posted by Martin Piper

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?

Originally Posted by deimos

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]

OK, seems I'm having a bit of an "issue" with

__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:

__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:

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]

Oh, stop the press.

Looking at the asm output, I've just noticed it's moved

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]

Originally Posted by Spec-Chum

OK, seems I'm having a bit of an "issue" with

__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]

Originally Posted by Spec-Chum

Oh, stop the press.

Looking at the asm output, I've just noticed it's moved

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]

Originally Posted by deimos

Could you attach tut9.c? And your makefile?

Originally Posted by hooverphonique

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]

Originally Posted by hooverphonique

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]

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]

Originally Posted by Spec-Chum

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]

(Have you forgotten to commit gcc8_a_support.s?)

[Spec-Chum]

Originally Posted by deimos

(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]

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]

Originally Posted by deimos

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]

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]

Originally Posted by deimos

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]

Originally Posted by Spec-Chum

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:

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:

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.