An issue (?) in SpartaDOS 3

[drac030]

Not sure if this is a bug in SpartaDOS 3 or maybe a misconfiguration (but I have no idea how to fix it in the latter case), but here is what I stumbled upon some day:

 

I have a binary program which consists of several init segments and one run segment. This program loads fine and works under DOS 2.5, DOS XL 2.30, MyDOS 4.55p, BW-DOS 1.30 and, last but not least, SpartaDOS X.

 

But with SpartaDOS 3.2d, 3.2g and 3.3a there is only a less or more spectacular crash during loading. I have found out that this crash occurs, because after the second init segment SpartaDOS 3 thinks that the loading is finished, thus (since the run vector has not yet been set at this point) making a call to the "beginning of the program", i.e. the first init segment, which at this time is of course long non-existing.

 

Now the second init segment opens and parses a configuration file. And this - particularly the OPEN call - causes all this confusion. The file does not even have to exist: it is enough to make an OPEN 4,"D:FOO.BAR":CLOSE in an init segment to trigger this problem.

 

If this is not fixable in a simple manner (like by changing a default parameter in SpartaDOS binary), I would say that this looks like a flaw disqualifying SpartaDOS 3 as a DOS. For opening a file during loading a binary is to my knowledge in no way a forbidden operation. And even DOS 2.5 tolerates this well.

Edited February 21, 2020 by drac030

[Marius]

Perhaps @Stephen J. Carden knows more? Does the bug also occur on Real.dos?

 

Could you post an example test file?

[drac030]

I tried Real.DOS (build 30) and yes, it also crashes in these circumstances.

 

But I have to say that I cannot now reproduce the behaviour of jumping to the first segment that was loaded, although I was sure that I was observing that while debugging what is wrong with the original program. Now (with the example below) the DOS's behaviour is that after returning from segment 1 it simply at one point jumps from the middle of its code to the middle of nowhere. So maybe it matters after all if the file being opened exists or not... or there are other factors I did not see.

	.in ..>maeinc>sysequ.mae
	.out sd32down.obj
	.org $3000

; SEGMENT 0, NOT STARTED
begin0
	ldx #<txt_err
	ldy #>txt_err
putline
	txa
	ldx #$00
	sta icbufa,x
	tya
	sta icbufa+1,x
	lda #$ff
	sta icbufl,x
	lda #$09
_xciov
	sta iccmd,x
	jmp jciomain
txt_err
	.byte "Error!",$9b
end0

; INIT SEGMENT 1, STARTED AT INIT1
	.org end0+123
init1
	ldx #$00	;find free IOCB
?c	lda icchid,x
	cmp #$ff
	beq ?f
	txa
	clc
	adc #$10
	tax
	bpl ?c
?f	lda #<cfg	;try opening D:FOO.BAR
	sta icbufa,x
	lda #>cfg
	sta icbufa+1,x
	lda #$04	;for reads
	sta icax1,x
	lda #$00
	sta icax2,x
	lda #$03
	jsr _xciov
	lda #$0c	;close
	jmp _xciov
cfg	.byte "D:FOO.BAR",$9b

	.org $02e2
	.word init1

; RUN SEGMENT
	.org $4000
run	ldx #<txt_ok
	ldy #>txt_ok
	jmp putline
txt_ok
	.byte "Started OK",$9b

	.org $02e0
	.word run

 

sd32.mae sd32down.obj

[Rybags]

Why would the Dos think the load has finished after the second Init segment?

The only condition for that should be EOF.

 

Also (and 30+ years too late to complain) it's a bastardisation of the standard to assume the load address as Run address unless overridden within the file.

 

Another querie - if the first segment of the file is to populate the Init address, does SD 3 assume that to be the run address?  ie, JMP $2E2 at EOF

[drac030]

3 hours ago, Rybags said:

Why would the Dos think the load has finished after the second Init segment?

The only condition for that should be EOF.

Because of the internal confusion. My current hypothesis is that the internal DOS parameters for the file being opened within the init segment ("D:FOO.BAR" in the example above) influence (or override) the internal DOS parameters for the binary file being loaded. Therefore if "D:FOO.BAR" exists and has been read out, an EOF status was reached, but the binary loader thinks that this EOF was reached in the binary file, hence it attempts to run it.

 

When the "D:FOO.BAR" does not exist, the file is apparently internally marked as "not open", the loader trying to continue with the binary file gets an error 135, which is apparently so unexpected as to cause the DOS to crash.

[Rybags]

