thfisher@watnot.UUCP (02/12/87)
I am having a problem with the expansion port of the C64. The interface I have
made puts 256 bytes of RAM in the I/0 1 block ($DE00 to $DEFF). I am using
HM-6116 chips with 150ns access time. When I write to location $DE09, the
information at location $DE49 sometimes changes with it. I have tried several
different chips, but the problem persists. Writing to other addresses does not
seem to create the situation.
I would really appreciate any suggestions on how to correct this problem, or
what is causing it.
Terry.
{watmath,alberta,ubc-vision}!watnot!thfishercuda@ihlpg.UUCP (02/13/87)
> > I am having a problem with the expansion port of the C64. The interface I have > made puts 256 bytes of RAM in the I/0 1 block ($DE00 to $DEFF). I am using > HM-6116 chips with 150ns access time. When I write to location $DE09, the > information at location $DE49 sometimes changes with it. I have tried several > different chips, but the problem persists. Writing to other addresses does not > seem to create the situation. > > I would really appreciate any suggestions on how to correct this problem, or > what is causing it. > > Terry. > > {watmath,alberta,ubc-vision}!watnot!thfisher There is already RAM at those locations so I am a little confused as to why you would need to put ram there externally. In fact (if I remember correctly there are 3! things addressed at those locations. I/O registers, RAM, and character ROM. The ram under all those locations is usable but you will need to be carefull about how you do it. I believe that one of the I/O bits on the 6510 controls the area between RAM and I/O and some bit in one of the 6526 control the character memory at that point. The safest and most non-interfeering way to use it is to switch from I/O to RAM in the uP and read/write what you need then switch the I/O back in. The Programmers Reference Guide can tell you which bit needs to be changed. Mike Nelson
simon@ukma.UUCP (02/15/87)
>> I am having a problem with the expansion port of the C64. The interface I have >> made puts 256 bytes of RAM in the I/0 1 block ($DE00 to $DEFF). I am using >> HM-6116 chips with 150ns access time. When I write to location $DE09, the >> information at location $DE49 sometimes changes with it. I have tried several >> different chips, but the problem persists. Writing to other addresses does not >> seem to create the situation. >> >> I would really appreciate any suggestions on how to correct this problem, or >> what is causing it. >> >> Terry. >> >> {watmath,alberta,ubc-vision}!watnot!thfisher The reason you are changing multiple locations with one write has something to do with the I/O block not being fully decoded. I don't know the exact specifics of the problem, but you should check out the address lines (from the schematics) to see exactly how it is decoded. The reason this area isn't decoded is that chips like the sid chip only use a small range of addresses, so to save both design time and hardware cost it is easier just to not decode some of the address lines. This results is the (sid) registers appearing in every block of 32 or so addresses. Just from what you said about writing to location $DE09, maybe you trace down address line 7 (bit value 64 ($40)) and make sure it is decoded when the computer thinks it is looking at the I/O chips. However, as Mike said, there is already ram there, why add more? ---------------------------------------------------------------------------------- >>>>> Simon Gales, usenet: cbosgd!ukma!simon, >>>>> bitnet: simon@UKMA.BITNET, >>>>> csnet: simon@ms.uky.csnet >>>>> Voice: (606) 254 9387
daveh@cbmvax.UUCP (02/17/87)
> The reason you are changing multiple locations with one write has > something to do with the I/O block not being fully decoded. I don't know > the exact specifics of the problem, but you should check out the address > lines (from the schematics) to see exactly how it is decoded. No, the I/O section is fully decoded for 256 bytes in each I/O section. You're confusing a point of DECODING GRANULARITY. Read on... > The reason this area isn't decoded is that chips like the sid chip > only use a small range of addresses, so to save both design time and hardware > cost it is easier just to not decode some of the address lines. This results > is the (sid) registers appearing in every block of 32 or so addresses. The above paragraph is true. What's actually happening in the C64 is that a PLA (Programmable Logic Array) is generating decode lines for each of the I/O areas in memory. But this PLA is limited; its got only 16 pins around for input, and 8 pins for output. So after I get all the control signals I absolutely need for a particular function, I have to consider address lines, for the actual decoding. If I can get the top 8 address lines, I can decode every page; a granularity of 256 bytes. If I can fit only 7 address lines in, my granularity is only every 512 bytes. So now I've got this PLA, with select lines coming out of it for particular devices, like SID chip, 6526s, and I/O slots. Let's look at the I/O section of the C64 for instance. In this section, which also decodes the 6526s, we've got a decoding granularity of 256 bytes. But the 6526 chips only have address inputs for 4 address lines; indicating that they've go 16 registers or less. I'm forced by my section grain to put each 6526 in its own 256 byte region, even though it only needs 16 bytes. And any access of that 256 byte region is going to tell the 6526 that its been selected. The 4 address lines going to the 6526 pick its register. It has no way of knowing where in the 256 byte range its been accessed at; the end result is that the 16 registers of the 6526 are repeated throughout the 256 byte range. For the I/O slot, you've also got a 256 byte range of address space for each I/O select. Whether or not something's repeated, though, depends on its addressing characteristics. If I put another 6526 out for the IO1 space, you'd get the 16 registers repeated thoughout the 256 byte range. If I put a 256 byte RAM out there, however, I've got just enough registers (in this case memory cells) for a 1:1 mapping. The RAM chip would accept the lower 8 address lines, and everything would work out just fine. If I tried to stick a 512 byte RAM out in the IO1 space, though, the decoding of the /IO1 select line would insure that only 256 bytes would be accessable, thus preventing this device from interfering with anything else. >>>>>> Simon Gales, usenet: cbosgd!ukma!simon, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh You too can put the POWER of RANDOM NUMBERS to work for you! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~