Session 12: Initialisation

[detays]

Hello,

I have tested this code using DASM and Stella but there is something that I don't understand. I've got light orange lines at the begining of the picture and at the end. I also used Z26 and these line remained the same. Is it normal ?

PS Sorry for my quite bad english, I hadn't practiced for a while ...

 

There are probably timing issues with your code. post it so i can try to help you.

 

BTW: Your english is fine

I have used the code of the post #2 . I guess, I have to adjust "SLEEP".

In fact "sleep" manage another effect ...

Edited January 28, 2008 by detays

[kamakazi]

I am just loving this! I'm actually able to learn assembly after years of being stuck with BASIC...and it's for the 2600! If it's alright with Andrew...I might use this code in the start of my first game program for the 2600. I like it...it's clean.

 

Also...would doing away with all of the spaces between lines in an assembly source code be ok...or are the spaces there for a reason? Can't wait to see how to do sprites and sounds! ON TO THE NEXT LESSON!

[+Andrew Davie]

I am just loving this! I'm actually able to learn assembly after years of being stuck with BASIC...and it's for the 2600! If it's alright with Andrew...I might use this code in the start of my first game program for the 2600. I like it...it's clean.

 

Also...would doing away with all of the spaces between lines in an assembly source code be ok...or are the spaces there for a reason? Can't wait to see how to do sprites and sounds! ON TO THE NEXT LESSON!

 

Go for it, make a fortune!

The spaces between lines are purely a style issue. I have it, you don't... yet

Remove those, if you wish.

 

Cheers

A

[kamakazi]

I may be new to 2600 and assembly...but I'm no newcomer to programming. I just like to try and keep instructions nice. This was taught to me in high school while learning BASIC and in college using COBOL.

 

I know that I'm getting off the subject here, but I did create my first Atari 8-bit program on my 800. I tried submitting it to make my mark in Atari's history. They loved my game! But the guy (who was an ex-atari programmer) was supposed to try and add some "better" graphics...there's only so much you can do with BASIC in any form I guess. However, he became ill and may not be able to finish "our" program. My question is what equipment will I need to start producing my own carts for testing and final production. I would love to be able to continue supporting what it is that Atari Age is doing as well as some other websites.

 

I can also say that, despite the 2600s prehistoric faults, the machine is actually quite impressive on how it handles code.

 

A few more questions:

 

Is there a free assembler editor (using windows notepad now)?

And do you know where I could find a programming manual for the 2600?

 

 

Thankx Andrew. When do we dig into the 5200 or 7800?

[SeaGtGruff]

Is there a free assembler editor (using windows notepad now)?

And do you know where I could find a programming manual for the 2600?

Are you on Windows? If so, you might want to check out Crimson Editor (www.crimsoneditor.com). I use it with batari Basic and assembly.

 

Michael

[kamakazi]

Thank you for that information. It's good to know that people are still out there willing to help others.

 

On a sad note...my Atari 2600 finally died today. I've had since it was bought new for me on Christmas back in 1980. It hasn't had a scatch on it. Other than ebay and amazon...is there anywhere else I might could look to buy another one?

[SeaGtGruff]

is there anywhere else I might could look to buy another one?

http://atariace.com

 

Michael

[Wickeycolumbus]

Thank you for that information. It's good to know that people are still out there willing to help others.

 

On a sad note...my Atari 2600 finally died today. I've had since it was bought new for me on Christmas back in 1980. It hasn't had a scatch on it. Other than ebay and amazon...is there anywhere else I might could look to buy another one?

 

what happened to your 2600? it might be fixable.

[Wickeycolumbus]

Hey Andrew, I know that it is kind of late for this, but can you do a session on joystick and paddle input and maybe one on bank switching? I would really apericiate it because I am doing vertical and horizontal positioning right now, and would like to control the sprite with a joystick.

Thanks.

Edited March 27, 2008 by Wickeycolumbus

[kamakazi]

Well...I did some testing on my 2600 (Mine was the sixer) and the power supply wasn't supplying. Good thing I have extra's on hand! But that didn't work. I ran tests on all the major parts (mainly ICs). The weird thing is...as soon as I plug in different adapter...they are somehow being shorted out. I've had this happen before with my 800. I think that the 2600 suffered a power surge...as I usually don't keep these older consoles on a power surge protector. Leason well learned. Keep your Atari consoles on a power surge.

 

And thanks for the link...I'll check it out. Too bad there's not a place that sells these new (mainly the 2600jr).

[jarrodparkes]

let me know if i understand this correctly, but when you use the term stack you are only referring to the locations $0080 - $00FF? the stack is only 128 bytes, correct?

