6502.org

Posted: **Fri Jan 26, 2007 3:49 am**

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.

Posted: **Fri Jan 26, 2007 3:22 pm**

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?

Posted: **Fri Jan 26, 2007 3:54 pm**

Quote:

So, I could use an 74LS08 to gate the R/W and 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.

Quote:

What is the reason for this? Why does my ROM chip not require gating with PH2?

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.

Posted: **Fri Jan 26, 2007 8:46 pm**

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?

Posted: **Sat Jan 27, 2007 5:19 am**

Quote:

I think, to keep it simple, I might stick whith...

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.

Quote:

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

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.

Posted: **Sun Jan 28, 2007 2:15 am**

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

Posted: **Sun Jan 28, 2007 2:44 am**

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

Daryl

Posted: **Sun Jan 28, 2007 3:22 am**

Here's my current code:

Code: Select all

; Program NCS ROM2 $0000 to $1FFF 	01/24/2007
; Flashes alternating LED's connected to 6522 Port 'A' & 'B'

	.ORG $0000
Out_B	= $8000		;Output Port B 6522
Out_A	= $8001		;Output Port A 6522
DDR_B	= $8002		;Data Direction Register Port B 6522
DDR_A	= $8003		;Data Direction Register Port A 6522

	LDA #$FF	;Set Data Direction to Output for port A
	STA DDR_A
	
	LDA #$FF	;Store 255 in memory address 1024
	STA $400
                LDA #0
	
main	LDA $400
	INC $400	
	STA Out_A
	JSR delay
	JMP main	;repeat

delay	LDA #$00 	
	LDX #$C4 	;2 cycles $C4x$FF=49980 Cycles apprx 1/10 second 
loopB	LDY #$FF 	
loopA	DEY		
	BNE loopA 	
	DEX 		
	BNE loopB 	
	RTS 		
	.END

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

Posted: **Sun Jan 28, 2007 3:53 am**

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.

Posted: **Sun Jan 28, 2007 4:04 am**

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...

Code: Select all

; Program NCS ROM2 $0000 to $1FFF    01/24/2007 
; Flashes alternating LED's connected to 6522 Port 'A' & 'B' 

   .ORG $0000 
Out_B   = $8000      ;Output Port B 6522 
Out_A   = $8001      ;Output Port A 6522 
DDR_B   = $8002      ;Data Direction Register Port B 6522 
DDR_A   = $8003      ;Data Direction Register Port A 6522 

        LDA #$FF
        STA DDR_A	;Set Data Direction to Output for port A 
        STA $400	;Store 255 in memory address 1024 
    
main    LDA $400 
        INC $400    
        STA Out_A 

delay   LDX #$C4    ;2 cycles $C4x$FF=49980 Cycles apprx 1/10 second 
loopB   LDY #$FF     
loopA   DEY       
        BNE loopA     
        DEX        
        BNE loopB     
        BEQ main        
        .END

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.....

Posted: **Sun Jan 28, 2007 4:08 am**

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.

Posted: **Sun Jan 28, 2007 4:13 am**

kernal34 wrote:

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.

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...

Posted: **Sun Jan 28, 2007 4:29 am**

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.

Posted: **Sun Jan 28, 2007 4:32 am**

No problem, glad I could help

Posted: **Mon Jan 29, 2007 11:59 am**

kernal34 wrote:

It appears my breadboard 6502 computer is freezing. It will only execute the first few lines of code on my 2864 ROM chip, and then appears to freeze.

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.

6502.org

Freezing 6502

Re: Freezing 6502