OSFILE corrupting variables

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
Andrewcee
Posts: 51
Joined: Thu Sep 21, 2017 4:27 pm
Location: Swindon
Contact:

OSFILE corrupting variables

Post by Andrewcee » Sun Feb 11, 2018 2:08 pm

Hi folk, Has anyone any experience of 'losing' vars (strings and ints) after a call to OSFILE from Basic with A%=5, get file attributes on a Beeb B? - Running Basic4 with 65C02, OS1.2.

I can print all vars before the call okay, they apparently gone after CALL &FFDD. Checked memory parameter block, everything is there okay, file name address (file name in said address, eg. :0.X.ABC) and file adress info post the call - but Basic looks to have its / some of its vars?

Thanks,
Andrew

User avatar
hoglet
Posts: 7113
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: OSFILE corrupting variables

Post by hoglet » Sun Feb 11, 2018 2:55 pm

Which file system ROM are you using?

Andrewcee
Posts: 51
Joined: Thu Sep 21, 2017 4:27 pm
Location: Swindon
Contact:

Re: OSFILE corrupting variables

Post by Andrewcee » Sun Feb 11, 2018 3:12 pm

I switch between Solidisk DFS2.1J, Solidisk ADFS, DataCenter RamFS (still to try), and SPI sdcard DFS - using SPI to test just now.

The card fsys roms and DFS are, I believe, all seen by the Beeb as DFS filing systems hence the need to 'switch'. I am currently trying to copy on a single fsys thus no switch involved. I've have even had my code running on the Pi Co-Pro before starting to use zero page vectors to keep track of things, will try the co-pro once I've everything working on the I/O processor. This is a new problem, for whatever reason something has changed, not that I can find it! I can see my vars from Basic the line before the osfile call, they are gone the line immediately after.

User avatar
BeebMaster
Posts: 2537
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: OSFILE corrupting variables

Post by BeebMaster » Sun Feb 11, 2018 3:17 pm

I think make sure X% and Y% correctly point to the parameter block, and that the result block is correctly pointed to in the parameter block, and make sure enough space is reserved for the result block. Use DIM to reserve space rather than using any fixed memory location. Sometimes I find that OS calls overflow the result block, and I can't always fathom the reason why, but it has the effect of overwriting any variables declared after the DIM for the OS call space. When that happens I usually reserve some space straight after the result block, so DIM results 32, morespace 256.

Also make sure you aren't using LOCAL variables in any function or procedure, as they will revert to global values, or not exist at all, outside the FN/PROC.
Image

User avatar
hoglet
Posts: 7113
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: OSFILE corrupting variables

Post by hoglet » Sun Feb 11, 2018 3:21 pm

You might have to post more of your code if you want someone to be able to help.

Andrewcee
Posts: 51
Joined: Thu Sep 21, 2017 4:27 pm
Location: Swindon
Contact:

Re: OSFILE corrupting variables

Post by Andrewcee » Sun Feb 11, 2018 4:06 pm

Confirmed X%, Y% pointing to parameter block correctly. Result block for file attribute get (A%=5) is I believe the parameter block itself, although first two bytes vector the address of the filename (ending with CR) also confirmed okay. Am using DIMs to reserve memory, although will try with few more bytes than in theory needed, and will DIM a 'dummy' immediately after the OSFILE parameter block for good measure - thanks!

Have found Proc local vars problematic in my application even when the var is not used outside the proc, hence replaced with globals all defined at start of code, and filled with appropriate number & string constants, dummy vars, to ensure Basic reserves memory upfront.

Feels like some sort of memory type issue as I've never before 'lost' variables in anything I've done, even a complex Basic/Assembler prom programmer I built 30 odd years ago - and recently got working again. Could always write the procedure in m/c code #-o

Thanks for the suggestions - I've noticed a few people asking for help moving files between different fsys, thought I'd look at what others have done and write my own. Happy to post once I've it working okay.

Will post code, keeps giving Invalid File Extension error when selecting from 'add files' button.

Andrewcee
Posts: 51
Joined: Thu Sep 21, 2017 4:27 pm
Location: Swindon
Contact:

Re: OSFILE corrupting variables

Post by Andrewcee » Sun Feb 11, 2018 4:20 pm

Mr BeebMaster, Sir - You're a star!

OSFILE call block requires 12 bytes, I had DIM block% &10 - no, no, no >>> DIM block% &11 is the minimum required. As always, operator error. Interestingly enough, I have noticed the odd rogue character appearing in my code (presumably this is one such example) for no obvious reason. Nothing to do with my code I hasten to add, something my aging machine is doing to keep me on my toes.

Sorted - something stupid on my part. Thanks for your advice, much appreciated. Will post the finished programme for anyone who wants to try it once I've it finished and working.

Andrew

Post Reply