itaych

Yes, that's it exactly. Looks to me like a completely broken design decision on behalf of Atari800. Since you're compiling it yourself anyway I think it would be trivial for you to fix this by changing the OK to CONNECT (or anything else as long as it starts with the letter C).

My first theory is that you were already online - manually - when you tried the dialing menu. In that case Ice-T doesn't try to hang up and the BBS you are connected to doesn't know what to do with the ATD command. If this is not the case, and you're sure you were offline (in AT command mode), does this happen *only* with darkforce? Can you post a screenshot of a successful manual connection? It should show the ATD line you type and as much as possible beyond that, so pause the terminal with ctrl-1 before the ATD line scrolls off screen. I can't reproduce this with Altirra and I don't use Atari800.

Your issue is specifically addressed in the manual.

Go to: http://www.horus.com/~hias/atari/#tools-win32 Get the "Atari Tools for Win32" file (named tools-win32-101002.zip). Extract dir2atr.exe to some directory. Within that directory create an empty 'temp' directory. Place the .xex file inside that. Then back up in the parent directory enter the command: dir2atr new.atr temp This will create a disk image 'new.atr' containing all files in the 'temp' directory, in this case the xex file.

Here's another release. I believe I've fixed most of the visual glitches and known bugs I mentioned earlier, so this is supposed to be a little more solid (coloring rules are unchanged). Also, a new feature useful for emulator users: if you're loading this by dragging the .xex file into the emulator window then there is no DOS and therefore no "D:" device - but from this version, if there's an "H:" device present (set up as a mirror of a folder on your hard disk) then it will be used as the default path for the configuration file and file operations - so you can now save your settings without needing to load DOS or use a disk image. A lot of code has been weeded out or optimized so this file is actually a little bit smaller than the previous one. Let me know if this has introduced any problems. icet_280_alpha2.xex

Dude, I would have happily made Ice-T sooner but in 1989 I was 10 years old. I've answered this before when I was asked to do a VBXE version. Ice-T cannot change its graphic rendering engine as one changes their socks. The 80-column Graphics 8 bitmap concept is deeply ingrained into every part of the code. This would require a rewrite of almost everything. The idea seems valid, but let's look at it from the programmer's perspective (i.e. mine). First of all, this would mean keeping track of the color of each individual character. So I'd need a 2KB buffer for this - 2KB which would have to come at the expense of something else because I don't have 2KB lying around. Secondly, this buffer would need to be carefully scrolled around and properly filled and cleared so as to always accurately mirror the situation on the screen - groan. Third, this would also add yet another mess to the spaghetti that is the code today (remember, this is Assembly language). And I don't really like the concept. A terminal is a very simple and deterministic machine; its emulator is supposed to be likewise. Also while theoretically the idea sounds nice, in reality I don't think it will look very good and I don't want to expend a large amount of time and effort to find out. Perhaps some Atari centric BBS's could detect that you're running Ice-T (easy: send a ctrl-E and see if you get "Ice-T" in response) and adjust their coloring scheme accordingly? I could even take this a step further and add a custom control code that will allow applying *any* color from the Atari palette, but again this would need cooperation from the BBS side to be of any use.

