itaych

There's a problem with the Disk Drives > Mount folder as virtual SpartaDOS disk (maybe DOS too) feature. Once a file is loaded by the Atari, if the file is changed by the host system and the Atari tries to load it again, things go berzerk: either the Atari will read garbage from the file or Altirra will crash. Here is a step by step of what I did: Drag the SpartaDOS cartridge image SDX445_sdx128.car to Altirra. This boots SDX. (Let me know if you need this file.) Mount drive 1 as a SpartaDOS virtual disk pointing to a directory containing one file named ICET.XEX (version 2.8.0 alpha 5, see the Ice-T 2.76 thread). Load the file: X ICET.XEX and wait for Ice-T to load. Coldstart the Atari, you're back to SDX. In Windows, replace ICET.XEX with a different version (alpha 4 from the same thread). Load the file: X ICET.XEX. Altirra crashes - the minidump is attached (remove .txt from file name). AltirraCrash.mdmp.txt

Thanks Kyle, that did the trick. Here is alpha 5. SpartaDOS 4.x: Time sync with OS clock. Notes: (1) If an RTime8 is detected then the OS time is ignored. (2) Time is only read from the OS at startup. Ice-T is pretty good at keeping accurate time from that point on, but it will gradually lose sync with whatever hardware clock you have, perhaps by one or two seconds a day. Does anyone keep Ice-T running for that long? View file: minor bugfix. icet_280_alpha5.xex

How many times are you going to repeat this request without giving me any information on how this is supposed to be done?

Screen dump to disk = Ctrl+Shift+D. The doc is included in the release .zip, so you can view it with notepad++ on your PC. It is also included within the ATR. The ATR includes a file viewer named COL80 which can view it. Finally, Ice-T itself includes an internal file viewer that is capable of displaying the manual text file. The file has lines terminated with an ASCII LF rather than ATASCII so it can't be viewed with other viewers on the Atari. But, it's formatted for 80 columns so there wouldn't be much point anyway. I might change it so the version on the ATR is in ATASCII in the next release.

2.8.0 alpha4 is here. With this release emphasis has been placed on file transfer and management. Here's what's new, in no particular order: X/Y/Y-G/Zmodem downloads: fixed various bugs and cases of incorrect behavior. See notes below. New feature: Xmodem upload. Only 128-byte packets are supported. Note the setting of Mini-DOS>U/L EOL Trans. as this will affect transferred files. See notes below. New feature: VT-parse file. This loads a local file from disk and dumps its contents to the Terminal, as if they had been received from the remote side. This is useful mostly as a way to view clever VT100 animations, such as the ones available here (check out twilight.vt, it's pretty cool). Note: Set Settings>End of Line to "LF alone" before viewing these files, and change it back to CR+LF before resuming regular work. During animation playback, press Start to freeze, Select to slow down (approximating a 9600 baud connection), and Option to slow way down (one vertical blanking delay per character), or any keyboard key to quit. ASCII upload, file viewer, capture buffer: bug fixes and code cleanups. Xon/Xoff flow control could cause visual glitches or crashes if it became active while Ice-T was in menu mode. This bug, known since 1997 is now fixed. Terminal emulation: some fixes to behavior of double-width lines in fairly obscure cases. Some notes regarding file transfers: As far as I can see at this point, Ymodem-G cannot work on a real Atari. An appropriate warning is shown before you try. It does work under Altirra however and perhaps might some day be made to work on real hardware too, so I am leaving the feature in. Zmodem normally requires the receiver to save to disk while data is still being received, a capability which the Atari lacks. The protocol includes an ability for the receiving end to specify a buffer size to the sender, and the sender is supposed to stop after sending that amount of data to allow the receiver to save data to disk. Unfortunately most current implementations, including Linux 'sz' fail to support this (I have actually spoken to its author, he acknowledged the problem but doesn't seem very eager to fix it) leading to a "Buffer overflow" warning message followed by a possibly long recovery delay. I'm afraid there is little I can do about this except recommend that you switch to Ymodem. Xmodem upload, as with download, pads the transferred file with up to 127 bytes of 0x1A. This is an inherent side effect of the protocol (which dates to 1977) and cannot be fixed. If you are using a Telnet connection under Altirra please upgrade to the very latest version (look for the latest 2.5 prerelease in this thread). At this point downloads work well but uploads will not work in some cases. I am working with phaeron on solving this. The situation is similar with APE but I think I will only approach its author after Altirra is working. This issue does not affect usage with dialup modems. Enjoy! icet_280_alpha4.xex

