6502.org

hi guys

i began recently studying 6502, i studied 8086, python, java and other programming languages, and now im curious about 6502, so i began following a tutorial who teached how to paint a pixel in the screen, using lda and sta commands, my question is sta takes the adress where the pixel will be painted, the problem is that i have the addresses $200, $201, $202 n some more going to the same position, the same way if i send 3 diferent colours by lda command to the same position $200 the colours will be painted in diferent and connected pixels side by side. Other situation if i paint some pixels with black colour and in the middle i paint 2 random pixels with diferent colours, only the last one receives the colour i gave to it, the first one keeps going with the black colour.

Why those things happen, i don't understand, maybe because of my program in android platform or what other reason? I don't know.

Best regards and thanks guys

Having a memory mapped screen at $0200 is not one I recognise, so I think we really need to know which 6502 system you're using.

Mostly because each 6502 system "back in the day" had it's own, unique way of doing graphics, and some even had many different ways (or screen modes). So a single byte in RAM might give you 1 pixel in 256 colours, or 8 pixels in 2 colours, or it may be an "attribute" pixel that changes the colour (or sometimes size) of the screen pixels to the right... Really hard to know without knowing the system you're using.

Cheers,

-Gordon

Welcome, ecktor. As Gordon says, every 6502 system is different, as to how the screen works and where to find it. It might well be that you're using the simple emulated system in the one-page tutorial here:
http://skilldrick.github.io/easy6502/

Maybe you can share your code? The first example of the page uses this code to paint 3 pixels:

Thanks for all your kind and attention in the forum with me and my question.

The following code is the one who gave me the situation i reported initially, the program i'm using has the manual designed by Nick Morgan, you can find it online, searching for he's name, i'm following these manual because it was suggested with the program i found about the 6502 programming running in android platforms.

LDA #$01
STA $0200
LDA #$05
STA $0201
LDA #$08
STA $0202
LDA #$f
STA $04ff
LDA #$e
STA $0400
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$1
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
sta $0419
LDA #$08
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$0
STA $0419
LDA #$2
STA $0419

Best regards
ecktor

Hi ecktor,

welcome,

the simulator you are using tells you what it can do if you hit the "Notes" button: I did not test the random feature nor the input but a little code to fill the screen with some colors:
It appears to me that the simulator operates properly. Perhaps you can figure out how my test work.

Each pixel of the screen corresponds to a single address in the range $0200..$05ff. Changing the contents of a memory in that region will change the color of the corresponding pixel on screen (to be precise: if one or more of the lower 4 bit is changed, the upper 4 bits do nothing).

All programs are automatically assembled to begin at $0600.

I don't know if the explanations on that page are enough for you. Otherwise you may try to get a book about the 6502 and its instructions (and addressing modes which are perhaps difficult to understand in the first run) - like Rodnay Zaks "Programming the 6502".

Hi ecktor
one thing to note is that your whole program will run and finish in a fraction of a second. So a sequence like this
LDA #$0
sta $0419
LDA #$08
STA $0419
LDA #$0
STA $0419
will paint the pixel at $0419 black, then orange, then black. You won't see the orange because it is immediately replaced with black.

Try the 'debugger' mode which is under the screen: click the tickbox and then use 'step' to see your program run one instruction at a time. I think that will help you see what is happening.

If you want to have a delay in your program, to slow it down to human timescales, you need to include the delay in your program. Usually this is done by counting. Further down the easy6502 page you will see a mention and an explanation - search for spinWheels.

More time spent with the same tutorial you give as reference and more strange things appearing, i went to the debugger to try some simple math operations like these:

LDA #$15 ; a= 15
ADC #$7 ; a= 1c
SBC #$8 ; a= 13

then i did some little changes in the code trying to understand the thing

ATTENTION: each new test i began always with the command LDA

LDA #$15 ; a= 15
ADC #$1 ; a= 16
ADC #$7 ; a= 1d
SBC #$8 ; a= 14
----------------------------------------------
LDA #$15 ; a= 15
ADC #$8 ; a= 1d
SBC #$8 ; a= 14
---------------------------------------------
LDA #$6 ; a= 6
ADC #$8 ; a= e
SBC #$8 ; a= 5
--------------------------------------------
LDA #$2 ; a= 2
ADC #$6 ; a= 8
SBC #$6 ; a= 1

Then i tried a new idea, work only with ADC and SBC commands to perform the operations

ADC #$1 ; a= 1
ADC #$6 ; a= 7
SBC #$6 ; a= 0

I'm going to test the programs you sent to me, but in my free time i tried more material of the same tutorial and sent the situations i found.....i believe these kind of things can be related with the diference of processors, and processors families but its my idea, nothing more.

Thank you all for your time.
Regards
HAPPY NEW YEAR TO ALL
ecktor

Very useful explorations! You'll find that ADC is usually preceded by a CLC, and SBC is usually preceded by a SEC. (Understanding the way the carry flag works and how it's used is one of the themes of learning to program the 6502.)

In the case of ADC, there are always three numbers being added:
- the carry bit (0 or 1)
- the value in the accumulator
- the other value specified in the instruction (whether an immediate or a value fetched from memory)

And similarly for SBC.

(Edit: and Happy new year! And glad we're able to help with your explorations.)

LDA #$2 ; a=2 pc=0x602 c=0
ADC #$6 ; a=8 pc=0x604 c=0
SBC #$6 ; a=1 pc=0x606 c=1
-------------------------------------------------
- and b always 1
sp always 0x1ff
all the other values always 0
--------------------------------------------------
LDA #$2 ; a=2 pc=0x602 c=0
CLC ; a=2 pc=0x603 c=0
ADC #$6 ; a=8 pc=0x605 c=0
SBC #$6 ; a=1 pc=0x607 c=1
--------------------------------------------------
LDA #$2 ; a=2 pc=0x602 c=0
ADC #$6 ; a=8 pc=0x604 c=0
SEC ; a=8 pc=0x605 c=1
SBC #$6 ; a=2 pc=0x607 c=1
--------------------------------------------------
LDA #$2 ; a=2 pc=0x602 c=0
CLC ; a=2 pc=0x603 c=0
ADC #$6 ; a=8 pc=0x605 c=0
SEC ; a=8 pc=0x606 c=1
SBC #$6 ; a=2 pc=0x608 c=1

by my tests results, looks like clc command doesn't make changes in the values, but sec command make changes in c and in the final result of a, other thing i paid attention was the value of the position in memory (pc) changes 1 or 2 numbers depending of the instruction, as you can see in the examples i give in these post.

the values i registered in each case were only the changed along the test, all the others kept them original values as refered at the beginning.

Regards
ecktor

That's because it was already clear in every case where you did a CLC, so no change was made to C. It is working correctly though. Any of the programming manuals will explain it in detail. My favorite one to recommend of course is "Programming the 65816—Including the 6502, 65C02 and 65802" by David Eyes and Ron Lichty. I believe this is definitely the best 65xx programming manual available, and a must-have for every 65xx programmer!
If you mean B the break bit, it does not physically exist in the processor-status register P. It's just a bit position in the stacked record of the processor status after an interrupt, telling if a BRK instruction caused the interrupt.