Just a heads up to everyone, RemoWilliams is now part of the testing team.

Anyway.... here's some PM's we've exchanged today... see if you guys can think of anything.

CJ wrote:

they both (1942 and BoB) default to whatever the machine is at when its run. BH1942  turns cache off on F30/TT....

So they should run flat out...

Remo wrote:

See this is where I'm getting confused.  My MSTE clearly boots at 8Mhz (double checked by forcing 8Mhz/nocache from the renamed CPX control program) - but BH1942 runs at the same greatly accelerated speed regardless of what speed the MSTE is set for going into the program.

If I'm entering BH1942 at 8Mhz on the MSTE, the performance should be the same as Steem or my 1040ST, right?  But it's not...

CJ wrote:

Then that MUST be something wacky on your machine because nothing is changed as far as speed goes on that one.

Remo wrote:

It basically mirrors the results I'm seeing on many of those single load files.  What the hell could cause that?  And why wouldn't I see it with things outside these patches?  If my machine was somehow automagically going into overdrive on it's own it should speed up and break everything else like other cracks and copy protected originals.

And you'll like this.  I just tried an old floppy crack of BH1942 and it runs at the expected 8mhz speed.  

Maybe it's just me.  I swear if I had a nickel for everytime in my life I've heard 'I've never seen/heard that before' I'd be rich.    

And I just tried BOB, and when the machine is set for 8Mhz it runs at normal speed, and 16Mhz at an accelerated speed like it should...
Not that this will likely help much, but I ran sysinfo on a clean boot and it says 8Mhz / cache off.

CJ wrote:

OK, it kinda makes sense.

BoB does nothing to the CPU, and that is working as intended.
BH1942 disables the cache.... 99% of all our patches disable the cache by default...

So we've narrowed it down to the cache. What doesnt make sense is that the intros dont play with cache control until they quit.. hrm i'll have a think but it does sound like something up with your cache.

CJ wrote on 02.02.09 at 08:24:40:


Sorry, no idea...
I just want to note that enabling the cache only on a MegaSTE won't give any speed boost - it has to be set to 16Mhz CPU as well (I guess you know that).
16Mhz with cache off, otoh, also doesn't give any significant acceleration (only a few percent), so, for some reason, Remo's machine seems to be running at 16Mhz + cache on.

Hi guys

Shw - I just tried Viking Child on my MSTE and Steem at the same time for comparison.  

(MSTE) Unlike other intros, this one (and the others that use the same intro) the intro music and everything is at the right speed.  8Mhz / 16Mhz/cache doesn't seem to make a difference in either game loading speed or ingame play speed.   The ingame speed seems to be the same as Steem.   For example as I'm watching both screens and hit up to jump  it takes exactly the same time on Steem and the MSTE (regardless of intro speed settings) for the character to jump up into the air and return to the ground.  Ingame sound (50/60hz booted) is always too fast compared to Steem

So a question here would be - should I be seeing double the ingame speed at 16Mhz/cache or does this game have a frame limiter, and the extra speed would only help for bog downs.

If so, is there a game that will play flat out loony at 16Mhz/cache to make the difference obvious?

I can tell you for sure as an example that BOBTFH most assuredly plays twice or so as fast when I use Xcontrol to set 16Mhz/cache before launching it, over the standard 8Mhz boot speed.

I just tried the new release of JP2 that has the fancy SHW intro.  Regardless of the selected state of the radio buttons in the intro for  16mhz & cache  (basically either both on or both off) in game speed of Mr. Pond is exactly the same.

I measured his speed by my very scientific 'press right on both Steem and the MSTE at the same time and see how fast he runs' test.

Now, get this...   I loaded the older JP2 crack (no nice intro) after MSTE cold boot, and as expected again it ran the same speed as Steem.   However - after cold boot then running Xcontrol and selecting 16Mhz/cache, then running old JP2 again - he is now moving much faster as expected and beating his Steem competition by a large amount in the old foot race test.

Don't know whether this is any worth at all, but in both speeds in the old JP2 test, the music runs at the same silly high speed.

Other than replacing the 2.05 ROMs with 2.06 ROMs shortly after getting the unit, no.

Maybe it's worth dumping my 2.06 ROMs to verify them ?

EDIT: ok, looks like that's not it.

c9093f27159e7d13ac0d1501a95e53d4 *TOS.ROM  (my 2.06 dump)

c9093f27159e7d13ac0d1501a95e53d4 *TOS v2.06 (1991)(Atari Corp)(Mega-STE)(US).img

remowilliams wrote on 02.02.09 at 18:18:32:


you're right... I've just tested my original ULS v1 of JP2 and it runs much faster then my new ULS 3.12 version of JP2 (on my mste). I'm not sure if cache is being turned on. to investigate!

Shw

Yes I understand what you mean. Until now I thought that not all falcon's were created equal. Apparently that is also true for the MSTE's as well.

Anyway, welcome to the testing team.

CJ wrote on 02.02.09 at 07:59:52:

Since BH1942 is always running in super duper mode on my MSTE (and I can't force it to run at 8Mhz), is it possible your cache flipping code is somehow doing the opposite of what's intended and flipping my machine into 16/cache on?

That may not make any sense, but it does fit the evidence at hand.  

Shw wrote on 03.02.09 at 17:11:39:

Confirmed.  (MSTE) JP2 intro set to 16/cache off he's running around like a madman.    

remowilliams wrote on 03.02.09 at 21:28:22:


I don't think so.
8Mhz and cache on is physically impossible on the Mega STE - the hardware does not allow it.
That's also the reason you won't find this setting in the CPX module.

Okay, since I seem to be in some sort of personal Atari twilight zone...    

Here's some nudie pics of my actual MSTE that you've all come to love.    Anyone see anything odd?  Besides the weird looking SIMMs.

Ok

2 test prgs.

VBL_INTR.PRG plays the music in the vblank interupt.
VBL_MAIN.PRG plays the music in the main loop with a vsync check.

try those

I guess the reason music plays ok on my intros is that I play the music at 50hz using Timer C....

not the vbl.

Shw

CJ wrote on 04.02.09 at 05:33:39:


I was thinking about that, too.
Is it an LCD monitor perhaps?
Would a scan-doubler also double the VBL interrupt frequency?

Looking at CJ's code, it now seems to me that the VBL routine is executed twice on Remo's machine, before returning to the main code.
If it was just a higher frequency, VBL_MAIN.PRG should also play at double speed.

So, yes, looks like a hardware failure to me.