-------------------------------------------------------------------------- FAQ: HOW TO UPDATE YOUR A590 TO MEET TODAY'S REQUIREMENTS a.k.a. A590 and Guru-ROM V6 in perfect harmony, how? Version: 1.3, Date: Tuesday, 11th May 1999. Maintained by Timo Rönkkö . -------------------------------------------------------------------------- The purpose of this document is to help out the owners of A590, but this information could be partially useful to A2091 owners as well. However, the use of good, old-fashioned common sense is recommended. As usual, standard disclaimer applies: it's your own risk, and the author of this document can't be held liable for anything. I.E., if your cat gets run over by a car and/or if your house burns down, it's still your own problem. This document covers the most common A590 related questions and tries to give satisfying answers as well. If you haven't wondered about these things before, maybe it's about time. After all, the A590 is indeed showing it's age in some aspects. -------------------------------------------------------------------------- Q: Drives bigger than 1 GB won't work properly, what's wrong? A: The 6.6 ROM's (afaik, the last version) from Commodore can only access blocks up to 2,097,152 (two million, ninety-seven thousand, one hundred and fifty-two). Keeping in mind that one block equals 512 bytes, this forms a barrier at 1 GB mark. Q: Could I cheat by changing the volume blocksize to 1024, 2048...? A: No, this doesn't work. The 1 GB problem remains. Q: Is there anything I could do to fix this problem, then? A: The simplest solution is to surf to http://www.schatztruhe.de and place an order for "Guru-ROM V6 for A2091". This is a whole new driver ROM, making the problems of the Commodore one a thing of the past. Q: How much does this Guru-ROM V6 cost? A: 99 DM (at the time of the writing, it equals roughly 51 Euro's or 56 US dollars) + postage & packing. It may sound expensive for a "mere" ROM update, but trust me when I say: Guru-ROM V6 is rock-solid quality work. The ROM is hundred times worth it's weight in solid gold once you get properly acquinted. Without exaggeration, it's as if you had bought a whole new controller! Q: Does Guru-ROM V6 have any specific hardware requirements? A: The DMAC chip on your controller needs to be revision 2. It's easiest to check this using "ShowConfig". The right kind of DMAC would show up as "Prod=514/3" in the output. If you really insist on checking out the actual chip, it's the big, square Fat Agnus-lookalike chip right about in the middle of your controller. It should be labeled "390563-02". It's quite impossible to miss it: just look for the biggest chip! Other than that, Guru-ROM V6 will happily run on any 680x0 processor (even on Kickstart 1.3), and there's no need for a new SCSI controller chip either! Q: All this sounds too good to be true, so what's the catch? A: Except for the dropped XT drive support (let's face it, when did you last see anyone use OR own one anyway?), everything works just like it used to, only better. The only problem I can think of, is the height of the ROM adapter. Whereas the original Commodore ROM was divided on two chips, the Guru-ROM V6 is on just one. The ROM adapter was originally designed for the A2091 (where there's more room), so getting an internal drive to fit in the A590 case may be hard. Q: How did you solve the ROM adapter height problem yourself? A: Well, I haven't had use for the A590 case in years, instead my drives are piled on the table and on the controller. All I did, was to cut a hole - just the size and shape of the ROM - in the metal shielding, and placed two plastic PlayStation memory card covers on the metal shielding behind the ROM chip; as to smoothen the surface a bit for the CD-ROM drive. ;) Q: I can't find JP2 or JP5 on my A590 PCB like defined in Guru-ROM V6's A2091 manual addendum, now what? A: Not to worry, there are four dip switches behind your controller, and they look like this: +---+---+---+---+ on (short/close) |#*#| | | | | |#*#|#*#|#*#| +---+---+---+---+ off (open) 1 2 3 4 A590 dip switch A2091 PCB jumper Effect when enabled --------------- ---------------- ------------------- 1 ............... JP2 ...................... No driver 2 ............... JP5, connector 4 ......... Suppress initial SDTR 3 ............... JP5, connector 2 ......... (unknown) 4 ............... JP5, connector 1 ......... Ignore RDB By default, switch 1 must be enabled and switches 2-4 disabled, just like the small graphic above shows. Q: I'm suffering from occasional SCSI-bus hangups. Could this be cured by Guru-ROM V6? A: Well, I used to suffer from SCSI-bus hangups from time to time, even though my devices were properly terminated. This usually happened, when accessing several devices at once, like copying something from one device to another. Under Guru-ROM V6, this has never happened again, even if I've tried to tease it the best I can. :) Q: What about performance, then? Can I expect a dramatic increase? A: I'd say it's pretty safe to expect that. Here are RawScsiSpeed results from my A500+: (buffer size 262144 bytes, synchronous transfer mode) read speed: 3139918 bytes/second write speed: 3165427 bytes/second (buffer size 262144 bytes, asynchronous transfer mode) read speed: 2277358 bytes/second write speed: 2284642 bytes/second For the test duration, the SupraTurbo accelerator I have was disabled, so the machine was running on 68000 @ 7 MHz. The tests were executed on an otherwise clean boot, except for running SetPatch v43.6b. Of course, test results are never the same as real use, particularly when it's raw SCSI speed we're talking about, but this should give you at least some clues what to expect. Under the Commodore 6.6 ROM's, the throughput was 1.4 MB/sec at it's best, even though my SCSI bus controller chip is a 33C93A. It doesn't seem to make a difference, whether your SCSI bus adapter chip is a 33C93A (better of the two) or a 33C93 (worse of the two) under the Commodore ROM's. Under Guru-ROM V6, the difference for 33C93A's favor is _significant_ (~220%) speed increase. Q: I'm a Guru-ROM V6 user and my Amiga isn't the fastest in the world. During disk access, the DMA eats up an excessive amount of resources. Is there anything I could do about it? A: All those imaginative enough, who've read the excellent Guru-ROM V6 manual with some thought, must've figured the GvpScsiCtrl's serialpatch feature could be (mis)used to work this around. Anyways, the idea is to split the DMA chunks into smaller pieces so that your Amiga has the chance to "catch breath" often enough. Placing the following line in your startup-sequence or user-startup will do the trick: run >nil: gvpscsictrl SERIALNAME timer.device CHUNKSIZE 32768 SERIALPATCH At least for me, the chunksize of 32768 bytes is a nice balance between speed and system usability. The smaller the chunksize, the more resources will be available to you during transfers, but the slower the disk access will be. Experiment and find one that suits your configuration and personal preference best. Q: Will Guru-ROM V6 enable me to use partitions bigger than 2 GB and drives bigger than 4 GB? A: Yes. Guru-ROM V6 being TD64 (TrackDisk64) compatible, all you need is a filesystem with TD64 support. I personally recommend Professional File System 2, but if you really insist on sticking to FFS (but why?), download disk/misc/ffstd64.lha from Aminet. Q: Professional File System 2, eh? What's that? A: PFS2 is a commercial FFS replacement filesystem, delivering much higher performance than FFS in all given areas. PFS2 volumes are always valid, so you may forget those boring validate-wait times. Using TD64 or direct SCSI, partitions up to 104 GB and drives up to 2 TB (2000 GB!) are supported. And get this, it works on any Amiga with Kickstart 2.0 or higher! PFS2 is an ideal partner for Guru-ROM V6, so I recommend it highly to everyone. Read more about PFS2 in my review, available as docs/rview/pfs2.txt on Aminet. The author's web page can be found at http://www.greed.nl. Schatztruhe are the distributors of PFS2, so you may order both Guru-ROM V6 and PFS2 simultaneously from the same place. Q: What about Amiga Technologies' FFS v43.xx at http://www.amiga.de? A: You should stay well away from Amiga Technologies' FFS v43.xx, as it's known to be compatible-to-nothing. Any piece of software with a mention of "NSD" (New Style Device) in it should be, IMHO, treated like plague. It isn't long ago, that I completely failed to get AT FFS to work on my system, and bugs@amiga.de seems to be be the internet equivalent of Black Hole; comparisons with NIL: and /dev/null can't be avoided. Just say NO to AT FFS. Q: Are there any other advantages, as why to use Guru-ROM V6? A: Well, you can kiss them Mask and MaxTransfer problems goodbye. Under Guru-ROM V6, just set Mask to 0xffffffff and MaxTransfer to 0x7fffffff, and let Guru-ROM work it out. Easy, huh? Other than that, there's tons of new features, such as the ability to write-protect your devices and changing more advanced settings like SCSI parity, synchronous transfers, etc. simply by using OmniScsiCtrl. Q: What about my software? Do I need to make any (dramatic) changes for Guru-ROM V6 to work with what I've got? A: Except for changing all the references from scsi.device to omniscsi.device in mountlists, tooltypes, etc., the answer is no. Everything works like it used to, and if it doesn't, there are user-configurable workarounds to make ill-behaved software enjoy it's stay. Q: What about HDToolBox then, can I still use it with Guru-ROM V6? A: Yes, of course. However, for really big drives, using Oliver Kastl's "HDInstTools" (disk/misc/hdinst.lha on Aminet) might be a better idea. Q: What about DAT streamers? A: No problem with Guru-ROM V6. Just plug & play. No need to plug & pray. All you need is a suitable piece of software supporting the DAT. Q: Is there any 68000-compatible software with tape drive support? A: Well, it's sad some programs choose to be 68020+ only nowadays; the marginal speed increase gained doesn't justify sacrificing compatibility. I say: if it's 020+ only, it's just programmer's laziness! But what comes to tape drive support, Quarterback comes to my mind first. The only requirements being Kickstart 1.2 or above and 512 kilobytes of memory, not too many Amigas out there fail to meet it! As for it's availability, I'm not so sure. However, Quarterback 6.1 & Quarterback Tools were given away on the cover CD-ROM/floppy of CU Amiga Magazine, July 1997 issue. There's also Ami-Back (afaik, it's a Quarterback-like backup program with tape drive support) and TapeWorm-FS (afaik, it's a standard AmigaDOS filesystem, capable to read-only (WORM = Write Once, Read Many) from tape drive(s)), but I've got no personal experience of these programs and the authors seem to have vanished from the face of the earth. I'm sure there are more recent programs out there, but these programs haven't obviously made enough noise to be noticed... Q: Does it make any sense to use DAT on an A500 in the first place? A: It sure does! For the sake of benchmarks, it took 8 minutes 37 seconds to back up 203,643,833 bytes of data on my humble A500 using Quarterback 6.1 with hardware compression enabled (but, since the files mostly consisted of Aminet material in it's still-compressed form, this didn't obviously have much of an effect). That makes the average speed roughly 400 kilobytes per second, just as the specs of my particular DAT tape drive promise (a 4mm DDS-2 Seagate CTD8000H/R-S, internal half-height 5.25" OEM model, SCSI-2). Not bad, eh? Q: Could you explain me this DAT-related acronym, DDS? A: DDS stands for Digital Data Storage. There are several DDS levels, each backwards (but not forwards) compatible. What this means, you can use DDS, DDS-2 and DDS-3 tapes on a DDS-3 device, but you can't use DDS-2 or DDS-3 tapes on a plain DDS device. Here's information about the tape lengths and their respective sizes: DDS 60 meter: 1.3 GB uncompressed, 2.6 GB compressed 90 meter: 2 GB uncompressed, 4 GB compressed DDS-2 120 meter: 4 GB uncompressed, 8 GB compressed DDS-3 125 meter: 12 GB uncompressed, 24 GB compressed DDS-4 150 meter: 20 GB uncompressed, 40 GB compressed The "compressed" figures refer to a case, where the DAT drive supports hardware compression, and the data to be backed up indeed contains enough redundance. A compression ratio of 2:1 is assumed by manufacturers. Depending on the files, the ratio could be better or worse than that. If you take a bunch of already-compressed files such as .lha, .lzx and .zip, there's no way you could get even close to the "compressed" figure. The compression algorithm is yet another Lempel-Ziv variant, called DCLZ. Another thing worthy to be noted is you can't read hardware compressed tapes on a drive, that doesn't support data compression. Q: But I can't afford a DAT! Are there similar, more economical ways? A: I've used Hugo Lyppens' "Video Backup System" for quite some time (something like four years, to be exact); it's not exactly a speed monster but it works, never the less! All you need is an Amiga with Kickstart 1.2 or above, 512 kilobytes of memory, an ordinary VHS VCR with some sort of video signal output feature and serial port where to plug the VBS cartridge (basically VCR video signal -> Amiga serial converter). In some sense, this system could be called a "poor man's DAT". As it happens, VBS has recently become freely distributable (downloadable from the author's web page at http://www.stack.nl/~hugo) BUT you'll only get the software from the web. Somebody really needs to design a real-life version of ST:TNG replicator suited for internet use! :) In the meantime, until such a trinket is invented, I suggest you keep your eyes peeled for second-hand VBS hardware. The MOST economical way (providing you've got spare floppy disks), of course, would be to use Commodore's own bog-standard (read: it's quite horrible) HDBackup to be found from SYS:Tools/ and back up on floppy disks. Happy disc-jockeying! :) Q: I'm looking for a decent CD-filesystem to replace the Commodore one. Any suggestions? A: I suggest you download disk/cdrom/amicdfs240.lha from Aminet. The AmiCDFS distribution archive, besides a good and fast CD filesystem (probably the only thing missing is Joliet support), contains a nice CD player supporting CDDA ID's. Providing, of course, your CD drive supports playing audio CD's. The more recent versions of this CD player (MCDPlayer) don't unfortunately work on plain 68000. Q: The A500 is a dead relic, so why bother with a FAQ supporting it..? A: Well, think about it: how many A500's did they sell in comparison to higher-end (020+) Amiga's, such as A3000, A4000 or even A1200? A500's are everywhere and one can make a very usable machine out of an A500 with very little trouble and expense. It's a reliable workhorse, surely capable to deliver for many computing needs. After all, in relative speed, your humble old 7 MHz A500 still beats an Windows-running Pentium system. "Relative speed" is all the Amiga really has, as in terms of raw CPU power, even the finest 060/PPC combo loses to the high-end PC's of today. I think the lesson to be learned, is that benchmarks shouldn't be blindly stared at, as they don't tell you the whole story. Besides, it'd appear I'm perfectly capable of running OS 3.1 and most of today's programs on my setup, so can you still claim the A500 is dead? As for the games, who cares? Better buy a PlayStation, new Amiga games aren't very special. (With the few really major titles being PC conversions, one could say there's no such thing as AMIGA games!) Q: Hmm?! Errrm, that doesn't quite explain this FAQ... A: Okay, okay! I just want to help out my fellow A500 users out there. After all, we're all brothers in arms and more or less in the same boat. There's nothing in this for me financially, but if I manage to make a difference even in one person's life by encouraging him to alternative things that could be done on a "mere" A500, then I'm happy. Good enough? -------------------------------------------------------------------------- To do: ------ * Test unorthodox devices (ones that you haven't got used to see connected to an A500) such as SCSI scanner(s) and CD-R writer(s). Guru-ROM V6 supports all this for sure, but many questions remain. Such as, does it make any sense to even try to use any of this equipment on an A500? I intend to find out! However, I have none of this equipment and will have to rely on some friendly person to lend it to me for a short while. * Alternative formats for this FAQ, such as HTML and AmigaGuide. * And, of course, cover whatever questions YOU would like to have answered. This FAQ could be stretched to cover all kinds of Amiga medium questions, if there's enough demand. -------------------------------------------------------------------------- Acknowledgements: ----------------- * Ralph Babel, the author of Guru-ROM V6, for providing valuable technical information when I needed it the most. Besides being a nice and friendly person, he's one hell of a coder too! * Great Effects Development, the authors of Professional File System 2, for kindly donating a copy of this excellent filesystem. * Seagate, the manufacturers of many excellent things, for one of the best web pages I've ever seen. There they offer PDF manuals for just about all of their products _ever_, spec sheets, installation information, general in-depth SCSI knowledge... All this is for free, so who could possibly need anything else? Even if you wouldn't have any Seagate-made hardware, this makes very interesting reading! So, be sure to visit http://www.seagate.com. * K-P Koljonen, the author of HippoPlayer, for making continuous background noise possible, without which I'd have had much less inspiration to concentrate (?) on this document. How are those bugfixes coming, by the way? -------------------------------------------------------------------------- Got any additional questions, suggestions or corrections in your mind? Be sure to submit them to the FAQ's maintainer by email! Any kind of feedback (and help) is highly appreciated and welcome. Flames will probably be redirected to /dev/null, though. --------------------------------------------------------------------------