Hang on a minute: doesn't your LED experiment show that d0 is being driven high? That would imply that the ROM does have FF in it - it's perhaps your test circuit (or maybe the programmer) that has a bad connection.

(Make sure the ROM leads are clean and without oxide too.)

I got new ROMs and they are burning and erasing fine now. There may be a wiring problem, which cause the old ones to fry.

This is the test program I am running, I have a standard LCD with a Hitachi (I think) interface.


.processor 6502
.ORG $E000

RESET:
;Setup LCD
jsr CHECK_BUSY
LDA #$3C
STA $2000
;Turn on Display
jsr CHECK_BUSY
LDA #$0C
STA $2000
;Clear Display
jsr CHECK_BUSY
LDA #$1
STA $2000

;Dump Letters
jsr CHECK_BUSY
LDA #$48 ;H
STA $2001
jsr CHECK_BUSY
LDA #$45 ;E
STA $2001
jsr CHECK_BUSY
LDA #$4C ;L
STA $2001
jsr CHECK_BUSY
LDA #$4C ;L
STA $2001
jsr CHECK_BUSY
LDA #$4F ;O
STA $2001

FOREVER:
JMP FOREVER


CHECK_BUSY:
LDA $2000
AND #$80
BNE STOP_BUSY
jmp CHECK_BUSY
STOP_BUSY:
RTS

.ORG $FFFC
.word RESET

Sadly it does not work (no suprise).

Datasheet is this: http://www.sparkfun.com/datasheets/LCD/ ... tended.pdf

when your program reaches JMP FOREVER, you should have a measurable pattern on the address lines (and A0 and SYNC will be running at some measurable frequency)

Or, if it turns out you're stuck at CHECK_BUSY, you should see some different pattern on the address lines, and a slightly different frequency on SYNC.

You can also measure the waveform or frequency of the chip select for your display, and for R/nW - all should be useful evidence.

(I'm assuming you have at least a frequency counting multimeter? Better yet if you have a logic analyser or scope. If none of those, you might need to cook up a means to single-step your CPU)

It looks like the E input to the display will need to be a combination of phi2 and the chip select (address decode)

The RS input needs to be tied low.

Can you put up a diagram or sketch of your circuit?

First of all, thanks a lot BigEd for the help, and to everyone else to

Not at home right now, but in many circuits I see clk(phi) and the chip enables tied with a AND. This is for rising edge triggered chips right? Currently I just have the last three address lines going into a 3-8 demux, then going out depending to each device.

Sadly I do not have a logic probe (or analyzer) nor a oscilloscope, so will have to wait a while before I can purchase one.

Found a single-step circuit someone posted, from the Apple 1 manual. Will probably wire one up since I have a few 7474 chips.

Just found out because I am using the 6502 from the NES, it has no single step capability (not SYNC or RDY lines). hmmmmmm

I've never used a logic probe - they seem quite cheap but I suspect as a first low-cost instrument a multimeter might be a better investment.

I got something like this last year and it seems to do the job: frequency counting is a useful diagnostic - even without a SYNC pin you can count chip select, r/w and various high-order address pins to distinguish between different cases. Continuity tester is good for quickly checking correct soldering (and no short circuits)

(I'd be interested to hear from the others here though: for $20 or $50 or $100 what tools or instruments would be the first things to buy?)

On the subject of single-stepping, I was thinking of suggesting that you send in a very low speed clock, but I think the NES 6502, being almost an exact copy(*) of the real one, probably won't work below some 100kHz.

You need some kind of diagnostic: can you rig up a PIA or VIA or just a latch so your program can light an LED when it gets to a specific point?

Or can you arrange the various addresses so your program can signal by accessing addresses and causing certain address bits to go high? For example, I think A10 and A11 won't go high with your program as it stands, so you can do some LDA $0800 or LDA $0400 in a loop and signal your location. (I'm ignoring the reset vector addresses, which are only accessed at reset)

Cheers
Ed

(*) Huge chip photo here - by Christian Sattler, released into the public domain.

If it were possible to wear out a logic probe, my trusty BK Precision DP21 would have quit working years ago. It is the first thing I reach for when a digital circuit is misbehaving, followed by my 'scope. About all I use a multimeter for is to check that Vcc is present and to verify the integrity of a connection. The DP21 works at up to 20 MHz on either CMOS or TTL circuits. I don't recall what I paid for it (got it c. 1991) but I've sure gotten my money's worth out of it.


It may have been buried in the discussion some time ago, but it completely escapes me why he is fooling around with the NES 6502. He should be using a 65C02 instead. It'd make life a lot simpler.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Does the demux have an enable input? That would be the place to bring the clk in. The device, it seems, is clocking its inputs on the rising edge, so that needs to happen after the inputs (addresses, R/nW) are stable. In a system like yours, phi2 is a good signal to use.

I see that a logic probe is under £20, so that might be a useful purchase: it will tell if a line is steady, has short pulses or a rapid pulse train. I think a frequency counting multimeter is also useful: maybe everyone needs one of each, if they don't have a scope or logic analyzer. In the meantime, an LED with a resistor can tell you something.

Given the constraints (no sync or rdy, can't run very slow) I think you need to be using your software to let you know where it's got to, by signalling somehow. An interesting puzzle. Once you have the display working to some extent, you can output diagnostic information onto that. (If you add a uart that would be another way to get information out.)

Cheers
Ed

Was talking to my professor, he said I could wire a octal flipflop to the cpu, and have it output to a few LEDs. Then try writing to it and try to make a pattern to see if the cpu is running properly.

BigDumbDinosour, reason I am using the NES CPU is it's the only 6502 I have at the moment. It came from a junk broken NES I had laying around. Don't want to sacrifice my working commodore and atari for one.

Reason it was broken was a botched job trying to disable the 10NES lockout chip.

If you want to try working with the CMOS part it can be gotten very cheaply from sources such as JAMECO electronics. They won't be the high speed ones produce by WDC, though.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

If you are in the UK I have a number of spare Rockwell, Synertek and WDC 6502's in my chip collection.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Might have traced the problem to the EPROM. I wired it seperatly, yet still no data comes out!

VCC to power

I wired GND, /CE, and/OE, and A0-A12 to ground.

D0-D7 have LEDs.

Not a single LED is turned on, even though 0x00 on the ROM has data (FF). Both roms do this. Does the /PRG pin need to be connect to power to output?

Ok, I think it's working. Redid the eprom's wiring, and left the SRAM disconnected for now. Well it seems the address lines are producing a pattern that does not look random. Also me putting my finger near or on the cpu does not effect operation (this happen whenever wiring was bad or a broken chip). So it's looking good! Going to try and get a actual LED test.

Added: Ok, it seems it works now ! I ran a infinte loop at certain addresses. and the pins were active/inactive based on it!!! Now to get SRAM and LCD to work... hopefully.

great!

I was going to say: in case your SRAM isn't working, you could avoid using subroutine calls - same program, but no need for the stack.

You can of course test the SRAM by writing different values and checking that they read back as they should.

Sounds like you've got a way to communicate results from your program using the address lines, which should help a lot!

Cheers
Ed