Low level hardware questions

[ScumSoft]

[ROM ACCESS]

1) When the Atari wants rom data, it sets the A12 line high to read from the higher address space correct?

2) Does it ever flip A12 high for other things?

3) How long will it allow A12 to remain high with no data before the data valid window expires?

4) If the data valid window expires what state does the Atari end up in?

5) Once valid data is retrieved does the A12 line remain high if the instruction doesn't have the VCS access a lower address space? such as INY, JMP, ect...

 

[DISPLAY]

6) What is the currently achieved copy limit of the RESP0/1 trick? ignoring any alignment issues.

7) What is the max amount of player copies you could get had you sent RESP0/1 directly to the TIA? (bypassing the 6507)

[Omegamatrix]

[DISPLAY]

6) What is the currently achieved copy limit of the RESP0/1 trick? ignoring any alignment issues.

7) What is the max amount of player copies you could get had you sent RESP0/1 directly to the TIA? (bypassing the 6507)

6) 18 per scanline. Scrolling example:

 

http://atariage.com/forums/topic/207391-circus-atariage-2600/?p=2677582

 

7) If you mean something like bus stuffing, then the answer is still 18.

[ZackAttack]

[ROM ACCESS]

1) When the Atari wants rom data, it sets the A12 line high to read from the higher address space correct?

2) Does it ever flip A12 high for other things?

3) How long will it allow A12 to remain high with no data before the data valid window expires?

4) If the data valid window expires what state does the Atari end up in?

5) Once valid data is retrieved does the A12 line remain high if the instruction doesn't have the VCS access a lower address space? such as INY, JMP, ect...

 

[DISPLAY]

6) What is the currently achieved copy limit of the RESP0/1 trick? ignoring any alignment issues.

7) What is the max amount of player copies you could get had you sent RESP0/1 directly to the TIA? (bypassing the 6507)

1) Correct. Based on the schematic of the VCS, A12 is used as the chip select input for the TIA and RIOT. This effectively maps those components into all memory locations below $F000.

2) No. There isn't any internal hardware mapped to that memory range.

3) The 6502 bus timing diagram has this information. After the address is stable the Memory Read Access Time (Tacc) is how long you have to put valid data on the bus. Tacc depends on the CPU speed. It is 575ns and 300ns for 1MHz and 2MHz CPUs respectively. Since the 6507 in the VCS is clocked between 1 and 2 MHz I'd use 300ns as the limit. If that's not enough you could interpolate the timing data to get exact amounts for NTSC and PAL versions.

4) Most likely a random state that either completely crashes the program or halts the CPU. There's a good chance the system will have to be powered off to recover.

5) Based on what I've seen on http://visual6502.org/ A12 will remain high as long as the CPU continues to access sequential memory locations. So yes, A12 will remain high across multiple instructions being executed.

[ScumSoft]

Many thanks! Here's one I forgot.

 

q) How much time do we have after initial power on before rom is first requested?

[ZackAttack]

The 6502 data sheet shows the Input Low Threshold Voltage (V_ILT) as Vss+0.8. In other words once the /RES pin has 0.8 Volts or more the CPU could come out of reset. The first thing it does is pull the reset vector from the ROM. I'm not sure if any clock cycles occur before the actual read of the vector, but in general a good design will be completely initialized before the POR delay expires. The schematic shows a 4.7uF 10K ohm RC network attached to the /RES pin. So if I did the math correctly it has a POR delay of about 8.195ms.

 

Keep in mind that the original systems had inductors on the power and ground pins going out to the cartridge. So there will likely be a good chuck of the POR delay used up while the voltage going to the cart ramps up. Also, there could be other factors that affect how much time there is before the ROM is accessed depending on the system revision. That's why when developing hardware/firmware it is best to test on as many platforms as possible before release. In theory the design should prevent these unintended interactions, but in practice that's more the exception than the rule.

 

Disclaimer: I make no guarantee about the accuracy of this post

[Bryan]

Many thanks! Here's one I forgot.

 

q) How much time do we have after initial power on before rom is first requested?

It appears to be somewhat variable. The reset circuit is not the same on all schematics.