MyDos Bugs

[+Larry]

In the MyDos ramdisk thread, a couple of posts referred to the bugs in MyDos. I've read a number of times about "Ramdisk Bug" that supposedly will format D1: if it can't find the appropriate drive. (I've personally never seen this bug, but I can't say that I've ever tried to get my hard drive formatted this way.)

 

But what are some others? Let's make the lower limit of this as version 4.50, OK? And this isn't about limitations -- i.e. the 64 file limit per directory isn't a bug. If MyDos won't work with a specific program because of it's memory requirements, that's not a bug. A bug (to me) is an unexpected consequence that is contrary to the way MyDos was intended to work.

 

Since the release of 4.50, what bugs (if any) have been added? A four-digit sector entry is not a bug, although it certainly can cause mischief with some programs that were designed for Dos 2.0 and 2.5.

 

Aside from curiosity, it would be great to document the bugs.

 

If you are MyDos-knowledgeable, can you show us a bug that can be reproduced?

 

-Larry

[+CharlieChaplin]

Well,

 

here is one MyDOS bug:

 

http://www.atariage.com/forums/topic/46196-mydos-and-ramboot/page__p__558568__hl__MyDOS%20bugs__fromsearch__1#entry558568

 

mentioned in the PS of post 2...

 

As I understand it, whenever MyDOS is NOT configured for a ramdisk, but there is a ramdisk-driver on the disk (or you copy one onto this disk), then MyDOS will format drive 1 ( instead of the ramdisk, drive 8 ). So you always have to make sure, that whenever you put a ramdisk-driver on a MyDOS disk, that MyDOS is configured for a ramdisk, otherwise this disk will self-destruct in less than five seconds when booting.

 

You can always put a ramdisk-driver on a DOS 2.5 disk and when there is no ramdisk available, it will simply not format a ramdisk nor drive 1...

 

-Andreas Koch

Edited August 25, 2010 by CharlieChaplin

[+Larry]

Hi Andreas-

 

Since we are evidently "short" on known MyDos bugs, I'm going to try to reproduce this bug with a small compact flash D1: hard drive setup. I'll let you know my results. My own knowledge of MyDos bugs is limited to bugs in the earlier 4.1X or 4.2X versions, and I really don't remember what they were. At that time (mid-to-late 1980's IIRC) new versions of MyDos were coming out pretty regularly. I got my first copy of MyDos with a new piece of hardware I bought. It was 4.1 and had a copyright date on it of 1985 (still have the docs and probably a disk -- somewhere).

 

-Larry

 

Well,

 

here is one MyDOS bug:

 

http://www.atariage.com/forums/topic/46196-mydos-and-ramboot/page__p__558568__hl__MyDOS%20bugs__fromsearch__1#entry558568

 

mentioned in the PS of post 2...

 

As I understand it, whenever MyDOS is NOT configured for a ramdisk, but there is a ramdisk-driver on the disk (or you copy one onto this disk), then MyDOS will format drive 1 ( instead of the ramdisk, drive 8 ). So you always have to make sure, that whenever you put a ramdisk-driver on a MyDOS disk, that MyDOS is configured for a ramdisk, otherwise this disk will self-destruct in less than five seconds when booting.

 

You can always put a ramdisk-driver on a DOS 2.5 disk and when there is no ramdisk available, it will simply not format a ramdisk nor drive 1...

 

-Andreas Koch

[+bob1200xl]

What ramdisk driver? D8: is the ramdisk? Is this about 4.50?

 

My experience with MyDOS is that you can set the ramdisk to any drive. I used to set it to D1: on my battery-backed memory upgrade and it would jump into the ramdisk after DOS loaded, automagically. I don't recall any 'drivers' for this.

 

Why are you using a CF drive? (rather than a floppy)

 

Bob

 

 

 

Hi Andreas-

 

