How long is does a TIA color clock take to execute?

[DementedPurple]

So, I know that the main CPU runs at 1.19 Mhz, and I also know that the TIA is 3 times as fast as the 6507, so it runs at 3.57 Mhz. How would I figure out how long a single color clock takes to execute?

[DementedPurple]

Oh, and also, at what address is the reset vector?

[tschak909]

Where this matters is relative to the CPU. In any case, The processor clock is 1/3rd of the color clock. So for every processor cycle, 3 color clocks happen.

 

As for the reset vector, get a decent 6502 quick reference chart, and it will show you, the RESET vector is $FFFC.

 

-Thom

[RevEng]

So, I know that the main CPU runs at 1.19 Mhz, and I also know that the TIA is 3 times as fast as the 6507, so it runs at 3.57 Mhz. How would I figure out how long a single color clock takes to execute?

Usually you just take the reciprocal of a frequency to get cycle length. Here's the longform thinking, converting to base units...

 

3.57MHz = 3579545 Hz (aka 3579545 cycles per second)

 

1 second / 3579545 cycles = 0.000000279 seconds/cycle ( or 0.279 microseconds/cycle. not sure what end unit you're looking for here)

 

 

Oh, and also, at what address is the reset vector?

This is common to all 6507/6502 systems...

Interrupt LSB   MSB
NMI	  FFFA	FFFB
RESET	  FFFC	FFFD
IRQ/BRK	  FFFE	FFFF

[DementedPurple]

How are the interrupt vectors at $FFFA through $FFFF if the address bus is only 13-bits wide? Or does it count as $1FFA through $1FFF?

[RevEng]

Correct. Because of the missing address lines, 1###=3####=5###=7###=9###=B###=D###=F###

 

You can create a 4k ROM that references any of these addresses instead of 1###, and it will behave the exact same.

[DementedPurple]

One last question, how does the stack work if there's only 128 bytes of RAM? On a system lack the NES, you have 2K of ram, and 256 bytes of zeropage, following 256 bytes of the stack, which lives at $0100 through $01FF, and whenever you jump to a subroutine, the address of where you jumped from is pushed onto the stack, and when you return, it pulls the address from the stack and pushes it onto the program counter. But since the Atari has only 128 bytes of RAM, of which aren't even located at $0100, where would a push to the stack go?

[tschak909]

The memory on the VCS is provided by 128 bytes of static RAM on the RIOT, which is mapped to the bottom of both page 0 and 1 (the magic of partial decoding, similar to the ROM address reflecting above)

 

As the Stella Programmers Guide puts it (paraphrasing), RAM and Stack are shared, and you pray that they never meet.

 

So in other words, keep your subroutine depths low, and try not to push too much onto the stack.

 

-Thom

[DementedPurple]

So does the stack start at $80 and is still 256 bytes long? And since this forum is turning into a bunch of different questions, I'm going to also ask how the noise channel is generated. I hear from some sources that it's completely random, but if that's the case, then why can you adjust the frequency? Is there some sort of algorithm used to generate the waveform?

[Nukey Shay]

The stack moves upward in memory from whatever value the stack pointer was set at. A clean start routine typically resets the SP to $FF. As mentioned, it's shared with user ram, so it's 128 bytes long maximum. Although you can set the SP to hardware ram addresses to make kernel routines more efficient (such as enabling/disabling the ball and 2 missile sprites all in one go).

 

 

You can create a 4k ROM that references any of these addresses instead of 1###, and it will behave the exact same.

In other words, you can easily repurpose the upper 3 irrelevant bits in MSB pointers/tables for other uses

Edited October 2, 2017 by Nukey Shay

[DementedPurple]

Is that what the TXS instruction is for? Do I do 2 TXS instructions to get the full address?

[tschak909]

Stack is permanently attached to page 1, so only one TXS. Please, PLEASE google for a 6502 reference card

 

-Thom

[Nukey Shay]

The SP points to zero page on the 2600. The "full address" is a single 8-bit value.

[tokumaru]

Hey DementedPurple, tokumaru from NesDev here. A lot of this stuff is exactly the same as in the NES, so you should already know a lot of this.

 

It appears that the memory sizes are confusing you a bit, so never forget one thing: mirroring. The CPU may only have 13 physical address lines (a cost-cutting measure), but everything inside the chip still works with 16-bit addresses (i.e. the PC is still 16-bit), so the result is that the 8KB that can be physically addressed appears 8 times in the 64KB addressing space. The same 4KB of ROM can be seen at $1000-$1FFF, $3000-$3FFF, $5000-$5FFF, $7000-$7FFF, $9000-$9FFF, $B000-$BFFF, $D000-$DFFF and $F000-$FFFF. It doesn't matter in which of these ranges you .org your code, it'll work the same. Since the 6502 vectors traditionally sit at $FFFA-$FFFF, it's common to think of ROM in the Atari 2600 being mapped to $F000-$FFFF, but like I said, there are 7 other mirrors that are just as functional.

 

Mirroring also explains the same 128 bytes of RAM being used for ZP and the stack. The same RAM is visible at $80-$FF and $180-$1FF (and several more times across the rest of the addressing space). Stack accesses made by the CPU use $180-$1FF, but it's the exact same physical memory you use for your variables at $80-$FF. That's why you should be very careful with stack usage on the 2600, or you might end up overwriting your variables.

 

Just keep in mind that 256 bytes of ZP, 256 bytes of stack, 64KB total memory, interrupt vectors, and the like are details/limitations of the 6502 architecture, but it's up to the console/computer to provide the actual memory the CPU will see, in whatever amounts and layouts the designers decided on.

Edited October 7, 2017 by tokumaru