itaych

Update: the modified version of Ice-T did not help. So, for some reason neither P:R:Connection nor MIO are working for russg on real hardware. I don't have either of these, and without further information there's nothing I can do. Does anyone else have either of these interfaces and can test Ice-T on it?

Just to clarify this misconception, the ICET850 file is actually the Ice-T executable with the ATARI850.HND file prepended. So, it behaves the same as if you had loaded ATARI850.HND, then loaded ICET.COM. Now, the ATARI850.HND is just a little stub that tries to download the actual device handler from the hardware device (the 850 or, in your case, the PRC). On Altirra it fails gracefully, so it has no effect, but an R: handler is not required there so Ice-T runs anyway. On your real Atari it should download the PRC handler and install the R: handler, and then Ice-T will load correctly as well. You shouldn't have to load both PRC.HND and then ICET850. So this disproves a theory I had, that Ice-T was starting too low in memory and overwriting the R: handler. I've PMed you a version of Ice-T that uses a more conservative method to access R:. Let me know if that works for you on your hardware.

Try this experiment. With BASIC enabled, boot MyDOS. Load the PRC's R: handler (a handler known to be working, not necessarily with Ice-T). Then exit to BASIC and issue the command: PRINT PEEK(743),PEEK(744) Let me know what you get. (Oh, and thanks for your concern, but it's just half past midnight here.)

With your PRC and 1050 setup, boot MyDOS. Load ATARI850.HND. When the DOS menu comes back load ICET.COM from 2.73 or 2.74. Does this work?

The 'jjjjj' bug also affected real hardware in certain circumstances, and several users complained about it. Altirra (and its author) helped me reproduce and solve the bug, but this was certainly not an emulator-only issue. I've now ran Ice-T on a real machine with various configurations and could not reproduce your problem, but unfortunately I don't have a PRC to test with so I can't reproduce your setup exactly. However, I don't really understand how you're connecting your modem. The P:R:Connection should connect directly to the Atari's peripheral port on one side, and directly to the modem on the other. The APE cable is not supposed to be involved here. Can you be a little clearer on what you're doing? Another thought I've had is that if the "ICET850" worked for you, then instead of the PRC.HND try loading ATARI850.HND. This will reproduce what the "ICET850" is doing (it loads the 850 handler, then loads the regular Ice-T binary). The 850 handler is not actually specific to the 850 as it downloads the device handler from the remote hardware, so it just might work for you. If none of this helps please test version 2.73 as I requested in my post above.

Russ, can you do the same experiment with version 2.73? Link here.

That would explain why you're encountering a bug I fixed last year. And I have no idea where that disk image came from, someone probably prepended the 850 handler to the Ice-T executable and put it online.

There is no file named ICET850 in any of my releases. I want to understand what russg is doing because he's doing something wrong.

What on earth is ICET850.AR0 ?

Have you tried using the X command? (type X ICET) Adding a second Pokey for stereo sound is more like a memory upgrade or OS replacement. If on the other hand you had replaced Pokey with a backward compatible hardware chip that also added stereo sound, MIDI support, SID emulation and 48khz audio sampling then my attitude would be similar to VBXE. If you have any questions that are too specific for posting in the forum, no problem, PM me.

Heh, maybe this is just a trick he's pulling to get a free cart?

