In the latter case, I would assume my tinkering with the timer would hose something else up. The intervals I saw were fairly short and made sense in the context of syncing up the screen. I'm pretty sure the timer goes unused during the basic program code that executes after the drawscreen.

The timer is absolutely essential during the code that executes after the drawscreen. I'm not quite sure why your store to TIM1T didn't mess things up, but the timer is the only way the system can know where the electron beam is the next time you call drawscreen and wait for it to be at the bottom of the screen before triggering vertical retrace.

I'm sorry but I don't think that is quite true.
I've spent the better part of this evening reading through some other assembly program sources. (Thanks Kirk for yours! The red line thing is excellent.)
The way it really works, I believe, is that the basic program is assumed to take less time than what is available, and it runs in the overscan period where things don't need to be synced in the way the kernel does. When control passes to the display kernel, it waits for a sync, then uses the timer to delay for specific things related to the display. When the frame is done, control then passes to the basic program again for the next cycle.
Batari? Am I way off here? What I don't know is if the vblank section of code is using the timer or not.
Edit: Instead of dribbling this out, here was my plan.
Ground the paddles, trigger the timer at the beginning of the execute time available to the basic program, write a zero to the paddle variable and enable interrupts.
I did a search on the riot chip today to better understand how it worked. And it's got an interrupt capability! Another quick search of the stella list suggests this capability is not being used. So that begs the question, is the interrupt even connected to the CPU? If not, this is all moot. But I think it is, so I'm moving forward on that assumption.
The next step, in reading the paddles outside the display kernel, involves releasing the ground on the paddles, letting them charge, so that gets done asap.
While they are charging, the timer triggers it's interrupt multiple times in sequence, adding one to a variable accessable to the basic program, if the paddle does not yet show the charged state. Once the paddles are charged enough to show a true result, the interrupts quit adding. If this never happens, the last interrupt puts things back to normal so the display kernel never knows what happened and it uses the timer the way it always does. Interrupts would be disabled at this time.
Of course this slows the basic program down, but maybe there would still be plenty of time for things to happen anyway. In the case of the ooze game, I could break actions across frames and still keep things fairly fast and furious. (Which is what I want the paddles for. the game is fun now, but the joystick kind of limits what could be happening.)
The alternative would be to check the paddle throughout the program, using the timer count to correct for variances in the program execute time, thus bringing the paddle accuracy to a useable level.
Sorry for not detailing that sooner. I really didn't formulate the entire idea until I saw the Interrupt capability and also saw that it really hasn't been used much, if at all.
And that brings me back to the emulator question. I didn't see the behavior I expected today. It's as if the timer is being ignored, where on a real machine it would be doing something. Probably breaking something, but at least I would know.
Being a newbie, feel free to slap this idea down hard. I'll learn something good either way, but you don't get unless you ask, so I'm asking!
...what's the cheapest way to get code running on a real 7800, which is what I have actually?
Edited by potatohead, Thu Aug 4, 2005 11:54 PM.