Weird ERROR 130 error in DOS 2.5

[Rybags]

It is a limitation of Dos, actually DUP to be precise.

 

The problem is that in between where the DOS program ends and where DUP gets loaded is the space that Dos is able to allocate buffers for files and drives without conflicting with DUP.

The original intent of DOS 2.x was that there'd never be more than 4 drives to worry about. But throw in a Ramdisk and suddenly you can have 5 and that's when you get this problem.

Hardware has nothing to do with it.

[Marius]

You may be correct. I tried with Altirra and 15 for 4 drives, worked, so did 63 for 6 drives.

It isn't a limitation of DOS 2.5, it may be a limitation on the real hardware.

You don't have to hit RESET, at least in Altirra just type DOS to enter DUP after the POKE.

This is without the D8: RAMdisk.

You'd sorta have to have a APE/SIO2PC to test with all those drives on real hardware.

Also, you might have memory insufficient, each drive requires a buffer.

 

The question is: what did you try with the 4 drives.

 

The problem ONLY exists after copying a file; using DOS 2.5 menu. It does not matter What Dx: or Dy: is as long as a file is copied from Dx: to Dy: an Error 130 appears AFTER the copy process.

 

It's hardly a problem, unless you want to copy several files from Dx: to Dy: in ONE pass. (Copy *.*) since DOS stops copying after that Error 130 occurs.

 

The Error 130 message is strange, since the copy process actually works; so which device he tries to open/close is puzzling me. Probably is the device table or a buffer overwritten or so.

 

