MyDos Versions for Hard Disks?

[1050]

Thanks FJC, just the caliber of information I need too.

 

You should know that xio 41 in MyDOS only worked from the DUP.SYS menu before Beta4. But it should be fully working for BASIC or 3rd party apps in Beta4, so your 'current implementation problem' should yeild different results now. Please do see if it needs more work or not. That's why it's called beta - it works as far I can test it, your mileage my vary though.

 

Can you describe more fully just how you are 'opening "Dn:"'? Just curious.

[flashjazzcat]

You should know that xio 41 in MyDOS only worked from the DUP.SYS menu before Beta4.

I find this surprising, since The Last Word has successfully used XIO 41 in MyDOS since 1999. It wasn't a case of the command not working, but the manner in which it worked (described below).

 

But it should be fully working for BASIC or 3rd party apps in Beta4, so your 'current implementation problem' should yeild different results now. Please do see if it needs more work or not. That's why it's called beta - it works as far I can test it, your mileage my vary though.

I can't wait to have a look!

 

Can you describe more fully just how you are 'opening "Dn:"'? Just curious.

Sure. A good example is simply opening the directory for read (as would any file selector). If you open "D:*.*" you get a listing of whatever drive / folder the user set as the "working directory". However, if you open "D1:*.*", you get the root of D1, regardless of what drive / folder has been set as the working directory.

 

In The Last Word, as a result, in order to navigate the directory tree using the disk menu, it's been necessary to:

 

1) Catalogue the root dir of the desired drive (by specifiying Dn:[mask])

2) Highlight a folder in the root directory, then select it with [Return]. This causes the selected folder to become the current working directory and the drive to be recatalogued.

3) Normally, at this point, the user sees the files / folders in the selected directory. Not so in MyDOS. It's now necessary to change the drive spec from "Dn:" to "D:". The disk is read again, and finally we see the files in the folder we selected earlier.

4) In order to access another drive, it's necessary to repeat the above steps, starting at the root directory of the selected drive.

 

It's "conventional" to have a "working directory" for each drive on the system. We get at each working directory by specifying "Dn:" without a path. As for the drive specifier without a number (i.e. "D:"), we might simply (as does SDX) allow the user to specify the default drive. If the user specifies that the default drive is "D3:", for example, all references to "D:" will go to drive 3 (the current working directory thereof, NOT necessarily the root).

 

