itaych

I've just compared Ice-T to a PC-based ANSI Telnet client as well as FlickerTerm, and Ice-T looks fine. However, I didn't dig very deep into rdfig.net because at some point it wouldn't let me proceed without giving my home address. If you can point me at a menu or picture that looks broken I'd appreciate it. Ice-T actually has an advantage over FlickerTerm, in that it has a full character set whereas FT is limited to 127 characters, and therefore line-drawing etc. characters are reduced to a subset. Just look at how FT displays the welcome screen (Ice-T screenshot attached, I have no idea how to take a screenshot of FT) to see what I mean. Also, how did you connect Ice-T to the net? I'm running it under Atari800WinPlus 4.0. The emulator listens to incoming connections on port 23, so I wrote a C program that connects to the remote host, connects to the local Atari emulator and bridges them. Unfortunately the emulator's R: device seems to have a bug - the most recent byte received from the network is buffered and only released when the next byte arrives. So, for example when typing a word, the letter that's echoed back to you is the previous one you typed. Oddly enough, this bug only appears in Ice-T and not in FT or other terminal programs. Hmm. If you know of a better way to do this I'd be happy to hear about it. -itay

I don't know the authoritative answer to your question but I'm quite sure that the answer is that this only circulated as a text file and was never published as a book. My main reason for posting is to point out that all the online copies have some text missing in chapter 15, but that this text was actually found (source here and here). The text files read: CHAPTER 15 DISPLAY LISTS [some of this file was lost...] chip also has a memory scan counter. [...] Here is the full version: CHAPTER 15 DISPLAY LISTS The program which runs the ANTIC chip is called the display list. Much like a microprocessor, the ANTIC chip has a program counter, called the display list counter. The display list counter is a 16 bit register. However, the six most significant bits are semi-fixed. These bits can only be changed with a jump instruction. The result of this is that the display list counter cannot cross a 1K memory boundary (i.e. $A3FF to $A400) without using a jump instruction. The ANTIC chip finds the address of the display list in DLISTL [$D402 (54274)] and DLISTH [$D403 (54275)]. SDLSTL [$0230 (560)] and SDLSTH [$0231 (561)] are the shadow registers for DLISTL and DLISTH. The ANTIC chip also has a memory scan counter. [...] -itay

Just out of curiosity, how is FlickerTerm better than Ice-T in terms of ANSI emulation? I've used Ice-T to access ANSI based BBSes back in the day and never noticed problems other than the lack of color. -itay

Indeed, proof that I had WAY too much time on my hands. Actually it was pretty trivial to do this, as double-width means 40 columns, and the Atari has little trouble doing that. It's a very rarely used feature though, which is why most terminal programs don't bother with it. -itay

You don't need to tack anything on, just rename atari850.hnd (included in the distribution) to rs232.com and you're all set. Sorry about the delay in answering, I hope 6 years is better than never In YModem-G, data is streamed without any breaks except those generated by hardware flow control. Ice-T will attempt to write to the file to disk without closing the R: port but simply not reading data, assuming that the R: driver will take care of flow control. With the hardware I was developing and testing with - either an Atari 850 or an SIO2PC cable that behaved like a P:R: Connection cable - this was an illegal operation and would crash the Atari. I only allowed this mode because people on c.s.a.8 told me that there is hardware (MIO and BB, I believe) that does allow writing to disk while the R: port is still open, and does take care of flow control. I'm sorry but there was no way for me to test Y-modem-G on my setup at all, or debug this issue. Sorry if I sounded like a jerk. Indeed, universities have that annoying tendency to close students' accounts when they graduate. I don't seem to remember such an email, sorry about that. This bug probably has something to do with the way Ice-T generates keyclicks. Since Ice-T has 3 different keyclick styles (none, simple, standard), and since some keys are accepted by Ice-T that do not naturally generate a click, the keyclick is defeated when the keys are read from the keyboard, and only after checking the current mode is the keyclick generated (or not, in "none" mode). The method by which the "standard" keyclick is generated is by artificially inserting an arbitrary value into the keyboard buffer, then calling the OS keyboard read routine. I'm pretty sure that arbitrary value is a 'j'. The OS read routine is supposed to clear that buffer, but obviously in some case (no idea which) it does not. Needless to say, this never happened to me on any system or emulator I've tried it on. A workaround to this bug would be to use Simple or no keyclick. I've posted the source code to Ice-T for your debugging pleasure in this thread. If anyone can reproduce and explain the "screamin' J's" bug, I'd be happy to hear it. -itay

