reconsidering MS BASIC

[+hloberg]

off to another point. My intention on using the Atari MSBASIC .exe 2.7 (or .xex) was so there could be a run time created.

I been trying to figure out how to execute the AUTORUN.SYS (MSBASIC.EXE) then have another program pull in a BASIC program after. I had thought about a AUTORUN.SYS that would execute a MSBASIC.EXE program then after load insert LOAD.BAS into the editor and run a program that way. But, I don't know how to have a program wait then execute another program. or is there a better idea?

Edited March 1, 2016 by hloberg

[1050]

Gets complicated using autorun files by the fact that DOS is waiting to be returned to after autorun string of files has auto ran. This process then requires that all autorun files can only use INITAD (02e2h) addresses to be invoked with and they must end with RTS (machine language equivalent to BASIC RETURN statement) to allow DOS to keep on loading other autorun files. So 'normal' executable files that use RUNAD (02e0h) to run with need altering so that they now fire up with INITAD and those that don't end with RTS can't be used anyway for 'legal' autorun use. This leaves out MSBASIC entirely from autorun consideration.

 

Autorun files need to do their thing and then end automatically is the short way to put it and BASIC of any flavor isn't going to do that unless they are modified with this precise purpose in mind. They also still need to use the INITAD mode of invoking them or it's the end of the autorun session at least as far as returning control to DOS goes.

 

Better idea? None here really, even with a modified MSBASIC as autorun1 then autorun2 changes the RTS in MSBASIC to what should be there to work and goes ahead and feeds 'RUN"D2:MYTOY.BAS' into the E: device, there is no warranty that any of it could ever work as hoped for. Sounding more like a job for a batch capable DOS to me, what flavor of DOS was this for? SpartaDOS may be able to do this and I wouldn't know that anyway having no need to ever try that there. I do know that many talents come with batch though.

[fujidude]

originally, in the MSDOS world, .com were small files (I believe less then 256k) and .exe were larger files. Personally I have continued the tradition in the Atari world with small utilities as .com and applications as .exe. I was out of the Atari world a while and just got back into it. I'll add .xex into the mix.

 

Almost got it. In MSDOS world, .COM files were within 64KB; the size of a "segment" of memory on the 8086.

[+CharlieChaplin]

Hmmm,

 

since I am no programmer, I did like that TB XL can be named Autorun.SYS and after its loaded it can load a file named Autorun.BAS automatically; the CTB-Runtime can also be named Autorun.SYS and once it is loaded it can load a file named Autorun.CTB automatically.

 