MyDOS evidently already keeps track of which directory is attached to "D:", so I'm assuming to do the same across eight drives, we' need to maintain eight sector pointers, one for the working directory of each drive. As far as returning the working path for a given drive via an XIO call (which isn't currently possible), even if this has to be done iteratively (i.e. starting at the root of the drive and collecting the directory names, appending them to the path as we go, until we hit the "working" directory pointed to by the sector pointer mentioned above), this would be an acceptable way of going about it (I'm assuming here that there simply isn't room to keep eight dynamic "current path" buffers in RAM).

 

IIRC, MyDOS supports CWD "D:<" to back up one level in the directory tree, so presumably there is some back-tracking hierarchical mechanism in place, for one drive ("D:") at least.

Edited August 14, 2011 by flashjazzcat

[flashjazzcat]

Just been having a look through the source code and CDIREC is a 16 bit pointer to the "current" directory. The routine GETFMN, for example, checks for "D:" or simply ":" (the latter being shorthand for the default drive / directory), and if found, calls SETDIR with CDIREC in A, Y. It shouldn't be too difficult to make CDIREC into an 8 element array, and do the SETDIR lookup for "Dn:". PIKDIR is used to set the default directory, and this routine sets CDIREC. In addition, it ought to be possible to reuse an augmented version of TONXDR (which digs recursively into nested directories) to implement XIO 48.

 

Of course such modifications would have to be implemented in a very economical fashion, and code size optimizations might be required elsewhere to make room.

 

This is rather interesting, from Mathy's site:

There is an area of 2kB between dos.sys and dup.sys that is used as a 'resident driver's buffer'. This is the area where eight hard drives are supposed to be set up with all their percom blocks, sector skews, etc. But with the Black Box, there is nothing there, just empty space. It's never used for modern systems at all, and I wonder if it EVER was used in any system at all. I wouldn't know how to hook up a hard drive directly to an 8bit such that it would be detected by these hard drive routines and I wonder about reclaiming this area sometimes. Have you ever seen any documentation on hooking up hard drives without the BB, MIO, Supra or other device first, other than Woolley's IDE? How about floppies other than SIO units like the 810, 1050, rana, etc., and/or BB floppy board? If those days never really existed for the 8bit, then reserving 2kB between DOS and DUP seems rather stupid doesn't it? I'm not burning up to change this, yet I must ask the question, why do it?

Edited August 14, 2011 by flashjazzcat

[drac030]

As Mathy points out too, one can retrograde your subdirectory path by one directory at a time by using :: as a chosen path to set the default directory to. As in MS-DOS's use of 'cd ..' to do the same thing in a similar manner.

 

So, provided that ':' is also a path separator in MyDOS, to have an equivalent of MS-DOS 'cd ..\..\..' you have to type '::::::::' ?

 

The "resident's driver buffer" is probably reserved for a device driver which the OS attempts to load just after the DOS itself is booted.

[flashjazzcat]

So, provided that ':' is also a path separator in MyDOS, to have an equivalent of MS-DOS 'cd ..\..\..' you have to type '::::::::' ?

Going back up one level can be accomplished with "<" (as with SpartaDOS), but whether "<<<" would take you back three levels, I'm unsure.

[Roydea6]

I would like to have the MyDOS program that needs to be buried three directories deep. Or even look for data at that level.

 

[flashjazzcat]

I would like to have the MyDOS program that needs to be buried three directories deep.

It was written, and executed once, but never seen since.

[1050]

 

Sure. A good example is simply opening the directory for read (as would any file selector). If you open "D:*.*" you get a listing of whatever drive / folder the user set as the "working directory". However, if you open "D1:*.*", you get the root of D1, regardless of what drive / folder has been set as the working directory.

 

In The Last Word, as a result, in order to navigate the directory tree using the disk menu, it's been necessary to:

 

1) Catalogue the root dir of the desired drive (by specifiying Dn:[mask])

2) Highlight a folder in the root directory, then select it with [Return]. This causes the selected folder to become the current working directory and the drive to be recatalogued.

3) Normally, at this point, the user sees the files / folders in the selected directory. Not so in MyDOS. It's now necessary to change the drive spec from "Dn:" to "D:". The disk is read again, and finally we see the files in the folder we selected earlier.

4) In order to access another drive, it's necessary to repeat the above steps, starting at the root directory of the selected drive.

 

It's "conventional" to have a "working directory" for each drive on the system. We get at each working directory by specifying "Dn:" without a path. As for the drive specifier without a number (i.e. "D:"), we might simply (as does SDX) allow the user to specify the default drive. If the user specifies that the default drive is "D3:", for example, all references to "D:" will go to drive 3 (the current working directory thereof, NOT necessarily the root).

 

