Created English translation of the Extended Turbo Basic (Turex.com) documentation

[markmiller]

8 hours ago, Brad Nelson said:

I'm trying to create a Turbo-BASIC XL program that will (without going to DOS) allow you to change the directory.

I've been trying this, and I'm stuck like you. I created a dummy directory before entering TB.

 

What I get when I run your program is error 130 - non-existent device at the XIO call. So, I thought about opening a channel before that, using:

130 OPEN #1,6,0,"D:"

The 6 in the 2nd parameter is "disk directory input operation." I then closed the device after the call.

 

This caused a different error, 129 - Is open, meaning "device already open", at the XIO call. I tried opening, then closing the channel before the XIO call, and got error 130.

 

I also tried

130 OPEN #1,6,0,E$

but this gave me error 130, even if I put in "D:" for E$.

 

I ran the XIO call on my directory in direct mode, and it seemed to work. When I ran DIR in TB, I got an empty listing (I assume from an empty directory).

 

If I tried putting the other device modes I know for OPEN in that 2nd parameter (in the first statement): 4,8,12, or 9. They all gave me error 129 - Is open/already open, at the XIO call.

Edited November 29, 2023 by markmiller

[dmsc]

Hi!

7 hours ago, markmiller said:

Just to clarify, I was trying to figure out how, on one hand, you were inputting a float array, and on the other, a single float, having the routine access them the same way. I see with your increment of P (while N>0) that you're actually doing pointer arithmetic, since the way the math package formats floats is as 6-byte BCD. So, rather than just incrementing an index in the array, you're traversing over the individual bytes in it (6 bytes per cell).

Yes, one big limitation of FastBasic compared to C is that there are no "pointer types", only integers. This means that the compiler does not know how to do pointer arithmetic and automatically advance a pointer with the correct amount.

 

Also, in FastBasic arrays are also zero based, so in this regard it is already similar to C.

 

Have Fun!

[dmsc]

Hi!

1 hour ago, markmiller said:

@dmsc - Hmm. Alright. Looks like my problem was I was dimensioning the strings. If I took that part out, the example from the manual works.

Just remember that the biggest difference between FastBasic and Atari BASIC / TurboBasic is that strings are automatic - the memory is allocated when first assigned. And with DIM you define string arrays, so you were trying to assign an string array to a string.

 

Have Fun!

[markmiller]

1 minute ago, dmsc said:

with DIM you define string arrays, so you were trying to assign an string array to a string.

Okay, like with Microsoft Basic's string arrays. Yes, I'm remembering that in MS-Basic, I was able to just use strings without DIMming them, since they were the same length as I see in your manual.

[dmsc]

Hi!

8 hours ago, Brad Nelson said:

Here's a puzzler.

 

I'm trying to create a Turbo-BASIC XL program that will (without going to DOS) allow you to change the directory.

 

The command is straightforward enough. And if you type this in direct mode, it will work fine: XIO 44,#1,0,0,"D1:TBFOLDER"

 

If you want to back up in the directory, it would be: XIO 44,#1,0,0,"D1:.."

 

The problem I'm having is getting this to work in deferred mode (by running the program). The code below doesn't work. The XIO command will not work using a string variable. And I'm out of ideas. Does anyone know a way to make this work?

 

And it's not a case of the E$ string being bad. I've tried this out in another version where it just prints out the whole command (including the XIO part) via a print statement. You can then enter the cursor into this line in direct mode and the command will work. But the XIO command doesn't like taking a string as the directory path in any mode.

 

20 REM MODE DOWN A DIRECTOR: H:FOLDER
30 REM MOVE UP DIRECTORY: H:..
40 DIM DIR$(20),C$(5),E$(40)
50 C$=CHR$(34):REM QUOTE CHARACTER
60 PRINT "ENTER DIRECTORY INFO"
70 PRINT "(NO QUOTES) ";
80 INPUT DIR$
90 REM E$="XIO 44,#1,0,0,"
100 E$(LEN(E$)+1)=C$
110 E$(LEN(E$)+1)=DIR$
120 E$(LEN(E$)+1)=C$
130 DIM A$(100),B$(6)
150 XIO 44,#1,0,0,E$

 

 

