Current disk device number?

[danwinslow]

What's the best/accepted way to find out what the 'current disk number' is? That is, when opening a file ( via XIO, in this case ) I would like to know what the 'current drive' is. For instance, the drive that a "copy dx:*.*" would wind up copying to. Is there a way to do that that is relatively portable across modern DOS's like RealDos and sparta? Is there an extended XIO code specifically for that?

[Rybags]

It won't be easy. I had a brief discussion with drac030 about it some time ago.

 

I think later SpartaDOS versions might have an XIO that allows to "get working drive".

 

Another possibility could be to Open a file then check what device id/unit # is left in the DCB @ $300.

 

But that in itself isn't a huge help. The SIO device corresponding to D2: may well be mapped to another logical device, e.g. D6: in SpartaDOS, so that method would only give the "absolute" device not the logical one.

[flashjazzcat]

With DOS 2.5, I think "D:" is always drive 1. There's already a discussion on the main forum about how difficult MyDOS makes it to interrogate not only the default drive but the default path. SpartaDOS X has an internal CURDEV variable which represents the current drive number, and if you can get the address of the CURDEV symbol, you can obtain the drive number. This is relatively easy in the most recent SDX versions, but best done from inside native SDX relocatable binaries in the older versions. Another way - in SDX - would be to put a driveless filename in the command line buffer and then call CRUNCH and see what default drive number the routine placed in front of it: it will equate to the current default drive. I don't know how older Sparta versions handled this, since I never used them for long enough to find out. Same goes with RealDOS, but I can have a look into it.

 

 

 

[danwinslow]

Thanks, guys. Its always interesting the things you take for granted that are suprisingly hard. This question revolves around the network utilities I'm developing finding their config file. The file holds ip, dns server, gateway, and some MAC information. It needs to be loaded to start the stack up. So really I'm looking for a reliable way for them to find that file. I would prefer to just keep them all together, so that where ever you launch the program from would be expected to also be where the config file was...but I don't know where that is at run time. I kind of expected that just using D: would default to whatever was current, but it doesn't seem to work that way in sparta or RealDos. I haven't explicitly tested DOS 2.5, but I assume from what Jon said that it would work there.

 

lol, maybe I could parse the screen on the way up to extract the drive from the dos prompt

Edited August 28, 2011 by danwinslow

[flashjazzcat]

I'm not actually 100 per cent sure that the CIO observes the "default" drive number outside of the CP in the case of disk-based SpartaDOS, but you can certainly specify a default on the command line. As I say, in the case of DOS 2.5, D: is always D1:.

 

Like I say - no need to parse the screen. The best across-the-board way of obtaining the default drive in any version of SpartaDOS is probably to put a dummy string in the command line buffer without a device spec in front of it and then call CRUNCH and see what DOS put in front of it.

 

This is the beauty of environment variables in SDX: we can specify where the config files for our apps should go, and tell our apps about it. Sadly, however, we don't enjoy such luxuries with other DOSes...

Edited August 28, 2011 by flashjazzcat

[danwinslow]

I think I'll just cheese it up and require that no matter where the executables are run from, the config file must be in D1: at root.

[+David_P]

Please no! A little extra effort to do it right will save you from dozens of anguished cries like mine!

[drac030]

As far as I know, only MyDOS, SpartaDOS 3.2g and SpartaDOS X implement a concept of "current drive", referred to by "D:". In the rest (including SpartaDOS 3.2d for example), "D:" is equal to "D1:".

[flashjazzcat]

My suggested method of putting a dummy argument in the command line and then calling CRUNCH is really quite simple and works well. The Last Word does it this way with the older SDX versions. Very much worth the effort and not a herculean programming challenge. Everything you need is in the Sparta / SDX manual.

[danwinslow]

My suggested method of putting a dummy argument in the command line and then calling CRUNCH is really quite simple and works well. The Last Word does it this way with the older SDX versions. Very much worth the effort and not a herculean programming challenge. Everything you need is in the Sparta / SDX manual.

 

Sure, but I'm not writing just for people who are using spartados. My goal is to be DOS-agnostic as much as possible.

 

Please no! A little extra effort to do it right will save you from dozens of anguished cries like mine!

 

