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.