You are trying to put quotes inside a string.... this does not make sense. The quotes in your XIO 44,#1,0,0,"D1:TBFOLDER" are part of the language - is the way you declare a string, not par of the string!

 

What you are trying to do is much simpler, this is a full example in 4 lines of TurboBasic XL:

 

 

 

Attached is the sample ATR.

 

Have Fun!

 

 

 

tbasic.atr

[markmiller]

9 minutes ago, dmsc said:

This means that the compiler does not know how to do pointer arithmetic and automatically advance a pointer with the correct amount.

Well, what I implied is it's doing pointer arithmetic, but it treats the float array like one big char array/character buffer. I didn't talk about that in my C example, but it would be like having a char array of 24 bytes, and storing 4 float values in it. In that case, you'd have to advance a char pointer 6 bytes to get over each value.

[markmiller]

6 minutes ago, dmsc said:

You are trying to put quotes inside a string.... this does not make sense.

Okay, just tried it, and it works!

 

I see in your example you used channel #7. That makes sense, too, but channel #1 also works. What was screwing it up was the embedded quotes.

[Brad Nelson]

Thank you, dmsc and Mark. When I got rid of inserting the quotes in my existing program, it worked. The thing is, I thought I had tried that before and it didn't work. But things can get confusing.

 

The idea (or one method) would be to "ENTER" these lines at the bottom of an existing in-progress program (when working in an emulator or real hardware...renumber to start at 10000 or whatever) and call it with a "GOTO" if you needed to change directories. My "H:" drive, for instance, is so full of stuff, I really need to organize it into folders. But because there is no way to access individual files (from Turbo-BASIC XL, anyway), that was problematic. And obviously I'm not talking about disk images which can be manually loaded via an emulator from anywhere.

 

And it would probably be helpful to have this program in the root of one of the spare D drives in case you plunge down into a directory, erase the program that you're working in, and need to change the directory again. By the way, is Channel #7 better to use because it's less likely to conflict with something else?

 

With the superior file handling of FastBasic, this kind of program is not necessary as the directory tree is available by the save or open command (with appropriate colons for the directory path...not sure that this is mentioned in the manual, but if it was, I missed it).

 

So how weird that the solution was so close. But that's computers, for you. I've added a modicum of error handling. For instance, you can't just jump from one directory to another. (And added a trap for just having "H:". It doesn't do any harm but also doesn't do anything.) The XIO 44 command (from what I can see) lets you move only up and down, not sideways, as it were. And I left the input statement the way it was because I wanted it to be compatible with Atari Basic.

 

In theory, the below will be just part of a larger "FileManager" type of program that will also give you directory listings. I have that working except for the trapping. I cannot find a way to TRAP for a non-existent disk in a drive without mucking it up. Somehow it is conflicting with the other trap for loading the directory (which traps for EOF). And because this is bound to be more complex of a solution, I'm averse to asking for more help. But I may post that later and explain the problem I'm having. And many thanks for the help given so far.

 

20 REM MOVE DOWN DIRECTORY: H:FOLDER
30 REM MOVE UP DIRECTORY: H:..
40 REM ENTER <Q> TO QUIT
50 DIM DIR$(20)
60 PRINT "ENTER DIRECTORY PATH"
70 INPUT DIR$
80 IF DIR$="Q" THEN END 
90 IF LEN(DIR$)<4 THEN 130
100 TRAP 130
110 XIO 44,#1,0,0,DIR$
120 END 
130 ? "ENTER VALID PATH":GOTO 60

 

Edited November 29, 2023 by Brad Nelson

[Brad Nelson]

Keeping within the general theme of the dynamic duo, Turbo-BASIC XL and FastBasic, I've been using the operating environment of SpartaDOX X 4.49 lately. I started experimenting with it several months ago.

 

I'm running it as a virtual cartridge via the Altirra emulator. It's been prettied up with a few things such as aliases (via DOSKEY on the toolkit disk). I added the "H:" driver support via adding "PCLink" as a device via Configure System>Devices in Altirra. It's a bit slow but it does at least work.

 