From that link: Cool, how did you do that? The bank-selecting code is such a mess, it barely makes sense even if you have the sources -itay

Very well, here's the source. It is intended be built using the ATasm cross-assembler. If you have a Win32 machine the assembler executable is already in there, if not (or you're worried about exes) get the latest from the svn at Sourceforge and build it for your machine. I've successfully run it on a PPC-based Mac as well as my Windows box. Simple instructions: In Windows you should be able to build this by simply unzipping and double clicking on build.bat in the Build directory. The result will be named icet.obj in the bin directory. Mark, the author of ATasm, was kind enough to add a "-mae" command line option, that makes ATasm recognize MAE-style local labels. In MAE, any label starting with a "?" is considered local. Regular (global) labels automatically delimit regions, which is a different behavior from MAC/65. So, if you have a code segment like this: label1 ldx #0 ?lp sta table,x inx bne ?lp label2 jmp ?lp ; error!! label3 ?lp jmp ?lp ; not an error. There are two different "?lp" labels, but note the ambiguous call after label2, which would cause a build error. If this is still unclear, please feel free to dig up MAE's documentation for more details. For all other issues regarding the format of the assembler, seek the documentation for ATasm at http://atari.miribilist.com/atasm/ . Read the various .txt files lying around, they will give some good background information. There is currently no distribution license for this code. Until I can think of something more intelligent, everyone is free to tinker with it as long as your results are given free of charge and not sold. And before anyone asks, indeed, the code is not perfect. There are "cmp #0" (the horror!!) instructions scattered throughout, and the code is not the tightest. I wrote most of this in my early teens, give me a break . I didn't fix anything because I wanted to release code that will generate a binary-identical object file to what I released in 1997. (The original is in there, so you can diff it with your result.) Any further questions, post them here and I will try to answer them the best I can. -itay 20071008IceT_XE_v2.72_AtariAge.zip

Just another thing for you to keep in mind: When displaying video through a PCI/USB capture device, there is usually a small delay incurred by the capture, deinterlace and display process. This is usually not too terrible when watching video, but when playing fast-action games the delay (of perhaps 2-4 frames) can become an issue. Maybe the standalone box really is your best solution, because those (or at least the ones I'm familiar with) have no frame memory and display what they receive immediately to VGA. Another note is that standalone VGA converters output video in the same refresh rate as what they receive. Some monitors may have problems if your Atari is PAL, because 50 Hz is not always supported (CRTs are better at this than LCD). With NTSC you shouldn't have a problem, as 60 Hz is a standard refresh rate for PCs. -itay

Trust me, your surprise is probably nothing compared to my astonishment at seeing people discussing Ice-T over ten years after its last release! And I guess that as long as I can breathe, I can still accept money But to be more serious, the plain answer is that there is no real benefit for registering. I never made a "registered" version of the software (it was hard enough to maintain the mess of the source code under the 8-bit's file managing tools without having two versions to worry about). There are only about 20 registered users, Ice-T was never the money-maker I hoped it would be Anyway, let's wait and see. If we get people breathing new life into this project there might be a point in asking for donations. Or, perhaps it could be sold as a cartridge, depending on whether anyone is interested and can pull it off. -itay

Hmm. How about I release the source code, and let you guys try and fix the bugs? Anyone interested in this? (I can't do any of it myself, the best I can offer is to answer to any questions you might have about the code while debugging.) -itay