Er, I, umm, love you too... Wow, if this works with the Incogneto I'd love to hear about it, it would be so cool to have this running on an 800 I've discussed this with one of the developers. If the Dragoncart's support software can present itself as an R: device and include a Telnet client (basically it should do what Altirra and APE do) then not only Ice-T but any other terminal software should be able to use it. The code can be placed in the RAM under the OS, as Ice-T doesn't use it and as far as I know no other terminal software does either. Short answer: no. Long answer: also no, with the reasons being Philosophical, Programmatic and Practical. Philosophically speaking, nobody forced me to write Ice-T. When I started I could just as easily have set the aging Atari aside, scrounged an old PC clone from somewhere, hooked up a modem and used Kermit or Telix to happily do the same things I did online, freeing the spare time from several years of my life for other things. I wrote Ice-T because of the challenge involved in making the Atari with its limited capabilities do something it was not designed to do, where others have tried and failed. As far as I'm concerned once you replace the Atari's display chip with a modern alternative it's not an Atari anymore. It's a new platform, perhaps interesting to some but I may as well spend my time writing an Android app - at least there I have the potential for more than a few dozen users. Programmatically, keep in mind that Ice-T despite its professional look is a big ugly hack written many years ago in assembly by a teenager with a lot of time on his hands (mostly by putting school at the bottom of the priority list) but very little knowledge of software architecture. Which is probably just as well because a similarly featured but properly maintainable and structured application would run slower and probably not fit in 128K - it's bursting at the seams as it is. More to the point, there is no single "display a character" function that I could replace with the VBXE equivalent; virtually all of the code is written around the bitmapped 80-column display, from the VBI that handles the fine scrolling to the menu system to the code that flashes the cursor. Basically we are talking about an almost complete rewrite. Which brings me to the Practical part of my answer: the 80-column display is the most interesting aspect and "killer feature" of Ice-T. It's the reason for Ice-T's existence and is where I spent most of my time and effort. With VBXE it becomes redundant, and once you've gotten rid of it, what's left? The terminal emulation and file transfer code is not rocket science, it's just ugly because it's in assembly. You would probably want to throw it out and reimplement it, preferably in a higher level language like C. Or possibly just port existing C code from another emulator, such as Minicom (an open source terminal emulator for Linux). The reason you would now be able to do this is that without the bitmapped 80 columns you've just freed up about 90% of CPU time and around 50% of memory use, so you can now afford to write much cleaner code at the expense of a little bloat. So in any case, if anyone would like to take Ice-T's code as a foundation for a VBXE based terminal emulator, I'm not going to stop you but don't expect me to do it.

The cable costs $60 and the software costs $40. I assume you already have a cable, so why do you claim it costs $150? Steve has always answered my questions immediately so I don't know where you got that 0% figure either... Also, you really need version 3.0.8 and above to use it as a Telnet gateway for Ice-T, otherwise it will identify to the remote host as a VT-52 and you will get garbage on the screen.

