Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!cfchiesa From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa) Newsgroups: comp.sys.atari.8bit Subject: Re: 16K cartridge - How? Message-ID: <2899@bsu-cs.UUCP> Date: 6 May 88 18:17:21 GMT References: <2806@bsu-cs.UUCP> <2676@umd5.umd.edu> Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 141 Keywords: Cartridge 16K ROM RAM Summary: Cartridge stuff In article <2676@umd5.umd.edu>, hans@umd5.umd.edu (Hans Breitenlohner) writes: > In article <2806@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes: > >1) Centipede is a 16K cartridge and I'm just not getting all the code. > > My Centipede cartridge (CXL4020) is definitely an 8k cartridge. Hmm... I'd have sworn I'd seen two chips in there when I opened it. Maybe I'm thinking of something else. But BASIC and CENTIPEDE are the ONLY two carts I have. Don't have the CXLnnnn number here (I'm away from home at the moment) but that LOOKS right... > > How do I get at the other 8K ? Is there a "switch" address in the ROM > > that toggles in the second half "upon request"? Or does it appear in > > some other, hidden memory block that I haven't found yet? > Standard 16k cartridges occupy memory from $8000 to $BFFF. There are two > ROM enable lines on the cartridge connector, one for the block $8000-$9FFF > and one for the block $A000-$BFFF. There are also separate select lines > for the two banks of ROM, and only enough address lines for 8k. All this > surely is a remnant from the design of the 800's memory. Whaddya mean a "remnant"? This IS an 800 I'm talking about here! :-) > See "Mapping the Atari", Appendix 14, or the schematics for your system, > for more detail. I'd already looked at "Mapping the Atari," appendices and text; haven't looked at the schematic though, and I don't think it would tell me anything if I did: it's all a bunch of lines and gibberish to me... (This is why I got OUT of Electrical Engineering and into Computer Science... ;-) ) > Then there are the bank-switched cartridges. Basic-XE, for instance, crams > 16k into an 8k address space. Switching is done by addressing locations > $D500-$D5FF. $Bxx addresses one block of ROM or RAM, $Axx addresses one of > three blocks of ROM or RAM. (I hope I got this right, haven't actually > had a chance to play with one). > Your cartridge definitely is not bank-switched. I don't understand what you just said! In fact, I'm having a devil of a time even explaining what it is I don't understand. Basically that didn't make much sense to me; could you clarify it? What memory address controls the bank- switching? $D500-$D5FF is a 256-byte range, neither a single "control regis- ter" nor an 8K block; I don't understand what appears there, under what condi- tions. What about "$Axx" and "$Bxx"? Is that a value that goes into some con- trol register, affecting what data appears at bank-switched addresses? I'm confused! > > 2) Centipede is an 8K cartridge but detects RAM-vs-ROM execution and bungs up > > if you've moved it to RAM. > > > I would be surprised if this was the case. Okay. I won't waste any more time on that concept. > >There ARE a few places in the code where an LSR (logical shift right) is per- > >formed on memory addresses WITHIN the Cartridge ROM... > > I would guess these are data areas or tables of addresses. I suppose that could be, but I don't understand HOW. Doing an LSR on a ROM lo- cation doesn't affect the contents of that memory address; the only non-ROM data affected by an LSR, as I understand it, should be the Carry bit in the condition-code register. But in this case, the LSRs (for of 'em) DON'T seem to be followed by anything that USES the Carry bit. It's as inscrutable a piece of code as I've ever seen! I thought maybe the specified ROM address was a "switch" register under certain conditions... > There are other, more innocent possibilities: > > 1. During initialization the OS sets up numerous pointers based on the size > of RAM that it finds. Addresses $6A, $2E4-$2E6 come to mind, but there > may be more. To keep everything away from the cartridge code you have to set > up all of these just right, or someone might trash part or your RAM. I don't understand how this would interfere. The first thing I tried, in fact the thing that got me started on this, was a "CARTCOPY.BAS" program that simply copied an 8K cartridge from either slot (I have an 800) to a disk file. It worked fine on the Atari BASIC and Assembler/Editor cartridge, but bombed out on Centipede. The program comments indicated that it worked "... only for 8K carts...", which was what led me to think Centipede might be 16K, for one thing. But the point is, as far as can be told, the SAME DATA in the SAME ADDRESSES WORKS when it's running from the CARTRIDGE, and DOESN'T work when running from a disk file (or direct-copied RAM). Does this, and your comment, imply that I'm not really getting the SAME DATA to DISK as is in the cartridge? I find that hard to believe, especially in light of the way other cartridges don't exhibit the same behavior. > The only > way to be sure you are doing it right is to paw through the OS listings, > and try to duplicate whatever is done there. Gack. I've been through those damn things forward and backward for the past five YEARS without figuring out what the heck goes on in there... I still don't understand how the heck the WARMST and related flags work; it's still "magic" to me and I find that incredibly frustrating. On a related note, though: I've noticed that loading a binary file into RAM at addresses which at other times are cartridge ROM, seems to make the machine un- happy. I've seen innumerable programs which load, say, 7K of data into some- where ELSE, then go to a lot of trouble to MOVE the data into, say $A000-... I've experimented with altering these files to load directly at $A000 in the first place, and often as not they bomb the machine. Why? Why? Why?? > 2. Some OS scrolling and screen clearing routines touch memory beyond > the end of the screen area. Read what "Mapping the Atari" has to say > about location $6A for more details. There might be some interaction > with BUG/65 and its screen handling, too. You might experiment with > setting $6A (and related cells) to a value lower than $A0. Also the > Centipede cartridge might have routines which are doing similar sloppy > things. No, I took care of that first thing. Moved the display list, screen memory etc. well below cartridge area, and then set $6A just above my "new" memory area. And then didn't EXECUTE the ROM, just MOVED the data hither and yon... > 3. I would also be concerned about what happens to your system (and memory > contents) when you plug and unplug a cartridge while the system is running. > After all, you are disturbing everybody's address and data bus when you > do that. That's what I always thought. But that aforementioned "CARTCOPY.BAS" program used this technique and simply said "if the machine locks up, reboot and try again." It seems to be a matter of getting the cartridge in STRAIGHT, FAST, and ALL THE WAY. Any "tilting" of the cart so that one end of the bus enga- ges before the other, sends the machine off into la-la land. But the computer doesn't seem any the worse... What exactly am I risking, besides locking up the current "session"? Is there a better method? > > Happy hunting, > > Hans Thanks! I appreciate your taking the time to comment. You've been most helpful! Chris -- UUCP:!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP