Re: [cc65] CBM POSIX I/O - USR Files

On 2010-03-30, at 10:16, Oliver Schmidt wrote:

> If I understands things right then this is something I did all the
> time without thinking about it:
> 
> - Using C1541 to write files to a .D64 image (without giving the type
> thus writing PRG)
> - Using cc65 POSIX I/O to read those files (without setting _filetype
> thus reading USR)

I think setting _filetype is important on creating/writing the file. As the posted previously test code showed, it is not needed on reading. Therefore using cc65 I/O you create USR by default, which is IMHO quite understandable. If you read, you read it just by name, which (having in mind that only Groepaz' DOS allows duplicate names :-) is also very much fine.

> 
> <flame> That sort of reminds me on Windows saving upper/lowercase
> filenames but reading them without caring about the case </flame>
> 

There is more filesystems, which are not case sensitive. Under OSX you can choose whether you want the filesystem to be case sensitive or not for example.

[...]

>> [...]
>> More or less ;-) The difference is that you have to specify that you want to load USR file. Otherwise you get FILE TYPE MISMATCH error. Other than that - the same (AFAIR).
> 
> I tried that yesterday evening using VICE 1.21 on Win32 and could
> _not_ reproduce that error. I saved a file using C1541 using ",u" and
> verified that it showed up as USR. Then I entered
> 
> LOAD "MYFILE", 8
> 
> and experienced the same behaviour with a PRG file of the same conent:
> The system prints READY but I don't get a prompt anymore. I understand
> thios behaviour as the file in question doesn't have a valid load
> address in the first two bytes.

I was writing off my head but you forced me to set my gear up and test it. Seems that I didn't lie ;-) Things behave as I described (with standard DOS and KERNAL).

Do you have "True drive emulation" turned on? This is crucial if you want to check things out. Also current version of VICE is 2.2! 1.2 is quite... outdated to say the least. I can imagine that it may behave somewhat differently than the current version. Grab the latest version, turn "true drive emulation" on and then check things out.

>>> 
>>> And what about LOAD,* ? Does it load the first PRG file or load the
>>> first <whatever> file?
>> 
>> Depends. It either loads the most recently accessed file or - if you are freshly initialised - the first PRG file.
>> To make sure you actually load the very first file, you put a colon before the asterisk. But then the file must be PRG or you get the familiar (already) error, unless you specify the type.
> 
> Again I was _not_ able to reproduce that. Putting an USR file first on
> .D64 image and using the 'Autostart image' feature of VICE (which
> prints 'LOAD "*,8,1') the system was obviously trying to load the
> (bogus) USR file instead of a (valid) PRG file being the second in the
> image.

Again - I double verified that now - works as described. Do you have "True drive emulation" turned on? This is crucial if you want to check things out.

> I'd be happy if I could really understand these things for a reason
> beside pure curiosity: I need to put a data file first on a image (for
> certain reasons) and would like to keep the users (and especially the
> VICE autostart feature) from trying to load it and thus locking up
> their machine.

It is quickly becoming off-topic here but one more comment: AFAIR current VICE's autostart feature turns "true drive emulation" OFF by default. This _may_ cause different behaviour. You have to instruct current VICE NOT to turn true drive emulation off when autostarting a disk image.

HTH.

P. S. Here are the 507 bytes of the disk image I used for testing:

http://zennon.internetdsl.pl/testimage.d64.zip

It has the same BASIC program (with two bytes loading address) different only with text printed. One is USR TEST, the other is PRG TEST. They are written in the directory as both USR (first) and PRG (second). Check for yourself (with standard ROMs, true drive emulation on, and current VICE. Or real hardware).

-- 
SD!

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.