This is (for me) the closest thing to an operating system, proper, that I've seen for the Atari 8-bit. True, it's "just" a disk operating system. But it acts as a central repository to quickly get at your disks (and directories). And launching things (for me) is just so much easier. This may be despite (or because of?) the command-line interface of SpartaDOS X. Whatever the case may be, I have nothing but problems working with Atari's DOS. I just find copying, renaming, etc., to be so much easier and intuitive in Sparta.

 

You can have the Day/Time ever-present via "TD on". (I think you need "R-Time 8" added as a device to make that work, but I forget.) I have all the Manuals unstuffed and set up on the "D5:" or "E:" drive. They are the same. I went with the alphabet convention for drive names just to tr to get used to it.

 

Via autoexec.bat files you can easily enough set some parameters (on you D1:/A: boot-support drive), such as background color, text color, key repeat rate, etc. Some of these (such as key repeat rate) may hold over to TB or FB when you launch them. You can add shortcuts for commands that you find more convenient (such as "LS" for "DIR" or "MOVE" for "COPY /M").

 

I can be a little funky to launch programs. I have an alias to launch TB (with a "TB" alias) from drive 4 (D:). The alias is a shortcut for the commands: D:|X AUTORUN.SYS (as it's named on the disk it's on). You get some garbage on the screen at launch but it appears to be just a cosmetic issue.

 

I also have an alias "FB" for FastBasic. It will launch via the same method ( F:|X FB.COM -EFAST) except that you do get some garbage and glitches on the screen for a while. When I load a program into FastBasic, that will go away. But all the glitches go away (for some reason) if you just first, within SpartaDOS X, go to the F: drive and type X FB.COM. I'm not sure if the -EFAST parameter actually invokes EFAST. But it seems to do no harm. And you will get no garbage or glitches on the screen.

 

Now...for the wish list. One good aspect (certainly not unique to SpartaDOS X) is saving the contents of your Atari Basic program in memory (on the ramdisk) when you exit to SpartaDOS X. This works great, But I would love the means to do so from FB and TB as well. But I've not found anyone doing that or read about any means for making that happen. But it would be a great feature to have. Let me know if you have any ideas.

 

I wouldn't call Sparta completely bug-free. I've had very occasional crashes that I don't think I would have otherwise had. But these things can be difficult to track down as to source. And they are quite few and far between.

Edited November 29, 2023 by Brad Nelson

[markmiller]

3 hours ago, Brad Nelson said:

I really need to organize it into folders. But because there is no way to access individual files (from Turbo-BASIC XL, anyway), that was problematic.

I haven't tried it, but re. TB, you might want to look into MyDOS. It supports hard drives, and subdirectories. It supports a RAMdisk, and allows you to set up a config. file where you can list the files you want autoloaded into it at bootup. Otherwise, it functions a lot like Atari DOS, which I can see is more compatible with TB than Sparta.

 

I used MyDOS many years ago when I was using the CC8 C compiler on the Atari. The reason being I was dealing with a lot of files, and wanted to sort things into subdirectories. I worried about getting things mixed up. It worked great. It doesn't have a command line, though.

 

Re. traps

 

TB has an ERR command you can use to get the last error code. It also has an ERL command, which gives you the line number where the error occurred. You could plug these things into some if-statements to find out what actually happened.

 

Atari Basic has a STATUS command that, from what I read in the manual, is supposed to give you the error code. Since TB fully supports Atari Basic, it has this command, as well.

 

This is reminding me why languages like C++ and Java implemented exceptions. Though, I found the try-catch construct clunky.

 

A different strategy I saw in the Smalltalk system was to make exception handling part of what you're trying to do, rather than something you bolt on to it. As an example, you could do this:

arr at: i ifAbsent: [<do something>].