Since we are evidently "short" on known MyDos bugs, I'm going to try to reproduce this bug with a small compact flash D1: hard drive setup. I'll let you know my results. My own knowledge of MyDos bugs is limited to bugs in the earlier 4.1X or 4.2X versions, and I really don't remember what they were. At that time (mid-to-late 1980's IIRC) new versions of MyDos were coming out pretty regularly. I got my first copy of MyDos with a new piece of hardware I bought. It was 4.1 and had a copyright date on it of 1985 (still have the docs and probably a disk -- somewhere).

 

-Larry

 

Well,

 

here is one MyDOS bug:

 

http://www.atariage.com/forums/topic/46196-mydos-and-ramboot/page__p__558568__hl__MyDOS%20bugs__fromsearch__1#entry558568

 

mentioned in the PS of post 2...

 

As I understand it, whenever MyDOS is NOT configured for a ramdisk, but there is a ramdisk-driver on the disk (or you copy one onto this disk), then MyDOS will format drive 1 ( instead of the ramdisk, drive 8 ). So you always have to make sure, that whenever you put a ramdisk-driver on a MyDOS disk, that MyDOS is configured for a ramdisk, otherwise this disk will self-destruct in less than five seconds when booting.

 

You can always put a ramdisk-driver on a DOS 2.5 disk and when there is no ramdisk available, it will simply not format a ramdisk nor drive 1...

 

-Andreas Koch

[+Larry]

I did think of using a floppy. Some reason not to use a CF?

-Larry

 

What ramdisk driver? D8: is the ramdisk? Is this about 4.50?

 

My experience with MyDOS is that you can set the ramdisk to any drive. I used to set it to D1: on my battery-backed memory upgrade and it would jump into the ramdisk after DOS loaded, automagically. I don't recall any 'drivers' for this.

 

Why are you using a CF drive? (rather than a floppy)

 

Bob

[+bob1200xl]

Well,,, you introduce another source of potential failure with a CFcard/HDD interface. It may be more productive to test on a platform of known, baseline hardware. Like a stock 130XE and 1050.

 

Bob

 

 

 

 

I did think of using a floppy. Some reason not to use a CF?

-Larry

 

What ramdisk driver? D8: is the ramdisk? Is this about 4.50?

 

My experience with MyDOS is that you can set the ramdisk to any drive. I used to set it to D1: on my battery-backed memory upgrade and it would jump into the ramdisk after DOS loaded, automagically. I don't recall any 'drivers' for this.

 

Why are you using a CF drive? (rather than a floppy)

 

Bob

[+Larry]

Hi Bob-

 

Fair enough. I'll do both and see if either, neither, or both cause this bug to raise its ugly head.

 

-Larry

 

 

Well,,, you introduce another source of potential failure with a CFcard/HDD interface. It may be more productive to test on a platform of known, baseline hardware. Like a stock 130XE and 1050.

 

Bob

[+Larry]

Perhaps there are other conditions that must be met in order to produce this bug as described. Or perhaps this was an earlier version. (?)

 

Test #1

I used a Bob Puff "Master" of MyDos 4.50, stock 130XE, stock 1050.

 

Set up MyDos so that it did not have a ramdisk, but included the RAMBOOT.AUT file as AUTORUN.SYS on D1:.

 

Formatted & wrote the Dos files to the 1050 floppy and copied AUTORUN.SYS to the same disk.

 

It boots, and automatically set up D8: as the ramdisk. Hmm, does that qualify as a bug, since the dos had been configured as not having a ramdisk? But it requires a conflict -- i.e. Dos saying "no" but the AUTORUN.SYS saying "yes." Certainly nothing as severe as formatting D1:.

I suspect that the Dos setup -- letter "O" is exactly what it says -- "Change Configuration" to override the default values for what MyDos "thinks" it needs to be, so if you include the RAMBOOT.AUT, MyDos will set up the ramdisk.

 

Test #2

Same as Test #1, except I used a 256K 800XL (very stable, BTW )

Same results -- set up D8: as the ramdisk for 256 KB machine (1920 free sectors).

 

Test #3

Same as Test #1, but this time I used a new Black Box HD partition and swapped it into the D1: position.

