Jump to content
IGNORED

Ice-T XE 2.76 released


itaych

Recommended Posts

Ice-T XE is a VT-100/ANSI terminal emulator for the Atari 8-bits.

New for 2.76:

  • SpartaDOS: TDLINE is now disabled automatically in nearly all versions (2.x, 3.x, SDX 4.4 and above).
  • Fixed some cases where CPU intensive events such as clearing the screen could cause data loss.
  • VT100: Many improvements to emulation with the goal of conforming to the VT100 specification as closely as possible; now passes all tests in the 'vttest' suite relevant to VT100 emulators.
    • Added Origin mode, LEDs, DECREQTPARM (request terminal parameters) command.
    • Answerback string changed to "Ice-T".
    • Shift-Break now sends longer break signal, as per the VT100 spec.
    • Various misbehaviors, bugs and glitches fixed.

Enjoy,

-itay

Ice-T_XE_2.76.zip

post-16047-0-00555900-1381443217_thumb.png

post-16047-0-64203700-1381443223_thumb.png

post-16047-0-47108500-1381443228_thumb.png

post-16047-0-39400000-1381443233_thumb.png

post-16047-0-89604100-1381443237_thumb.png

post-16047-0-79676100-1381443242_thumb.png

post-16047-0-01596300-1381443248_thumb.png

Edited by itaych
  • Like 5
Link to comment
Share on other sites

