Some questions

[Shiru]

Hello. It's not really about programming 2600. I'm wrote emulator of Atari 2600 (mostly in self-education purposes), and have some questions. Unfortunatelly, i don't have a real hardware by now, and can't find answers by myself. Maybe you can help me?

 

 

- Whats consists RAM and TIA/RIOT registers on power-up? It's zeroes, or random values?

 

- Whats reading from undocumented TIA/RIOT registers (#0C-#3F, #298-#29F)? Possibly what is bug in my emu, but some progs try read from this adresses.

 

- Whats undocumented opcodes have a 6507? It's have all that opcodes from NMOS or CMOS 6502?

 

 

 

Thats all my questions by now.

 

Sorry for my strange english:)

[supercat]

- Whats consists RAM and TIA/RIOT registers on power-up? It's zeroes, or random values?

From an emulation standpoint, random is probably good.

- Whats reading from undocumented TIA/RIOT registers (#0C-#3F, #298-#29F)? Possibly what is bug in my emu, but some progs try read from this adresses.

Any TIA read will return, in the lower six bits, the contents of the last thing on the data bus. In the case of zero-page instructions, this will be the address. In the case of absolute-mode instructions, this will be the most-significant byte of the address. For indexed instructions, the address in question is the one in the instruction, not the "final" one (e.g. "lda $12,x" will yield $12 if the resulting address is $00-$7F). The two MSB's will return the indicated value, or zero for unimplemented locations (note that read locations wrap every 16 bytes, not every 64). Note that this is pretty reliable on a 2600 (depending upon the type of ROM in a cartridge); it's a bit dicey on the 7800.

- Whats undocumented opcodes have a 6507? It's have all that opcodes from NMOS or CMOS 6502?

 

NMOS.

[Shiru]

Big thanks for so much detailed answer, supercat:)

[Shiru]

And one more question now i have. Some docs about 650x say: 'ROR intruction is available on MC650x microprocessors after June, 1976.'. Developing of Atari 2600 start, afaik, something in begin of 1976 (early than June), and finished in 1977. It's mean that 6507 in Atari 2600 have ROR instruction?

[supercat]

And one more question now i have. Some docs about 650x say: 'ROR intruction is available on MC650x microprocessors after June, 1976.'. Developing of Atari 2600 start, afaik, something in begin of 1976 (early than June), and finished in 1977. It's mean that 6507 in Atari 2600 have ROR instruction?

952717[/snapback]

 

Almost certainly. What would be more interesting would be to know what pre-1976 chips do with that opcode (or the undocumented rotate-and-something variant). My guess would be that on pre-1976 chips the opcode acts like an LSR, but I don't really know.

[Shiru]

Almost certainly.

Yes, now i trace some games in my emu (can't do it before i ask, because he's in very early stage;), some of them use ROR (Pitfall, Pac-Man).

 

What would be more interesting would be to know what pre-1976 chips do with that opcode (or the undocumented rotate-and-something variant).  My guess would be that on pre-1976 chips the opcode acts like an LSR, but I don't really know.

952732[/snapback]

I interested that too - 650x very interesting CPU for me (two weeks ago, before start emu, i knew absolutely nothing about it:). But i not found any information about acting this opcode in old chips. All documentation say about 'no ROR before 76', or just say nothing.

[Shiru]

I have some new questions, now about TIA logic:)

 

- Does HMCLR executed immediatly? Or it's have effect just after HMOVE, like HMP/HMM/HMBL?

 

- I not clearly understand about VDEL for player graphic. As i know, enabling vertical delay not display object (content of GRPx register) on current scanline, but it will be displayed on next scanline. But if content of GRP be changed before that next scanline, what will be displayed? New data, or previous written in GRPx?

 

- If RESx executed in horizontal blanking time (say, -4 pixel before visible part), object will be displayed partially?

[cd-w]

- Does HMCLR executed immediatly? Or it's have effect just after HMOVE, like HMP/HMM/HMBL?

 

