Capabilities of SpartaDOS 3.2 G

[GoodByteXL]

While doing compability tests with SDX 4.48 I tried some with SD 3.2 G and couldn't verify this feature:

What's new in SpartaDOS version 3.2g

************************************

Version 3.2f could only access drive
ID numbers from D1-D8.  Now, you can
access drive D9.

************************************

A filespec that does not contain a
drive number, such as D:TEST, will
now default to your currently logged
drive on the command line.

For example, if you are logged to D4:
a filespec of D:TEST will be converted
to D4:TEST, instead of D1:TEST as it
used to be. This change can be very
useful when running programs from
different drive numbers, since you
can access files with D: and they
will automatically be taken from
whichever drive the program was 
was started from.

You must now be careful however, to
always type D1: when you need to 
access drive 1 specifically.

************************************

It always accesses "D1:" when trying to use the current drive with "D:".

 

As this is the original distribution disk wherefrom it is taken I wonder if this feature was never realized or if my disk was not updated before sending it out in Summer 1994.

 

Anybody having hard facts about it?

[+bf2k+]

I thought I remembered this working in the past but I just tested it with X33A.DOS and it doesn't appear to work there either.

Edited May 21, 2016 by bf2k+

[GoodByteXL]

Anybody capable of fixing this?

[_The Doctor__]

I wonder what got changed or lost over the time.... I am not sure of the current behavior.... I do remember that when you changed the drive by changing the working directory (CWD etc etc) and in at least one rendition typed the drive in the command prompt... D5: D6: etc etc.. that using D: or no drive identifier at all caused the operation to be performed on the working directory or active directory. That might have been changed to save space... so that Sparta always looks to D1: unless specified otherwise.... I preferred the working directory/active directory method where it acted on no id or D: with no number as working or active directory as the default.

[flashjazzcat]

I'm not aware of a drive number ever denoting the root in SpartaDOS, though it does in MyDOS. This is a different issue to D: denoting a default drive other than D1:, of course.

[_The Doctor__]

D: without a number or letter should operate on the command prompt drive or working directory drive but not path, not sure why it isn't....

 

my muddle in the post above was unclear.... As I understood it, it was to acces the root directory of a drivepath....

 

so let's say I am in...

D9:>EXAMPLE>ETC>

but I wanted to read a .bat, .exe, .sys or .txt or whatever without changing or losing my working directory....I would type at the command prompt of D9:>EXAMPLE>ETC>D:ROOT.BAT or D:POKE. {arguments like 82,0}

 

it would run it from root of D9: and return and still be in the D9:>EXAMPLE>ETC>

directory even thought it ran the program or bat from the root

that is what I remember the intended purpose discussion was about..... the idea was to be able to make and read files while deep in directory tree of a bbs etc.... and not have to leave it to do some things

 

Whatever ended up being on the distribution disk should have at least stayed within the same drive or drivepath no matter what the ultimate conclusion was....

Edited June 4, 2016 by _The Doctor__

[flashjazzcat]

D: without a number or letter should operate on the command prompt drive or working directory drive but not path, not sure why it isn't....

 

my muddle in the post above was unclear.... As I understood it, it was to acces the root directory of a drivepath....

 

so let's say I am in...

D9:>EXAMPLE>ETC>

but I wanted to read a .bat, .exe, .sys or .txt or whatever without changing or losing my working directory....I would type at the command prompt of D9:>EXAMPLE>ETC>D:ROOT.BAT or D:POKE. {arguments like 82,0}

 

it would run it from root of D9: and return and still be in the D9:>EXAMPLE>ETC>

directory even thought it ran the program or bat from the root

that is what I remember the intended purpose discussion was about..... the idea was to be able to make and read files while deep in directory tree of a bbs etc.... and not have to leave it to do some things

 

Whatever ended up being on the distribution disk should have at least stayed within the same drive or drivepath no matter what the ultimate conclusion was....

The idea is that you have a default drive, just as you have a default working directory. I wasn't so sure about the behaviour of disk-based Sparta, so I just fired up 32G tested it to confirm the expected behaviour. If >EXAMPLE>ETC is the logged directory on drive 9, any access to drive 9 which omits a path will be to D9:>EXAMPLE>ETC. To get the root of D9: without changing the current directory, the spec is D9:>. You can also refer to the root of the drive with "<<" (to back up two levels in the hierarchy).

 

What's being discussed regarding the default drive appears to concern whether accesses to D: refer to D1: or to (say) D9: after "D9:" was typed on its own at the command prompt to change the default drive to unit 9. If this were the case, "D9:" followed by "CD >EXAMPLES>EXT" followed by "DIR D:" would list the contents of ">EXAMPLES>ETC" on drive 9. "DIR" does the same thing (as does "DIR D9:").

 

