Ice-T XE 2.76 released

[doctorclu]

I have run into this overflow of text:

 

In this situation the text goes from something that is understandable to what appears to be random characters. Sometimes it will become readable, but the keyboard map will be off (you type a x, you get an "i" strange stuff like that.) This happens after I have been BBSing for about an hour to three hours.

 

Setup over here, Atari 800 (pokey and PIA chips recently replaced), Incogneto install running Sparta Dos and the latest Ice-T version 6 alpha.

 

Serial interface is the More Than Games Speedier module with the Bob-Inverter 2.4 Fast Handler (10/16/89). Found 19.2K was only sometimes responsive so running at 9600 baud at the moment.

 

Might try with a 850 interface to see if I get the same problems.

[itaych]

Hey curious if you had any luck with this?

 

There's nothing particularly difficult with what I want to do, the hard part is finding time. There was a bit of a slump at work which lasted a couple of months, which meant I didn't have much to do and therefore had plenty of mental energy left to do Atari stuff in my free time, which allowed the last several versions. The present and usual case unfortunately is that when I get home the bits of my brain that are busy when I code are worn out and need their rest. Even on weekends it's hard to find time with all the being a dad thing. So I can't promise when I'll get to it, but I will when I can.

 

I have run into this overflow of text [...]

 

I'm going to need a LOT more information if I'm ever going to be able to diagnose and fix this. I'd need answers to as many of these questions as you are able to answer:

 

Does this happen more than once? Does it happen often? Is there a pattern? Is this something that will ALWAYS happen after a certain amount of time or activity? Try starting up Ice-T and leave it idle for a few hours, does the bug happen or do you need to be actively using it for a long time?

 

Once it happens, is there any way to snap out of it? Tried things like switching to the menu and back? Use the "Reset Term" option in the menu? Can you hang up with +++ ATH, and if so do you return to normality and can you dial again? Try going to the File menu and viewing the disk directory - that closes and reopens the serial port, does that help? Turn your modem off and on, any luck? If all else fails, press Reset, which reinitializes Ice-T - does that help? Failing that do a coldstart - does that fix it?

 

Was there ever a time when your present configuration did work for many hours without displaying this problem? What changed since then?

 

Can you try connecting to your BBS by Telnetting through Altirra? Does the bug happen there? If so can you save the state and send me the state file?

 

In any case do try with a different interface, or try using another terminal program (like FlickerTerm) for the sake of the test. For all I know this could be your modem acting up or something in the interface driver, or maybe even a problem in your replacement POKEY - since I've never heard of this bug from anyone else.

 

This reminds me of a funny story: one day I was playing a lengthy game of Joust, when suddenly the game halted and returned to the title screen. I was having a pretty good session so, annoyed, I started a new game. A few minutes later, it happens again. Then I notice the game options (difficulty and players) are changing on their own - a few times a minute, then gradually faster and faster. Turns out that GTIA was faulty and was sporadically indicating presses of the console keys. It only happened when the chip warmed up, so my solution of course was an ice cube in a bag placed on the chip which let me keep on gaming until I could have it replaced. My point is that perhaps your POKEY (which controls the serial port) is broken but only shows its problem after a few hours of use. Also that Joust is a great game, but I digress.

 

Anyway, try these things and let me know what you find. Thanks.

[flashjazzcat]

First rule of software troubleshooting: blame hardware.

[_The Doctor__]

YES!

[Marius]

ON SDX I keep getting that the R: device is not found. I load RS232 drive, which works... ( I hear the beep of my atari 850 ) but the program keeps reporting:

 

* R: device not found!

 

What am I doing wrong?

[itaych]

ON SDX I keep getting that the R: device is not found.

I don't have an SDX cartridge, and my 850 is long gone, so I can't try this on real hardware. Altirra has recently added full SIO emulation of the 850 however, so I thought I'd have some luck with that. Under MyDOS I could load the 850 R: loader (RS232.COM, distributed on the Ice-T disk as ATARI850.HND), the bleeps were loud and clear and Ice-T loaded just fine. Under SDX however the 850 doesn't respond to the loader at all - no beeps, so no R:. So, I am seeing the same result as you but this is probably not the same problem.

 

If I try a different handler (such as RVERTER) then Ice-T loads just fine, but of course there are no communications.

 

Do other terminal programs work for you in this scenario?

 

 

Phaeron, can you please take a look at this? It happens when setting R: device to 850 and SIO mode to Full.

[phaeron]

