Ice-T XE 2.76 released

[itaych]

Len Spencer wrote a high speed handler for the MIO and Blackbox which has hardware flow control.

 

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.

 

Itay, your hunch is absolutely correct about ramdisk access, they do turn all interrupts off for access to the extended banks [..]

 

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.

[BillC]

 

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.

That's up to you, I thought it might be of use since the post I was responding to mentioned dropping data with the MIO.

[Lord Cygnus]

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

 

Works great on my Atari 130XE, P:R:Connection, and Lantronix UDS-1100. Great work, Itay!

 

-=[Lord Cygnus]=-

[itaych]

That's up to you, I thought it might be of use since the post I was responding to mentioned dropping data with the MIO.

 

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.

[w1k]

how i can take screenshot and save it to D1?

[itaych]

how i can take screenshot and save it to D1?

 

Does anybody ever read the fine manual these days?

[w1k]

on ATR file?

 

it is unreadable.. in LW text editor.....

 

or ZIP file? - any info about making screenshots

[itaych]

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

[itaych]

...

 

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.

Edited November 26, 2013 by itaych

[w1k]

time sync with SDX/U1MB/SIDE II clock will be good

[itaych]

time sync with SDX/U1MB/SIDE II clock will be good

 

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

[flashjazzcat]

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

He has no such information.

[Kyle22]

Hi Itay, fine work. I think you may find appropriate clock info here: http://sdx.atari8.info/sdx_files/4.46/Manual_V4-46_V1-1.pdf

 

Look at page 170 (184 in the browser pdf viewer.)

 

Hope that helps.

 

-Kyle

[itaych]

time sync with SDX/U1MB/SIDE II clock will be good

 

I think you may find appropriate clock info here: http://sdx.atari8.info/sdx_files/4.46/Manual_V4-46_V1-1.pdf

 

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

Edited November 27, 2013 by itaych

[+Stephen]

 

 

 

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.

 

Excellent - works perfectly for me, using U1MB.

[phaeron]

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?

 

You might be surprised. I once got a bug report on Altirra losing two minutes a day in the emulated Atari's clock. It turned out the user was running a BBS program in emulation that was assuming 60Hz and didn't compensate for Atari's slightly non-standard 59.9227Hz refresh rate, and was running it long enough over multiple days to notice the clock drift....

[w1k]

works fine with SIDE II, u1mb.. but when i quit ICE-T, i missing top bar in SDX.. i dont know if is issue of SDX or ice-t

[flashjazzcat]

works fine with SIDE II, u1mb.. but when i quit ICE-T, i missing top bar in SDX.. i dont know if is issue of SDX or ice-t

Ice-T. AFAIK, it disables the TD Line under SDX and doesn't re-enable it on exit. There's also a whole lot of screen garbage when loading the program with the TD line on under SDX if the TD line hasn't been turned off before CRITIC gets set during the loading process. This only happens some of the time.

[itaych]

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

[flashjazzcat]

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

Well, before loading ICET - with TD Line enabled under SDX - $230 (SDLSTL) points to $142C, which is the top of the TD Line Display List (this will vary depending on where in RAM the driver loaded). This display list ends with a JMP to $9C23, which is where the remainder of the OS display list resides. When the problem occurs, after typing "X ICET.XEX", the "X" command first disables the library and moves the screen and display list up in RAM by 8KB. When the garbage is displayed, the SDLSTL points at $BC20 (so the TD line has been disabled), but the end of the DL does a jump/wait to $BC2C, which is the wrong address. So the target of the jump/wait was not properly reset when the TD line was disabled (presumably by changing the DL vector, rather than calling the driver, which would have reset the DL properly).

 

While investigating this, I noticed that Altirra's .dumpdlist command always reports the target address of the Antic jump/wait command rather than the content of SDLSTL if the two differ (which they shouldn't in any case).

 

So - if you're going to shut off the TD Line by directly writing to the display list vector, you also need to trace through the DL (following the Antic JMP instruction, $01) and also amend the target address of the jmp/wait at the end of the OS display list.

 

The fact this issue only happens about half of the time would suggest to me that the stage 2 VBL is resetting the jmp/wait vector when the application is half way through changing SDLSTL. The solution might simply be to do an SEI prior to amending the vectors.

Edited November 28, 2013 by flashjazzcat

[Triads]

 

You might be surprised. I once got a bug report on Altirra losing two minutes a day in the emulated Atari's clock. It turned out the user was running a BBS program in emulation that was assuming 60Hz and didn't compensate for Atari's slightly non-standard 59.9227Hz refresh rate, and was running it long enough over multiple days to notice the clock drift....

 

Hey that was me! ha

[itaych]

So - if you're going to shut off the TD Line by directly writing to the display list vector [..]

 

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?)

[flashjazzcat]

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?)

OK - that's good to hear. In that case, a delay loop before any disk activity would be an excellent idea, just to give the stage 2 VBL a chance to tick over a couple of times before DOS sets CRITIC.

[itaych]

the end of the DL does a jump/wait to $BC2C, which is the wrong address.

 

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.

Edited November 28, 2013 by itaych

[flashjazzcat]

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.

Yep - just tried loading some other stuff with the X command and screen garbage occasionally appears. Hopefully the garbage won't "stay", however, providing DLT are informed of the issue.