Ice-T XE 2.74 released

[itaych]

Ice-T XE is a VT-100/ANSI terminal emulator for the Atari 8-bits.

It has taken far too long to incorporate the feedback and requests from the 2.73 release, but here it is: 2.74 in all its glory.

The distribution now includes a quick start guide for those of you who would just like to get this working as quickly as possible on a Windows based emulator. So, if you have Altirra go ahead and give it a try.

Here's what's new:

• Screen dump to disk added (by request) .
• Minor speed improvement in text rendering thanks to Jon Halliday (of The Last Word).
• R-Time 8 cartridge support was buggy, fixed.
• Minor improvement to clock accuracy (when no RT8 present).
• RS232.COM automatic loading is now only attempted under MyDOS.
• SpartaDOS 3.x: Added automatic disable for TDLINE if it is on. (SDX users, sorry but I couldn't get this to work.)
• SpartaDOS 3.x: The configuration file ICET.DAT will now be correctly loaded from the current path. Also Ice-T's current path (Mini-DOS menu) will also point to the correct current path at startup.
• SpartaDOS X: Ice-T must be loaded with the "X" command. A reminder is shown if you did not.
• Mini-DOS menu: Path will now accept any single-letter (or letter and number) device type, so you can access files on things like H:. Also '\' is now allowed as a directory separator.
• File Viewer: Fixed EOL parser, should work with Unix/Windows/ATASCII files.
• VT100 emulator: Minor tweaks to font; Underline now ignored for mode 3 (top half of double height row) text; Fixed a very very old bug discovered at the release of 2.72 (in 1997!) involving scrolling portions of the screen in bold-text mode; Fixed bug that caused double-width/height lines to misbehave when scrolling upwards. Bold text is now enabled by default.

The bold text bug was a particular reason that I had delayed this release. I needed to find the time and patience to rewrite a buggy but particularly tricky piece of code, and I'm happy to say that it seems to work well now. The bug itself was probably noticeable to no one except me, but it was there.

With these fixes the VT100 'torture test' now passes. I've added screenshots of both Ice-T and a real VT100 terminal performing the test for your entertainment . As usual I'll be happy to hear feedback.

 

-itay

Ice-T_XE_2.74.zip

[doctorclu]

You rock Itay!!!

 

Now I finally have a reason install my Incogneto!!

[w1k]

yes, i go tesing thanks

[MEtalGuy66]

Yeah. I have to say.. NICE JOB.

 

and thanks.

Edited September 25, 2013 by MEtalGuy66

[flashjazzcat]

Quality software... Looking forward to trying it. VBXE version would be awesome!

[Android8675]

I love you Itay, seriously...

[Fletch]

Awesome job. So glad that amazing software continues to me made for our little world of computing.

[w1k]

hmm, APE software is useless in year 2012 - 64bit windows, no support etc..

so its unreal start ICE-T on real HW

 

can you try add support for dragon cart?

[russg]

You rock Itay!!!

 

Now I finally have a reason install my Incogneto!!

I couldn't get it working very well, illegible characters on the screen, in altirra nor atari800winplus 4.

So.... I got out my trusty 2400 baud modem, PRC, 256K 800XL, monitor, telephone cord and called a BBS (214-987-2135 in TX).

Very nice. I've never seen 80 columns so clear on an Atari. I have a 14,400 modem, but it didn't work so good.

That modem never did work so good if I remember. I gave my 56k hayes modem to a friend who still uses dialup.

Now, is there a way to dial-up and use telnet? Seems like you have to have an internet connection to use telnet.

Edited September 26, 2013 by russg

[+Stephen]

hmm, APE software is useless in year 2012 - 64bit windows, no support etc..

so its unreal start ICE-T on real HW

 

can you try add support for dragon cart?

Ape is certainly usable - I am running registered 3.0.8 on 64-bit WIndows 7. I log into BBSes almost daily. What issue are you having?

[russg]

I couldn't get it working very well, illegible characters on the screen, in altirra nor atari800winplus 4.

So.... I got out my trusty 2400 baud modem, PRC, 256K 800XL, monitor, telephone cord and called a BBS (214-987-2135 in TX).

Very nice. I've never seen 80 columns so clear on an Atari. I have a 14,400 modem, but it didn't work so good.

That modem never did work so good if I remember. I gave my 56k hayes modem to a friend who still uses dialup.

Now, is there a way to dial-up and use telnet? Seems like you have to have an internet connection to use telnet.

I got ICET850 screen looking fine after I found to disable artifacting.

[BillC]

I couldn't get it working very well, illegible characters on the screen, in altirra nor atari800winplus 4.

So.... I got out my trusty 2400 baud modem, PRC, 256K 800XL, monitor, telephone cord and called a BBS (214-987-2135 in TX).

Very nice. I've never seen 80 columns so clear on an Atari. I have a 14,400 modem, but it didn't work so good.

That modem never did work so good if I remember. I gave my 56k hayes modem to a friend who still uses dialup.

Now, is there a way to dial-up and use telnet? Seems like you have to have an internet connection to use telnet.

I used a 14.4K modem with an 800XL in the early/mid 90s to connect to Compuserve, but I found that I had to restrict the connection to 9600 baud even with the 19200 capabilities of my MIO. The reason was the hardware compression, 9600 decompresses to 19200. When using an 850/PRC you would probably need to restrict the connection to 4800 if the modems hardware compression is turned on.

[Fletch]

A version for the Dragon Ethernet Cart would rock. But I'm enjoying the update nonetheless

[popmilo]

Excellent job Itay!

Works just as it should...

[russg]

I used a 14.4K modem with an 800XL in the early/mid 90s to connect to Compuserve, but I found that I had to restrict the connection to 9600 baud even with the 19200 capabilities of my MIO. The reason was the hardware compression, 9600 decompresses to 19200. When using an 850/PRC you would probably need to restrict the connection to 4800 if the modems hardware compression is turned on.

Ha Ha. Yes there were modem commands that need be done. I got out my modem command book. To init I did:

AT&e1s95=46S0=255s11=60 Which was enable re-train(whatever that was)verbose connect results,255 rings to answer,tone dial duration. I have lots of notes.

put an 8 in s37 (ats37= 8 ) for 4800 baud followed by a ATN0. I have a modern PC serial port plugged into a PCI slot as com3. It is for my APE interface. I couldn't get it

to recognize my 2400 baud modem for PC DOS Procomm terminal software. That may be because I'm using DOS emulation (DOSBOX).

Itay's quick start works well to telnet on Altirra 2.3 emulation. I haven't tried the dial-up to telnet that he also has in his instructions. I have a fax line at my house now.

I'm thinking of cranking up my BBS Express, registered, but that would disable my fax. I could limit it to 9PM to 9AM.

Edited September 26, 2013 by russg

[w1k]

Ape is certainly usable - I am running registered 3.0.8 on 64-bit WIndows 7. I log into BBSes almost daily. What issue are you having?

 

APE 3.0.2.

only usb SIO2PC support (RS232 failed to init).

 

i dont want pay 150$ for this strange software.. 0% support

Edited September 26, 2013 by w1k

[MEtalGuy66]

The dragon cart is an ill concieved waste of time.. As soon as a proper embedded ethernet PBI device comes out, noone is going to bother supporting that thing. ICE-T already requires extended ram to run and pushes the limit of the atari's cpu time and resources. There's no way you're gonna add the necessary code to run that slow-assed TCP stack that the dragon cart requires and still have a useable/useful 80 column term program. (Maybe something could be done with VBXE since the software is not doing the 80 columns, but you are still limited by the relatively large overhead necessary to support the dragon cart)

 

Everyone on here who posesses any degree of technical expertise warned you guys that the dragon cart would have very little practical application, given the scale of the atari's native resources and the fact that the dragon cart is simply based on an ethernet controller which was designed to run on a much larger/faster system and is completely dependant on system-native code for it's application. Modern TCP is not something that was ever intended to run on a 2mhz 8-bit, 64k scale system. Yes, it CAN BE DONE.. But it amounts to little more than a novelty, where practical applications are concerned.

 

You knew what you were buying.. You bought it anyway.. Now you have to live with it's limitations..

[Fletch]

Just said a version for the Dragon cart would be cool. In no way am I expecting one to be produced. I'm in no way disappointed with the Dragon cart. I knew what I was buying and find it just fine.

[itaych]

 

APE 3.0.2.

only usb SIO2PC support (RS232 failed to init).

 

i dont want pay 150$ for this strange software.. 0% support

 

The cable costs $60 and the software costs $40. I assume you already have a cable, so why do you claim it costs $150? Steve has always answered my questions immediately so I don't know where you got that 0% figure either... Also, you really need version 3.0.8 and above to use it as a Telnet gateway for Ice-T, otherwise it will identify to the remote host as a VT-52 and you will get garbage on the screen.

[+Stephen]

 

The cable costs $60 and the software costs $40. I assume you already have a cable, so why do you claim it costs $150? Steve has always answered my questions immediately so I don't know where you got that 0% figure either... Also, you really need version 3.0.8 and above to use it as a Telnet gateway for Ice-T, otherwise it will identify to the remote host as a VT-52 and you will get garbage on the screen.

Yeah - the support for his products has always been very good. Have you posted anything on the AtariMax forums?

[itaych]

I love you Itay, seriously...

Er, I, umm, love you too...

 

Now I finally have a reason install my Incogneto!!

 

Wow, if this works with the Incogneto I'd love to hear about it, it would be so cool to have this running on an 800

 

can you try add support for dragon cart?

I've discussed this with one of the developers. If the Dragoncart's support software can present itself as an R: device and include a Telnet client (basically it should do what Altirra and APE do) then not only Ice-T but any other terminal software should be able to use it. The code can be placed in the RAM under the OS, as Ice-T doesn't use it and as far as I know no other terminal software does either.

 

Quality software... Looking forward to trying it. VBXE version would be awesome!

 

Short answer: no.

 

Long answer: also no, with the reasons being Philosophical, Programmatic and Practical.

 

Philosophically speaking, nobody forced me to write Ice-T. When I started I could just as easily have set the aging Atari aside, scrounged an old PC clone from somewhere, hooked up a modem and used Kermit or Telix to happily do the same things I did online, freeing the spare time from several years of my life for other things. I wrote Ice-T because of the challenge involved in making the Atari with its limited capabilities do something it was not designed to do, where others have tried and failed. As far as I'm concerned once you replace the Atari's display chip with a modern alternative it's not an Atari anymore. It's a new platform, perhaps interesting to some but I may as well spend my time writing an Android app - at least there I have the potential for more than a few dozen users.

 

Programmatically, keep in mind that Ice-T despite its professional look is a big ugly hack written many years ago in assembly by a teenager with a lot of time on his hands (mostly by putting school at the bottom of the priority list) but very little knowledge of software architecture. Which is probably just as well because a similarly featured but properly maintainable and structured application would run slower and probably not fit in 128K - it's bursting at the seams as it is. More to the point, there is no single "display a character" function that I could replace with the VBXE equivalent; virtually all of the code is written around the bitmapped 80-column display, from the VBI that handles the fine scrolling to the menu system to the code that flashes the cursor. Basically we are talking about an almost complete rewrite.

 

Which brings me to the Practical part of my answer: the 80-column display is the most interesting aspect and "killer feature" of Ice-T. It's the reason for Ice-T's existence and is where I spent most of my time and effort. With VBXE it becomes redundant, and once you've gotten rid of it, what's left? The terminal emulation and file transfer code is not rocket science, it's just ugly because it's in assembly. You would probably want to throw it out and reimplement it, preferably in a higher level language like C. Or possibly just port existing C code from another emulator, such as Minicom (an open source terminal emulator for Linux). The reason you would now be able to do this is that without the bitmapped 80 columns you've just freed up about 90% of CPU time and around 50% of memory use, so you can now afford to write much cleaner code at the expense of a little bloat.

 

So in any case, if anyone would like to take Ice-T's code as a foundation for a VBXE based terminal emulator, I'm not going to stop you but don't expect me to do it.

[MEtalGuy66]

 

I've discussed this with one of the developers. If the Dragoncart's support software can present itself as an R: device and include a Telnet client (basically it should do what Altirra and APE do) then not only Ice-T but any other terminal software should be able to use it. The code can be placed in the RAM under the OS, as Ice-T doesn't use it and as far as I know no other terminal software does either.

Hahah! Yeah RIGHT... And since the dragon cart's "software" only manages less than 10cps with a simple "proof of concept" program using the native atari OS screen driver, how many hundreds of characters per second are gonna end up dropped once ICE-T's software 80 column and extensive feature set routines are running at the same time?

 

No offense to anyone.. But I'll BELIEVE THAT SHIT WHEN I SEE IT. .. It's not going to be anything practically useful/useable..

 

Now.. If Lotharek brings out the new accelrator(s) he is talking about recently.. That's a whole different story. The Apple IIgs manages a native TCP stack reasonably well so I dont see why a 16bit atari with ample speed & memory wouldn't be able to.

Edited September 26, 2013 by MEtalGuy66

[flashjazzcat]

Short answer: no.

Long answer: also no, with the reasons being Philosophical, Programmatic and Practical.

 

Philosophically speaking, nobody forced me to write Ice-T. When I started I could just as easily have set the aging Atari aside, scrounged an old PC clone from somewhere, hooked up a modem and used Kermit or Telix to happily do the same things I did online, freeing the spare time from several years of my life for other things. I wrote Ice-T because of the challenge involved in making the Atari with its limited capabilities do something it was not designed to do, where others have tried and failed. As far as I'm concerned once you replace the Atari's display chip with a modern alternative it's not an Atari anymore. It's a new platform, perhaps interesting to some but I may as well spend my time writing an Android app - at least there I have the potential for more than a few dozen users.

 

Programmatically, keep in mind that Ice-T despite its professional look is a big ugly hack written many years ago in assembly by a teenager with a lot of time on his hands (mostly by putting school at the bottom of the priority list) but very little knowledge of software architecture. Which is probably just as well because a similarly featured but properly maintainable and structured application would run slower and probably not fit in 128K - it's bursting at the seams as it is. More to the point, there is no single "display a character" function that I could replace with the VBXE equivalent; virtually all of the code is written around the bitmapped 80-column display, from the VBI that handles the fine scrolling to the menu system to the code that flashes the cursor. Basically we are talking about an almost complete rewrite.

 

Which brings me to the Practical part of my answer: the 80-column display is the most interesting aspect and "killer feature" of Ice-T. It's the reason for Ice-T's existence and is where I spent most of my time and effort. With VBXE it becomes redundant, and once you've gotten rid of it, what's left? The terminal emulation and file transfer code is not rocket science, it's just ugly because it's in assembly. You would probably want to throw it out and reimplement it, preferably in a higher level language like C. Or possibly just port existing C code from another emulator, such as Minicom (an open source terminal emulator for Linux). The reason you would now be able to do this is that without the bitmapped 80 columns you've just freed up about 90% of CPU time and around 50% of memory use, so you can now afford to write much cleaner code at the expense of a little bloat.

 

So in any case, if anyone would like to take Ice-T's code as a foundation for a VBXE based terminal emulator, I'm not going to stop you but don't expect me to do it.

 

I take your point completely. Not having a central "put character" function would make the conversion really difficult (this is why I now take pains to write everything using a centralised character-out routine, so that even if it doesn't support Drac030's S_VBXE driver, it can have some kind of proprietary driver written for it; I had to rewrite 30 per cent of The Last Word in order to add VBXE support). The philosophical and practical objections are also valid (believe me, I've been through a similar thought process, and it's recurring). All I'll say is that VBXE support doesn't detract from the achievement of the "stock" software; I certainly don't feel that adding VBXE support to The Last Word took anything away from the original achievement. In a way, it was an interesting challenge in its own right, and I guess it widened the appeal of the application somewhat. There's also the issue of the dearth of applications for VBXE, but that's a kind of chicken and egg situation, and not really an obligation to be placed on developers - especially if the hardware isn't your cup of tea.

 

So - I still think a full-colour VBXE terminal app would be cool, but I completely, one hundred percent appreciate your reasons for not wanting to take the job on. What you've achieved already - within those right hardware constraints - is more than enough.

Edited September 26, 2013 by flashjazzcat

[danwinslow]

The dragon cart is an ill concieved waste of time.. As soon as a proper embedded ethernet PBI device comes out, noone is going to bother supporting that thing. ICE-T already requires extended ram to run and pushes the limit of the atari's cpu time and resources. There's no way you're gonna add the necessary code to run that slow-assed TCP stack that the dragon cart requires and still have a useable/useful 80 column term program. (Maybe something could be done with VBXE since the software is not doing the 80 columns, but you are still limited by the relatively large overhead necessary to support the dragon cart)

 

Everyone on here who posesses any degree of technical expertise warned you guys that the dragon cart would have very little practical application, given the scale of the atari's native resources and the fact that the dragon cart is simply based on an ethernet controller which was designed to run on a much larger/faster system and is completely dependant on system-native code for it's application. Modern TCP is not something that was ever intended to run on a 2mhz 8-bit, 64k scale system. Yes, it CAN BE DONE.. But it amounts to little more than a novelty, where practical applications are concerned.

 

You knew what you were buying.. You bought it anyway.. Now you have to live with it's limitations..

Metalguy, have you used the dragon cart and the new IP65 based stack? There's a telnet program for it that works great. The stack is about 10k and there are zero problems with speed. I don't know why you have always been so dismissive and spiteful about the dragoncart without even having had any experience ( that I know of ) with one. And by the way, I have PLENTY of technical expertise, I've been a professional programmer for 30 years across all kinds of systems.

 

The dragoncart works well, and its perfectly possible to write atari programs for. I again refer you to the telnet program. The dragoncart also works fine under Contiki. Would it work with ICE-t? I don't know, but unless ICE-t is really doing something unusual I think there's a reasonable chance that a properly written driver would work.

 

Why are you being so hostile about it anyway? You seem to take it personally, and I don't understand why.

Edited September 26, 2013 by danwinslow

[danwinslow]

Hahah! Yeah RIGHT... And since the dragon cart's "software" only manages less than 10cps with a simple "proof of concept" program using the native atari OS screen driver, how many hundreds of characters per second are gonna end up dropped once ICE-T's software 80 column and extensive feature set routines are running at the same time?

 

No offense to anyone.. But I'll BELIEVE THAT SHIT WHEN I SEE IT. .. It's not going to be anything practically useful/useable..

 

Now.. If Lotharek brings out the new accelrator(s) he is talking about recently.. That's a whole different story. The Apple IIgs manages a native TCP stack reasonably well so I dont see why a 16bit atari with ample speed & memory wouldn't be able to.

What software are you talking about that manages only 10 cps? Contiki?

 

Metalguy, I would be glad to send you a cart, and you can try the IP65 stack for yourself and see what you think.

Edited September 26, 2013 by danwinslow