It's kind of ugly. The 850 relies on a three-stage bootstrap: a type 1 poll command (cmd=$3F), relocator load (dev=R:, cmd=$21), and then handler load (dev=R:, cmd=$26). The type 1 poll command unfortunately overlaps with the get high speed index command used for disk drives. It appears that newer versions of SpartaDOS X (4.46) can issue this command blindly to disk drives when older versions (4.20) wouldn't. This can happen enough times for the 850 to respond to the command as a type 1 poll, after which it shuts off and never answers the poll again until power cycle. I don't have a physical 850 to test this on, but this is from an analysis of the controller ROM. The problem would therefore depend on many factors including which version of SpartaDOS X is in use, how many disk drives are attached, and whether those drives respond to the high speed index command.

 

The 850 does always respond to the relocator load command ($21), but the problem is that the computer doesn't know the length of the relocator unless it has the DCB from the type 1 poll response. BobTerm appears to just try kicking out this command anyway if it can't find the device by polling, but it hardcodes the 850's relocator length of $155 bytes, and that doesn't work with Altirra at the moment because its relocator is shorter ($144 bytes). Doh.

 

A robust RS232.COM loader could be made that had a custom SIO routine that could issue $21 and figure out on the fly how long the payload is. Problem is, that's more work than just loading the handler off disk... and there are faster and smaller R: handlers than the one built into the 850 anyway.

[itaych]

So, can you recommend a replacement disk-based handler that will work around this problem, but still function with a real and emulated 850? I will be happy to add it to the Ice-T distribution.

 

BTW a minor nitpick: On a real Atari, if booting without a disk drive but with an 850, the 850 will respond to the boot request and boot its R: handler before the Atari gives control to the cartridge/BASIC/Self Test ROM. So for example Basic has access to R: without the need to load anything from disk (useful if you only have a tape to load your programs, I guess). This does not occur on Altirra. Perhaps - and this is just a wild guess - if you emulate this behavior correctly, SDX will automatically load the R: from 850 when starting up? It sure makes a lot of weird I/O noises, perhaps it's looking for an 850. But again this is purely speculation.

[phaeron]

It's been a while since I worked on the 850 emulation, but I seem to recall that the P:R: Connection handler was compatible. If not, I could make an EXE version of Altirra's handler... but I can't guarantee it would work on real hardware, not having tested it.

 

Regarding the boot issue, do you have Fast Boot on? It looks like there's a bug where this shortcuts the disk polling before the 850 bootstrap can see it, which I'll fix. If D1: isn't present, the 850 emulates a disk after 25 failed attempts. This does happen in Altirra if you have fast boot disabled.

[itaych]

 

ProWizard, I've tried a disk-based R: handler for the P:R:Connection (which is mostly 850 compatible). Under Altirra and SDX it loaded fine, and Ice-T runs and communicates with the virtual modem, except for some harmless garbage data received when opening the serial port. Please try it yourself. Get the file PRC.ZIP from this post by russg, and try the included handler instead of RS232.COM.

 

Regarding the boot issue, do you have Fast Boot on?

You're right, disabling Fast Boot did the trick. My guess was wrong though, this had no effect on SDX. The disk based handler seems an acceptable workaround though.

[Marius]

I know now what went wrong, although it is still weird.

 

The driver I had in my folder was named: RS232.COM but … on Car: was also a RS232 driver located!

 

The RS232 was loaded from CAR: and not from the folder where ICET was located in.

The RS232 from CAR loaded the 850 driver (I hear the BEEEEEEEP)

 

But it does not work with that one!

 

When I renamed RS232.COM into something else, and I load that driver with X it works.

 

Why doesn't ICET-T work with the RS232 driver that is part of the SDX package? That is now the new question

[itaych]

The emulated 850 won't respond to SDX's RS232 just as it won't respond to the standard version, therefore I have no way of reproducing this. So, I guess use whatever workaround works for you

Edited February 27, 2014 by itaych

[_The Doctor__]

That's interesting, the new sparta did the same thing to me with a mio and black box, but the r: ports were off and ape was on... I turned the ports on in the mio and bb ape's off- pressed reset and nada, then I loaded rs232.com it said it was already loaded nadah.. then I renamed and loaded disk version... and it worked sort of..... then I turned it of unloaded the cart rs232.com and loaded disk based and all was fine..... looks like something is weird on the car: based rs232.com

 

Ice T on the other hand was pure color candy! not it's fault sdx's rs232.com just didn't wanna play.... same results with other terms....

 

Nice to see color T once again.

[w1k]

any news?

[Marius]

Today I have 'hacked' ICET 2.80 alpha 6, so it works with MyDOS on unmodified atari 130XE and MyIDE interface.

 

Since MyBIOS on stock atari disables internal OS and wants bit 0 of PORTB being false, I replaced all PORTB values in the binary.

 

I know MyBIOS is not popular here, but I keep using it from time to time, and I really wanted ICET to run, without the need of SDX. On SDX it also runs on 130XE on unmodified atari.

 