Ice-T XE is a VT-100/ANSI terminal emulator for the Atari 8-bits. It has taken far too long to incorporate the feedback and requests from the 2.73 release, but here it is: 2.74 in all its glory. The distribution now includes a quick start guide for those of you who would just like to get this working as quickly as possible on a Windows based emulator. So, if you have Altirra go ahead and give it a try. Here's what's new: Screen dump to disk added (by request) . Minor speed improvement in text rendering thanks to Jon Halliday (of The Last Word). R-Time 8 cartridge support was buggy, fixed. Minor improvement to clock accuracy (when no RT8 present). RS232.COM automatic loading is now only attempted under MyDOS. SpartaDOS 3.x: Added automatic disable for TDLINE if it is on. (SDX users, sorry but I couldn't get this to work.) SpartaDOS 3.x: The configuration file ICET.DAT will now be correctly loaded from the current path. Also Ice-T's current path (Mini-DOS menu) will also point to the correct current path at startup. SpartaDOS X: Ice-T must be loaded with the "X" command. A reminder is shown if you did not. Mini-DOS menu: Path will now accept any single-letter (or letter and number) device type, so you can access files on things like H:. Also '\' is now allowed as a directory separator. File Viewer: Fixed EOL parser, should work with Unix/Windows/ATASCII files. VT100 emulator: Minor tweaks to font; Underline now ignored for mode 3 (top half of double height row) text; Fixed a very very old bug discovered at the release of 2.72 (in 1997!) involving scrolling portions of the screen in bold-text mode; Fixed bug that caused double-width/height lines to misbehave when scrolling upwards. Bold text is now enabled by default. The bold text bug was a particular reason that I had delayed this release. I needed to find the time and patience to rewrite a buggy but particularly tricky piece of code, and I'm happy to say that it seems to work well now. The bug itself was probably noticeable to no one except me, but it was there. With these fixes the VT100 'torture test' now passes. I've added screenshots of both Ice-T and a real VT100 terminal performing the test for your entertainment . As usual I'll be happy to hear feedback. -itay Ice-T_XE_2.74.zip

I found the following to be true, unfortunately neither is enough to establish a pattern. cleartext[0] = cypher[0] XOR cypher[1] and also cleartext[0] = abs(cypher[0] - cypher[1]) Also, if cleartext is a result of some computation involving cypher and cypher[i+1] then that would explain why the cypher is one character longer than the cleartext.

Page 76. May I suggest obtaining the PDF version and using the search capabilities of your favorite reader

Hi all, In ANALOG Computing issues 24-26 (Nov.84-Jan.85) the following announced appeared: The prize offered to the first five correct entries was a free one-year cassette or disk subscription. The deadline for submitting a solution was January 1 and yet the correct answer was not published in the forthcoming issues. Only when a reader inquired about the matter did the magazine respond, half a year later in issue 32 (July 85): Interestingly the magazine never explained what the encryption scheme was. Can anybody figure it out?

Thank you for your kind words. And yes, that's the demo.

Wow synthpop, you did a beautiful job. For those of you wondering why there aren't sound effects, original music, or why the game is so bare: this was a quick hack written in a week in 1994. I was 15. Most of my serious programming time was devoted to Ice-T. Also, in my defense, I did not take anything from the game Plastron. I had not seen nor heard of the game at the time. The music was ripped from Plastron by persons unknown and used in the Atari Expo 1991 demo, which is where I heard it. The music data and player were present on that demo disk as a separate file, ready to be copied and reused. I had no idea I was infringing on commercial IP and would not have done it if I knew. Interestingly in 2004, in the process of rescuing the source code from the old floppy images, I did try to figure out the source and/or author of the music so I could at least credit them in the source code, and I did what I could not do in 1994: take various interesting words from the scrolling texts in the Atari Expo demo (which were in a European language I couldn't understand) and google them. One of those words was "Plastron", and that's how I learned where the music came from. May I add that the music (written by Richard Munns according to the Plastron title screen) is awesome! When I first heard it I left the demo running for a long time and let the music loop repeatedly as I grooved to it. I thought it would serve as the perfect background to my game and I'm sorry if not everyone agrees. -itay

I'm not familiar with the atari8ethernet project but I have feeling that loading random R: handlers and hoping that Ice-T will magically work, is not the way to go. For starters, there is no TCP stack. Even if you had one, Ice-T is not a Telnet client and will not interface with TCP/IP. What were you expecting?

It's a VT-100 terminal emulator, allowing you to connect the Atari to various online services. Google "ice-t atari" for more information.

It's a rap music generator with autotune

Jacques, this is an issue with APE's telnet client - it presents itself incorrectly as a VT-52 terminal when connecting, and there's nothing Ice-T can do to fix this. I've spoken to Steve Tucker, author of APE, and he has added an "identify as" option in the R: configuration - VT100 or ANSI should work well. The fix appears in version 3.0.8 which is available to registered users. Good luck

w1k, please turn your computer off and leave it off for about 10 seconds between running two different beta versions. Let me know if that fixes the problem you've seen,

Here's another beta. EDIT: The speed improvement is not as dramatic as I thought. Let this be a lesson to us all: never release software versions at 3 AM. Hope you enjoy regardless... Speed improvement in text rendering thanks to an idea from The Last Word. Thanks to Jon Halliday (flashjazzcat) for this one. Minor improvement to clock accuracy (NTSC only at the moment, PAL soon). Mini-DOS: Path will now accept any single-letter (or letter and number) device type, so you can use files on things like H:. Also '\' is now allowed as a directory separator. File Viewer: Fixed EOL parser, should work with Unix/Windows/ATASCII files. VT100 emulator: Minor tweaks to font. Underline now ignored for mode 3 (top half of double height row) text. Fixed a bug involving scrolling portions of the screen in boldface mode. With these fixes the VT100 'torture test' now passes. icet2.74BETA4.xex