Path: utzoo!attcan!uunet!pyrdc!grebyn!umd5!hans
From: hans@umd5.umd.edu (Hans Breitenlohner)
Newsgroups: comp.sys.atari.8bit
Subject: Re: 16K cartridge - How?
Message-ID: <2761@umd5.umd.edu>
Date: 20 May 88 19:21:01 GMT
References: <2806@bsu-cs.UUCP> <2676@umd5.umd.edu>
Reply-To: hans@umd5 (Hans Breitenlohner)
Organization: University of Maryland, College Park
Lines: 111

> 
Apparently I did not describe things real well on my last try, so here we go
again:
> Hmm... I'd have sworn I'd seen two chips in there when I opened it.  Maybe I'm
Yes, there are two chips, but they are both 4k ROMs.  Maybe these were cheaper
than the 8k variety at the time, or maybe one half contains subroutines
common to several games.  The key thing is that they both are selected by the
S5 signal, which indicates the address range $A000-$BFFF.  16k cartridges
(with a flat 16k address space) will also use the RD4 and S4 signals, and
bank switched cartridges will use the CCTL signal.  The Centipede cartridge
does not even have contacts in these locations.  (See 'Mapping the Atari',
Appendix 14, for the pinout of the cartridge connector.
> 
> 
> Whaddya mean a "remnant"?  This IS an 800 I'm talking about here!  :-) 
Sorry, I did not mean to offend you.  But when you look at this from the point
of view of an XL or XE, this addressing scheme might seem strange.
> 
> 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!  
> 
The i/o area address space $D500-$D5FF is decoded in the Atari, and the 
result is fed to the cartridge as the CCTL line.  This apparently was meant
for such applications as bank switching, and for cartridges with i/o devices.
After that it is up to the cartridge what to do with it.  
The scheme I described is used by the OSS cartridges (Basic XL and XE,
Mac/65, and maybe Action, too).   In the more common approach you would
store a value xx in a control register to accomplish a certain action.
In this scheme, instead, you reference location $D5xx.  
This probably simplified hardware design.
So, for instance, a reference to $D500 selects bank 0, $D501 selects bank
1, and so on.  Since these may be store instruction, this can be done without
affecting registers, which may simplify programming.
Where I referred to $Axx and $Bxx, that should have been $Axxx and $Bxxx,
to indicate that these cartridges treat the two halves of their address
space separately.

> > >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 
What I suggestes was that these areas are not really code, but data used for
displays or whatever.  After all, if you disassemble arbitrary data you some-
times get what looks like real instruction sequences.  On the other hand, 
if these LSR instructions are in the middle of what appears to be legitimate
code, then I was probably wrong, and this is some form of copy-protection.
You might try replacing these instructions with SEC or CLC, as appropriate.
> > 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.
> 
You are probably right on this one, but let me explain my point.  When you 
boot without cartridge, the OS sets up numerous pointers to reflect a 
memory size of 48k.  When you boot with a cartridge, those pointers are set
up for a memory size of 40k.  When you boot without cartridge, and then want
to run the equivalent of a cartridge, you have to change those pointers.  My
point was that if you do not make all the changes needed, then some
cartridges may run, and others may not, depending on which pieces of infor-
mation they use.  And of various pieces of code that I have looked at, I have
not seen one yet that set all of these things correctly.

> 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??  
I can't think of any reason why that should be so, but have made the same
observation at times.  Never had the time to chase it down, though.
> 
> doesn't seem any the worse...  What exactly am I risking, besides locking up
> the current "session"?  Is there a better method? 
Apparently lockups are all you are risking.  If you are going to do a lot
of this, a switch in the S5 line would make the cartridge appear and
disappear, while keeping the memory occupied at all times.  You could add
that either in the cartridge or in your 800.

> 
> 
> Thanks!  I appreciate your taking the time to comment.  You've been most
> helpful!
>
> Chris
>
You are welcome.  This has been a fun project to pursue, and I don't even
have to do any of the work!

Hans