I did not try it yet, but I'm pretty sure the DOS configuration program does the SAME thing as your poke command, so I don't expect it to work suddenly (I'm going to try it though).

 

It's not a limitation of the hardware since there is no hardware reason for this issue.

[Marius]

@Russ

 

When you access a non configured disk number in DOS you get an error 160, not error 130 (!)

 

So when I try to access D4: when it is not setup, I do get error 160. I was talking about a weird error message "Error 130" which is not a regular error message when it comes to Diskdrives. You'll get Error 130 when you try to access the R: device, and the R: driver is not loaded....

 

So this Error 130 problem has nothing to do with the bits that are true or false for D4:

[russg]

@Russ

 

When you access a non configured disk number in DOS you get an error 160, not error 130 (!)

 

So when I try to access D4: when it is not setup, I do get error 160. I was talking about a weird error message "Error 130" which is not a regular error message when it comes to Diskdrives. You'll get Error 130 when you try to access the R: device, and the R: driver is not loaded....

 

So this Error 130 problem has nothing to do with the bits that are true or false for D4:

Yes. I can get a directory of all six drives. But I get error 130 trying to copy from/to D2:

I also get error 130 just deleting a file on D1: It deletes it, but errors 130 at the end.

This should be when the E: device is giving a DUP menu.

It's like the E: or S: handler in device handler corrupted. I'd suspect Altirra, but

I guess you're using real hardware.

I don't remember this problem from when I used DOS 2.5.

I'd have to find a real DOS 2.5 floppy. and set up a real Atari.

Maybe there's something wrong with the DOS 2.5 we're using.

[flashjazzcat]

Has Phaeron (amplified by Rybags) not already fully described the reason behind this issue?

[russg]

Has Phaeron (amplified by Rybags) not already fully described the reason behind this issue?

I hope so. I can't get 2.5 to do any copy, delete, just about anything. I've tried a different

DOS 2.5. I will look for Phaeron and Rybags.

Use a different DOS, like MyDOS.

Rybags has already answered in this thread.

Edited February 6, 2016 by russg

[Rybags]

Has Phaeron (amplified by Rybags) not already fully described the reason behind this issue?

 

Precisely. The problem and cause has been described. And it was a known issue which the Setup.com program actually warned you about (though it doesn't tell you exactly why).

 

Device handlers, hardware etc. have little/nothing to do with it. It's all down to the buffers running into workspace which happens to corrupt the filespec that's used during copy and probably some other operations as Phaeron described earlier.

 

Case closed. There's absolutely no point arguing or complaining about it. It is what it is.

In any case, if you're a "power user" who needs to use 3 or more drives at a time, Atari's DOS 2.x is about the last thing you should be using.

Throw away the training wheels and use SpartaDos instead.

[Kyle22]

Plain and simple. If the DOS buffers encroach into and overwrite the DUP.SYS machine code program, then the unpredictable odd thing will happen. Unexpected errors, etc. Just be glad that it didn't format your disk. This is a corrupted code problem because of poor design from the start. AtariDOS was never meant to handle that many drives/files, and the buffers (and DUP) are not relocatable, therefore, there is a problem.

 

The only fix is to use SpartaDOS (or MyDOS if you must). End of discussion!

[Marius]

Lol

 

There is no discussion. Russg was giving advice, and I replied to him that his advice was not working, since he obviously did not test the results of his advice in the way the problem would show up.

 

I had a reason to use DOS 2.5 ... I haven't use this DOS since 1994 or so; and then I did run into the problem.

 

The reason I had to use it, was because I was trying (and succeeding) in using Speed Start INIT from E. Reuss on Medium Density formatted disks. On Abbuc forum I got a tool to format disks in Enhanced density to use them with Speed Start INIT. Unfortunately only DOS 2.5 was/is able to write this disks.

 

When I was doing some experiments with it, I did run into the issue of the Error 130.

As I wrote before (no discussion about it) I missed the warning on the screen. I thought it meant that I should not return to DOS and start using the configuration, but that I should write the DOS first and then reboot. The warning is not that clear you see. Since I did not try other configurations (I wanted to enable D1 D2 D3 D4 D8; so that was the first thing I typed in) I did not see that the warning does not show up when you only configure D1: D2: D3: D8 or so).

 

Rybags already gave the main answer, so that was end of story already for me. Since other people started with solutions, the thread kept going.

 

By the although although I understand the advice to use SDX or MyDOS, it's not suitable here. I already use all those other DOS (of course!)

 

By the way there are more very good DOS compatible with more drives. I love XDOS 2.43 from Stefan Dorndorf most for disk. And SpartaDos 3.3a most for harddisk; but that's because these DOS do meet my personal needs best.

 

Edit: typo

Edited February 7, 2016 by ProWizard

[Rybags]

If source code is available (or even without) a fix could be put in place.

Simply have Dup.sys reside a bit higher up in memory to allow for more buffers.

[Fox-1 / mnx]

Would it help to upload this?

 

 

(snippet from the source)

1270 *

1280 * link parts of FMS source

1290 *

1300     .INCLUDE #D:RECDOS1.M65

1310     .INCLUDE #D:RECDOS2.M65

1320     .INCLUDE #D:RECDOS3.M65

1330     .INCLUDE #D:RECDOS4.M65

1340 *

1350 * link resident part of DUP

1360 *

1370     .INCLUDE #D:RECDUP.M65

1380 *

1390     .END

1000 * RECDOS1.M65

1010     .PAGE "author notice"

1020 *

1030 * Atari FMS was originally written in the second half of 1978

1040 * by Paul Laughton, assisted by Paul and Kathleen O'Brien

1050 * It was updated (19 Aug. 1980) by Paul Laughton for

1060 * the Atari DOS 2.0S.

1070 * The DOS 2.5 version (adapted for enhanced density

1080 * by Bill Wilkinson???) was released in late 1984.

1090 *

1100 * This is a reconstructed & commented version of the

1110 * enhanced density DOS.SYS source file.

1120 *

1130 * A description of Atari DOS is published by COMPUTE!

1140 * as INSIDE ATARI DOS.

1150 *

1160 * system equates

1170 *

1180 ZICB =  $20     zero page i/o control block

1190 FMSZPG = $43    DOS zero page registers (7 bytes)

1200 STAK =  $0102   stack loc for put byte

1210 DSKTIM = $0246  addr of o.s. worst case disk time out

1220 LMADR = $02E7   pointer to bottom of free memory (called MEMLO by the o.s.)

[Marius]

Not sure... since the problem is in DUP and not in DOS

Do you have source of DUP.SYS 2.5?

[Fox-1 / mnx]

 

1370     .INCLUDE #D:RECDUP.M65

 

It's both DOS and DUP.

[Rybags]

Possibly both might need modification. With DUP relocated, the operation of Mem.sav would change. I would think the core Dos program would handle most/all of that.

[Kyle22]

Reassembly at a higher, non-conflicting address would be the only proper way to fix this. The only down side is that there will be less memory available for user programs.

[1050]

Here <== DOS 2.5 source

http://atariage.com/forums/topic/130992-here-dos-25-source/

 

And mighty good luck with that. After looking it over a long time ago, I never attempted to assemble it myself to see if it even would.

[Fox-1 / mnx]

Reassembly at a higher, non-conflicting address would be the only proper way to fix this.

Relocating parts of it to the area under the O.S. is a way to free up memory but introduces lot's of incompatibility issues at the same time, and since there are other DOS's using that approach it's of not much use anyways since you can simply use those versions.

[thorfdbg]

Reassembly at a higher, non-conflicting address would be the only proper way to fix this. The only down side is that there will be less memory available for user programs.

Actually, it would be much more helpful if DUP would have been relocatable....

[Kyle22]

Actually, it would be much more helpful if DUP would have been relocatable....

Would have, Could have, Should have....

[_The Doctor__]

What's the harm if someone does move things just enough and we get dos 2.5++ or whatever... if it only moves a little bit it might still be pretty darn compatible with just about everything anyway...

[Fox-1 / mnx]

Dos 2.5 is more or less considered a standard. With the exception of Dos specific software, as long if your program runs with Dos 2.5 you're safe. Changing Dos 2.5 means it's not Dos 2.5. anymore and there are already a lot of other Dos' around that are compatible with 2.5 (or at least claim to be, or close enough).

 

But if someone want to dive into it, be my guest, however I'd be more interested if it would get the option to work with all the regular densities (Single/Enhanced/Double) and maybe even Quad Density (only if nothing has to be sacrificed).

[_The Doctor__]

its' only bumping into the area ever so slightly... working around it somehow might not change it enough to break its compatibility... that part seemed reasonable... however adding all the density control might change the length of things significantly unless it could be written in the error handling spaces of 2.5.... Some people are amazing coders so anything is possible...

[Fox-1 / mnx]

Anything that makes it more useful without loosing compatibility is worth a try.