Jump to content
EMwhite

RELative file support in X16?

Recommended Posts

Does/will X16 support REL files; assumed that the hardware will be happy to allow pushing 15 command channel commands to an IEC device, but does the emulator support it today and will the hardware support the emulation of code on an SD image?

I dusted off an old program I wrote in the 80s and have been enhancing it under VICE x64.  Wondering if I should bother to continue; I read somewhere (here) that SEQ support was added specifically.

Thanks all

 

Share this post


Link to post
Share on other sites
2 hours ago, kktos said:

Pardon my ignorance 😞 but what are REL files ?

It's a mode designed for random access files. The file has two parts: a vector table and the actual record data. Essentially, the vector table is a list of indices into the table that allow you to point to various locations in the file and (I think) update the order of the records without physically re-writing the records (you would just change the index). I think the primary use cases was for databases, since a separate chain for indexes would let you re-order data without physically re-writing the data portion of the file. 

 

Edited by TomXP411
  • Like 2

Share this post


Link to post
Share on other sites
5 hours ago, kktos said:

Pardon my ignorance 😞 but what are REL files ?

It's a random access construct (drive seeking) for fixed length 'records' with variable data held within with zero overhead required by the Commodore deivce.

With one command (via a 15 command channel), you can instantiate file of [as example] 192 characters per record; once created, you can open and close a file via simple open command without describing the structure; then via command channel, seek to any 'record' between 1 and 65535 with an offset in the record from 1st to 192nd character.  Each record can have a varied structure (like a MongoDB document) and once open and positioned, you use typical "input #2,a$,b$" in order to read data.

Again, zero overhead to the computer, all done within the 1541 (as example) drive.

Anybody know?

  • Like 2

Share this post


Link to post
Share on other sites

The most recent word I saw was that they were not sure they would be implementing it, but that would not have been sometime before the start of the semester, so before mid September.

Share this post


Link to post
Share on other sites

I've never needed REL files, and they don't really exist on non-Commodore computers. Will we have the ability to seek within a file in SEQ files? I don't know CBM-DOS well enough to even know how to do that. 

** edit: never mind. There is no seek command in SEQ files. So you either have to load the entire file into memory, then re-write it, or you need to use some other construct. 

We definitely need the ability to seek within a file, but I'd be fine if we can simply issue a SEEK command with an open SEQ/PRG file (there is no distinction on the Commander.)

 

Edited by TomXP411

Share this post


Link to post
Share on other sites

VICE implemented it just fine... why not just reuse or is there a thorny licensing issue that does not seem to bother the VICE crowd but is an issue here? (made more challenging still because nobody knows what it is : )

Did the x64 developers actually start with nil and build up the entire legacy Commodore drive DOS but skip REL and USR portion of the code?  Jim Butterfield (RIP) would be most disappointed. 

