H: and Mydos 4.50T

[Thelen]

I'm Trying to load a binary file (P.OBX) in Mydos from the H1 drive. The only result I get is an Error 168.

 

When I copy The file (P.OBX) from H1: to D1: and load the file from D1: it works ok. But when I load it from H1: it gives error 168...

 

How can i let the file work from HD in mydos ? (everything is done in the emulator)

 

H1: is a mounted path to my pc HD where the file P.OBX is standing.

 

 

stupid thing is that when i load atari dos 2.0s, and when i load the binary file from H1: it works ok....

 

 

 

Thanks !!

Edited August 18, 2009 by Thelen

[Urchlay]

How can i let the file work from HD in mydos ? (everything is done in the emulator)

...

stupid thing is that when i load atari dos 2.0s, and when i load the binary file from H1: it works ok....

 

I have a theory on why this doesn't work...

 

The H: device driver is built into the emulator, and it only supports a subset of the CIO operations... and it's the same device driver, no matter what DOS you're running.

 

In Atari DOS 2.0S, when you go to load an executable from DUP.SYS, it does something like:

 

1. Use the CIO OPEN command to open the file

2. Read the contents of the file using CIO "READ BLOCK" commands

3. Use the CIO CLOSE command to close the file

4. Jump to the start of the loaded code...

 

All the CIO commands DOS 2 uses are the standard ones for open/read/close, which are supported for the D: devices by DOS.SYS, and for the H: device by the emulator itself. Note that Atari DOS does NOT have a CIO call that means "Load and run an executable file" (the menu option exists, but it gets the job done by making several CIO calls for open/read/close).

 

In MyDOS (and also in SpartaDOS), the D: device driver actually supports an extended CIO command that means "Load and run an executable"... I can't remember the command number, but you can even use it from Atari BASIC with the XIO command. When you use the "load binary file" option from the MyDOS menu, it makes a single CIO call (the MyDOS-specific "load/run executable"). MyDOS's D: driver understands that, and loads the file... but the emulator's H: device driver doesn't understand it, so it returns an error...

 

...or perhaps MyDOS's DUP.SYS is actually checking to see if the filename starts with D: or not, and if not, returns the error immediately without even trying to execute a CIO "load and run" command on the H: device. The only reason I think this might be possible is that, if I remember correctly, error code 168 is MyDOS-specific, not in the set of error numbers DOS 2.0S uses (I may be wrong about that though).

 

The way to fix it: Modify the emulator so that its H: device understands MyDOS's extended CIO call for "load and run". However, if the DUP.SYS code is actually checking for D: in the filename, this won't help (you'd also have to modify MyDOS to remove the check).

 

None of the above has been tested, it's all theoretical (pulled out of my brain), so I might be 100% wrong... but I've now gotten interested enough that I'll go and check, and post my results here

[Shannon]

That sounds about right. When I was working on atarixlbox I ran it thru debug mode to see if I could figure out the deal with the H: device. My memory is a little fuzzy but I do remember having issues with the load command, and I believe the delete command didn't work as well (for any DOS).

 

Anyways it was passing a CIO command before failing.

[1050]

None of the above has been tested, it's all theoretical (pulled out of my brain), so I might be 100% wrong... but I've now gotten interested enough that I'll go and check, and post my results here

 

Urchlay, I think you are pretty close to it.

In the meantime I'll post what I found in the technical manual for 4.50 MyDOS.

 

To load (and possibly execute) a program file, MYDOS provides the CIO function 39 call. CIO function 40 will do the same; it was included for compatibility with programs written for SpartaDOS. From BASIC you can load and execute a program by executing the line: XIO 39, #3, 4, 0, "D:MYPROG.OBJ". Any inactive IOCB can be used, and if AUX1=4 both the INIT and the RUN entries will be executed. If AUX1=5, the RUN entry will be executed; if AUX1=6, the INIT entry will be executed; and if AUX1=7, the file will be loaded without executing either entry point.

Any other values of AUX1 will return an error code and do nothing.

 

I would hazzard a guess that in setting up for access to the H: device, the emulator code is clearing the AUX1 byte and causing MyDOS to crap it's pants as per the last line of the tech manual quote.

 

No easy solution comes to mind...

 

On another subject slightly related,

Wouldn't it be better, for the sake of so-called SpartaDOS compatability, that MyDOS's CIO function 40 should ignore start and init vectors (AUX1 entirely) and instead load and run the first segment of code found in the actual file just like Sparta does? It just doesn't make sense to me to have it otherwise.

[+therealbountybob]

Just a feeble thought but there is mydos4.53 if this was a DOS issue maybe it was addressed

[atarimac]

It may be a little of both. The current version of Atari800 has the code in there to support the MyDos commands for loading files in the H: driver. But if you are using an older version of Atari800WinPlus, it may not, as it is not up to date with the Atari800 code base, and no one is maintaining it.

 

However, I suspect the real problem is MyDos expects D: devices for a lot of device operations. You can read/write and get directories with H:, but as I recall file deletes don't work either. And it's not just MyDos, as evidenced by a recent thread on here, there are problems with using Action! and other programs which expect a disk drive to be a D: device, not an H:.

 

I have a solution for this. On the Mac, the latest version of Atari800MacX presents an alternative, and when I get time I will be checking the solution into Atari800 CVS, if the rest of the developers agree.

 

What I do is use D5:-D8: as hard drives instead. The new D: patch replaces the original vector that DOS installs and checks the drive letter for the operation call. If it is 1-4, then it simply passes the call to the original DOS routine. Otherwise, it uses the same routines that H: uses to process the call. D5: and D6: point to the first 2 hard drive directories without translation, and D7: and D8: use translation. The limitation on the D: patch is it does require a DOS to be present, so it would work with a cartridge and no disk. It is compatible with H:, and both can be used at the same time.

 

Mark

[Thelen]

Thanks for the info's ! I tried vers. 4.53 but that didn't help..

 

Maybe somebody knows a solution for this problem :

 

I have 4 files (4x a .bmp picture of 64KB) on a disk(.atr). I use Mydos 4.5 because I need the large disk size (16mb) for hosting the bmp's. For the ease I have H1 on the emulator which is a folder where I compile my source. Then i boot mydos, copy from h1 to d1 my compiled source and then run it with the binary load command from d1 (run it direct from h1 will be more easy, but that doesn't work)...all this is a bunch of work to test my compiled source...

 

