Re: [stella] Hello from Square One

Subject: Re: [stella] Hello from Square One
From: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 07 Jan 1999 15:46:48 +0100
At 15:59 06.01.99 -0800, you wrote:
>1)  I was looking over some of the disassembled code printouts and I
>notice that there are no "memory locations" (roughly analogous to line
>numbers in BASIC?) listed by the code.  So how is the code put in? 
>Where to the memory location assignments come in?  And if you just
>start typing everything in, how do you know where the JSR and JMP
>commands are supposed to lead to?

There are labels next to the code that the JMP commands can refer to.
Your assembler counts the number of bytes that all the instructions
take up up to the label and replaces the referrence after the JMP
with the correct memory address, when it compiles your source code
into a binary. You only have to tell the assembler where to start
counting. For example:

     ORG $1000
     ldx $1234
     stx $80
L1:  dex
     jmp L1

The ORG statement tells you assembler to start counting at address $1000.
The assmbler knows that ldx $1234 takes 3 bytes and that stx $80 takes
2 bytes. Therefore it will replace jmp L1 automatically with the
machinecode representation of jmp $1005.

>2)  I was reading a book on programming the Apple IIe (6502 processor,
>doncha know), and it mentions that the branch commands only go 127 (or
>128, depending on direction) bytes at the most.  Has anybody ever run
>into a situation where branches are required further than this?

Usually machine code programs are so short that branches don't have
to go further than 127 bytes. If you have a case where 127 byte
branches are not enough, you can usually replace the branch with
a negative branch and a jump. For example you can replace

      bne TooFar
Next: lda #$10


with the following:

      beq Next
      jmp TooFar
Next: lda #$10

>3)  Please explain the Stack Pointer with regards to the subroutines. 
>What location in memory is it?  How big is it?

The VCS has 128 bytes of RAM from address $80 to $FF. Usually the
stack pointer points to address $FF. Whenever something is pushed
onto the stack, it gets stored at the RAM address that the stack
pointer currently points to and the stack pointer gets decremented
by one. When something is pulled from the stack the stack pointer gets
incremented by one and the value is read from the RAM location that
the stack pointer currently points to.

Since those 128 bytes are the only RAM in the VCS, the size of the stack
depends on how many of the RAM (starting from $80) you want to use
for your variables.

>4)  Supposing I JSR to a JMP command.  Will a RTS send the program
>back to the command after JSR, or will I screw up the program?

When a JSR instruction is executed, two byte the memory location for
the intruction after the JSR is pushed to the stack and the execution
continues at the address that the JSR points to. When a RTS intruction
is executed, a two byte address is pulled from the stack and the
execution continues at that address.

If you don't change the stack pointer or the RAM location where the
return address was pushed to, you can do anything you want between
a JSR and a RTS.

>5)  When the Atari powers up, are all the memory locations, flags,
>etc. reset automatically, or in some random state so the programmer
>needs to reset them himself?

It's completely ramdom. You have to reset all TIA registers to avoid
strange display problems to happen and you should also reset the
RAM locations that you want to use, if their initial state matters.

>6)  Is there a way to produce text for a few words on the Atari, or do
>any words have to be drawn out by the graphics engine (is that the
>right term?)?

Anything on the VCS has do be done by an individual graphics engine,
even text. There is a nice text display routine in the source code
for Dark Mage which I think can be found on Nick's Atari programming
page at http://www.primenet.com/~nickb/atariprg.htm
But this routine might be a bit difficult for a beginner to understand.

>7)  What exactly is the deal with bankswitching?  If I recall what I
>read correctly, the Atari has 4K of memory.  The standard cart is 4K. 
>For 6K, presumably, one 2K bank would be retained in memory while the
>other 2K bank is swapped with another.  Okay.  Assuming I'm
>remembering correctly, how does the bankswitching command know which
>bank to keep, which to replace, and what to replace it with?  Am I
>missing any important info here?

Bankswitching is not a build-in-feature for the VCS. It is done by
adding some extra hardware to the game cartridge. How it works depends
on how it is implemented in hardware. Usually the extra hardware
monitors the cartridge bus to see if a hot spot ROM location is
accessed. If the hot spot is for example $1FF8 and you do a CMP $1FF8
instruction, the extra hardware would swap in bank 1 between
$1000 and $17FF. A different hot spot at $1FF9 could mean to swap
in bank 2 between address $1000 and $17FF.

There are several different methods of bankswitching. A nice overview
about them can be found at Kevin Horton's web site. I think it is at
http:///www.iquest.net/~khorton

But bankwitching is nothing you should worry about much until you
understand the basics of VCS programming and have done some experemental
programs on your own.

>Finally, regarding Glen's posting about a ROM image for River Raid and
>other advances, my immediate response is, "Why bother?"  I have
>fantasies about programming a quest game for the Atari, but I know

The question is why you asked about bankswiching in the first place
when you don't want to use more than 4 kb of ROM anyway. ;-)


Ciao, Eckhard Stolberg



--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/

Current Thread