SpartaDOS - Early Versions

[Alfred]

 

BTW, what is the ICD XASM65 assembler, noted in the comments? I don't think I've ever heard of that before. Does it have any relation to the Avocet cross-assembler products?

 

avocet cross asm.jpg

 

I don't think so. Best I know, xasm65 is just the assembler that Gustafson wrote for ICD. I seem to have source for three different versions, the last being 1.4. I just noticed that myself when I was looking over your post, which begs the question, what were they using before Mike wrote that assembler ? Anyway, it all works, the assembler and the linker. The linker will produce standard Atari binary files, although oddly it names them with a .ATR extender. I would have thought he would make it default to .COM, but perhaps they used the same linker for building ST products and wanted an easy method of distinguishing the binaries.

 

I suppose 3.5 could be fixed, but why bother ? It doesn't offer anything over normal SpartaDos.

[+MrFish]

I don't think so. Best I know, xasm65 is just the assembler that Gustafson wrote for ICD. I seem to have source for three different versions, the last being 1.4. I just noticed that myself when I was looking over your post, which begs the question, what were they using before Mike wrote that assembler ? Anyway, it all works, the assembler and the linker. The linker will produce standard Atari binary files, although oddly it names them with a .ATR extender. I would have thought he would make it default to .COM, but perhaps they used the same linker for building ST products and wanted an easy method of distinguishing the binaries.

 

OK, maybe just coincidence about using the same name.

 

So, an ICD in-house development tool. I'd love to have a look at that. Have you actually used it much yourself?

 

Good question ("what were they using before XAsm65?")... Mac/65?

 

 

I suppose 3.5 could be fixed, but why bother ? It doesn't offer anything over normal SpartaDos.

 

I don't use SpartaDOS (any variety), and have no plans to in the future. I barely need any DOS for what I do, and

when I do, DOS 2.5 or whatever is sufficient. I'm mainly interested in it for preservation and to have a look at

something from a producer of great products. It's kinda like prototype games: some may not be very complete or

even very interesting, but still unique pieces of history for Atari software.

 

I agree, I don't see much point in rushing to fix 3.5a (although somebody else may think so), but, if a version 3.5

exists that does function properly, then I'd be very interested in checking it out and seeing it preserved. I suppose

being that it's a disk version too, some may be interested in the final disk version for actual use -- seeing that some

favor disk versions of SpartaDOS for their particular setups.

[Alfred]

 

So, an ICD in-house development tool. I'd love to have a look at that. Have you actually used it much yourself?

 

No, I have never used it myself. There's no doc for it, since of course Mike would already know. It use an odd (to me) structure where every routine is labelled as a "procedure" like this:

 

; dir_mode

; B[7]: 1 = put size and TD and end of line

; B[6]: 1 = Include attributes after filename

; B[5]: 1 = Put space between filename and extension

; B[4]: 1 = Replace above space with a '.'

; B[3]: 1 = Space over 2 for filename

; B[2]: 1 = 24 Hour clock

; B[1]: 1 = skip seconds on time field

; B[0]: 1 = put # sectors and end of line ('DIR' if dir)

 

seg c_file

;=================================================

; Create displayable directory entry

; ----------------------------------

; in:

; dentry = directory entry to process

; dir_mode= directory display mode flag

; out:

; ebuf = buffer containing directory entry

 

format_dir_entry: proc

jsr clebuf ; clear output buffer...

 

ldy #0

lda #8

bit dir_mode

beq ..fd1

lda dentry+DEsta ; if to skip first space, then

and #DESpro ; put protected flag there!

beq ..npro

lda #'*'

sta ebuf,y

..npro ldy #2 ; space over 2 for filename

 

..fd1 ldx #0

..nam lda dentry+DEfnam,x ; move entry name to buffer

sta ebuf,y

iny

inx

cpx #8 ; at ext pos?

bne ..ext ; jump if not

 

lda #32

bit dir_mode ; if 0, then no space before ext

beq ..ext

lsr a

bit dir_mode ; if 0, then insert a space

beq ..spc

lda #'.' ; else insert a period

sta ebuf,y

..spc iny

..ext cpx #11

bne ..nam ; jump if not at end

 

bit dir_mode ; if 0, then no attributes in display

bvc ..nattr

iny

jsr attributes

 

..nattr bit dir_mode

bpl ..nlong ; if 0, then not long dir listing

iny

jmp size_and_td ; else include size and time/date

 

..nlong lda #1

and dir_mode

beq ..xit

iny

jmp number_sectors

..xit rts

endproc

 

 

The worse problem is not knowing how the linker works, how the directives for mapping the final object file work etc. So I never bothered.

 

 

I agree, I don't see much point in rushing to fix 3.5a (although somebody else may think so), but, if a version 3.5

exists that does function properly, then I'd be very interested in checking it out and seeing it preserved.

 

I can't imagine a working 3.5 exists. I mean, AFAIK there's only three people alive who might still have a copy of the source: Me, Hohman and Gustafson. And I don't think those two have their copies any more.

[+MrFish]

 

No, I have never used it myself. There's no doc for it, since of course Mike would already know. It use an odd (to me) structure where every routine is labelled as a "procedure" like this:

 

The worse problem is not knowing how the linker works, how the directives for mapping the final object file work etc. So I never bothered.

 

I wouldn't expect any formal documentation; but, yeah, it seems entirely possible that none ever existed for it.

 

Still very interesting -- at least to me.

 

 

I can't imagine a working 3.5 exists. I mean, AFAIK there's only three people alive who might still have a copy of the source: Me, Hohman and Gustafson. And I don't think those two have their copies any more.

 

OK, I expected something like that to be the case. Still very cool to see that someone has this orphaned version, at least in some form. Thanks for sharing; it's great information.

[kenames99]

hi Alfred,

  I think a working copy of SpartaDOS 3.5 should be a thing. I may be able to fix it if I had the source. I do have src for spartdos 3.2 all versions, realdos all versions, so I have extensive experiece with them. I also have some experience with the xasm65 and xlink that Mike wrote but no docs for them. anyway, whatever you think best.

 

Ken

 

[kenames99]

On 3/13/2019 at 4:33 PM, MrFish said:

 

It says v3.5 was completed; so, you'd expect working. You posted 3.5a, which I guess is the continuation noted in the comments below v3.5.

 

 

 

BTW, what is the "ICD XASM65 assembler", noted in the comments? I don't think I've ever heard of that before. Does it have any relation to the Avocet cross-assembler products?

 

speaking of the Avocet Systems cross assembler, does anyone have the cross assem products that include avmac65 and avlink? plus there are other tools in the pkg.

 

Ken

 

[ijor]

On 10/23/2023 at 6:12 PM, kenames99 said:

I do have src for spartdos 3.2 all versions ...

😲 Really!? Original source with original comments? That would be the first time somebody claims he has source code for an ICD, and not FTE, version!

Edited October 24, 2023 by ijor