We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm trying to use the _init_boxh() function but the function always fails. When I look into the assembler code I noticed that the _init_boxh() routine is not support. 64Ksegment length huge pointers, but using the 16Ksegment far memory model instead when it is testing the memory space: // example, calling function: // use 0x1000 block at 0x11F000 _init_boxh(0x11F000,0x1000,0x100) MOV R11,#0x0100 MOV R10,#0x1000 MOV R8,#0xF000 MOV R9,#0x0011 CALLS _init_boxh(0x2B7E8) (0x2B7E8): _init_boxh() routine: MOV R4,#0x00 ADD R11,#1 AND R11,#0xFFFE JMPR CC_Z,0x02B828 ADD R10,R8 => NOT VALID in 64Kspace => cc lost!! MOV R6,R8 MOV R5,R8 ADD R6,#6 SUB R10,R11 JMPR CC_C,0x02B828 => exits here because R10 < R11
It appears that there is indeed a problem with this library routine when the size + base_offset = 0x??0000. We are working on a solution that will be included in the next release. For the mean time, you should avoid placing the block so that it is located at the end of a 64K page. Jon
Mike, thanx for the solution: allocating the pool size with (size + 1) as a work around. Jon, the chance of having POOL_SIZE + OFFSET = 0x??0000 is quite high since static memory allocation order is top to bottom. Thanx for the quick response.