Does anybody ever read the fine manual these days?

On a similar note I've recently been discussing the Linux X/Y/Zmodem implementation with its author, Uwe Ohse, asking him why in a couple of places the Zmodem sender sz (which imitates Chuck Forsberg's original) does things not according to the document standard, breaking Ice-T's receiver. He had a few choice words on the subject, which I believe should be a guiding light to inspire us all in these difficult situations: "I do not think the specification is worth anything. Regards, Uwe"

Hey. I've been at work the last few days taking advantage of the fixed Telnet, and implemented Xmodem upload in Ice-T. Unfortunately, while it works for direct (non-Telnet) connections it fails over Telnet when transmitting a file containing a CR LF sequence. When comparing a Wireshark analysis of Ice-T+Altirra to a working case (Tera Term in Telnet mode), it seems that the correct behavior for outgoing data is to add a NUL after every CR, regardless of whether it is followed by a LF. This is also shown when running vttest (you may need to 'sudo apt-get install vttest'): select option 6 (terminal reports) then option 2 (Linefeed/Newline test). PuTTY seems to be the only Telnet client that gets it right: only when sending CR NUL LF does the host receive CR LF properly. As we agreed before, this behavior should only be enabled following a successful Telnet negotiation, so there's no worry about breaking a non-Telnet host. And just to clarify, I'm only talking about the outbound direction here, the inbound character handling seems to be perfect at this point. I will email you an updated Ice-T later today so you can test the Xmodem for yourself, though I'm fairly certain that if you can get vttest to pass then the problem will be solved. Thanks for being so patient with this..

Renaming a file now never returns an error. Trying to rename a file that doesn't exist does nothing, yet returns success. Renaming a locked file succeeds when it should fail. R: still waiting for terminal type negotiation. Hope you haven't forgotten that one Other than that everything looks great!

Excellent! This is rock solid as far as I can see. I have a few other notes. It'll probably take you a few minutes to fix these: The Hayes compatible modems were never case sensitive in their command set. I think 'atdi' should work just like 'ATDI', just as my modem never had a problem with 'atdt'. Make port 23 the default if not specified in the ATDI command. This is primarily intended as a Telnet client so why not? H: device: IO Commands 33/35/36 (delete/lock/unlock file) all work well but do not return an error if they fail (e.g. trying to act on a nonexistent file, delete a locked file, etc). H: device: IO command 32 (rename file) works well but always returns an error code 146 regardless of success or failure. Thank you once again!

When Telnet protocol is disabled ("Emulate Telnet protocol" is unchecked), please do not perform outgoing translation, i.e. do not convert FF to FF FF or CR to CR NUL. Leave them as is. Thanks

The incoming end seems to be handled well now, and the OOB issue is taken care of. Great! However the outgoing is now broken: With the new version I can't type more than one consecutive Return! The second and all subsequent Returns look like they just send a NUL and no CR. If you are worried that some hosts will break on receiving a CR NUL, what you could do is default to sending regular CR, but if the remote host performs a Telnet negotiation (the FF xx commands at the beginning of a session) then you can switch to CR NUL mode (as I described), knowing that this is no SMTP or whatever. Any server that can perform a Telnet negotiation should be able to require or at least quietly ignore these NULs.