This is an array reference ("arr" being the array). If "i" is beyond the bounds of the array, you can have it execute a routine to do something (the part in []'s) in response. (In Smalltalk, arrays are immutable. So, you can't add to them if what you want isn't there, but I think this scheme localizes error handling nicely.)

Edited November 29, 2023 by markmiller

[Ray Gillman]

On 3/27/2023 at 1:08 PM, _The Doctor__ said:

feed it to deepl, combine with goog translate and between the two you may end up with a better document to touch up.

Yes if you have a larger document to translate you can make it into an HTML web page, then access the page with Chrome and google should offer to automatically translate the entire HTML for you to save. Technical programming docs can be tricky because of the use of a lot of non-language key words like GOTO which should not be translated

[Brad Nelson]

Thanks for the suggestions, Mark. That did help me to debug a bit. Long story short, after dmsc's and your note about getting rid of the embedded quotes, I reworked the directory part of this utility. And with some of the changes,  it became a Turbo-BASIC XL-only program. I was going to try to make it work with Atari Basic as well. And with relatively minor changes I could do it. But up and running first. Bells and whistles later.

 

And not because it wasn't working or had embedded quotes. But knowing that I could use a variable in the path name, that allowed me to work things into a shorter program. In reworking it, things just started to work correctly. I had some kind of recursive loop happening (most likely) and I just couldn't see it or figure it out. Reworking the code seems to have unstrung it.

 

I included support for both "H1:" and "H2:" drives. I never use more than two but more could be accommodated. And it should be easy enough to add a filtered directory listing. I might try that next.

 

And both the directory-listing and change-directory aspects are now integrated together.

 

10 REM "H1:FILEMGRA.LST"
15 DIM DIR$(20),MSG$(25)
20 DIM ENTRY$(64),DR$(15),C$(5)
30 DIM DRIVE$(25),DLET$(1):C$=CHR$(34)
40 DRIVE$="":DLET$="D"
50 ? "DRIVE (1-8) <Q><CD>: ";:INPUT DR$
60 IF DR$="Q" THEN END 
65 IF DR$="CD" THEN 260
70 IF DR$="H" OR DR$="H1"
80   DLET$="H":DR$="1"
90   GOTO 170
100 ENDIF 
110 IF DR$="H2"
120   DLET$="H":DR$="2"
130   GOTO 170
140 ENDIF 
150 IF ASC(DR$)<49 THEN PRINT CHR$(253);:PRINT "";:GOTO 50
160 IF ASC(DR$)>56 THEN PRINT CHR$(253);:PRINT "";:GOTO 50
170 DRIVE$(LEN(DRIVE$)+1)=DLET$
180 DRIVE$(LEN(DRIVE$)+1)=DR$
190 DRIVE$(LEN(DRIVE$)+1)=":*.*"
195 TRAP 240
200 OPEN #1,6,128,DRIVE$:GOTO 210
210 TRAP 240
220 INPUT #1,ENTRY$:PRINT ENTRY$
230 GOTO 220
240 CLOSE #1
250 GOTO 40
260 REM =============CHANGE DIR
270 REM "H1:CHDIRG.LST"
280 REM MOVE DOWN DIRECTORY: H:FOLDER
290 REM MOVE UP DIRECTORY: H:..
300 REM ENTER <Q> TO QUIT
320 MSG$="ENTER DIRECTORY PATH"
330 PRINT MSG$
340 INPUT DIR$
350 IF DIR$="Q" THEN END 
360 IF LEN(DIR$)<4 THEN 400
370 TRAP 400
380 XIO 44,#7,0,0,DIR$
390 GOTO 40
400 MSG$="ENTER VALID PATH":GOTO 330

 

filemgra.lst

Edited November 30, 2023 by Brad Nelson

[dmsc]

Hi!

6 hours ago, Brad Nelson said:

 

Thank you, dmsc and Mark. When I got rid of inserting the quotes in my existing program, it worked. The thing is, I thought I had tried that before and it didn't work. But things can get confusing.

 

The idea (or one method) would be to "ENTER" these lines at the bottom of an existing in-progress program (when working in an emulator or real hardware...renumber to start at 10000 or whatever) and call it with a "GOTO" if you needed to change directories. My "H:" drive, for instance, is so full of stuff, I really need to organize it into folders. But because there is no way to access individual files (from Turbo-BASIC XL, anyway), that was problematic. And obviously I'm not talking about disk images which can be manually loaded via an emulator from anywhere.

Under BW-DOS or SpartaDOS-X, you can access directories using the ">" symbol, like this:

 

If you start the path with a ">", it means from the root directory; if not it means relative to current working directory.

 

Note that using TurboBasic from SDX needs a computer with more than 64K RAM, to install the drivers in banked memory.

 

 

6 hours ago, Brad Nelson said:

With the superior file handling of FastBasic, this kind of program is not necessary as the directory tree is available by the save or open command (with appropriate colons for the directory path...not sure that this is mentioned in the manual, but if it was, I missed it).

 

I think that the "file handing" is the same for both  

 

Have Fun!

[Brad Nelson]

Thanks, dmsc. That works like a charm. I knew that directory feature/syntax was available from within SpartaDOS X's command line. And I did have a vague idea that this DOS still sat underneath Turbo-BASIC XL while I was using it. But it never occurred to me that I could use it in TB.

 

Mark did an excellent job with the translation and formatting of the TB documentation (the very point of this thread). I think we could start collecting tidbits such as this to add to it. I would, as a graphic designer, be willing to further format the text and add additions and such...unless I would be stepping on Mark's toes.

 

Either way, I'd love to see this kind of information integrated, organized, and made readily available to people.

Edited November 30, 2023 by Brad Nelson

[Brad Nelson]

Just a quick update. On line 240 above, change it to just "CLOSE" instead of "CLOSE #1." It works fine in SpartDOS X but not in any other OS that I've tried.

 

Edit: Added support for filtered search. Just type the usual (without quotes) into the input line.

 

filemgrc.lst

Edited November 30, 2023 by Brad Nelson

[markmiller]

1 hour ago, Brad Nelson said:

I think we could start collecting tidbits such as this to add to it. I would, as a graphic designer, be willing to further format the text and add additions and such...unless I would be stepping on Mark's toes.

 

Either way, I'd love to see this kind of information integrated, organized, and made readily available to people.

Go for it. The point I had for putting it out here was so that people would use it.

 

BTW, I also recently made a translation of Ostrowski's articles on the TB compiler.

 

 

[Brad Nelson]

Mark, is that RTF file that you posted in the first post considered the master file? Also, do you have an RTF version of the original TB docs? I have just a pdf. My mission, Jim, should I decide to accept it, would be to rework the original docs and integrate the TUREX info as appendix or something like that.

 

I have an older copy of Word and can certainly use it, and obviously have opened it. I know people who do amazing things in Word, but I'm not one of them. I'd probably want to use a page layout program. But correct me if I'm wrong, wouldn't a text-searchable PDF be a pretty good format for the finished product? As long as I can export to pdf from the page layout program from that, we should be good.

 

Also, I would want to consult with you on design and content decisions. Not onerously so. Not fine-grained. Just to bounce ideas off of you. Let me know if that sounds within reason. Obviously it would be great to have additional examples and such. One fellow wrote some examples of how to do loops for FastBasic and I think dmsc has them at his site. Stuff like that, here and there, would be good. And I would think integrating the common commands of Atari Basic would make sense. There's no mention of the SQR function and there really should be, etc.

Edited November 30, 2023 by Brad Nelson

[markmiller]

37 minutes ago, Brad Nelson said:

Mark, is that RTF file that you posted in the first post considered the master file? Also, do you have an RTF version of the original TB docs? I have just a pdf.

I just compared the TUREX doc. I posted here and the copy I have, and they're identical. So, yes, I'd say it's the master file.

 

Re. the interpreter, all I have is what's been called the Expanded documentation, which is the PDF. Incidentally, in the thread that flowed from my posting on the translation of Ostrowski's articles on the compiler, someone posted an English translation of his article on the interpreter, as well. I looked it over, and it contains a few tidbits that are not in the Expanded documentation, but the Expanded doc. pretty much has it all.

 

The Expanded doc. was written with the idea that readers already know Atari Basic, and it just describes the parts that are not in Atari Basic. I have at times found that frustrating, because I'd like to just look in one document for what TB can do, or get an explanation for an error code (again, the Expanded doc. only shows you the error codes TB adds).

42 minutes ago, Brad Nelson said:

wouldn't a text-searchable PDF be a pretty good format for the finished product?

Yes, I think it would. It's what's used for the TB Expanded doc. I've found it very usable. I use a Mac, though. It brings up PDFs in Preview, which is a simple imaging app. that comes with macOS, but it's able to display and search PDFs. Obviously, PDFs are readable on Windows, but what I've seen is Windows users have to install Adobe's PDF Reader to look at them outside of a web browser. It doesn't seem like an onerous burden to me, since I imagine everyone who needs it, has it (it's free), but I dunno.

 

