Info-Atari16 Digest Tuesday, August 22, 1989 Volume 89 : Issue 404 This weeks Editor: Bill Westfield Today's Topics: Re: Archive bit ICD host adapter problems with SONY drive Re: Multitasking on the ST New Atari 68030 Machines Re: Screen flicker, top st1040s in Pgh? Mac emulation Re: Multitasking on the ST Re: user base ST market cartridge port ---------------------------------------------------------------------- Date: 14 Aug 89 23:21:11 GMT From: imagen!atari!towns@ucbvax.Berkeley.EDU (John Townsend) Subject: Re: Archive bit To: info-atari16@score.stanford.edu in article <8908091359.AA08065@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) says: > > > Bit 5 of a file mode is the archive bit. This is to do with backing up files. > When a file is backed up it's archive bit is set. When it is next written to > the bit is cleared. From this senario the disk back up program can tell whether > a file has been modified since the last back up and if so back up the file > otherwise leave it. This enables an incremental backup to be performed i.e. > back up your hard disk totally every month, and backup just the files that have > changed every week. Unfortunatley this procedure doesn't work on the old TOSes > (or so I'm informed) TOS 1.4 is said to fix this. > I have seen plenty of files on my disks with this bit set. You may be running > a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85 > i.e. 20th November for you in the US who don't put the date in ascending or > descending order of significance (make your minds up!) > You have it backwards. In TOS 1.4, the bit is set when a file is created or modified. The backup program should clear it after backing up the file. -- John Townsend Atari Corp. ------------------------------ Date: Tue, 15 Aug 89 09:22 GMT From: IKT7%CZHETH5A.BITNET@Forsythe.Stanford.EDU Subject: ICD host adapter problems with SONY drive To: info-atari16@score.stanford.edu X-Original-To: info-atari16@score.stanford.edu, IKT7 Hi folks We are seeking help on connecting a SONY SRD2040Z harddisk via a ICD host adapter to an ATARI ST as we are experiencing some problems. First of all we would like to mention that we connected this drive to a MAC SE. The SONY hard disk could be formatted and installed without any problem. This gives us the impression that not the drive is faulty as it behaved like a SCSI drive should. It may be of some interest to know that APPLE has a contract with SONY for a large amount of these drives. Observing the signals on the SCSI bus with a logic analyzer we have found out that the request/acknowledge handshaking doesn't work: - The first ACK going true coincides with the first REQ while no valid data is on the bus. From then on the handshaking doesn't work so that the whole command sequence is not closed in right manner. - We have tried all available drivers including the SYQUEST 555 (similar SCSI controller) to format our drive. None of them complies to our SONY drive. Does anybody on the net have any advice on what else to try? Any hint will be appreciated. Thanks a lot in advance for your help! Hansruedi Andrist ------------------------------ Date: 15 Aug 89 04:18:08 GMT From: cbmvax!joe@uunet.uu.net (Joe O'Hara - QA) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <29201@pbhya.PacBell.COM> dbsuther@PacBell.COM (Daniel B. Suthers) writes: >After reading this a question popped into my head. If you are downloading in >the back ground (it seems the most popular multi-task task) and running a >action game in the foreground, do you set the download process to the >highest priority to avoid losing data or do you just put up with longer >download times and connect times so your joy-stick will be responsive? Believe it or not, the answer is neither. The actual I/O is processed by device drivers, in these examples the serial device and the gameport device. The drivers have higher-than-standard priorities. In the download situation, received characters are stored in a buffer until the application program gains control and "reads" them (burst them into the program). The joy-stick action results in events which are passed to the game program as messages. Consequently, the game program could be given higher priority if you wished without a noticeable degradation of the teleprocessing task. The serial device buffer can range from 512 - 16,000 bytes (user controlled). -- ======================================================================== Joe O'Hara || Comments represent my own opinions, Commodore Electronics Ltd || not my employers. Any similarity to Software QA || to any other opinions, living or dead, || is purely coincidental. ------------------------------ Date: 14 Aug 89 18:13:39 GMT From: astroatc!nicmad!madnix!curtis@speedy.wisc.edu (Curt Chambers) Subject: New Atari 68030 Machines To: info-atari16@score.stanford.edu Just caught a news bit in InfoWorld concerning "new" Atari 68030 machines w/VME slots that will run Atari Unix Sys. V. Is this true? Cringely's article went on to say that they would be released on the 25th of August. Anybody know anything else? Curt Chambers ------------------------------ Date: 15 Aug 89 08:48:57 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Screen flicker, top To: info-atari16@score.stanford.edu In article <15286@duke.cs.duke.edu> currier@romeo.cs.duke.edu (Bob Currier - DCAC Network Comm. Specialist) writes: |Greetings, | |This weekend, while noodling around with animation, I came across a |most puzzling phenomena. My graphics displayed fine while on the |lower part of the screen (I am using a monochrome 1040), but when |my little critters got about 30 or 40 pixels from the top they |started to get a bad case of the flickers. I was using Vsync() to |control flicker, and it seemed to work well, except for this |twilight zone. | |I pulled my hair out for a couple of hours on this one, dug thru all |my books, and finally, at about 1 a.m., in the premier issue of START, |found a comment in an article about al graphics that went like this: | |"...vsync, but you will still see flicker near the top of the screen. This |is a problem that can only be dealt with by very complex multiple screen |flipping techniques..." | |So, does anyone know of this problem? What causes it? And, Virginia, how |can I eliminate it? My name is not Virginia, Bob, but I still think I can make some sensible remarks about this one. Flicker is caused by updating the physical screen, that is: writing to the physical screen in some way. Most often one erases part of the screen, then draws on the erased part; at the same time this part of the screen is being read by the video stuff. Most animations use a separate screen to draw in, then as the picture is complete, swap the screens. All GEMDOS, (X)BIOS and GEM functions that deal with graphics (including characters) are being drawn on the logical screen (a chunk of 30000 bytes of memory pointed to by a system vector, 0x44e if my memory is OK 8-). The physical screen location is determined in two I/O addresses (it always starts on a 256 byte boundary). For reading the screen 3 I/O addresses are being used; they correspond to registers in the shifter (an ST custom chip for the video stuff). After each VBL these addresses are reinitialized from the two 'physical screen start' I/O addresses (this is also the reason that, though you could alter the physical screen start between VBL's (the XBIOS function Setscreen() does this), it can only take effect at the moment of the next VBL (the 3 I/O addresses for reading the screen are read-only). The Vsync() is not totally unuseful: it synchronizes your software with the VBL, that is, you know that after a Vsync() statement the shifter reads at the top of the screen (so at that moment avoid updates there). You could do updates to the lower part of the screen, or use a timing loop so you know the shifter already has had the upper part. Alternatively you could read the 3 I/O addresses (in supervisor mode, of course) to determine where the shifter is currently reading; in this case you don't need the Vsync(), which really can speed things up (I know, I did this myself). The most commonly used technique is to use two separate screens, one as the physical screen, one as the logical (as mentioned above), draw your stuff on the logical one, then use Setscreen to swap the screens. Now you must do a Vsync() before any new updates of the (new) logical screen, because remember until VBL it is still the old physical screen, which is being read by the shifter. This technique is guaranteed to be flicker-free, and, as opposed to what was possibly mentioned in START, is not difficult at all. A third technique is a somewhat more complicated variant of the second one. Its main idea is to use several screens (more than two) to avoid using Vsync(), thus gaining in speed. You use the screens alternatively: screen1 physical, screen2 logical screen2 physical, screen3 logical etc. screenn physical, screen1 logical screen1 physical, screen2 logical etc. The number of screens to use depends on the speed with which you can draw a new image on the logical screen. Since a physical screen remains fixed for at least one VBL period, doing the cycle of n screens must take at least one VBL. Since it doesn't make sense to swap screens a lot during a VBL period (only the last one takes effect) and it DOES take some time in general to redraw your screen, a useful number of screens is 3. Hope this helps - if you need the exact location of the I/O addresses I can look it up for you. Leo. ------------------------------ Date: 15 Aug 89 13:57:54 GMT From: ak2w+@andrew.cmu.edu (Alan Kennedy) Subject: st1040s in Pgh? To: info-atari16@score.stanford.edu Does anyone know how to buy a 1040 in Pittsburgh? I've been phoning one shop At Your Service, but they never answer their phone. Is the best thing to do to order by mail from NY? ------------------------------ Date: 14 Aug 89 09:43:16 GMT From: mcvax!cernvax!unizh!draxler@uunet.uu.net (draxler) Subject: Mac emulation To: info-atari16@score.stanford.edu Hi there, I am new to the net, so please excuse my question if it has been answered already... Are there any legal problems in using a Macintosh emulator (such as Aladin or others)? What I need is a quoteable source, no rumours! Maybe the legal situation in different countries is different.. So what is it like in Germany and in Switzerland? If there are no such problems, which emulator is best? Which programs are known to work, which programs won't work? How do I get my Mac data and applications to my ST? Can I drive my Laser printer from the Mac software? Can I read and write to Mac disks? Can I use my Atari Harddisk? Yes, load'sa questions... Reply by e-mail to Christoph Draxler: draxler@ifi.unizh.ch ------------------------------ Date: 15 Aug 89 10:58:43 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <483@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes: |In article <1071@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |[] | |This point is well taken, but does not negate the point that process protection |is desirable (in my mind). I would be the last one to deny that; what I meant was that a non-multitasking machine like the ST can benefit from process protection too. |> My point |>is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE |>EXCELLENT SYSTEM. That safe system (which undoubtedly will have a |>notion of privileges, users) is what you should start with in the first |>place. |> | |An MMU can protect pages of memory that the system considers special. The |system vectors could be marked as un-writable by user level processes. An |attempt to modify the protected pages could be trapped and prevented. Any usable system will have to have a way to install (re-install) system vectors, switch to supervisor mode etc. In the current TOS each user program can do that. What I meant was that the system should have a notion of users with special privileges (root) so that one cannot inadvertently switch to kernel mode and do strange things. If you want to do something special, OK become root and then do your stuff (very careful), then go back being a normal user. This should be a hard fact in the system; it could prevent a lot of viruses. |>B.T.W. what do you do when a thunderstorm is coming up, but your |>raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? |> | |Well, here in Sunny California (tm) we don't get many of those! :) :) :) Here in Rainy Holland (B.V.) we usually get them after a few sunny days (I shouldn't complain however - we had the best summer in years). |>|I'm all for system robustness for ANY system. My point is that when you |>|introduce multitasking, memory protection is more important due to the |>|potential to disrupt other processes. |> |>I heard this one before and I still won't believe it, unless a proper |>argument is given. |> | |So I assume (if you were using a multi-tasking system) that you would prefer |NOT to have process protection? I do not see the logic in this. No, what I meant was that I would prefer to have memory protection in both cases. I don't see a reason why it should be more important in the multitasking case. You can have lots of vulnerable processes in the other case as well. |Yes, VM is nice. In my day-to-day Amiga experience I do not run out of memory |much. I DO experience agonizing crashes which kill all my processes. From |this experience I developed the priority of process protection being more |important. If VM were available, I'm sure I would enjoy it and make use of it. >From what I hear in this group, a lot of people DO run out of memory - even the ones with > 1 M memory. Accessories, TSR's, RAMdisks, disk caches all grab a (not to be ignored) constant part of your memory. Now try and run something like gcc (a known memory hog). Lots of people expanded their memory already. But IMHO the most important use for VM is not protection, not paging in additional memory when needed, but ... the processes being position- independent! Try to implement the UNIX fork() call, you know what I mean (also relocation becomes unnecessary, but that is a minor issue). | |Thank you for this enjoyable discussion. I hope it can continue on the |amiable and informative level that has been maintained all along. Looking |forward to your reply. Thank you too, me too, me too (in that order). Cheers, Leo. P.S. One noticeable difference between ordinary conversations and Usenet discussions is that the former resembles multitasking, the latter something like coroutines 8-). ------------------------------ Date: 15 Aug 89 16:02:44 GMT From: obryan@gumby.wisc.edu (Mark O'Bryan) Subject: Re: user base To: info-atari16@score.stanford.edu In article <747@greens.UUCP>, allegro@sunpix.UUCP ( SunVis) writes: > > Does anyone have an idea how many ST's & MEGA's have been sold in N.A. > and Europe as well as Asia ect. According to Sam Tramiel in a recent issue of STart magazine, there are almost 1.5 million worldwide, and almost 200,000 in the U.S. I don't know how close "almost" means, but this is what he reported. Beyond just the raw numbers, however, you'll want to consider what seg- ment of the potential market is going to be interested in your product. This is almost never close to 100%, usually much, much less. -- Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu Western Michigan University Kalamazoo, MI 49008 ------------------------------ Date: 15 Aug 89 16:00:13 GMT From: blake!bissiri@beaver.cs.washington.edu (Moja Fritzah) Subject: ST market To: info-atari16@score.stanford.edu I ran out last night to pick up the infoworld issue describing the TT. I stood back a bit from the large array of computer journals, reading the covers of most. The Atari journals spotlighted "Bingo; Calorie Counter; Games and Entertainment..." ATARI can't be blamed entirely for creating the "game machine" sobriquet. ------------------------------ Date: 15 Aug 89 15:50:39 GMT From: blake!bissiri@beaver.cs.washington.edu (Moja Fritzah) Subject: cartridge port To: info-atari16@score.stanford.edu NOTATOR requires a dongle in the cartridge port for copy protection. I would like to purchase the GCR... as well as a few other products requiring use of the cartridge port. I know this subject has been of issue for as long as the machine has been in existence. But what is the latest development on the expansion of the port? C-Lab, the makers of NOTATOR, have come up with a product that allows 3 dongles to hang off the cartridge port. They are asking $349.00 !!! I think this is perfectly unreasonable. Anybody disagree? -kevin bissiri@blake.acs.washington.edu ------------------------------ End of Info-Atari16 Digest ************************** -------