Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

itaych

Members
 View Profile  See their activity

  • Content Count

    210

  • Joined

  • Last visited

Posts posted by itaych

  1. Posted · Edited by itaych

    I've just compared Ice-T to a PC-based ANSI Telnet client as well as FlickerTerm, and Ice-T looks fine. However, I didn't dig very deep into rdfig.net because at some point it wouldn't let me proceed without giving my home address. If you can point me at a menu or picture that looks broken I'd appreciate it.

     

    Ice-T actually has an advantage over FlickerTerm, in that it has a full character set whereas FT is limited to 127 characters, and therefore line-drawing etc. characters are reduced to a subset. Just look at how FT displays the welcome screen (Ice-T screenshot attached, I have no idea how to take a screenshot of FT) to see what I mean.

     

    Also, how did you connect Ice-T to the net? I'm running it under Atari800WinPlus 4.0. The emulator listens to incoming connections on port 23, so I wrote a C program that connects to the remote host, connects to the local Atari emulator and bridges them. Unfortunately the emulator's R: device seems to have a bug - the most recent byte received from the network is buffered and only released when the next byte arrives. So, for example when typing a word, the letter that's echoed back to you is the previous one you typed. Oddly enough, this bug only appears in Ice-T and not in FT or other terminal programs. Hmm.

     

    If you know of a better way to do this I'd be happy to hear about it.

     

    -itay

    post-16047-127652300576_thumb.jpg

  2. Posted

    I don't know the authoritative answer to your question but I'm quite sure that the answer is that this only circulated as a text file and was never published as a book.

     

    My main reason for posting is to point out that all the online copies have some text missing in chapter 15, but that this text was actually found (source here and here). The text files read:

     

                                     CHAPTER 15
    
                                DISPLAY LISTS
    
    
    [some of this file was lost...]
    
    
    chip also has a memory scan counter. [...]

     

     

    Here is the full version:

     

                                     CHAPTER 15
    
                                DISPLAY LISTS
    
    
    The program which runs the ANTIC chip is called the display list. Much
    like a microprocessor, the ANTIC chip has a program counter, called the
    display list counter.
    
    The display list counter is a 16 bit register. However, the six most
    significant bits are semi-fixed. These bits can only be changed with a
    jump instruction. The result of this is that the display list counter
    cannot cross a 1K memory boundary (i.e. $A3FF to $A400) without using a
    jump instruction.
    
    The ANTIC chip finds the address of the display list in DLISTL [$D402
    (54274)] and DLISTH [$D403 (54275)]. SDLSTL [$0230 (560)] and SDLSTH
    [$0231 (561)] are the shadow registers for DLISTL and DLISTH.
    
    The ANTIC chip also has a memory scan counter. [...]

     

    -itay

  4. Posted

    I remember using it to access the public library many many years ago and was amazed at how it produced the double width text perfectly, something I've never seen any PC terminal emulator do.
    Indeed, proof that I had WAY too much time on my hands. :)

     

    Actually it was pretty trivial to do this, as double-width means 40 columns, and the Atari has little trouble doing that. It's a very rarely used feature though, which is why most terminal programs don't bother with it.

     

    -itay

  5. Posted · Edited by itaych

    Okay I've given up trying to get the 1030 to work with Ice-T.. so now I'd like to try to get my 850 interface working with Ice-T.

    Which R: handler am I going to want to use for this, (and if possible where can I get it)? I know I'm going to need a handler of some kind, as Ice-T refuses to load without one tacked on to itself.

    You don't need to tack anything on, just rename atari850.hnd (included in the distribution) to rs232.com and you're all set. Sorry about the delay in answering, I hope 6 years is better than never :)

     

    Ice-T will bomb with Y-modem-G and when I reported the Bug to the Author his reply was (oh then use Zmodem) #@!
    In YModem-G, data is streamed without any breaks except those generated by hardware flow control. Ice-T will attempt to write to the file to disk without closing the R: port but simply not reading data, assuming that the R: driver will take care of flow control. With the hardware I was developing and testing with - either an Atari 850 or an SIO2PC cable that behaved like a P:R: Connection cable - this was an illegal operation and would crash the Atari. I only allowed this mode because people on c.s.a.8 told me that there is hardware (MIO and BB, I believe) that does allow writing to disk while the R: port is still open, and does take care of flow control. I'm sorry but there was no way for me to test Y-modem-G on my setup at all, or debug this issue. Sorry if I sounded like a jerk.

     

    Looks like the original link is dead
    Indeed, universities have that annoying tendency to close students' accounts when they graduate.

     

    The problem with ICE-T is that it doesn't work on my machine. Whenever I run it, all I get is a continuous flow of "j" characters running through the terminal screen (and yes, the same stuff appears on the other side too). I mailed Itay Chamiel about it several months ago, but got no reply at all.
    I don't seem to remember such an email, sorry about that. This bug probably has something to do with the way Ice-T generates keyclicks. Since Ice-T has 3 different keyclick styles (none, simple, standard), and since some keys are accepted by Ice-T that do not naturally generate a click, the keyclick is defeated when the keys are read from the keyboard, and only after checking the current mode is the keyclick generated (or not, in "none" mode). The method by which the "standard" keyclick is generated is by artificially inserting an arbitrary value into the keyboard buffer, then calling the OS keyboard read routine. I'm pretty sure that arbitrary value is a 'j'. The OS read routine is supposed to clear that buffer, but obviously in some case (no idea which) it does not. Needless to say, this never happened to me on any system or emulator I've tried it on. A workaround to this bug would be to use Simple or no keyclick.

     

    I've posted the source code to Ice-T for your debugging pleasure in this thread. If anyone can reproduce and explain the "screamin' J's" bug, I'd be happy to hear it.

     

    -itay

  6. Posted

    A few years ago someone asked me to pack ICE-T so it would boot from a 1mbit cartridge, you can find it here:

     

    http://www.atarimax.com/flashcart/forum/viewtopic.php?t=246

     

    I'd also love to see any new development of ICE-T.

     

    Steve

    From that link:
    Ice-T has been modified to run with extended memory and the maxflash cartridge at the same time.

    Cool, how did you do that? The bank-selecting code is such a mess, it barely makes sense even if you have the sources :)

     

    -itay

  7. Posted

    So if you could release the source, that would be fun to look at.

    Very well, here's the source. It is intended be built using the ATasm cross-assembler. If you have a Win32 machine the assembler executable is already in there, if not (or you're worried about exes) get the latest from the svn at Sourceforge and build it for your machine. I've successfully run it on a PPC-based Mac as well as my Windows box.

     

    Simple instructions: In Windows you should be able to build this by simply unzipping and double clicking on build.bat in the Build directory. The result will be named icet.obj in the bin directory.

     

    Mark, the author of ATasm, was kind enough to add a "-mae" command line option, that makes ATasm recognize MAE-style local labels. In MAE, any label starting with a "?" is considered local. Regular (global) labels automatically delimit regions, which is a different behavior from MAC/65. So, if you have a code segment like this:

     

    label1
  ldx #0