While doing compability tests with SDX 4.48 I tried some with SD 3.2 G and couldn't verify this feature:

What's new in SpartaDOS version 3.2g

************************************

Version 3.2f could only access drive
ID numbers from D1-D8.  Now, you can
access drive D9.

************************************

A filespec that does not contain a
drive number, such as D:TEST, will
now default to your currently logged
drive on the command line.

For example, if you are logged to D4:
a filespec of D:TEST will be converted
to D4:TEST, instead of D1:TEST as it
used to be. This change can be very
useful when running programs from
different drive numbers, since you
can access files with D: and they
will automatically be taken from
whichever drive the program was 
was started from.

You must now be careful however, to
always type D1: when you need to 
access drive 1 specifically.

************************************

It always accesses "D1:" when trying to use the current drive with "D:".

 

As this is the original distribution disk wherefrom it is taken I wonder if this feature was never realized or if my disk was not updated before sending it out in Summer 1994.

 

Anybody having hard facts about it?

 

As mentioned above, I'm seeing the desired behaviour here with 32G, and it pervades to - for example - CIO calls from BASIC. If I log D5: at the command prompt, subsequent references to "D:" refer to "D5:", as does opening a file on "D:" from BASIC.

[_The Doctor__]

FJC,

If I understand what you have written... then your copy of 3.2G is working properly. Since you log D5:...... then reference D: in DOS or in Basic... it is giving you D5: root..

Then your copy is correct.....

As GoodbyteXL is saying his copy does not exhibit that behavior... and does not see any change and has access on D: going to D1: no matter what... then his copy of 3.2G is not correct.......

 

I think that is the answer to the question the OP was after.... and perhaps a bad or fake 3.2G is out there.... FJC might want to compare his copy with GoodbyteXL copy and we all should check what we have.... Thank you for helping make the mud become clear!

 

As is almost always the case... FlashJazzCat not only knows and figures out what is suppose to be but has a knack for explaining it more clearly on a level all can understand.... FJC's last understanding and explanation is the best by far.

Edited June 4, 2016 by _The Doctor__

[GoodByteXL]

As mentioned above, I'm seeing the desired behaviour here with 32G, and it pervades to - for example - CIO calls from BASIC. If I log D5: at the command prompt, subsequent references to "D:" refer to "D5:", as does opening a file on "D:" from BASIC.

Received the 1994 shareware distribution disk more than 2 decades ago, paid the fee but never got any feedback on it nor the promised manual.

Just did a quick try on real hardware using BASIC XL. From SDX it refers to the current drive/path when asked per DIR to display the contents of the current drive/path.

 

This is not going to happen with my copy of SD 3.2G. If there are different copies around it might help to upload them here to see if there are differences. Attached the ones I have.

 

 

A_SD_3-2F_complete_disk.ATR

B_SD_3-2G_3-2Gx.ATR

[flashjazzcat]

Just did a quick try on real hardware using BASIC XL. From SDX it refers to the current drive/path when asked per DIR to display the contents of the current drive/path.

 

This is not going to happen with my copy of SD 3.2G. If there are different copies around it might help to upload them here to see if there are differences. Attached the ones I have.

You're right: unfortunately I was in a hurry this morning and forgot there was a volume on D1:. "D:" only refers to a logged drive other than D1: from the Sparta 32G command prompt - not from the CIO. However, the hint is in the original changelog:

 

A filespec that does not contain a

drive number, such as D:TEST, will

now default to your currently logged

drive on the command line.

The change must simply have referred to the command line and not the CIO, which seems inconsistent but there it is. Slightly more convenient on the command line since you can then omit the device specifier completely and when "D:" is prepended by the parser, the filespec will refer to the logged drive instead of drive 1.

[GoodByteXL]

You're right: unfortunately I was in a hurry this morning and forgot there was a volume on D1:. "D:" only refers to a logged drive other than D1: from the Sparta 32G command prompt - not from the CIO. However, the hint is in the original changelog:

 

 

The change must simply have referred to the command line and not the CIO, which seems inconsistent but there it is. Slightly more convenient on the command line since you can then omit the device specifier completely and when "D:" is prepended by the parser, the filespec will refer to the logged drive instead of drive 1.

I see - so it's useless at least in my view. Or could this be used e.g. in a BASIC program?

[flashjazzcat]

Nah... it's not gonna be any use outside of the command line. Probably not too hard to patch the CIO handler, though.

[rcamp48]

Is it possible to use IF Then statements in Spartados 3.2G batch files?

 

[+bf2k+]

On 6/24/2022 at 1:10 AM, rcamp48 said:

Is it possible to use IF Then statements in Spartados 3.2G batch files?

 

No.