Atari Basic Rev. A (XEX fileversion) did not load any file automatically, until I asked Fandal, so he patched it for me to load Autorun.BAS automatically; he also patched Atari Basic Rev. C (XEX fileversion) to load Autorun.BAS automatically; he patched Fast Basic to load Autorun.FBA automatically; he patched Hypra-Soft Basic to load Autorun.HSB automatically; he patched Basix to load Autorun.BSX automatically... (I don`t know how its done technically, but he did it successfully).

 

When Altirra Basic appeared as a file version, I asked phaeron if he could patch it, so it loads a file named Autorun.BAS automatically and he did this (while I changed it to Autorun.AIB for Alt-Irra-Basic). There is also the Basic XL runtime (a little misleading since it is for un/non-compiled Basic XL programs), which can run Autorun.BXL automatically...

 

Maybe you could ask Fandal if he could patch MS-Basic (XEX fileversion), so it runs a file named Autorun.MSB automatically ?!? Should not be that different to Atari Basic, Fast Basic, Hypra-Soft-Basic, Basix, TB XL, CTB-Runtime, Altirra Basic, Basic XL, etc. to load a file named Autorun.??? automatically... - IF this is what you want for MS-Basic...?!?

 

Edit: You can find some altered Basic versions with Autorun.* option in the "U-Basic" topic (posts #7 and #14), MS-Basic is not one of them yet... http://atariage.com/forums/topic/240811-u-basic/

Edited March 1, 2016 by CharlieChaplin

[+hloberg]

Gets complicated using autorun files by the fact that DOS is waiting to be returned to after autorun string of files has auto ran. This process then requires that all autorun files can only use INITAD (02e2h) addresses to be invoked with and they must end with RTS (machine language equivalent to BASIC RETURN statement) to allow DOS to keep on loading other autorun files. So 'normal' executable files that use RUNAD (02e0h) to run with need altering so that they now fire up with INITAD and those that don't end with RTS can't be used anyway for 'legal' autorun use. This leaves out MSBASIC entirely from autorun consideration.

 

 

load other Autorun files? I thought there could only be one on a disk?

But I do get what you say. A RTS to DOS is executed and autorun.sys takes over. No threading capabilities on the Atari.

thus the autorun.sys (MSBASIC program) would have to be modified to look for a BASIC file on execution and load it.

OR use a DOS like sparta or DOS XL with batch capabilities. I'm going to pursue that avenue for now.

[1050]

load other Autorun files? I thought there could only be one on a disk?

Recent MyDOS allows for multiple autorun files that are named in succession of desired loading as *.AR# where the number dictates the loading order with 9 being the upper limit. The workaround for single autorun.sys files is to merge them into one file with several INITAD invokes along the way, same effect as .AR0 scheme but more hacker abilities required.

 

But I do get what you say. A RTS to DOS is executed and autorun.sys takes over.

Misfire there, A RTS to DOS is the end of autorun session and DOS menu appears on the screen. UNLESS you want to be looking at a MSBASIC editor input screen anyway. But this isn't standard use of autorun.sys system. Not breaking any laws here so you can do this, and it's starting to sound by CharlieChaplin's post above that is exactly what you want to do with a modified MSBASIC that goes ahead and looks for it's own version of .BAS file to autoload and run just like you asked for to begin with. My bad there, I'm not up to speed with the latest offerings in BASIC it seems.

 

No threading capabilities on the Atari.

It appears we be can wrong about that, but I was thinking so too.

 

thus the autorun.sys (MSBASIC program) would have to be modified to look for a BASIC file on execution and load it.

OR use a DOS like sparta or DOS XL with batch capabilities. I'm going to pursue that avenue for now.

I'm going to go investigate some of these modified BASIC offerings at CharlieChaplin's link and see what can be learned looking at how those were done. Probably much faster results to be had if one of those guys would tackle MSBASIC for you.

[+CharlieChaplin]

There is also a patch for DOS 2.0s in Antic, Analog or Compute available that gives DOS 2.0 multi-Autorun capability (1st Autorun is named Autorun.SYS, 2nd is named Autorun1.SYS, 3rd is named Autorun2.SYS, etc.). This was used by some programmers in the Abbuc Software contest, e.g. the original release of Mulewars used a patched DOS 2.0s + multi-Autorun...

 

Other DOS 2.x versions with multiple-Autoruns are MyDOS 4.5x (version 4.50 does not have it, it was introduced either with 4.51 or with 4.53) and SmartDOS 6.x/8.x, not sure about Top-DOS. Turbo-DOS XL/XE, DOS II+D, DOS XL and X-DOS can have multiple Autoruns with batchfiles. Maybe Bibo-DOS has such a function as well with option N - startup edit, if so, I never used it (but it could be, that it only starts Basic files with this option). Under X-DOS 2.4x an Autorun.SYS file can be a) a ML-file, b) a Basic file or c) a text file/batchfile...

 

- batchfile under Turbo-DOS XL/XE: use the ramdisk+batchfile driver as Autorun.SYS, the batchfile must be named Setup.BAT then;

- batchfile under DOS XL: afaik, the batchfile must be named Startup.EXC ?!?

- batchfile under DOS II+D: use the JOB command, thus type in: a) JOB Filename.COM to start a ML file, b) JOB CAR RUN"D:Filename.BAS" to start a Basic program or c) JOB @Filename.EXT to execute a batchfile (textfile)

- batchfile under X-DOS 2.4x: just name it Autorun.SYS

- batchfile under MyDOS: if you don`t want to use the multi-Autorun function (or if you are using an older version of MyDOS that does not support this), you may use the BatchFile Enhancement (BFE) for MyDOS by Thorsten Karwoth; since I never used the BFE, I do not know what filename must be used for the batchfile, maybe its Autoexec.BAT...

 

- multiple-Autoruns under SmartDOS and MyDOS 4.5x: Autorun.ARx, where x is a number from 0 to 9 (1st Autorun is Autorun.AR0, 2nd Autorun is Autorun.AR1, etc.)

- as said before, I do not know if Top-DOS or Bibo-DOS do support multiple-Autoruns or batchfiles (find out yourself)...

[+hloberg]

Recent MyDOS allows for multiple autorun files that are named in succession of desired loading as *.AR# where the number dictates the loading order with 9 being the upper limit. The workaround for single autorun.sys files is to merge them into one file with several INITAD invokes along the way, same effect as .AR0 scheme but more hacker abilities required.

 

 

Go to show I need to RTFM! I use MYDOS as my DOS (no pun intended) of choice. But just naming a game.bas file to autorun.sys won't work will it? i will have to create a program to load the file into memory and run it or the least have it sent to E: to show on screen?

 

so I will test that startup.exc batch file ands see what happens. Can't remember if I tested my MSBASIC.exe under DOSXL and it worked? Need to test that too.

If that doesn't work I might try some of the other DOSs CC named (thanks).

Edited March 2, 2016 by hloberg

[+MrFish]

I'm in the process of creating a good manual for DOS XL anyway (all the ones I found are in bad shape)...

 

I just created a good version of the DOS XL manual a few weeks ago. It's up on my website for download (link in sig).

Edited March 4, 2016 by MrFish

[+MrFish]

In fact, I'll add here, that there are a lot of improved versions of manuals on my site that you won't find anywhere else. Most of them I've added bookmarks and made them text-searchable, and others I've also added better quality covers. The DOS XL manual was an extreme case, where pages were out of order, and most pages needed straightening out and cleaning up as well. That was one of the main reason for the creation of my site: to house these improved manuals and make them available in a single location.

 

 

[+hloberg]

 

I just created a good version of the DOS XL manual a few weeks ago. It's up on my website for download. The link to my site is in my sig.

Just found it thanks. The DOSXL manual was a real mess and was only 1/2 way through fixing it. looking over some of the other manuals I need too. Great site.

Edited March 2, 2016 by hloberg

[+MrFish]

Just found it thanks. The DOSXL manual was a real mess and was only 1/2 way through fixing it. looking over some of the other manuals I need too. Great site.

 

Thanks, it's new and still growing.

 

Alright, at least I saved you some time then.

[1050]

This wouldn't be in the manual though so you kinda escaped without penalties there. By recent I mean there is break between 4.50 and higher versions of MyDOS. 4.50 uses single autorun.sys file method, while 4.53 and 4.55 beta 4 use the .AR0 type of autorun file loading. But NO, loading a .BAS file will fail as an autorun file, likely to hang the machine too.

 

http://www.mathyvannisselroy.nl/mydos.htm

 

Yell yeah thanks CC, that's some potent stuff there. As it is you could set it up to autorun his CBASIC.COM and it would load version C Atari BASIC which has some very clever preload switcharoo going on that I got my eye on that does 'RUN"D:AUTORUN.ABS"' into the editor after BASIC fires off. All you need to do is rename the .BAS file that you want to autoload/run to AUTORUN.ABS and have it on D1: and the deal is done after a boot up.

 

Now to do this same to MSBASIC. Going to see what Xuel has done in his version of .xex, it sorta looks like there might be some way to wedge this switcharoo thing in there, but I have no clue yet as to what he does there fully. So in the meantime, is his .xex working fine for you?

[+hloberg]

I looked at Xuel .xex for MSBII. it's just the cartridge to .xex file. it still needs to load the supplement disk with the extra commands as AUTORUN.SYS. MSII

2.7 (which is just MSBII 1.01 stripped from the disk and very slightly modified) does have the supplemental commands added. MSBII2.7 works fine as it's a complete stand alone AUTORUN.SYS.

 

Thought, the supplemental commands loads after the Xuels MSB.xex. a AUTORUN.SY1 (MSbII.XEX) , AUTORUN.SY2 (suppl files WITH BASIC file load command wedged in)

MSBII has become resident with the load of the .xex. then attach onto the end of the supplemental to do a RUN "D:AUTORUN.BAS" <enter>

attached is supplement fileMS2-SuppDisk.atr

Edited March 2, 2016 by hloberg

[+hloberg]

Can't get msbasic, in any form, to work with DOS XL.

[+CharlieChaplin]

Can't get msbasic, in any form, to work with DOS XL.

 

Hmmm,

 

you have a "hacked" fileversion of MS-Basic and this fileversion also includes the supplemental disk... Maybe the hacker/programmer who did this fileversion, decided to use the RAM under the OS for the supplemental disk ?!? And maybe DOS XL and this fileversion both try to use RAM under the OS which does not work... (just guessing)...

[1050]

Don't know much about DOSXL. I've got 2.7 looking for autorun.msb file but I don't even have one, can someone be so kind as to supply me with a ready made MSBASIC.BAS file for testing? TIA. While gazing at my navel I happened to spot a an interesting thing in Xuel's offerings, within the code the text autorun.amb can be read. Any clues as to what it might be? Is it already set to autorun BASIC files by that name? Or is this the supplement file? I used to have these disks but I never used them, I might have a look around.

[+CharlieChaplin]

Hmmm, used my super programming skills and wrote:

10 PRINT"TEST":PRINT"TEST":PRINT"TEST" (this works fine in direct mode under MSB)

and saved it as Autorun.AMB. When I loaded MS-Basic 2.7 this file did not get loaded automatically (so maybe Autorun.AMB is for the supplemental disk, which is included in the hacked fileversion)...

 

Not sure if it is possible then to add another Autorun which should load a MSB file automatically from disk (e.g. Autorun.MSB). Have to ask Fandal...

Edited March 4, 2016 by CharlieChaplin

[1050]

I went ahead and hacked Xuel's version to autoload .MSB files instead of .AMB and it autoloads just fine with just that trick. So the supplemental disk if one actually exists in the first place is just a standard disk with a standard .BAS file on it renamed. If I were releasing a cartridge/disk package that was to be at least a little bit hacker proof this is NOT the way I would have done it. I strongly suspect then that this autorun talent only comes from Xuel.

 

So below is the above .xex, patched disk based 2.7 and a SAMPLE autorun.MSB file.

Msbas27.zip

 

This (and the original) disk based version 2.7 is attempting to query R: device with 3Fh request which then sends 12 bytes with possibly an Init jump thru address which it then does. I've patched that part such that only if you have sequential SIO call successes with all those operations does this happen, otherwise you skip that and just go to Fandal type autorun section. And nicely if you don't have an autorun file on D: you do get #170 file not found error as I was hoping for. It does have garbage code within it that is redundant and useless which may have been part of the copy protection of the original that wasn't hackered very well can we say? As such it may not work right, but I wouldn't know where or how or especially IF it's broken in the first place. It's just a possibility is my suggestion.

 

Xuel's version is impeccably done by contrast however and I have to trust his fixes over the disk based version myself. Both ways alter key parts of the system and these are not undone when returning to DOS, Xuel's is quite difficult to reenter successfully too. My current MyDOS, beta 4, has issues with the disk version, but if you work at it, eventually it will fly.

 

Fandal is a genius, the trick is to drop in a substituted entry for the E: handler in HATABS table pointing to local code instead of ROM code, duplicate ROM code in local code and then change just the get byte vector in local code to more local code that is actually bucket feeding E: with 'run"d:autorun.msb"' string, and on the last byte of the string you replace the original E: pointer into HATABS. I was never here is the effect and it's brilliantly clever. This is a prime example of hacking done by disk editing skills, the original code is pretty much entirely intact and what has happened here is the simple insertion of 'other' code into the file along with the original code.

 

After looking around some, all I found was an empty box, but it does say on it 800 so it's likely the disk only version of MSBASIC. I do not recall having a cartridge either. I'll find the disks in a couple of years and say 'there you are', only to have lost the box between now and then.

[+hloberg]

the supplemental disk to MSBASIC II had some extra commands such as AUTO on the disk. It took an additional 2k to load. On the original disk it was just a autorun.sys file. the extra commands were already in the MSBASIC 1 and 2.7 verision

Edited March 6, 2016 by hloberg

[+hloberg]

I went ahead and hacked Xuel's version to autoload .MSB files instead of .AMB and it autoloads just fine with just that trick. So the supplemental disk if one actually exists in the first place is just a standard disk with a standard .BAS file on it renamed. If I were releasing a cartridge/disk package that was to be at least a little bit hacker proof this is NOT the way I would have done it. I strongly suspect then that this autorun talent only comes from Xuel.

 

So below is the above .xex, patched disk based 2.7 and a SAMPLE autorun.MSB file.

Msbas27.zip

 

 

 

 

Well gosh darn, it looks like it works. you both are geniuses! This now makes MSBASIC viable to use and distribute with programs.

For me it simplifies the conversion of my old TI-99 programs, thanks. Another arrow in our quiver of tools.