home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 12: Textmags & Docs / nf_archive_12.iso / MAGS / TEXTMAGS / ATARI16 / INFO91.ZIP / INFO91 / 514.TXT < prev    next >
Text File  |  1997-04-16  |  30KB  |  649 lines
  1. Info-Atari16 Digest         Sun, 29 Sep 91       Volume 91 : Issue 514
  2.  
  3. Today's Topics:
  4.                             ARJ? K.I.S.S.!
  5.                     ATARI MEGA 2 ST W/ HD FOR SALE
  6.                       Cartridge Port for STBooks
  7.                    Hi-Rez Vidio card info wanted!!!
  8.              lharc 2.01e vs zoo 2.1: some tests (2 msgs)
  9.                         More Lies From Atari?
  10.     People dumping machines (was.. Atari Mega 2 system.. for sale)
  11.     Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?)
  12.                       question about Megafile 30
  13.                               STOS Users
  14.                      Weekly Posting of New Stuff
  15.  
  16. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  17. cross-posting to/from Usenet is getting closer, but still getting thrashed
  18. out.  Please send notifications about broken digests or bogus messages
  19. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  20.  
  21. Please send requests for un/subscription and other administrivia to
  22. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  23. instead of the moderators are likely to be lost or ignored.
  24.  
  25. If you want to unsubscribe, and you're receiving the digest indirectly
  26. from someplace (usually a BITNET host) that redistributes it, please
  27. contact the redistributor, not us.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: 28 Sep 91 00:31:28 GMT
  31. From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!kbad@arizona.edu
  32.  (Ken Badertscher)
  33. Subject: ARJ? K.I.S.S.!
  34. To: Info-Atari16@naucse.cse.nau.edu
  35.  
  36. rosenkra@convex.com (William Rosenkranz) writes:
  37.  
  38. |[...] burrying GEM code in a an application
  39. |making it "bisexual", if you will, makes it larger (obviously). bundling
  40. |the gem user interface for like programs (all archivers pretty much do
  41. |the same thing) in a separate shell seems like a better approach, though
  42. |it may make installation slightly more complicated.
  43.  
  44. True.  The problem I have with the archiver situation in the TOS world,
  45. though, is that so darned many of them exist.  TOS versions of Arc have
  46. long been surpassed in performance by more efficient compressors.  Yet
  47. a lot of the archives I see on BBS's and elsewhere are still ARC format.
  48. I find LZH situation depressing.  I personally have had little luck
  49. getting a single LZH tool that would deal with the variety of LZH
  50. formats out there.
  51.  
  52. This is why I was happy to see ZOO version 2.1 appear, with its high-
  53. performance option that beats or matches LZH compression.  The main
  54. reason I like zoo is for its superior directory handling and "novice"
  55. command set.
  56.  
  57. Having ARJ available will be even better.  After using it under DOS, it
  58. became apparent to me that it merges all the best features of the
  59. different archivers I've used.  Its compression is phenomenal (you want
  60. fast?  ARJ does fast... you want tiny? you can get that too; slower,
  61. but not unreasonably so). It has a complete set of options for handling
  62. directories and for creating self-extracting archives, split-volume
  63. archives, etc. ad inf.
  64.  
  65. If the programmers porting ARJ make a version that everyone can use
  66. conveniently, we may be looking at the StuffIt of TOS archive programs.
  67. Because the compression beats the competition (and after all, that's
  68. the bottom line in archivers, no?), people will likely latch onto it.
  69. If, as an added bonus, it has a user-friendly face, more people will
  70. want to look at it.  If it's the best archiver in terms of compression
  71. vs. speed tradeoffs, and flexibility in file handling, it'd sure be
  72. nice if it were also the best in terms of ease of use.
  73.  
  74. As an aside...
  75. |also, IF atari plans on ever releasing some flavor of UNIX in the future,
  76. |it will be in your best interest to educate users on using CLIs anyway.
  77. |[...] i really don't see a way around CLI use in unix
  78. |at some point (i.e. sys admin). who knows, atari might suprise us :-).
  79. I think the Atari Unix group will do just that!
  80.  
  81.  
  82. |the other problem is that i fear gem code and the application will get
  83. |hopelessly intermingled making it impossible to port to non-GEM platforms.
  84. |that is assuming source is even distributed.
  85.  
  86. [Good example of how to insert system-specific GUI code into a
  87.  CLI-based source distribution deleted]
  88.  
  89. |comments, ken??? could this be a new standard programming practice? :-)
  90.  
  91. You're right on that count.  People porting programs like this
  92. should be careful about how they wedge GEM features into a CLI-based
  93. program.  Whenever one modifies a source distribution, the modifications
  94. should be as nonintrusive as practical, and there should *always* be a
  95. way to retrieve the original, using conditional compilation or other
  96. techniques.
  97.  
  98. Also, while it's true that programs bloat a bit when GEM features are
  99. added, the rewards are worth the few extra K of disk space consumed.
  100. The extra effort can make a program useful to thousands more people. As
  101. an example, wiring a non-trivial GEM UI into MicroEMACS costs adds only
  102. about 20K of disk space to a 100K or so program.  That 20% increase in
  103. size makes the program much, much easier to use (in my experience, and
  104. in the experience of EMACS users, both novice and pros, on whom I
  105. foisted the bug-ridden hack :).
  106. --
  107.    |||   Ken Badertscher  (ames!atari!kbad)
  108.    |||   Atari Corp. System Software Engine
  109.   / | \  #include <disclaimer>
  110.  
  111. ------------------------------
  112.  
  113. Date: 28 Sep 91 04:30:14 GMT
  114. From: ucivax!gateway@locus.ucla.edu (James Tang)
  115. Subject: ATARI MEGA 2 ST W/ HD FOR SALE
  116. To: Info-Atari16@naucse.cse.nau.edu
  117.  
  118.         I have an Atari Mega 2 ST system for sale.  Asking for $1500.00 or
  119. best offer (make me an reasonable offer) for the the following:
  120.  
  121. Atari Mega 2 ST unit
  122. Atari Color Monitor SM124
  123. 85 MB HD for sale (Seagate 296N with ICD FAST Host adaptor)
  124. Tweety Board, stereo sound
  125. Replay4 sound digitizer
  126. Owner's menu for all of the above Items
  127.  
  128. All softwares that I have is included.
  129.  
  130. Such as:
  131.         Populous and the Promise Land disk
  132.         ICD HD utilities .....
  133.  
  134. Please reply with e-mail at:
  135.  
  136. jtang@einstein.oac.uci.edu
  137.  
  138. or call at
  139.  
  140. (714) 725-5798 and ask for James
  141.  
  142. ------------------------------
  143.  
  144. Date: 27 Sep 91 19:24:01 GMT
  145. From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!trh@arizona.edu
  146.  (T R Hall)
  147. Subject: Cartridge Port for STBooks
  148. To: Info-Atari16@naucse.cse.nau.edu
  149.  
  150.         As I said in the earlier post, the "120-pin Expansion Port" has all
  151. of the signals neccesary to create a cartridge port, and we (Atari) have
  152. encouraged/ are encouraging third parties to make a _*very*_ simple board to
  153. convert from Expansion to Cartridge. (two connectors and a PCB... _*no*_
  154. active parts)
  155.  
  156.         What I wanted to add is that I have built such a board in the lab,
  157. and it works just fine.
  158.  
  159.                                         Tracy R. Hall
  160.  
  161. ------------------------------
  162.  
  163. Date: 27 Sep 91 21:11:15 GMT
  164. From: rayssd!jarsun1!drd!d.cs.okstate.edu!cummins@uunet.uu.net (John Cummins)
  165. Subject: Hi-Rez Vidio card info wanted!!!
  166. To: Info-Atari16@naucse.cse.nau.edu
  167.  
  168. I want to purchase a good vidio setup for my Mega ST.
  169. I'd prefer 1024 X 768 pixel modes for both color and monochrome, and
  170. I hope to be able to handle standard LO-REZ, MED-RED, and HI-REZ
  171. modes as well (For existing software that doesn't check the screen
  172. size... or that does check and asks you to set it to LO-REZ or whatever.
  173.  
  174. I intend to do an SST (Gadgets by Small) upgrade on the machine as well...
  175. and wish to maintain as much compatability as possible.
  176.  
  177. Prices and impressions Please!!!
  178. (Especially BARGAINS!!!)
  179. (email too, my news-server expires things in less than 24 hours)
  180.  
  181. jc (john Cummins)  cummins@d.cs.okstate.edu
  182.  
  183. ------------------------------
  184.  
  185. Date: 27 Sep 91 23:01:16 GMT
  186. From:
  187.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
  188.  .ohio-state.edu!usenet.ins.cwru.edu!ncoast!bjsjr@arizona.edu (Bill Shroka)
  189. Subject: lharc 2.01e vs zoo 2.1: some tests
  190. To: Info-Atari16@naucse.cse.nau.edu
  191.  
  192. In article <1991Sep26.064525.15427@convex.com> rosenkra@convex.com (William
  193.  Rosenkranz) writes:
  194. >
  195. >friends-
  196. >
  197. >to help understand the claim that lharc is the best thing since sliced
  198. >bread, and so much better than zoo 2.1, i ran some tests. this is a rather
  199. >long post. if you think i am crazy, hit 'n' now. or put me in your kill
  200. >file :-). if you have an open mind, read on for enlightenment...
  201.  
  202. As the person responsible for the ST version of Zoo (and one of the many
  203. versions of LHarc), I guess I should make a few comments here.  The following
  204. will be a highly edited version of Bill's article.
  205.  
  206. >summary:               zoo 2.1 is just about as fast as lharc 2.01e and
  207. >                       makes files about the same size.
  208.  
  209. Agreed.  Lharc 2.01e is undisputedly the fastest LHarcer available for the ST.
  210. The slow version of Zoo (the current version) is almost as fast as lharc 2.01e
  211. but is much, much more compatible across (and on the same) platforms.  That's
  212. why I gave up on LHarc: There was no central development team to make decisions
  213. on design.
  214.  
  215. >test platform is mega4 (4 MB) 8 Mhz, TOS 1.2, using gulam CLI. environment
  216. >included TMP=ramdisk and TEMP=ramdisk (i confirmed there was no use of
  217. >hard disk by observing that no disk access lights went on).
  218.  
  219. Just a note(for those interested):  Zoo doesn't use any type of TMP variable.
  220.  
  221. >       lharc 2.01e (questor, Assemblerversion vom 14.07.1991)
  222. >       zoo 2.1 (1991/07/14 22:39:26)
  223. >
  224. >i would call this "equal" technology since the versions were realized
  225. >on the same dates! zoo was compiled with GNU c (gcc) though i do not know
  226. >which version. i confirmed this by both "printstk zoo.ttp" which did not
  227.  
  228. I used GCC 1.40.  I'm always on the cutting edge of the GNU stuff :-)
  229.  
  230. >fail, listing a reasonable stacksize (16k) and by "strings -10 zoo.ttp"
  231. >which listed ascii strings that would appear if gcc was the compiler.
  232. >it also looks like zoo 2.1 was compiled with MiNT so that it could be
  233. >"backgrounded" in a multiprocessing environment. i could be way off base
  234. >here, however. i just spotted the string "MiNT" in the .ttp. i saw no
  235.  
  236. I used Patchlevel 72 (I think) of bammi's library, which is slowly merging
  237. with Eric's mintlib.  I use the 16K stacksize (as opposed to all available
  238. memory) so that Zoo can be used in the background MiNT or RTX.
  239.  
  240. >evidence that lharc was equally endowed. it also looks like zoo may support
  241. >UNIXMODE tho i don't use it myself. UNIXMODE allows configuration so that
  242. >forward slashes "/" can be used in file paths as well as backslash "\".
  243.  
  244. Yes, Zoo does support UNIXMODE though I don't use it either.
  245.  
  246. >zoo21: extract files:
  247. >
  248. >this took 25 seconds. the times and dates of extracted files were exactly
  249. >correct (same dates and times as files in the archive).
  250.  
  251. Though the times and dates were correct for you, there are some known bugs in
  252. Zoo time code, especially the timezone stuff.  I have been informed that they
  253. have already been fixed for the next version.
  254.  
  255. >----------------------------------------------------------------------------
  256. >test 4:
  257. >
  258. >i tested each program's ability to be interrupted. during archive creation,
  259. >i issued a control-C to both. both stopped. however, lharc left a file
  260. >behind "lharc.)2(" so it does not really handle signals. zoo does since
  261. >it was compiled with GNU C library (another reason why it is better to
  262. >use a compiler with a decent library). zoo cleaned up after itself.
  263.  
  264. The GCC-ST library is a tribute to Jwahar Bammi and Eric Smith (and all of
  265. the other contributors).  It makes ports like Zoo a breeze.  Thanks guys.
  266.  
  267. >       - the size of the executables is significantly different. about 2x
  268. >         (lharc being the smaller). however, after packing with pfxpak,
  269. >         zoo is about 53k and lharc is about 28k. the difference is not
  270. >         that significant in a 16 MB partition. what i do find fascinating
  271. >         is that the executable for lharc is itself an archive! this is
  272. >         a really super hack. incidently pfxpak was written by the very
  273. >         same thomas questor who provides the lharc under scrutiny. (and
  274. >         thomas, i DID disassemble it, tho the crash in test 3 wiped it
  275. >         out since i had the source on the ramdisk. maybe you could mail
  276. >         me the source now...:-). still, i generally dislike self extracting
  277. >         archives though this is a twist on that concept.
  278.  
  279. In these days of massive sized hard drives I personally find executable size
  280. VERY, VERY, unimportant.  If I have a choice between exec size and speed, I'll
  281. take speed every time.  I would guess UNIXMODE adds quite a bit to the size
  282. of GCC execs (I'm not sure) since it is emulating a new file system.
  283.  
  284. >       - the version of zoo sources i have can easily be ported to any
  285. >         system with POSIX library and an ANSI C compiler. this includes
  286. >         scores of systems from the PC and ST to supercomputers. lharc
  287.  
  288. Many thanks to R. Dhesi for this!
  289.  
  290. >       - i can take the zoo 2.1 archive up to a unix (or VMS) system and
  291. >         extract the archive with no effort. i do not have to track down
  292. >         a version which will extract it. the original version posted to
  293. >         the net (source code) works fine. i have tried unlzhing an lh5
  294. >         archive on unix with LHarc for unix v1.02 with no luck. it complains
  295. >         that it cannot extract this method. in this case someone is going to
  296. >         berate me saying "well, you should get this_and_such version and
  297. >         quit moaning". i would (naturally) respond with "so how often do
  298. >         i have to update lharc on unix to remain current? i already have
  299. >         2 versions. how many more do i need? i only need one version of
  300. >         zoo 2.1!". if it is any consolation, at least 1.02 does not core
  301. >         dump when it finds this out (0.03 does, at least my port on a
  302. >         convex does).
  303.  
  304. When Yoshi added -lh5- to lha (as it is now known) he also re-wrote much of
  305. lha in assembly.  Thus, no version of lha has ever been ported to Unix, so you
  306. cannot unlzh any -lh5- archives.
  307.  
  308. >also, i know of some optimizations for zoo which may not have been applied
  309. >in the version i have (posted to comp.binaries.atari.st by steve grimm).
  310. >i know the unix version with larger i/o buffers is significantly faster
  311. >(at least 20% on a convex C210 with VME disks). if that is also true on
  312. >the ST, then the small speed advantage lharc has (only on compression, that
  313. >is) over zoo goes away. and zoo 2.1 may be even faster than lharc on
  314. >extraction in that case.
  315.  
  316. There have been some significant optimizations to ST Zoo, though none of them
  317. change any of the Zoo code.  All i/o is done with the aid of a 32K buffer (as
  318. set by __DEFAULT_BUFSIZ__).  When I initially ported Zoo, it took 7:03 to
  319. compress gcc-cc1.ttp(roughly 600K) using high compression.  After profiling
  320. and then 'inlining' the appropriate functions, I was able to get the
  321. compression time down to 5:36.  I believe that shows some of the power of the
  322. GCC compiler.
  323.  
  324. >also note that this version of zoo appeared within days of being posted
  325. >to alt.sources. i am sure it has not been tuned in the slightest. and i
  326. >hope it stays that way, so we don't end up with 50 versions of zoo.
  327.  
  328. It took me about 1 hour to do my initial port of ST Zoo.  Any 'tuning' I did
  329. has been added to the mainstream Zoo source.
  330.  
  331. >it would also be nice to look at each program's i/o efficiency by controlled
  332. >tests in cluttered hard disk partitions or on virgin-formatted floppies.
  333. >i have not done that nor do i think it is worth the effort at this point.
  334. >also each program's handling of directory trees should be tested. zoo 2.1
  335. >(on the ST only!) now has an improved method for doing recursive hierarchies
  336. >(a//). the unix version still uses the "find . -print | zoo aI archive"
  337. >method as far as i know. this is not possible with the ST without CLIs that
  338. >support pipes. gulam (and the desktop) do not support pipes.
  339.  
  340. I don't know if I'd call the present method of 'recursive descent of directory
  341. trees' improved :-)  I think enough people have twisted R. Dhesi's arm so that
  342. he will add this feature to the next version of Zoo.  At least that's what he
  343. told me (I haven't seen the new code yet).
  344.  
  345. >comments??? rebuffs??? name calling???
  346.  
  347. Thanks for the initial comparison.  I wouldn't mind seeing a more in-depth
  348. comparison of the archivers (including ARJ if it's ever released).  It would
  349. help me address any of Zoo's shortcomings.  Anyone interested in doing this??
  350.  
  351. >-bill
  352. >rosenkra@convex.com
  353. --
  354. --------------------------------------------------------------------------
  355. Bill Shroka
  356. bjsjr@NCoast.ORG
  357. uunet!usenet.INS.CWRU.Edu!ncoast!bjsjr
  358.  
  359. ------------------------------
  360.  
  361. Date: 28 Sep 91 13:22:41 GMT
  362. From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard)
  363. Subject: lharc 2.01e vs zoo 2.1: some tests
  364. To: Info-Atari16@naucse.cse.nau.edu
  365.  
  366. In article <1991Sep27.162345.14991@convex.com> rosenkra@convex.com (William
  367.  Rosenkranz) writes:
  368. > In article <1991Sep27.131642.16914@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz
  369.  (Roger Sheppard) writes:
  370. > >I have just had a look at your rather long posting, well for one thing
  371. > >that I find that it is very biased to ZOO 2.1..
  372. >
  373. >
  374. > >BUGS. I think you will find that the Date/Time Problem is possible caused
  375. > >by TOS 1.2, I have tested some files and never found a date or time probem,
  376. > >but then I do use TOS 1.4.:-)
  377. >
  378. >
  379. > >ARGV is claimed to be supported, but I have no way to test it, there
  380. > >was some comments in the Doc's that Thomas had fixed ARGV in version 201D.
  381. >
  382. > i do (and did). lharc 2.01e DID cause my system to crash. if there is a
  383. > newer version than this, send it to me and i will retest. you never run
  384. > across this because you never run CLIs. if you did, your system would
  385. > likely crash as well.
  386.  
  387. I have noticed that the system LZH201E was compiled with Torbo C 2.0,
  388. may be there is a Problem with a C libary,? that caused ARGV to fail,
  389. I do know its there as I have traced it..
  390.  
  391. > spending money has never been my problem :-). i have 2 ataris (mega 4
  392. > and 1040ST, megafile 60, sh204, at least 3 monitors, etc, etc,etc). i
  393. > should upgrade (one of these days) but that is still no excuse for lharc
  394. > not to work properly on 1.2 and 1.0 (if it is in fact  a TOS 1.4
  395. > incompatibility as you suggest). as far as i know, the Fdatime GEMDOS call
  396. > works the same in all TOS versions. it is used to set file timestamps.
  397.  
  398. From some Atari Notes that I have on TOS 1.4, they mention incorrect
  399. documentation of the Fdatime GEMDOS call, thats in earlier versions of TOS ?,
  400. could this be the problem ?.
  401.  
  402. One thing you did not test with both Archivers was full i/o, did you
  403. not state that ZOO 2.1 has a problem with Disk i/o,?
  404. if this is the case then none of your tests are valid.
  405.  
  406. I think that it would be far better if some one had done these test,
  407. that was not that biased, you new of the new features in zoo 2.1, but
  408. you did not bother to find out about any new features of LZH201X..
  409.  
  410. As far as ZOO is concerned, I find that ZOO is used on only
  411. about 2-5% of the PD files that I get.
  412.  
  413. Also I have never made a ZOO archive, I had so many problems with
  414. eXtracting ZOO archive that I don't use it as a archiver at all, there
  415. are too many switches to understand, unless you have a Computer Science
  416. Degree, so far from what I can see only used by Unix Freeks, they like
  417. wearing key boards out..:-)..
  418.  
  419.  
  420. > -bill
  421. > rosenkra@convex.com
  422. >
  423. > --
  424. > Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
  425. > Convex Computer Corp.      |ARPA: rosenkra@convex.com
  426.  
  427.  
  428.  
  429. --
  430. ***  Roger W. Sheppard      *      Roger.Sheppard@bbs.actrix.gen.nz  ***
  431. ***  85 Donovan Rd        *    *   GEnie.  R.SHEPPARD5               ***
  432. ***  Kapiti                        At least I don't Flicker,         ***
  433. ***  New Zealand..          *      not like a dying light globe      ***
  434.  
  435. ------------------------------
  436.  
  437. Date: 27 Sep 91 18:04:08 GMT
  438. From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!trh@arizona.edu
  439.  (T R Hall)
  440. Subject: More Lies From Atari?
  441. To: Info-Atari16@naucse.cse.nau.edu
  442.  
  443. darling@cellar.UUCP (Thomas Darling) writes:
  444.  
  445. >techno@lime.in-berlin.de (Techno) writes:
  446.  
  447. >> Well, the ST-BOOK is available here in Germany. I've seen one here
  448. >> at my dealer two days ago.
  449. >>
  450. >> Features:
  451. >> 1 MByte RAM, 40 MB HD, cost 4000.- DM
  452. >> I/O: MIDI, DMA, parallel, serial, system bus, external mouse
  453. >> built-in modem optional, external 1.44 MByte (!) 3.5" disk drive optional
  454. >> 10h battery life on optional accu pack, rechargeable inside 2h during mains
  455. >> operation.
  456. >>
  457. >> Personal optinion: I like the thing, esp. the screen and the VectorPad.
  458. >
  459. >What I want to know is this: Does it have a cartridge ("dongle") port?  I need
  460. >that port for my SMPTE/MIDI expander box (Unitor, from C-Lab).
  461. >
  462. >If this is, in fact, one of the I/O's mentioned above, please inform me, for I
  463. >know not the technical terms.
  464.  
  465.         There isn't directly a cartridge port, _*BUT*_...
  466.  
  467. The "120-pin Expansion Port" (my/atari's name for the "system bus") has
  468. _*all*_ the signals neccesary to _*create*_ a cartridge port. We have
  469. encouraged/are encouraging third parties to make a _*very*_ simple board to
  470. convert the "Expansion" to "cartridge". (two connectors and a PCB... no active
  471. parts at all).
  472.  
  473.                                 Tracy R. Hall
  474.  
  475. ------------------------------
  476.  
  477. Date: 28 Sep 91 14:24:10 GMT
  478. From:
  479.  noao!asuvax!cs.utexas.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-b
  480.  eacon!eru!hagbard!sunic!ugle.unit.no!lise.unit.no!stigvi@arizona.edu (Stig
  481.  Vidar Hovland)
  482. Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
  483. To: Info-Atari16@naucse.cse.nau.edu
  484.  
  485. In article <1991Sep27.143553.27920@magnus.acs.ohio-state.edu>,
  486.  dhbutler@magnus.acs.ohio-state.edu (David Butler) writes:
  487. |> This is a TRUE 25mhz 68030
  488. |> machine (why did Atari screw up the TT with a 16mhz bus system? arrgghh!!),
  489.  
  490. The Motorola 68000 series of microprocessors have an asyncronous bus system.
  491.  There is no 16MHz or
  492. 32Mhz or xxMHZ bus system in the TT. As you probably know, the MC68030 can read
  493.  from TT-ram
  494. in burst-modus and this is as fast as it can be. It is not limited by a "slow
  495.  bus".
  496.  
  497. Stig Vidar Hovland - stigvi@lise.unit.no
  498.  
  499. ------------------------------
  500.  
  501. Date: 26 Sep 91 13:25:56 GMT
  502. From: ispd-newsserver!psinntp!uupsi!stiatl!iam@uunet.uu.net (Ian Mercado)
  503. Subject: Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?)
  504. To: Info-Atari16@naucse.cse.nau.edu
  505.  
  506. steve@thelake.mn.org (Steve Yelvington) writes:
  507.  
  508. >[In article <1991Sep21.030908.985@cs.sfu.ca>,
  509. >     wolfgang@cs.sfu.ca (Wolfgang Jung) writes ... ]
  510.  
  511. > > My feeling of this is that you NEED (i never read you did) to remove or
  512. > > at least deactivate the 256K Chips , which normaly reside in BANK 0
  513. > > In the case you forgot that, the hardware gets into VERY big Trouble when
  514. > > reading from the rams at an Address greater than 512K. If you leave the
  515. > > HIGH Address line unconnected (MAD10 i think) the system reads and writes
  516. > > into the same bytes, which shouldn't make any Problems.
  517.  
  518. >How do you do this (temporarily)? I have an old nearly-original 520 (with
  519. >modulator, without floppy) that has a half-populated Tech Specialties
  520. >piggyback board. I'd like to bring it up to 4MB, since chips are
  521. >practically free these days, but to do so I need to disable bank 0. I'd
  522. >like to do that without having to get a bunch of chips desoldered -- in
  523. >case it doesn't work and I have to restore the original setup.
  524.  
  525. All I did on my original 1040 to disable the leftover bank was clip the
  526. L1 inductor which provides power to the chips.  Worked like a charm, and I
  527. could always solder it back together if I felt it was necessary.  (Although WHY
  528. I might want to go back to 2.5 meg from 4 meg is way beyond me.
  529.  
  530. --
  531. --------   ----   ----   --    |   Ian Mercado: iam@salestech.com             |
  532.    --     -    -  -----  --    |                emory!slammer!stiatl!iam      |
  533.    --    -------- --  -----    |                                              |
  534. -------- --    -- --   ----    |            "I'd rather be flying."           |
  535.  
  536. ------------------------------
  537.  
  538. Date: 28 Sep 91 13:40:52 GMT
  539. From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard)
  540. Subject: question about Megafile 30
  541. To: Info-Atari16@naucse.cse.nau.edu
  542.  
  543. In article <1991Sep27.161732.14365@edm.isac.CA> darius@edm.isac.ca (Darius S.
  544.  Naqvi) writes:
  545. >
  546. > Inside my megafile 30 is a seagate ST238R hard drive; the R means RLL
  547. > format.  Am I correct in assuming, then, that the controller in the
  548. > megafile is an RLL-to-ACSI board?  Does this mean that if I want to swap
  549. > the drive mech., the only choice I have is to use an RLL drive, or is it
  550. > possible to use some other type of drive?
  551. >
  552. > Please be patient with me if this question seems stupid.  I'm not a hard
  553. > drive expert, just someone who wants an easy way to get a bigger, faster
  554. > hard drive.
  555. > --
  556. > Darius S. Naqvi                    mail:darius@edm.isac.ca
  557. > ISA Corp.                         phone:(403) 420-8081
  558. > Edmonton, Alberta, Canada
  559.  
  560. Yes you are right, you can only use a MFM RLL drive, or take a chance
  561. and use a normal MFM drive and format it RLL..
  562.  
  563. Also it is posible to format hard drives with a 1:1 interleave, but
  564. this has to be forced with some format software, as the controler is
  565. seen as a Adaptec 4070, this normaly can't do 1:1,
  566. but this is a Atari one, and it Can..!
  567.  
  568. --
  569. ***  Roger W. Sheppard      *      Roger.Sheppard@bbs.actrix.gen.nz  ***
  570. ***  85 Donovan Rd        *    *   GEnie.  R.SHEPPARD5               ***
  571. ***  Kapiti                        At least I don't Flicker,         ***
  572. ***  New Zealand..          *      not like a dying light globe      ***
  573.  
  574. ------------------------------
  575.  
  576. Date: 28 Sep 91 14:32:17 GMT
  577. From:
  578.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
  579.  .ohio-state.edu!usenet.ins.cwru.edu!cleveland.Freenet.Edu!aj639@arizona.edu
  580.  (Michael Cox)
  581. Subject: STOS Users
  582. To: Info-Atari16@naucse.cse.nau.edu
  583.  
  584. I was wondering if anyone programs in STOS?  I have an Amiga and use AMOS
  585. but would like to try and port some STOS programs over.  I'd also like
  586. to see what an STOS program looks like.  If anyone could help me, please
  587. send email to aj639@cleveland.freenet.edu
  588.  
  589. Thanks in advance!
  590.  
  591. Mike
  592.  
  593. --
  594. Okay, folks, look for the newest AMOS PD disk called the AMONER Project.  It's
  595. available on:
  596. ab20 (128.155.23.64)  directory: /amiga/games/amos  filename: amoner01.dms
  597. ux1  (128.174.5.50)   directory: /amiga/amoner      filename: amoner01.dms
  598.  
  599. ------------------------------
  600.  
  601. Date: 28 Sep 91 10:46:40 GMT
  602. From: umich!terminator!usenet@yale.arpa (Atari Archive Robot)
  603. Subject: Weekly Posting of New Stuff
  604. To: Info-Atari16@naucse.cse.nau.edu
  605.  
  606.   drwxrwxr-x daemon     1024    Sep 21 09:23 .
  607.   drwxrwxr-x jon        2560    Sep 22 00:37 ./magazines/streport
  608.   -rw-r--r-- weiner     48866   Sep 22 00:37 ./magazines/streport/str738.txt.Z
  609.   drwxrwxr-x jon        2048    Sep 22 00:37 ./magazines/znet
  610.   -rw-r--r-- weiner     28706   Sep 22 00:37 ./magazines/znet/znet9140.txt.Z
  611.   -rw-rw-r-- weiner     111096  Sep 21 09:23 ./Index
  612.   drwxr-xr-x weiner     1536    Sep 21 09:21 ./dc
  613.   -rw-r--r-- weiner     11483   Sep 21 09:21 ./dc/dcpopbr2.arc
  614.   -rw-r--r-- weiner     1469    Sep 21 09:22 ./dc/Index
  615.   -rw-rw-r-- weiner     51759   Sep 21 09:23 ./CompInd.Z
  616.   -rw-rw-r-- weiner     3704    Sep 22 15:50 ./admin/Current.monthly.posting
  617.   drwxrwxr-x daemon     1024    Sep 24 21:15 .
  618.   -rw-r--r-- weiner     3206    Sep 24 21:15 ./telecomm/Index
  619.   -rw-rw-r-- weiner     111170  Sep 24 21:15 ./Index
  620.   -rwxr-x--- weiner     209     Sep 24 21:13 ./.compind
  621.   -rw-rw-r-- weiner     51800   Sep 24 21:15 ./CompInd.Z
  622.   drwxrwxr-x daemon     1024    Sep 25 20:16 .
  623.   -rw-rw-r-- weiner     9111    Sep 25 20:16 ./games/Index
  624.   drwxr-xr-x weiner     512     Sep 25 20:15 ./games/tads
  625.   -rw-r--r-- weiner     178463  Sep 25 20:15 ./games/tads/uu2v101.lzh
  626.   -rw-rw-r-- weiner     111171  Sep 25 20:16 ./Index
  627.   -rw-rw-r-- weiner     51804   Sep 25 20:16 ./CompInd.Z
  628.   drwxrwxr-x daemon     1024    Sep 26 17:11 .
  629.   -rw-r--r-- weiner     1342    Sep 26 17:11 ./music/Index
  630.   -rw-rw-r-- weiner     111494  Sep 26 17:11 ./Index
  631.   -rw-rw-r-- weiner     51988   Sep 26 17:11 ./CompInd.Z
  632.   drwxrwxr-x daemon     1024    Sep 27 23:29 .
  633.   drwxrwxr-x jon        1536    Sep 27 23:11 ./demos
  634.   -rw-rw-r-- weiner     407844  Sep 27 23:11 ./demos/spoon_a.msa
  635.   -rw-rw-r-- weiner     3250    Sep 27 23:13 ./demos/Index
  636.   -rw-rw-r-- weiner     379678  Sep 27 23:11 ./demos/spoon_b.msa
  637.   drwxrwxr-x weiner     1024    Sep 27 23:11 ./ste
  638.   -rw-r--r-- weiner     401421  Sep 27 23:11 ./ste/delirs3a.msa
  639.   -rw-rw-r-- weiner     1139    Sep 27 23:15 ./ste/Index
  640.   -rw-r--r-- weiner     386716  Sep 27 23:11 ./ste/delirs3b.msa
  641.   -rw-rw-r-- weiner     112061  Sep 27 23:29 ./Index
  642.   -rw-rw-r-- weiner     80123   Sep 27 23:26 ./ls-lR.Z
  643.   -rw-rw-r-- weiner     52299   Sep 27 23:29 ./CompInd.Z
  644.  
  645. ------------------------------
  646.  
  647. End of Info-Atari16 Digest
  648. ******************************
  649.