Wow, this is weird stuff. Now that I look at it, the Wireshark analysis says that the FF is sent in a "Malformed Packet"! It also happens that way when connecting with Tera Term, but not with the command line Microsoft Telnet, though I can't see anything in its negotiation that would tell the remote side to disable the OOB feature. Anyway it sounds like you've found a solution, let's hope it works. As far as I can tell, it seems that you agree with my idea for handling the incoming data, and are considering options for the outgoing direction. In my previous post I told you how I think it should be handled, it is different from the two options you described and there is no buffering or delaying required, plus a CR LF would not get a NUL stuffed in between. The downside is that if a NUL must be transmitted after a CR, it wouldn't be sent immediately but only when the Atari decides to send the next byte, which may be a significant amount of time later. However I don't think this should be a problem; today when the user presses Return just a CR is sent, and if the remote were waiting for the subsequent NUL we'd all notice it because your session would hang. So what I think is happening is that the remote side is not waiting for the NUL but is able to ignore it if received. If this is correct then my solution would work because in normal operation a NUL would be sent by the Atari after the user presses the next key after Return - that would be ignored by the remote. Binary transfers would be fixed because if the Atari ever needs to send a CR NUL in the context of a binary upload it would be correctly converted to a CR NUL NUL. I've done this experiment: From Altirra, connected to a Linux host over Telnet, type "cat" <return>, then Ctrl-space (which sends NUL) twice. The first one is not echoed, because the Linux Telnet server was waiting for a NUL after the CR. The second one is echoed as ^@. When trying the same with Tera Term the first Ctrl-space is echoed, because Tera Term sent a NUL after the CR. This is strongly in favor of my proposed solution. Of course this is all moot when connecting to a non-Telnet destination; isn't that exactly what the "Emulate Telnet protocol" option is for? When that option is disabled there should be no conversion of anything. Which, BTW, wasn't the case last time I checked - transmitted FF bytes (from the Atari) would be swallowed by Altirra - have you addressed this? Thanks

Another issue is the handling of the 0D (CR) character in Telnet mode. According to the RFC (854, page 10) if a CR alone is transmitted (and not as part of a CR LF sequence) it should be converted to CR NUL. This applies to both directions. This means that: In the inbound direction, when receiving an 0d pass it to the Atari but also raise a flag; for the next byte received, if it's 00 then suppress it and do not pass it to the Atari. Drop the flag. (but if the byte is 0D raise the flag again, of course.) In the outbound direction, if a 0D is sent by the Atari, send it out, but raise a flag. Upon the next byte sent from the Atari, if it's a 0A send it as is; if it's anything else, send a 00 and then that byte. Drop the flag. (but if the byte is 0D raise the flag again.) The problem with the present state is that the Atari receives NUL bytes which are supposed to be ignored at the Telnet level. Sorry to be so pedantic, my desire is to have Ice-T be able to do binary file transfers.

In Ice-T braces are Ctrl-9 and Ctrl-0. To test the new version I hit Ctrl-C when in a Ubuntu Linux telnet shell. Doing this causes the host to respond with FF F2 over the network, and then the expected ^ C characters and then the command prompt. The FF F2 is supposed to cause no effect, but Ice-T receives the F2. The F2, as any other value received here (except FF), should be ignored and not passed to the Atari.

Is anyone still maintaining MyDOS and able to fix this?

Thanks for the fix. It seems that +++ would indeed work, but nothing else worked - that is, the communications line became unresponsive and would not transmit data. I checked and the problem is not fixed, and indeed according to the changelog you only fixed it for outbound data. What about the inbound direction? It needs to be handled in the same way, i.e. ignore anything after an FF except for another FF (in which case Atari gets a single FF). Cheers

I have a few bug reports.. H: handler (1): When opening a file in append mode (aux1=9) if the file doesn't exist a File Not Found error (170) is returned; the correct behavior is that a blank file should be created and no error is returned. H: handler (2): In MyDOS, attempting to copy a file from H: to an emulated D: drive fails with Error 165. There is no problem accessing the file, I can even drop to BASIC and write a program that will copy the same file, but MyDOS won't do it. R: handler: The R: device completely dies if you make an outbound connection then cold-start while still connected. The only workaround I've found is to quit and reopen Altirra. There are also a couple of requests I made in the 2.3 thread, which I'm not sure if you've seen. I am quoting that message below. Thank you once again for an incredible emulator!

