Search the Community
Showing results for tags 'timing'.
Found 4 results
Greetings Starfighter, You have been recruited by the Star League to defend the frontier against Xur and the Ko-Dan armada. --- Sorry, wrong topic. I loved that movie, though. Greetings Atari Fans and Developers! I am a computer programmer, no stranger to assembly language, yet I am new to the 6502 (or 6507, as it were) chip and - more to the point - cpu cycle counting. As such, my first Atari program is an exercise in timing. I have attached my first program for your critiquing pleasure. Basically, the program displays colored lines in the background, each based on the current descending line count. However, that being only marginally interesting, it also changes the color as frequently as possible on the current scan line. Finally, just for fun, it tracks a cycle counter that is added to the current line number. The final effect is 11 scrolling color bands. I have executed this program both in Z26 and Stella, and observed a couple of bugs that I am having trouble tracking down: * At regular intervals there is a short period of increased velocity, as if the program is "catching up". * There is a minor visual anomaly that results in the horizontal seems between scan lines being slightly crooked at times. This is probably related to the previous issue, and could very well be simply due to a limitation of the EMUs. * The first color band is shorter than all the others, while the last is longer. I feel like this is just the nature of the alignment of the cycles, but I am curious if it can be fixed. I haven't the means to dump this to a cart, but I do wonder if those behaviors would be the same on the actual device. If any devs out there have some insight or general advice, I'd be glad to have it! Thanks, Grif PS: This was part of the alphabet would look like if Q and R were eliminated. PPS: I love the Topics Tags. We need more adoption of tags on the internet. student.asm
Looking at this schematic I see a 74LS74A which appears to be set up to trigger a cycle of WAIT upon every M1. That's not too uncommon for Z80 machines because it extends the opcode fetch read from 2 cycles to 3, moving it into line with most other accesses. It's even offered as a sample external circuit in at least one of the Z80 data sheets. Yet I've never heard about that in ColecoVision world. It would if I'm reading things correctly give operations the same cost as on the MSX. So e.g. NOP would take 5 cycles, not 4. Since I trust my schematic reading maybe only 70%, having no formal grounding in electronics, can anybody confirm or deny that the ColecoVision inserts an extra cycle into every M1 machine cycle?
Per the SN76489 data sheet, it needs 4 cycles to load a data value. I note from the schematic that its ready line is connected to the Z80's WAIT input. I notice that the Z80 OUT will have been asserting the write input for 1.5 cycles before it tests WAIT. So it looks to me like it should end up inserting three WAIT cycles, making the entire machine cycle seven cycles long. Or, in net, adding three cycles to any OUT that is decoded to access the SN76489. Is that a correct reading?
Greetings Atari Fans and Developers! My first post was in the n00bs section, but Godzilla suggested I post here and reference that one, so here I am. I feel like my question is beyond the newbie topic, even though I am new to 2600 programming. I do look forward to getting some feedback. Here is my original post: http://atariage.com/forums/topic/212657-jumping-in-head-first/ Thanks, Grif