6502.org Forum Projects Code Documents Tools Forum
It is currently Mon Apr 29, 2024 5:15 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Newbies

All times are UTC




Post new topic Reply to topic  Page 2 of 3
  [ 44 posts ]  Go to page Previous  1, 2, 3  Next
  Previous topic | Next topic 
Author Message
gilhad
PostPosted: Tue Apr 02, 2024 10:35 pm 
Offline
User avatar

Joined: Fri Jan 26, 2024 5:47 am
Posts: 37
Location: Prague; Czech Republic; Europe; Earth
About EEPROM programer - For programming AT28C256, AT28C128 and AT28C64 (probably all fake) I am using Arduino Mega, as I have already shield with ZIF40, but anything with enought I/O pins or shift registers and breadboard woud work too.

There is no need for speed, so I simply use digitalWrite and after setting addresses and data I set the control pins to write and later to read in cycle,until it stabilise (the more simple and stupid method from datasheet). Programing full chip take couple of seconds, but I do not do it so often. (Profesional programmer does it under second, but I do not care.)

Code:
   for (int i = 0; i < 16-1; i++) {
      digitalWrite(pins_addr[i], (address & (1 << i)) ? HIGH : LOW);
   };
   for (int i = 0; i < 8; i++) {
      pinMode(pins_data[i], OUTPUT);
      digitalWrite(pins_data[i], (data & (1 << i)) ? HIGH : LOW);
   };
   digitalWrite(OE, HIGH);
   digitalWrite(CE, LOW);
   digitalWrite(WE, LOW);
   digitalWrite(WE, LOW);
   //
   digitalWrite(WE, HIGH);

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others
Top
 Profile  
Reply with quote  
barnacle
PostPosted: Wed Apr 03, 2024 6:08 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 664
Location: Potsdam, DE
Rob,

You might like to consider my 'Romless Neolithic' SBC here: viewtopic.php?f=4&t=7757

Note that it does require a WDC65c02, which are easily available from Mouser; it won't work with NMOS parts or other CMOS parts (though with additional components it could be made to).

The main advantage of it is that at reset, code is sent to it from a connected computer over a serial link and executed. There is no rom/eprom/eeprom on board and so no need for a programmer.

