Today's Topics: Accelerators for the ST forsale All BBS sysops. ARJ? Atari.archive monthly posting BBS request, here is two from NZ. Deactivating your 520ST RAM (for upgrading) dump files Emulate? What about the other way. ESDI harddrive Gif viewer Mega/STE Screen Shifting Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?) 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: 21 Sep 91 22:37:36 GMT From: noao!asuvax!cs.utexas.edu!usc!rpi!usenet.coe.montana.edu!ogicse!sequent!muncher .sequent.com!ether!bug!stevef@arizona.edu (Steven R Fordyce) Subject: Accelerators for the ST forsale To: Info-Atari16@naucse.cse.nau.edu I have come to possess a large number of Processor Accelerators for the 520, 1040, and Mega ST that I will sell for $65 each shipping included (add $5 for shipping outside the U.S.). I will sell two for $100. These are new units, in the box, were built by CMI and are fully tested. These accelerators are on multilayer boards that plug into a socket you solder onto the 68000. These boards are built around a 16 MHz 68000 and run at double the standard processor speed. The speed up you get with this product depends on the software you are running, but it runs from 10 to 30%. These boards (there is a different one for the 520/Mega or 1040, so let me know what you want) also accept 68881 floating point unit of any speed, although it doesn't pay to get one faster than 16 MHz. For software that uses the math chip you can get speed ups of eight to ten times or more. There is also a socket for an Atari blitter chip if your machine didn't come with one. You can get these from your Atari dealer. These boards originally sold for around $300. Schematics and PAL equations are available on request. Complete instructions are included. DON'T try to install one of these if you are not handy with a soldering iron and haven't done this kind of thing before! I will not be liable for your mistakes. If you want one of these, call or send a check to: Steven R. Fordyce 6913 Sunnyview Rd NE Salem, OR 97305-9543 (503)362-8637 Steven R. Fordyce uunet!sequent!ether!stevef ------------------------------ Date: 23 Sep 91 10:38:44 GMT From: arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!wupost!waikato.ac.nz!aukuni.ac.n z!kcbbs!kc@arizona.edu (Jon Clarke) Subject: All BBS sysops. To: Info-Atari16@naucse.cse.nau.edu To the syops out there with FoReM, Express and the likes. We have just set up a FNET node here in the Pacific (New Zealand) which is run by Z*NET South in Wellington. We are looking for other sysops in the Pacific basin to join in and or in any part of the world. Please email me or I can drop a note here for all to read and send to their favorate syops. To the MBBS users and Sysops out there we have Usenet .MCL file if you are interested in it please also email us. A copy was sent to the Bath BBS in the UK but I have never _heard_ back from them so I guess they went off the air. - Jon Clarke Z*NET International Sysop of Z*NET Pacific BBS, in Auckland New Zealand. {there is even an Atari in Antartica!} ------------------------------ Date: 22 Sep 91 17:59:16 GMT From: noao!ncar!asuvax!cs.utexas.edu!samsung!caen!uwm.edu!linac!convex!rosenkra@arizo na.edu (William Rosenkranz) Subject: ARJ? To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep22.140142.12168@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >In article <1991Sep19.232557.10878@convex.com> rosenkra@convex.com (William Rosenkranz) writes: >> [ i rationally plead for non-GEM version of ARJ, calling for a seperate >> GEM shell for desktop use, then i see this: ] >Note: I brought a Atati because of its Gem capabilties, very easy to >use and learn, but you keep on about CLI, Why do you live in the >dark ages. first of all, i am NOT saying don't make ARJ use from the desktop impossible. i AM saying don't make ARJ use from a command shell impossible (like using it in scripts or as part of a rule in make). i am not being fascist here. i am not restricting YOUR life. go ahead an use the desktop. go ahead and use ARJ from the desktop. second, most of us that program the codes you use for free, find it virtually impossible to program from the desktop. it is just not efficient at all. if you write more than 500 lines of code a week you would agree. if you are scratching you head right now wondering what "make" is that i mentioned in the above paragraph, you do not fit in this category. the "dark ages" are infinitely more productive for programming than the "ultra-modern" GEM desk top. without multitasking windows (which GEM does NOT feature), a robust set of GEM-based tools (none of these, either), the desktop is only ok for running applications. please do not impose on me or scores of other developers your concept of what we should use. don't be a fascist... > If I wanted CLI, I would have brought a PC, I am one for things >that are easy to use, that is how you get more productivity. >If you what to stay with your Steam Engine, why not go play with it, >in the Museum. geez, what can i say :-) have you ever used a $250,000 high-end state-of-the-art workstation or a $25,000,000 supercomputer? i got news for you: they ALL have CLIs for using them. they ALL use unix (with few exceptions like CTSS, LTSS, COS for crays). since when does atari's GEM desktop (which is not even multitasking) better than unix for programming? sheesh. you are obviously not using the ST the way i do. i WANT the st to look just like my good ol' vt100 screen which i use at work on unix boxes. that means a real unix-like shell. for your information, CLI's are almost always 1) more productive, 2) FAR more versatile, 3) prefered by programmers. and note that windowing systems on workstations run CLI's in windows. the only difference is that you get more CLI's on the screen at once and can cut and paste between them. it is still a CLI, however. now leave me alone... the ST is a very nice platform for development because unix utilities port easily and hence make it nice do work like you would on workstations and other unix boxes, even supercomputers. here is another aspect: how do you list all lines in a file which contain a certain string? you run grep.ttp. but this is not a GEM application so you type in the dialog box its arguments. now how do you find a file named "xxx.dat" on a hard disk? you run find.ttp. but that is not a GEM application either so you type in the dialog box its arguments. keep this up with about 50 other utilities commonly used by programmers and you see that you might as well just enter them on a command line anyway. if you provide me with GEM versions of ALL the utilities i regularly use when programming i might be persuaded to go to the desktop. i also want to do the grep and find AT THE SAME TIME like i can with a CLI (with minix or MiNT). so go ahead and make GEM multitask while you're at it. until then don't make stupid statements like CLI's are from the "dark ages". in fact there is only one desktop approach that comes close to productive use without a CLI and that is probably NeXT. even they offer CLI's, however, since there are IMPORTANT things to do which can't be done (or are not available) with a desktop metaphor. the Mac may have reasonable programming tools as well from its desktop but i don't have a Mac. and i am a reasonably proficient typist so why should i not use this skill? i spend 75% of my time typing data into a file with an editor. you would too if you were a programmer. so why should i move my hands off the keyboard, slowing me down, if i am spending all my time typing anyway? or do you have access to some system that programs with mouse clicks? if you do, i am sure lots of people would be interested. i also use my ST to connect to my system at work (which is obviously not GEM based, thank god :-). that means i type. again, no mouse. those of us born before 1970 (1960?) remember typing our programs on cards with key punches. an interactive CLI was like a jump into the 25th century by comparison. the GEM desktop, however, is not. it makes life easy for users but not for programmers (who write the programs users use). why do you want to slow us down and cut the production of programs you need/want/use? an archiver is probably more important for me because of my 80 MB of hard disk, about 1/3 or more is source code, mostly archived. it has to be solid. i'll challenge you to a duel: we each write, compile, and execute a significant application, you exclusively from the desktop, me from a CLI. we use the same compiler (say gcc). guess who will get done first? and note that the standard desktop limits the number of args to .ttp programs. i regularly execute programs with 100's of characters on the command line. to go thru a GEM version would mean clicking on scores of buttons to execute say a compiler. and i'd still have to type in file names anyway (unless the desktop can now read minds :-). to re-execute the same command could mean re-clicking. with a cli i just type "!c" (to execute the last command starting with the letter "c", say the compiler "cc") or equivalent, all without my fingers leaving the keyboard to reach for a mouse. this is how i use MY st. how you use yours will not in the slighest be impacted by a GEM shell for ARJ. a GEM-only ARJ will severely impact me, however. i don't think you really understand the difference. i have proposed a scheme to allow you to use it the way you want while you are suggesting a scheme where i cannot. what gives you the right and the wisdom to do this? who are you to tell me (and other developers) how we should use our computers? and why should i go out and buy a compiler for $200+ to get an integrated (perhaps GEM) environment when i can get a portable compiler (gcc) for free? and it gets updated far more frequently than say turbo or lattice C. and it is supported by top-notch programmers (esmith and bammi, et al) who understand my needs since theirs are similar. and gcc runs on unix boxes and can generate atari executables. this is not true of borland or lattice compilers as far as i know. sorry for the vented spleen, but i just get PO'd when i read stuff like this... >What is wrong with Thomas Questers version of Lharc, it is fully >compatible with the PC version, and a lot better, plus it supports >all the othere LZH/LARC Formats and Unix ones as well, and Note. >packs far better than all the otheres, and is blindly fast. there is no source available. he also added lh5 format which is not generally available on other platforms. it has also no english docs or screen help (except possibly only very recently tho 2.01c i believe still spits out german with no args - and it has been 20 years since i last read/spoke german [high school]). it is also written in assembler (mostly?) so it will not port to anything else. i even volunteered to thomas to help him port the sucker to unix if he sends me source, but have so far not seen hide nor hair of it (just the executables). if TQ's lharc is so good, then a unix version will help make it universal. then it could port to VMS and MSDOS as well. then TQ will be the lord of lharc :-) as long as he maintains it like rahul dhesi does with zoo. also, i think i have a version of TQ's lharc which unpacks files with the wrong date, tho i have to double check this (i tested about 10 lharc programs one day and several had this problem, one of which was one of TQ's, i believe). if this IS the case, this is totally unacceptable. i need the date to be exactly the same as it is in the archive since i use tools which only work based on the date of files (e.g. make and RCS). if an archiver can't get this correct, it is absolutely useless, no matter how fast or efficient it is. unfortunately, if it packs with lh5, you may not be able to unpack it on (say) a unix or VMS system. and believe me, MANY people want to be able to do this, even if you don't. so tho it can handle any lharc, it itself generates files which are incompatible. and i don't want to spend half of my life figuring out what is the latest version of lharc on 2 or 3 different platforms EACH WEEK. of all the lharc's out there, TQ's seems to be the most robust, tho it has its problems. there are so many versions out there that for compatibility alone, zoo should get the nod for information exchange on the net. what you do at home is your business. go ahead and lharc everything. just don't shove it down my throat. zoo is centrally supported (like arc) on all platforms. lharc is not. every system (PC, ST, amiga, etc) has its own (incompatible) versions, even on the same system. that, pardon my french, sucks. if you think not, just read some of the pleadings by other people on this net saying "i can't extract .lzh with my version of lharc". happens every week. i have every version of lharc i can find on the ST (including 3 or 4 of TQ's programs). this is a huge waste of disk just to satisfy my paranoia that i will be able to extract any .lzh that happens my way. in contrast, i have but 2 arc (arc 5.21 and 6.02) and 1 zoo (zoo 2.1). i can extract ANY non-corrupt .arc or .zoo with these (and in the case of zoo, with fiz i can often extract parts of corrupt files). this is not possible with lharc either (as far as i know). zoo 2.1 gives about the same compression ratio as lharc. and i know it won't get screwed up too badly by 16 people trying to "improve" it. and it will probably be optimized fairly soon so that it runs like tuned lharc version. personally, i'd sacrifice 2x the speed (on compression) just to get the compatibility. how many times do we have to go thru this? lharc should be banned, no matter how "blindingly fast" or how tiny it makes files. that is not the issue at all... >PFX will pack programs, and will save a lot of disk space. pfx is nice. i do use it on occasion. i plan to use it more now that i have switched form alcyon to gcc (compilers). gcc tend to make larger executables. and if TQ would mail me source to pfx (so i don't have to disassemble it) i will even send him a shareware contribution (hint, hint, thomas :-). -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 22 Sep 91 19:52:47 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!samsung!umich!terminator!terminator.cc.umich.e du!weiner@arizona.edu (Jeff Weiner) Subject: Atari.archive monthly posting To: Info-Atari16@naucse.cse.nau.edu Welcome to atari.archive.umich.edu This is the monthly posting from the umich atari posse. We hope it will answer some of those nagging questions that always seem to pop up from time to time. If you have any additional suggestions, please mail them to me, at weiner@atari.archive.umich.edu. [Changes from month to month are marked with a * for easier reading] 1: How do I use BART? Use bart by mailing atari@atari.archive.umich.edu and using the word "help" as the body of the message. This *should* send you a help file. If you have read the help file, and still have questions, please send them to jon@atari.archive.umich.edu, not me. 2: How can I connect via FTP? If you are interested in ftp, I recently wrote a beginner's guide. Please mail me and I will send you a copy. I'll post it every once in a while too. It's also available in the 3: What if my machine doesn't support name service? Two things to do here:1) Demand that your sys-admin install it soon, and 2) use the internet address 141.211.164.8. Be forewarned however, this may change on a moments notice. 4: I can't download because my hard drive doesn't work and my modem goes out sometimes and .....HELP!!! Sorry, outside of the archive I really can't help you....Your best bet is to find someone at your site with a similar set-up, or post to c.s.a.st for advice. 5: What are all the ???s in your index? The ??? symbol means that I have no clue what this file is. If you know please drop me a note, but be sure to include what directory the file is in, etc. Thanks. 6: When I try to FTP to the archive's host, I get a message saying that my machine wasn't recognized and I wasn't allowed to log in. What's up? We only accept ftp logins from recognized hosts. If you are not allowed to log in, please try again. It is possible that the DNS took a bit too long. If you are still denied access, ask your sys-admin to fix your name servers. 7: Here's a question for you Jeff, how come I can't use 'ftp terminator.cc.etc' any more to connect? That's because you're not using atari.archive.umich.edu like we told you to. Don't say we didn't warn you......The name of the host and/or the host itself may change soon. There are a few files you'll really like to have: archivers/arc602.arc : The latest version of arc archivers/zoo21bin.zoo : The classic archive program archivers/compress.zoo : Useful for removing .Z from sounds and binaries archivers/unlzh172.arc : Unpacks .lzh files archivers/sttar.arc : Removes those nasty .tar extenders THEY ARE CONTAINED IN THE SELF EXTRACTING ARCHIVE starter.tos!!! PLEASE USE IT! * Please don't archive anything for uploading in arc6.02, unless you want to provide me with the unix sources for it. I didn't think you wanted to ...... HOWEVER, I'd be happy to accept zoo2.1 uploads. Thanks to everyone who has uploaded anything lately..... * Interesting things this month: 1. The other umich archives are starting to gain popularity. You may want to check them out. They are located at archive.umich.edu. All except the atari archive are housed there. BART PROBLEMS: * There haven't been many lately. Things seem to be moving smoothly. There was no down time for BART in the past month. * Once again, BART problems go to JON, not ME. PLEASE NOTE: FTP service is a privelege, not a right! Please make a supreme effort to keep heavy FTP use in off-time hours (i.e. after 5 pm EST but before 8 am EST), or else you will be shot. (We mean it). Any ideas, questions, comments, etc. to me, weiner@atari.archive.umich.edu -- Jeff Weiner --- weiner@{ub.cc, um.cc, atari.archive}.umich.edu Corner of Packard and State, 2nd house from Blue Front on Arbor Couldn't think of a witty saying to go here - give me some time ------------------------------ Date: 23 Sep 91 10:28:04 GMT From: noao!ncar!asuvax!cs.utexas.edu!wupost!waikato.ac.nz!aukuni.ac.nz!kcbbs!kc@arizo na.edu (Jon Clarke) Subject: BBS request, here is two from NZ. To: Info-Atari16@naucse.cse.nau.edu Name : Z*NET Pacific , STaTus BBS Phone : (011-649) 606067 (011-649) 608485 Storgae : 1,300 megabytes Location: Auckland New Zealand Software: Michtron Version 3.0 Baud : 300,1200,1200/75,2400,9600,14.4k in PEP -=-=-=-=-=-=-=-=- Name : Z*NET South , Harbour Board Phone : (011644) 762852 Storage : 60 megabytes Location : Wellington, New Zealand Software : FoReM ST with FNET conferences to the USa and UK Baud : 300,1200,1200/75,2400 Hope this helps Dennis. Jon Clarke, Z*Net International Online Magazine Sysop Z*NET Pacific, the STaTus BBS in Auckland, New Zealand. (The telecom capital of the global village) ------------------------------ Date: 22 Sep 91 07:37:45 GMT From: noao!asuvax!cs.utexas.edu!utgpu!watserv1!bmaraldo@arizona.edu (Commander Brett Maraldo) Subject: Deactivating your 520ST RAM (for upgrading) To: Info-Atari16@naucse.cse.nau.edu In article steve@thelake.mn.org (Steve Yelvington) writes: > > My feeling of this is that you NEED (i never read you did) to remove or > > at least deactivate the 256K Chips , which normaly reside in BANK 0 > > In the case you forgot that, the hardware gets into VERY big Trouble when > > reading from the rams at an Address greater than 512K. If you leave the > > HIGH Address line unconnected (MAD10 i think) the system reads and writes > > into the same bytes, which shouldn't make any Problems. >How do you do this (temporarily)? I have an old nearly-original 520 (with >modulator, without floppy) that has a half-populated Tech Specialties You do not have to remove the 16 256k drams to deactivate them. To put the chips into a low power standby mode you put CAS0 and CAS1 high. This is easily accomplished: 1) locate resistors R135 and R136 2) desolder the left lead from each resistor from the main board - this is the left lead with the board oriented component-side up, with the connectors furthest from you. 3) connect the desoldered leads to +5V (pin 8 of the memory chips) If the 520 doesn't have R136 and R136, you can disable the memory row by putting RAS high. Cut the trace leading from pin 8 of U15 (RAS on MMU) to pin 4 of U16 (sometimes U17). connect pin 4 of U16 to +5V. Brett L Maraldo -- -------- Unit 36 Research --------- "Alien Technology Today" bmaraldo@watserv1.UWaterloo.ca {uunet!clyde!utai}!watserv1!bmaraldo ------------------------------ Date: 22 Sep 91 06:18:07 GMT From: noao!ncar!asuvax!ukma!gatech!mailer.cc.fsu.edu!bind!boyd@arizona.edu (Mickey Boyd) Subject: dump files To: Info-Atari16@naucse.cse.nau.edu In article , lahtinen@gideon.gideon.fmi.fi (Kimmo Lahtinen) writes: > >I am looking for a programs that lets you see (in hex and ascii) a file >and perhaps also edit it. There should be some programs like this, so >I think it is not worth doing it myself. I have been using DLII, but >it quite complicted to go to the file editor. The best one I have seen is Memfile, by the same guy that did Neodesk. It is PD or Shareware, and available via ftp from atari.archive.umich.edu. It is a memory/file/sector editor. There was also a really neat German pd or shareware program, but it did not like my Neodesk installed font. -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Kirk to Enterprise. All clear FSU Computer Science | down here. Beam down Technical Support Group | yeoman Rand and a six-pack . ." email: boyd@nu.cs.fsu.edu | ---------------------------------+------------------------------------- ------------------------------ Date: 22 Sep 91 06:26:22 GMT From: noao!ncar!asuvax!ukma!gatech!mailer.cc.fsu.edu!bind!boyd@arizona.edu (Mickey Boyd) Subject: Emulate? What about the other way. To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep20.151133.5618@bdt.com>, CATHRYN@bdt.COM writes: >How about an ST emulator card which would fit into a slot of a PC clone. So I >could run old ST software and clone software without having computers take >over the house! Derek M (the author of STXFormer, the software 8-bit emulator) has stated that he is/was working on a software ST emulator for 80xx6 platforms. The "Gemulator" can supposedly blow an ST out of the water on a 486. I have not heard a followup on this for some time (I read about it in Current Notes some months ago). This should be interesting if it ever appears . . . . -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Kirk to Enterprise. All clear FSU Computer Science | down here. Beam down Technical Support Group | yeoman Rand and a six-pack . ." email: boyd@nu.cs.fsu.edu | ---------------------------------+------------------------------------- ------------------------------ Date: 22 Sep 91 06:39:04 GMT From: netcomsv!seitz@decwrl.dec.com (Matthew Seitz) Subject: ESDI harddrive To: Info-Atari16@naucse.cse.nau.edu In article <8774@squire.cme.nist.gov> chang@lurch.cme.nist.gov (Forrest Chang) writes: > >I figure I'll have to get an atari->scsi host adpater and then a scsi >to EDSI [sic] adapter if such a beast. Yes, there is such a thing as an ESDI to SCSI adapter. My company uses the Emulex MD-23 ESDI-SCSI controllers. Each MD-23 allows up to four ESDI drives to be accessed from the SCSI bus. One nice benefit of this approach is that the four ESDI drives share just one SCSI ID (they have different SCSI LUNs). Theoretically, one could hook up 28 ESDI drives to your system this way. In theory, this should work. However, I have never attempted to use an MD-23 to hook an ESDI drive to an ST. -- Matthew Seitz seitz@netcom.com ------------------------------ Date: 22 Sep 91 08:23:14 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!ninjam@arizona.edu Subject: Gif viewer To: Info-Atari16@naucse.cse.nau.edu Does anyone kow where I can get ahold of a GIF viewer for my 520 st? Thanks......... ------------------------------ Date: 22 Sep 91 11:55:23 GMT From: arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!@ arizona.edu (LarsErikOsterud) Subject: Mega/STE Screen Shifting To: Info-Atari16@naucse.cse.nau.edu The last weeks several people having the same trouble with their new MEGA STE has asked me how we fixed mine, and I hope this file can help you fix it. It's really the best machine Atari has made so it would be terrible not to have it in perfect condition :-) Errors on DMA-sound and video on MEGA STE - HOW WE FIXED IT ! """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Here's a summary of what we found at service in Norway. First - the errors on both machines we discovered were: - Static/noise on DMA sound and MIXed standard ST sound. - Sync-problems when using Spectrum512 pictures (vertical bars). - Vertical flickering bars on monochrome (most at 8 MHz). - Right edge of monochrome screen "flips" over to left edge when changing screen adress/resolution in mono-mode. We tried to find a chip that could be the cause of all these problems and found a big VLSI chip partly hidden under the right edge of the VME-card holder. It's chip U502 on my MEGA STE and is called GSTSHIFTER on the print-layout. After looking at the print-layout on both MEGA STE and standard STE we found the same chip on standard STE, a combined sound/video chip but with a totally different part-number. Anyway, we removed the original MEGA STE chip (made in 1990) and replaced in with the STE chip (from 1989) and all the problems were gone. If you want to "steal" a chip from a standard STE it's chip U401 inside the STE (still GSTSHIFTER). Disclaimer: Even though this solved the problems for us it might not work for all MEGA STE's and you do this at your own risk (I still would like Atari Corp to give some official information on this. It's not "ONLY YOUR MACHINE" anymore. It's quite a few...) Lars-Erik / Registered Developer / ABK-BBS +47 2132659 / ____ ______ 0sterud / w/ Atari Scandinavia / larserio@ifi.uio.no / /___ / __________/ _______________________/ ______________________/ ____/ / ------------------------------ Date: 22 Sep 91 01:49:00 GMT From: ubc-cs!fornax!wolfgang@beaver.cs.washington.edu (Wolfgang Jung) Subject: Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?) To: Info-Atari16@naucse.cse.nau.edu In article steve@thelake.mn.org (Steve Yelvington) writes: >[In article <1991Sep21.030908.985@cs.sfu.ca>, > wolfgang@cs.sfu.ca (Wolfgang Jung) writes ... ] > > > My feeling of this is that you NEED (i never read you did) to remove or > > at least deactivate the 256K Chips , which normaly reside in BANK 0 > > In the case you forgot that, the hardware gets into VERY big Trouble when > > reading from the rams at an Address greater than 512K. If you leave the > > HIGH Address line unconnected (MAD10 i think) the system reads and writes > > into the same bytes, which shouldn't make any Problems. > >How do you do this (temporarily)? I have an old nearly-original 520 (with >modulator, without floppy) that has a half-populated Tech Specialties >piggyback board. I'd like to bring it up to 4MB, since chips are >practically free these days, but to do so I need to disable bank 0. I'd >like to do that without having to get a bunch of chips desoldered -- in >case it doesn't work and I have to restore the original setup. There are 3 Lines which need to be disconnected to the old chips and also to be set to a certain Level (Are they High or low activ, if High active tie them via a 1Kohm Resistor to GND and if activ low tie them via a resistor same type to +5V) The Lines are CAS0H CAS0L RAS0. You need those for the SIMMS, and normaly there are resistors via which CAS0H and CAS0L are connected so there is an easy way to re/connect them if nescassary.. RAS0 (also RAS1) has no resistor to use for this kind of thing, BUT it shoulb be running OK without disconnecting RAS0, becasue only in conjunction with the CAS lines the RAMS get selected and selects the specific BITS, it will refresh those old 256K Rams but that should't cause any Problems, except for the loading the MMU (depends on the builddate .. I think the oldest are the ones which are capable of accepting the MOST load.. Bye Wolfgang -- Note: Please Use woju@cs.sfu.ca as Address after Monday the 9th Sept After 25th Sept mail to woju@mist.sub.org ------------------------------ End of Info-Atari16 Digest ******************************