Does somebody know a quicker way ?

 

Thanks !

[Urchlay]

I have 4 files (4x a .bmp picture of 64KB) on a disk(.atr). I use Mydos 4.5 because I need the large disk size (16mb) for hosting the bmp's. For the ease I have H1 on the emulator which is a folder where I compile my source. Then i boot mydos, copy from h1 to d1 my compiled source and then run it with the binary load command from d1 (run it direct from h1 will be more easy, but that doesn't work)...all this is a bunch of work to test my compiled source...

 

Does somebody know a quicker way ?

 

Find a utility for your PC that can create the giant ATR image for you, invoke it from your Makefile or batch script (whatever you're using to automate your build process on the PC side).

 

On Linux, you can use "dir2atr" from HiasSoft's AtariSIO package. I don't know of an equivalent tool for Windows or Mac, but possibly you can build just the dir2atr tool for Windows (the actual AtariSIO driver is Linux-specific, but the tools should be portable). There are various Windows tools that can create and/or copy files to an ATR image, but not all of them can handle 16MB images, and not all of them can run non-interactively (e.g. you run it with some command-line arguments from within your build script). You don't want to be dorking around with a mouse, manually dragging the same files to the same place, over & over again...

 

(Note: there's another tool called DIR2ATR.EXE for DOS, but it's not the same thing: It appears to be interactive only, and I'm pretty sure it can't handle large ATR images)

 

Basically, the procedure would be something like...

 

1. Create a large ATR image that's got a bootable MyDOS, call it "image.atr"

2. Edit and compile your Atari code

3. Copy the Atari executable and data files into "image.atr" (name the executable AUTORUN.SYS if you want)

4. Start up your emulator, with "image.atr" as D1:

5. Exit the emulator, goto step 2

 

Steps 2 to 5 above should be automated (if you're on Windows, use a batch file) and bound to a keystroke in your text editor, so when you're ready to test your code, you whack F9 or something, and the latest version of the code is running in the emulator within a second or so... I don't know how to set up a Windows environment to do this, but it's definitely possible.

[Thelen]

Thanks for the dir2atr info Urchlay ! I downloaded a dir2atr for dos/win from HiasSoft's(not the old dos one), and that worked great ! only thing is that when i wannt to make the disk bootable

it looks like it does everything ok, but when i boot it in emu it hangs.... and I use dos.sys from mydos 453 and in the command line I put the -b mydos453 command.

 

Does somebody know how to make it bootable and that it boots ?

Edited August 20, 2009 by Thelen

[Thelen]

Problem solved ! you have to use a dos.sys from mydos 4.53/4 and I used vers. 4.53/3.....

[Urchlay]

Problem solved ! you have to use a dos.sys from mydos 4.53/4 and I used vers. 4.53/3.....

 

So, no more need for the H: drive? Cool.