itaych

So, can you recommend a replacement disk-based handler that will work around this problem, but still function with a real and emulated 850? I will be happy to add it to the Ice-T distribution. BTW a minor nitpick: On a real Atari, if booting without a disk drive but with an 850, the 850 will respond to the boot request and boot its R: handler before the Atari gives control to the cartridge/BASIC/Self Test ROM. So for example Basic has access to R: without the need to load anything from disk (useful if you only have a tape to load your programs, I guess). This does not occur on Altirra. Perhaps - and this is just a wild guess - if you emulate this behavior correctly, SDX will automatically load the R: from 850 when starting up? It sure makes a lot of weird I/O noises, perhaps it's looking for an 850. But again this is purely speculation.

I don't have an SDX cartridge, and my 850 is long gone, so I can't try this on real hardware. Altirra has recently added full SIO emulation of the 850 however, so I thought I'd have some luck with that. Under MyDOS I could load the 850 R: loader (RS232.COM, distributed on the Ice-T disk as ATARI850.HND), the bleeps were loud and clear and Ice-T loaded just fine. Under SDX however the 850 doesn't respond to the loader at all - no beeps, so no R:. So, I am seeing the same result as you but this is probably not the same problem. If I try a different handler (such as RVERTER) then Ice-T loads just fine, but of course there are no communications. Do other terminal programs work for you in this scenario? Phaeron, can you please take a look at this? It happens when setting R: device to 850 and SIO mode to Full.

Makes sense, Ctrl-Break is a system break and opens the debugger. If you want to press the equivalent of the Atari Break key just press Break.

Not really crazy, this sort of string manipulation (ab)use was a well known technique for fast memory clears and moves, with magazine articles describing how to perform it and type-in games utilizing the technique. Just sayin'

There's nothing particularly difficult with what I want to do, the hard part is finding time. There was a bit of a slump at work which lasted a couple of months, which meant I didn't have much to do and therefore had plenty of mental energy left to do Atari stuff in my free time, which allowed the last several versions. The present and usual case unfortunately is that when I get home the bits of my brain that are busy when I code are worn out and need their rest. Even on weekends it's hard to find time with all the being a dad thing. So I can't promise when I'll get to it, but I will when I can. I'm going to need a LOT more information if I'm ever going to be able to diagnose and fix this. I'd need answers to as many of these questions as you are able to answer: Does this happen more than once? Does it happen often? Is there a pattern? Is this something that will ALWAYS happen after a certain amount of time or activity? Try starting up Ice-T and leave it idle for a few hours, does the bug happen or do you need to be actively using it for a long time? Once it happens, is there any way to snap out of it? Tried things like switching to the menu and back? Use the "Reset Term" option in the menu? Can you hang up with +++ ATH, and if so do you return to normality and can you dial again? Try going to the File menu and viewing the disk directory - that closes and reopens the serial port, does that help? Turn your modem off and on, any luck? If all else fails, press Reset, which reinitializes Ice-T - does that help? Failing that do a coldstart - does that fix it? Was there ever a time when your present configuration did work for many hours without displaying this problem? What changed since then? Can you try connecting to your BBS by Telnetting through Altirra? Does the bug happen there? If so can you save the state and send me the state file? In any case do try with a different interface, or try using another terminal program (like FlickerTerm) for the sake of the test. For all I know this could be your modem acting up or something in the interface driver, or maybe even a problem in your replacement POKEY - since I've never heard of this bug from anyone else. This reminds me of a funny story: one day I was playing a lengthy game of Joust, when suddenly the game halted and returned to the title screen. I was having a pretty good session so, annoyed, I started a new game. A few minutes later, it happens again. Then I notice the game options (difficulty and players) are changing on their own - a few times a minute, then gradually faster and faster. Turns out that GTIA was faulty and was sporadically indicating presses of the console keys. It only happened when the chip warmed up, so my solution of course was an ice cube in a bag placed on the chip which let me keep on gaming until I could have it replaced. My point is that perhaps your POKEY (which controls the serial port) is broken but only shows its problem after a few hours of use. Also that Joust is a great game, but I digress. Anyway, try these things and let me know what you find. Thanks.

Why not? It's so fun!

Hehehehmhmhmhheheheheh.

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.

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?

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.

Writing assembly code that parses a formatted text file scores points for being both a user-unfriendly hack *and* 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..)

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. 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. 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.

Fair enough. This will remain an external helper app for anyone who wishes to use it. I've fixed the hang bug and added command line parameters, so it's a lot more user friendly now. Since it is not Altirra specific but useful for users of APE as well as Altirra, I have moved it to the Ice-T thread. The relevant post is here.

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: Download Plink.exe and Putty.exe from the Putty download page (google it). 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. Put tcp2con.exe (from the attached zip) and plink.exe in the same directory. 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 [email protected]" 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. Load Ice-T (or any other terminal program) on the Atari. 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". 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. 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

I understand your worries, but note that Plink was designed expressly for this purpose (Xming uses it with no problems). However, as Stallman famously quotes Hillel, "If I am not for myself, who will be for me?" I have implemented a bare bones proxy application named tcp2con that does what I described. The source is attached. It runs Plink locally with given command options, and allows an external program to connect to it via TCP, linking the TCP socket to the program's stdio. With this, one can SSH from Ice-T under Altirra. (This can also work for a real Atari and APE, though I haven't tried that.) The application is buggy (see below) and is not user friendly (arguments are hard coded!) so is recommended only to programmers at this point. Here are the steps to use it: Download Plink.exe and Putty.exe from the Putty download page (google it). Modify the COMMAND_LINE in the attached source file to correspond to the location of plink.exe and your desired command line. For example: "c:\plink.exe -ssh [email protected]". Also change the listening port from 9001 if you like. Build under Visual C++ (I used 2010 but this should work with others too) and run the program. In PuTTY change the default Terminal type string to vt100. The default setting "xterm" will cause Linux 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. In Altirra disable "Emulate Telnet protocol". This is only needed because Altirra still sends CR NUL even when no Telnet negotiation takes place - this will hopefully be fixed soon. (Also note that in any case the "terminal type" option has no effect here.) Load Ice-T or any other terminal program in Altirra and type: atdi localhost 9001 <return>. If all went well you should now see the login prompt of the destination machine specified in the COMMAND_LINE above. Plink has two modes of operation. I have no idea why it decides to use one or the other. In one it requests the SSH password in a dialog box that pops up. In the other the request will be inline (in the terminal window). If the latter happens to you, note that you need to hit Ctrl-J instead of <return> after typing your password. Enjoy! You're SSHing from an Atari! However, when the session ends tcp2con will not clean-up properly and will hang (this is the aforementioned bug). You will need to kill and restart it if you wish to use it again. I'd be happy if anyone with more Windows programming experience can help with the cleanup process. Basically there are two slave threads, one for each direction (tcp to process, process to tcp). The main thread waits for either thread to quit, then closes the socket and kills the process (if it's still up) and waits for the other slave thread to quit as a result. The first thread will quit if there is a TCP error (Altirra hangs up), but the second thread is supposed to quit when the Plink process quits or is terminated - I was expecting an error to be returned from the ReadFile call at line 220 - but it doesn't, and the main thread is waiting forever for that thread to end. Phaeron: Once this bug is taken care of I think you can safely integrate this feature in Altirra. The code is straightforward, is only slightly modified from MSDN examples and seems to work well. tcp2con.cpp.txt

Thanks - the update works. The reason I was trying this at all was to access the Windows command prompt in Ice-T and execute Plink from within, thus being able to SSH with Ice-T as the terminal. It worked, but not very well (weird EOL conversions, misplaced echoes, text not being sent until I press Return...). I then made a similar attempt with Netcat, which seemed to break things similarly. I'll keep trying and post if I have any luck finding some combination that works

Hi, me again. While playing around with the Telnet client today I ran into another problem with it. It's probably yet another weird edge case - basically I telnetted to the Telnet Server service running on my own Windows machine, it used to work but now the NUL characters break it completely. Again it seems that PuTTY is the golden standard and has no such problem, but instead of investigating the issue I had another idea. The PuTTY suite (which is open source) includes a utility called Plink. What it does is open a connection for you - be it Telnet, Raw, Rlogin, SSH, or even to the computer's serial port - takes care of all translations for you and all you need to do is send and receive bytes via stdin and stdout. Let's suppose Altirra accepted a new command, say, ATDP args. The args will be sent as is to the Plink command line (like ATDP -ssh [email protected]). Once Plink is launched you output CONNECT 9600 and then connect the Atari's virtual serial port to the Plink process's standard i/o. You do need to monitor for '+++' but otherwise Altirra is just a transparent pipe; and when Plink quits output a NO CARRIER. I think that's pretty much it (you don't even have to do the Telnet negotiation, it's all taken care of) - that's all you have to do to get not only a perfect Telnet client but also SSH and others I noted above and most importantly this seems like a future-proof solution: when Telnet has gone the way of the dodo you're not going to be pestered by people like myself who are still playing with their Ataris and will want SSH and Plink will surely support additional future standards too. If Plink needs a password or wants to report a connection error it pops up its own dialog so you needn't worry about error messages (e.g. "NO ANSWER") or password dialogs. This idea is intended to augment, not replace the existing Telnet functionality - no need to require that the user download a separate utility to communicate - but let him have the option should he desire it. Pretty please? Sugar on top?

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

Indeed. This is a bug in SpartaDOS and there's nothing Ice-T can do to fix it short of actually repairing the display list, an unreasonable task for a user program. Adding a delay doesn't help. Sorry, but the garbage stays.

I'm not changing any file that is still open. Load a file, reboot, replace the file, load file. Anyway the bug seems fixed so I guess the issue is closed. Thanks! Did you notice my comments regarding Telnet in my previous post? I edited them in after posting so you may have missed them.

No way. The method by which I turn TD off is described here and uses the SDX vectors. If there's anything else I should do beyond that to prevent the garbage, let me know. (Perhaps wait a vblank?)

If you can think of a simple way to fix the screen garbage issue I'd be happy to fix it.

The telnet is awesome, you nailed it I do think however that if the user requests "None" in the terminal type then it should behave as before, i.e. refuse to negotiate. The result should be that in Linux echo $TERM returns "network" (now it returns a blank string). The "dec-vt*" options should probably be moved to the bottom of the list as Linux doesn't accept them (try running Emacs). Regarding the virtual disk behavior, I retried the same sequence I described previously. Now Altirra doesn't crash but still at some point when loading the file after it is modified, it seems to act as if the file just contains zero bytes. (Ice-T has a multi-stage loader. After one of the intermediate stages runs and returns, the rest of the file has zeroes.) This causes Ice-T to load in a broken state. I did see this bug before but thought it and the crash were the same bug. Once the file seemed corrupted (only to the Atari of course, it was perfectly intact on the PC) I copied it to a Sparta format ATR. That ATR is attached here (rename .zip to .7z) because I found no simple way to transfer the file back to the PC for analysis. The file should be compared to the 2.8.0 alpha 5 Ice-T executable. BTW there is nothing special with my setup, this is Win 7 32-bit with everything on the local hard drive. temp.7z.zip

In that case the Disk Drives dialog should prevent you from setting them to R/W.

Agreed, I've just tried to reproduce this issue with MyDOS and DOS format with no problems. So I guess the issue lies in SDX virtual disks only. However, writing files to these virtual disks (from the Atari) doesn't seem to work for me, regardless of format.