Effort I don't have a problem with. The problem is, I don't know what 'right' is. What I am doing is to write a bunch of executables to do various internet-ty things like ping, resolve, telnet, etc., that could just get copied onto whatever disks they are using and run under pretty much any DOS. Is that too broad of a goal?

 

a. Should I require people to use a particular dos (ie., spartados) to run the programs?

b. Whats wrong with requiring the config file to be on D1:? In my setup ( Realdos/HD ) it doesn't seem to be much of an issue. I can't think of why it would be a problem, so help me out.

 

As far as I know, only MyDOS, SpartaDOS 3.2g and SpartaDOS X implement a concept of "current drive", referred to by "D:". In the rest (including SpartaDOS 3.2d for example), "D:" is equal to "D1:".

 

I'll have to check those specifically, but for realdos at least I'm not getting anything out of using D:....I'm using some home-gown XIO wrappers to do I/O so maybe I need to re-examine exactly how I'm doing the open's.

[drac030]

b. Whats wrong with requiring the config file to be on D1:? In my setup ( Realdos/HD ) it doesn't seem to be much of an issue. I can't think of why it would be a problem, so help me out.

 

The answer is pretty simple: on a setup without D1: your program won't be able to load the config file.

[fox]

Many programs use SIO DUNIT at $301 for the drive number they were loaded from.

[flashjazzcat]

My suggested method of putting a dummy argument in the command line and then calling CRUNCH is really quite simple and works well. The Last Word does it this way with the older SDX versions. Very much worth the effort and not a herculean programming challenge. Everything you need is in the Sparta / SDX manual.

Sure, but I'm not writing just for people who are using spartados. My goal is to be DOS-agnostic as much as possible.

Quite so. Your software first has to check which DOS it's running under, and only execute this routine if SpartaDOS 3.2g or SDX < version 4.44 are detected. This is part and parcel of writing A8 programs which work with many different DOSes. I don't know why it is that when I explain how a piece of software might accomplish something under SpartaDOS, people think I'm advocating the abandonment of all other DOSes. What I'd really like to encourage is software which works with a variety of DOSes, but doesn't ignore the facilities present in SpartaDOS / SDX (facilities which are too often ignored, IMO). It's perfectly possible to write programs which play well with everything. This increases your user base and generally makes the software even more configurable when it's run under an advanced DOS (and SDX happens to be the most advanced of them all by a country mile, regardless of what anyone says).

 

Here's the routine as it's coded in The Last Word:

 

COMTAB = 10
BUFOFF = 10
LBUF = 63
COMFNAM = 33
ZCRNAME = 3

LDA $701
CMP #$44 ; if SDX version is 4.44 or above, we use the symbol (see next snippet)
bcs no_get_cdrv
LDY #ZCRNAME+1
LDA (COMTAB),Y
STA CRUNCH+1
INY
LDA (COMTAB),Y
STA CRUNCH+2
lda #'A ; use trickery to extract current drive number
ldy #lbuf
sta (comtab),y
lda #155
iny
sta (comtab),y
ldy #bufoff
lda #0
sta (comtab),y
jsr crunch
ldy #comfnam+1
lda (comtab),y
sec
sbc #48
sta curdev
no_get_cdrv


...

CRUNCH
  JSR $FFFF

 

If we detect $44 in $701, however, we may use the following simple method:

 

JCAR_SW  = $7FA
JCAR_OLD = $7FD

LDA #$FF
JSR JCAR_SW ; TURN ON THE CARTRIDGE (ASSUMING THE APPLICATION WAS STARTED WITH THE "X" COMMAND)
lda #< cdsymbol
ldx #> cdsymbol
jsr $07EB
sta ptr1
stx ptr1+1
ldy #0
lda (ptr1),y ; get current drive
sta curdev
JSR JCAR_OLD ; TURN THE CART OFF AGAIN

CDSYMBOL
.BYTE "CURDEV  ",0

 

