Info-Atari16 Digest Fri, 16 Aug 91 Volume 91 : Issue 434 Today's Topics: Atari CD-ROM? (4 msgs) Clearing space on a hard disk Dialog Boxes (2 msgs) Help for an old, handicapped ST? Is BART down? Puting a pixel to screen (3 msgs) Spectre GCR Turbo St Using a big hard disk (3 msgs) Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 12 Aug 91 08:56:35 GMT From: uhccux!uhunix1.uhcc.Hawaii.Edu!kiki@ames.arpa (Jack W. Wine) Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu In article <1896@mwca.UUCP> bill@mwca.UUCP (Bill Sheppard) writes: >CD-I players are based on the 68340 chip, a derivative of the 68020, and >CD-RTOS, a specialized version of OS-9. Since the STE (or TT) can both >run OS-9, it wouldn't be too much of a stretch for either machine to be >CD-I compatible, though it might take some additional hardware (on a VME >card?) to support the full motion video. I hope more information can be given on CD-RTOS. A Magnavox brochure describes it as providing a user shell with the following functions: o Auto-start CD-I o System entry o Load Application o Display Time/Date o CD-DA auto-start/repeat/shuffle o Info (calls up function info screen) o Dim screen Mating Microware's CD-RTOS with Motorola's M68340 super-muscular micro- controller sounds awesomely devastating. Supposedly, one series of CD-I machines will use a Signetics 68070 which is something like a 68K with integrated DMA, timer and I/O support. I don't know much about the M68340, but found this info about a close relation, the M68332: "The 68332 is the first member of Motorola's revolutionary new family of highly integrated, high-performance 32-bit devices designed to meet the ever-increasing demands of embedded-control functions. The 68332 is the world's most powerful microcontroller with a high-performance 32-bit CPU core. The CPU is surrounded by 'smart' peripherals, including a powerful RISC-like TPU (Time Processor Unit), to reduce CPU overhead. The result is the ultimate in system performance. Just as the human brain has two hemispheres, one for sequential logical operations and one for simultaneous creative operations, the 332's CPU and TPU perform as two powerful CPUs on one chip: one to process numbers and one to process time. For many appli- cations, our two-CPU approach is more powerful than any feasible single-CPU alternative. The 68332 is truly the best of both the microcontroller and micro- processor worlds. Its high degree of system integration eases system design and slashes the total chip count. Functional modules of the 68332 include: o A 32-bit CPU fully compatible with the 68K Family software. o A RISC-like high performance TPU which processes 16 channels of time-based event functions independent of CPU intervention. o The TPU has a prioritized scheduler, RAM and ROM to help manage sophisticated time-related control functions. o A Queued Serial Module containing two separate serial interfaces, one synchronous (SPI) and one asynchronous (SCI), for easy attachment of specialized, off-chip peripherals without using the CPU as an interface. o 2KB of fast static RAM with standby capability for low-power applications and battery backed-up operation. o A System Integration Module (SIM) containing programmable chip selects, system clock, periodic interrupt, test/emul- ation, and system protection features. Additional members of the 300 Family will be introduced that will provide a variety of peripherals and discrete logic functions com- bined with a powerful 32-bit CPU. Available modules will include ROM, DMA, A/D, EEPROM and many others." The M68340 would probably have the integrated DMA and maybe the ROM and EEPROM. Its clock speed isn't known, but probably is 16-20 Mhz. Jack ------------------------------ Date: 12 Aug 91 09:13:30 GMT From: uhccux!uhunix1.uhcc.Hawaii.Edu!kiki@ames.arpa (Jack W. Wine) Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu In article <8159@tekgen.BV.TEK.COM> boblu@tekgen.BV.TEK.COM (Robert Luneski) writes: >Before you hold your breath for the introduction of CD-I, consider that >Phillips has been promising it's imminent introduction for the last three >years. Sound like any company we know? Nah.... :-) There is every indication that consumer CD-I systems will be available in the coming months. Sony sponsors a segment on a daily radio show which promotes and provides information about CD devices. For the entire week last week, the features of CD-I were announced. The announcer didn't use generalities, but provided the actual specs for a typical system. Some of the announced details of the broad range of video mode colors: DYUV 16 million, RGB 32,768, CLUT8 256, CLUT7/RL7 128 and RL3 with 8. The video resolution is 384/768 (horizontal), 240/480 (vertical). Philips/Magnavox recently started to provide brochures to anyone interested; just contact them at: One Philips Drive, PO BOX 14810, Knoxville. TN 37914. Phone number is (615) 521-3230. In Europe: Philips Interactive Media Systems, PO BOX 80002, 5600 JB Eindhoven The Netherlands. Ask for the CD-I 910 and 602 systems' brochures. Jack ------------------------------ Date: 12 Aug 91 09:43:35 GMT From: uhccux!uhunix1.uhcc.Hawaii.Edu!kiki@ames.arpa (Jack W. Wine) Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu In article gjh@hplb.hpl.hp.com (Graham Higgins) writes: > >_Both_ UK ST mags (STUser & STFormat) are reporting AtariUK's intentions to >make available a CD-I peripheral for the ST/TT (one mag reports the spec). They >warn the drooling reader that purchase availability is likely to be >early/mid-92 with a guestimated price tag of 400 pounds sterling. > >Let's hope that Atari's marketing management make a better job of CD-I than >they did with CD-ROM. That sounds like a good development! In the US, the actual price would be around $500, I think, because hardware seems to be cheaper here. That would put the Atari CD-I in the range of regular CD-ROM drives, so instead of being limited to a niche market, it could carve out something much bigger. Another Atari product mentioned in the online mags was a super-graphics engine based on a RISC processor that connected to the ST DMA port. It was supposed to be designed in England, so I hope some UK net readers can keep everyone abrest of its development and availability. Thanks, Jack ------------------------------ Date: 12 Aug 91 11:54:53 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wupost!psuvax1!psuvm !dearn!dmswwu1c!onm07@arizona.edu Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu In article <3579@odin.cs.hw.ac.uk>, neil@cs.hw.ac.uk (Neil Forsyth) says: >In the same purile rag, there is mention that Atari are to provide TOS 2.x >as 512K ROM upgrade for all machines including STFM's. They do not say who >their 'sources' are but it wasn't Atari. I view this piece of reporting as >pure nonsense since we know that the Mega STE ROM is 256K and will take >TOS 2.x (Lars has done it!) but the STFM has only 192K of ROM address space. >Upgrading an STFM would involve some serious hacking to the machine, including >a new GLUE chip, and I doubt that Atari are going to do that. > I know of at least two groups of german developers, who have this thing up and running. I think we will here more about that after the Atari fair in Duesseldorf (Aug 23-25). ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________ ------------------------------ Date: 12 Aug 91 10:37:11 GMT From: waikato.ac.nz!comp.vuw.ac.nz!actrix!Alex.Valdez@decwrl.dec.com (Alex Valdez) Subject: Clearing space on a hard disk To: Info-Atari16@naucse.cse.nau.edu Why not just backup one's hard disk (by files, not an image copy), do a low-level format, and restore? And you get a clean unfragmented drive in the process as well. -- ================================Alex Valdez============================= "Alas sais na naman, oras ng pagdidili-dili... Isaisip ang mabuti, ang masama'y iwaksi..." ------------------------------ Date: 12 Aug 91 10:46:08 GMT From: waikato.ac.nz!comp.vuw.ac.nz!actrix!Alex.Valdez@decwrl.dec.com (Alex Valdez) Subject: Dialog Boxes To: Info-Atari16@naucse.cse.nau.edu In article <1991Aug8.011546.2457@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: > > One thing I'm curious about right now: Is there any reason > to open the "physical workstation" if you aren't going to be using > GDOS calls? I haven't found anything in the Lattice C docs telling > me when and where you use 'v_opnwk()' as opposed to 'v_opnvwk()' > except that you can *only* use 'v_opnwk()' if GDOS is present. > But everything I've done (except the 'vro_cpyfm() call) has been > working so far without my using 'v_opnwk()' at all. > > > > -- > Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 > lsuc!jimomura > Byte Information eXchange: jimomura You cannot use v_opnwk() for the screen, as it has already been done by AES itself. With GDOS present, you can (and must) use v_opnwk() to open other physical devices such as a printer. -- ================================Alex Valdez============================= "Alas sais na naman, oras ng pagdidili-dili... Isaisip ang mabuti, ang masama'y iwaksi..." ------------------------------ Date: 12 Aug 91 11:55:16 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!wupost!psuvax1!p suvm!dearn!dmswwu1c!onm07@arizona.edu Subject: Dialog Boxes To: Info-Atari16@naucse.cse.nau.edu In article <1991Aug10.122208.16653@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura) says: > So that would mean that "v_opnwk()" in Lattice C is an entirely >bogus command! Neato! :-) > And wrong. Of course there are other things than screen workstations. Think about printers, metafile drivers, postscript drivers or plotter drivers. >Conclusion #1: We need some new books put out on GEM/TOS programming. >Hopefully, some of those books will be the manuals that come with >these compilers. > >Conclusion #2: (Ahem. I have another conclusion but I think I will >not currently state it in public. :-) > >Supposition: "v_opnwk()" is probably necessary for some GDOS commands. >Probably I'll find this out if I ever actually use a GDOS related command. >That's fair enough. In the mean time, I won't worry about it and I >won't use it. >-- >Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 >lsuc!jimomura >Byte Information eXchange: jimomura ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________ ------------------------------ Date: 12 Aug 91 02:50:06 GMT From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard) Subject: Help for an old, handicapped ST? To: Info-Atari16@naucse.cse.nau.edu In article <37911@mimsy.umd.edu> bane@tove.cs.umd.edu (John R. Bane) writes: > My ancient and revered 520 has a problem. Its serial port has partially > died; it can send but not receive characters. To give you an idea of > how old this machine is, it started out with a single-sided external floppy. > It now has an external double-sided floppy, an 80 meg hard drive, and a > 1/2.5/4 meg RAM board from Tech Specialties (currently at 2.5 meg). > The serial port is important to me, as it's how I do my backups. > > I'm trying to find the cheapest way of fixing this mess. The options I've > thought of are: > > Anybody else ever have a serial port hardware problem? Did you solve it? > Anyone have a machine to sell? > > Bob Bane (bane@tove.cs.umd.edu) > -- > Internet: bane@tove.umd.edu > UUCP:...uunet!mimsy.umd.edu!bane Just replace the RS232 receve IC. MC1489A/UA1489A, this is IC No. U13 in the old ST's. They can some times get damaged with Modems that don't have a earth, and you plug them in with the power on..!! I know I used to work for a Big banking net work, the bigest in NZ. and we used to replace at one time some 2 IC's a week.. -- *** Roger W. Sheppard Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * GEnie. R.SHEPPARD5 *** *** Kapiti * * At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 12 Aug 91 10:01:57 GMT From: pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!nntpd.lkg.dec.com!aidev.enet. dec.com!miskinis@decwrl.dec.com (John Miskinis) Subject: Is BART down? To: Info-Atari16@naucse.cse.nau.edu Has anyone been able to download from Bart recently? I'm sending requests to atart@atari.archive.umich.edu but haven't got anything back... Actually, to be more specific I tried getting spcpics/robotarm.pic and spcpics/trontank.spc... _John_ ------------------------------ Date: 11 Aug 91 07:03:00 GMT From: mcsun!news.funet.fi!funic!nic.funet.fi!lahtinen@uunet.uu.net (Kimmo Lahtinen) Subject: Puting a pixel to screen To: Info-Atari16@naucse.cse.nau.edu I want to know what is now the "official" way to put a pixel to screen. I have read form this group that Line-A is not a good idea, but I did not find any simple pixel routines from VDI. I hope it is not too slow. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Kimmo Lahtinen E-Mail : lahtinen@gideon.fmi.fi or Finnish Meteorological Institute kimmo@field.fi Phone : +358 0 758 1322 Possessed by a Spirit G3 Fax : +358 0 758 1396 ------------------------------ Date: 12 Aug 91 10:29:22 GMT From: noao!asuvax!ukma!psuvax1!wupost!cs.utexas.edu!cse!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: Puting a pixel to screen To: Info-Atari16@naucse.cse.nau.edu In article lahtinen@gideon.gideon.fmi.fi (Kimmo Lahtinen) writes: >I want to know what is now the "official" way to put a pixel to screen. >I have read form this group that Line-A is not a good idea, but I did >not find any simple pixel routines from VDI. first off, line A was such an easy way to do things like this without writing a GEM program. rue the day that atari took this away... here is one way: first, find screen size (width and height) by some means. call these scrn_w and scrn_h. assume the pixel we want to set is (x,y) where (0,0) is upper left, x,y get larger positive values toward the lower right, up to (scrn_w-1,scrn_h-1). char *pscrn; /* ptr to physical screen mem */ char *pbyte; /* ptr to byte containing pixel (bit) to twiddle */ int shft; /* amount to shift mask */ pscrn = Physbase (); /* get screen loc */ pbyte = (char *) ( (long) pscrn + /* start here */ (long) y * (long)scrn_w/8L + /* goto line */ (long) x / 8L ); /* and byte */ shft = 8 - (x - (x/8)*8); /* setup mask */ *pbyte |= (char) (1 << shft); /* to set pixel */ *pbyte &= (char) i hope i have this right. i just did this today for mgif (eliminating the use of line A totally). it works. if not, this is close... this makes no use of line A (obviously). it only requires that u know the width of the screen. it assumes the screen width is evenly divisible by 8 (a reasonable assumption, i would think - it should be divisible by 16). note that pscrn need not be Physbase. it could be any virtual screen stored in memory. this *should* be 100% portable, regardless of ST, STe, TT, etc. note that this is for a monochrome screen!!!! doing this for color is left as an exercise for the reader. it is not that bad, u just have to account for interleaving of the planes when getting the byte. then again, u have to deal with the color, i suppose. >I hope it is not too slow. well, this can be optimized. i did it this way for clarity (i hope). it should be about as fast as line A would do it, give or take. i notice no real difference in speed. you can use word offsets instead. just make sure u get the pointer correct (remember: once u cast to long, u loose pointer arithmetic so adding 1 is adding 1 byte, not 1 word). note that it is easy to draw vertical or horizontal lines this way, but a bit more complicated to draw arbitrary lines. i think i posted ages ago a program called bez which is my (manual) screen saver. it does this trick with bezier curves. i did not write it originally, i just ported it. the origin escapes me but it was in a magazine (byte?) a couple of years ago... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 11 Aug 91 13:24:39 GMT From: mcsun!news.funet.fi!funic!nic.funet.fi!lahtinen@uunet.uu.net (Kimmo Lahtinen) Subject: Puting a pixel to screen To: Info-Atari16@naucse.cse.nau.edu Thank you for your reply, but I am afraid that it is no use for me, as I have a high resolution graphics card. And if I am correct you routine writes directly to screen memory, but you can not write to screen memory of the graphics card. Actualy you could but you have to use different system with every different graphics card. So I am looking for a general solution using normal system routines. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Kimmo Lahtinen E-Mail : lahtinen@gideon.fmi.fi or Finnish Meteorological Institute kimmo@field.fi Phone : +358 0 758 1322 Possessed by a Spirit G3 Fax : +358 0 758 1396 ------------------------------ Date: 9 Aug 91 21:38:10 GMT From: psinntp!uupsi!tfd!afp!gna!linn!Franck.Arnaud@nyu.arpa (Franck Arnaud) Subject: Spectre GCR To: Info-Atari16@naucse.cse.nau.edu In a message of <31 Jul 91 13:48:49>, dhbutler@magnus.acs.ohio-state.edu writes: >> Do you have the little INIT that causes your menus to act like GEM >> menus? You know, to drop down, instead of having to be laboriously AutoMenu does this very well. It is recent and compatible with System 7. --- /* Point of no return; */ - Paris Franck.Arnaud@linn.fidonet.org ------------------------------ Date: 12 Aug 91 03:24:02 GMT From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard) Subject: Turbo St To: Info-Atari16@naucse.cse.nau.edu Can any one tell me if Turbo St by Softrek is still around, if so what is the latest Version.. If so where do I get it. No 800 No's Please.. they are no good here in NZ... If not is Quick ST far better...??? -- *** Roger W. Sheppard Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * GEnie. R.SHEPPARD5 *** *** Kapiti * * At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 12 Aug 91 03:06:27 GMT From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard) Subject: Using a big hard disk To: Info-Atari16@naucse.cse.nau.edu In article <1991Aug11.070159.11845@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: > I got an impossibly great deal on a ST-4702N (600 MB Wren-V). I have it > hooked up to my BMS-200, and it responds to commands alright. I can > even get the BMS disk initializer to prepare 60 MB of useful file space on > it. But I want to set this thing up as a large number of large partitions, > and to do that I need HDX. So far, with a few reasonable tries, HDX refuses > to do ANYTHING with this disk. Any suggestions? > Steve saj@chinet.chi.il.us Well HDX is now upto Version 4.01, but that is for the 'TT', the old one should be Version 3.02.. You will need to write the settings for that drive into the Wincap file, get a text reader "Tempas" and have a look at the Wincap file, from the info in the Wincap file and the info you have on your drive you should be possible to create your own entry to the Wincap file, for that drive. -- *** Roger W. Sheppard Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * GEnie. R.SHEPPARD5 *** *** Kapiti * * At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 12 Aug 91 03:59:24 GMT From: noao!ncar!midway!machine!chinet!saj@arizona.edu (Stephen Jacobs) Subject: Using a big hard disk To: Info-Atari16@naucse.cse.nau.edu In article <1991Aug11.212523.6360@netcom.COM> rcb@netcom.COM (Roy Bixler) writes: >In article <1991Aug11.125507.21713@doug.cae.wisc.edu> carter@cae.wisc.edu (Gregory Carter) writes: >>In article <1991Aug11.070159.11845@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >>>I got an impossibly great deal on a ST-4702N (600 MB Wren-V). I have it >>>hooked up to my BMS-200, and it responds to commands alright. I can >>>even get the BMS disk initializer to prepare 60 MB of useful file space on >>>it. But I want to set this thing up as a large number of large partitions, >>>and to do that I need HDX. So far, with a few reasonable tries, HDX refuses >>>to do ANYTHING with this disk. Any suggestions? > I would recommend calling Berkeley Microsystems. I had a >similar problem when I first got my HD/BMS-200 combination and they >were very helpful. I actually called Berkeley Microsystems before buying the disk, and they gave me a few suggestions. I can now use all 600 MB of it using their "if all else fails" method (partition using their fourpart partitioner). The version of Atari's HDX I'm using is recent enough that it asks whether the drive is on the SCSI or the ACSI bus. I've tried all sorts of plausible WINCAP entries, and HDX absolutely always says it can't partition the disk until it's formatted correctly, and it can't format the disk. I guess, since AHDI drives the disk ok, what I really need now is a way to define the last partition on the disk as an 'XGM' partition, and to parcel it out. Something that leaves the first 3 partitions alone wouldn't hurt, but isn't necessary either. Steve ------------------------------ Date: 12 Aug 91 08:56:43 GMT From: noao!asuvax!ukma!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio- state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!fauern!faui43.infor matik.uni-erlangen.de!csbrod@ (Claus Brod) Subject: Using a big hard disk To: Info-Atari16@naucse.cse.nau.edu saj@chinet.chi.il.us (Stephen Jacobs) writes: >I actually called Berkeley Microsystems before buying the disk, and they gave >me a few suggestions. I can now use all 600 MB of it using their "if all >else fails" method (partition using their fourpart partitioner). The version >of Atari's HDX I'm using is recent enough that it asks whether the drive is >on the SCSI or the ACSI bus. I've tried all sorts of plausible WINCAP entries, >and HDX absolutely always says it can't partition the disk until it's >formatted correctly, and it can't format the disk. Try HDX 4.01, not 4.00. It is much better at recognizing and formatting SCSI disks of all kinds. Try switching off the MODE SENSE part during the formatting process (there is a field for this purpose in the WINCAP file). --- ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ---------------------------------------------------------------------- ------------------------------ End of Info-Atari16 Digest ******************************