My BBS User and Message manager can be rewritten but the catalog of TPUG PET Recipe and VHS cataloging programs have now died their 2nd death : (

 

 

Share this post


Link to post
Share on other sites
3 hours ago, EMwhite said:

VICE implemented it just fine... why not just reuse or is there a thorny licensing issue that does not seem to bother the VICE crowd but is an issue here? (made more challenging still because nobody knows what it is : )

Did the x64 developers actually start with nil and build up the entire legacy Commodore drive DOS but skip REL and USR portion of the code?  Jim Butterfield (RIP) would be most disappointed. 

My BBS User and Message manager can be rewritten but the catalog of TPUG PET Recipe and VHS cataloging programs have now died their 2nd death : (

VICE is a virtual machine that runs the original Commodore software; the REL support on the virtual 1541 (and 1571, 1581, etc) is due to the ROMs that shipped with the drives that are being emulated. That's a completely different situation than what is happening here: the DOS code has to be written from ground zero, because there never has been (as far as I know) a CBM-DOS to FAT32 driver for 6502. 

As to your legacy software... you always have the option to use a real 1541, a Pi1541, a 1541 Ultimate, a 1581, a Lt Kernel hard drive, or an SD2IEC, which does support REL files inside of disk images. 

 

Share this post


Link to post
Share on other sites
On 1/14/2021 at 3:00 AM, TomXP411 said:

I've never needed REL files, and they don't really exist on non-Commodore computers. Will we have the ability to seek within a file in SEQ files? I don't know CBM-DOS well enough to even know how to do that. 

** edit: never mind. There is no seek command in SEQ files. So you either have to load the entire file into memory, then re-write it, or you need to use some other construct. 

We definitely need the ability to seek within a file, but I'd be fine if we can simply issue a SEEK command with an open SEQ/PRG file (there is no distinction on the Commander.)

CMDR DOS can seek in files!  It's documented in the README.  There is one mistake:  the Position command works in Read mode, as well as Modify mode.

  • Thanks 1

Share this post


Link to post
Share on other sites
22 hours ago, EMwhite said:

VICE implemented it just fine... why not just reuse or is there a thorny licensing issue that does not seem to bother the VICE crowd but is an issue here? (made more challenging still because nobody knows what it is : )

Did the x64 developers actually start with nil and build up the entire legacy Commodore drive DOS but skip REL and USR portion of the code?  Jim Butterfield (RIP) would be most disappointed. 

My BBS User and Message manager can be rewritten but the catalog of TPUG PET Recipe and VHS cataloging programs have now died their 2nd death : (

 

 

Almost the entirety of the File I/O system has to be rewritten.

Share this post


Link to post
Share on other sites
14 hours ago, Greg King said:

CMDR DOS can seek in files!  It's documented in the README.  There is one mistake:  the Position command works in Read mode, as well as Modify mode.

The problem being that this ReadMe is not included in the emulator package, so I had no idea it existed until earlier today (when I was looking at the block I/O API.)

Yes, the P command works great. I've already written a small demo program to test it. 

Also, it's worth noting there is an error in the ReadMe. The ReadMe says:
 

POSITION P channel p0 p1 p2 p3 Set position within file (like sd2iec); all args binary

"all args binary" is not correct. The channel number needs to be passed in ASCII, so the correct syntax to seek to position 128 on channel 1 is....

DOS"P1"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0)

Channels 10-15 need to be entered as the ASCII characters after 9  (:;<=>?)

here's an example:

20 OPEN 1,8,8,"@:DEMO,S,W"
40 FOR L=0 TO 255
50 PRINT#1,CHR$(L);
60 NEXT
90 CLOSE 1
100 OPEN 10,8,8,"DEMO,?,M"
110 DOS"P:"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0)
115 DOS
120 FOR I=1 TO 4
130 L=0:GET#10,L$:IFL$<>""THEN L=ASC(L$)
150 PRINT L;
160 NEXT I
170 PRINT
999 CLOSE 10

When you run this, it will create a 256 byte file.

Then it will re-open the file for random access and seek to position 128. 

It will then print 4 bytes byte at that position. That should be 128-131.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Odd that whomever wrote the code/doc chose to buck the convention set by Commodore code and go with printable ASCII characters only to reach into the awkward range of special symbols; '?' is an especially bizarre choice (my coloured opinion, only).

Would a 'DOS"P"+CHR( {channel} + 48) + CHR$ ( {low byte} ) + CHR$ ( {high byte}  ) + CHR$ ( {higher-order-byte} ) + CHR$ ( {highest-order-byte} ) work?

Interesting that as high as 32 bits can be expressed (4GB max file seek is potentially possible.  Maybe dump the entire Encyclopedia Brittanica into a single file and allow an 8 bit Commander app to provide a browse/search, just as the early 90s IBM PC CD-ROM titles did.  That was amazing !!

 

Share this post


Link to post
Share on other sites

The channel argument is binary!  Also, where the document says ",?,M", that question mark is a place-holder.  You should substitute a file-type letter.  Therefore, the BASIC code should be:

20 OPEN 1,8,8,"@0:DEMO,S,W"
40 FOR L=0 TO 255
50 PRINT#1,CHR$(L);
60 NEXT
90 CLOSE 1
100 OPEN 10,8,8,"0:DEMO,S,M"
110 DOS"P"+CHR$(8)+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0)
115 DOS
120 FOR I=1 TO 4
130 L=0:GET#10,L$:IFL$<>""THEN L=ASC(L$)
150 PRINT L;
160 NEXT I
170 PRINT
999 CLOSE 10

Share this post


Link to post
Share on other sites

For some reason, when i first tried it with CHR$(8), I got "no channel", and it worked when I put in "8". When I tried it again today, it worked both ways. So it looks like the DOS code clips the top 4 bits, so it seems like either way works.

 

Share this post


Link to post
Share on other sites

I'm wondering....
Why are we trying to mimic the C64 OS here ?
I'm thinking that if I want to have a better C64, we know there are (mainly there is) far better alternatives.
But is looks like a C64, you can say.
Yes, true. On the software side.
But that's mainly because it was the easiest path to go. No need to rewrite everything.
That being said, back to my initial question.
As we are more or less making the thing, we can choose to do whatever we want.
And we may go for ways more explicit than DOS"P"+CHR$(8)+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0), don't you think ?

Something as simple as a DOS SEEK, for instance......

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, kktos said:

I'm wondering....
Why are we trying to mimic the C64 OS here ?
I'm thinking that if I want to have a better C64, we know there are (mainly there is) far better alternatives.
But is looks like a C64, you can say.
Yes, true. On the software side.
But that's mainly because it was the easiest path to go. No need to rewrite everything.
That being said, back to my initial question.
As we are more or less making the thing, we can choose to do whatever we want.
And we may go for ways more explicit than DOS"P"+CHR$(8)+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0), don't you think ?

Something as simple as a DOS SEEK, for instance......

Yes, it would really help if the Commander DOS functions were backed up by BASIC commands. MKDIR, CHDIR, RMDIR, COPY, DELTE, and SEEK. 

I'd also like to see some more numeric conversion and math functions. Specifically, we need HEX$ and BIN$ functions and the MOD operator. 

Right now, it takes about 10 lines of code to display a number to hex, when it really should just be something like PRINT HEX$(A)

There are also still open feature requests for banked memory management and a few other things, as well... so there's still a long way to go on these kinds of things. Maybe if you have the skills, you can jump in and lend a hand. Now that I'm starting to get a handle on assembly for the Commander, I may step in and add some of my own commands (specifically, the ones I just mentioned.)

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Something i was wondering - isn't the basic ROM bank size on the cx16,  16 kilobyte?  ($c000-$ffff, the kernal rom is in another bank from what I now understand)  Why is it then that we already had trouble to find rom space to add those hex$ and bin$ functions?  (at least I remember we ran into that)  because the basic v2 rom on the c64 was just 10 kilobyte or so.      The few extra existing commands that were added can't account for the other 5-6 kilobyte surely?     I may be way off course here in my estimations but I suddenly was curious

Share this post


Link to post
Share on other sites
20 minutes ago, desertfish said:

The few extra existing commands that were added can't account for the other 5-6 kilobyte surely?

I can't tell you, I just thought that the Commander X16 specific command already added was the reason we ran into space issues.

Share this post


Link to post
Share on other sites
1 hour ago, desertfish said:

Something i was wondering - isn't the basic ROM bank size on the cx16,  16 kilobyte?

Actually BASIC has to fit into 8KB if I'm not mistaken. Aren't the other 8KB used by the KERNAL ROM?

Share this post


Link to post
Share on other sites

Hmm, that's not how I now understand the banked roms to be working in the memory map from the documentation https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#memory-map   and the discussion in the file i/o performance topic.   I read that as "basic is in a different banked rom, namely 4, as the kernal, which is in bank 0" and the rom banks are 16 kb each....

Share this post


Link to post
Share on other sites
1 minute ago, desertfish said:

I read that as "basic is in a different banked rom, namely 4, as the kernal, which is in bank 0" and the rom banks are 16 kb each....

That's correct

Share this post


Link to post
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
Reply to this topic...

×   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.


×
×
  • Create New...

Important Information

Please review our Terms of Use