Could it be related to memory config, ie how many drives and buffers etc are allowed?

[drac030]

I do not know. But even if so, one would then expect error 161 (too many files open) and not a crash...

[Kyle22]

Konrad, I am still having error problems w/ 4.49d. I am running a 65c802 in an Incognito. I now work 7 days a week (because now I am 50% owner of the store) :) so I don't have much extra time these days. I will install it again and do more testing and report results. IIRC, is was an error 146 Function not implemented when I had the error.

 

4.47 doesn't make the error, and 4.48 won't run at all because I don't have high RAM (Not possible on 802).

 

 

[drac030]

Kyle, as I told you, despite the 4.47 supposedly working, this looks like a hardware stability problem. Whether this is true or not, I cannot diagnose anything overseas without sufficient information. So:

 

1) first of all, to eliminate a hardware problem, please reproduce your exact setup on Altirra and report back, if the same problems occur there. This will prove, that the problem is in the software (and software can be fixed). By exact setup I mean the CPU (65C816+"High memory: none, 16-bit addressing" is 65C802) and the RAM config, the contents of the ROMs, the storage type, the disk contents, the DOS setup (config.sys and startup files) you use daily.

 

2) when you manage to reproduce the problem in this environment, please:

 

a) specify the hardware config.

 

b) specify all the resident drivers you use: file names, length of these files, time/date stamps on them.

 

c) quote the CONFIG.SYS file(s) you use and other startup files (like AUTOEXEC.BAT).

 

d) provide information, do you use TD.COM or not. If so, do the problems occur without.

 

Thanks.

 

[Marius]

Today I sent Stephen J. Carden an e-mail. I hope he will check that, and return to here. 

 

He is one of the people who could address this issue.

[Stephen J Carden]

On 2/21/2020 at 7:22 AM, drac030 said:

Not sure if this is a bug in SpartaDOS 3 or maybe a misconfiguration (but I have no idea how to fix it in the latter case), but here is what I stumbled upon some day:

 

I have a binary program which consists of several init segments and one run segment. This program loads fine and works under DOS 2.5, DOS XL 2.30, MyDOS 4.55p, BW-DOS 1.30 and, last but not least, SpartaDOS X.

 

But with SpartaDOS 3.2d, 3.2g and 3.3a there is only a less or more spectacular crash during loading. I have found out that this crash occurs, because after the second init segment SpartaDOS 3 thinks that the loading is finished, thus (since the run vector has not yet been set at this point) making a call to the "beginning of the program", i.e. the first init segment, which at this time is of course long non-existing.

 

Now the second init segment opens and parses a configuration file. And this - particularly the OPEN call - causes all this confusion. The file does not even have to exist: it is enough to make an OPEN 4,"D:FOO.BAR":CLOSE in an init segment to trigger this problem.

 

If this is not fixable in a simple manner (like by changing a default parameter in SpartaDOS binary), I would say that this looks like a flaw disqualifying SpartaDOS 3 as a DOS. For opening a file during loading a binary is to my knowledge in no way a forbidden operation. And even DOS 2.5 tolerates this well.

Hi All.  This is not any code I have written. I need some one to send me the program so I can see what it is trying to do or if it is a virus program.  Also Because of lance ringquest I do not support any version of SpartaDos 3.3 a,b,c,d. My Ramdisk programs and tdline2 will work with all versions of spartaDos  I have been a bit sick lately but I do have some cool stuff for realdos on its way.

 

Take care Steve

[flashjazzcat]

Konrad has provided everything you need above (examples, source code, etc).

[Stephen J Carden]

On 2/22/2020 at 1:30 PM, drac030 said:

Because of the internal confusion. My current hypothesis is that the internal DOS parameters for the file being opened within the init segment ("D:FOO.BAR" in the example above) influence (or override) the internal DOS parameters for the binary file being loaded. Therefore if "D:FOO.BAR" exists and has been read out, an EOF status was reached, but the binary loader thinks that this EOF was reached in the binary file, hence it attempts to run it.

 

When the "D:FOO.BAR" does not exist, the file is apparently internally marked as "not open", the loader trying to continue with the binary file gets an error 135, which is apparently so unexpected as to cause the DOS to crash.

