> Erik. Thanks for the reply. As it turns out I figured all that out
about
> 15 minutes after I mailed the Stella list. I changed the timer to 1/5 of
a
> second and then realzed my routine only checked the format of the screen I
> told it to draw. It sucked. I am trying another route though. I think
it
> ultimately will suffer from the same problem, but it's a good excercise in
> programming to help me cut my teeth a bit. A complete PAL frame uses only
> 99.23% of the cycles that a complete NTSC frame uses. I'm going to try
and
> figure a way to measure usage to figure format. I suspect it's completely
> impossible, but I never give up after only 13 or 14 failures. I usually
> wait for around 3 or 400. I'll keep everyone posted. Later.
Detection routines based on the frame timing won't work, because
both consoles should react the same to whatever frame you make them
draw.
There might be a possibility to detect NTSC and PAL consoles, though.
But I'm not sure if it really would work reliably with all of them.
The Stella programmers guide tells us not to access any of the
positioning registers during the 24 cycles after a HMOVE, as that might
result in "random" positions. In most cases the positions will be
different from the normal positions, but the NTSC and PAL consoles will
still give the same predictable results.
But in Kool Aide Man the score display positioning routine accesses the
registers in such a wierd way, that on all my PAL consoles the players
will be positioned partly on top of each other. This causes a constant
triggering of the collision detection, which makes the game unplayable.
On the NTSC consoles the game seems to work normally though.
So I think you could use this positioning trick to detect the console
type. But I'm not sure how SECAM consoles would react. And the emulators
would also fail this test and react similar to the PAL consoles.
Ciao, Eckhard Stolberg
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
