Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site imsvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!gatech!seismo!elsie!imsvax!bob From: bob@imsvax.UUCP (Bob Burch) Newsgroups: net.micro.atari Subject: 256K 800XL Lives (Part II) Message-ID: <480@imsvax.UUCP> Date: Mon, 16-Dec-85 22:09:24 EST Article-I.D.: imsvax.480 Posted: Mon Dec 16 22:09:24 1985 Date-Received: Thu, 19-Dec-85 04:25:22 EST Organization: IMS Inc, Rockville MD Lines: 166 The following article has been passed down from CompuServe. It applies to the original circuit described in "The Quarter-Meg Atari" by Claus Buchholz in BYTE of 9/85. ========================================================================= 256k 800XL Ram Disk Controller -------------------------------- Vers. 1.0 10/29/85 This is an enhanced version of the original Ram Disk Controller for a 256k 800XL as described by Claus Buchholz in his construction article which appeared in the Sept. '85 issue of BYTE magazine, pg. 247. Added is the capability to change the density of the ram-disk with multiple density DOS systems. This is accomplished via the PERCOM config block standard. Information on this subject can be found in the Oct. '85 issue of COMPUTE! magazine, pg.110. Many thanks to Bill Wilkinson for writing that article, without which, this function would not have been possible. The other major additon to this controller is the use of another drive while in single density mode. This gives the user the same amount of ram-disk storage regardless of which density is active. I have also included some primitive diagnostic routines that check the operation of the ram upgrade. Also, a hook has been added to the immediate vertical blank routine that will enable the HELP key to 'cold-boot' the computer without turning it off, toggle sound output for ram-disk access and a toggle to modify screen and characther color for compatability with monochrome monitors. 1). - Density default and changing density. There are two versions of this controller, ERAMDSK1 and ERAMDSK2, they differ only in the default density setting when the system is first loaded. The drives recognized are D3: and D4:, the latter active only when single density is selected. Changing densities requires one precaution if you are switching from single to double density. Do not change D3:, use D4: instead. This will prevent a fatal I/O error from occuring if the DOS your using lists the state of all drives after one is changed as is the case with the CONFIG command in DOS XL. If that is the case, D4: will appear to be active but, if you list the active drive table again, D4: will then be inactive. 2). - Format and diagnostic routines. Initialization of the drives takes a little longer now that a ram test has been included to check the memory in each of the 6 banks, (0-5), that comprise the ram-disk. I have also included a check for the bank select logic circuit. At the end of the ram test for each bank, the location $00FD is written with the number of the bank in use. When the ram-test phase has concluded, a loop check of the same address in each bank is performed to verify that 6 distinct banks exist. If a format error is returned during an initialize command, ad- dress $CC06 will contain the type of error that occured. Locations $CC00 through $CC05 hold the results of the error as follows: $CC06 = 0 - No errors, operational. 1 - Ram test failure. 2 - Select logic error. Ram test failure results: Select logic results: =========================== ======================= $CC00 - Bank # of bad address. $CC00 - 00 ( Bank 0 ) $CC01 - Page # of bad address. $CC01 - 01 ( Bank 1 ) $CC02 - Address in page. $CC02 - 02 ( Bank 2 ) $CC03 - Data expected. $CC03 - 03 ( Bank 3 ) $CC04 - Data received. $CC04 - 04 ( Bank 4 ) $CC05 - 05 ( Bank 5 ) If you have a select logic problem you will most likely see some sort of sym- metry with the data in $CC00 through $CC05, for example, 00 00 02 02 04 04 would indicate a problem that results in the least significant bit of the bank select circuit not being set. A problem with the ram test is not as hard to solve as the select logic. Not to say that there isn't a multitude of things that can go wrong with dynamic ram. But please take note that this ram test is only capable of finding a simple failure, not intermittent or other bizzare malfunctions. Also, only the first error encountered will be recorded before exiting the format routine. If there are multiple errors they will only show up after the first error has been corrected. The two types of failures that most often occur are either total chip failure (dead row or column) or one dead bit. The first failure would almost certainly prevent the computer from successfully completing a boot pro- cedure, swapping one ram chip at a time and booting will usualy locate the offending chip unless two or more chips are faulty (mail order rejects). This test is centered on the second common error, to find the bad chip in this case is a straight forward process. Compare $CC03 and $CC04 to determine the bad bit, change the ram chip according to the following table: Bit 0 - Chip U09 (closest to power switch) " 1 - " U10 " 2 - " U11 " 3 - " U12 " 7 - " U16 " 6 - " U15 " 5 - " U14 " 4 - " U13 (furthest from power switch) 3). - HELP key functions. There are three functions that are controlled by the HELP, SHIFT and CONTROL keys as follows: - toggle screen modifiers. - toggle ram-disk access sound. - perform cold boot. The screen modifiers update the values of character lumenence, background and border colors and left cursor once every vertical blank. This is included as a convienence to users of monochrome monitors so the intensity and contrast cont- rols don't have to be continualy changed between programs. The left margin is also set to 0 when this toggle is active. The sound toggle gives an audible ap- preciation of the speed of ram-disk use. The cold boot has been included be- cause the reset hook can be stepped on when a lock-up or other sort of problem occurs. This way, the data in the ram-disk will not be destroyed because the computer doesn't have to be turned off in order to cold boot the system. I am fairly confident that this hook will not be disabled during operation, but, if you do experience something strange try to leave me a detailed account of what went wrong so that I can prevent it from occuring again. One final note about the cold boot, the burst of broken horizontal lines that appear for a short time when the system is first turned on will not show when a keyboard cold boot is initiated. I have used this controller with DOS XL, DOS 2.0 and DOS 2.5 with no problems at all. I use Amodem 4.89 for telecommunications with two Indus GT disk drives running under DOS 2.5, and except for an occasional lock-up with the capture buffer when Atari translation is in use, I've never had a problem, typical time for a full buffer (22K+ bytes) to dump to a single density ram-disk takes only 25 seconds! I can't comment on any other DOS systems, you have to find out just what is and isn't compatible. If you have any suggestions, please leave me a message via EASYPLEX, I'm not able to get to read the forum message base often enough. John P. Radigan (76545,201) Of note to DOS XL 2.3xx users: INIT.COM has a bug that doesn't let you initialize D4:, to correct this you need a sector editor. On a single density disk with INIT.COM on it, examine sector 2 of the file, byte 4 should be a $35 not $34, change and save the sec- tor and INIT.COM will now work. The two files DOSXL.SUP and DOSXL.XL are extended memory configurations that gives the user additional free memory. Do not, at any time, use DOSXL.XL, it will not work with this controller. DOSXL.SUP will work fine with DOS XL 2.30 and this ram-disk, but, DOSXL.SUP will not work with DOS XL 2.35i. For users with Indus drives and synchromesh, please note that DUPDSK.COM and DUPDBL.COM while functional, have a rather obscure bug that turns off Synchro- mesh after writing to the ram-disk the first time. Synchromesh will re-activate at the end of the duplication. I contacted Indus but they feel that this is a trivial bug that probably won't be corrected because it only happens when a non-Indus drive is the destination. I have found that COPY Dn:*.* Dn:*.* is actually faster in this instance. Finnaly, by copying all your .COM files to the ram-disk and changing your default drive to the ram-disk you will see that extended commands such as COPY are now painless. MAC65.COM for example, loads in under 4 seconds. A double density drive would take 11 secondes with synchromesh engaged to load, 22 seconds without synchromesh engaged.