MyDOS evidently already keeps track of which directory is attached to "D:", so I'm assuming to do the same across eight drives, we' need to maintain eight sector pointers, one for the working directory of each drive. As far as returning the working path for a given drive via an XIO call (which isn't currently possible), even if this has to be done iteratively (i.e. starting at the root of the drive and collecting the directory names, appending them to the path as we go, until we hit the "working" directory pointed to by the sector pointer mentioned above), this would be an acceptable way of going about it (I'm assuming here that there simply isn't room to keep eight dynamic "current path" buffers in RAM).

 

IIRC, MyDOS supports CWD "D:<" to back up one level in the directory tree, so presumably there is some back-tracking hierarchical mechanism in place, for one drive ("D:") at least.

I'm pretty sure that MyDOS doesn't do CWD "D:<", even beta4, but I never think to try these Sparta things so I can't say for sure. Maybe it always could and my 'idea' isn't so new! The MyDOS subdirectory character has always been ":", Puff just added support for some greater than signs to be used but I haven't gone there at all. Only single directory recursions are possible unless you purposely foul with the DUP.SYS's, R. Pick Directory option choice and force the default drive to return to the root by naming an illegal directory for example or some other such high-jinks. Even then no one gets a guarantee of anything. You broke it, you buy it, it's yours now. And don't do that.

 

The recursion occurs as the DNAME text is zeroed from the end and a new xio 41 call is made for the 'new' shortened directory. ONLY one recursive step at a time is allowed unless you want to bloat memlo for this feature and I don't. If you want to go more than once, you'll just have to do it again. OR issue a totally new xio 41 call with the very much shortened directory string. Which then alters the current sector number kept in CDIREC.

 

Your 'conventional' example describes MS-DOS but is NOT how MyDOS ever worked though. In order to get it to work like this I'm thinking the 40 byte string buffer needs to be expanded into a 360 byte buffer raising memlo way more than a page and we just made it next to unworkable.

 

The 'fix' made to beta4 was that MyDOS would not attempt to change drive numbers and subdirectories at the same time with a single xio 41 call while booting - now it can do that trick while still booting AND the single step recursion thing with "::".

 

Your interesting suggestion for a methodology to hold eight paths from 16 bytes stored in ram is a potentially massive amount of data to be read in looking for all possible directory paths and reading in each of them in turn until finally a connecting match is found - even if you can use current routines for most of the work, the added code is likely to approach the 360 byte size that the much simpler eight additional text buffers would cost. I'm doubtful that it can be done in a competitive amount of code space. But I'll be looking at those named routines a bit differently from now on, to see if I can see what you saw.

 

My proposed xio 48 call for the current MyDOS would simply be to move the start address for the DEFAULT/DNAME text string buffer into the IOCB block (icbal,h) that register X has been set to (provided the IOCB block is already closed) along with the string length data (icbll,h), returning with register X unchanged - and that should be all that is required? Very easy to do that much. If we had the space for eight more text buffers to hold the default path strings for each drive (ramdisk can take D9:), it would take just a little more code to query for the drive # and do it just for that buffer as done above.

 

Something else would have to be gutted severely in order to get the room to have MyDOS behave as MS-DOS does as regards to subdirectories during changing of the default drive. I'm always looking for something to gut though. And the behavior desired is sure enough noble. We should do it if at all possible.

[flashjazzcat]

I'm pretty sure that MyDOS doesn't do CWD "D:<", even beta4, but I never think to try these Sparta things so I can't say for sure.

I always assumed the left wedge was supported, but I find directory navigation so cumbersome I mustn't have tested it thoroughly when developing The Last Word. I just made a concerted effort to try it out now with a copy labelled 4.53.3 and it doesn't work. The Last Word attempts a CWD "D:<" and although no error is returned (?), nothing happens - I'm still looking at the contents of D2:EXAMPLES.

 

Maybe it always could and my 'idea' isn't so new! The MyDOS subdirectory character has always been ":", Puff just added support for some greater than signs to be used but I haven't gone there at all. Only single directory recursions are possible unless you purposely foul with the DUP.SYS's, R. Pick Directory option choice and force the default drive to return to the root by naming an illegal directory for example or some other such high-jinks. Even then no one gets a guarantee of anything. You broke it, you buy it, it's yours now. And don't do that.

Sounds like it left the factory broke (rather like The Last Word's support for MyDOS).

 

The recursion occurs as the DNAME text is zeroed from the end and a new xio 41 call is made for the 'new' shortened directory. ONLY one recursive step at a time is allowed unless you want to bloat memlo for this feature and I don't.

I'm not too fussy about multiple recursions in a single call. Just as long as it works, given that I get nagged to support MyDOS when writing applications which do a lot of directory tree traversal.

 

If you want to go more than once, you'll just have to do it again.

On the other hand, if a function was written to do it once, surely the parser could call the same routine for each "<" it encounters in a path string.

 

...OR issue a totally new xio 41 call with the very much shortened directory string. Which then alters the current sector number kept in CDIREC.

Ah yes... CDIREC...

 

Your 'conventional' example describes MS-DOS but is NOT how MyDOS ever worked though.

I'm aware MyDOS never worked this way, but I'm finding the directory handling features "incomplete" and a PITA to code around. I can only assume that those who still use MyDOS on a regular basis simply don't "go there" when it comes to using the current working directory in any practical way. However, I'd love to see it improved, which is why I started looking into all this.

 

In order to get it to work like this I'm thinking the 40 byte string buffer needs to be expanded into a 360 byte buffer raising memlo way more than a page and we just made it next to unworkable.

I was thinking better to get rid of the string buffer altogether and build it on the fly whenever CIO gets asked what the path is for a given drive. DOS would already have a pointer (CDIREC) to the current directory for a given drive.

 

The 'fix' made to beta4 was that MyDOS would not attempt to change drive numbers and subdirectories at the same time with a single xio 41 call while booting - now it can do that trick while still booting AND the single step recursion thing with "::".

So - what should an application issue via XIO 41 to go back up one directory level? "D:::"?

 

Your interesting suggestion for a methodology to hold eight paths from 16 bytes stored in ram is a potentially massive amount of data to be read in looking for all possible directory paths and reading in each of them in turn until finally a connecting match is found - even if you can use current routines for most of the work, the added code is likely to approach the 360 byte size that the much simpler eight additional text buffers would cost. I'm doubtful that it can be done in a competitive amount of code space. But I'll be looking at those named routines a bit differently from now on, to see if I can see what you saw.

Apart from bug fixes, I haven't seen a great deal change in MyDOS so I think these added features might be pretty interesting for MyDOS fans. In my experience, there is often a surprising amount of code space which can be regained with the benefit of hindsight when applied to "old" code, but the question is whether anyone's up for having a go. I certainly don't claim to be sufficiently familiar with the MyDOS sources yet to be able to blithely claim that this or that should be done and that it will be easy.

 

My proposed xio 48 call for the current MyDOS would simply be to move the start address for the DEFAULT/DNAME text string buffer into the IOCB block (icbal,h) that register X has been set to (provided the IOCB block is already closed) along with the string length data (icbll,h), returning with register X unchanged - and that should be all that is required? Very easy to do that much. If we had the space for eight more text buffers to hold the default path strings for each drive (ramdisk can take D9:), it would take just a little more code to query for the drive # and do it just for that buffer as done above.

It would be certainly be useful to at least query "D:" and find out where it points (i.e. which directory and on which drive). We could then display this information in a file selector, along with the filemask. Without individual paths on a per-drive basis, however, we're still stuck with the situation of cataloguing a different drive number and then having to assign "D:" to a directory on that drive, before changing the device ID from "Dn:" to "D:" to make the contents of that directory visible (when using XIO 41, at least: of course we could dispense with CWD calls altogether and process each drive using absolute paths, but this means the application itself then has to keep track of eight or nine complete path strings). If we could at least assign "D:" to a drive number without having to CWD into a folder, a file selector could then set "D:" to whatever drive # the user selects, then simply display the root of "D:". Any subsequent XIO 41 calls would then work as expected, without the user having to drop the drive number to see what's inside the folders. I guess, though, at the end of the day a file selector could be "smart" and automatically omit the drive number as soon as the user selects a folder in a drive's root directory. Unfortunately this is just the kind of special-case coding that I want to avoid when designing software which works with as many DOSes as possible.

 

Something else would have to be gutted severely in order to get the room to have MyDOS behave as MS-DOS does as regards to subdirectories during changing of the default drive. I'm always looking for something to gut though. And the behavior desired is sure enough noble. We should do it if at all possible.

Great! I'm sure it can be done, but I'm not volunteering myself right now, so I'm prepared to be proved wrong.

Edited August 15, 2011 by flashjazzcat

[drac030]

I'm aware MyDOS never worked this way, but I'm finding the directory handling features "incomplete" and a PITA to code around. I can only assume that those who still use MyDOS on a regular basis simply don't "go there" when it comes to using the current working directory in any practical way.

 

What comes to mind is that MyDOS does not really support hierarchical directories. What it does support may perhaps be called "multiple flat directories": everything is fine as long as every single program is contained in one directory. I.e. this is prepared for old-style programs, which did not use subdirectories because DOS 2.0 did not support them. When a new-style program wants to use MyDOS directories in a more sophisticaed way, "stairs begin" (so to speak).

[flashjazzcat]

What comes to mind is that MyDOS does not really support hierarchical directories. What it does support may perhaps be called "multiple flat directories": everything is fine as long as every single program is contained in one directory. I.e. this is prepared for old-style programs, which did not use subdirectories because DOS 2.0 did not support them. When a new-style program wants to use MyDOS directories in a more sophisticaed way, "stairs begin" (so to speak).

That seems to me a perfect description of the situation.

[1050]

So - what should an application issue via XIO 41 to go back up one directory level? "D:::"?

Goodness no!! If you use the full filespec starting with "D", be sure to use the drive number, one semi-colon, and then the full path and this would be as explicit as possible. I don't think that there is an explicit method entry then to back up one directory, unless you've used the old path and shortened that manually - that WILL work. Leaving the only other way to do it via a relative path method and the proper entry there is just "::".

 

I would have answered earlier but my dialup speeds led to a server error last week and my real life got in the way again too. Thankfully the information I supply is not too critical.

 

Apart from bug fixes, I haven't seen a great deal change in MyDOS so I think these added features might be pretty interesting for MyDOS fans.

We can hope!

Unfortunately this is just the kind of special-case coding that I want to avoid when designing software which works with as many DOSes as possible.

I thought about other ways software could 'get by' with MyDOS too, but ultimately the problem is with MyDOS and it should be fixed such that software runs pretty much the same for both platforms.

 

Great! I'm sure it can be done, but I'm not volunteering myself right now, so I'm prepared to be proved wrong.

I really didn't think you were volunteering to start with, but very interesting to see how you would go about it, lots of drive access and scratch pad use too, building all possible paths. Again, I'll look at those routines differently from now on.

[+Larry]

The recent thread for the SUPRA version 4.0 of MyDos got me motivated to start digging through my MyDos archives.  Here is a PDF of my version 4.1 docs that I scanned.  I have not seen an early 4.x version docs posted previously. Note also that the (SUPRA) 4.0 and 4.2 MyDos images were posted early in this thread.  I'm going to try to sort through all my images and get some better insights.  I'll update this thread as I find things that I think would be of interest.

MyDos 4.1 Docs.pdf

[evilmoo]

On a whim, I went looking up the author of MyDOS and found this: http://www.marslett.com/mydos.html

[Mathy]

Hello guys

 

Something tells me "MyDOS for Hard Disks" is just MyDOS with all the options preset to "hard disk" by Supra Corp.  Nothing special about "MyDOS for Hard Disks".  But that's just a feeling.

 

Sincerely

 

Mathy

[+Larry]

Hi Mathy-

 

IMO there are two major differences. The biggest is that as far as I've been able to test/determine, no version 3.x MyDos supported high capacity drives (or ramdisks, either). All 4.x versions support both. One of the effects was that 4.x versions got much larger (and have continued to grow). 

 

The one caveat is that I've never found 3.13b for the ATR8000, which supposedly supported a HD through CP/M. (???)  So I don't really know how it worked. And when I had an ATR 8000, I *really* searched to find 3.13b and set up a CP/M HD system (which supposedly only worked with one obscure SASI controller). No luck. Bummer!

 

Nor do I know much of anything about ROMDOS, but now that I have a copy, I plan to find out more about its features. 

 

Subdirectory support was added around 3.09, but resulted in little increase in size. (Being limited to floppy disks, subdirectories didn't seem to bring much to the table at that point.)

 

One of the features that I've always liked a lot -- pressing 1-8 to get that drive's directory or the asterisk key for the current working directory -- also started with 4.x.  And of course, the MyDos 64 file limit is still present in all versions. 

 

Although I didn't originally think of it, MyDos versions for hard disks like SUPRA also included HD utilities not found on the "generic" versions. My first HD system was an MIO, but all of its utilities were supplied by ICD.  So happy I purchased the MIO rather than SUPRA, but that's just an opinion.

 

Well, didn't intend for this to be so long.  And I wonder if Charles Marslett ever did one of the Atari interviews?  That would be neat!

[1050]

There is support for 77 track drives which I tend to think might be some flavor of original 8 inch drives, but have nothing other than a hunch about that.

 

And then one can specify huge sector counts in a drive table that lends itself to mounting 16 meg ATR files as one of those drives quite nicely. Perhaps this method of putting in obscene values into the standard configure drive method was meant for "hard drives"?

 

The code for 4.1 (1985) still contained bugs that would not allow full function of a 16 meg drive properly. In 1988 and with 4.50 those bugs were addressed and fixed by Puff. The odd hard drive table above is still in play as well.

 

Larry, you can also press * to get a directory of the default directory, which if it's pointing at some subdirectory can be handy too.

[Frankie]

On 5/30/2020 at 2:35 AM, Larry said:

Hi Mathy-

 

IMO there are two major differences. The biggest is that as far as I've been able to test/determine, no version 3.x MyDos supported high capacity drives (or ramdisks, either). All 4.x versions support both. One of the effects was that 4.x versions got much larger (and have continued to grow). 

 

The one caveat is that I've never found 3.13b for the ATR8000, which supposedly supported a HD through CP/M. (???)  So I don't really know how it worked. And when I had an ATR 8000, I *really* searched to find 3.13b and set up a CP/M HD system (which supposedly only worked with one obscure SASI controller). No luck. Bummer!

 

Nor do I know much of anything about ROMDOS, but now that I have a copy, I plan to find out more about its features. 

 

Subdirectory support was added around 3.09, but resulted in little increase in size. (Being limited to floppy disks, subdirectories didn't seem to bring much to the table at that point.)

 

One of the features that I've always liked a lot -- pressing 1-8 to get that drive's directory or the asterisk key for the current working directory -- also started with 4.x.  And of course, the MyDos 64 file limit is still present in all versions. 

 

Although I didn't originally think of it, MyDos versions for hard disks like SUPRA also included HD utilities not found on the "generic" versions. My first HD system was an MIO, but all of its utilities were supplied by ICD.  So happy I purchased the MIO rather than SUPRA, but that's just an opinion.

 

Well, didn't intend for this to be so long.  And I wonder if Charles Marslett ever did one of the Atari interviews?  That would be neat!

Here is MyDos 3.18 for ATR8000 RS232 Version. Not sure if that's what your looking for.

MYDOS318.atr

[Mathy]

Hello Frankie

 

3 hours ago, Frankie said:

Here is MyDos 3.18 for ATR8000 RS232 Version. Not sure if that's what your looking for.

MYDOS318.atr 90.02 kB · 4 downloads

 

Is that the disk as it came from Charles Marslett or did you add the other files (everything except DOS.SYS and DUP.SYS) yourself?

 

Sincerely

 

Mathy

Edited May 31, 2020 by Mathy

[Frankie]

1 hour ago, Mathy said:

Hello Frankie

 

 

Is that the disk as it came from Charles Marslett or did you add the other files (everything except DOS.SYS and DUP.SYS) yourself?

 

Sincerely

 

Mathy

Got it from here http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/mydos-3-18-atr8000/

 

[Frankie]

Or here, I can’t remember anymore

http://atarionline.pl/v01/index.php?ct=utils&sub=8. DOS-y&tg=Sources

 

[+Larry]

Thanks, Frankie.  The elusive one is 3.13b -- if you or anyone else ever comes across it. 

[Frankie]

Here is 3.13 ... but no B

MYDOS313.atr

[+Larry]

Thanks, again.  I'll check this one out.  I have a 3.013, but all it has is DOS and DUP on it.  This has a lot more. 

 

Presume you have an ATR8000?  When did you get it?  (Wow, they are big!)  I never used mine much, but when I did (mostly for testing stuff), I used it with a couple of 40-track Percom drives (DS/DD, half-height).  I miss it now and then, but wow, they sure took up a lot of space to store!

 

 

[+CharlieChaplin]

Just curious, now that we have several versions of MyDOS 3.x and 4.x - was there ever a MyDOS version 1.x or 2.x ?!?