USR and REL files still a thing?

[MystikShadows]

like the title says. can we work with these file types on the commander x16? and how? Or is there a preferred method? and how? 

Thank you.

[svenvandevelde]

On 6/7/2022 at 4:18 PM, MystikShadows said:

like the title says. can we work with these file types on the commander x16? and how? Or is there a preferred method? and how? 

Thank you.

You mean, when the files are stored on an sdcard and the sdcard is mounted?

[EMwhite]

Some discussion here ... 

 

Didn't seem to land anywhere useful (a year ago); whomever owns this part of the dev SHOULD (my opinion only) implement this functionality.  Commodore squeezed it into a few 8K ROMs back when, shouldn't be too difficult to emulate or rewrite, clean-room.  Of course, the Commander, if it ever materializes in hardware, is NOT meant to be 100% Commodore compatible; but as a platform that might invite some porting of old software, it would be nice : )

 

[MystikShadows]

On 6/7/2022 at 12:15 PM, svenvandevelde said:

You mean, when the files are stored on an sdcard and the sdcard is mounted?

yes...and/or when dos"$ returns for a drive 

 

[TomXP411]

On 6/7/2022 at 7:18 AM, MystikShadows said:

like the title says. can we work with these file types on the commander x16? and how? Or is there a preferred method? and how? 

Thank you.

tl;dr REL files are extinct because CX16-DOS has a seek command. Since you can seek to any point in a file, there's no need for a dedicated random-access file format.

long version:

 USR files are just a special case of sequential files. Actually PRG files are also just a special case of sequential files. USR, PRG, and SEQ files are all single-chain files that have a single stream of data. The only difference between the three is the file type flag in the directory. The CX16 doesn't actually make a distinction between these file types, except that a PRG file is expected to have a two-byte header with the program's load address, and SEQ files are not. 

REL files are different: REL files contain multiple streams of data, organized into separate records, and an index file. The index tells CBM-DOS where each record starts, and the actual records are stored as orphan sectors on the disk. These orphan sectors are not pointed to by the directory, although they are reserved by the Binary Allocation Map (BAM).

I'm sure you can guess at the problem here: The Commander is not using CBM-DOS formatted diskettes. It will be using FAT formatted SD card, and FAT has no concept of a multi-stream record-oriented file format. So the compromise is to introduce a new file command in CX-16 BASIC, which allows you to randomly seek around in a file. This is the POSITION command. It looks like this:
P channel p0 p1 p2 p3

You'd use it something like this:
PRINT#15, "P" + CHR$(8) + CHR$(0) + CHR$(4) + CHR$(0) + CHR$(0)

This seeks to location 1024, or 0400 hex. 

https://github.com/commanderx16/x16-rom/tree/master/dos

 

[Scott Robison]

On 6/7/2022 at 4:16 PM, TomXP411 said:

tl;dr REL files are extinct because CX16-DOS has a seek command. Since you can seek to any point in a file, there's no need for a dedicated random-access file format.

And for people who might not know or remember, the idea of files having fixed length records that you could seek to was very common in systems prior to the 1980s. CP/M basically treated files as a number of 128 byte records (the size of a sector usually). The idea that you could seek to an arbitrary byte offset in any old file was pretty radical when it was introduced. Given that much of the world ran off 9 track magnetic tape, the record abstraction was convenient for batch processing.

Today we take for granted that we can seek around in a file and read it back in a random order. Such has not always been the case.

[TomXP411]

On 6/7/2022 at 3:27 PM, Scott Robison said:

CP/M basically treated files as a number of 128 byte records (the size of a sector usually)

I was going to write a program that manipulated C/M disk images in a GUI.... I took one look at the "Extents" management and decided that I had better things to do with my time, like hit myself in the head with a hammer.

 

[Greg King]

On 6/7/2022 at 6:16 PM, TomXP411 said:

This is the POSITION command. It looks like this:

P channel p0 p1 p2 p3

You'd use it something like this:
PRINT#15, "P" + CHR$(8) + CHR$(0) + CHR$(4) + CHR$(0) + CHR$(0)
This seeks to location 1024, or 0400 hex. 

https://github.com/commanderx16/x16-rom/tree/master/dos

That's big-endian.  But, the number must be little-endian!  Also, don't use strings.  That will run the string garbage collector, which will slow down your program.  Write it this way:

PRINT#15,"P";CHR$(8);CHR$($0);CHR$($0);CHR$($4);CHR$($0)

[TomXP411]

On 6/21/2022 at 8:43 AM, Greg King said:

That's big-endian.  But, the number must be little-endian!  Also, don't use strings.  That will run the string garbage collector, which will slow down your program.  Write it this way:

PRINT#15,"P";CHR$(8);CHR$($0);CHR$($0);CHR$($4);CHR$($0)

That's incorrect: you are writing the number in Big-Endian format, and this will try to seek to location 262,144.

The P command takes the low-order byte first. (That's what Little-Endian means). So if you were seeking position 1, you would send the bytes in this order:  01 00 00 00 

If you were seeking position 256, you would send: 00 01 00 00

And 1024 is: 00 04 00 00 

Likewise, if you were jumping 64K into the file: 00 00 01 00

And if you wanted to jump 16 megabytes into the file: 00 00 00 01

 

[ZeroByte]

Does the P command have a "seek end of file" cousin?

[TomXP411]

On 6/21/2022 at 12:25 PM, ZeroByte said:

Does the P command have a "seek end of file" cousin?

No. 

FYI, for some reason, this manual doesn't get included with the emulator build. You can read the DOS manual here: 
https://github.com/commanderx16/x16-rom/tree/master/dos

[Greg King]

On 6/21/2022 at 12:23 PM, TomXP411 said:

That's incorrect: you are writing the number in Big-Endian format, and this will try to seek to location 262,144.

The P command takes the low-order byte first. (That's what Little-Endian means). So if you were seeking position 1, you would send the bytes in this order:  01 00 00 00 

If you were seeking position 256, you would send: 00 01 00 00

And 1024 is: 00 04 00 00 

Likewise, if you were jumping 64K into the file: 00 00 01 00

And if you wanted to jump 16 megabytes into the file: 00 00 00 01

You're right.  I forgot that the number is 32, not 16, bits.  I was thinking nybbles instead of bytes.

[TomXP411]

On 6/21/2022 at 7:42 PM, Greg King said:

You're right.  I forgot that the number is 32, not 16, bits.  I was thinking nybbles instead of bytes.

Happens to the best of us. Every time I post a tutorial or even just a code sample, I end up having to go back and fix something. 

And you were right about using the ; instead of + to concatenate the characters. Using + will build a string and then pass it all at once, whereas using ; will transmit the individual characters one at a time without building a new string on the string table. 

so my example for 1024 should be:
PRINT#15, "P";CHR$(8);CHR$(0);CHR$(4);CHR$(0);CHR$(0)