?lp
  sta table,x
  inx
  bne ?lp
label2
  jmp ?lp ; error!!
label3 
?lp
  jmp ?lp ; not an error.

    There are two different "?lp" labels, but note the ambiguous call after label2, which would cause a build error. If this is still unclear, please feel free to dig up MAE's documentation for more details. For all other issues regarding the format of the assembler, seek the documentation for ATasm at http://atari.miribilist.com/atasm/ .

     

    Read the various .txt files lying around, they will give some good background information.

     

    There is currently no distribution license for this code. Until I can think of something more intelligent, everyone is free to tinker with it as long as your results are given free of charge and not sold.

     

    And before anyone asks, indeed, the code is not perfect. There are "cmp #0" (the horror!!) instructions scattered throughout, and the code is not the tightest. I wrote most of this in my early teens, give me a break :) . I didn't fix anything because I wanted to release code that will generate a binary-identical object file to what I released in 1997. (The original is in there, so you can diff it with your result.)

     

    Any further questions, post them here and I will try to answer them the best I can.

     

    -itay

    20071008IceT_XE_v2.72_AtariAge.zip

  8. Posted

    Maybe I'll just have to make room for a 13" TV, or try out one of those standalone video->VGA boxes.

    Just another thing for you to keep in mind: When displaying video through a PCI/USB capture device, there is usually a small delay incurred by the capture, deinterlace and display process. This is usually not too terrible when watching video, but when playing fast-action games the delay (of perhaps 2-4 frames) can become an issue. Maybe the standalone box really is your best solution, because those (or at least the ones I'm familiar with) have no frame memory and display what they receive immediately to VGA.

    Another note is that standalone VGA converters output video in the same refresh rate as what they receive. Some monitors may have problems if your Atari is PAL, because 50 Hz is not always supported (CRTs are better at this than LCD). With NTSC you shouldn't have a problem, as 60 Hz is a standard refresh rate for PCs.

     

    -itay

  9. Posted · Edited by itaych

    I'm surprised to 'see' you here. Is it still possible to register Ice-T?

    Trust me, your surprise is probably nothing compared to my astonishment at seeing people discussing Ice-T over ten years after its last release!

     

    And I guess that as long as I can breathe, I can still accept money :)

     

    But to be more serious, the plain answer is that there is no real benefit for registering. I never made a "registered" version of the software (it was hard enough to maintain the mess of the source code under the 8-bit's file managing tools without having two versions to worry about). There are only about 20 registered users, Ice-T was never the money-maker I hoped it would be ;)

     

    Anyway, let's wait and see. If we get people breathing new life into this project there might be a point in asking for donations. Or, perhaps it could be sold as a cartridge, depending on whether anyone is interested and can pull it off.

     

    -itay

  10. Posted

    hi guys, I am having some problems with this term program. [...]

    Hmm. How about I release the source code, and let you guys try and fix the bugs? Anyone interested in this?

     

    (I can't do any of it myself, the best I can offer is to answer to any questions you might have about the code while debugging.)

     

    -itay

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...