Well. Seeing that this version is more or less stable, time to shake things up a bit. Here is a new version for your testing pleasure. I hope you all enjoy it. Changes are:

  • Changed the versioning scheme by adding a dot between the minor and revision digit, where it had been missing all along (i.e. 2.76 should really have been 2.7.6). So the next minor version will be 8 and the first release shall be 2.8.0.
  • Updated the R-Time 8 code to only read the time from the cartridge once per second, saving CPU time.
  • Moved non essential code from immediate to deferred VBI. This improves stability of disk I/O (I've had cases where file operations would choke for no known reason, this was it).
  • Implemented graphic rendition modes 30-37. It's not yet complete (this is an alpha version) and a little buggy, with some limitations imposed by the hardware but I think the results are worthwhile nonetheless.

icet_280_alpha1.xex

  • Like 3
Link to comment
Share on other sites

Ah, good that you asked. Here are the rules of the game.

ANSI supports text colors Black, Red, Green, Yellow, Blue, Magenta, Cyan, White, in two luminosities, normal and bright. Ice-T supports all these except black, which is treated as white (I couldn't think of a way to render black text though I might use inverse text in the future). Here are the additional limitations:

Each character on the screen can be colored or uncolored. (White text of normal luminosity is considered uncolored. Anything else is colored.)

Coloring a character will also color its adjacent character, as the resolution of the coloring underlay is only 40 columns in width.

All colored characters within the same horizontal range out of these five ranges [0-15], [16-31], [32-47], [48-63], [64-79] will be of the same color. If attempting to use two different colors the more recent color will change the others within that range. Vertically there is no limitation, so each text line can have up to 5 different colors.

ANSI allows defining the background and foreground colors separately but this is impossible in ANTIC F (Graphics 8 ) mode which Ice-T uses. So for a colored character the foreground and background colors are the same. If different background and foreground colors are specified the foreground color takes priority adn background is ignored. If only a background color is specified it is treated as foreground.

 

There are some things I didn't implement yet - which may cause visual problems like color blocks remaining on the screen when the text has been erased, also the colors might be ugly if the color scheme isn't the default white text on black background. There are also very likely to be visual glitches and bugs as this hasn't been thoroughly tested (colors may be wrong on top line of screen, this is a known issue). But hey, it's color! In 80 columns! I think it's a first on the Atari.

post-16047-0-66883000-1381644470_thumb.png

post-16047-0-17049600-1381644475_thumb.png

post-16047-0-85928000-1381644480_thumb.png

Edited by itaych
  • Like 7
Link to comment
Share on other sites

Very cool. Itay, perhaps a nice optimization would be to select the color that is dominant in a region instead of always the last one set. Maybe also experiment with turning off color for text that would get the wrong color, or maybe selectively disabling color based on a hue difference calculation.

Link to comment
Share on other sites

Not fair ... I wanted this back in 1989 when I used to call ANSI BBSes all the time. :(

 

Another thing to try: Emulation of PETASCII for calling Commodore 64 BBSes ... this would be easier to do, you could use 40 columns if you want, in Antic 4 or Antic F mode, with PM overlays. It just might be possible to get the 16 colors needed. I would have loved to have this back in the day, when I used to call a Color 64 BBS located just up the road from me.

Link to comment
Share on other sites

Not fair ... I wanted this back in 1989 when I used to call ANSI BBSes all the time. :(

 

Dude, I would have happily made Ice-T sooner but in 1989 I was 10 years old. :)

 

Another thing to try: Emulation of PETASCII for calling Commodore 64 BBSes ...

 

I've answered this before when I was asked to do a VBXE version. Ice-T cannot change its graphic rendering engine as one changes their socks. The 80-column Graphics 8 bitmap concept is deeply ingrained into every part of the code. This would require a rewrite of almost everything.

 

Very cool. Itay, perhaps a nice optimization would be to select the color that is dominant in a region instead of always the last one set.

 

The idea seems valid, but let's look at it from the programmer's perspective (i.e. mine).

 

First of all, this would mean keeping track of the color of each individual character. So I'd need a 2KB buffer for this - 2KB which would have to come at the expense of something else because I don't have 2KB lying around. Secondly, this buffer would need to be carefully scrolled around and properly filled and cleared so as to always accurately mirror the situation on the screen - groan. Third, this would also add yet another mess to the spaghetti that is the code today (remember, this is Assembly language).

 

And I don't really like the concept. A terminal is a very simple and deterministic machine; its emulator is supposed to be likewise. Also while theoretically the idea sounds nice, in reality I don't think it will look very good and I don't want to expend a large amount of time and effort to find out.

 

Perhaps some Atari centric BBS's could detect that you're running Ice-T (easy: send a ctrl-E and see if you get "Ice-T" in response) and adjust their coloring scheme accordingly? :) I could even take this a step further and add a custom control code that will allow applying *any* color from the Atari palette, but again this would need cooperation from the BBS side to be of any use.

Edited by itaych
  • Like 3
Link to comment
Share on other sites

Here's another release. I believe I've fixed most of the visual glitches and known bugs I mentioned earlier, so this is supposed to be a little more solid (coloring rules are unchanged).

 

Also, a new feature useful for emulator users: if you're loading this by dragging the .xex file into the emulator window then there is no DOS and therefore no "D:" device - but from this version, if there's an "H:" device present (set up as a mirror of a folder on your hard disk) then it will be used as the default path for the configuration file and file operations - so you can now save your settings without needing to load DOS or use a disk image.

 

A lot of code has been weeded out or optimized so this file is actually a little bit smaller than the previous one. Let me know if this has introduced any problems.

icet_280_alpha2.xex

Link to comment
Share on other sites

 

Well. Seeing that this version is more or less stable, time to shake things up a bit. Here is a new version for your testing pleasure. I hope you all enjoy it. Changes are:

  • Changed the versioning scheme by adding a dot between the minor and revision digit, where it had been missing all along (i.e. 2.76 should really have been 2.7.6). So the next minor version will be 8 and the first release shall be 2.8.0.
  • Updated the R-Time 8 code to only read the time from the cartridge once per second, saving CPU time.
  • Moved non essential code from immediate to deferred VBI. This improves stability of disk I/O (I've had cases where file operations would choke for no known reason, this was it).
  • Implemented graphic rendition modes 30-37. It's not yet complete (this is an alpha version) and a little buggy, with some limitations imposed by the hardware but I think the results are worthwhile nonetheless.

 

 

Awesome!

 

Question: How do I transfer this .xex file to an .atr or floppy disk to load on my real Atari?

 

-=[LC]=-

Link to comment
Share on other sites

Go to: http://www.horus.com/~hias/atari/#tools-win32

 

Get the "Atari Tools for Win32" file (named tools-win32-101002.zip). Extract dir2atr.exe to some directory. Within that directory create an empty 'temp' directory. Place the .xex file inside that. Then back up in the parent directory enter the command:

 

dir2atr new.atr temp

 

This will create a disk image 'new.atr' containing all files in the 'temp' directory, in this case the xex file.

Link to comment
Share on other sites

Here's another release. I believe I've fixed most of the visual glitches and known bugs I mentioned earlier, so this is supposed to be a little more solid (coloring rules are unchanged).

 

Also, a new feature useful for emulator users: if you're loading this by dragging the .xex file into the emulator window then there is no DOS and therefore no "D:" device - but from this version, if there's an "H:" device present (set up as a mirror of a folder on your hard disk) then it will be used as the default path for the configuration file and file operations - so you can now save your settings without needing to load DOS or use a disk image.

 

A lot of code has been weeded out or optimized so this file is actually a little bit smaller than the previous one. Let me know if this has introduced any problems.

I wasn't going to ask this question, because if falls into the realm of emulators, but since you are supporting H: drive I thought I'd go for it. :D

 

I've built atari800 ver 2.2.1 with the options --enable-riodevice and --enable-rnetwork (--target=x11)

 

This gives me access to telnet for R:

 

To use the feature I need to invoke atari800 with the -rdevice switch (without a device parameter specified), load the Atari 850 driver, and then Ice-T.

 

From there I can manually type ATDI <address> <port> and open my connection to a BBS (or any telnet session).

 

Optionally I can type ATDL. The difference is this suppresses auto linefeeds (I think)

 

Here's my question.

 

Is there an easy way to change the dial command for Ice-T's dialing directory? I think Ice-T currently uses ATD and then the string in the directory. Atari800's rdevice module seems to be expecting ATDI (or ATDL) and a space and then the string.

 

I tried my best to patch my copy of rdevice.c for atari800 but programming (especially in C) is not one of my strengths.

 

-SteveS

Edited by a8isa1
Link to comment
Share on other sites

Your issue is specifically addressed in the manual.

Oops, so it is :o

 

I'm still having trouble with darkforce-bbs.dyndns.org. I can see some communication going on but Ice-T never leaves dialing mode. Here's some screenshots.

 

post-9154-0-82658500-1381883433_thumb.pngpost-9154-0-25435800-1381883486_thumb.pngpost-9154-0-48248400-1381883525_thumb.png

 

 

I can connect by manually typing the ATDI etc

Edited by a8isa1
Link to comment
Share on other sites

My first theory is that you were already online - manually - when you tried the dialing menu. In that case Ice-T doesn't try to hang up and the BBS you are connected to doesn't know what to do with the ATD command.

If this is not the case, and you're sure you were offline (in AT command mode), does this happen *only* with darkforce?

Can you post a screenshot of a successful manual connection? It should show the ATD line you type and as much as possible beyond that, so pause the terminal with ctrl-1 before the ATD line scrolls off screen. I can't reproduce this with Altirra and I don't use Atari800.

Link to comment
Share on other sites

My first theory is that you were already online - manually - when you tried the dialing menu. In that case Ice-T doesn't try to hang up and the BBS you are connected to doesn't know what to do with the ATD command.

If this is not the case, and you're sure you were offline (in AT command mode), does this happen *only* with darkforce?

Can you post a screenshot of a successful manual connection? It should show the ATD line you type and as much as possible beyond that, so pause the terminal with ctrl-1 before the ATD line scrolls off screen. I can't reproduce this with Altirra and I don't use Atari800.

 

post-9154-0-94241100-1381918183_thumb.png

Could the problem be due to atari800's virtual modem responding with "OK" instead of "CONNECT"?

Link to comment
Share on other sites

Yes, that's it exactly. Looks to me like a completely broken design decision on behalf of Atari800. Since you're compiling it yourself anyway I think it would be trivial for you to fix this by changing the OK to CONNECT (or anything else as long as it starts with the letter C).

Link to comment
Share on other sites

Yes, that's it exactly. Looks to me like a completely broken design decision on behalf of Atari800. Since you're compiling it yourself anyway I think it would be trivial for you to fix this by changing the OK to CONNECT (or anything else as long as it starts with the letter C).

That worked.

 

Also, since it's for my personal usage and I don't need to initiate real serial communications I'm having ATDT also route to telnet. I just don't think that I'd remember to use 'ATDI' at a future time. 'ATDT' is imprinted in my brain. :D

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...