1 hour ago, Brad Nelson said:

I would want to consult with you on design and content decisions. Not onerously so. Not fine-grained. Just to bounce ideas off of you. Let me know if that sounds within reason.

Sure, consulting with me would be fine, so long as you're fine with a bit of a delayed response. It might take me a day to get back to you, assuming nothing disastrous has happened on my end (or even losing my internet connection, which happens sometimes).

 

When you mentioned integrating the Atari Basic documentation (which I assume means the Atari Basic Manual), I had the thought that it would deserve some revisions. Something I remember is some of its code examples have bugs in them! This wasn't that unusual. When I was getting my computer science degree in the late '80s, my professors even complained about this, that authors would put code examples in their technical books, but wouldn't test them before publishing.

 

You didn't mention this, but something I think really needs documenting is the TB compiler. When I was first getting into it, I could find almost no documentation (at least in English). I found out almost everything I know by just running experiments on it, and seeing what worked, and what didn't. It turned out Ostrowski had some guidelines for "do's and don'ts" in his article about it, but it's not nearly a complete description of the pitfalls to avoid. I don't have a complete sense of what to avoid, either, but I think I've discovered most of it.

[Brad Nelson]

The Expanded doc. was written with the idea that readers already know Atari Basic, and it just describes the parts that are not in Atari Basic. I have at times found that frustrating, because I'd like to just look in one document for what TB can do, or get an explanation for an error code (again, the Expanded doc. only shows you the error codes TB adds).

 

