Ice-T XE 2.76 released

[itaych]

when i quit ICE-T, i missing top bar in SDX..

 

Ok, here is alpha 6.

• SDX: At startup, TDLINE is removed only after all initial tests pass.
• SDX 4.4+: TDLINE is restored when quitting if it had been removed by Ice-T.

I'm also happy to announce that with the latest Altirra (2.5 test 10) file transfers work with no problems! Don't forget to set the terminal type (in System > Serial Ports > Negotiate terminal type) to the same type selected in Ice-T (vt102, ansi or vt52, ignore the "dec" options).

 

Enjoy

icet_280_alpha6.xex

[+Stephen]

Excellent - thanks so much for the TDLINE restoration.

[itaych]

One of the things that's been bothering me is that when communicating with a remote Internet host we are at the mercy of whomever wrote the communications layer between the Atari and the Internet connection. In the case of Altirra there is an excellent Telnet client, thanks to my persistence and Phaeron's responsiveness and willingness to get it right, so we were lucky there. In the case of APE however the Telnet implementation is not perfect, and I doubt I can convince the author to mess with it. And neither of them offer SSH, which is the current standard for remote access while Telnet is losing support due to its security flaws.

 

In looking for a solution I came across an application named Plink, which is a component of the PuTTY suite. PuTTY is a terminal emulator for modern machines that includes an excellent Telnet/SSH/Rlogin implementation. It is also under constant development, and so is a good foundation to rely on. So, what is Plink? Plink is a subset of PuTTY, which opens the connection and takes care of all negotiations, security and binary transparency but does not do any terminal emulation - it's a simple stdin/out console application, useless on its own but just what we need. However there is a missing link needed to connect the Atari's terminal emulation to Plink's stdin/out.

 

I have implemented a simple proxy application named tcp2con that runs Plink as a slave process, receives a TCP connection from an Atari (real, through APE or emulated by Altirra) and bridges the two, such that the Atari only needs to emulate the terminal while Plink handles the communications protocol.

 

I've attached the source code (for Visual Studio 2010) and x86 executable. Here's how to use it. Perform these steps on the same machine on which APE or Altirra is running:

1. Download Plink.exe and Putty.exe from the Putty download page (google it).
2. Open putty and change the default Terminal type string to vt100 (or vt102, ansi, vt52). The default setting "xterm" will cause Linux hosts to send control codes Ice-T does not recognize. Connection > Data > Terminal-type, fill in "vt100" then Session, click "Default Settings" and Save. Close PuTTY.
3. Put tcp2con.exe (from the attached zip) and plink.exe in the same directory.
4. Open a command window in that directory and type: tcp2con plink.exe parameters , where the parameters are whatever you'd give putty if you were using it directly. For example, "-telnet 10.0.0.1" or "-ssh username@10.0.0.2" or the name of a saved configuration in putty. Make sure the saved configuration has the terminal type set properly (see step 2). With a saved configuration you can even connect the Atari to a real modem attached to your PC's serial port.
5. Load Ice-T (or any other terminal program) on the Atari.
6. Disable the Telnet protocol on the Atari side. APE: use Server mode and type atb2 . Apparently you have to do this before every time you connect. In Altirra disable "Emulate Telnet protocol".
7. Connect: APE users type "atd localhost 9001". In Altirra use "atdi" instead of "atd". If all went well you should now see the login prompt of the destination machine specified in the tcp2con command line. Note: If using SSH, Plink prompts you for the password. It seems that when typing the password you need to finish with Ctrl-J rather than <return>. I have no simple solution for this.
8. Enjoy!

That should take care of most use cases. The application also has a few command line options:

• -v : print version information and exit.
• -p=port : set listening port number (default 9001).
• -o : once - exit after one session. (normally it will wait for another connection.)
• -a : public access. Allows access from addresses other than localhost. This is a security risk and is not recommended.

Finally, note that you can set tcp2con to use any other console application instead of plink.exe. I can't think of a reason why you'd want to but the option is there. Of course this can also pose a security risk so use with care.

 

