SDX C: vs D3:

[Copper]

Spartanians, I'm wondering if the driver letter assignment in SDX is a tribute to MSDOS or useful (except of typing 1 letter less)?
What are you using / familiar with?

 

best Marco

[TGB1718]

Probably because you can have more than 9 drives, so makes sense to use letters above 9, but

also use the lower letters as alias for D1: etc.

 

[+Eyvind Bernhardsen]

The fact that ? is hardcoded to D4: in SDX almost made me stop using it back when I first discovered it. That and the backslashes: if I wanted MS-DOS nostalgia I'd just use Windows. Unit numbers 10-15 could have been solved using hex; DA:, DB:, DC:, DD:, DE:, DF: would have been much more logical and Atari DOS-like.

 

So, to answer your question: I use M:, N:, and O: for my large storage volumes and ramdisk because they didn't conflict with any existing devices (unlike ?, ?, E:, and K:, but now N: is for Fujinet! Grrr...), but other than that I try to ignore the drive letters and use > (along with <, which is delightful) as the directory separator.

 

Edit: despite all my efforts, the forum insists on converting my drive letters to smileys. Sigh.

Edited April 4, 2021 by Eyvind Bernhardsen
Forced emoji explanation

[flashjazzcat]

28 minutes ago, Eyvind Bernhardsen said:

Unit numbers 10-15 could have been solved using hex; DA:, DB:, DC:, DD:, DE:, DF: would have been much more logical and Atari DOS-like.

Yes, but the reasoning behind kernel device names and drive letters has more to do with flexibility. Imagine only being able to use a single device ID and unit number for something like the 'CAR:' (cartridge volume) or 'PCL:' (PCLink) devices. 'C:' and 'P:'? Nope... already taken.

 