The thread is probably worth a read anyway just for the pitfalls and solutions found with the design. The final design is right at the end of the file (there's a subtle bug with the initial design).

Neil
Top
 Profile  
Reply with quote  
barnacle
PostPosted: Wed Apr 03, 2024 11:46 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 664
Location: Potsdam, DE
Re EEPROM programmer... my experience is that many of the EEPROMs available as 'new' on the bay are in fact equipment pulls, programmed with 'something', and often locked (in fact, I've never had a new one, but I've never had a failure, and the price is usually partly rebated when you complain).

With small additions to your programmer code you can usually unlock and reprogram these parts; there are magic numbers you can write to certain addresses to unlock, erase, and permit writing.

(You probably already found that, it's in all the data sheets, but just in case it's stumping you :mrgreen:)

Neil
Top
 Profile  
Reply with quote  
rob42
PostPosted: Wed Apr 03, 2024 1:02 pm 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
barnacle wrote:
Rob,

You might like to consider my 'Romless Neolithic' SBC here: viewtopic.php?f=4&t=7757

Note that it does require a WDC65c02, which are easily available from Mouser; it won't work with NMOS parts or other CMOS parts (though with additional components it could be made to).

The main advantage of it is that at reset, code is sent to it from a connected computer over a serial link and executed. There is no rom/eprom/eeprom on board and so no need for a programmer.

The thread is probably worth a read anyway just for the pitfalls and solutions found with the design. The final design is right at the end of the file (there's a subtle bug with the initial design).

Neil


Thank you very much, Neil. I really appreciate all the help and advice that I'm getting here, and I'm sure that topic link will help me along. I've 'real world' stuff to deal with, right now, so I'll hold off reading that until I can fully commit to it.

Have a great day.

---

@gilhad

Thank you so much for taking the time and trouble to post. I'm sure that what you have contributed will be very useful to me and I will take in that information just as soon as I can.

You have a great day, also.

---

Again, I huge thank you to everyone who has taken the time and trouble to read this thread, as well as contribute to it.

I hope that many others will find the information herein, of help.

~ Rob.

edit to add:

Hey Neil. I've had a read of your 'Romless Neolithic' SBC project and I can see, right off of the bat, that what you've posted is going to be of some real help to me, so thank you for that, as well as pointing me to it.

---

A small progress report: I figured that the next thing I should do, is to off-load the clock signal that my Pico is providing. I thought that I'd be able to simply use a 555, in A-Stable Mode, but after reading what Garth has to say...

Quote:
Note: WDC now recommends a separate clock circuit that feeds both the Φ0 input (pin 37 of the DIP) and the rest of the circuit's Φ2, rather than feeding the rest of the circuit from the processor's Φ2 output (pin 39 of the DIP) which would inevitably be slightly delayed from the Φ0 input. WDC also wants a maximum transition time of 5ns, ie, no slower than that; so here's an extra note: A 555 timer is nowhere near fast enough in its rise and fall time, even if you want the frequency in Hz to be super low.


... I decided to use my Teensy 2.0 for the task. In time (and when I no longer need to adjust the clock speed) I'll use a crystal oscillator, put for this proof of concept, I'm simply using whatever I have to had.

So, I'm now feeding the ϕ1(OUT) signal back into my Pico, which is now reading that signal on the same pin that it was using to send the ϕ0 signal. A quick rework of my monitor app (which is still running on the Pico) and I’ve now got that working. It is in fact better than before, as the T-State now holds at zero, until the Pico gets the ϕ1 signal, and advances said T-State based on that signal, which very much (to my mind) emulates what a would happen if I was using a crystal oscillator.
Top
 Profile  
Reply with quote  
rob42
PostPosted: Fri Apr 05, 2024 12:36 am 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
Update:

I've redesigned my monitor/bus driver and I've also figured out how to code some "memory locations".

I have "10" at FFFD and "00" at FFFC. Looking back at what John suggested...

John West wrote:
Feed it $8f, $ea, $ea, $ea, $ea, ..., and see if it writes to memory. I expect it won't.


... I put "8F" at 1000 and everything else has "EA".

This is the trace, after I send a 'reset' signal:

Code:
T-State: 31 ..............................
ADDR BUS OUT: 1111|1111|1111|1100 :: 0xFFFC
DATA BUS   R: 0000|0000 :: 0x00

ADDR BUS OUT: 1111|1111|1111|1100 :: 0xFFFC
DATA BUS   R: 0000|0000 :: 0x00

T-State: 32 ..............................
ADDR BUS OUT: 1111|1111|1111|1101 :: 0xFFFD
DATA BUS   R: 0001|0000 :: 0x10

ADDR BUS OUT: 1111|1111|1111|1101 :: 0xFFFD
DATA BUS   R: 0001|0000 :: 0x10

T-State: 33 ..............................
ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 1000|1111 :: 0x8F

ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 1000|1111 :: 0x8F

T-State: 34 ..............................
ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 1110|1010 :: 0xEA

ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 35 ..............................
ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 1110|1010 :: 0xEA

ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 36 ..............................
ADDR BUS OUT: 1110|1010|1110|1010 :: 0xEAEA
DATA BUS   W: 0000|0000 :: 0x00

ADDR BUS OUT: 1110|1010|1110|1010 :: 0xEAEA
DATA BUS   W: 0000|0000 :: 0x00

T-State: 37 ..............................
ADDR BUS OUT: 0001|0000|0000|0011 :: 0x1003
DATA BUS   R: 1110|1010 :: 0xEA

ADDR BUS OUT: 0001|0000|0000|0011 :: 0x1003
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 38 ..............................
ADDR BUS OUT: 0001|0000|0000|0100 :: 0x1004
DATA BUS   R: 1110|1010 :: 0xEA

ADDR BUS OUT: 0001|0000|0000|0100 :: 0x1004
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 39 ..............................
ADDR BUS OUT: 0001|0000|0000|0100 :: 0x1004
DATA BUS   R: 1110|1010 :: 0xEA

ADDR BUS OUT: 0001|0000|0000|0100 :: 0x1004
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 40 ..............................
ADDR BUS OUT: 0001|0000|0000|0101 :: 0x1005
DATA BUS   R: 1110|1010 :: 0xEA


As you can see, there is a memory write at T-State 36, although it is writing zeros.

So, is this what John was saying? I'm unsure what I'm supposed to be seeing, but I feel that what I see is that we have a write operation to memory location "EAEA". Am I correct in my interpretation, please?

For the rest of the trace (which I halted at apx T-State 100) I simply see the addresses increment by one, for each T-State and no further write operations.

edit to add:

As another experiment, I've tried:

Code:
1000: 4C
1001: 00
1002: 10


... which from my very limited understanding is 'JMP $1000' and indeed, I see this:

Code:
T-State: 25 ..............................
ADDR BUS OUT: 1111|1111|1111|1100 :: 0xFFFC
DATA BUS   R: 0000|0000 :: 0x00

ADDR BUS OUT: 1111|1111|1111|1100 :: 0xFFFC
DATA BUS   R: 0000|0000 :: 0x00

T-State: 26 ..............................
ADDR BUS OUT: 1111|1111|1111|1101 :: 0xFFFD
DATA BUS   R: 0001|0000 :: 0x10

ADDR BUS OUT: 1111|1111|1111|1101 :: 0xFFFD
DATA BUS   R: 0001|0000 :: 0x10

T-State: 27 ..............................
ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

T-State: 28 ..............................
ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

T-State: 29 ..............................
ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

T-State: 30 ..............................
ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

T-State: 31 ..............................
ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

T-State: 32 ..............................
ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

T-State: 33 ..............................
ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

T-State: 34 ..............................
ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0000|0000 :: 0x00

T-State: 35 ..............................
ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0001|0000 :: 0x10

...


So, maybe I'm getting what I should be getting?
Top
 Profile  
Reply with quote  
John West
PostPosted: Fri Apr 05, 2024 8:05 am 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 293
OK, that surprises me. The trace with $8f does indeed look like the SAX instruction - it's writing something to $eaea. The value it writes can be anything, as the chip is straight out of reset and the A and X registers could have anything in them. A 65C02 should not write anything anywhere given that sequence.

So you might have an NMOS 6502 after all. I say 'might' because I am confused and part of my brain won't accept the evidence. Why would someone fake a chip to look like what it already is?

I didn't look in detail at the earlier trace (the one that didn't write) at the time, but now that I do ... it doesn't make sense. It starts out with a sequence of BRK ($00) instructions, reading the IRQ vector (as it should) and getting another BRK. Then you give it $8f8f as the IRQ vector, so that never gets interpreted as an instruction. But then the sequence of NOPs ($ea) has the top 4 bits of the address incrementing on every cycle, when it should be the whole address incrementing on every other cycle (NOP is a two cycle instruction, with the second reading the first byte of the next instruction). I can't explain that.
Top
 Profile  
Reply with quote  
John West
PostPosted: Fri Apr 05, 2024 8:41 am 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 293
No, I can think of a couple of potential explanations.

This is NMOS, and NMOS can do surprising things if you clock it too slow. You'll be able to get away with a much slower clock than the datasheet suggests, as that value has to cater for the full range of supply voltages, operating temperatures, and manufacturing variations. But there will still be a limit.

And also: are you resetting it properly? If you don't hold reset low for a sufficient number of cycles after the power supply is at the right level, the internal state might not be consistent and it could do anything.
Top
 Profile  
Reply with quote  
rob42
PostPosted: Fri Apr 05, 2024 9:02 am 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
Hi John. Thank you for posting back: your help and insight are of real value to me.

To answer your questions:

John West wrote:
And also: are you resetting it properly?


Tbh, I can't say that I was doing a correct reset, because, as a Noob, I'm still learning, but I now know to hold the reset for a few clock cycles, which I will do, moving forward.

I'm not entirely happy with my monitor app, as the output is still a little confusing, so I'm going to fix that, so that it's easier to follow. Once that's done, I will once again run these op codes and post back the trace output.

My thinking with this, is that doing things this way, is as good as having a single step, as I can see each operation, in the trace.

I have the 6502 running at 2Hz (I see the program counter incrementing once per second), but this can be increased, if you think that it's running too slow for reliability.

Thank you for your time and I trust that you'll come back and offer me more help, if you're not getting too sick of this.

Have a good day.

Later...
Top
 Profile  
Reply with quote  
barnacle
PostPosted: Fri Apr 05, 2024 9:37 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 664
Location: Potsdam, DE
One thought might be to check the current taken by the questionable 6502... with a 2Hz clock, a current CMOS part will take microamps; an NMOS should be tens of milliamps. It might be a better check at a higher clock rate, and you'll need to consider that current which flows into the processor and out through whatever components you have attached to the address and data lines...

Neil
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Fri Apr 05, 2024 12:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
If you want the 6502 to proceed slowly you can feed it a reasonable clock but hold RDY low most of the time, raising it only when you a bit of progress.
Top
 Profile  
Reply with quote  
rob42
PostPosted: Fri Apr 05, 2024 12:47 pm 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
Update:

I've re-seated the 6502, along with all the breadboard connections and I've also done some code modifications to my Monitor app.

I've also adjusted the clock speed and it's now running at 2.500Hz

Looking carefully at the start-up, I noticed the NMI scan:

Code:
T-State: 8 ..............................
ADDR BUS OUT: 1111|1111|1111|1010 :: 0xFFFA
DATA BUS   R: 0000|0000 :: 0x00

T-State: 9 ..............................
ADDR BUS OUT: 1111|1111|1111|1011 :: 0xFFFB
DATA BUS   R: 0001|0000 :: 0x10


... so, I put '$00' and '$10' in those locations, just to see what would happen, and indeed the PC jumped to $1000, just as I though it may do. Now, at $1000-$1002 I have '$4C', '$10', '$00' (JMP $0010), and there I have '$8F', followed by '$EA' (NOP), in the rest of memory, moving up, which so far as I can tell simply advances the PC:

Code:
T-State: 10 ..............................
ADDR BUS OUT: 0001|0000|0000|0000 :: 0x1000
DATA BUS   R: 0100|1100 :: 0x4C

T-State: 11 ..............................
ADDR BUS OUT: 0001|0000|0000|0001 :: 0x1001
DATA BUS   R: 0001|0000 :: 0x10

T-State: 12 ..............................
ADDR BUS OUT: 0001|0000|0000|0010 :: 0x1002
DATA BUS   R: 0000|0000 :: 0x00

T-State: 13 ..............................
ADDR BUS OUT: 0000|0000|0001|0000 :: 0x0010
DATA BUS   R: 1000|1111 :: 0x8F

T-State: 14 ..............................
ADDR BUS OUT: 0000|0000|0001|0001 :: 0x0011
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 15 ..............................
ADDR BUS OUT: 0000|0000|0001|0010 :: 0x0012
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 16 ..............................
ADDR BUS OUT: 1110|1010|1110|1010 :: 0xEAEA
DATA BUS   W: 1110|1010 :: 0xEA

T-State: 17 ..............................
ADDR BUS OUT: 0000|0000|0001|0011 :: 0x0013
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 18 ..............................
ADDR BUS OUT: 0000|0000|0001|0100 :: 0x0014
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 19 ..............................
ADDR BUS OUT: 0000|0000|0001|0100 :: 0x0014
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 20 ..............................
ADDR BUS OUT: 0000|0000|0001|0101 :: 0x0015
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 21 ..............................
ADDR BUS OUT: 0000|0000|0001|0101 :: 0x0015
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 22 ..............................
ADDR BUS OUT: 0000|0000|0001|0110 :: 0x0016
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 23 ..............................
ADDR BUS OUT: 0000|0000|0001|0110 :: 0x0016
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 24 ..............................
ADDR BUS OUT: 0000|0000|0001|0111 :: 0x0017
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 25 ..............................
ADDR BUS OUT: 0000|0000|0001|0111 :: 0x0017
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 26 ..............................
ADDR BUS OUT: 0000|0000|0001|1000 :: 0x0018
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 27 ..............................
ADDR BUS OUT: 0000|0000|0001|1000 :: 0x0018
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 28 ..............................
ADDR BUS OUT: 0000|0000|0001|1001 :: 0x0019
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 29 ..............................
ADDR BUS OUT: 0000|0000|0001|1001 :: 0x0019
DATA BUS   R: 1110|1010 :: 0xEA

T-State: 30 ..............................
ADDR BUS OUT: 0000|0000|0001|1010 :: 0x001A
DATA BUS   R: 1110|1010 :: 0xEA


I believe that this trace could be a little easier to follow and I also believe that the 6502 is showing consistent with what we saw before. The one difference is that the data bus is now presenting '$EA' to address '$EAEA' (see T-Sate 16). It's maybe better to say that, I think that's what I see, as I'm still very green and I'm relying on you guys to please tell me when I'm wrong; it's the only way I'll learn what is correct and what is not.

---

@Neil

Thank you for that suggestion. I'll have a look at that option. I do have some equipment that will measure very low current, but (as you say) I'll need to consider the other components in circuit.

---

@BigEd

Another good suggestion; thank you.
I'm unsure (at this stage) what type of 6502 I have and as such, I'm unsure how complicated that option could be. I'm aware of the theory, but the practice would need a de-bounce (possibly?) circuit and while I know how to do that, I'd rather not (at this stage) introduce something that could skew what I'm already not too sure about.

As soon as I'm confident that I'm getting consistent as well as sane readings, I can move this along and explore that option.

Thank you.

---

So, I'll wait for and hope to get some feedback on what I have here (be that good or bad, but as long as it's constructive, that's what matters) before I move it along some more.

With thanks to you all.

~ Rob.

edit to add:
barnacle wrote:
One thought might be to check the current taken by the questionable 6502... with a 2Hz clock, a current CMOS part will take microamps; an NMOS should be tens of milliamps...


A quick measure is showing a 48mA current draw. Even if I disconnect the LED matrix, there's no real difference in the current draw, so could this be the 'smoking gun'?

I've yet to 'smoke' any of my ICs, but it's early days! :mrgreen:


Last edited by rob42 on Fri Apr 05, 2024 3:47 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
gilhad
PostPosted: Fri Apr 05, 2024 3:33 pm 
Offline
User avatar

Joined: Fri Jan 26, 2024 5:47 am
Posts: 37
Location: Prague; Czech Republic; Europe; Earth
John West wrote:
Why would someone fake a chip to look like what it already is?

So the chip could be sold :D

My theory is, that those all are "second hand chips" excavated from trash. With many scratches from trashbin and even more from the line of "processing it" as there are too many peole to feed and too few money, that nobody cares to be gentle with anything.

And that there is some cheap technology, how to change chip to fake chip. (Something along the line take old chip, grind the top, paint it with this, (laser)print markings and bake it - you have brand new chip)

So while heavily scratched chips are worth nothing, brand new chips are worth few dollars each. And the fake marking cost all the same, so they will use something similar to origin (as disputes also cost them time and money) and having just few choises and probably low knowledge, even random choise is probabely "close enough".

So you end up with chip, which is faked (so no scratches would be visible) to the basically correct visual (dont you say, that there are more different variants of 6502 chip ...) :D

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others
Top
 Profile  
Reply with quote  
rob42
PostPosted: Sat Apr 06, 2024 12:56 pm 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
Update:

I have a very rudimentary system running some asm code:

Code:
  lda #$ff
  sta $6002

  lda #$55
  sta $6000

  lda #$aa
  sta $6000

  jmp $8005


... I'm having this issue:

Code:
Start of code execution

T-State: 38 ..............................
ADDR BUS OUT: 0000|0110|0000|0000 :: 0x0600
DATA BUS   R: 1010|1001 :: 0xA9                <- LDA

T-State: 39 ..............................
ADDR BUS OUT: 0000|0110|0000|0001 :: 0x0601
DATA BUS   R: 1111|1111 :: 0xFF                <- #$FF

T-State: 40 ..............................
ADDR BUS OUT: 0000|0110|0000|0010 :: 0x0602
DATA BUS   R: 1000|1101 :: 0x8D                <- STA

T-State: 41 ..............................
ADDR BUS OUT: 0000|0110|0000|0011 :: 0x0603
DATA BUS   R: 0000|0010 :: 0x02                <- (low byte) $02

T-State: 42 ..............................
ADDR BUS OUT: 0000|0110|0000|0100 :: 0x0604
DATA BUS   R: 0110|0000 :: 0x60                <- (high byte) $60

T-State: 43 ..............................
ADDR BUS OUT: 0110|0000|0000|0010 :: 0x6002    <- indeed, we see this address
DATA BUS   W: 0110|0000 :: 0x60                <- but this is not #$FF, it's the address high byte

T-State: 44 ..............................
ADDR BUS OUT: 0000|0110|0000|0101 :: 0x0605    <- now we're back to the next program counter
DATA BUS   R: 1010|1001 :: 0xA9


... at T-State 43.

Now, clearly, there could be any number of reasons why this is happening, my coding skills not being the least of them; but one step at a time.

[I've also many other things to try, 'timing' being front and center, so please don't point me there, as I'm fully aware that this could very well be where I'm slipping up, but thank you, none the less]

The first thing I'll like to eliminate, is that fact that the 'A' register may not be having the value #$FF loaded into it. So, is there any way that I can check on that, post the LDA operation, or do I have to take it on faith, that the LDA is fact working?

My thanks for any insight.
Top
 Profile  
Reply with quote  
barnacle
PostPosted: Sat Apr 06, 2024 1:50 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 664
Location: Potsdam, DE
I know you don't like the word 'timing'... but...

If, as it appears, you have a re-marked NMOS 6502, then running it at such a slow speed is so far out of its specification that, basically, anything might happen to the registers - which as others have pointed out, need to operate at a much higher speed to be reliable.

In which case, you may not be able to take LDA # on faith... it might be working, it might not be working, it might be doing anything.

I would strongly suggest investing ten bucks with Mouser or Jameco and getting a genuine WDC 65c02. It will work with you existing setup (with the addition of a single pull-up on BE) and will operate down to DC.

Neil

p.s. you can check what the accumulator contains by writing it somewhere. I would suggest a value other than zero or 0xff, though, since they are likely to pop up from various circuit errors.
Top
 Profile  
Reply with quote  
rob42
PostPosted: Sat Apr 06, 2024 1:59 pm 
Offline
User avatar

Joined: Mon Apr 01, 2024 9:58 pm
Posts: 24
Location: ZZ9 Plural Z Alpha
Thank you, Neil: I appreciate what you're saying.

I would indeed like to check what the accumulator contains by writing it somewhere, and this is where I'm going to need some help, as the only way that I know of, for how to do that, is set out in my ASM code, but you see the issue? I don't know how else to check the the contents of the 'A' register. :?

---

to add: I see the same thing, when I run the 6502 at 10Hz. Is that still too slow?

The faster I run the 6502, the less confident I become about the timing between the 6502 and the Pico.

The other thing of note, is that I always see what was last on the data bus, when it was in read mode, when I then read from the data bus, after it switches to write mode... in fact, as a type this, I'm having a thought... humm... hold the press; I need to try something...
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 3
  [ 44 posts ]  Go to page Previous  1, 2, 3  Next

Board index » 6502.org Users Forum » Newbies

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.