Let me know if you find any problems, or have any feature suggestions. Right now there is one known issue: If the slave process (plink) outputs anything to stderr, the message is only shown when the process exits. This causes a few out of place messages to appear when logging out (such as "Using username ..." which should appear in the beginning of the session).

TCP2Con_1.0.zip

[doctorclu]

I was so excited about this new version of Ice-T with color ANSI that I dedicated today to installing the Incogneto on my Atari 800 and set up a drive.

 

Just two hurdles to overcome hopefully and I will be BBSing with my Atari 800 in true ansi color!!

 

Ok it is telling me that the base 48K is not free. I had the Incogneto in Xl/XE mode with 320 RAMBO mode.

Also telling me "SDX Users: Use "X" to launch Ice-T"

 

New to SpartaDos so any help will be appreciated.

[doctorclu]

Got it figured out, just needed to load with x d3:ice*.* and that got it.

[doctorclu]

Itaych,

 

Loving the new Ice-T with ANSI COLOR. The color is still hit or miss, mostly hit, but it is a grand improvement over what we had before (which was nothing or at best shades of blue with Flickerterm)

 

So what makes for a good BBS experience is macros.

 

I was happy to see the dialing menu, and I see that the dialing menu and all configurations save at drive 1.

 

I have a Compact Flash setup that starts with Drive 3. Well it did, but I went ahead and got back in fdisk with my incogneto setup and changed a drive to be drive 1 so that my config file for Ice-T would save there.

 

But ultimately it would be a nice feature to give the user the choice of where the config file will be saved.

 

One request I would like to ask is the ability to send macros. It is helpful when you have the username and passwords ready to send with the hit of a few buttons. Basically Bobterm, and Flickerterm, and Zterm (Mac), and I believe Freeze Dried Term (ST) my favorite term programs over time had a feature to have two, possibly three macros per BBS.

 

(Kudos to Bobterm who actually had macros with joystick controls. Was able to set up north, south, West, east, and Attack for online games.)

[itaych]

Loving the new Ice-T with ANSI COLOR. The color is still hit or miss, mostly hit, but it is a grand improvement over what we had before (which was nothing or at best shades of blue with Flickerterm)

Thanks. The color implementation still has a few deficiencies as far as I'm concerned, which is why the latest releases have all been alphas. I hope to get to fixing it up soon and make a proper release.

 

But ultimately it would be a nice feature to give the user the choice of where the config file will be saved.

Good idea, but how would the application know, at startup, where the config file is located so it could load it? Bet you didn't think of that

 

Anyway, Ice-T loads the configuration file from the "current" directory. So if your config and executable are located in different places, change your current location to the path of the config file then load the executable with its full path.

 

One request I would like to ask is the ability to send macros.

I know macros would be useful but I never quite figured out how to implement them without it turning into a complex project. I also didn't want to make a crappy implementation that would look like a hack. And since it wasn't very important to me as a user it kinda fell to low priority. A good starting point would be if you could tell me what kind of GUI you'd expect for creating and editing macros, what keyboard combinations would activate them, etc. (read the manual - almost every keyboard combination is already assigned to something). I'm not promising anything at all but I need input if I'm going to consider this.

[flashjazzcat]

Macros are cool, of course. If you don't want to code up an editor, just make them plain text files.

 

As for config file locations - I take it the user is running a hierarchical filing system. If it's SDX, get the application to read the config file from the DOS PATH, or observe some (optional) environment variable containing the absolute path to the config file. It's appreciably different with other (lesser) DOSes, but there's always a way. I think we chatted about a few of the approaches LW uses a year or so back.

[itaych]

Macros are cool, of course. If you don't want to code up an editor, just make them plain text files.

Writing assembly code that parses a formatted text file scores points for being both a user-unfriendly hack *and* a complex project.

 

If it's SDX, get the application to read the config file from the DOS PATH, or observe some (optional) environment variable containing the absolute path to the config file.

Again, this is assembly code. C++ or Python make this sort of stuff easy, but we don't have that. What is wrong with the current method? All the user has to do is point the current directory to the path of the config file, it can easily be done manually or with a batch file. (It was annoying enough getting *that* to work under SDX..)

[flashjazzcat]

