MOONliGhT WORkshop
ThE XL/XE GUidE TO EXpANdEd MEMORy, PART 2
JEff McWilliAMS, AC STAff ColUMNiST
In Part 1 of this series I dug into the technical specifics of how expanded RAM worked. You might be wondering why. After all, the main focus of this series is supposed to be about expanded RAM applications, not programming. Using applications is supposed to be simple. You boot them or load them from DOS, do what you have to do, and then forget about them. Nothing could be easier, right?
Two At One Time?
Suppose you were running two programs at the same time. Things might get complicated then because both applications could try to use the same areas of memory and wipe each other out. That's not a problem for us, though, because we don't run two programs at the same time, do we? Sure we do, all the time! Sometimes I run three at the same time. Have I lost my mind? Humble Atari 8 -bit computers can't do that! Or can they?
What happens when you boot DOS 2.5 on a 130XE? RAMDISK.SYS loads, sees that you have at least 128K of memory, and takes that extra RAM and makes it act like a disk drive. Ever thought about how it does that? It works like this: RAMDISK.SYS loads into memory and stays there, loitering around until DOS or another application requests disk access to D8:. In other words, RAMDISK.SYS is **always** in memory doing its thing. When you load an application from DOS 2.5, you then have two programs running: RAMDISK.SYS and the program you just loaded.
There are other programs that get loaded into memory and stay there, like the R: handler for your P:R: Connection or 850 interface, or the 80 column handler for the XEP80. With all this stuff hanging around in your computer's RAM, something is bound to go wrong sooner or later. Murphy's Law says so, and believe me it does happen. When things go awry for seemingly no logical reason, it's better to have a host of technical information at your command than to languish in frustration not knowing what went wrong or how to fix it. Dealing with expanded RAM is especially tricky because of the way it's implemented on our Ataris. When Atari created the 130XE with 128K, they should have added some routines to the Operating System to manage that extra memory.
Memory Management
Suppose you boot SpartaDOS on a stock 130XE, load RD.COM to set up a RAMdisk as D8:, and copy some files to it. Your files are now stored in expanded memory, which is emulating a floppy drive. Now you load up Textpro XE and load a 40K file from your D1: drive. A 40K file would occupy the main bank, and banks 1 and 2 of Textpro XE. You edit it, move some stuff around, and then save it back to your floppy drive. You exit back to DOS, and examine the files you have stored on D8:, your RAMdisk. Surprise! They're corrupted!
What happened? Both RD.COM and Textpro wanted to use the same memory for their own purposes. The RAMdisk driver was using the extra 64K to emulate a disk drive and store files, while Textpro was trying to use that same RAM to hold your document. Neither one has much consideration for the other, so Textpro simply clobbered your RAMdisk, and all the files that were in it. What if those files represented hours of work you hadn't saved to disk yet? You'd be pretty mad, wouldn't you?
Another Sunnyvale Legacy
If Atari had put memory management routines into the 130XE Operating System (OS), these nasty things wouldn't happen. The RAMdisk program would have let the OS know that it was reserving the expanded RAM for its own uses. When you loaded Textpro XE, it would have asked the OS if it was okay to reserve some RAM to hold your 40K file. The OS would have denied Textpro's request because all expanded memory was already being used by the RAMdisk handler. Textpro would have refused to load your 40K file from disk because it wouldn't have enough room of its own to hold it.
That wouldn't be as bad as Textpro clobbering the RAMdisk! Those memory management routines would have been easy to implement too. This isn't a totally new concept to Atari 8-bit developers. The OS that comes with the Turbo816 card has memory management routines for its 16-megabyte addressing capability as well as memory management routines for standard 130XE banked RAM. The Diamond GOS also had its own HIMEM drivers for 130XE expanded RAM. Programs written explicitly for Diamond were supposed to use the Diamond HIMEM drivers when using any expanded RAM.
I mentioned in Part 1 that Claus Bucholz had changed his 256K upgrade immediately after hearing about the 130XE. Initially his method used 32K sized banks. When the specs for the 130XE became available, Claus modified his upgrade so that it would be compatible with the 130XE. He did this because Atari set the standard for expanded memory. If they had put in memory management, it would have been the standard too. Software written to utilize expanded memory would have done so through the memory management routines in the operating system. Your wordprocessor wouldn't clobber your RAMdisk because it would query the OS for available memory and only use it if the OS said some was available. Atariwriter+ wouldn't clobber your DOS 2.5 RAMdisk, and Textpro XE, the X-COM Wedge, and Snapshot 1.5M would all be happy running at the same time, assuming you had enough RAM to support all three programs.
Atari didn't put those routines into the OS, and there isn't much that can be done about it now. Suppose we all convinced CSS to revise the Ultraspeed+ OS to include memory manage ment routines, or for MyDOS to have them? It wouldn't make a difference because you would have to patch all your programs so they "behave" and use those routines. If you used even one program that ignored the memory management calls, you might as well not use them at all. That one misbehaved program might wipe out all the data that was supposedly reserved by the other utilities you have running. The chances are practically nil that the 8 bit community could patch each and every expanded memory program so they all behaved.
Not having memory management isn't the end of the world. We get by. We've been getting by for years, and we'll continue to do so. Since the computer can't make sure programs and data "collide" by attempting to use the same RAM areas, we have to do it ourselves.
This means knowing which utilities and applications work together, and which ones don't. It may also involve taking extra measures to configure your programs in special ways so that you can use two or more of them together. Being able to do all that requires you, the user, to have that all-important knowledge about how expanded RAM works. You have to be able to call upon those technical details about banked RAM we discussed earlier.
"XE" Banks
Recall that in Part 1 of this series we talked about "Port B". This was the hardware location we wrote to in order to enable BANKED RAM, and to indicate which bank was supposed to appear in that memory window from 16384-32767 ($4000-$7FFF in base 16 notation). The 130XE has 64K of expanded RAM, divided into 4 banks of of 16K each. Thus, one of 4 different values can be written to Port B, each value enabling one of the 4 available banks of RAM. On upgrades between 256K and 1088K, you have 12 to 64 banks of RAM that can be enabled by writing to Port B. If you take the 4 numbers that you wrote to Port B on a stock 130XE, and wrote those same numbers to Port B on a machine with 256K or more memory, the effect should still be the enabling of 4 different banks of expanded RAM. That's what makes these machines "130XE compatible". All expanded memory computers have at least these 4 memory banks in common. Because of this commonality these banks are named the 130XE banks. These XE banks are numbered 0-3.
Some programs only assume you have a 128K 130XE, and so they only use those 4 banks. Other programs with loftier goals can access any and all expanded RAM, and can be specifically told to leave banks 0-3 alone. If you have one program that only uses the 130XE banks, and another like a RAMdisk driver that uses everything **but** the 130XE banks, then those two programs should work together. This is the key to managing your memory. The trick of course, is to determine what parts of expanded RAM each program uses, so you can determine if they're compatible with each other.
Expanded RAM programs can be divided into three basic categories, as shown in Table 1. Once you've categorized your programs, figuring out whether two expanded RAM programs will work together is easy. I've created a little memory compatibility chart you can use to determine which programs should work together. First determine which category each of the two programs in question fall into from Table 1. Then go to the chart in Table 2, following one program type horizontally and the other vertically until they meet. The YES or NO in that box will tell you whether or not the programs should work together. You'll notice mostly "NO"s in the squares. That's partly because my chart is rather conservative. In general, the information in Table 2 is true, but there are tricks you can do with certain programs to make them work together even though the chart predicts otherwise.
| Category Description | Category Type |
| Use only the XE
banks Use any banks except the XE banks Use any and all banks |
XE
Programs PLUS Programs XE+ Programs |
| TYPE |
XE |
PLUS |
XE+ |
| XE |
NO |
YES |
NO |
| PLUS |
YES |
NO |
NO |
| XE+ |
NO |
NO |
NO |
Some programs can operate in one of several modes. The Disk Communicator by Bob Puff is one. When you first load the program, it asks if you want to use XE memory. It then asks if you want to use ALL XE memory. If you answer NO to the first question, Disk Communicator wont touch any expanded RAM. If you answer YES to the first and NO to the second, then Disk Communicator will operate as an "XE Program". If you answer yes to both questions, assuming you have more than a stock 130XE, Disk Communicator will operate as an "XE+ Program". Later on when we start looking at individual programs, I'll include tips and tricks that will make certain combinations of programs more compatible. We're almost there. It's time to explore how programs use expanded RAM, starting with one way that's guaranteed to significantly boost your 8 bit computing productivity no matter what you do with your Atari.
RAMdisks: Faster Than Warpdrive!
From the beginning, RAMdisk programs have been the biggest users of expanded RAM. A RAMdisk emulates a floppy drive. Instead of data being read or written to a disk, it's read or written to expanded RAM. In Claus Bucholz's "Quarter Meg 800XL" article in BYTE magazine, he provided code that created two 90K RAMdisks as D7: and D8: for DOS 2.0s. Now just about every DOS currently in use has a RAMdisk driver in one form or another. A RAMdisk is a super high speed device that can drastically reduce the time you wait to load applications and read or write data. It can also reduce unnecessary wear and tear on your floppy drives when doing database operations or when compressing or uncompressing files. Additionally, a RAMdisk can increase the versatility and usability of your computing system, especially if you only own one floppy drive.
When Ben Poehland and I were running the 1992 Mail Campaign to get AC started, I used a database program called TurboFile from Micromiser Software. TurboFile was responsible for all the mailing lists, and for collecting the data written on those 600-odd postcards people sent back to me. When AC became a reality, I dumped my database files onto a disk and sent them to Ben. To this day, TurboFile is still handling all the mailing lists for this magazine. Despite a few bugs and quirks, there is no other database that can do for AC what TurboFile does. [Editor's Note: this fellow is much too modest; see "Saga of the AC Database" elsewhere in this issue for how Jeff solved a TurboFile problem that had this magazine on the ropes - BLP]
TurboFile is a disk intensive program. Along with its companion application Turboword+, it consumes at least 200K worth of disk space because of all the little modules and support files that make up these two applications. There are different modules that get loaded to accomplish different tasks, like account set-up, data entry, sorting, and printing. What's more, database records are divided and put into 26 separate files. As you move about in TurboFile, doing the things that databases do, your computer is constantly reading and writing data and modules to and from the disk. Using TurboFile from a floppy drive- even with Ultraspeed- is just awful. You constantly wait as the drive grinds away reading and writing all that data. Entering new records into the database is unbearable!
My 800XL has the Newell 1088K memory upgrade installed in it. I set up a 960K RAMdisk as drive #1 under SpartaDOS-X and copied all my applications and data from floppy to the RAMdisk. From that point on, all TurboFile operations were done completely from the RAMdisk. Menus appeared instantly because each module loaded at electronic machine speed instead of the slow mechanical speed of a floppy drive. Searching a database of 800 people took only a few seconds instead of several minutes. The speed difference was like going from a 10-speed bike to an F-15 Strike Eagle screaming along at Mach 1.5.
UNARCing a file takes very little time compared to doing the same operation from a floppy disk drive. Even uncompressing a file as large as 80K is no big deal. The same applies to running a UUdecoder on stuff obtained from the Internet, or running SDVERT to change those Line Feed/Carriage Return codes into Atari 8-bit End Of Line codes.
Poor Man's Hard Drive
A RAMdisk is also great if you only own one disk drive and need to copy lots of files around. My 256K 1200XL has an XF551 disk drive attached to it, upgraded by CSS to a 3.5" 720K drive. With this upgrade I can read files written to MS-DOS formatted disks. Since I only have the one disk drive attached to my 1200XL, the easiest way to copy MSDOS files to an Atari disk is to first copy them to a RAMdisk, and then from the RAMdisk back to an Atari disk.
If you have a really large RAMdisk, like the 960K one in my 800XL, it can act like a poor man's hard drive. I'm using Turboword+ to write this article. Turboword+, TurboFile, and the TW+ spelling dictionary are all sitting comfortably in RAM along with Omnicom, BobTerm, Textpro XE, and some miscellaneous utilities. All tolled, I have over 140 files consuming 668K of my RAMdisk. No problem, I still have more than 250K free for anything else that needs to be loaded. Transferring a program from the University of Michigan Atari Archive on the Internet to my Atari goes something like this:
- Load OmniCom, my VT100 emulator. Log onto the Unix system, find and transfer the desired file from the Atari Archive to the Unix system.
- Quit OmniCom and load BobTerm, while the modem remains connected to the university computer. Use Ymodem protocol to download the file.
- Use the SpartaDOS-x ARC utility to de-ARC the file.
- Use SDVERT if necessary on the documentation file to convert ASCII carriage returns into Atari 8-bit End of Line codes.
- Jump into Textpro and execute a macro that removes any extraneous linefeeds from the documentation file, leaving linefeeds only at paragraph breaks.
- Load Turboword+ to view and edit the file in the comfort of an 80-column display. When done, print the documentation, staple the pages together, and file it away in my doc folder.
As we've seen, a RAMdisk can be extremely valuable in all sorts of situations. It saved me both time and wear and tear on my floppy drives when using the Mail Campaign database. It makes copying files easier when you only have one disk drive. Best of all for me, it acts like a built-in warpspeed hard drive. Considering the modest cost of DRAM chips these days, all this added performance comes at a bargain-basement price.
RAM Volatility
It's important to remember that the contents of RAM disappear when you turn off your computer. That's one of the bad things about RAMdisks. If you really like having a certain set of applications constantly available in RAM, you will have to put them on your RAMdisk every time you turn on your computer. With a big 960K RAMdisk like mine, it can take a good 15 minutes to load all 600K worth of programs and data files from floppy into RAM. What I do is leave the computer on for days at a time to spare myself from this annoyance. This way my favorite applications are always loaded into the RAMdisk without that 15 minute wait.
Important files like downloads and manuscripts in progress are always saved to floppy at regular intervals. The last thing I need is to lose hours of work due to a power outage, surge, or a program that crashes and corrupts parts of my RAMdisk. I reduce the chance of that occurring as much as possible by making sure my power line and my phone line are connected to surge suppressors. A line conditioner with brownout protection would be much better, but also a lot more expensive. Having a TransKey and the TKFreeze circuit installed in my computer also helps. The Transkey is a product that lets me use an IBM keyboard with my 800XL. The TKFreeze is an additional circuit for the Transkey that forces a cold boot of the computer when I press [ESC]-[SHIFT]-[DELETE] all at the same time. There have been many occasions when this has saved my day by allowing me to reboot from a crashed program without wiping out the contents of my RAMdisk.
Next Time. The AC Guide To Expanded Memory continues with a look
