All my number entry is in decimal(sorry I'm a dinosaur who counts in base 10) and when it loads it works plus the other screens non Hex work and I admit I wasn't aware of the Hex only rule.
Thanks for input from Martin too.
Will redo screens using Hex and report back.
I didn't mean use hex when you're typing definitions; that won't affect the problem you're having. What I meant is that the screens are stored as files and the numeric part of the filenames is in hex. So, if you were having problems with screen 10 (decimal) then the filename for that screen would be scr0a.f
For corrupted screens it would be useful for me to see the appropriate files.
The manner of the corruption lead me to concur with you that it could be a spand problem as the one I set aside for Forth use is a 5 year old issue 1 and have noticed occasional graphical glitches with this one before.
So I cleared the decks and installed a fresh copy of FIF 102 on an issue 3 and re-entered every screen I had created up to press.
They all saved as expected and when re-loaded compiled to the letter and worked well.
I then deliberately made errors in the listings (e.g) S->D became S->G MOD became MUD etc etc and pleased to say each error was flagged up correctly whereas before it was just ? with no reference to the fault.
So I corrected the screens and when saved all reloaded and compiled correctly.
I can only surmise that during the save procedure my older spand was playing up and causing the unwanted corruption.
The P and I type words I am aware of and use the FORTH DEFINITION as needed so no worries there.
I also am a fairly fast with a keyboard and thanks to your rapid keyboard routine can type full pelt though sometimes trip over myself, wondering why my pendulum frequency routine was showing errors when it finally clicked that 724. isn't 274.
In conclusion Alan it would seem a dodgy spand is the culprit and apologies if I caused you any worries and my grateful thanks to you and Martin also for his input.
Thanks again for time and trouble taken.
I'll do some testing on real hardware tomorrow and see whether I get any problems.
As I said earlier in the thread there can be some oddities with ZXpand. I've got over a dozen 2GB SD cards. Most of them are used unbranded ones and they all work fine. However the two good quality ones I have (Kingston & Sandisk) both fail to be recognised by my ZXpand+ CAT. You'd have thought it might be the other way round. There does seem to be an element of pot luck. Nevertheless I'm quite prepared to believe there might be a bug in the editor or FIF interaction with ZXpand too. I'll eyeball the code for a while longer (all I can do as I can't reproduce the problem).
The fact that you've been successful with a different spand suggests there's nothing outrageously wrong with eithrr FIF or what you're doing.
I've had a mammoth session session today knocking the source code into shape for release. Almost there. It won't be perfect but it ought to be clear enough. I'll continue the tidying at a more leisurely pace after it's released (and after the laughter has subsided)
This original way of working with Forth is truly delightful and is really testing the old grey matter.
Hmmm. That's no zero, that's an $F8 character. I can't see that kind of character at that kind of position arising from the non-ZXpand parts of FIF doing the corrupting. It looks far more like a problem with data being corrupted during saving to the ZXpand. That would be consistent with why it's not observed using EO or another emulator (I assume that the corrupt file happened on real hardware? Please let me know or I may be on a wild goose chase).
It doesn't look like a quick fix. I'll study the ZXpand write code and, if I can't see anything obvious, I'll see about rewriting that part using just API calls. If it still shows problems then it may be a job for Charlie.
Yes real kit with issue three spand. I have three spand+ but not too fond of using them for any length of time till I get a regulated 7.5v supply for them.
Try using a normal power pack and very carefully stick your finger on the 5 and 3 volt regs that are side by side on the back of the spand or the single reg at the back on the spand+ issue 5.1 after a ten minutes or so, hot doesn't describe it all due to the voltage they are having to sink and I'm not fond of chips that small running that hot close together so it will be the classic one for the time being. 7.5 v supplies do alleviate the problem thankfully.
What Im doing for the time being is keeping copies of screens that are ok and should one corrupt when I add to them I can swap the screen out using ZXpand commander like I have done for this one, seems to work ok.
When you cannot see the anomaly in the listing it's hard to know what to redo so easier to revert to good backup.
It'd enable you to edit the screen files and, if you see an anomaly, fix it. I'd also be interested to see a few other corrupted files if they arise. You don't really need to use hex within it as it handles character input in the window the shows the decoded text.