You might also want to take advantage of SDX environment variables (see the SDX programming docs). Again, this might offer a more flexible experience for the end user, without detracting from the functionality of the software under DOS 2.5, MyDOS, etc. Most of The Last Word's SDX-specific code is in an init block which is jettisoned before the main application loads. The old version 2.0 of The Last Word used to work with SDX, Sparta 3.2, MyDOS, DOS-XE and DOS 2.5, and tailored itself to whichever DOS it was running on. This in no way implied that users were obliged to use it with any particular DOS.

 

Whats wrong with requiring the config file to be on D1:? In my setup ( Realdos/HD ) it doesn't seem to be much of an issue. I can't think of why it would be a problem, so help me out.

Imagine a user (like me) who has a hard disk which boots from drive C. Instant problems.

 

Can you, in fact, not simply use "D:CONFIG.TXT" and thereby care less what the actual unit number is?

Edited August 29, 2011 by flashjazzcat

[Rybags]

Using DUNIT on the surface sounds like the solution, but we have the problem that drive remapping can screw us up.

 

Does any DOS other than Sparta support remapping?

 

If not, then you should be able to determine what logical drive is mapped to the last referenced device (DUNIT) at load time.

 

Another alternative for the whole thing might be to have a Setup program that you run, and it has the user select the drive/path where your config info is to be kept, then patches your executables.

[danwinslow]

My suggested method of putting a dummy argument in the command line and then calling CRUNCH is really quite simple and works well. The Last Word does it this way with the older SDX versions. Very much worth the effort and not a herculean programming challenge. Everything you need is in the Sparta / SDX manual.

Sure, but I'm not writing just for people who are using spartados. My goal is to be DOS-agnostic as much as possible.

Quite so. Your software first has to check which DOS it's running under, and only execute this routine if SpartaDOS 3.2g or SDX < version 4.44 are detected. This is part and parcel of writing A8 programs which work with many different DOSes. I don't know why it is that when I explain how a piece of software might accomplish something under SpartaDOS, people think I'm advocating the abandonment of all other DOSes. What I'd really like to encourage is software which works with a variety of DOSes, but doesn't ignore the facilities present in SpartaDOS / SDX (facilities which are too often ignored, IMO). It's perfectly possible to write programs which play well with everything. This increases your user base and generally makes the software even more configurable when it's run under an advanced DOS (and SDX happens to be the most advanced of them all by a country mile, regardless of what anyone says).

 

Here's the routine as it's coded in The Last Word:

 

COMTAB = 10
BUFOFF = 10
LBUF = 63
COMFNAM = 33
ZCRNAME = 3

LDA $701
CMP #$44 ; if SDX version is 4.44 or above, we use the symbol (see next snippet)
bcs no_get_cdrv
LDY #ZCRNAME+1
LDA (COMTAB),Y
STA CRUNCH+1
INY
LDA (COMTAB),Y
STA CRUNCH+2
lda #'A ; use trickery to extract current drive number
ldy #lbuf
sta (comtab),y
lda #155
iny
sta (comtab),y
ldy #bufoff
lda #0
sta (comtab),y
jsr crunch
ldy #comfnam+1
lda (comtab),y
sec
sbc #48
sta curdev
no_get_cdrv


...

CRUNCH
  JSR $FFFF

 

If we detect $44 in $701, however, we may use the following simple method:

 

JCAR_SW  = $7FA
JCAR_OLD = $7FD

LDA #$FF
JSR JCAR_SW ; TURN ON THE CARTRIDGE (ASSUMING THE APPLICATION WAS STARTED WITH THE "X" COMMAND)
lda #< cdsymbol
ldx #> cdsymbol
jsr $07EB
sta ptr1
stx ptr1+1
ldy #0
lda (ptr1),y ; get current drive
sta curdev
JSR JCAR_OLD ; TURN THE CART OFF AGAIN

CDSYMBOL
.BYTE "CURDEV  ",0

 

You might also want to take advantage of SDX environment variables (see the SDX programming docs). Again, this might offer a more flexible experience for the end user, without detracting from the functionality of the software under DOS 2.5, MyDOS, etc. Most of The Last Word's SDX-specific code is in an init block which is jettisoned before the main application loads. The old version 2.0 of The Last Word used to work with SDX, Sparta 3.2, MyDOS, DOS-XE and DOS 2.5, and tailored itself to whichever DOS it was running on. This in no way implied that users were obliged to use it with any particular DOS.

 

