SpartaDos X and basic OPEN command

[Roydea6]

ATARI BASIC

 

10 DIM A$(20),B$(64)
20 CLOSE #1:OPEN #1,6,128,"DC:*.*"
30 TRAP 30:INPUT #1,B$:A$=B$(14,18)
40 ? B$
50 IF A$(5,5)>">" THEN END
60 GOTO 30

 

With out the TRAP statement I keep getting an error. The Manual version 4.47 talks about it but not about the TRAP statement.
Is there any way to not have the words

 

Volume: BOOTC
Directory MAIN

 

I want to bypass the first two INPUT B$

 

 

[flashjazzcat]

The formatted directory listing includes a few blank lines which cause the substring assignment in line 30 to fail, so you need to check that the string isn't empty. You can skip the first two entries by just maintaining a counter and only printing the third non-blank entry onwards.

[Roydea6]

 

My first attempt to view partition folders in one go.

 

 

My final tweaks to this program to view SDX partitions instead of using DIR E: run CATSDX and get a directory of a full partition all folders.

 

and a fix tweak for disk base SpartaDos.

 

Edited February 19, 2016 by rdea6

[flashjazzcat]

That's a pretty nice tool, and is a useful alternative to TREE /F (SDX toolkit) for those who require a more detailed listing than that utility provides.

[Roydea6]

That's a pretty nice tool, and is a useful alternative to TREE /F (SDX toolkit) for those who require a more detailed listing than that utility provides.

Maybe you could reverse engineer it with real ASM or MAD SDX compliant code for us all to use. I have never gotten into machine language code except for small snippets for Basic Code.

[flashjazzcat]

Maybe you could reverse engineer it with real ASM or MAD SDX compliant code for us all to use. I have never gotten into machine language code except for small snippets for Basic Code.

 

I wouldn't really want to reverse engineer any of the SDX tools (far nicer to politely ask DLT for illumination, or request an extra switch to make TREE display more information), but skeleton code for these kinds of command line tools would probably be very useful indeed, if only I could find time to sit down and prepare it. Your tool is very nice as is, however.

[drac030]

I think rdea6 wanted to say that you perhaps could reverse engineer his program in assembly.

 

The program looks interesting indeed, but after trying it I think it might need some more development. If I run the compiled version, and press C or example, the program appears to hang while listing the third subdirectory from my drive C:. It lists 14 files, then it stops, and does not react on keypresses. The reason might be that the 15th file in this directory is named ".BAT" (no fname part, just the ext).

 

On another drive it goes to Morbovia while listing a directory which consists of 49 subdirectories only. After few first dirs listed the listing gets lightly screwed then it turns to complete garbage. After a while of producing this, the program hangs. I of course do not know what is the real reason for these problems, just trying to descrbe what may be peculiar about the circumstances. On yet another drive the program seems to hang for no visible reason - it might be however that the problem is a subdirectory with an extension in the name (DEMOS.ATR ... <DIR>). On yet another case it seems to hang encountering an empty subdirectory.

 

I am not writing all this to criticize you, rdea6. I know that recursive scanning is not an easy task, and I remember that I got trapped in some of these myself in the past (while developing COPY.COM for example) It is rather admirable that a BASIC program is able to do that. There still are some bugs to fix as it appears.

 

Also, after seeing the initial prompt, I cannot seem to find a method to leave the program without listing anything. The program does not seem to react on anything except drive numbers, and it is reset proof. It can only be terminated after it listed the contents of at least one directory and found nothing more of them. This is a problem when the program happens to have a problem and never completes the required task.

 

Also, the LST listing in the ARC archive looks broken.

 

In SDX there is the MENU, which allows to review the directory trees. I know however that the program is not perfect, as not everything it wants to load does fit in the buffer it has. FIND *.* lists all files, but does not display anything besides path/filename. TREE is practically the same as in the SDCS. So, there probably is some room for yet another tool to list directories, yet.

[Kyle22]

I also noticed the garbage on screen after a few directories were listed.

[flashjazzcat]

I think rdea6 wanted to say that you perhaps could reverse engineer his program in assembly.

You think? Well - disassembling compiled BASIC is no more appealing.

 

Since we're talking about recursive directory scans, what's your approach in - say - COPY.COM, Konrad? Back when I wrote some SDX tools which recursively scanned directory trees, I'd use some simple stack mechanism to keep track of the nesting, but also kept opening new IO channels for each new nesting level so I could temporarily read the child folder. This worked fine if - say - there were no more than half a dozen levels of nesting, but what's the method used in COPY.COM? Aside from reading entire catalogues into RAM or building a list of child folders as they are encountered (to be opened later, completely changing the resulting output), I suppose one could push the file pointer onto a stack when encountering a child folder, close the parent, open the child, and so on. When going back up one level, the parent directory could be re-opened and the saved file pointer restored.

