Wow, now I'm really lost!

[KAZ]

Wow, that's all I have to say, I didn't realize this part till I looked at it more closely:

 

So I'm referring to the playfield document at:

http://www.neonghost.com/the-dig/dox/nbtia_1_asm.txt

 

What I did was assemble it FIRST, and then I disassembled it.

 

The goal was to get rid of all those comments, so that I could just look at the CODE ONLY.

 

So I went back to the site, and was going to compare the:

 

commentless version of the file, and the one directly from the site.

 

Here's a brief example that just threw me right off:

 

FROM THE WEBSITE:

 

LDA INTIM

BNE DrawScreen ; Whew!

STA WSYNC

 

FROM MY "COMMENTLESS" TEXT FILE AFTER ASSEMBLING/DISASSEMBLING (Same exact location where it should be):

 

LF047: LDA INTIM

BNE LF047

STA WSYNC

 

Notice how he writes in "Drawscreen", but in the disassembled version that VANISHES, and is replaced by LF047?

 

 

So I'm way lost now....I don't know what that means.

 

It means that if I code something, it won't look the same if I assemble it and then disassemble it.

 

Maybe the assembler knows the command: Drawscreen

and it DOES something at that point, to create the BNE LF047

 

 

 

Play by play, by kaz.

[Heaven/TQA]

 

hmmm....strange questions... well...disassembling (well turning back an assembled file into sourc code...) will loose every "label"-names. why?

 

because at that time there was no "symbolic" assembling like in visual studio c++. so the debugger gets all informations for variables, labels, etc... as well... i guess turning back a PC exe into source code will give you same results like your atari stuff...why? when building the final code no additonal informations are included in the build. no gamer needs that anyway, right?

 

maybe that is the clue why you are confused... the disassembler can get some hints where loops, etc. are and puts random label names there like LF047 instead of "Drawscreen". why? because he has no information about "Drawscreen"...

 

it is like printing a word document out...scan the doc back, run a OCR software, and try to get back the original word document with all images, spaces, tables, etc... this will be not possible to recreate 100%...

 

hve

[KAZ]

What confuses me is this:

 

It looks like I could either write drawscreen, or LF047 if I were coding.

That is precisely what confuses me.

 

It doesn't seem to make a difference to the assembler, which makes me think that drawscreen is a COMMAND of some kind. This also would explain why disassembling existing BIN files doesn't always give you what the original COMMAND? was. All you see is a number like LF047.

 

I've seen this issue come up several time, some code is taken completely out (labels you call them) when you assemble code.

 

I'm just trying to figure out whatever I can. I'm going to the library to pick up some sort of 6502 programming book.

 

Thanks for responding to such an "obscure" question.

[KAZ]

Twice now I've heard the dasm assembler referred to as "he".

 

That is interesting Maybe the maker of the program was a he or something.

[Thomas Jentzsch]

What confuses me is this:

 

It looks like I could either write drawscreen, or LF047 if I were coding.

That is precisely what confuses me.

 

It doesn't seem to make a difference to the assembler, which makes me think that drawscreen is a COMMAND of some kind.  This also would explain why disassembling existing BIN files doesn't always give you what the original COMMAND? was.  All you see is a number like LF047.  

That's something called label (and no command!). It's there mainly for the programmers convenience. You give the address a name that you can easy remember and the tells something about it's purpose.

 

Another very important reason is, that if you should add any source code before that label, it's address will change. So you manually(!) had to adjust all jumps to all jump addresses (and data tables) starting from the point of the new code. By giving the address a name, the Assembler is doing that for you.

 

Labels are used in Assembler over and over for jump addresses, tables, variables etc.

 

In your code example there are already 3 labels used:

• INTIM is name for a VCS hardware register

[*]DrawScreen is a jump address

[*]WSYNC is another name for a VCS hardware register

DiStella is a bit clever and knows all hardware register by their name and replaces them automatically. And LF047 is already a label too (for address $F047). Else your code would look like this:

  LDA $0284; no jump label in front anymore!

 BNE $F047; now we jump to an address, not a label

 STA $02

That's even harder to understand, isnt it?

[Joel D. Park]

You mentioned the fact that you couldn't find the words Hello World anywhere, I think. I'll explain a little below... This is when you will learn that the 6502 doesn't do anything on it's own.

 

**HERE IS WHERE THE LETTER H IS WRITTEN!

**SEE EXPLANATION BELOW

PFData0 ;H 4 5 6 7

.byte $00,$f0,$00,$A0,$A0,$E0,$A0,$A0

 

The whole PFData0 PFData1 etc. thing are registers that contain the Playing field... They are in there kind of funny. There is a program GFX something I don't quite remember but it will allow you to draw your graphics by just clicking check boxes on a screen to represent pixel on or off... Here's really what's happening though..

 