Same results -- set up D8: as the ramdisk for a stock XE (387 free sectors).

 

Test #4

Used a stock 800XL to see what happens when there is no expanded ram.

Results in no ramdisk being set up, even though the AUTORUN.SYS file is there.

 

I'm going to look through the notes for the the "fixed" ramdisks, but as I understand the bug, it can't be confirmed as described. "Busted?"

 

-Larry

Edited August 28, 2010 by Larry

[Mathy]

Hello Larry

 

The bug you mention does (read: did) exist. I've seen it destroy partitions too.

 

Some of the bugs I mentioned before in another thread:

 

- Something was wrong with the MEM.SAV feature.

- The memory detection routine got screwed up (that's why there's a patched version of MyDOS 4.50 for the Newell 1MB upgrade)

- If you change the PERCOM Block and then tell the drive to format, MyDOS will not look at the Percom block but format the drive according to the settings in (or set via???) DUP.SYS

- pre-4.55 beta 3 versions don't check the size of your RAMdisk before copying the content of your RAMDISK: subdirectory to your RAMdisk

- There was an error in the VTOC building routine

- If you don't use a period between filename and extender (possible if the filename is 8 characters long or replaced by the asterisk) the first character of the extender is sometimes chopped off (and the rest of the extender moved forward one character)

 

Some other bugs:

 

- Sidedness isn't always displayed correctly

- MyDOS shows S or D as the density, but never E

 

And there are probably more. But the bugs mentioned above are all fixed at the moment.

 

sincerely

 

Mathy

[+Larry]

Hi Mathy-

 

Thanks for posting these! It's "grist for the mill!"

 

Of course I have questions and a comment or two...

 

First, all of the bugs/anomalies that you show are fixed -- in 3.55 b3 or?

 

Were all of the issues you mentioned still in 4.50 Bob Puff version?

 

Do you remember the other thread that you mentioned? Perhaps these were discussed at more length?

 

I'm quite curious about bugs being fixed in 4.55, because when I used it recently, one of the first things I noticed was that I formatted a disk and the result was an incorrect sector count. This was using Omniview 256 (800 replacement) OS. Perhaps I had a corrupted copy of 4.55. (?)

 

-Larry (who sometimes uses SDX and recognizes it's power, but still is most comfortable with good ol' MyDos)

 

 

Hello Larry

 

The bug you mention does (read: did) exist. I've seen it destroy partitions too.

 

Some of the bugs I mentioned before in another thread:

 

- Something was wrong with the MEM.SAV feature.

- The memory detection routine got screwed up (that's why there's a patched version of MyDOS 4.50 for the Newell 1MB upgrade)

- If you change the PERCOM Block and then tell the drive to format, MyDOS will not look at the Percom block but format the drive according to the settings in (or set via???) DUP.SYS

- pre-4.55 beta 3 versions don't check the size of your RAMdisk before copying the content of your RAMDISK: subdirectory to your RAMdisk

- There was an error in the VTOC building routine

- If you don't use a period between filename and extender (possible if the filename is 8 characters long or replaced by the asterisk) the first character of the extender is sometimes chopped off (and the rest of the extender moved forward one character)

 

Some other bugs:

 

- Sidedness isn't always displayed correctly

- MyDOS shows S or D as the density, but never E

 

And there are probably more. But the bugs mentioned above are all fixed at the moment.

 

sincerely

 

Mathy

[1050]

Perhaps there are other conditions that must be met in order to produce this bug as described.

 

Very much yes.

 

Or perhaps this was an earlier version. (?)

 

4.50 - I'll swear to that.

 

I'm going to look through the notes for the the "fixed" ramdisks, but as I understand the bug, it can't be confirmed as described. "Busted?"

 

-Larry

 

You wouldn't be so quick to say Busted if it was you that lost a partition like I did. I can't remember just how it happened but it was totally gone before I could even believe it happened.

 

But I did recently hear of a MyDOS bug that you won't find so easy a way around. Just try to (J) Duplicate Disk with a fullish Enhanced Density disk. Come back and tell us of your successes, soon. Funny how it works OK with either SD or DD too, now is that a bug or a feature?

[Mathy]

Hello Larry

 

All the above bugs were still in 4.50 and are now fixed in 4.55 beta 5 (which I do not have). I seem to remember that even the Duplicate Enhanced Disk bug mentioned by 1050 is fixed, but I'm not sure.

 

sincerely

 

Mathy

[+Larry]

Hi-

 

Thanks for your input. As much as anything else, I hope to learn more of the foibles of MyDos (and just maybe dispel a few incorrect notions or provide some work-arounds).

 

Presumably you didn't have a backup when you lost your partition. About the closest I can come to your experience is that when working with a Happy drive as D2: -- probably doing something unsavory. I managed to get things bolixed up enough to format my D1: which was my MyDos MIO HD. Yes, definitely a disconcerting experience! (I had a backup, but was still a pain because it was on 3-1/2" floppy disks.)

 

About the ED thing... I almost never use ED at all, but as a test, I formatted two MyDos 1040 sector images (for those who don't know -- this is very different from Dos 2.5's version of ED). Formatted them using MyDos 4.50, showing 1027 free sectors. Copied files from my HD to one of the images. After copying, I had 44 free sectors, and verified the VTOC with VTOC Fix V1.2. All was well, so I copied one image to the other using MyDos J with no parameters. Copied perfectly and then I verifed the target VTOC -- again no errors. Repeated the test using J's "copy sectors" copying 1-1040. Same result -- no issues. So perhaps as with the ramdisk issue, something else must take place to unleash the bug.

 

I have really disliked ED, especially when getting Dos 2.5 disks that are formatted that way and trying to deal with those in MyDos. However, reading the MyDos 4.5 docs last night, it states that MyDos can fully READ all the sectors of a 2.5 ED disk. I never knew that -- and I tested it and it works! However, it can't write to the 2nd 2.5 directory/VTOC, showing 0000 free sectors on the disk and immediately "squawking" with an error 162 if you try to write.

 

-Larry

 

 

Perhaps there are other conditions that must be met in order to produce this bug as described.

 

Very much yes.

 

Or perhaps this was an earlier version. (?)

 

4.50 - I'll swear to that.

 

I'm going to look through the notes for the the "fixed" ramdisks, but as I understand the bug, it can't be confirmed as described. "Busted?"

 

-Larry

 

You wouldn't be so quick to say Busted if it was you that lost a partition like I did. I can't remember just how it happened but it was totally gone before I could even believe it happened.

 

But I did recently hear of a MyDOS bug that you won't find so easy a way around. Just try to (J) Duplicate Disk with a fullish Enhanced Density disk. Come back and tell us of your successes, soon. Funny how it works OK with either SD or DD too, now is that a bug or a feature?

[Mathy]

Hello Larry

 

I almost forgot. The other thread I was talking about is the RAMdisk thread you mention in your first posting above.

 

sincerely

 

Mathy

[1050]

Repeated the test using J's "copy sectors" copying 1-1040. Same result -- no issues. So perhaps as with the ramdisk issue, something else must take place to unleash the bug.

I stand corrected then at least in the 'not so easy to get around it' department, but you kind of cheated. You were supposed to let MyDOS detect the required format and do the formatting of the destination disk on it's own choosing in the middle of the (J.) Duplicate Disk process itself. AND you should have used only one drive, did you? Somehow in your preformatting of the target disk you left the drive(s?) in that configuration and you got lucky. Here I could not get lucky no matter what I did even when I tried the above. You real lucky.

I have really disliked ED, especially when getting Dos 2.5 disks that are formatted that way and trying to deal with those in MyDos. However, reading the MyDos 4.5 docs last night, it states that MyDos can fully READ all the sectors of a 2.5 ED disk. I never knew that -- and I tested it and it works! However, it can't write to the 2nd 2.5 directory/VTOC, showing 0000 free sectors on the disk and immediately "squawking" with an error 162 if you try to write.

 

-Larry

 

For those of us that came up with only one unmodified 1050 drive, DOS 2.5's ED was the only logical choice since it's +999 sectors were so much more than the 720 SD format. When I finally got a ramdisk and realized the full potential there, only then did I change over to MyDOS and went thru the hell you descibe until I had gotten all my 2.5 files moved over. It made me absolutely crazy more than once, but I can't say I dislike it since it meant so much to me at one time.

 

Try using the /X feature for copying files. This is supposed to invoke a swap disk mode which would be particularly important to have working on the very simple single drive system I just mentioned. You've got a huge file on a crowded disk and you want it all alone on freshly formatted disk so you have more room to allow it to grow. Use the /X feature to allow MyDOS to pause and prompt you to insert the source and destination disks as needed since the file is large enough to cause multiple reads and writes while both files remain open for that activity. Most important to use only one drive for this attempt. I could never get it to work here, so I assumed I didn't know what I was doing right or wrong, and I quit trying to use the feature as soon as I got a 2nd drive anyway. Has this one finally run you aground with a jolt?

[+Larry]

Hi-

 

> You were supposed to let MyDOS detect the required format and do the formatting of the destination disk on it's own choosing in the middle of the (J.) Duplicate Disk process itself. <

 

You didn't specify that or the one drive copy initially, so I just made the copy the way I normally would.

 

But OK, I've run some more tests and more variations. I hope I've got this correct -- I've tried enough different things this morning that my brain is getting scrambled!

 

1) In my original post, I did mention using images simply because it's a lot handier than using floppies. Like using two drives, it's the way that I typically use my Atari systems. It turns out that APE & images really mitigate this ED bug.

 

2) The bug really seems not to rear it's head when using ATR images, likely because when you create the image, APE "knows" the size/type of image. So if I disk copy (J) between images, the copy doesn't fail. As best I can tell, it never failed. This includes "swapping" images using the same "drive" number (J) 2,2.

 

3) When using a real 1050, things are different. As best I can tell, when MyDos formats the target disk during the ED copy process, it will always format the target with a single density VTOC, showing 708 free sectors. Hence when it runs out of space, the copy fails.

 

4) I thought that I could get around this by using the /N switch to prevent MyDos from incorrectly formatting the target disk. That partially works. But the last file on the target disk consistently shows BAD LENGTH using VTOCFIX.COM. However the rest of the copy checks OK. A kludge work-around is to re-copy the last file to the target disk. VTOCFIX then finds no errors with the disk.

 

5) A much better fix is to use (J) 2,2/N(1-1040) to make the disk copy by sectors. This seems to work in all cases.

 

So, yes, this bug can be replicated and hopefully it is fixed in 4.55 B5.

 

-Larry

 

 

I stand corrected then at least in the 'not so easy to get around it' department, but you kind of cheated. You were supposed to let MyDOS detect the required format and do the formatting of the destination disk on it's own choosing in the middle of the (J.) Duplicate Disk process itself. AND you should have used only one drive, did you? Somehow in your preformatting of the target disk you left the drive(s?) in that configuration and you got lucky. Here I could not get lucky no matter what I did even when I tried the above. You real lucky.

 

For those of us that came up with only one unmodified 1050 drive, DOS 2.5's ED was the only logical choice since it's +999 sectors were so much more than the 720 SD format. When I finally got a ramdisk and realized the full potential there, only then did I change over to MyDOS and went thru the hell you descibe until I had gotten all my 2.5 files moved over. It made me absolutely crazy more than once, but I can't say I dislike it since it meant so much to me at one time.

 

Try using the /X feature for copying files. This is supposed to invoke a swap disk mode which would be particularly important to have working on the very simple single drive system I just mentioned. You've got a huge file on a crowded disk and you want it all alone on freshly formatted disk so you have more room to allow it to grow. Use the /X feature to allow MyDOS to pause and prompt you to insert the source and destination disks as needed since the file is large enough to cause multiple reads and writes while both files remain open for that activity. Most important to use only one drive for this attempt. I could never get it to work here, so I assumed I didn't know what I was doing right or wrong, and I quit trying to use the feature as soon as I got a 2nd drive anyway. Has this one finally run you aground with a jolt?

[1050]

You didn't specify that or the one drive copy initially, so I just made the copy the way I normally would.

Yes, my bad there. You are not alone testing at less than full throttle, I suspect that's how the bugs got under the radar in the first place. Two drives makes a big difference if it's a one drive bug. I've used the MAC/65 cart with the emulator and got away with ARCing and UNARCing in the ramdisk while the cart was 'plugged in' - you don't get to do that in the real world!!

 

While you rest up to take the /X bug for a spin, here is that ramdisk bug. It's actually in RAMBOOT3 but 'remnants' are still in 4.50 itself. Marslett shuts off the ramdisk by storing the byte FF into $070A, Puff does it by storing the byte 00 instead. The CIO/SIO routines take the FF byte and translate it into a very real D1: format while the same routines take the 00 byte and error out such that the actual format never takes place. While using 4.50, if you answer no to the question 'RAM disk present?', you will get FF stored to 070A which is a set up for a catastrophe even if one never fully develops. RAMBOOT3 is so buggy I don't think it's actually used by anyone, but it will sure enough format D1: for you.

 

Please use this 'clean' version of beta3 as the mooked version available in the ramdisk thread has had the copyright date fudged with. I hope Marslett doesn't ride thru here with guns a blazing. Download this, make it a real disk, boot it on a real machine, move it to D2: and put a work disk in D1:. Then load RAMBOOT3 as a normal load-N-go file and watch D1: get formatted and MEM.SAV written to it, which is not how MyDOS's MEM.SAV is supposed to even work in the first place, just to add more confusion it seems.

 

Md455_b3.zip

[Mathy]

Hello 1050

 

You shouldn't use RAMBOOT3 anymore. Please use either MYRD or MYRD2 which you can find (in one .ARC it seems) on my MyDOS page.

 

sincerely

 

Mathy

[+Larry]

Hi-

 

So there it is! Yes, it absolutely formatted my D1: and ultimately wrote MEM.SAV to it (649 free sectors). I can see why I never have run across it before, since I never used RAMBOOT3 nor have I tried to use the ramdisk file as a regular BLOAD.

 

But this gets more interesting. I cannot get this bug show itself using these exact steps with original MyDos 4.50 Dos files. So that begs the question -- is this something that has been unleashed because of changes to 4.50? I tried the same experiment (with the Public Domain release version of 4.50) both not configured and configured for a D8: ramdisk.

 

When not configured, it does not set up a ramdisk. It does read (slowly) the DUP.SYS file, but evidently does nothing with it.

 

When configured for the ramdisk, it sets up D8: as it is supposed to. As above, it slowly reads DUP.SYS from D1: and in this case transfers it

to D8:. It clearly doesn't behave properly, but no disk formatting. Will you try this and see if you can verify my findings?

 

The "clean" release version is available at the CSS support files page:

http://www.nleaudio.com/css/Files.htm

 

I'm confident that Mathy has a "stock" version at his site, also.

 

-Larry

 

 

Yes, my bad there. You are not alone testing at less than full throttle, I suspect that's how the bugs got under the radar in the first place. Two drives makes a big difference if it's a one drive bug. I've used the MAC/65 cart with the emulator and got away with ARCing and UNARCing in the ramdisk while the cart was 'plugged in' - you don't get to do that in the real world!!

 

While you rest up to take the /X bug for a spin, here is that ramdisk bug. It's actually in RAMBOOT3 but 'remnants' are still in 4.50 itself. Marslett shuts off the ramdisk by storing the byte FF into $070A, Puff does it by storing the byte 00 instead. The CIO/SIO routines take the FF byte and translate it into a very real D1: format while the same routines take the 00 byte and error out such that the actual format never takes place. While using 4.50, if you answer no to the question 'RAM disk present?', you will get FF stored to 070A which is a set up for a catastrophe even if one never fully develops. RAMBOOT3 is so buggy I don't think it's actually used by anyone, but it will sure enough format D1: for you.

 