That was my thinking as well. By the way, I found a pretty good online PDF to Word converter. I ran the Turbo-BASIC XL pdf "expanded documentation" through it, opened it in LibreWriter, and it seemed to do a very good job. You don't get those broken line endings which is so common when you, for instance, copy-and-paste text from a pdf.

 

The immediate challenge would be to see if the pdf document outline view (which is really well done in the original) can be maintained. I wouldn't want to have to recreate it. But I suppose it could be. Even running it through the official online Adobe pdf converter did no better. So maybe that outline just won't convert. I may open it tomorrow in Acrobat Professional and see what's what. I have a friend who is much more fluent in that program who might be able to help.

 

It turned out Ostrowski had some guidelines for "do's and don'ts" in his article about it, but it's not nearly a complete description of the pitfalls to avoid. I don't have a complete sense of what to avoid, either, but I think I've discovered most of it.

 

That kind of info would be very valuable. In a sense, for these languages to stay alive and relevant in the retro community, having this kind of info would be good. I've learned a thing or two using it with SpartaDOS X (and some tips from dmsc) that would be useful. If we want people to use and enjoy these languages, then tearing down a few barriers in regards to getting to know them would certainly be helpful. I can definitely see some kind of addendum with a round-up of FastBasic in terms of "If you know Turbo-BASIC XL, you can likely be comfortable in this program as well". Not a detailed list of FB capabilities, by any means. An introduction.

 

The next step is for me to investigate whether or not I should take this to InDesign or Affinity Publisher so as to get the benefits of automatic indexes and stuff like that. But certainly the second step would be more or less to tear the docs down to basic text, no tables. Just headlines, subheads, and body text. Starting from scratch and designing (and applying) styles is probably the way to go. One could fiddle forever with the existing tabs, extra spaces, tables, and line separators. Those are, in the beginning, constraints to doing what you want to do.

 

Just thinking out loud. It's doable but would have to be considered somewhat of a long-term project. It depends if a few people can join in and help.

Edited November 30, 2023 by Brad Nelson

[Brad Nelson]

If we're going to have a new manual, then TB should at least have a logo. Consider this a proof-of-concept. In the graphics art field, you can't be a snowflake. "I hate it" is an acceptable criticism. But you can like it too, if you want.

 

I tried to capture the retro look, including the retro color and a suggestion of the Atari graphic "lines" style that they used in a lot of their literature.

 

[markmiller]

 

