Jump to content
  • 0

USR and REL files still a thing?


MystikShadows
 Share

Question

13 answers to this question

Recommended Posts

  • 0
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?

Link to comment
Share on other sites

  • 0

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 : )

 

Link to comment
Share on other sites

  • 0
  • Super Administrators
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

 

  • Like 2
Link to comment
Share on other sites

  • 0
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.

  • Like 3
Link to comment
Share on other sites

  • 0
  • Super Administrators
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.

 

Link to comment
Share on other sites

  • 0
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)

Link to comment
Share on other sites

  • 0
  • Super Administrators
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

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
  • Super Administrators
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)

 

 

Link to comment
Share on other sites

  • 0
On 6/7/2022 at 6: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.

So,  for instance,  the only REL files I used extensively back in the day were Forth Block files,  so the record was a uniform 1KB. But with an underlying FAT file system and seek functions working on any old sequential files,  there is no need for a special format: a block file can simply seek the correct number of KB and then read or write 1KB from or to the block buffer.

Indeed,  if a maximum block file size is set..
.  such as 1MB (1K of 1KB blocks)... that would allow for multiple block files to be placed in the 64MB space that can be referenced by a traditional 16bit Forth system, similar to the Forth Inc approach of accessing block files..

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use