Writing assembly code that parses a formatted text file scores points for being both a user-unfriendly hack *and* a complex project.

Where did you read the bit about it being a hack? It's a damned sight easier than writing an editor (especially when you don't have a GUI to hand), and personally I'm all for plain text files rather than uneditable binary blobs. This is why I changed all the config files in The Last Word from binary to plain text. I'm sure upset and shocked to discover how much of a user-unfriendly hack that is.

 

As for complexity: it surely depends on what you consider complex. All you're looking for is an identifier (say - an ATASCII code), followed by an equate symbol, followed by the macro text. That's not really a complex project.

 

Again, this is assembly code. C++ or Python make this sort of stuff easy, but we don't have that. What is wrong with the current method? All the user has to do is point the current directory to the path of the config file, it can easily be done manually or with a batch file. (It was annoying enough getting *that* to work under SDX..)

Well, you'd have to delve into the SDX programming manual, I guess. C++ is not an absolute requirement for reading the SDX environment with a few dozen bytes of code. But there's absolutely nothing wrong with the current method at all. It has the advantage of being reasonably generic, easy to understand (from the user's point of view), and simple to implement.

 

Anyway - I won't disagree that it's a pain making uniform functionality work across different DOSes. A few minutes ago, doctorclu's suggestion was deemed "a good idea", but now (following a couple of suggestions on how it might be implemented), it's obviously become an almighty pain in the ass. I'm perfectly happy with the current arrangement, and was merely throwing in ideas. Please ignore them, and don't misinterpret my suggestions as implicit criticisms of something which works just fine as it is. Sheesh.

 

BTW: It was someone else who'd asked me about finding config files a while back.

Edited December 9, 2013 by flashjazzcat

[itaych]

Everything in Ice-T is configurable and editable from within the GUI, it would look bad - in my opinion - if just one certain feature would require externally editing a text file. The user can edit a name and phone number within the Dialing menu today - there already is an editing GUI - so it should be possible to edit macros in there too.

 

The question is, should a macro be able to send just a plain text string? Or does it need to send special codes such as an end of line, control character or special sequence (such as the arrow keys, which send three bytes each - bytes that are different depending on the terminal's keyboard mode!). Enabling things like that would make editing a lot more complex, while not enabling them would make the macro functionality somewhat limited. So I am interested to know what the needs are, what sort of thing would people use macros for. How would you as a user expect to input a macro that contained special codes. That sort of thing. I have seen Microsoft Word, its macro feature is a complete programming language with its own IDE - it's probably more complex than everything else in Word combined! So I guess I want to know where to draw the line

 

About that last bit you wrote: I'm not upset, and no criticism taken, I know you're sharing your knowledge and offering ideas and I appreciate it. I'm just explaining why I don't want to invest what I think would be a disproportionately high amount of time and energy in the load config feature when I (and you too, it seems) think it's just fine as it is.

[doctorclu]

Itay and FlashJazzcat, I was surprised to see such a buzz on the suggestion!

 

Ok, here is what I have in mind:

 

Add some entries to the Dialing Directory since that GUI is already in place. Right now it asks for BBS name, and number, just add lines for Macros 0-9.

 

When you dial a number that macro set is brought into play, and can be activated by hitting START + number. (SELECT and number, you get the idea).

 

Generally you would only need three macros (name, password, last three digits of phone number), but since the other numbers are there, you could have the other seven keys for other things (signatures, hayes AT commands, etc).

 

On the question of plain text or control string, I would say plain text would be fine.

[w1k]

icet- will be most powerful telnet on atari.. but dont exist suport for dragon carts.. :/

maybe works ports 21, 25, 110, 80, etc.. :/

[Marius]

icet- will be most powerful telnet on atari.. but dont exist suport for dragon carts.. :/

maybe works ports 21, 25, 110, 80, etc.. :/

 

It will never be compatible with dragon carts, since dragon carts eats almost all memory and quite some resources from the system. Dragon cart is nice hobby project; it proves that atari 8bit is capable of doing things, but it has not really a serious usuable potential (yet).

 

If you want to standalone telnet grab one of these Lantronix or compatible devices and Atari 850 or compatible.

[itaych]

Generally you would only need three macros (name, password, last three digits of phone number), but since the other numbers are there, you could have the other seven keys for other things (signatures, hayes AT commands, etc).

I'm thinking of just allowing something like 10 macros that are global, always available and not tied to a particular dialing destination. The reason is that (a) 10 macros (or even less) for each dialing entry would take a lot of RAM, (b) most of the macros you mention above don't seem to be tied to a certain destination, ( c) things like AT commands aren't particularly useful once you're already online, (d) I want to keep it simple. So this means that editing the macros would be done in the menus, unrelated to the Dialing menu. I think 60 characters are a good length for a macro, and that some support for control characters should be doable. A macro will be sent by pressing a Start+number combination on the keyboard.

 

How does this sound?

Edited December 10, 2013 by itaych

[doctorclu]

Maybe take the Atari 800 version of Ice-T (Still good, used it for years with my Atari 800) and being a low resource version retool that for the Dragon Cart.

 

Then you can have like you used to have in the 80's with the "Express" term program (remember THAT term program? Could only do about 4800 baud unreliably but was great in the day) and just how you had Express 1030, Express 850. Now you can have Ice-T 800, Ice-T Dragon, and the regular Ice-T with all the colors and features.

--------------------------------

So curious, how long has Ice-T had ANSI color?

[doctorclu]

I'm thinking of just allowing something like 10 macros that are global, always available and not tied to a particular dialing destination. The reason is that (a) 10 macros (or even less) for each dialing entry would take a lot of RAM, (b) most of the macros you mention above don't seem to be tied to a certain destination, ( c) things like AT commands aren't particularly useful once you're already online, (d) I want to keep it simple. So this means that editing the macros would be done in the menus, unrelated to the Dialing menu. I think 60 characters are a good length for a macro, and that some support for control characters should be doable. A macro will be sent by pressing a Start+number combination on the keyboard.

 

How does this sound?

 

Universal macros sound good and maybe need a little less directory filing in the config file. Since they are universal, and you like the START + number idea, how about START + any key?

 

This would actually work great as a BBSer. I could assign number 1 and 2 for alternate sign on names, and then hit START + B for the Boot Factory password, or START + D for the Dark Forces password, ect. 0-9 can get confusing on which password is which, but if you had the ability to assign a letter that would make ease for pulling up a password.

 

I hear what you're saying on the macros taking up ram, however when quite a few users now days have 320K, 576K, or even 1088K ram (all those standard with the Incogneto upgrades) what's a little ram usage?

Edited December 10, 2013 by doctorclu

[doctorclu]

(over 24 hours later)

 

 

.... Or if that is too tall an order, I guess 1-0 will work.

[itaych]

If I'm quiet it just means I'm thinking.

 

My plan at present is to allow up to N macros of L length each (probably N=16, L=64), where each macro can be mapped by the user to an alphanumeric character of their choice. However my free time is limited so don't hold your breath. It's on the todo list.

[Kyle22]

Any chance of having a "wait for" type thing, basically, (because of Upper or lower case 'P') waiting for 'assword:' then automatically sending a string? Something like <waitfor>'assword:'<xmit pw$> where pw$ would be a pre-defined string from that particular entry in the dial menu, specific to each BBS. Store them in a file, so as not to use too much RAM. Maybe allow 3 or 4 short (20-40) character strings per dial entry.

 

Just an idea

 

-K

[doctorclu]

If I'm quiet it just means I'm thinking.

 

My plan at present is to allow up to N macros of L length each (probably N=16, L=64), where each macro can be mapped by the user to an alphanumeric character of their choice. However my free time is limited so don't hold your breath. It's on the todo list.

 

 

Making it where we can assign any character for the macro sounds great. Realize time is limited, but looking forward to that change when it happens in the future.

[itaych]

assword

Hehehehmhmhmhheheheheh.

[doctorclu]

I was trying not to go there.

[itaych]

Why not? It's so fun!

[doctorclu]

Hey curious if you had any luck with this?

 

I was playing with Ice-T with my Incogneto clock battery working right for the first time.. it was neat to see the the built in clock in the program.