Whats wrong with requiring the config file to be on D1:? In my setup ( Realdos/HD ) it doesn't seem to be much of an issue. I can't think of why it would be a problem, so help me out.

Imagine a user (like me) who has a hard disk which boots from drive C. Instant problems.

 

Can you, in fact, not simply use "D:CONFIG.TXT" and thereby care less what the actual unit number is?

 

? I wasn't implying that you were advocating one DOS over another. I simply said that I wanted to be dos agnostic.

 

I don't know what you mean by 'boot from drive c' in atari terms. Are you saying you don't have a d1:? I'm surprised, but then again I don't really know how most systems are set up in the wild, which is part of why I'm asking.

 

I would love to use D:xxxxx.yyy and not care. As I mentioned, it doesn't seem to be working. I'll re-verify the behavior and that I don't have some kind of problem with my XIO calls.

 

Thanks very much for the code snips, I'm sure they will be useful.

 

Another consideration is that the Dragon is a cart...I'm not sure how many people will be able to run the dragon and an SDX cart together. I think those with a MIO-style extender can, but still need to test that specifically.

 

Many programs use SIO DUNIT at $301 for the drive number they were loaded from.

 

I had a dim notion of exploring that option...good to know it works. Thanks.

 

Another alternative for the whole thing might be to have a Setup program that you run, and it has the user select the drive/path where your config info is to be kept, then patches your executables.

 

Yes...there is going to be a setup program that has to run anyway to ask the user whether they want DHCP or a statically assigned ip, as well as their MAC that they want the dragon to have, so I was considering doing what you suggest.

 

Thanks, all.

[drac030]

I don't know what you mean by 'boot from drive c' in atari terms. Are you saying you don't have a d1:? I'm surprised

 

See post #11. There is no need to have a D1:, and "boot from drive C:" in "Atari terms" means boot from D3:

[danwinslow]

Ah..so SDX actually translates the D3: to C, or is it just commonly referred to as 'C' even though its still really D3:?

Also, why would someone boot from D3: in preference to any other drive, such as D1:? Just wondering.

[Roydea6]

Because I want to leave D1: and D2: open for floppy SIO usage on real 1050's and 810's.

And use 'C: ala D3: as IDE 2.0.

[danwinslow]

Makes sense. Thanks.

[flashjazzcat]

I wasn't implying that you were advocating one DOS over another. I simply said that I wanted to be dos agnostic.

No problem. It's just that I've sensed a trend in the past whereby every time I explain how I'm going to support SDX in a program, certain parties see fit to remind me that "SDX is not the only DOS". I would have thought that my tireless efforts to make LW work with every DOS which doesn't use the Shadow RAM demonstrate that I'm already well aware of that fact. I get really frustrated that it just seems to be KMK himself, me, and a handful of other coders who actually write applications which take advantage of Sparta features. As I've already said, it's perfectly possible to make applications which are "DOS aware", and which give the user the best of both worlds, so to speak. There's nothing worse than firing up an application under SpartaDOS and finding that the file selector can't handle subdirectories. SpartaDOS has been around for what - 25 years?

 

I certainly don't mean to imply that you misunderstand my meaning in this way though, Dan. I'm sorry if that's how it came across.

 

I don't know what you mean by 'boot from drive c' in atari terms. Are you saying you don't have a d1:? I'm surprised, but then again I don't really know how most systems are set up in the wild, which is part of why I'm asking.

KMK has already covered this, but I should have said "D3:". There's absolutely no need to have drive 1 online, though, especially when you're using a hard disk. Consider it in the same terms as a PC with no floppy drive installed.

 

I would love to use D:xxxxx.yyy and not care. As I mentioned, it doesn't seem to be working. I'll re-verify the behavior and that I don't have some kind of problem with my XIO calls.

That would probably have been my preferred approach. Thinking back, the main reason I put a lot of graft into default drives, etc, was more to do with allowing the user to keep configuration files inside sub-folders on those systems which supported them. Then things get really interesting!

 

Thanks very much for the code snips, I'm sure they will be useful.

My pleasure. I hope they're helpful.

 

