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:
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:
3. I might have misunderstood how the debugging prints worked, I tried adding this code in the main loop of the example:
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!
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:
Code:
INCBIN(tunnelData,"data/tunnel.bpl")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!
etc.
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.
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.
Same problem with the Incbin here..
Hi,
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"
I don't think there's currently a way to force data into chipmem. We just allocated memory via
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.
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.
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...
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...
...and while I am at the "Stuff I can't quite figure out why..." phase, I get the following error in the OUTPUT console:
Not sure what that is, everything seems to work anyway, so it's just a minor annoyance!
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!
Don't know if this still works but try it. For the chip ram issue.
http://cahirwpz.users.sourceforge.net/gcc-amigaos/chip.html
http://cahirwpz.users.sourceforge.net/gcc-amigaos/chip.html
Have you installed the C/C++ extension?
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.
On the bright side elf2hunk will happily place sections in chip if their name ends in .MEMF_CHIP, so doing
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
Code:
will place bar in chip mem.__attribute__((section("foo.MEMF_CHIP"))) UBYTE bar[] = {1,2,3,5};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.
No worries, I'm not in a hurry.
And thanks for the very neat toolchain. :)
And thanks for the very neat toolchain. :)