itaych

Ok. Here is one more beta. With this version the RS232.COM will only be loaded (and suggested, if missing) under MyDOS. I think it's ready for release; if anyone thinks otherwise please let me know. icet2.74BETA3.xex

Ahh, but conventionality belongs to yesterday... at least on MyDOS, where this trick works. No luck with Sparta though, setting icaux2 to 128 indeed causes the R: handler code not to run, but does not prevent the original file load from being lost. That is, even if I JSR to the RS232 init routine then RTS, it drops back to DOS and doesn't resume loading Ice-T. I am simply going to disable this feature in Sparta and recommend the batch file solution unless there's anything I missed. And no I am not going to implement a binary file loader, it's reinventing the wheel and not worth the effort.

This is what I do, and as you can see it works - the only problem being that DOS forgets that it was in the middle of loading Ice-T. One thing I will try is setting 128 in aux2, doing the JSR to the R: handler myself, and hoping that doesn't break the Ice-T load process.

Fox-1: In MyDOS, the aux1 value determines whether it'll just load or also init and/or run the binary code. In Sparta it seems that the only accepted value for aux1 is 4 (both init and run) and other values just cause an error. If you could find a way to load without running it might solve the problem - I'd JSR to the init address from within my code and hope that Sparta will resume loading Ice-T afterwards.

When you load Ice-T, the init code is loaded into memory at $3000, then the init address is written to $2e2. Within that code (other than the memory checks) is the code to load RS232.COM. What it basically does in MyDOS is call XIO command 39 to binary load the file RS232.COM. After the call returns, if an R: device is indeed found, the code performs an RTS and MyDOS loads in the rest of Ice-T. In SpartaDOS the only difference is that I use command 40 - however, this is from information received many years ago and I have no documentation of this command. Anyway, the command works, the R: device is loaded, but then the RTS returns to the DOS prompt - basically DOS forgets that it was in the middle of loading Ice-T. I am either misusing command 40, or perhaps the fact that I use channel #3 for this conflicts with Sparta in some way, or perhaps this scheme just isn't possible in Sparta, in which case we're screwed. If you have any ideas on how to fix this or a pointer to the relevant doc I'd appreciate it.

In the scenario where Ice-T loads the RS232 but returns to the command line, is there any text output at all? What about the RVERTER handler? This is the one I used when I developed Ice-T. It will load an R: handler regardless of hardware so you can try it out without anything special connected. Can you try this with MyDOS?

phaeron, the R: in Altirra-2.10-test24 seems to be not working. I can't see an 'R' entry in HATABS... Also, I see this in the changelog: "Fixed incompatibility with Ice-T XE and the R: handler's STATUS handler". Can you elaborate?

Thanks. I'm happy that the RT8 is working properly. I did check that ICET.DAT (yes that's what I meant) was being loaded/written properly but I wanted confirmation. Try the following: Disable the BlackBox R:. From the DOS prompt try directly loading each of the R: handlers. They should have no noticeable effect but some may hang the machine for a couple of seconds as they try to talk to some hardware, others may display a message. Choose one that has some observable effect. Rename that one to RS232.COM and load Ice-T. You should see the same thing occur while Ice-T is loading (after which it will say there is no R: and exit to DOS). I tried this with the ATARI850 handler, it caused a pause and a long "thbthbthbthbt" sound, and when I renamed it to RS232.COM I got the same sound when loading Ice-T under SpartaDOS. I'd like to know that this works for you too. Make sure RS232.COM is located in the current path when trying this.

rdea6 and fox-1: I want to stay away from SpartaDOS-specific code for RT8 support, as I want this to work under any DOS. phaeron: Indeed, this was my hunch and fox-1's results and your reply confirmed it - I need to mask off the upper nybble, this will probably solve the problem. The attached version should do the trick. Please let me know if it works now. Also please confirm that the other fixes work (is ICET.CFG now loaded and saved to the correct location? Was I right that RS232.COM was never being auto-loaded under Sparta and is now loaded? If your HW doesn't need an RS232 handler just try the ATARI850 one. It should have no effect but you will notice the delay and I/O sound as it attempts to load.) icet2.74BETA2.xex