HMCLR is just a convenient way to reset all the HMxx registers at once. It clears these registers immediately, but it will not affect the position of the sprites/missiles until you execute an HMOVE.

 

- I not clearly understand about VDEL for player graphic. As i know, enabling vertical delay not display object (content of GRPx register) on current scanline, but it will be displayed on next scanline. But if content of GRP be changed before that next scanline, what will be displayed? New data, or previous written in GRPx?

 

VDELxx does not delay the player graphics by one line (as indicated in the stella programming guide). Instead VDELP0 delays GRP0 until a write to GRP1 is performed. In effect, when VDELP0 is enabled there are two copies of the GPR0 register. When you write to GRP0, you are writing to the second copy, and by writing to GRP1 you swap the content of the two registers. This is explained in more detail here. If GRP0 and GRP1 are written on alternate scanlines, then the player sprites are delayed by 1 line, but this is not the only way to use the delay. This trick is used to good effect in the 6-character score display routine.

 

- If RESx executed in horizontal blanking time (say, -4 pixel before visible part), object will be displayed partially?

 

I'm not entriely sure about this, but I think that if RESx is executed before the visible part, then the relevant sprite will appear at the left of the screen.

 

Chris

[SeaGtGruff]

- If RESx executed in horizontal blanking time (say, -4 pixel before visible part), object will be displayed partially?

956747[/snapback]

 

The documentation says that the object will be displayed at the left edge of the screen, but that isn't quite right; it will be displayed *near* the left edge of the screen, but slightly to the right of the edge.

 

There is no way to partially display an object; if you display it far enough to the right, then the left side of the object will be displayed on the right side of the screen, and the right side of the object will wraparound to the left side of the screen.

 

Here are some notes I made for myself while tinkering with an emulator (I wasn't able to try it out on a real 2600):

________

 

The Ball

 

If the ball is displayed without issuing a positioning command, it will begin at screen position 96, or color clock 164 (i.e., where the first 68 color clocks occur during the horizontal blank).

 

If the RESBL command ends at machine cycle 22 or less (i.e., during the horizontal blank), then the ball will begin at screen position 2, or color clock 70.

 

If the RESBL command ends between machine cycles 22 through 74, inclusive, then the screen position of the ball will be 3 * (M - 21) - 1, where M is the machine cycle. Add 68 to the screen position to get the color clock.

 

If the RESBL command ends at machine cycle 75, then the ball will begin at screen position 1, or color clock 69.

 

If the RESBL command ends at machine cycle 76, then the ball will begin at screen position 2, or color clock 70.

________

 

The Missiles (same behavior as for the ball)

 

If missile 0 or missile 1 is displayed without issuing a positioning command, it will begin at screen position 96, or color clock 164.

 

If the RESM0 or RESM1 command ends at machine cycle 22 or less (i.e., during the horizontal blank), then missile 0 or missile 1 will begin at screen position 2, or color clock 70.

 

If the RESM0 or RESM1 command ends between machine cycles 22 through 74, inclusive, then the screen position of missile 0 or missile 1 will be 3 * (M - 21) - 1, where M is the machine cycle. Add 68 to the screen position to get the color clock.

 

If the RESM0 or RESM1 command ends at machine cycle 75, then missile 0 or missile 1 will begin at screen position 1, or color clock 69.

 

If the RESM0 or RESM1 command ends at machine cycle 76, then missile 0 or missile 1 will begin at screen position 2, or color clock 70.

________

 

The Players (*nearly* the same info as for the ball and missiles)

 

If player 0 or player 1 is displayed without issuing a positioning command, its leading edge (leftmost pixel) will begin at screen position 97, or color clock 165.

 

If the RESP0 or RESP1 command ends at machine cycle 22 or less (i.e., during the horizontal blank), then player 0 or player 1 will begin at screen position 3, or color clock 71.

 

If the RESP0 or RESP1 command ends between machine cycles 22 through 74, inclusive, then the screen position of player 0 or player 1 will be 3 * (M - 21), where M is the machine cycle. Add 68 to the screen position to get the color clock.

 

If the RESP0 or RESP1 command ends at machine cycle 75, then player 0 or player 1 will begin at screen position 2, or color clock 70.

 

If the RESP0 or RESP1 command ends at machine cycle 76, then player 0 or player 1 will begin at screen position 3, or color clock 71.

________

 

As you can see, the missiles (and the ball) are positioned one pixel to the left of the players. That is, if you display player 0 and missile 0 without any positioning commands, at single-width (i.e., each pixel is 1 color clock wide), you essentially get a "combined shape" that is 9 pixels wide-- the missile being the leftmost pixel of the "combined shape," followed by the 8 player pixels. Of course, they are still separate objects, but they will *look* like one object that's 9 pixels wide.

 

The only way to position an object at the left edge of the screen (screen position 0, or color clock 68) is to first position it *near* the left edge, then use an HMOVE to bump it a few pixels to the left. The closest you can get to the left edge of the screen *without* using HMOVE is to issue a RES* command that ends at machine cycle 75.

 

Michael Rideout

[Shiru]

Thanks for answers:)

 