Please use this 'clean' version of beta3 as the mooked version available in the ramdisk thread has had the copyright date fudged with. I hope Marslett doesn't ride thru here with guns a blazing. Download this, make it a real disk, boot it on a real machine, move it to D2: and put a work disk in D1:. Then load RAMBOOT3 as a normal load-N-go file and watch D1: get formatted and MEM.SAV written to it, which is not how MyDOS's MEM.SAV is supposed to even work in the first place, just to add more confusion it seems.

 

Md455_b3.zip

[1050]

So that begs the question -- is this something that has been unleashed because of changes to 4.50?

I really doubt it. What you may not know is that all 4.50 distributions are preconfigured for a D9: ramdisk so even when you thought you weren't, you actually were. I did some testing here and got a D1: format when the 070A byte on the boot disk was FF as I expected. When the disk was preconfigured for a valid ramdisk number I got various results depending on if I actually had valid ramdisk bytes written back to the boot disk by using or not using (H) Write DOS files. When the disk had the correct info I got a ramdisk format correctly but sometimes I got MEM.SAV written to the boot disk anyway and never did I get DUP.SYS written anywhere.

 

What you may have run into also is the endless hunt for DUP.SYS that MyDOS often does when a mistake has been made and it falls back to loading DUP.SYS from each drive in turn. It did that here about three times and only found the wrong version once which of course causes a lock up. Why it couldn't find it at all one other time is beyond me but these things happen sometimes, I've not a clue.

 

The main problem with the D9: ramdisk for me is that you can't see that you have one from the menu display. Only when I hit 9 and a directory listing shows up do I really believe I have one anyway, 'out of the box' it's doubtful that you had the proper banking bytes in the table for it to acually work but it's possible?

 

I got similar enough results that I don't think it's 'a beta thing' or a problem with beta 3 in particular - it does work fine with MyRD2 as Mathy has suggested. I normally keep RAMBOOT3 in box with a very tight fitting lid!!

 

So don't forget to answer NO to 'RAM disk present?' AND write DOS files back and then see if 4.50 don't do what beta 3 did with the demo disk I posted one more time? Maybe a difference in the RAMBOOT3 files too, I haven't checked that yet. Playing with RAMBOOT3 is a lot like trying to catch a loaded and cocked revolver tossed into the air with a spin - one of these times...

[+Larry]

OK, I've reproduced the bug with a clean copy of 4.50 using the steps that you laid out:

1) Use RAMBOOT3.AUT (the bug does not appear from the other ramdisk file, RAMBOOT.AUT).

2) Configure MyDos with "No" to "ramdisk present?", and write the modified system files to a disk or image.

3) BLOAD -or- use AUTORUN.SYS to load RAMBOOT3.AUT

4) D1: is formatted and ultimately MEM.SAV is written to it.

 

I did not know that MyDos was pre-configured to use D9: as the ramdisk. That's handy to know. And fortunately, it's very easy not to get "stung" by this RAMBOOT3.AUT bug.

 

Edit: running a few tests, it appears that the default on my system disks is D8: (when used with RAMBOOT.AUT). I can't get D9: to function at all except by using the Set RAMdisk # (S). Also, yes, I've seen the DUP.SYS search on the other disks before. I've learned a lot from this thread -- thanks.

 

I have previously read about the /X switch -- that it basically doesn't work. I'll have to review my notes. Do you have any specific comments about it? All of this good info is going into my MyDos doc notes.

 

-Larry

 

I really doubt it. What you may not know is that all 4.50 distributions are preconfigured for a D9: ramdisk so even when you thought you weren't, you actually were. I did some testing here and got a D1: format when the 070A byte on the boot disk was FF as I expected. When the disk was preconfigured for a valid ramdisk number I got various results depending on if I actually had valid ramdisk bytes written back to the boot disk by using or not using (H) Write DOS files. When the disk had the correct info I got a ramdisk format correctly but sometimes I got MEM.SAV written to the boot disk anyway and never did I get DUP.SYS written anywhere.

 

