Beginner in digital circuitry
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
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)
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)
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.
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.
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.
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.
- BigDumbDinosaur
- Posts: 9426
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Logic Probe
BigEd wrote:
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.
Quote:
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.
x86? We ain't got no x86. We don't NEED no stinking x86!
ioncannon wrote:
Currently I just have the last three address lines going into a 3-8 demux, then going out depending to each device.
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.
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.
- BigDumbDinosaur
- Posts: 9426
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
ioncannon wrote:
...reason I am using the NES CPU is it's the only 6502 I have at the moment.
x86? We ain't got no x86. We don't NEED no stinking x86!
- BitWise
- In Memoriam
- Posts: 996
- Joined: 02 Mar 2004
- Location: Berkshire, UK
- Contact:
BigDumbDinosaur wrote:
ioncannon wrote:
...reason I am using the NES CPU is it's the only 6502 I have at the moment.
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
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?
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.
Added: Ok, it seems it works now
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
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