Another consideration is that the Dragon is a cart...I'm not sure how many people will be able to run the dragon and an SDX cart together. I think those with a MIO-style extender can, but still need to test that specifically.

This is a good question. It's always an argument against putting apps on a cart, but I don't think it's a reason to drop or lessen SDX support in applications. Remember there's the option of upgrading original SDX carts (with pass-thru) to version 4.44 (which I've done); also, we have IntSDX, and the forthcoming Ultimate 1MB. So I'd like to bet there'll be a fair number of potential users who'll want to run the Dragon with SDX. What really troubles me is how we're going to run it with the GUI if the GUI is on a cart.

[danwinslow]

So I'd like to bet there'll be a fair number of potential users who'll want to run the Dragon with SDX. What really troubles me is how we're going to run it with the GUI if the GUI is on a cart.

 

:/ I know, this bothers me as well. I think from a memory standpoint we may be in conflict any ways...it looks like I will need 2-3 banks worth for full TCP, although the UDP stack only needs 1 bank ( or none, if running non-banked ).

 

I think that what we need to do is to work together to implement an asm driver for the device under the GUI. The basic get/put packet operation is very simple. Then I could write a system accessory/app as the target/source for the packets. In other words, I don't see what I am doing now as being able to fit with the GUI in any case. But, all the lessons learned and techniques could be applied to re-engineering it under the GUI..provided that you have a disk-based version of the GUI, or a pass through doohickey, or the MIO extender works, etc. Of course, there's likely to be other ethernet connectivity solutions at hand at some point, and we can replace the driver but keep the stack.

[flashjazzcat]

I think that what we need to do is to work together to implement an asm driver for the device under the GUI. The basic get/put packet operation is very simple. Then I could write a system accessory/app as the target/source for the packets. In other words, I don't see what I am doing now as being able to fit with the GUI in any case. But, all the lessons learned and techniques could be applied to re-engineering it under the GUI..provided that you have a disk-based version of the GUI, or a pass through doohickey, or the MIO extender works, etc. Of course, there's likely to be other ethernet connectivity solutions at hand at some point, and we can replace the driver but keep the stack.

This sounds eminently sensible. It's hard enough making the GUI play nicely with DOS, let alone anything else that's resident.

[drac030]

If we detect $44 in $701, however, we may use the following simple method:

 

JCAR_SW  = $7FA
JCAR_OLD = $7FD

LDA #$FF
JSR JCAR_SW ; TURN ON THE CARTRIDGE (ASSUMING THE APPLICATION WAS STARTED WITH THE "X" COMMAND)
lda #< cdsymbol
ldx #> cdsymbol
jsr $07EB
sta ptr1
stx ptr1+1
ldy #0
lda (ptr1),y ; get current drive
sta curdev
JSR JCAR_OLD ; TURN THE CART OFF AGAIN

CDSYMBOL
.BYTE "CURDEV  ",0

 

BTW. calling jcar_sw before and jcar_old after jsr $07eb seems not necessary. You can save 8 bytes of code

 

Ah..so SDX actually translates the D3: to C, or is it just commonly referred to as 'C' even though its still really D3:?

 

I would say that it is really just a "3", which may be represented as C:, or 3:, or D3: or even DC: in drive specification depending of circumstances (via CIO or not) and of what you prefer.

Edited August 30, 2011 by drac030

[flashjazzcat]

BTW. calling jcar_sw before and jcar_old after jsr $07eb seems not necessary. You can save 8 bytes of code

The code comes straight from The Last Word, hence "TURN ON THE CARTRIDGE (ASSUMING THE APPLICATION WAS STARTED WITH THE "X" COMMAND)".

 

[drac030]

BTW. calling jcar_sw before and jcar_old after jsr $07eb seems not necessary. You can save 8 bytes of code

The code comes straight from The Last Word, hence "TURN ON THE CARTRIDGE (ASSUMING THE APPLICATION WAS STARTED WITH THE "X" COMMAND)".

 

Yes, I noticed the remark. I'll still repeat what I wrote above: "calling jcar_sw before and jcar_old after jsr $07eb seems not necessary. You can save 8 bytes of code".