VDELxx does not delay the player graphics by one line (as indicated in the stella programming guide). Instead VDELP0 delays GRP0 until a write to GRP1 is performed. In effect, when VDELP0 is enabled there are two copies of the GPR0 register. When you write to GRP0, you are writing to the second copy, and by writing to GRP1 you swap the content of the two registers. This is explained in more detail here. If GRP0 and GRP1 are written on alternate scanlines, then the player sprites are delayed by 1 line, but this is not the only way to use the delay. This trick is used to good effect in the 6-character score display routine.

Strange thing. I realize that all, and 6 Digit Score Display (1998) (Robin Harbron) (PD).bin bring to work. It's display 6 digit number (not so correct as Stella, because my emu very incomplete;). But. If i write GRP0B with write to GRP1A and vice versa (GRP0A -> GRP1B) - as on diagram on Stella Programmer's Guide, i have some gfx glitches on whole displayed number. And if i write B-reg when writing A-reg - number displays correct. Except last digit, but it can be troubles with TIA/CPU sync (by now, i use very dirty method - CPU execute op, write mem ops acts immidiately, then TIA and RIOT ticks M*3 times).

 

I think, i miss something again, or not understand explainations right.

 

This is logic my current P-render:

 

- if CPU write to GRP0, i write values to virtual regs GRP0A and GRP0B

- if CPU write to GRP1, i write values to virtual regs GRP1A and GRP1B

 

When render pixel (electron beam at correct point on scanline):

 

- if bit in VDELP0 is set, i use bit from GRP0B

- if bit in VDELP0 is clear, i use bit from GRP0A

 

Same thing for P1.

 

I understand logic right?

 

 

Sorry for my stupidity, but i never work with Atari computers before, some conceptions very unfamiliar for me. And my knowledge of english is very bad, as you can see:)

Edited October 31, 2005 by Shiru

[vdub_bobby]

You might take a look at this document for a very detailed, very technical discussion of how the TIA works.

 

http://www.whimsey.com/atari_docs/TIA_HW_Notes.txt

[cd-w]

I think, i miss something again, or not understand explainations right.

 

This is logic my current P-render:

 

- if CPU write to GRP0, i write values to virtual regs GRP0A and GRP0B

- if CPU write to GRP1, i write values to virtual regs GRP1A and GRP1B

 

When render pixel (electron beam at correct point on scanline):

 

- if bit in VDELP0 is set, i use bit from GRP0B

- if bit in VDELP0 is clear, i use bit from GRP0A

 

Same thing for P1.

I understand logic right?

957024[/snapback]

 

Sorry - I don't think I understand what you are trying to do here. You only need to set VDELPx once. To switch the values of GRP0A and GRP0B you write to GRP1, and similarly to switch GRP1A and GRP1B you write to GRP0. When you write to GRPx you are always writing to the copy that is not currently displayed on the screen. The 6-digit score is one of the most advanced tricks on the 2600, so it can take some time to figure it out. If you post your code here, then I'm sure that someone will be able to see where you are going wrong.

 

Chris