Ice-T XE 2.73 released

[itaych]

1. Your "small trick" involves using a BBS.

2. Do the arrows work properly with telnet?

[w1k]

yes, on telnet on pc works OK

[itaych]

In that case you need to post a detailed, step by step list of instructions to reproduce the problems you see. Your messages are far too short for me to be able to reproduce these problems myself. I highly prefer that you reproduce under Altirra as right now my real Atari is not set up.

[w1k]

best testing is on real hw.. i cant write detailed, cause my english is poor today i post photo..

[MEtalGuy66]

Can this version run from a "current directory" in SpartaDOS X?

 

Some "versions" of 2.72 could not..

 

Also, does it work with all of the various "850 emulating" R: handlers, such as the built-in handlers in the ICD P:R: CONNECTION and ICD MULTI I/O interfaces? That would be nice, rather than having to load a special disk-based handler...

 

Just some suggestions..

[itaych]

I've downloaded the latest version of SDX from the SpartaDOS Upgrade Project website. I mounted the cartridge image named SDX445_sdx128.car in Altirra, then tried to load Ice-T. What I can see is that the cartridge occupies memory in the low 48K range. Ice-T needs this range free and so can't work with it at all, and neither would any older version. Did I miss something?

Edited May 5, 2012 by itaych

[Roydea6]

X ICET

 

 

should do it.

[itaych]

Thanks, that works. Is there anything I could do to prevent the need for "X ICET"? Failing that, is there an easy way to detect SDX so I can put an informative message telling the user to use "X"?

[Fox-1 / mnx]

Example:

 

$0700 : "S" = SpartaDOS (all versions), "R" = RealDOS (all versions), "M" = MyDOS

$0701 : $32 = SpartaDOS 3.2, $40 = SpartaDOS X 4.0, $10 = RealDOS 1.0

$0702 : $02 = Revision 2 (Sparta-Dos X only)

Edited May 5, 2012 by Fox-1 / mnx

[Roydea6]

In the config.sys have these two lines:

DEVICE ENV.SYS

DEVICE COMEXE

 

And then rename ICET.COM >>ICET.EXE

[w1k]

i want ask if author this superb program planning a new version?

[itaych]

What about SpartaDOS 3.2g? It keeps putting an annoying status bar at the top of the screen, ruining the display. Is there anything I can do to make it stop?

[Fox-1 / mnx]

edit "STARTUP.BAT"

 

remove the line "TDLINE.COM"

 

Or enter "TD OFF" when it's booted with TDLINE enabled.

 

 

 

edit: typo

Edited May 5, 2012 by Fox-1 / mnx

[itaych]

Can this version run from a "current directory" in SpartaDOS X?

Tested and seen no problems.

Some "versions" of 2.72 could not..

I don't know of more than one version of 2.72, nor why any of them would behave differently from one another in this regard.

Also, does it work with all of the various "850 emulating" R: handlers, such as the built-in handlers in the ICD P:R: CONNECTION and ICD MULTI I/O interfaces? That would be nice, rather than having to load a special disk-based handler...

If you mean that these peripherals contain their own R: handler like the 850, they still need a tiny disk based handler (just like the 850 does) that requests the handler from the device. In that case you can use the 850's file, supplied with the distribution. Or did you mean something else?

[itaych]

Fox-1: is there a clever way to detect that TDLINE is running, so I can abort Ice-T's load telling the user to disable it?

Edited May 5, 2012 by itaych

[itaych]

SpartaDOS 3.2g has a weird behavior, where Ice-T tries to read/write the configuration file "D:ICET.DAT" but the file actually accessed is in the home directory of drive 1, regardless of the "current" path (disk and directory). I haven't seen this behavior in any other DOS including SDX. However the SDX I used is a recent version (4.45), perhaps this is a recent bug fix and MEtalGuy66 is using a version of SDX before the fix?

[Fox-1 / mnx]

Example how to turn on/off when using SpartaDOS 2.x/3.x (and probably also SpartaDOS X)

 

lda $D301
pha
and #$FE
sta $D301
ldy #$00 ; $00 / $01 to turn Off / On TD Line display
jsr $FFC6 ; TDLINE Vector
pla
sta $D301

 

As for the current path, remember that disk based version of SpartaDOS are different compared to SpartaDOS X. They only look alike, using the same disk/directory formats and share several vectors but are different beasts. I only use disk based versions (3.3x) myself.

 

When using SpartaDOS 3.3, the "?DIR" command returns the current path (working directory). This won't help you with inline code but I know it's possible to use the current directory for data files. Need to look it up.

[itaych]

Checked with SD3.3, same problem. "?DIR" only returns directory, not disk number.

 

Your code works under SD3.2 but crashes SDX... :/

Edited May 5, 2012 by itaych

[Fox-1 / mnx]