See the .byte thing, $00, $F0 etc.. Before you can see the picture, these will need to be converted from HEX to Binary, I use my windows calcuator for this, just set it on "Scientfic" mode, click the HEX button, type in each number like 00 of F0 then click the BIN button to convert it here's what you will get:

 

$00 = 00000000

$f0 = 00001111

$00 = 00000000

$A0 = 10100000

$A0 = 10100000

$E0 = 11100000 <---SEE THE H ??

$A0 = 10100000

$A0 = 10100000

 

I hope this helped. :-)

[Nukey Shay]

You can lay out the byte data in binary form, as well. This might make things easier to see in the source code. Where hex values are preceded by the $ character, binary values use the % character.

i.e. instead of...

.byte $A0

.byte $A0

.byte $E0

.byte $A0

.byte $A0

...you could use...

.byte %10100000

.byte %10100000

.byte %11100000

.byte %10100000

.byte %10100000

 

Here's a quick rundown of how binary numbers are converted into hex...

Hex byte values are broken into two halves, called nybbles (boy, that's original!). A full byte (8 bits) consists of two digits...each digit represents 4 bits.

A binary value like 01101101 is broken in half... 0110 1101.

Hex digits have a value of 0-15, and are numbered 0123456789ABCDEF

The first (leftmost) bit of a nybble has a decimal value of 8, the second 4, the third 2, and the rightmost 1.

So, a nybble with the binary value of 0110 would be equal to 4+2, or 6 in decimal (6 in hex, as well). A nybble with a binary value of 1101 would be equal to 8+4+1, or 13 in decimal (D in hex). Therefore, the hex value of 01101101 would be $6D.

To find the decimal value from a hex one, you simply multiply the first nybble by 16 and add the second nybble. $6D is equal to 6x16+13 or 109 in decimal.

The maximum value a byte can hold is $FF...which would be 15x16+15 or 255 in decimal (which is why games often have a problem when exceeding that value for level #, # lives, etc.)

 

Decimal math in 65xx...

 

So how do games manage to keep score without using hex digits like D? Thankfully, the 65xx chip offers an easy solution. When you need to update a value that will be shown on the screen as a decimal value (like a score), you can instruct the computer to do the math in decimal form by using the SED opcode (SEt Decimal mode). After doing the math, you can clear this mode by using CLD (CLear Decimal mode). Here's a sample scoring routine :

CLC ;clear the carry flag

SED ;do the following in decimal...

LDA $LOSCORE ;grab the lower two score digits

ADC #$10 ;add 10 points (not 16...remember, we're in decimal mode)

STA $LOSCORE ;store it

LDA $HISCORE ;load the upper two digits

ADC #$00 ;if a rollover occured in LOSCORE, add it now to HISCORE

STA $HISCORE ;and store it

CLD ;clear the decimal mode

 

By searching programs for the SED command, you can often find how the game does certian things, like scoring. To find out how this score is displayed on the screen, simply search for the labels or addresses used in the adding routine (easy way to find cheats!). Not all programs use the decimal mode, but a good share of them do (it's just quicker to code).

[Joel D. Park]

That's a really great explanaion of HEX/Binary/Dec. That should go in the assembler FAQ, even I can understand that one. :-)

[KAZ]

These explanations are awesome! I asked for the answer, and you gave me it. Some of it (alot of it) is over my head.

 

The first (leftmost) bit of a nybble has a decimal value of 8, the second 4, the third 2, and the rightmost 1.

 

I understand that! That is great! A binary code is 8 digits, and you split that in half, and then you can know its decimal value.

[Nukey Shay]

Actually, breaking a binary number into two halves is not really necessary if all you want is the decimal value...I was trying to show how binary numbers and hex numbers are related (via nybbles).

 

The quickest way to convert all 8 bits to the decimal equivilant is to use this...

128+64+32+16+8+4+2+1

That does all 8 bits in one go (i.e. %10000011 = 128+2+1 = 131). If you know the decimal value of a number and want to convert to binary, simply start at the left of that list and try to subtract each from the value. If the value is too small, stick a zero in that bit. Then move to the next one and try to subtract that bit's value.

If you know the decimal value and want to convert to hex, divide it by 16, use that for the high nybble, and put the remainder in the low nybble.

 

If you are doing a lot of this converting, the absolute quickest way is to print out a spreadsheet that shows all the numbers in columns. I use one that is layed out like this (sorted by decimal number)...

 

Decimal #, Binary #, Hex #(low $00-$FF), Hex #(high $0000-$FF00), Atari Char., C64 Char.

[KAZ]

Excellent, you have a spreadsheet of those columns, I'm watching everything you are saying closely.

 

As I start to actually grasp some of this stuff, I'll be making a spreadsheet like that. I'm not there yet, not for a bit...

 

I have to read this stuff a little at a time....I can't digest it that fast.

 

What am I up to right now?

I'm going to take the playfield.txt file and attempt to see if spacing and indentation makes a difference to the assembler...

 

Like instead of this:

LF00F:x JSRxxLF021

xxxxxxxJSRxxLF03F

xxxxxxxJSRxxLF044

xxxxxxxJSRxxLF047

xxxxxxxJSRxxLF096

xxxxxxxJMPxxLF00F

 

there's no X's written, it is the only way I can space it

 

I'm going to write it like this:

LF00F: JSR LF021

JSR LF03F

JSR LF044

JSR LF047

JSR LF096

JMP LF00F

 

Or maybe remove all spacing, and see how it deals with that.

Since I'm a newbie, this is very important to understand how this is all supposed to actually look in a text file.

 

I learned that an accumulator has to do with memory.

 

There are a certain amount of registers...three general and 2 specific or something.

 

 

And then I'm wondering what small thing I could add to the playfield to see what it does....I'm not talking editing it via binary (distella), but rather actually changing the source code.

 

I'm gonna take a nice look at my beginning programming for dummies when I go to bed too.

[KAZ]

It is mysterious...sometimes when I change spacing it doesn't affect the assembly, but sometimes it does.

 

Very confusing.

[Nukey Shay]

I believe that the FAQ's show where spacing is critical.

 

In any case, removing the spacing where the labels go would just make the source code more difficult to read (since the opcodes would be shifting around).

 

BTW The 6502 contains the following registers...note that each do not have one of the $0000-$FFFF addresses, they are built into the processor :

 

Accumulator : This register handles all the math done in machine language. The instruction set also includes ways of transferring it's contents into any other register.

 

X and Y : These two assist the accumulator. For general looping/counting, it's probably a good idea to use the X register (to free Y for more complex tasks, like (indirect),Y addressing...which X cannot do).

 

Status : This register's bits contain the "flags" that are tripped (like the carry bit when the other register's roll over...this register is where that carry bit exists).

 

Stack pointer : The stack ($0100-$01FF) mainly keeps track of JSR origin addresses, so that the program knows where to return to when a RTS is called (but can also be used to store additional accumulator values, and can pass values back to Basic if the accumulator is pushed onto it). The stack pointer is how much is currently sitting in the stack. It's usually not a good idea to mess with this, as long as your subroutines close themselves the stack can take care of itself.

 

Program counter : This is simply the 2-byte address (or "word") that the program is currently running.

[KAZ]

I keep posting in the wrong sections, that just sucks.

 

And then the editing process takes like 5 minutes, I just hope 70 people didn't notice I posted in the wrong place while waiting for it to submit

[Nukey Shay]

See what happens when you start to understand assembly?? j/k

[Thomas Jentzsch]

Like instead of this:

LF00F:x JSRxxLF021    

xxxxxxxJSRxxLF03F    

xxxxxxxJSRxxLF044    

xxxxxxxJSRxxLF047    

xxxxxxxJSRxxLF096    

xxxxxxxJMPxxLF00F

 

there's no X's written, it is the only way I can space it

 

I'm going to write it like this:

LF00F: JSR LF021

JSR LF03F

JSR LF044

JSR LF047

JSR LF096

JMP LF00F

Those spaces mean absolutely nothing. The Assembler handles them like extra spaces eg. in Visual Basic or blank lines in HTML. They are only there to make the code more readable.

 

Have you tried reading some assembler docs?

[KAZ]

No, I haven't picked up a book devoted to assembly language yet, I only picked up a general programming book.

 

I just want to understand the general framework for all of this, and understand terms, etc.

 

from what I know so far there is:

 

machine language: binary code (1's and 0's)

assembly language: a low level language, that can be difficult to read.

 

Then you have some languages that are more readable:

C language, Basic, and Pascal

 

Then you have some high level languages:

C ++, FORTRAN, COBOL, QBASIC

 

I guess the question is can I use one of these more friendly languages like BASIC to write programming for the Atari 2600?

 

Or perhaps assembly language is needed because the code is more efficient, and runs faster.

 

I've always been hung up on where to put the code at

like where would I put a Basic code? Not in a text file I wouldn't think, I would think I'd need a special Basic program to write at.

 

This is just what I've read so far in the first like 20 pages of programming for dummies.

[Nukey Shay]

The problem with higher-level languages is that they use memory themselves. On the 2600, you are already in short supply of ROM and especially RAM. As Thomas said...no other languages.

 

Except maybe the Basic Programming cartridge