If interested let me know. I don't know whether author of ICET want me to release it, or not, so I do not post it here.

[flashjazzcat]

I didn't realize Ice-T required SDX anyway - I must have missed a meeting.

[Marius]

ICET does not require SDX, but since it uses XE ram, and it uses hard coded bytes it is not compatible with MyBIOS or any other OS that lives in OS-RAM. (those bankswitch values like #$E3,#$E7,#$EB, #$EF all set Bit 0 of PORTB to 1, which kills MyBIOS).

 

To make it MyBIOS Compatible I changed these values into #$E2, #$E6, #$EA and #$EE.

 

Seems to work.

[flashjazzcat]

Ah - I understand. Ice-T should really leave the OS ROM select bit alone, ideally, unless it's actually putting its own code and data under the OS.

Edited April 12, 2014 by flashjazzcat

[itaych]

Today I have 'hacked' ICET 2.80 alpha 6. [...]

To make it MyBIOS Compatible I changed these values into #$E2, #$E6, #$EA and #$EE. [...]

I don't know whether author of ICET want me to release it, or not, so I do not post it here.

There are about 75 instances where these values occur in the code for setting PORTB. And then there are places where these values may be used for some other random reason. There is virtually no way for you to tell the difference without disassembling everything and you will probably miss something and break some feature. So, thanks for not posting it

 

I didn't realize Ice-T required SDX anyway - I must have missed a meeting.

Of course not. Ice-T was developed under MyDOS. SDX support was added only recently, when emulators allowed me to test against it and users requested it.

 

Ah - I understand. Ice-T should really leave the OS ROM select bit alone, ideally, unless it's actually putting its own code and data under the OS.

Ice-T doesn't do anything with the RAM under the OS, because (a) the ROM OS is still needed for handling I/O and interrupts so this would have made things more complicated than I like, (b) it would have broken all sorts of system upgrades that use this RAM.

 

I'm surprised however that this specific problem has remained unreported for the 20 years that Ice-T has been available! I'll add it to the todo list.

[Marius]

Hehe ok... I won't post it. Although -so far- everything seems to run fine.

[_The Doctor__]

That explains it a little, I was using it with SDX & MyIDE. maybe it had more to do with that as ProWizard also had to modify for use with MyBios.... MyDos seems to work fine... hope thats not confusing.

[UKRetrogamer]

I'm trying to track down the most up-to-date version of Ice-T.

 

I've visited a couple of threads here [each with multiple pages] and I STILL don't know which revision is current.

 

At the time of my posting, the latest version APPEARS to be 2.8 alpha 6?

 

Is it REALLY necessary to open a new thread for every minor point release?

 

Surely, it would make more sense to have a SINGLE thread and have a link within the first post UPDATED with the most recent revision.

(Unless the forum policies prevent this?)

[itaych]

Is it REALLY necessary to open a new thread for every minor point release?

What you call a "minor" release is actually the result of many months of work responding to user feedback, fixing bugs, refactoring code, adding features and updating documentation. So yes, I think it is fair to announce what I consider a milestone in a new thread each time - I doubt anyone would notice it otherwise, I don't think four threads in two years is unreasonable, and I can't edit a post once it's been replied to anyway. Now, when I release a version with new features that are not done yet, I name them 'alpha' or 'beta' (depending on how well the new features are baked, in my opinion) and post them in the thread belonging to the latest version. So, prerelease versions of 2.76 appeared in the 2.75 thread and prerelease versions of 2.8 (which has not been released and is in a bit of a freeze at the moment) appear in this thread.

 

Sorry if this system confuses you but no one has complained so far and I think it's a pretty straightforward system, and I'm not the only one using it (see the Altirra 2.40 thread, containing dozens of 2.50 alpha versions as another example).

 

In general for the latest 'stable' fully documented release simply grab the file from the first message of the thread with the highest version number (2.76 as of today). Then browse through the thread for the latest alpha/beta if you want to try the latest features. 2.8 alpha 6 is indeed the latest.

[Marius]

I love ICE-T ... It's one of those programs that shows (to the outside world) how powerful the a8 is.

 

I can understand the problem of UKRetrogamer, but since I follow this project from the start, I have no problems with all the different topics.

[Britishcar]

Is Ice-T failing on an Incognito 800? I can get my .ATR (DOS 2.5, AUTORUN.SYS, ICET.XEX) on the Atari800MacX emulator but on my Incognito (in XL/XE 1088K RAMBO mode) it fails to a black screen and a non-responsive keyboard. The hardware is an Incognito 800, an 850 and a Hayes Optima 2400. The 800/850/Hayes work with 850 Express and dial out fine, connect, etc.

 

Any suggestions?

 

Thank you!