Hi all!

     Once again why are people loading and running this file when it is a problem file. This is not a program I have written. I have no idea where it comes from. But the program name means F*cked up beyond all recognition.  That is what foo bar means.   Draco was kind enough to turn it back into source.  This kinda of crappy programming is why all my new stuff has a header section that tell a bunch about all my support program. The update I am working on will include a way to set and/or check a crc of any of my support program. I am writting a program what will allow the the end user to set a few function like displaying certain text out of a program. I am also removing  lance ringquest out of all my programs. I just want to get back and update a few things with the support files. I have also received emails wondering if I am competing with sdx which I am not. SDX being a cart dos has a place for all. just like RealDos, MyDOS and all the other DOS's have there place. Most users do not know That I donated hardware so it would be supported with SDX. For the most part RealDos does everything I need. but I still have my hardware that has SDX Carts in them.  I have some cool support files coming.

 

Every One Take care and have a great Day!

Stephen J. Carden Ph.D

[flashjazzcat]

3 minutes ago, Stephen J Carden said:

Once again why are people loading and running this file when it is a problem file. This is not a program I have written. I have no idea where it comes from. But the program name means F*cked up beyond all recognition.  That is what foo bar means.

F*cked Up Beyond All Recognition = FUBAR, not FOO.BAR. Foobar is a placeholder in computing:

 

Foobar

 

5 minutes ago, Stephen J Carden said:

This kinda of crappy programming is why all my new stuff has a header section that tell a bunch about all my support program.

The assertion is that there is no reason why a perfectly well-behaved application should not want to open a secondary file on another channel as part of its initialisation process, before the binary load has completed. If the DOS binary loader disallows this or - as is the case with Sparta 3 and derivatives - becomes confused as a result, then it is DOS, not the binary file, which exhibits 'crappy programming'. The easiest solution would be to fix the issue in DOS.

[+Eyvind Bernhardsen]

2 hours ago, flashjazzcat said:

F*cked Up Beyond All Recognition = FUBAR, not FOO.BAR. Foobar is a placeholder in computing:

 

Foobar

Quote

It is possible that foobar is a playful allusion^[2] to the World War II-era military slang FUBAR (Fucked Up Beyond All Repair).^[2]

 

Fun fact: both "foo" and "bar" are banned in Microsoft source code (along with lots of other controversy-adjacent terms).

[_The Doctor__]

Mr. Carden may have had a memory lapse, he's used such conventions before at least in conversation. Please be kind. Many of us have the same kind of issues. I ask you remind and be kind. We still have much to offer.

Edited September 23, 2021 by _The Doctor__

[flashjazzcat]

Is there evidence of unkindness in any of the above responses? I'm not entirely sure how I can participate in a discussion without presenting a point of view.

 

[_The Doctor__]

I'm super guilty of this myself... It's a tone thing... and perhaps I am being to touchy.

Sometimes getting direct and to the point is too terse, or sometimes stream of consciousness rambling makes it come off wrong. There is nothing wrong in the plain truth of the responses. But maybe just prefacing it with a little qualifier of some kind can help keep the usual pile on that generally occurs and even I participate in from happening.

I know he means well as do we all. It's a hope to keep it from going wrong is the thing.

I do understand where the crappy programming statement comes from though(in the response)...

• I agree with darn near everything you have said.

as I read responses from folks I tend to combine them as a direction of the whole conversation these days and re-attribute bits of each to all in the conversation as a slope towards whatever it became. Sometimes I see this in my own posts and think that if someone hadn't built on my post it wouldn't be taken the wrong way. I also find that my building on another persons post can do the same. I just saw it possibly becoming a pile on and jumped in hoping to head it off at the pass.

 

Good to see Stephen back on AA and hope he gets back into the groove and catches up on the forum. Great to see the clarity you bring as well FJC.

Edited September 23, 2021 by _The Doctor__

[drac030]

4 hours ago, Stephen J Carden said:

Once again why are people loading and running this file when it is a problem file. (...) Draco was kind enough to turn it back into source.

The source code presented in post #3 is an extract - in source form - from a larger program of mine, and the result of my debugging, why that program crashes badly while being loaded under SpartaDOS 3 and derivatives, whereas in the rest of the DOS-es listed it loads and runs fine.

 

The listing pinpoints the exact code which causes the crash (in init1), and, because that code seems completely legit, the cause of the crash must be a problem inside SpartaDOS 3 binary loader, which goes bananas when an init segment is doing an OPEN call to the CIO.

 

It may be actually very simple to fix, e.g. perhaps some internal channel number should get preserved across a call to jmp ($02e2).

 

I know that people have teh SpartaDOS 3 source, and Real.DOS has its active developer, so this could get fixed. That is why I posted this, just as a bug report.