ADFS BeebEm 4.14 Weirdness...

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
The Welder
Posts: 1
Joined: Sun May 27, 2018 9:08 pm

ADFS BeebEm 4.14 Weirdness...

Post by The Welder » Mon May 28, 2018 8:49 pm

I'm writing some code on BeebEm 4.14 and I'm experiencing some issues with ADFS. This might be emulator issues or it could be my brain forgetting how to do stuff, since it's been years since I was coding games on this machine.

Anyway, consider the following piece of code...

Code: Select all

50LDA#8B:LDX#1:LDY#0:JSR&FFF4					\\ Equivalent to *OPT1,0
60LDA#&80:LDX#fname MOD256:LDY#fname DIV256:JSR&FFCE		\\ OSFIND, open file for writing
70LDA#65:JMP&FFEE						\\ Write letter A to screen
80.fname EQUS"Hello":EQUB&D
Now this code is simple, right? It performs a *OPT1,0 which suppresses filing system messages and then tries to open a file for writing. However, here's the weird behaviour that I'm seeing...

If the disk is write protected and the file doesn't exist, then the code just bombs out at the filing system call. It is supposed to give you a 0 in A so you can at least react to the error or perform an OSWORD &73 to get some error information. But you've got no chance of checking for an error, you just end up with a "Disc protected" and you never reach the OSWRCH call.

However, if the disk is write protected and the files DOES exist, then the OSFIND call succeeds and you end up with a channel number in A. If you run the program again, you get a "Can't - File open".

So what's going on here? Here's what I think... When you call it on a non-existent file (ADFS searches its internal memory to determine if the file already exists and if it cannot be found), ADFS tries to create it by writing to the disc itself. Thus you get a "Disc protected". If the file *IS* present in ADFS's internal memory, then it doesn't try to access the disk, it just assumes the file can be opened for writing and returns a channel for it. Only when you try to write to the file, or more likely, close it and it gets flushed to disc will it actually give you a "Disc protected" error. In either respect, your code is still going to bomb out to Basic or whatever is the active language ROM.

Does anyone know how to prevent this? Is there any way to detect ahead of time whether an ADFS disc is write protected or not? I can't find any OSWORD call that will give me this kind of information. What are my options for determining if a disk is write protected (Read then try to write a sector with OSWORD&72)? Open/Close/Delete a file? I thought *OPT1,0 would prevent a filing system exiting the code like this, but it seems to have NO effect on ADFS and probably only works for CFS. Failing that, could I trap this error through the BRK vector?

Post Reply