Try to use COMTAB ($0A) when running SpartaDOS.

 

COMTAB+33 is the start of a 28 bytes buffer which contains path info, including "D?:" It's also used to read/extract parameters from file names entered on the command line.

 

 

As for SDX... don't know. Someone else should jump in for this as I'm not an SDX user.

[flashjazzcat]

The TD vectors may be missing entirely in SDX, overwritten by software and their use "implies trouble", so says the manual. See pages 171 and 172 of the latest SDX 4.45 manual for a discussion of vectors under the OS. SDX now has a "get symbol" call in page 7 which you can use obtain vectors in the symbol chain, thereby permitting calls using "safe" methods. You should check for the page 7 vector (dependant on the SDX version, since it's a recently introduced facility), and only when no other method is viable, check the integrity of the vectors under the OS and only call them if they're still there.

Edited May 6, 2012 by flashjazzcat

[itaych]

Sorry, this is too complicated. I am automatically disabling TD for SD3, but SDX users will have to pay attention to what they're doing. I assume Ice-T isn't the only program that TD breaks.

 

As for the pathname (just 28 bytes??) I will look into it but I really don't like how SD breaks the simple concept of "D: is the current path".

[flashjazzcat]

Sorry, this is too complicated. I am automatically disabling TD for SD3, but SDX users will have to pay attention to what they're doing. I assume Ice-T isn't the only program that TD breaks.

 

Fair enough. I spent a LOT of time trying to ensure that the TD line didn't mess up the word processor's display, and there are still a lot of things it doesn't work with (VBXE modes for one). I suppose it's reasonable to ask users to disable it.

 

As for the pathname (just 28 bytes??) I will look into it but I really don't like how SD breaks the simple concept of "D: is the current path".

 

I believe D: always used to refer to D1: in SD 3.x, but in SDX D: refers to the current path on the current drive (which need not be D1:). This makes complete sense to me and is a change for the better. It ain't gonna change back to the old way, either, and making applications sympathetic to the underlying DOS is just one of those time-consuming and often frustrating tasks with which we developers are charged.

 

Also, note the maximum path length in SDX is 64 bytes. COMFNAM (COMTAB+33) is the destination buffer for the filename crunch routine, and is indeed 28 bytes long. This might seem short, but there's absolutely nothing to say you must use the ZCRNAME routine to pull parameters from the command line buffer. ZCRNAME simply translates the SDX kernel device names into SIO-friendly equivalents (where there is an equivalent). I eventually abandoned ZCRNAME altogether in The Last Word and read the CP arguments directly from the input buffer at LBUF (COMTAB+63).

 

It may seem "complicated", but KMK and Trub are usually happy to answer questions, and well they might be since well-behaved applications which play nice with SDX and make use of the advanced features just waiting to be utilized are of benefit to everyone. This is how I learned what I know about SDX - that, and picking my way through a google translation of the programming docs. I really hope KMK is getting somewhere with a proper English translation. It's clearly going to be useful.

Edited May 6, 2012 by flashjazzcat

[itaych]

I access the configuration file using 'D:'. If it works for everything except SD 3 then SD 3 is broken; as it appears now this is not a trivial workaround and so it's unlikely that I'm going to bother with this.

[Fox-1 / mnx]

Using the older Ice-T 2.72 on my SpartaDOS 3.3b set-up the old way works perfectly as far as talking the right path. In fact, I'm looking to it right now and ICET.DAT appears in D1:>DATACOM>ICET> with a current time/date stamp as I just saved it to disk.

 

As far as I can see the only thing that needs to be done to be multi-drive compatible on SD 3.x systems is something like:

 

 LDA $0700
 CMP "S" ; Check for SpartaDOS
 BEQ SPARTA
 CMP "R" ; Check for RealDOS
 BNE NOT_RD
 ;
SPARTA
 LDY #33
 LDA ($0A),Y ; If IceT started from "D2:", COMTAB+33 = "D2"
 STA YourFileNameBuffer
 INY
 LDA ($0A),Y
 STA YourFileNameBuffer+1
 ;
NOT_RD

 

(Note: it may be a good idea to walk through COMTAB with 16 bit ADC in stead of INY to prevent issues)

 

 

Could be the problem is more complicated then I think it is and that I'm just overlooking something. As always, feel free to correct me.

 

 

edit: not saying 3.3 "current path" behavior is the best approach but I'm just used to it.

 

edit 2: Maybe needs an extra branch in case SDX is used. Don't know.

Edited May 6, 2012 by Fox-1 / mnx

[itaych]

Suppose Ice-T was started from "D2:>DATACOM>ICET>" would writing to "D2:ICET.CFG" be enough to ensure that the cfg file is in the same directory? Or would I have to specify the complete path? In the latter case your code wouldn't do that, so I'm trying to make sure we're on the same page.