What you may have run into also is the endless hunt for DUP.SYS that MyDOS often does when a mistake has been made and it falls back to loading DUP.SYS from each drive in turn. It did that here about three times and only found the wrong version once which of course causes a lock up. Why it couldn't find it at all one other time is beyond me but these things happen sometimes, I've not a clue.

 

The main problem with the D9: ramdisk for me is that you can't see that you have one from the menu display. Only when I hit 9 and a directory listing shows up do I really believe I have one anyway, 'out of the box' it's doubtful that you had the proper banking bytes in the table for it to acually work but it's possible?

 

I got similar enough results that I don't think it's 'a beta thing' or a problem with beta 3 in particular - it does work fine with MyRD2 as Mathy has suggested. I normally keep RAMBOOT3 in box with a very tight fitting lid!!

 

So don't forget to answer NO to 'RAM disk present?' AND write DOS files back and then see if 4.50 don't do what beta 3 did with the demo disk I posted one more time? Maybe a difference in the RAMBOOT3 files too, I haven't checked that yet. Playing with RAMBOOT3 is a lot like trying to catch a loaded and cocked revolver tossed into the air with a spin - one of these times...

Edited September 1, 2010 by Larry

[Mathy]

Hello Larry

 

IIRC the D9: thing is in the MyDOS docs. Either in MAIN.DOC or TECH.DOC. D9: can only be used for the RAMdisk, not for a physical drive (unless your OS or PBI device uses it's magic to realize that).

 

The /X bug is killed in the latest versions of MyDOS if memory serves me right.

 

sincerely

 

Mathy

 

PS a new version of MyRD should be in CharlieChaplin's inbox, meaning the "large files into RAMdisk" bug is being squashed as we speak.

Edited September 1, 2010 by Mathy

[+CharlieChaplin]

Hello Larry

 

IIRC the D9: thing is in the MyDOS docs. Either in MAIN.DOC or TECH.DOC. D9: can only be used for the RAMdisk, not for a physical drive (unless your OS or PBI device uses it's magic to realize that).

 

The /X bug is killed in the latest versions of MyDOS if memory serves me right.

 

sincerely

 

Mathy

 

PS a new version of MyRD should be in CharlieChaplin's inbox, meaning the "large files into RAMdisk" bug is being squashed as we speak.

 

 

As of yet,

there is nothing in my inbox. May have to wait a couple of more hours...

-Andreas.

Edited September 1, 2010 by CharlieChaplin

[Mathy]

Hello Andreas

 

I sent it to the email address you mentioned in the last ABBUC magazine on page 19 yesterday, a few minutes after 8 pm.

 

sincerely

 

Mathy

Edited September 1, 2010 by Mathy

[+Larry]

Hi Mathy-

 

I'm not sure we are saying quite the same thing.

 

1050 indicated (if I understood correctly) that D9: is a default ramdisk device that is "hard-coded" into MyDos 4.50. So if I never configured MyDos for a ramdisk, but had a ramdisk file/driver present, then it would be D9: and I would be unlikely to know it, since it doesn't appear in the status bar on the DUP menu display.

 

But if I do not configure 4.50 (clean) for a ramdisk and have RAMBOOT.AUT loaded (as AUTORUN.SYS) then D8: always shows up in the display as 8R. I can manually switch this to D9: using the "S" menu command. It doesn't show up in the menu, but doing a directory on D9: properly shows it's contents. Carrying this one step further, after using the "S" command and writing the (revised) Dos files out to disk, then when I boot that disk/image, D9: is the ramdisk. So using "S" seems equivalent in this respect to going through the "O" (ramdisk portion) configuration.

 

I tried the exact same thing using RAMBOOT3.AUT, and in this case D9: was set up, so it appears that the two Ramboot files set up different drives as R(amdisk). Presumably that means that the ramdisk numbers are in the ramboot files (which seems very logical).

 

-LW