Re: [stella] Don't say you weren't warned....

Subject: Re: [stella] Don't say you weren't warned....
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Fri, 13 Aug 1999 17:53:20 -0400 (EDT)
nice timing.. caught me at work, needing to wait for these graphs to
finish before I could leave but with nothing else to do :)

> The actual space for the programs is from $F000 on up.  Where is the
> stack located so I don't accidentally write instructions onto it? 

It starts at RAM location $FF (also accessible via $1FF, $20FF, $21FF,
$40FF, $41FF, etc) and expands downward.

> Also, is the memory that I would use to store scores, cards, etc.
> located in the $F000 on up, or is it lower?

RAM is located from $80 to $FF, also accessible via $180 through $1FF,
$2080 through $20FF, $2180 through $21FF, etc.

>Once the cartridge is
> loaded and the game switched on, can I, say, write to location $F555

No, that's ROM.

> and read from it,

Yes, it's ROM.

>write something different to it, etc?  What are my

No, that's ROM.

> memory limitations as far as the values generated and tracked by the
> game?

You get 128 bytes of RAM.

>The memory limitations for the program is 4K at a time, right?

Without bankswitching, yes.

(I know the Supercharger breaks most of what I just said, but let's not
confuse him... :)

> It mentions setting up VBLANK at the start of the overscan period. 
> Why?  Is there that much of a difference between VSYNC 3 times/start
> VBLANK and VBLANK/VSYNC 3 times?

Actually, VBLANK would probably have been set at the start of overscan on
the previous frame.  It's probably a good idea to keep VBLANK on during
VSYNC... nobody's really sure, but there's the possibility that
accidentally showing some graphics in there could confuse a TV.
 
> I'm working on an IBM.  Keeping in mind I've been told DASM (which I
> haven't had a chance to play with yet) lets you label a location with a
> name (like TEMP, presumably) and any operations that require that
> memory spot don't need the hex number in the instructions, just type in
> the label and DASM will convert it later.  Assuming this is how it

Right.  Feel free to look through some source code... my own INV includes
a lot of this stuff; looking at the source  might help with the syntax.

> works, I think I remember seeing TIM64T in the Stella manual.  Is this
> an actual part of memory, like the VSYNC register, or is this just a
> label generally used so everyone can keep track of it, a sort of
> standardization for programmers?

TIM64T is the name for the register at address $296.

>  And what function does setting TIM64T
> serve?  I thought the TIA takes care of the linear movement itself and
> the programmer only has to worry about the top-to-bottom counting.

It counts time for you so your code doesn't have to do it.  By far the
most common use is to, immediately after VSYNC, set TIM64T so that it will
expire 37 scanlines later.  Then you do all your game-calculation code,
and then just watch the timer till it expires, then you know it's the
right time to start drawing the screen.  This way, you don't have to make
sure you catch every one of the 37 WSYNCs while doing your game
calculation.  Again, the source for both Nick's demo and INV does this.

> Checking the console switches:  by my count, there are five switches on
> the console--color, select, reset, and the two difficulty (mine has a
> TV channel switch, but I would bet that that's attatched to the actual
> video unit and has nothing to do with the CPU).  Since these are just
> switches, I imagine that individual bits (on/off) are used to keep
> track of their position.  But a byte is 8 bits long, right?  Which bit
> tracks the switches, and, if it is 8 bits long, what are the other
> three used for?

Five bits of the byte at register SWCHB are used for those switches.  (I
think, not 100% sure offhand.)  The other 3 are unused.

> The program gets to:
> LDA INTIM
> BNE DrawScreen
> STA WSYNC
> STA VBLANK
> INTIM is not listed previously in the document.  Since the Atari powers
> up in a random state, INTIM might not necessarily be 0 and might not
> switch off the WSYNC and VBLANK.  Or was it assigned 0 and I didn't

In Nick's demo (and in INV), the very first block of code zeros out all
the RAM and video registers.  

> notice it?  By the way, WSYNC has to be shut off?  Is this placed after

WSYNC is a strobe register; doing STA WSYNC doesn't actually shut anything
on or off.  It's a signal to the TIA to keep the CPU in a halt state
until the current scanline finishes.

> next instruction?  I guess what I'm asking is, is WSYNC an automatic
> command (computer waits until raster catches up then continues) or is

Yes.

> it like a switch that the program throws (computer waits until a
> command tells it to stop waiting)?  And if it gets turned on and off by
> the program, will putting in fewer commands that produce fewer cycles
> to do than for the raster to move throw everything off?  How close in
> cycle counting do you have to get to make the program flow properly?

During screen display, don't do more than 72 cycles between WSYNCs (or if
you do, make sure you know that and account for the missed WSYNCs.)

> Also, referring to the program nugget above, I don't see a Compare
> command before the Branch instruction.  Is the Compare IN the Branch
> instruction, or is this something Bensema left out to make us catch and
> pay attention?

The LDA sets the zero flag (that BNE tests) without need for a compare.

> "This is a decremental loop...which is why the graphics at the end of
> this file are stored 'bottom-up'.  In a way, one could say that's how
> the screen is drawn."  In the disassembled code for Adventure, I can
> make out the paterns for drawing the dragons, bat, chalice, etc.  But
> they're right-side up.  Or is what Bensema is refering to just for the
> background graphics?

Adventure could have different sprite and background routines than Nick's
code.

> Finally, I'm a little confused with the layout of the Graphics data. 
> What part of this is just commentary and not part of the program?  And
> what does all this do?
> PFData0; H   4 5 6 7
> .byte $00 $f0 $00 $A0 $E0 $A0 $A0
> If the playfield generator looks at the bits and draws where a 1 is and
> leaves blank where a 0 is, can't the letter H be drawn using just one
> byte at the most?  Or is this complication necessary?  What am I
> missing?

I got confused by that too, actually; ask Nick.




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

Current Thread