1050

And of course everyone is assuming that the drive mech has never been replaced with an improperly jumpered IBM drive mech which might explain everything? And I'm NOT referring to the drive number jumpers at all here - other jumpers CAN control index hole behavior just for starters among other aspects.

Patrik, could you please remove the cover and give us the make and model number for the drive mech so we can look up some jumper settings for it? The numbers we need might be under the side rails? TIA.

AtariDSK won't work right unless the disk is first formatted on the PC - that's a fact. Put that in your pipe and smoke it.
These are using PC drive mechs, and when they display PC behavior it confuses you? Somethings not right for sure, but the behavior is totally repeatable and I've come across it before, I'll bet that if Patrik made several copies of the OS disk using his 1050 and swapped them out as I described for using the Util program it might go ahead and load on up? Util was specially written to retry on read errors forever though, so it may only try three times and quit before a different disk can be inserted stopping the load entirely.

Something different every day around here.

Larry, on Mon Sep 12, 2011 5:40 PM, said:

I am very sure, the witchdoctor with the bone in his nose hasn't shown up yet so the 'can't format as you'd like to' bug is still in all MyDOS even beta4. If you had any success at all it was just your lucky stars that the disk you wanted was the same one MyDOS already had planned for you. There is no way around this abomination at present except to go the SIO route instead of the CIO route.

The CIO command for format is XIO 254 and the SIO command for it is XIO 21. With the CIO you get boot sectors and VTOC sectors written, with the SIO route all you get is a blank disk. You have to manually put the 'system' sectors on it if you want to use it as a regular disk but that will certainly work and MyDOS can not interfere with it since it hasn't been asked to contribute at all. But MyDOS is fully in charge of all CIO commands especially XIO 254 and it uses XIO 21 itself to do it with.

The XIO command you are looking for is $66, it writes both the percom block and the desired sector skew to the drive. You then need to format the drive with either the CIO or SIO command - but the CIO command still won't do it for you if you are using MyDOS. MyDOS will read the percom block you wrote the drive, ignore it, re-write it's own back to it and then format it the way it wants to - and you loose. I have no idea if you did this first as an SIO command and allowed MyDOS to 'mount' the disk as it were with it's special skew, whether or not this would have ANY effect on the outcome of a then attempted XIO 254 call. You could do the same thing by pulling a directory on the SIO formated blank disk and then doing a regular format from MyDOS's DUP.SYS menu - to the same effect as far as I know. The disk would be 'mounted' by MyDOS during the directory pull, when you then format it MyDOS will use the disk's Percom block info to do that with - but just what happens to your sector skew is the part I don't know anything about.

One thing I can add is that Puff's program Disk Communicator offers to write the destination in high speed skew for you if you choose allow it to format the destination disk, this would be an XIO 66 operation followed by XIO 21 since the disk is then filled with the .DCM image as it's uncompressed. And then I'm not really sure how to the read the sector skew anyway, at least in a very handy way. I suppose a 'chip to archiver' disk on a Happy drive would be the easiest way to get there?

Atarimax's Jindroush SIO commands page

So from BASIC you do...
XIO 66,#2,0,0,50,02,0,12,1,4,1,0,FF,0,0,0,12,10,E,C,A,8,6,4,2,11,F,D,B,9,7,5,3,1

following Jindroush's example with altered values for 720K.
I don't think you need to send any more bytes than neccessary, 128 is overkill for sure. If possible you should check 771 or 303h to see if the SIO call was successful before proceeding, a one or positive number here would be good, otherwise it's the negative error number. And if negative then it probably didn't take the data. You may need to change the FF above to 40 since Jindroush seems to indicate that this is the byte returned from the XF551 and some drives may not like different data sent to them than what they use as their default pattern.

and then
XIO 21,#2,0,0,"D2:"
To do the actual format without MyDOS's heavy handed tactics getting in the way, but then all you get is a blank disk. You could then format the disk with the /N option which does not do the actual format part but only rewrites the boot, VTOC and 8 cleared directory sectors thus putting the system sectors on the disk for you. It may not do the boot sectors now that I've thought a bit more about it, but the rest it sure will do. The boot sectors are simply address 700 thru 87f written to sectors 1, 2, and three. OR 1792 thru 2175 PUT to sectors 1, 2, and 3.

My issue with 720K disks was that I was not setting it up as an 80 track disk first, you do that thru the O Configure menu selection. This changes a critical 40 track default bit in the drive's table which MyDOS religously uses as the last word in what the disk is or is NOT. This 'table' starts at 7CC (1996 decimal) and make sure your drive # (eg.,D2:=1997 or 7cd) shows the proper byte change here before you format, or it won't fly at all. You'll get a DD disk with a 360K VTOC or some other odd duck but NOT a 2880 sector disk as you should have gotten. Again MyDOS ignores more than 40 tracks and won't change to 80 by itself, dumb as a box of rocks can be. Amazing no one complains much.

peek(1997) should be 91 but you would want to poke it with 43 for the 80 track value. 5b and 2b are the hex equivalents respectively so you can see it's the high nybble that's different.

31336haxx0r, on Tue Sep 13, 2011 1:29 AM, said:

I know I'm right - One of the key secrets to getting the IBM program Util.exe to read 1050 disks (look in UMich archive for it) was to be sure and have three or four copies of the Atari disk you wanted to read on hand and when the one in the drive quit reading you just swap it for another and hope it takes off reading again. Eventually you get the file read in completely and transfered to the PC!!! If you didn't know about having the multiple disks on hand and swaping them out prior to trying it, the program NEVER worked, always got hung up. I got Util.exe to work great! I got Happy's IBM disk reader program to work as well and used that for a long time for two way transfers, until I found Hias' AtariDSK which is a real dream come true. So good I still don't have an SIO2PC setup, as I don't need it. I really should cook one of those up sometime.

Patrik, on Wed Jul 13, 2011 4:48 PM, said:

Yeah, and nothings wrong with anything. The unnamed OS disk was written by a 1050 which does not use an index hole to line up it's sectors with and the XF551 is only capable of reading sectors that the index hole lines up with. Since the two drives turn at different speeds it's guaranteed that you can't read the entire disk (Atari's planned obsolescence in full bloom here), you are just running out of those sectors that it can read because the index hole is not in the right place anymore.

The other way this works is the disk won't even start to read at all by the XF551 but works fine in the 1050. If you want your disks to work with both drives then format them in the XF551 and these problems go away.

flashjazzcat, on Mon Aug 15, 2011 8:12 AM, said:

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.

Quote

We can hope!

Quote

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.

Quote

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.