Edited February 20, 2016 by flashjazzcat

[drac030]

 

 

I suppose one could push the file pointer onto a stack when encountering a child folder, close the parent, open the child, and so on. When going back up one level, the parent directory could be re-opened and the saved file pointer restored.

 

That is the exact method COPY.COM uses. The main advantage (apart from the fact that it never runs out of file handles) is low memory footprint, nearly all you need is a small stack.

[flashjazzcat]

Here's something I dug up from years ago:

 

qcd.zip

 

It's modelled after some arcane directory changing tool I saw on my dad's (already ancient) PC-XT in the mid Nineties. I fear it's full of bugs but I still have the source code. Usage:

 

QCD directory_name

 

Performs a recursive scan of the directory tree of the logged drive and attempts to CWD into the first matching folder it finds.

 

QCD

 

With no parameters, opens an interactive interface with a tree display of the current drive.

 

The program writes a map of the tree hierarchy of the logged drive to a file, in an attempt to speed things up the next time it's called. If the directory structure of the disk changes, the tree must be re-logged so the cache can be rebuilt.

[morelenmir]

A very nice little tool FJC!!!

 

Is it possible the original you saw your father using came from the cover disk of an issue of PCW in April 1994? If so I think I have that same utility somewhere in my file archive!

[flashjazzcat]

Possible. I wrote two versions of this, both inspired by PC utilities. The original just popped up a window right at the DOS prompt containing a scrolling list of all the folders in the current directory with a selection bar. More useful today with the proliferation of hard disks than back then when I had nothing larger or faster than a 360K floppy.

 

The idea of caching the directory tree in QCD was lifted from CentrePoint Software's PC Tools for DOS, IIRC.

[flashjazzcat]

I think the tool as it stands must have been inspired by Norton Change Directory:

[Roydea6]

I think rdea6 wanted to say that you perhaps could reverse engineer his program in assembly.

 

The program looks interesting indeed, but after trying it I think it might need some more development. If I run the compiled version, and press C or example, the program appears to hang while listing the third subdirectory from my drive C:. It lists 14 files, then it stops, and does not react on keypresses. The reason might be that the 15th file in this directory is named ".BAT" (no fname part, just the ext).

 

On another drive it goes to Morbovia while listing a directory which consists of 49 subdirectories only. After few first dirs listed the listing gets lightly screwed then it turns to complete garbage. After a while of producing this, the program hangs. I of course do not know what is the real reason for these problems, just trying to descrbe what may be peculiar about the circumstances. On yet another drive the program seems to hang for no visible reason - it might be however that the problem is a subdirectory with an extension in the name (DEMOS.ATR ... <DIR>). On yet another case it seems to hang encountering an empty subdirectory.

 

I am not writing all this to criticize you, rdea6. I know that recursive scanning is not an easy task, and I remember that I got trapped in some of these myself in the past (while developing COPY.COM for example) It is rather admirable that a BASIC program is able to do that. There still are some bugs to fix as it appears.

 

Also, after seeing the initial prompt, I cannot seem to find a method to leave the program without listing anything. The program does not seem to react on anything except drive numbers, and it is reset proof. It can only be terminated after it listed the contents of at least one directory and found nothing more of them. This is a problem when the program happens to have a problem and never completes the required task.

 

Also, the LST listing in the ARC archive looks broken.

 

In SDX there is the MENU, which allows to review the directory trees. I know however that the program is not perfect, as not everything it wants to load does fit in the buffer it has. FIND *.* lists all files, but does not display anything besides path/filename. TREE is practically the same as in the SDCS. So, there probably is some room for yet another tool to list directories, yet.

Drac030 just what is a reasonable amount of DIRECTORIES should I make for my program. My current fix has a possibility of 64 Folders.

Fixed the Folder name Xxxxxxxx.xxx problem.

Fixed the filename problem with just a blank filename.EXT extender

I added and escape from TITLE screen any character not 1-9 or A-O and set CAPS ON..

 

sdxfinal.arc

 

With tweaks for SpartaDox x33a also..

 

Edited February 25, 2016 by rdea6

[Roydea6]

dirpart.arc

 

 

I added a command line switch and renamed the file to DIRP.

 

Usage: DIRP /C

DIRP /3

 

and the basic source is here

 

dirp.bas