If I was to do the following, should it enter a loop?
write 0x80, 0x00 to 0xFFFC, 0xFFFD
write 0x63, 0x00, 0x80 to 0x8000, 0x8001, 0x8002. These are the opcodes for JMP $8000 (I hope).
From my understanding of assembly code, the processor should start execution at $8000, and then keep jumping back on itself. Is this correct or is there other code I need to have (NMI address or other?)
Tried this code, and the processor seems to cycle all addresses as it did with a NOP generator installed.
Test Code
Re: Test Code
Sentient wrote:
If I was to do the following, should it enter a loop?
write 0x80, 0x00 to 0xFFFC, 0xFFFD
write 0x63, 0x00, 0x80 to 0x8000, 0x8001, 0x8002. These are the opcodes for JMP $8000 (I hope).
From my understanding of assembly code, the processor should start execution at $8000, and then keep jumping back on itself. Is this correct or is there other code I need to have (NMI address or other?)
Tried this code, and the processor seems to cycle all addresses as it did with a NOP generator installed.
write 0x80, 0x00 to 0xFFFC, 0xFFFD
write 0x63, 0x00, 0x80 to 0x8000, 0x8001, 0x8002. These are the opcodes for JMP $8000 (I hope).
From my understanding of assembly code, the processor should start execution at $8000, and then keep jumping back on itself. Is this correct or is there other code I need to have (NMI address or other?)
Tried this code, and the processor seems to cycle all addresses as it did with a NOP generator installed.
I think you told it to start execution at 0x0080 vs. 0x8000.
Daryl
-
GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
FFFC-FFFD hold the reset vector, and addresses are always high-byte-first for the 6502. (This makes higher performance possible.) If you want the processor to start at $8000, FFFC must hold 00, and FFFD must hold $80.
The JMP-abs op code is $4C. $63 is nothing on the 6502/65c02 and is ADC stack-relative on the 65816. If you want an empty infinite loop that jumps back to its own beginning at $8000, then address $8000 needs to hold $4C, $8001 needs to hold $00, and $8002 needs to hold $80. The loop will be executed a third of a million times for each MHz of phase 2.
The JMP-abs op code is $4C. $63 is nothing on the 6502/65c02 and is ADC stack-relative on the 65816. If you want an empty infinite loop that jumps back to its own beginning at $8000, then address $8000 needs to hold $4C, $8001 needs to hold $00, and $8002 needs to hold $80. The loop will be executed a third of a million times for each MHz of phase 2.
Slightly confusing Garth 
High-byte first then, $00, $80
To me, $00,$80 would be low-byte first. Could you clarify? I think both you and 8BIT are saying it should be $FFFC=$80, and $FFFD=$00??
Not sure where I got $63, but I printed out the opcode sheet this morning and realised it was $43, but it still seemed to be wrong.
Will have a good play tonite now that I've got two power supplies, one for the eeprom writer and one for the main board.
High-byte first then, $00, $80
To me, $00,$80 would be low-byte first. Could you clarify? I think both you and 8BIT are saying it should be $FFFC=$80, and $FFFD=$00??
Not sure where I got $63, but I printed out the opcode sheet this morning and realised it was $43, but it still seemed to be wrong.
Will have a good play tonite now that I've got two power supplies, one for the eeprom writer and one for the main board.
-
GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
I'm sorry-- Yes, my mistake. I'm surprised someone else didn't jump in and set me straight sooner. It's always low-byte-first, but what I was thinking and what I wrote were two different things. So at $8000, you still need $4C, $00, $80, and the vector still does need to be $00, $80.
$43 and $63 are both undefined for the 6502 and NOPs for the 65c02. Are you sure you have the right data sheet and assembler?
$43 and $63 are both undefined for the 6502 and NOPs for the 65c02. Are you sure you have the right data sheet and assembler?
Guess I've caught your disease Garth.. Meant to say $4C, but wrote $43.
I'm just tracing my main circuitry as I noticed there are 'some' wires not connected. Its been a good few months since I tested it with the NOP generator, so I can't remember what state it was in when I got annoyed that I couldnt program the EEPROM.
I can feel the joy welling inside, knowing it may finally work
I'm just tracing my main circuitry as I noticed there are 'some' wires not connected. Its been a good few months since I tested it with the NOP generator, so I can't remember what state it was in when I got annoyed that I couldnt program the EEPROM.
I can feel the joy welling inside, knowing it may finally work
Now that I've dug through all the circuitry, I've 'almost' found the problem
Biggest problem wasnt the main board at all, but the EEPROM programmer - I had tied WE high so it could never write. Once I fixed that, the EEPROM programmed and ran in the main board properly... once
I think when i shorted the WE pin of the EEPROM to GND that it may have erased the chip or at least altered/changed the code. At least this is what I thought the problem was.
I reprogrammed the chip again, this time taking care to avoid shorting the WE pin once it was reinstalled in the main board, but nothing I do will get it to run again. Just that annoying cycling through addresses.
Woe is me
Back to the workbench.
Biggest problem wasnt the main board at all, but the EEPROM programmer - I had tied WE high so it could never write. Once I fixed that, the EEPROM programmed and ran in the main board properly... once
I think when i shorted the WE pin of the EEPROM to GND that it may have erased the chip or at least altered/changed the code. At least this is what I thought the problem was.
I reprogrammed the chip again, this time taking care to avoid shorting the WE pin once it was reinstalled in the main board, but nothing I do will get it to run again. Just that annoying cycling through addresses.
Woe is me
Back to the workbench.
Do you have a scope, or any other test equipment? If you have a scope, set it up to trigger on the 6502's SYNC signal. That signal is active whenever the 6502 is fetching an op-code from memory. If you set the scope to trigger on it, you can then probe the data bus, bit by bit, to determine what opcode is being fetched. If/when your JMP $8000 program is working, you'll see nothing but JMP instructions being fetched ($4C). You should also see the address bus cycling throuch $8000, $8001, $8002, $8000, etc. And you should see the second and third bytes of the JMP instruction being fetched.
If you have a fast enough storage scope, you could trigger it on RESET and watch the two vector bytes being fetched. But that's a non-repetitive signal, so a normal scope can't see it. You could try driving RESET with a square wave, which would make the 6502 reset repeatedly. That way, a normal scope (triggered on RESET) would be able to see the vector fetches.
Hope that gives you some ideas...
If you have a fast enough storage scope, you could trigger it on RESET and watch the two vector bytes being fetched. But that's a non-repetitive signal, so a normal scope can't see it. You could try driving RESET with a square wave, which would make the 6502 reset repeatedly. That way, a normal scope (triggered on RESET) would be able to see the vector fetches.
Hope that gives you some ideas...
Unfortunately I have no test equipment.
At the moment, my testing has relied on an LED connected to GND. I use this to check the voltages on pins of the 28C256 (32kx8 EEPROM).
The one time it worked successfully, all the address pins were low expect for A0 and A1 which I expected as the code was cycling around bytes 0,1 and 2.
When the machine is cycling all addresses, A0-A15 all light the LED, at the higher values (A13, A14) I can see the LED blinking. The main board is running at 1Mhz, so this gives a blinking rate that is visible on the A14 pin.
Not sure why it worked once, although I dont have a lot of faith in my home made EEPROM programmer. Managed to get smoke from my first 28C256 this morning when I inserted it backwards in the programmer.
Was looking at a few commercial programmers today to at least rule it out as a problem, and apart from the inhibitive cost, I cant find an even reasonably priced one for a 28C256. Best match so far is a build-it-yourself programmer but it doesnt seem to support the 28xxx series due to only setting pin 1 to VPP or A15, should be A14 on the 28 series.
At the moment, my testing has relied on an LED connected to GND. I use this to check the voltages on pins of the 28C256 (32kx8 EEPROM).
The one time it worked successfully, all the address pins were low expect for A0 and A1 which I expected as the code was cycling around bytes 0,1 and 2.
When the machine is cycling all addresses, A0-A15 all light the LED, at the higher values (A13, A14) I can see the LED blinking. The main board is running at 1Mhz, so this gives a blinking rate that is visible on the A14 pin.
Not sure why it worked once, although I dont have a lot of faith in my home made EEPROM programmer. Managed to get smoke from my first 28C256 this morning when I inserted it backwards in the programmer.
Was looking at a few commercial programmers today to at least rule it out as a problem, and apart from the inhibitive cost, I cant find an even reasonably priced one for a 28C256. Best match so far is a build-it-yourself programmer but it doesnt seem to support the 28xxx series due to only setting pin 1 to VPP or A15, should be A14 on the 28 series.
OK -- I'm wondering about the EEPROM programmer. Is it still working properly after the incident with the smoke? I'd offer to try to read your 28C256, but I suspect you're not anywhere near Bristol! Is there any way to can borrow time on an EPROM programmer, just to read the EEPROM? I think they'll read out just like a 27C256 EPROM. You could then simply check the few bytes that you need "by eye".
If your only diagnostic tools are the LEDs, it might be worth contructing a 1Hz square wave oscillator on a bit of strip-board and using that as the clock until you get it up and running. Then you will at least be able to see each individual step, the REST vector being fectched across the data bus, the op-code fetch etc etc....
Get it working at 1Hz first and you should have eliminated the majority of problems.
George
Get it working at 1Hz first and you should have eliminated the majority of problems.
George
-
GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Although 65c02's allow you to stop the clock with phase 2 high, the low time on most must be rather short (like 10µs or less) so a 1Hz square wave would not work. WDC's 65c02 can be stopped indefinitely in either phase without losing data.
What is almost as easy but more useful would be to make a debounced pushbutton circuit that gives you one phase-2-low pulse of only a microsecond or two each time you push the button. Then you have time between button pushes to probe as many lines as you wish before advancing to the next cycle.
What is almost as easy but more useful would be to make a debounced pushbutton circuit that gives you one phase-2-low pulse of only a microsecond or two each time you push the button. Then you have time between button pushes to probe as many lines as you wish before advancing to the next cycle.
I just bought a programmer from ebay for $55. The seller has more if you want to check them out.
http://cgi.ebay.com/ws/eBayISAPI.dll?vi ... 88143&rd=1
You can find others by searching ebay for "universal programmer".
Along with doing the eeproms, they can do the PAL16v8's, which is what I was after.
Good luck with your search!
Daryl
http://cgi.ebay.com/ws/eBayISAPI.dll?vi ... 88143&rd=1
You can find others by searching ebay for "universal programmer".
Along with doing the eeproms, they can do the PAL16v8's, which is what I was after.
Good luck with your search!
Daryl