Ah, good that you asked. Here are the rules of the game. ANSI supports text colors Black, Red, Green, Yellow, Blue, Magenta, Cyan, White, in two luminosities, normal and bright. Ice-T supports all these except black, which is treated as white (I couldn't think of a way to render black text though I might use inverse text in the future). Here are the additional limitations: Each character on the screen can be colored or uncolored. (White text of normal luminosity is considered uncolored. Anything else is colored.) Coloring a character will also color its adjacent character, as the resolution of the coloring underlay is only 40 columns in width. All colored characters within the same horizontal range out of these five ranges [0-15], [16-31], [32-47], [48-63], [64-79] will be of the same color. If attempting to use two different colors the more recent color will change the others within that range. Vertically there is no limitation, so each text line can have up to 5 different colors. ANSI allows defining the background and foreground colors separately but this is impossible in ANTIC F (Graphics 8 ) mode which Ice-T uses. So for a colored character the foreground and background colors are the same. If different background and foreground colors are specified the foreground color takes priority adn background is ignored. If only a background color is specified it is treated as foreground. There are some things I didn't implement yet - which may cause visual problems like color blocks remaining on the screen when the text has been erased, also the colors might be ugly if the color scheme isn't the default white text on black background. There are also very likely to be visual glitches and bugs as this hasn't been thoroughly tested (colors may be wrong on top line of screen, this is a known issue). But hey, it's color! In 80 columns! I think it's a first on the Atari.

Well. Seeing that this version is more or less stable, time to shake things up a bit. Here is a new version for your testing pleasure. I hope you all enjoy it. Changes are: Changed the versioning scheme by adding a dot between the minor and revision digit, where it had been missing all along (i.e. 2.76 should really have been 2.7.6). So the next minor version will be 8 and the first release shall be 2.8.0. Updated the R-Time 8 code to only read the time from the cartridge once per second, saving CPU time. Moved non essential code from immediate to deferred VBI. This improves stability of disk I/O (I've had cases where file operations would choke for no known reason, this was it). Implemented graphic rendition modes 30-37. It's not yet complete (this is an alpha version) and a little buggy, with some limitations imposed by the hardware but I think the results are worthwhile nonetheless. icet_280_alpha1.xex

Since I haven't received any complaints about the new beta, and as I am quite happy with it so far, it is now out as an official version here.

Ice-T XE is a VT-100/ANSI terminal emulator for the Atari 8-bits. New for 2.76: SpartaDOS: TDLINE is now disabled automatically in nearly all versions (2.x, 3.x, SDX 4.4 and above). Fixed some cases where CPU intensive events such as clearing the screen could cause data loss. VT100: Many improvements to emulation with the goal of conforming to the VT100 specification as closely as possible; now passes all tests in the 'vttest' suite relevant to VT100 emulators. Added Origin mode, LEDs, DECREQTPARM (request terminal parameters) command. Answerback string changed to "Ice-T". Shift-Break now sends longer break signal, as per the VT100 spec. Various misbehaviors, bugs and glitches fixed. Enjoy, -itay Ice-T_XE_2.76.zip

Haha, wrong again When I say "It-tie" think of the word "It" followed by the word "tie" (as in, tie a knot). "It, tie". Although the preferred version would be like saying the name of the letter E followed by the word "tie". I remember early versions of Linux tested the sound card by playing a clip saying "Hello, this is Linus Torvalds, and I pronounce Linux Linux". Maybe I should do that too

Of course I want you to move on to 2.76. I post these new versions because they are (hopefully) better than the older versions and because I want to hear feedback from users before making an official release. Please do get the latest beta and let me know if it works for you and whether you notice any difference, for better or worse. And sorry, no, I've never been much of a BBS user myself. I started with a Unix shell account and later moved on to dial-up Internet.

And another one. I've been busy polishing the emulator even more - at this point each of the tests in 'vttest' including the most obscure will either pass flawlessly or fail due to things that aren't planned to ever be supported in Ice-T (such as terminal types other than VT100, 132 columns, blinking and bold text simultaneously, etc). I've even simulated the keyboard LEDs, though I have no idea what they're useful for There are also some speedups in the code and added robustness against data loss, so this is a version worth getting even if you don't care about the finer details of terminal emulation. Cheers! icet_276_beta3.xex

Ok people. Here's another beta for you. In this version I've greatly improved the VT100 emulation. If anyone here uses Ice-T to login to a Linux shell, there's an application named 'vttest' you can use to stress test an emulator (to install: sudo apt-get install vttest). 2.75 actually failed miserably, but with this new beta version everything passes pretty much perfectly. (Note: if Telnetting with Altirra, before trying clever things like Emacs, don't forget to type: export TERM=vt100 . This is needed because Altirra doesn't negotiate terminal type when connecting.) I've also looked into the reasons why data is getting lost at high baud rates even though Ice-T maintains a rather large input buffer, and I think I've solved the problem. So, any of you who use Ice-T at lower baud rates just because of data loss, please try maximal baud rates with this version (russg, you mentioned this issue). Enjoy icet_276_beta2.xex

PRCONN.HND is similar (or perhaps identical?) to ATARI850.HND. It's a very small executable that contacts the PRC, downloads a handler that is stored on the PRC's internal ROM and installs that as an R: handler. After the PRC was released it was discovered to be incompatible with some misbehaving terminal program popular at the time (HomeTerm) and so a purely disk based handler, with some workaround built in, was released. It is named PRC.SYS on the disk that came with the PRC and named PRCONN2.HND here. You will notice that it's a much larger file than the PRCONN.HND. Since this file is a workaround for some problematic terminal program that does not interest us today, I am considering dropping this file from future Ice-T releases. Please try 2.75 with PRCONN.HND and let me know if it works so I can get rid of PRCONN2.

Very cool, thanks for the video! Just wanted to clear up a couple of things: Your attempt to pronounce my name is gallant but unfortunately incorrect: it's properly pronounced like "eat Thai" or "it tie", not "ee-tae". You're lucky you didn't try my last name The cable connecting your PRC to the Lantronix unit is most likely not a "null modem" cable but a standard RS232 cable. "Null modem" is what you'd use to connect the PRC to the serial port of another computer. The PRCONN2 file has nothing to do with the bugfix. Try the regular PRCONN file, there should be no difference; correct me if I'm wrong.

Probably not. I don't like SDX and it has annoyed me enough.

This message appeared on the 2.74 thread, regarding how I don't automatically turn off the TDLINE bar in SpartaDOS X. Thanks to the code in this article I'm now able to do this in SDX from version 4.4 and up. So now every SpartaDOS version should be covered in this respect, except between versions 4.0 and whatever came just before 4.4. If anyone would like to try it out, here's a beta. Enjoy icet_276_beta1.xex

Well, the changelog for 2.75 (which you quoted right there, in full) specifically mentions that very problem as solved in this version. So my suggestion is that you give it a try and post the results here. Thanks

Thanks. I'm responding in the 2.75 thread.

Works for me under Altirra and real 130XE through APE telnet client - this is obviously something I always check before releasing a version. You're going to have to give me a lot more information. What platform are you on? Exactly at which version (since 2.72) did this stop working for you?

It's not a new feature, but was previously employed with Ctrl-Esc (and still is, if you like). I'm still not changing it

Stephen, I'm not going to change this behavior as the Break key is disruptive in many other situations and you ought to be accustomed to not hitting it inadvertently.. But if you like, open the Ice-T binary in a hex editor, seek the string 'a9 3b 8d fc 02' and change 3b to 34. Now your Break key behaves like backspace. Interestingly it will even repeat if you hold the key down. Have fun

Update: Thanks to Russ this problem is now solved; the new version is available here.

Ice-T XE is a VT-100/ANSI terminal emulator for the Atari 8-bits. New for 2.75: Fixed a major regression from version 2.73 which broke compatibility with the P:R:Connection, MIO, and possibly other interfaces, due to incorrect reset of the BREAK key status. Thanks to Russ Gilbert for reporting and assistance in finding the cause of the bug. VT100: Fixed some visual errors when changing the width of existing text. Title screen: Fixed minor visual glitch if serial port failed to open. It wasn't easy debugging an issue that wouldn't occur on my hardware - I had to send Russ about a dozen different versions until we narrowed down the cause of the bug. In version 2.73 I added support for the BREAK key (to send a Break signal over the serial port). Reading the key is done by an interrupt handler, but a flag named "brkkey" (address $11) is zeroed by the OS and must be set back to its 'normal' value, outside of that handler but before any subsequent I/O operation is performed, otherwise the BREAK status will cause that I/O operation to abort with an error. Now, according to Mapping The Atari any nonzero value is good, so Ice-T stuffed a 1 value in there as part of the keyboard read routine. The trouble is that Mapping is wrong: the correct value for normal status is $FF, as stated by De Re Atari and confirmed by the P:R:Connection R: handler source code (luckily available for all to see in the device's user manual). So basically the PRC and apparently MIO as well were constantly thinking the BREAK key was pressed and reading bytes from the serial port would return with some constant value, causing an endless stream of a single garbage character like 'Q' or '?'. Enjoy, -itay Ice-T_XE_2.75.zip