(Edit: I've already given theses items away. Please do not respond.) A friend has recently gone through his storage and given me the following items: Stock Atari 800XL computer: PAL, working, missing back extension port cover, keyboard has dual-language stickers stuck on the keys and the unit needs a little cleaning. Atari 1050 disk drive: I put a disk in, it whined and creaked but it read with no problems. Needs some maintenance, but this is a working unit. There are EU compatible power supplies for both if you want them (personally I power my Atari with a cellphone charger ) and a data cable for the disk drive. No box, no manuals. Shipping from my country (Israel) to most of the world will cost approximately US$20 (surface) to $40 (airmail). The power supplies will probably not have a major effect on the shipping price. Anyone interested? Reply here or PM me, best offer wins.

I ended up asking a beta tester (russg) to test it. It improved his data rate but did not help with Ymodem-G. Thanks for pointing this out.

Hi Phaeron, Thanks for fixing the P: handler. I have a couple of requests regarding the R: emulation. These are basically issues I'm running into while working on Ice-T. If "Emulate Telnet protocol" is disabled, I expect the R: device to be able to send and receive any data transparently. However this is not the case: while the emulated Atari can receive any byte, it cannot send out a 0xFF. As for the Telnet emulation, I wish it could be improved a bit. First, it doesn't identify as a terminal type (there ought to be a drop-down like in APE with the options "Do not identify", "VT-52", "VT-100", "VT-102", "ANSI"). As a result of this, when Telnetting to a Linux shell various programs refuse to run (such as Emacs) unless you set the terminal type manually (e.g. export TERM=vt102). See below for a reference on how this negotiation looks like. Another problem with the Telnet emulation is that it doesn't handle escape sequences properly; for example if the host sends the sequence FF FF the Atari is supposed to receive just an FF, and if the second byte is anything else then it should be interpreted as a command (which can probably safely be ignored, but the Atari isn't supposed to receive anything). Also apparently if the Atari sends a FF it should be translated to FF FF. As a result of this problem, occasional garbage characters are received and file transfers such as Xmodem (which require 8-bit transparency) fail. I've tried other Telnet clients such as Tera Term and had no problems so this is definitely solvable at the Telnet level. Here is a dump (with some commentary) of Altirra's and APE's initial Telnet negotiation with a Ubuntu host, where Altirra refuses to identify and APE identifies as VT100. Telnet Negotiation on Altirra: Ubuntu: ff fd 18 ff fd 20 ff fd 23 ff fd 27 Start use: term type, term speed, X location, env.option Altirra: ff fc 18 ff fc 20 ff fc 23 ff fc 27 Won't use any of the above Ubuntu: ff fb 03 ff fd 01 ff fd 1f ff fb 05 ff fd 21 Will use Supress GA, Start use Echo, 1f. Will use 05, Start use 21. Altirra: ff fd 03 ff fc 01 ff fc 1f ff fe 05 ff fc 21 Start use Supress GA, Won't use Echo, 1f. Stop use 05. Won't use 21. Ubuntu: ff fb 01 Will use Echo. Altirra: ff fd 01 Start use Echo. Telnet Negotiation on APE: Ubuntu: ff fd 18 ff fd 20 ff fd 23 ff fd 27 Start use: term type, term speed, X location, env.option APE: ff fb 18 ff fc 20 ff fc 23 ff fc 27 Will use term type. Won't use any of the others. Ubuntu: ff fa 18 01 ff f0 Subnegotiate Term type, 1, end subnegotiation APE: ff fa 18 00 56 54 31 30 30 ff f0 Subnegotiate Term type, 0, "VT100", end subnegotiation Ubuntu: ff fb 03 ff fd 01 ff fd 1f ff fb 05 ff fd 21 Will use Supress GA, Start use Echo, 1f. Will use 05, Start use 21. APE: ff fd 03 ff fc 1f ff fe 05 ff fc 21 Start use Supress GA, Won't use 1f, Stop use 05, Won't use 21 Ubuntu: ff fb 01 Will use Echo. APE: ff fd 01 Start use Echo. Thank you!

