You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When talking about the command channel, $=C is mentioned, however is the secondary address is 15 when calling SETLFS, this will result in a 'Syntax Error' being returned.
Using a value of 0 makes it work. However this is the opposite for commands such as G-P where 15 is needed and 0 errors.
I dont know the reason behind this, but its worth mentioning in the documentation somewhere as I had to trap the call the kernel uses to figure out the right value to send.
Additionally when calling DOS("$=C") from the command line the kernel actually passes in 0x60. I don't know what the top nibble means here, but should that also be documentation?
The text was updated successfully, but these errors were encountered:
Anything beginning with $ is a (virtual) file, not a command channel command. On a C64, you would do LOAD "$",8 (which always uses channel/secondary address 0)
This extends to the other "file" type operations like filtered directory lists, and newly on the X16, the cwd listing.
The X16 DOS command looks specifically for $ as the first character of its string argument, which routes it to channel 0. Any other character routes the string to channel 15.
https://github.com/X16Community/x16-docs/blob/master/X16%20Reference%20-%2013%20-%20Working%20with%20CMDR-DOS.md#command-channel
When talking about the command channel,
$=C
is mentioned, however is the secondary address is 15 when callingSETLFS
, this will result in a 'Syntax Error' being returned.Using a value of 0 makes it work. However this is the opposite for commands such as
G-P
where 15 is needed and 0 errors.I dont know the reason behind this, but its worth mentioning in the documentation somewhere as I had to trap the call the kernel uses to figure out the right value to send.
Additionally when calling
DOS("$=C")
from the command line the kernel actually passes in 0x60. I don't know what the top nibble means here, but should that also be documentation?The text was updated successfully, but these errors were encountered: