6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 8:31 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: positions in the screen
PostPosted: Fri Dec 20, 2019 12:19 pm 
Offline

Joined: Fri Dec 20, 2019 12:01 pm
Posts: 4
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 20, 2019 12:27 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
ecktor wrote:
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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 20, 2019 1:29 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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:
Code:
LDA #$01
STA $0200
LDA #$05
STA $0201
LDA #$08
STA $0202


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 23, 2019 11:28 am 
Offline

Joined: Fri Dec 20, 2019 12:01 pm
Posts: 4
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


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 24, 2019 1:18 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Hi ecktor,

welcome,

the simulator you are using tells you what it can do if you hit the "Notes" button:
Code:
Notes:

Memory location $fe contains a new random byte on every instruction.
Memory location $ff contains the ascii code of the last key pressed.

Memory locations $200 to $5ff map to the screen pixels. Different values will
draw different colour pixels. The colours are:

$0: Black
$1: White
$2: Red
$3: Cyan
$4: Purple
$5: Green
$6: Blue
$7: Yellow
$8: Orange
$9: Brown
$a: Light red
$b: Dark grey
$c: Grey
$d: Light green
$e: Light blue
$f: Light grey


I did not test the random feature nor the input but a little code to fill the screen with some colors:

Code:
LDA #$04
LDX #0
LOOP1:
STA $0200,X
INX
BNE LOOP1
LDA #$03
LDX #0
LOOP2:
STA $0300,X
INX
INX
BNE LOOP2
LOOP3:
TXA
STA $0400,X
INX
INX
BNE LOOP3
LOOP4:
TXA
STA $0500,X
INX
BNE LOOP4



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".


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 28, 2019 10:25 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 03, 2020 11:24 am 
Offline

Joined: Fri Dec 20, 2019 12:01 pm
Posts: 4
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 03, 2020 11:32 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 04, 2020 4:52 am 
Offline

Joined: Fri Dec 20, 2019 12:01 pm
Posts: 4
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 04, 2020 5:07 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
ecktor wrote:
by my tests results, looks like clc command doesn't make changes in the values

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!

Quote:
- and b always 1

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 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: