Who is wrong, CALSLT or me?

بواسطة konamiman

Paragon (1190)

صورة konamiman

04-12-2010, 22:30

I have been stuck for several days in the development of the Denyonet TCP/IP BIOS due to a bug that I was not able to trace. I was testing one of my applications and I found that while it worked fine with InterNestor, with Denyonet it hanged the computer as soon as some TCP data was received.

Finally I discovered the cause. It was not the fault of the Denyonet BIOS, but of the application. The problem is that the Denyonet UNAPI entry point, which is on page 1, is invoked via a call to CALSLT, and the code that does the CALSLT call is on page 1 as well. As soon as I moved this code to page 2, everything works fine.

This is probably caused by a bug in my code (altough I can't find it no matter how carefully I inspect it), but anyway I wanted to ask: is there any rule that forbids invoking CALSLT from a certain page in order to execute code in another slot but in the same page? Something special about page 1? I couldn't find anything like this on MSX2 Technical Handbook.

By the way, the application is made with SDCC. It can be as well that the compiler is doing something that I don't expect when compiling...

Login أوregister لوضع تعليقاتك

بواسطة flyguille

Prophet (3031)

صورة flyguille

04-12-2010, 22:39

CALSLT , first selects the your page & page 3 (c000 ffff) with the slot that you are aiming to call, then it writes $FFFF for selecting the subslot in that slot), then it restore PAGE3 to original slot/sslot, then it do the call, IF you are calling PAGE 0 (0000 to 3ffff), it use a relocatable code in page 3 or so, to do the switching of page0 , page0 must HAVE the CALSLT code if you want to return? mmmm

IIRC, both BIOS-BASIC and EXT BASIC ROM, has doubled the CALSLOT and WRSLOT and RDSLOT code....

بواسطة Leo

Paragon (1236)

صورة Leo

04-12-2010, 22:50

so the problem is in page 1 or 0 ?

بواسطة RetroTechie

Paragon (1563)

صورة RetroTechie

05-12-2010, 00:03

is there any rule that forbids invoking CALSLT from a certain page in order to execute code in another slot but in the same page?
Not that I know of, but there is another variable: the stack. It should not be in the page that's called since that page gets switched out. Obviously page 3 may get switched as well to access secondary slot register(s), I think the ROM routines are smart enough to do that part using page 0 code. And use small helper routine(s) in page 3 for the case where call goes to page 0 (like flyguille said).

So: no chance your app (or your compiler) has relocated the stack? For example reserved space right after application code, or a temporary stack switch used for making BIOS calls? If that stack is in page 1 when calling CALSLT, things will crash. I guess I can only say: check your compiler output at Z80 code level & fire up debugger to see what exactly happens...

بواسطة flyguille

Prophet (3031)

صورة flyguille

05-12-2010, 00:28

I forgive, as a rule, IT IS SOOOO SLOW!!!!!!

try to measure how many CALLs you can do, to CALL just a RET instruction......

don't use this call in timming sensitive functions

بواسطة konamiman

Paragon (1190)

صورة konamiman

13-12-2010, 12:53

Sorry for being so silent, had a burst of real life recently Smile

@RetroTechie: I don't explicitly change the stack pointer, but since it is a C application I was not sure of what the compiled code would do, so I inserted some traces and saw that the stack never seems to go outside of page 3.

@flyguille: Using CALSLT for TCP/IP UNAPI calls seems to work fine in terms of speed. But it is good to know that it is a slow routine.