itaych Posted October 1, 2013 Share Posted October 1, 2013 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 6 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2013 Share Posted October 1, 2013 Ouch... Well done. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 1, 2013 Share Posted October 1, 2013 Congrats on finding the bug. I hate to say though - I really do not like the break key sending a break signal. It is only due to my poor typing skills But the break hey is touching the backspace key on the 130XE and I find myself dropping connections when I go to correct a typo. It doesn't help that my regular PC keyboard has a large backspace key in the same spot. I guess I will just have to start practicing some touch typing on the 130XE some more. Quote Link to comment Share on other sites More sharing options...
itaych Posted October 1, 2013 Author Share Posted October 1, 2013 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 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 1, 2013 Share Posted October 1, 2013 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 Awesome - thanks. I was not asking you to remove the feature, but thanks a bunch for the tip! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2013 Share Posted October 1, 2013 (edited) If it's actually dropping the connection it might have been worth making it optional... Especially if it's a new feature. Edited October 1, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
itaych Posted October 1, 2013 Author Share Posted October 1, 2013 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2013 Share Posted October 1, 2013 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 Heh - Ctrl-Esc is harder to hit by accident. Ctrl-Esc also brings up the Start menu in a Windows emulator, mind, so it's understandable that you moved it. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 2, 2013 Share Posted October 2, 2013 I have found another issue with the VT emulation. If you connect to irc.atarichat.net 800, the chat window will not scroll. Using Flicker Term, it works fine - but the font is unreadable on my setup. Quote Link to comment Share on other sites More sharing options...
itaych Posted October 2, 2013 Author Share Posted October 2, 2013 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? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 2, 2013 Share Posted October 2, 2013 I apologize - it was not a problem with ICE-T. For some reason, APE was identifying itself as an ANSI terminal. I changed that to VT100, and all is good. 1 Quote Link to comment Share on other sites More sharing options...
Lord Cygnus Posted October 4, 2013 Share Posted October 4, 2013 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 Awesome, Itay! I've been using ICE-T 2.72 on my Atari 130XE, PR:Conn, with Lantronix UDS-1100 device with no problems calling up ANSI 80 column boards for the past year or so. However, I installed your recent new version 2.74 and got QQQQQQQQQQQQQQQQQ's constantly across the screen. I will try this latest release 2.75 you just posted and see if that works. Any suggestions? -=[Lord Cygnus]=- SysOp of: YYZ BBS [yyzbbs.no-ip.org:23] 8-Bit Guild BBS [8bitguild.no-ip.org:10001] Quote Link to comment Share on other sites More sharing options...
itaych Posted October 6, 2013 Author Share Posted October 6, 2013 However, I installed your recent new version 2.74 and got QQQQQQQQQQQQQQQQQ's constantly across the screen. I will try this latest release 2.75 you just posted and see if that works. Any suggestions? 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 Quote Link to comment Share on other sites More sharing options...
itaych Posted October 6, 2013 Author Share Posted October 6, 2013 This message appeared on the 2.74 thread, regarding how I don't automatically turn off the TDLINE bar in SpartaDOS X. http://atariki.krap.pl/index.php/TD_Line:_wyłączenie_i_włączenie_z_poziomu_programu 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 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 6, 2013 Share Posted October 6, 2013 While on the subject of SDX, would it be possible to make it so Ice-T could read the clock (any of which work under SDX) and set it upon program launch? Quote Link to comment Share on other sites More sharing options...
itaych Posted October 6, 2013 Author Share Posted October 6, 2013 Probably not. I don't like SDX and it has annoyed me enough. 1 Quote Link to comment Share on other sites More sharing options...
Lord Cygnus Posted October 6, 2013 Share Posted October 6, 2013 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 Yes, Itay! Your handler file 'PRCONN2.HND' resolved the issue between the PR:Conn and ICE-T. This version 2.75 works great on my Atari system. View this YouTube video I made of ICE-T terminal in action: [media=420x315]http://youtu.be/HWqdz3GTZNM[/media] -=[Lord Cygnus]=- Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted October 6, 2013 Share Posted October 6, 2013 Using Flicker Term, it works fine - but the font is unreadable on my setup. The FlickerTerm standard distro includes an alternate 3-pixel-wide font which should be basically identical to the Ice-T font. Heck, it uses standard Atari .FNT files, so customizing its font is trivial. Quote Link to comment Share on other sites More sharing options...
itaych Posted October 7, 2013 Author Share Posted October 7, 2013 Yes, Itay! Your handler file 'PRCONN2.HND' resolved the issue between the PR:Conn and ICE-T. 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. Quote Link to comment Share on other sites More sharing options...
Android8675 Posted October 7, 2013 Share Posted October 7, 2013 Yes, Itay! Your handler file 'PRCONN2.HND' resolved the issue between the PR:Conn and ICE-T. This version 2.75 works great on my Atari system. View this YouTube video I made of ICE-T terminal in action: [media=420x315]http://youtu.be/HWqdz3GTZNM[/media] -=[Lord Cygnus]=- Dude I love your narration, so dry. My workmates are wondering what I was chuckling at, they didn't get it. Itay, gonna try 2.76 beta when I get home tonight. Didn't get your message til I got to work today. I don't know if I can do as good a job as Cygnus, but I may try my hand at doing a little video. Gonna clean my desktop first though, place is a disaster. -A. Quote Link to comment Share on other sites More sharing options...
Lord Cygnus Posted October 7, 2013 Share Posted October 7, 2013 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. My greatest apologies, Itay! Sorry, I guess I'm just a dumb American in pronouncing your name. hehe Yes, you are correct on the 'null modem cable' I stated. The RS232 cable is one that I made. However, I did plug it into a null modem cable into my custom-made RS232 cable out of the PR:Conn like an extension into the Lantronix and it works. Strange, I know. Well, I was using ICE-T vr. 2.74 when I first loaded up 'PRCONN.HND' when I got all the QQQQQQQQQQQQQQQ's. When I loaded up vr. 2.75 using 'PRCONN2.HND', everything worked fine. What is the actual difference between 'PRCONN.HND' and 'PRCONN2.HND'? -=[Lord Cygnus]=- Quote Link to comment Share on other sites More sharing options...
Lord Cygnus Posted October 7, 2013 Share Posted October 7, 2013 (edited) Dude I love your narration, so dry. My workmates are wondering what I was chuckling at, they didn't get it. Itay, gonna try 2.76 beta when I get home tonight. Didn't get your message til I got to work today. I don't know if I can do as good a job as Cygnus, but I may try my hand at doing a little video. Gonna clean my desktop first though, place is a disaster. -A. HAHAHAHAHA! I know, right? I'm just an old skool BBS'er from the 80's, dude! Maybe I should take some editing classes and not sound so elementary I actually made this video for my friend, David Baldwin, in New Zealand to show him the piece-by-piece retro equipment I'm using for telnet BBS'ing. It was intended for demo, but thought I would post the news here of the success. -=[Lord Cygnus]=- Edited October 7, 2013 by Lord Cygnus Quote Link to comment Share on other sites More sharing options...
itaych Posted October 7, 2013 Author Share Posted October 7, 2013 When I loaded up vr. 2.75 using 'PRCONN2.HND', everything worked fine. What is the actual difference between 'PRCONN.HND' and 'PRCONN2.HND'? -=[Lord Cygnus]=- 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. Quote Link to comment Share on other sites More sharing options...
itaych Posted October 8, 2013 Author Share Posted October 8, 2013 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 2 Quote Link to comment Share on other sites More sharing options...
itaych Posted October 8, 2013 Author Share Posted October 8, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.