fox-1, please boot your machine in BASIC with the RT8 installed and no DOS. Type the following: 10 POKE 54712,0 20 ? PEEK(54712),PEEK(54712) 30 GOTO 10 Run it. What do you see? You're supposed to see a real-time seconds counter (tens digit 0-5 and ones digit 0-9, separated by a tab). At least that's what I see on Altirra...

If the seconds start at B3, does the B count up every 10 seconds (and change to C, then D, etc.)? The minutes will only change if there is a rollback from 59 to 00 so the fact that they don't change makes sense. Also setting the time doesn't touch the seconds in RT8 mode so that makes sense too. Is this a regression from 2.73 or do you see the same behavior there? What if you run under MyDOS (just boot the 2.73 ATR, but try both executable versions)? Thanks.

I hear the keyclick, a bird, and some noise which is probably interference from the serial port electronics picked up by the audio output or the TV amplifier. You cannot seriously be thinking that this is a feature? Does this noise exist in some Ice-T version and not in another?

Sound?

Ok, here is a beta of 2.74. Please test it with your various platforms and DOSes and let me know what you find. The auto-loading of RS232.COM was never working on SpartaDOS, fixed. It still doesn't work with Atari DOS 2.0 because there is no load and execute binary XIO command. (I have no solution for this. Other than that DOS 2.0 seems to work fine.) The configuration file ICET.DAT, RS232.COM and the Mini-DOS current path now all work with the current path as specified in DOS. (Say, requesting a disk directory in Ice-T should always show the directory of the current path, etc.) SD3.x: TDLINE will automatically be disabled. (I have no solution for SDX, TDLINE ruins the display and I can't kill it.) SDX: If you forget to load Ice-T with "X" a warning will be shown. Enjoy icet2.74BETA.xex

Just for fun, here are the 'phantom' directory lists found on these disk images. First of all, on my original disk, we have: * DOS SYS 064 * SOLITARE 087 * PINBALL 045 * ATARI 825 034 * ATARIML 128 * FRED 060 * AUTO SYS 001 * WIPE 001 <cut> x xxGWUMP 038 * GUNINST 030 * GUNNER 038 * BIOINST 042 * BIORYTHM 038 * STOCKS 074 * ZAxxxxxxxxxxxxx (hmm, gunner, biorhythm, stocks.. what were they planning at Atari anyway?) The DOS 1.0 disk from 'ataristuff' contains this list: xxxxxx DUP 007 * STARRAID 070 * STAR 009 * TELEMODMBAS 048 * MICOM BAS 042 <cut> * OUT HOW 037 * FAST 009 * GAMMON 056 * CHK 009 * CHECKERS 060 * CHS 009 * CHESS 060 * MISSILE COM 070 * MCxxxxxxxxxxxxx ..note that the latter part of this list an exact excerpt (file names, sizes and even order are all the same) from the list of files on my disk.