On 11/25/2023 at 6:45 AM, markmiller said:

You may know about Thomas Cherryhomes from Fujinet. Many years ago, he did some videos on the Forth language on the Atari 8-bit. One part of that was writing what he called an Antic disassembler, or turning a display list into mnemonics you can read. He didn't go the other way, writing an Antic assembler, but it's not that hard to imagine that one could do that in Forth.

Following up on my display list discussion (quoting myself), for the record, I just saw a video where Thomas Cherryhomes demo'd an Antic assembler. It was nicely done (in Forth). A good feature, since display lists are repetitive, was that you could say, "20 Mode 4 lines," rather than having to repeat "Mode 4" 20 times. It would also fill in some necessary instructions, so you could just focus on the mode lines you want. Once it was generated, you could look at the display list itself, seeing all the bytes.

[Brad Nelson]

In the category of "Nothing new under the sun," I was searching for XIO uses and syntax and ran into this program called QUICK DOS. Anyway, I updated my version of File Mgr to version "E" (attached). It adds the abilities to rename and delete files.

 

All other features should work for any disk format that SpartDOS X can read, and that includes Atari DOS, DOS 2.5, and MYDOS disks.

 

And as far as I can tell, the ability to CD (change directory) is limited to directories created with SpartaDOS. I created a directory, for instance, in MYDOS 4.5. The program (and SpartaDOS X) recognizes the MYDOS-created directory in the root directory. It is even marked as <DIR> as normal. And you can save inside this directory from Turbo-BASIC XL You can even list the contents of that directory via a normal filtered directory command. But you can't "change directory" to inside this folder. Not a big deal but I certainly don't understand that.

 

Ahh...sorry. I just found the relevant info on page 166 of the SpartaDOS X manual: "It does not support the ability to create/delete, or set a working directory on MYDOS media." But in all other ways SpartaDOS X (and this file manager program) will read Atari DOS, DOS 2.5, and MYDOS disks just fine.

filemgre.lst

[markmiller]

@Brad Nelson - My memory is that when using MyDOS, I only used subdirectories for file management. I didn't use them within my programs. If I wanted to "CD" to a directory, I went into the "DOS" menu, since it had an option for changing the working directory. And it, of course, had the ability to copy to/from directories, and do file management.

[Brad Nelson]

I always disliked dumping into DOS and then having to figure out how to get back. Was my program saved before I left? Do I have to load it again when I come back? Do I load back in the program with "Autorun.sys" or some other name? I'll do a directory listing and look. It's just a pain. And I find the menus of most DOS's to be a bit of a mess, although MYDOS is certainly an improvement over Atari DOS in this regard. And I guess I've gotten used to the SpartDOS X way of doing things.

 

So I've tried to make this relatively sleek and (in terms of how large it is) it can be slimmed down further. But for now it seems to work pretty well and it's the kind of utility program that I always wanted. And if I do say so myself, it is far less klunky that most other such utilities.

 

What you don't have a hook into is copying files. But you can always sort of "Save as…" and save a copy to another disk or directory from the program.

 

Attached is the latest version...prettified here and there and some better (but simple) documentation in the REM statements. The basic menu structure is:

 

DR(1-8,H)<CD><MD><REN><DEL><DD><Q>

>

 

You can ignore the menus, if desired, and pretty much just enter any valid disk command at the prompt (within the constraints of the program...again, no copy function).

 

 

filemgrJ.lst

Edited December 3, 2023 by Brad Nelson

[Brad Nelson]

Someone on this thread helpfully posted a link to a semi-automatic Display List Maker. I say "semi-automatic" because you still need to know some of the geek settings such as the address. And it would be cool if it had dozens of presets (with the rest of the needed attributes automatically added).

 

And, truth be told, even when I poked some of the presets (there are a few) in, it didn't work. I'm fully consternated by this fact. I find Display Lists more impenetrable than a Minos labyrinth. It's not the first time that I've done something exactly as instructed and had it turn our different or not work at all.

 

Still, a utility such as this looks useful. Perhaps someone can post a Turbo-BASIC XL (or FastBasic) example of using it, and one that actually works. I'd appreciate it. A bread crumb trail is definitely needed.