In any case, from the CIO, the exact notation you suggested can be used anyway, and this does not involve any 'conflicts' with existing devices, even if you have an HDD partition on 'C:' (since it's D3:, DC:, DDSK3: or DDSKC: via CIO). But in the CLI, where there are pipes, batch files, and multiple installable devices, getting away from the limitations of the single-character device names made a lot of sense.

 

The screen editor and keyboard, etc, are referred to by different device names at the SDX command line, so no contention is possible with 'E:', 'K:', etc.

[+Eyvind Bernhardsen]

Yes, that’s why I got over it*. Drive letters aren’t necessary for longer device names, though, and given that disk access from outside SDX requires the D prefix I would argue that there would have been less confusion if they’d stuck with the existing convention, with D1:-DF: as disk drives.

 

From BASIC, “D:” means the current directory and you can use “D1:” through “D9:” just like the old days... but the next disk device is inexplicably “DJ:”, and on the SDX command line “D:” is always “D4:” (?) and none of the other CIO device letters work at all.

 

“C:” doesn’t conflict with “CAR:” anyway; CIO only supports a single character plus device number, so any device name one or two characters long could have been a CIO device, with three characters or more making it an SDX device. It does conflict with “D3:” now, which I think was unnecessary.
 

* okay, maybe I’m not completely over it ?

[Mazzspeed]

Where's /dev/null?

[+Eyvind Bernhardsen]

12 hours ago, flashjazzcat said:

The screen editor and keyboard, etc, are referred to by different device names at the SDX command line, so no contention is possible with 'E:', 'K:', etc.

Yes, this is what I'm upset about. Why can't I just use "E:"? Because it would conflict with the design goal of making SDX feel "exactly like an MS-DOS machine."

 

I'm not opposed to having a "CON:" device, I just want to be allowed to use its proper name like I can everywhere else in the system.

[flashjazzcat]

1 hour ago, Eyvind Bernhardsen said:

Drive letters aren’t necessary for longer device names, though

What about my PCLink volume on PCL2: (or "DPCL2:" via the CIO)?

1 hour ago, Eyvind Bernhardsen said:

From BASIC, “D:” means the current directory

"D:" denotes the current directory on the default drive, which may be anything from D1:-DO:. If you add a unit number, it still refers to the current directory on the specified drive, unlike the bonkers MYDOS implementation where adding a unit number forces a reference to the root of the specified drive.

1 hour ago, Eyvind Bernhardsen said:

and you can use “D1:” through “D9:” just like the old days... but the next disk device is inexplicably “DJ:”

Nothing inexplicable about it at all. "J" is the tenth letter of the alphabet. If you prefer, use "DA:" through "DO:".

1 hour ago, Eyvind Bernhardsen said:

“C:” doesn’t conflict with “CAR:” anyway; CIO only supports a single character plus device number, so any device name one or two characters long could have been a CIO device, with three characters or more making it an SDX device. It does conflict with “D3:” now, which I think was unnecessary.

It's HATABS which only supports a single character device name; the handler can do as it pleases, as evidenced by the SDX "D:" handler itself, which allows "DDSK1:", "DCON:", etc. I have to wonder how many times one wants to refer to the cassette device from the DOS prompt anyway.

1 hour ago, Eyvind Bernhardsen said:

Yes, this is what I'm upset about. Why can't I just use "E:"? Because it would conflict with the design goal of making SDX feel "exactly like an MS-DOS machine."

The reasons behind device kernel names have already been laboriously explained here and are explained in the manual as well. There is logical reasoning behind the design; you may not like or agree with it, but to portray it as arbitrary or a labrynth of confusion seems disingenous. As for MS-DOS: this may have informed the design of SDX, but this would hardly be surprising in the late 1980s when MS-DOS was probably the predominant disk operating system. Those of us old enough have been using '"A:" through "Z:" to address our disk drives and hard disk partitions on PCs for some thirty-odd years, and the conventions remain the same to this day. Perhaps one would prefer a linux /dev approach, but this would still involve a completely redesigned device naming scheme which is not directly compatible with the one implemented by Atari DOS 2.x. And the reasons for not simply sticking with that standard have already been covered.

[+Eyvind Bernhardsen]

Interesting; it seems you're angrier about this than me.

24 minutes ago, flashjazzcat said:

What about my PCLink volume on PCL2: (or "DPCL2:" via the CIO)?

What about it? "PCL2:" is "PCL2:". What does that have to do with "E:" being "E:" (and not "D5:")?

24 minutes ago, flashjazzcat said:

"D:" denotes the current directory on the default drive, which may be anything from D1:-DO:. If you add a unit number, it still refers to the current directory on the specified drive, unlike the bonkers MYDOS implementation where adding a unit number forces a reference to the root of the specified drive.

Yep, that's true in BASIC, and indeed everywhere else except on the SDX command line, where "D:" means the current directory on drive 4.

24 minutes ago, flashjazzcat said:

Nothing inexplicable about it at all. "J" is the tenth letter of the alphabet. If you prefer, use "DA:" through "DO:".

Well, as I said, I would have preferred "D1:" through "DF:". If you're used to using 1-9, "J" coming up out of nowhere is unexpected.

24 minutes ago, flashjazzcat said:

It's HATABS which only supports a single character device name; the handler can do as it pleases, as evidenced by the SDX "D:" handler itself, which allows "DDSK1:", "DCON:", etc. I have to wonder how many times one wants to refer to the cassette device from the DOS prompt anyway.

I know! I know perfectly well how this works, I'm just saying it would have been possible to add long device names while remaining compatible with the CIO device letters. If "C:" isn't useful enough for you, consider "E:" or "S:", the latter of which doesn't even conflict with a drive letter.

24 minutes ago, flashjazzcat said:

The reasons behind device kernel names have already been laboriously explained here and are explained in the manual as well. There is logical reasoning behind the design; you may not like or agree with it, but to portray it as arbitrary or a labrynth of confusion seems disingenous. As for MS-DOS: this may have informed the design of SDX, but this would hardly be surprising in the late 1980s when MS-DOS was probably the predominant disk operating system. Those of us old enough have been using '"A:" through "Z:" to address our disk drives and hard disk partitions on PCs for some thirty-odd years, and the conventions remain the same to this day. Perhaps one would prefer a linux /dev approach, but this would still involve a completely redesigned device naming scheme which is not directly compatible with the one implemented by Atari DOS 2.x. And the reasons for not simply sticking with that standard have already been covered.

If you think you've been laboriously explaining anything, I think you should re-read your own posts. I'm neither saying it's arbitrary nor a labyrinth of confusion, I'm saying it was an unnecessary design decision that causes pointless confusion. Again: "C:", "D:", and "E:" mean something different in SDX than they do everywhere else on the Atari, and the only reason for it is to allow MS-DOS drive letters to be used. Long device names are an orthogonal feature and I don't see why you keep bringing them up.

 

What I would have preferred is for old-style CIO device letters to be allowed alongside the long device names. That's it. That's my position.

 

By the way, "exactly like an MS-DOS machine" is a quote from the SDX V4.48 User Guide, page 18.

[Mazzspeed]

I believe the letter naming convention pre dates MS-DOS, it actually began with CP/M.

 

I was only joking regarding dev/null. However the fact that it's based on the Linux file structure does highlight an interesting point that many people struggle with:

 

When people complain that things are done differently under Linux compared to Windows, I always answer with the same reply to give their struggle context - Linux is Linux, Linux is not a Windows clone, there's no prerequisite for it to be a Windows clone.

 

Essentially, this situation is no different. SDX is SDX and should be viewed as such, it is not an MS-DOS clone even though it was modeled on MS-DOS which was popular at the time - No different to Linux with a Windows theme. Appreciate SpartaDOS-X for what it is, arguing over drive lettering really is quite petty. Relax people, we all know AmigaOS 3.1 was the best OS so it's all moot.

[drac030]

5 minutes ago, Eyvind Bernhardsen said:

I'm saying it was an unnecessary design decision that causes pointless confusion

Note that the design you are speaking about is exactly the SpartaDOS 3. I do not think they (ICD) would decide to make an "unnecessary" decision of redesigning the whole system, if the previous design had not come to a dead end. I guess that the primary reason was to make the I/O redirection flawless: thus the decision of adding another I/O layer ("the kernel") behind the CIO level. This in turn makes it necessary to add another set of device identifiers, and whether you, doing that, follow the MS-DOS example or anything else, is finally an arbitrary decision.

 

By the way, the name of disk 3 is not D3 nor C - it is $03. It can be visualised in different ways, but that is not very substantial.

2 hours ago, Eyvind Bernhardsen said:

I'm not opposed to having a "CON:" device, I just want to be allowed to use its proper name like I can everywhere else in the system.

Proper name of CON: is CON:, not E:. Or in other words, CON: is E: plus I/O redirection. The SDX shell does not have a clue about CIO, though, this is why it does not allow referring to the console as to E:, and this regardless on how disks are called.

 

DJ: - when the number of drives (originally 9) was being expanded to 15, it was not possible to name disk 10 "A" because "A" was already taken, meaning D1: from the very beginning. And since D9 was already an equivalent to I, assigning J to the next drive was quite logical.

 

/dev/null is named NUL:

 

It is of course not impossible to write an alternative shell which would access devices via CIO. I think, though, that it is not quite worth the effort.

 

Happy Easter, everyone.

[+Eyvind Bernhardsen]

7 minutes ago, drac030 said:

By the way, the name of disk 3 is not D3 nor C - it is $03. It can be visualised in different ways, but that is not very substantial.

Thanks for the technical insight! My main problem with the design is probably that I think the user-facing name is substantial, and CIO device name compatibility could have been special-cased in if drive letters hadn't been there. User-centric design is why I've been a Mac user for 20 years ?

 

I know I'm tilting at windmills, but that's what the Internet is for, after all. I'm not expecting SDX to change.

[flashjazzcat]

23 minutes ago, Eyvind Bernhardsen said:

Interesting; it seems you're angrier about this than me.

I am not in the least bit angry, and I don't know why you would conflate my attempts to explain the logic behind the SDX kernel device names as evidence of anger. It is you who has written that you are 'upset'.

24 minutes ago, Eyvind Bernhardsen said:

What about it? "PCL2:" is "PCL2:". What does that have to do with "E:" being "E:" (and not "D5:")?

I would say consistency. If you're going to make a clean break of it (for reasons Konrad can explain more eloquently than I), there is no point in leaving vestigial elements of the old convention in place for arbitrary reasons.

25 minutes ago, Eyvind Bernhardsen said:

Yep, that's true in BASIC, and indeed everywhere else except on the SDX command line, where "D:" means the current directory on drive 4.

If you understand that, from where does the confusion arise?

27 minutes ago, Eyvind Bernhardsen said:

Well, as I said, I would have preferred "D1:" through "DF:". If you're used to using 1-9, "J" coming up out of nowhere is unexpected.

Not really unexpected when if you have spent twenty minutes familiarising yourself with SDX or looking through the manual. A hex numbering scheme could certainly have worked, but is not really user-friendly if said user doesn't understand hexadecimal, and we seem to be discussing concepts which are purportedly hard to grasp for the average user. 1-F isn't very expandable, however; if SDX one day supported 26 drives, your hex unit numbering scheme would fall flat on its face.

30 minutes ago, Eyvind Bernhardsen said:

I know! I know perfectly well how this works, I'm just saying it would have been possible to add long device names while remaining compatible with the CIO device letters. If "C:" isn't useful enough for you, consider "E:" or "S:", the latter of which doesn't even conflict with a drive letter.

OK - chill. No offense intended. I was just responding to this:

3 hours ago, Eyvind Bernhardsen said:

CIO only supports a single character plus device number

I didn't realise you specifically meant the limitations of HATABS. My bad!

32 minutes ago, Eyvind Bernhardsen said:

If you think you've been laboriously explaining anything, I think you should re-read your own posts. I'm neither saying it's arbitrary nor a labyrinth of confusion, I'm saying it was an unnecessary design decision that causes pointless confusion.

I'm not sure you know what you're saying: in the same breath, you tell us you are not claiming the device naming scheme is arbitrary and confusing, and then say that it's 'unnecessary' and a source of pointless confusion. 'Arbitrary' means 'based on random choice or personal whim, rather than any reason or system.' So: pointless, which is what you call it in as many words.

41 minutes ago, Eyvind Bernhardsen said:

Long device names are an orthogonal feature and I don't see why you keep bringing them up.

I am arguing that long device IDs are essential to the flexibility of the SDX driver model, and that the DSK device should follow the same conventions for the sake of internal consistency in the SDX kernel.

 

Anyway: no aggravation intended. I speak as someone who has been using SDX since 1989, and I guess I have become used to it.

[drac030]

1 hour ago, Eyvind Bernhardsen said:

CIO device name compatibility could have been special-cased in if drive letters hadn't been there

I think that you are looking back to the point where the ICD programmers were standing in 1987 - and they have decided that the CIO-centered design has too much limitations (this is even hinted in the manual); I guess the planned features probably could still have been implemented in CIO - as it was already tried in SpartaDOS 3 - but all this would have been too kludgy, so they have decided to make a cut.

 

As a result, SDX is not built around CIO. It is rather an operating system on its own which also features a backward compatibility interface plugged into the CIO, so that old programs could still work. Atari BASIC etc. is the "old programs", this is why "D:" works traditionally in it.

 

Here is a drawing which shows schematically the internal structure of the SDX (I hope that it will be readable):

 

 

Note that the "D:" is just an outpost plugged into the Atari OS to maintain the backward compatibility, as I said

 

Edited April 5, 2021 by drac030

[Faicuai]

2 hours ago, drac030 said:

As a result, SDX is not built around CIO. It is rather an operating system on its own which also features a backward compatibility interface plugged into the CIO, so that old programs could still work. Atari BASIC etc.

Also, another key reason why SDX reached the heights it has attained, and also why (byte-for-byte, gram-by-gram) it just rules on the 8bit world.

 

I soon as I learned I could refer to a PC-Link drive as "PCLn:", right at the command prompt, I knew there was some serious work under SDX hood (eg. not really CIO). And I was truly grateful for it, indeed.

 

I grew up with Atari DOS, but always had contact with the MS-DOS world from early on... I (and those around me at my early-years workplace) always thought of Atari DOS being a toy. First time I saw DUP.SYS I was like... WTF was that? And not to mention the implementations we saw in other platforms...

 

 

 

Edited April 5, 2021 by Faicuai