vscode-amiga-debug - some questions

category: code [glöplog]
So, after watching the Evoke seminar about "vscode-amiga-debug" and being very impressed with it, I decided to ditch my old VBCC Amiga dev-toolchain and go for this new and fancy one, with superior debugging, more optimized code generated etc. etc.

Getting the simple example up and running was a breeze, but once I moved on from that, I keep running into some issues that I can quite figure out.

I've looked for contact info for Bartman/Abyss who is the guy behind it, but haven't been able to find any, so I turn to Pouet in the hope that maybe someone knows how to solve it, or perhaps he even spots the question himself.

My problems so far:
1. I can't get INCBIN to work. According to an example in the comments section here on Pouet, the following should work:

But the compiler complains:
Code: > Executing task: c:\Users\andr\.vscode\extensions\bartman-abyss.amiga-debug-0.7.1\bin\gnumake.exe -f Makefile8mingw -j4 < Compiling main.c In file included from C:/prg/Amiga/VisualStudio/gametest/main.c:1: C:/prg/Amiga/VisualStudio/gametest /support/gcc8_c_support.h:11:31: error: expected ')' before 'INCBIN_STR' ".global incbin_" INCBIN_STR(name) "_start\n" \ ^~~~~~~~~~ C:/prg/Amiga/VisualStudio/gametest/main.c:11:1: note: in expansion of macro 'INCBIN' INCBIN(tunnelData,"data/tunnel.bpl") ^~~~~~ C:/prg/Amiga/VisualStudio/gametest/support/gcc8_c_support.h:10:12: note: to match this '(' __asm__(".pushsection .rodata\n" \ ^ C:/prg/Amiga/VisualStudio/gametest/main.c:11:1: note: in expansion of macro 'INCBIN' INCBIN(tunnelData,"data/tunnel.bpl") ^~~~~~

2. Is there a way to tell the compiler that a certain variable needs to be in chip RAM? In VBCC you could simply do:
Code: __chip unsigned short copperlist[8192];

3. I might have misunderstood how the debugging prints worked, I tried adding this code in the main loop of the example:
Code: while(!MouseLeft()) { WaitVbl(); hw->color[0] = bgcolor; KPrintF("Hello debugger from Amiga %04x!\n",bgcolor); }

My expectation was that the debugger would print the ever increasing number of the bgcolor as the program was running, but instead I got:
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
Hello debugger from Amiga 0000!
added on the 2019-09-16 19:00:02 by Sdw Sdw
Oh, one more question:
4. According to the documentation "all necessary options are already configured for Amiga 500, Kickstart 1.3 (for debugging), if you want to change some things (resolution, window size, etc.) just go into the Configurations tab, select default, and hit Save"

I tried this (needed to test run some stuff with more than 512kb chip mem, so I upped that) but it doesn't seem to do anything to replace the default config, I select it and hit save, but the next time starting, chip mem is back at 512kb.
added on the 2019-09-17 21:43:44 by Sdw Sdw
Same problem with the Incbin here..
added on the 2019-09-18 17:48:06 by Virgill Virgill
thanks for using my little extension ;)

If you post your issues on the GitHub, I will get notified.
Thanks to Virgill for paging me ;)

Sorry, the INCBIN macro was broken. I uploaded a new release to GitHub.
Update the extension and use the new "gcc8_c_support.h" file.

Alternatively, insert these 2 lines before the "#define INCBIN"
Code:#define INCBIN_STR2(x) #x #define INCBIN_STR(x) INCBIN_STR2(x)

I don't think there's currently a way to force data into chipmem. We just allocated memory via
Code:UBYTE* pnkAllocChip(u32 size) { u32* mem=AllocMem(size+4,MEMF_CHIP); if (mem) { *mem++=size+4; return (UBYTE*)mem; } else return 0; } UBYTE* pnkAllocFast(u32 size) { u32* mem=AllocMem(size+4,MEMF_FAST); if (!mem) return pnkAllocChip(size); if (mem) { *mem++=size+4; return (UBYTE*)mem; } else return 0; } void pnkFreeMem(void *_mem) { if (!_mem) return; u32* mem=(u32*)_mem; mem--; u32 size=*mem; FreeMem(mem,size); }

3. There's some "fine details" with KPrintF. Basically, with "%04x" you're telling the underlying RawDoFmt function to print a WORD, however standard C's vararg says to always extend integer types to 32-bit (LONG), so using "%04lx" should work.

4. Unfortunately, memory isn't something that can be changed in the WinUAE config, because the vscode-extension always sets Quickstart to A500 KS1.3, 512k-Chip + 512k-Fast.
added on the 2019-09-18 21:35:35 by bartman bartman
Thank you for the answers (and the extension itself) Bartman!

I always have a hard time determining what to post as issues on GitHub, I tend to interpret that as more of a space for "This is a bug I found" not "I am too stupid to figure out how something works, please help"! :) So perhaps item #1 would have been something that actually *should* have been an issue.

Anyway, issue 1 and 3 have been answered and resolved nicely, thanks!

Regarding the chip RAM-thing of question 2, allocating would probably work fine for dynamic usage stuff (for example a copper list), but I was thinking what about static data in the .exe that you for example INCBIN?
I mean, if I have some picture data that I want to include directly in the executable, I want to make sure it ends up in chipmem, otherwise I'd have to allocate the same amount of memory again (but this time be certain that it is chip) and copy it over there, but that would waste memory, especially if it turns out that the original location was chipmem after all.
It might be me that is a bit off on how loading an Amiga exe works though...
added on the 2019-09-18 23:31:11 by Sdw Sdw
...and while I am at the "Stuff I can't quite figure out why..." phase, I get the following error in the OUTPUT console:
Code: Error: the description can't be converted into a problem matcher: { "base": "$gcc", "fileLocation": "absolute" }

Not sure what that is, everything seems to work anyway, so it's just a minor annoyance!
added on the 2019-09-18 23:35:34 by Sdw Sdw
Don't know if this still works but try it. For the chip ram issue.

added on the 2019-09-19 01:40:12 by Cefa Cefa
Have you installed the C/C++ extension?
added on the 2019-09-21 23:59:37 by bartman bartman
Yeah, I guess the chipmem thing would be nice, currently it‘s not supported. If 8 have time, I‘lol have a look if I can support it.
added on the 2019-09-22 00:02:58 by bartman bartman
On the bright side elf2hunk will happily place sections in chip if their name ends in .MEMF_CHIP, so doing
Code:__attribute__((section("foo.MEMF_CHIP"))) UBYTE bar[] = {1,2,3,5};
will place bar in chip mem.

However, I'm too much of a gcc noob to (so far) be able to use that to make an INCBIN_C macro. Simply changing the .pushsection in the INCBIN macro to any other name than .rodata makes elf2hunk fail. I guess this might be the result of some mystic linker settings I have no clue about. :-D
yeah, that's about right. unfortunately I don't have a setup right here to rebuild elf2hunk, so I can't help you right now.
added on the 2019-10-01 23:19:58 by bartman bartman
No worries, I'm not in a hurry.
And thanks for the very neat toolchain. :)