Make sure the RAM can only be written to when phase 2 is high. You must gate either the R/W\ or the select with phase 2. Make sure also that the ROM and anything else on the bus is disabled when RAM is being accessed.

RDY can be pulled up to Vcc if you're not using it. The same goes for NMI and IRQ. Don't let them float. It's much more likely that you'll want the interrupts though, so if they're not connected to anything yet and you don't want to exclude the possibility of using them in the future, pull them up with a 3.3K or so.

So, I could use an 74LS08 to gate the R/W and PH2. What is the reason for this? Why does my ROM chip not require gating with PH2?

I'm sure there are lots of ways it could be done that logically would work, but remember that logic's propagation speeds are finite and getting a few gates' delays in a row will limit the maximum clock speed you can operate at. Beginners often throw a '138 in there (which is kind of slow by itself) plus additional gates. (I did that too in 1985.) It's not necessary. You can use 32K of ROM and 16K of RAM plus up to ten 6522's and 6551's using only a 74xx00 for address decoding if you do it as shown in http://www.6502.org/users/garth/project ... chematic=2 . (The inverters can be replaced with NAND sections to get it all done with one IC.) With a small change, you can make it 32K of RAM and 16K of ROM.

The address lines are not guaranteed to be valid and stable before R/W\ goes down, let alone valid long enough to meet the RAM's address set-up time; so writing to a wrong RAM address during phase 1 is quite possible if the RAM is selected and R/W\ is down. The ROM does not get written to however, so you don't have to worry about overwriting random addresses there. This lets you get away with ROM that's not quite as fast. The 6522 OTOH will not work right if the CS and R/W\ pins are not valid before phase 2 rises; so make sure the CS is not gated by phase 2 for the 6522.

I think, to keep it simple, I might stick whith a 7408. I'll gate the R/W with the PH2, as this won't require adding gates to my 74LS138 for memory decoding, so I shouldn't run in to speed issues. I'm only running at 2Mhz anyway, so I should be safe.

.... On second thought... I guess I should use 2 NAND's because the PH2 is high, but the R/W will be reading low, and the RAM WE will be expecting Low as well, so I would have to inver the R/W before NANDing with the PH2. Am I thinking straight?

IYO, am I better off using the HC family of logic chips, or stick with the LS?

Your glue logic will be the simplest if you stick with the link I gave above. One 74xx00 does all the address decoding for more I/O than you could want, plus 32K of ROM and 16K of RAM.


I never use LS unless I need the IC right now and I have the LS and there's not time to get a CMOS. HC is generally (not universally) slightly faster than LS anyway, takes less power, and loads the lines less. My National Semiconductor paper data books say that in the case of the 74xx00, LS's typ/max is 10/15ns compared to HC's 8/15ns, and for the 74xx04, LS's numbers were 10/15ns compared to HC's 7/13ns, all under the same conditions. With the '139, they're the same. Some parts will go one way and others will go the other way. Fairchild's ap. note AN-368 says, "HC and HCT speeds are not identical to LS-TTL. Some delays will be faster and some slightly slower. This is due to inherent differences in designing with CMOS versus bipolar logic. For an average system implemented in HC or LS-TTL, the same overall performance will result. On an individual part basis, some speeds will differ."

With some 65xx parts you might need HCT instead of HC. HCT should always work with the thresholds involved, although I've never had any trouble with HC either.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well, my RAM is working now. I used a 74LS00 to combine the PH2 and R/W. I have confirmed the RAM is working properly, but my system still freezes after the first setting of the 6522 ports.

I know the RAM is working, because I modified my program to store the value I want to send to Port A and Port B to address $400, clear A, and then $400 back into A before I STA to Port A and Port B, and I can get the LED's to make any pattern, based on the value. This confirms that the RAM is working. But nothing after that works.

Any other suggestions as to why my whole program will not run after turning the 6522 port bits on.

Thanks

Can you post your latest asembly code? Purhaps we can find something.
Also, please tell us how your memory map is decoded.

Daryl

Here's my current code:



My memory map has the 2864 ROM from E000 to FFFF, my 6522 is mapped at $8000, and my 2KB RAM is mapped at $0000.

Let me know what else you would like to know.

Thanks

You start the code at address 0000, but you have RAM there now (as you should have). What method are you using to get the assembled program into RAM?

Otherwise, the source code looks ok, although you have a few unnecessary instructions there, and your delay will run longer than you wrote down, because DEY BNE loopA takes 5 clocks not 1. DEY takes 2, and BNE takes 3 when the branch is taken, unless it has to branch past a page boundary, which takes 4 instead of 3, but is very unlikely.

I see something, don't know if it's "it".....

You use the directive .ORG $0000. From the point of view of the ROM, the code then starts from the very start, while from the point of view from the 6502, the code is at $E000. Both the JSR and the JMP will point into the wild. Try using position independent code, like this, to see if thats it...


Also, the inner loop of the delay uses 5 cycles, not 2, so it last longer than intended, but that shouldnt be the problem here.....

Hi,

I don't think the .ORG $0000 is it, as once assembled, I am burning it to the beginning of my ROM according to my ROM, but once I insert it, It becomes $E000, and my Reset Vector points to $E000 as well.

Also, it does execute the beginning of the code... enough to initially turn on the LED's... and then halts.

I'm pretty sure it IS it. Yes, it becomes $E000, but the JSR will read something like "JSR $001B", instead of "JSR $E01B" as it should. Same thing for the JMP. There might be something else also, but could you test my code sugestion just to see if it starts working?

edit: yes, it will turn on the leds just fine, the problem is the jsr and jump following immediately after that...

I'm happy .... I owe you an appology... That was it.

Again, I wasn't thinking very good... That's kind of an obvious error. I'm pretty new at assembly programming, so I'll use that as my excuse.

Thanks Again.

No problem, glad I could help

I presume your code is OK in the first place.
I once had an Elektor Junior (a kind of KIM-1 clone) doing the same. But running the Junior at 500 KHz, it worked fine again. Replacing the EPROM worked out fine as well. IMHO in one or another way the EPROM had become slower. So my advice: try another EPROM.

_________________