Commander X16

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.

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.

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.

 

 

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 !!

 

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

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.

 

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

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

 

 

 

1 hour ago, TomXP411 said:

Specifically, we need HEX$ and BIN$ functions

I have already created a pull request to add HEX$ and BIN$

https://github.com/commanderx16/x16-rom/pull/176

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