Ok. Just for the heck of it I decided that I want to repair the original disk image rather than present a fixed version which is actually a fresh disk with the files copied over. So, here are the results of that effort. DOS.SYS repaired by comparing to a working version - these were basically several flipped bits. Corrupt (error-164) files fixed by finding the offending sectors and manually repairing the last 3 bytes. (Side note: Atari DOS 1.0 has its own format, documentation of which is nowhere to be found. But it's fairly similar to DOS 2.0 and easy to figure out.) Interestingly I can find no explanation to the corruptions I've seen here, these aren't a few wrong bits. Diff with the original if you can be bothered. That's it. Hope you enjoy this historically accurate restoration of an internal Atari (or pirate?) game compilation from 1981 or so Disk with old games - v2.zip

Suppose Ice-T was started from "D2:>DATACOM>ICET>" would writing to "D2:ICET.CFG" be enough to ensure that the cfg file is in the same directory? Or would I have to specify the complete path? In the latter case your code wouldn't do that, so I'm trying to make sure we're on the same page.

I access the configuration file using 'D:'. If it works for everything except SD 3 then SD 3 is broken; as it appears now this is not a trivial workaround and so it's unlikely that I'm going to bother with this.

Sorry, this is too complicated. I am automatically disabling TD for SD3, but SDX users will have to pay attention to what they're doing. I assume Ice-T isn't the only program that TD breaks. As for the pathname (just 28 bytes??) I will look into it but I really don't like how SD breaks the simple concept of "D: is the current path".

The fact that a similar directory listing appears as incidental data in a completely unrelated distribution of DOS, along with the different origin addresses as you point out, makes me think this was indeed some Atari internal release. Glad somebody finds this interesting

Hi all, In the early 80's my older brother copied various disks from his friends. One particular disk had always bothered me because it just never would work properly even though it had no sector errors. Since the games on it were quite old even at the time (Asteroids, Star Raiders etc.) and mostly available elsewhere, the disk basically gathered dust and was rarely touched. When I moved to ATR images, however, I took care to keep a sector copy of it, in case I would one day get around to figuring out what was wrong with it. Well, the day has come and I've finished the cleanup. In the included archive are the original and fixed disk images. The changes were: The disk had a bootable DOS 1.0, but DOS.SYS was corrupted causing all kinds of problems. This was fixed by downloading a fresh copy. (The 'fixed' image is the downloaded copy of DOS 1.0, to which I copied all the other files.) Two of the game binary files (GAMMON and CHECKERS) were unloadable (Error 164). Fixed by recovering the files, which were thankfully not fragmented, directly from the disk image. So what we have here is a disk which autoruns a BASIC-based menu which loads the games. The games are: Asteroids Space Invaders Missile Command Star Raiders Outlaw/Howitzer Avalanche Fastgammon Checker King Micro Chess To run this disk, you must boot as Atari 800 OS-A (not B!) with a BASIC ROM (any version) inserted. Now, these games are all available from other sources. Why do I bother the community with this disk image? The reason I found it especially curious was that I happened to look at the DOS 1.0 disk image I downloaded from a completely unrelated source (http://mousenet.radt.../ataristuff.htm) and noticed what appears to be the garbled remains of a disk directory at offset 0x0cf9 of the file. This is within DOS.SYS. The really weird thing I saw was that most of the files in that directory list relic are the same as on this disk! This could mean that this disk image has its roots not in the pirate community but within early 80's Atari Inc. Strangely enough, looking at the same place in my original disk, I can see names of different files even though the DOS.SYS itself is dated the same on both versions. I'd love to hear other people's thoughts on how this may have happened. Here are a few other notes about this collection: The binary files are in a format I'm not familiar with - the first two bytes are not FF FF as usual but 84 09. (Perhaps this is a DOS 1.0 convention?) The files will load, but NOT run, when loaded from DOS as they do not specify a run address. When loading Space Invaders through the menu, a cheat option is offered (number of lives, and a few others). You can quit the menu and load WIPE.DUP or LOADER.BAS, these are two other loaders. They have less games or list the same games but have trouble loading them. Missile Command is slightly different from the circulating version (the title text is missing, perhaps there are other differences). Some of the games use OS-A specific vectors and are different from the circulating versions, which have been fixed to use OS-B vectors. I hope this is in some way interesting to anyone... and if not, thanks for reading Disk with old games.zip

Checked with SD3.3, same problem. "?DIR" only returns directory, not disk number. Your code works under SD3.2 but crashes SDX... :/

SpartaDOS 3.2g has a weird behavior, where Ice-T tries to read/write the configuration file "D:ICET.DAT" but the file actually accessed is in the home directory of drive 1, regardless of the "current" path (disk and directory). I haven't seen this behavior in any other DOS including SDX. However the SDX I used is a recent version (4.45), perhaps this is a recent bug fix and MEtalGuy66 is using a version of SDX before the fix?

Fox-1: is there a clever way to detect that TDLINE is running, so I can abort Ice-T's load telling the user to disable it?

Tested and seen no problems. I don't know of more than one version of 2.72, nor why any of them would behave differently from one another in this regard. If you mean that these peripherals contain their own R: handler like the 850, they still need a tiny disk based handler (just like the 850 does) that requests the handler from the device. In that case you can use the 850's file, supplied with the distribution. Or did you mean something else?