[+SpiceWare]

let me know if i understand this correctly, but when you use the term stack you are only referring to the locations $0080 - $00FF? the stack is only 128 bytes, correct?

 

The stack is a "pile of information". When you put something on the stack, it goes on top. When you take something from the stack, you take it off the top. You can think of it like a spring loaded cafeteria tray dispenser.

 

The stack resides on page 1 on the 6502 family of CPUs (of which the Atari's 6507 is a member). Page 1 means $0100-$01ff. The first 2 digits (01) of a 16 bit hex value define the page, so $0080-$00ff is on page 0. That's also known as zero page because the 6502 CPUs can use it in special ways that are significantly faster than using memory in other pages.

 

The Atari only has 128 bytes and is normally referenced at locations $0080-$00ff (because of the fast zero page access). The memory in the Atari is wired in such a way that it has "mirrors". Mirrors are when the same memory shows up at multiple address ranges. Besides zero page, the Atari's memory also shows up at $0180-$01ff.

 

When stack operations (PHA, PLA, JSR, RTS, etc) are performed, they are done using the page 1 addresses because that's how the CPU is designed. Since it's a mirror, the stack data is also visible on page 0. The memory isn't typically mirrored like this on other 6502 based systems, so this is unique to the Atari.

 

Since the same 128 bytes are used for zero page and the stack, you need to be careful to not have them trample on each other. The "bottom" of the stack is at $01ff so normal memory usage is normally assigned starting at $0080. Most 2600 games make very limited use of the stack due to how little memory there is.

Edited August 8, 2013 by SpiceWare

[jarrodparkes]

Right, that all makes sense. I have a good grasp on how a stack works, zero page, etc. and your explanation helps a bunch (I have done a little NES assembly before). I guess my confusion lies in how I have seen the memory be laid out for the NES. In the NES, there is a separate page dedicated to stack memory (RAM), and then another page dedicated to general purpose RAM (see here http://en.wikibooks.org/wiki/NES_Programming).

 

But long story short, the Atari 2600's stack memory and general RAM share the same 128 bytes ($0080 - $00FF which is mirrored at $0180 - $01FF)?

Edited August 8, 2013 by jarrodparkes

[+SpiceWare]

But long story short, the Atari 2600's stack memory and general RAM share the same 128 bytes ($0080 - $00FF which is mirrored at $0180 - $01FF)?

 

Correct.

 

Using mirror memory was a very clever way of dealing with how expensive RAM used to be. I did some research a while back and found that in 1973, when development of the 2600 began, 1KB of memory cost $390 - so the 128 bytes of RAM would have been almost $50.

[jarrodparkes]

Another related question. Since the Atari program ROM uses the memory located at $1000 - $1FFF, is it alright to set the origin at "ORG $1000" instead of "ORG $F000" <--which is used in the tutorials? If I understand correctly, they reference the same data because $F000 - $FFFF mirrors what is contained at $1000 - $1FFF? Is there a particular reason that "ORG $F000" is used in the source code?

 

Thanks

 

@SpiceWare - By the way, I checked out your SpiceWare site, awesome stuff!

Edited August 8, 2013 by jarrodparkes

[+SpiceWare]

Thanks!

 

It's fine to use ORG $1000. I suspect $F000 is normally used because the 6502 interrupt vectors NMI, RESET and IRQ/BRK are defined as $FFFA, $FFFC and $FFFE.

 

In Medieval Mayhem I used a different ORG for each bank, ORG $8000 for bank 1, ORG $9000 for bank 2, ..., ORG $F000 for bank 8.

[johnnystarr]

Totally late coming in here, but I wanted to see if I am right or wrong about the following:

 

Your 9 byte solution is as follows:

 

  ldx #0
  lda #0
Clear
  sta 0,x
  inx
  bne Clear

 

Wouldn't the following be 8 bytes total?

 

  ldx #0
  txa ; 1 byte operation vs. 2 for lda #0 - as they are both zero
Clear
  sta 0,x
  inx
  bne Clear

 

The following is from the 6502 reference:

 

TXA Transfer Index X to Accumulator

addressing: implied

assembler: TXA

opc: 8A

bytes: 1

cycles: 2

Edited August 15, 2013 by johnnystarr

[+Andrew Davie]

   ldx #0
   txa ; 1 byte operation vs. 2 for lda #0 - as they are both zero
Clear
   sta 0,x
   inx
   bne Clear

The following is from the 6502 reference:

 

TXA Transfer Index X to Accumulator

addressing: implied

assembler: TXA

opc: 8A

bytes: 1

cycles: 2

 

 

 

Yes, that's a good 8-byte clear. It clears memory but doesn't set the stack pointer.

you should look at Session 24 "Some nice code" for a better one...

        ldx #0 
        txa 
Clear   dex 
        txs 
        pha 
        bne Clear

The above exits with stack pointer set to $FF, all memory zeroed, X and A zero.

[Omegamatrix]

 

 

Yes, that's a good 8-byte clear. It clears memory but doesn't set the stack pointer.

you should look at Session 24 "Some nice code" for a better one...

        ldx #0 
        txa 
Clear   dex 
        txs 
        pha 
        bne Clear

The above exits with stack pointer set to $FF, all memory zeroed, X and A zero.

 

Yes, that is a brilliant, optimal solution. Just stick a CLD on there and you are done.

 

 

I sometimes run into a situation where I need to re-boot or switch to an entirely new kernel (say titlescreen to a playing screen). The main issue to avoid is scanline bounces. The optimal code takes about 36 scanlines to complete which is too long. I made a routine that saves about 26 scanlines with the trade-off of using much more bytes. I tried to balance the byte cost vs amount of scanlines gained, and this was the best balance I could find:

    cld
    lda    #0
    ldx    #$2C
    txs
.loopClear:
    pha
    pha
    pha
    pha
    pha
    pha
    tsx
    cpx    #$7E
    bne    .loopClear
    ldx    #$FF
    txs

[Petruza]

[...]

(the optimised version, above, is 160 cycles faster - and that's 160x3 colour clocs = 480 colour clocks = more than two whole scanlines !! quicker). So you can see how crucial timing can be - by taking out a single instruction (the "cpx #$80") in a loop, and rearranging how our loop counted, we saved more than two scanlines - (very) roughly 1% of the total processing time available in one frame of a TV picture!

[...]

 

Hi, I must be missing something, but both pieces of code iterate $80 times, one counts from 0 to $80 and the other from $80 to 0 wrapping around.

So the only difference in cycle counting I find is the CPX #$80, what else is accounting for a 160 cycle reduction?

[+Andrew Davie]

 

Hi, I must be missing something, but both pieces of code iterate $80 times, one counts from 0 to $80 and the other from $80 to 0 wrapping around.

So the only difference in cycle counting I find is the CPX #$80, what else is accounting for a 160 cycle reduction?

 

Might be a mistake. If the loop is to $80, then that's 128 iterations. Times 2 for the cycle cost of the compare, that's 256 cycles total cost. A scanline is 76 cycles, so 256/76 = 3 and a bit scan lines cost for that single compare. It's a big penalty. Let's say I put that error in to make sure you were paying attention

[Petruza]

LOL no, I didn't even notice that.

Now I get it, I was counting the CPX just once, not realizing the obvious fact that it was being executed inside the loop, so adding 128 times its cycle count, not just once.

Now I see it. Thanks for the clarification.

By the way it's a great tutorial, I'm enjoying it a lot.

Edited May 2, 2014 by Petruza

[Roochie]

Hi, i'm new 'round these parts. These tutorials are quite capital!

I've just created a new account simply for the purpose of asking this question:

 

What pray tell is the difference between 'sta 0,x' and 'sta x'??!

 

Suppose 'sta 0,x' really is storing a in the memory location referenced by 0 + x. Unless i've gone completely bonkers, 0 + x = x.

If this is the case, and my understanding of 'sta x' is even somewhat accurate, then could you not instead use 'sta x'?

I'm no theoretical physicist, but since 'sta 0,x' takes a single operand more than 'sta x', and it must add them before referencing the supplied memory location, it seems that 'sta x' may even be more efficient memory-wise.

 

However, this is day 3 of my 'extensive' relationship with the '2600 and the assembly language. I could be quite far off...

 

Please, enlighten me;

I wait anxiously for thee

 

(by the by, thanks a million for the tutorials. Chompy to say the least bro)

[Thomas Jentzsch]

If this is the case, and my understanding of 'sta x' is even somewhat accurate, then could you not instead use 'sta x'?

That would work in this special case, but there is no sta x instruction. To use an index register, your always have to provide a base address, even if it is 0.

[Roochie]

That would work in this special case, but there is no sta x instruction. To use an index register, your always have to provide a base address, even if it is 0.

(chivalrous response)

Intriguing!

Many thanks to you my young Jentzsch, in the years to come my friends and children will hear stories of your intellect and kindness, and i will sow fear into your enemies hearts with stories of your ferocity on the battlefield.

 

(modern translation)

thanks man