This doesn't do me much good as I own neither of these boards. I'm not going to bother my beta testers with this either. In that case there is nothing I can do. Ymodem-G works under Altirra but probably can't work with real hardware. I'm not going to disable the feature, but the warning message displayed will be a little more general (something like "this is probably not going to work"). Next on the todo list is to code review the Zmodem download.

In the past few days I've been working on another issue that I'd like to get fixed up before the next release, and that is the matter of file transfers. I discovered and fixed a few minor inaccuracies in my implementation of X/Ymodem (Zmodem will wait for later), but got somewhat stumped on Ymodem-G. Ymodem-G is a special kind of file transfer designed for error-free data channels, such as modern dial-up modems which perform error correction on the fly, or a TCP connection. Once the file transfer starts the host does not stop transmitting the data packets unless the transfer is aborted. This means that the receiver must be able to write data to disk while data is still being received over the serial port. The Atari can't do this if both modem and disk drive are serial port (POKEY) devices, but should have no problem in other scenarios, such as if the disk drive is a RAMdisk, or if the modem is connected via some other means such as an MIO board, or, of course if the Atari is emulated, in which case the virtual modem doesn't use the emulated POKEY at all. This is nice in theory, but in real life only Altirra seems to actually work well in this mode. On a real Atari (with RAMdisk or MIO) data from the modem is lost. I don't know the precise details of what happens with an MIO (as this was tested by a user with Ice-T, which simply indicates a data error) but my 130XE has the US+ OS with built in RAMdisk, and when running a separate test program, if trying to write a file to RAMdisk while the data is received over the serial port, sporadic bytes are lost - one or two here and there - at any baud rate. I am not familiar with the low level details of what happens when a byte is received over the serial port, but as far as I can gather each incoming byte generates an interrupt in which there is a limited time slot for the CPU to read the serial port data before it is overwritten by the next byte. My hunch is that when performing a disk write, even to RAMdisk, this interrupt is disabled for some period of time and data may be lost. This however would not explain why the MIO is losing data (I assume the MIO works differently and has a buffer larger than 1 byte?). Is there anyone out there with knowledge deep enough to help here? At this point I'm considering disabling Ymodem-G entirely as I have not heard of a single user who's had success with it. Thanks in advance

Time for another release, 2.8.0 alpha 3. This release focuses on emulation accuracy and completeness. After the previous release, in which I went over the emulation code and reorganized it, I've now been able to take advantage of the much nicer code so I can fix old mistakes and add features. I have spent the last few coding sessions researching the various standards, searching for details I had missed or skipped in the past (when access to this sort of documentation was scarce) and filling in the blanks, running everything against Vttest, Emacs and a BBS with lots of ANSI art. At this point I think the emulation is pretty solid. So, the 'what's new' is: VT-52 emulation added (except the special graphical character set which is rarely used anyway). VT-100 emulation is upgraded to VT-102 (with added features such as insert/delete lines and characters). Several escape sequences not part of VT-102, but commonly used by ANSI systems (such as Emacs when TERM=ansi or BBS systems) have been added. ANSI-BBS mode now incorporates an additional tweak regarding cursor behavior when hitting the right margin. As a result some ANSI art looks much better, and Emacs is a lot happier. BBS users please set the Emulation setting to 'ANSI-BBS'. If you find any case where Ice-T seems to be performing incorrectly, try it against other terminal programs (I recommend SyncTERM for Windows) and let me know if you think there's a problem in Ice-T providing steps to reproduce the issue. APE users if you are using the trial version (which is rather old) to Telnet, the Telnet client identifies itself as a VT-52 to the remote host. If you get garbage control characters on the screen it may be useful to switch to VT-52 mode. (This was a complaint by w1k who showed me a video of this about a year ago, when he was trying to connect to irc.atarichat.net.) Linux shell users please set the TERM environment variable to 'vt102' or 'ansi' and set the Emulation setting to VT-102 or ANSI-BBS accordingly. Emacs will enable colors in ANSI mode but is very pedantic on the emulation setting. Enjoy icet_280_alpha3.xex

Very nice! You should definitely consider using your Atari's S-Video output, the red/blue colors on plain text aren't really supposed to be there, you know...