GPART: Fix for issue where IX and IY are not returned to caller

[vipoo]

Hi,

I stumbled on something that I am not 100% sure i fully understand.

I was trying to use the GPART function, and noticed that the, sector count, was not being returned in the IX:IY register, within my application. After much digging and barely understandings, i think i found the cause.

I noticed that the other functions that return values in the index registers, use FUNC_WITH_IXIY code. This function walks the stacks and replaces the stored IX, IY registers - expecting a certain stack depth. I thought that GPART just needed to be mapped in the same way. Alas, not quite, as the stack depth for when I call the GPART function is different (IX and IY are the first items after the return address).

So i made a similar block of code, especially for GPART, and my application now get the right value.

I also understand that GPART is currently used with the embedded fdisk code in the kernel . I am not sure if I have screwed that up - would not be surprised. Your insights would be welcomed.

Cheers
Dean

[Konamiman]

Hi, thanks for your contribution and sorry for not having answered before.

How are you calling GPART? If you are using the standard function call entry point at address 5 (which I guess is the case because your patch is for NEXTOR.SYS) then using FUNC_WITH_IX_IY should be enough. I don't get what's the problem for you not being able to use it.

Also don't worry about FDISK, it's invoked from BASIC and thus it doesn't use the address 5 entry point at all (it uses F37Dh instead).

[vipoo]

Hi

Thanks for reply -- I have to admit I cant fully recall all the details of this issue - its been a little while.

My specific builds are perhaps a little different that standard MSX configurations.

I use Nextor on my RC2014 based kit computer and to help others who build the kits, I wanted a bootable rom image that will work for as many people as possible - with as few dependencies as possible. I also wanted the image to be based on CBIOS, so that my distribution of the code does not breach any copyrights.

Because its based on CBIOS, where there is no basic interpreter in the image, the FDISK utility would not work. So I ported your code to be a standard MSX-DOS utility. Users can run the app from the embedded disk-less ROM image that I include. Enabling them to partition a Compact Flash module quite nicely.

And in porting the fdisk utility, I hit this issue. I cant quite remember all the details, but I do recall that calling GPART from a msxdos application would cause the system to crash, due to stack corruption.... With the changes in the PR, the application then worked.

Cheers
Dean

[Konamiman]

I have tested myself and indeed, it's a bug that happens when calling the function via CALL 5 but not when using CALL 0F37Dh.

However, as I suspected your change can be replaced with just this:

@GPART:
	call	FUNC_WITH_IXIY
	ret

(the CALL is needed because I'm POPing the return address in FUNC_WITH_IXIY)

If you implement this change I'll be happy to merge the pull request.

[vipoo]

Cool --- I will do so as soon as possible.

[Konamiman]

Hi, I'm closing this one, I implemented the fix in a separate pull request: #89 - I'll credit you in the release description.

[vipoo]

Hi,

Sorry - I had forgotten about this - I blame the usual adult distractions -- like needing to empty the bins...

Thanks
Dean