#3171 [z80][PC-88] Issue with frame ptr/stack (new chain)

[Benton Ferguson]

Hello,

I am building out an API for working with the PC-8x using SDCC (the z88dk toolchain leaves much to be desired).

I am working on the graphics code, but I get stuck here and there when calling functions outside of main.
Initially I thought it was the frame pointer - --fno-frame-pointer will fix the issue to a certain extent, but not always.

Detail:
frame pointer on, draw bitmap only

frame pointer off, draw bitmap only

frame pointer off, draw bitmap and draw single pixel
(corrupts stack)

frame poniter off, only draw single pixel (works)

frame pointer on doesn't corrupt stack, but it also doesn't address anything properly.
It may be something to do with near/far poniters, since code/data crosses page boundaries, but the code seems to work!

RAM is paged accessed by writing any byte to $5d-$5f.

NOTE:
Keeping it in main() allows it to all work properly. It seems to be an issue with calling functions.

My thread on info:
https://twitter.com/RetroDevDiscord/status/1351876840089149440

Full repo here:
https://github.com/bferguson3/pc88-c

Sources:
http://mydocuments.g2.xrea.com/
http://www.maroon.dti.ne.jp/youkan/pc88/iomap.html

[Benton Ferguson]

Using SDCC 4.0.0

[sverx]

can you try compiling with --no-peep option to see if this is the same as #3173 that I just filed?

If is so, that option will make the code work.

[Philipp Klaus Krause]

Also check with [r12035] if the fix for #3173 also fixes this issue.

[Benton Ferguson]

Thanks for the reply.

I discovered the issue is variable (specifically pointer location) assignment outside of main(). Is this related?

[Benton Ferguson]

Thank you for the reply.
I discovered the issue, which was unrelated to what I thought - performing assignment on a variable outside of a function.
e.g.

volatile unsigned char* ptr = 0xc000;

void main() {
     while(1) { } 
}

will reproduce this issue.

I tried your recommendation which did not fix it, but I can obviously work around this for now.

[Philipp Klaus Krause]

I don't see a problem when compiling that code. Maybe the problem is in some other part of your toolchain? Currently initalization of global variables is done in the crt0.

o you use a custom crt0? If yes, what does the asm code of that look like? Which comman d line do you use to link your program?

[Benton Ferguson]

Philipp,

Sorry, I meant to specify specifically on my PC-88 chain. The code will compile fine, but for whatever reason the stack/frame pointer doesn't like it calling too many functions within main after a global assignment like that above main() will corrupt the stack - probably bc of what you said.

Init of globals in crt0 would be the issue, then, I might have assumed it was something like that. I do have to use a custom crt0, called IPL.BIN. It performs the same basic function, setting up registers for the environment/screen and sets the stack pointer, then loads from disk to RAM and executes.

I use a custom tool to "link" after compiling main.c due to the hardware. (Right now everything compiled is included within main.c). The first sector of a floppy disk is the auto-boot sector, so crt0-ish code goes there (ipl.bin). This loads n sectors from the disk and jumps to $1000.

I assemble it using ASW due to my unfamiliarity with SDCC.

I have "remedied" the issue as described in the ticket, so it's okay to close this. But if anyone is interested and can take a deeper look at my code to help me figure out the global initialization problem I would appreciate it.

Thanks

[Benton Ferguson]

Hey guys,

Updating to 4.0.7 fixed the rest of the issues I was having. This can be closed.
Thanks!