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.

Guys, do any 3rd part MSTE upgrades (cpu/bus) work by detecting the cache enable lines?

CJ wrote on 02.02.09 at 08:24:40:

Guys, do any 3rd part MSTE upgrades (cpu/bus) work by detecting the cache enable lines?

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.

Remo: Do my patches work with 8/16mhz?

For example - James Pond 2, Legends of Valour, Viking Child, Wizkid ?

maybe it's an intro issue?

Shw

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.

No you shouldn't see an ingame speed difference, apart from some framerate differences. A good game to check would be james pond 2. The effect of the added speed is.. obvious.

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.

Did you do anything to your MSTE's TOS at any time in the past?

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

Seems as if for some strange reason your MSTE is turned to 16MHz + cache no matter what. As if something is installed that forces that operation. I can't understand it.
Have you tried booting your mste, set it to 8MHz and then start the game?

remowilliams wrote on 02.02.09 at 18:18:32:

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.

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

Christos wrote on 02.02.09 at 19:24:09:

Seems as if for some strange reason your MSTE is turned to 16MHz + cache no matter what.

I could believe that if all my other software (commercial or otherwise) ran entirely too fast.  Or if it looked to my eye at bootup that the machine was running much faster. I've spent many years watching GEM windows snap open and closed - and I can immediately tell if the machine is running 16/cache.

Or for more empirical data:

Cold boot:

http://img502.imageshack.us/img502/2923/img10615630051wc2.th.jpg

On cold boot after setting 16/cache in Xcontrol:

http://img515.imageshack.us/img515/4783/img10645593651bz5.th.jpg

So she's definitely not booting up at 16/cache on her own.


Christos wrote on 02.02.09 at 19:24:09:

As if something is installed that forces that operation. I can't understand it. Have you tried booting your mste, set it to 8MHz and then start the game?

Yes, and it makes no difference to the new JP2 - it always runs at the same normal 8Mhz speed (relative to Steem speed) regardless of intro speed settings.

Whereas old JP2 runs at 8Mhz speed on cold boot, and at 16/cache expected accelerated speed when selected beforehand in Xcontrol.

So in a nutshell new JP2 always runs at normal speed, whereas I can make old JP2 speedup by manual Xcontrol intervention prior to launch.

And I've probably given everyone a headache by now.   :(

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. :)

Christos wrote on 02.02.09 at 20:44:35:

Anyway, welcome to the testing team. :)

Thanks.  ;)  

Hopefully we can figure out what's going on here, as now it's moved to the 'under my skin' category.   >:(   ;D

CJ wrote on 02.02.09 at 07:59:52:

BH1942 disables the cache.... 99% of all our patches disable the cache by default...

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.  :-?

spot on!!

I've just traced the code... the cache on/off is the wrong way round!

For instance, try my James Pond 2 patch with 16mhz ON and Cache OFF

it then mirrors the speed of ULS 1, ie 16mhz....

please try.

Shw

Shw wrote on 03.02.09 at 17:11:39:

try my James Pond 2 patch with 16mhz ON and Cache OFF it then mirrors the speed of ULS 1, ie 16mhz....

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

Hmm... How far might that cache code issue go?   As in, previous releases where you think you are turning the cache off - either manually, or not being allowed to select it "---" in ULS...

Might that be why games otherwise running at normal 8Mhz speed have absurdly fast music for me ?

remowilliams wrote on 03.02.09 at 21:28:22:

Hmm... How far might that cache code issue go?   As in, previous releases where you think you are turning the cache off - either manually, or not being allowed to select it "---" in ULS... Might that be why games otherwise running at normal 8Mhz speed have absurdly fast music for me ?

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.

Yeah, that's a very good point.  Forgot about that.

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

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.


http://img4.imageshack.us/img4/9170/mstelco8.th.jpg http://img10.imageshack.us/img10/9886/mstemlq4.th.jpg http://img13.imageshack.us/img13/2999/msterup0.th.jpg

Klaz just pointed out something in the Wrangler thread.

All music in games is performed in the Vblank - regardless of CPU speed (8/16/20/68000/10,000,000Mhz) this would always be 50Hz or 60Hz.

I'm going to have to say I agree with Klaz and something I also mentioned earlier - Your MSTE has VSYNC issues :)

As for "how far does the ULS bug go" - unfortunatly - all the way back to release 1 in November.  HOWEVER, nobody else is getting the extreme speed issues you have described (this is not to say we don't believe you!) - So lets look over those JPGs of the inside of your beastie. How are you connecting to a screen? Monitor?

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 :)

---

VBL_INTR.PRG plays too fast (much like I've heard lately with other things)

VBL_MAIN.PRG plays just right.  

My MSTE hates me.   :'(

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

Music in VBL Interupt:


Code (]      pea supercode(pc)
     move.w #$26,-(a7)
     trap #14
     lea 6(a7),a7
     clr.l -(a7)
     trap #1

supercode
     moveq #0,d0
     bsr music

     move.l $70.w,-(a7)
     move.l #vbl,$70.w

     move.w #8,-(a7)
     trap #1
     add.l #2,a7

     move.l (a7)+,$70.w

     move.l #$8080000,$ffff8800.w
     move.l #$9090000,$ffff8800.w
     move.l #$a0a0000,$ffff8800.w

     rts

vbl      movem.l d0-a6,-(a7)
     bsr music+8
     movem.l (a7)+,d0-a6
     rte

music      incbin "jetset.max"
     even[/code):

Music in Main loop: [code]      pea supercode(pc)      move.w #$26,-(a7)      trap #14      lea 6(a7),a7      clr.l -(a7)      trap #1 supercode      moveq #0,d0      bsr music      move.l $70.w,-(a7)      move.l #vbl,$70.w loop      bsr music+8      move.w vbl_tick,d0 .hold      cmp.w vbl_tick,d0      beq.s .hold      cmp.b #$39,$fffffc02.w      bne.s loop      move.l (a7)+,$70.w      move.l #$8080000,$ffff8800.w      move.l #$9090000,$ffff8800.w      move.l #$a0a0000,$ffff8800.w      rts vbl      movem.l d0-a6,-(a7)      add.w #1,vbl_tick      movem.l (a7)+,d0-a6      rte vbl_tick      dc.w 0 music      incbin "jetset.max"      even

According to Remo, interupt works too fast, Main loop is ok. Looks like a confirmed HW fault to me?

CJ wrote on 04.02.09 at 05:33:39:

How are you connecting to a screen? Monitor?

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

OK try this one... If the music is twice as fast, your machine is generating 2 VBLs each frame for some reason.

[code]      pea supercode(pc)
     move.w #$26,-(a7)
     trap #14
     lea 6(a7),a7
     clr.l -(a7)
     trap #1

supercode
     moveq #0,d0
     bsr music

     move.l $70.w,-(a7)
     move.l #vbl,$70.w

loop      bsr music+8
     bsr music+8
     move.w vbl_tick,d0
.hold      cmp.w vbl_tick,d0
     beq.s .hold
     cmp.b #$39,$fffffc02.w
     bne.s loop

     move.l (a7)+,$70.w

     move.l #$8080000,$ffff8800.w
     move.l #$9090000,$ffff8800.w
     move.l #$a0a0000,$ffff8800.w

     rts

vbl      movem.l d0-a6,-(a7)
     add.w #1,vbl_tick
     movem.l (a7)+,d0-a6
     rte

vbl_tick      dc.w 0

music      incbin "jetset.max"
     even[/code]

---

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.  :(

CJ wrote on 04.02.09 at 07:23:29:

OK try this one... If the music is twice as fast, your machine is generating 2 VBLs each frame for some reason.

Yes, that too is sadly playing silly fast.

What in the world could possible cause the machine to generate 2 VBLs per frame?  If a likely HW culprit could be found, I'm not adverse to performing surgery on her.

This Topic was moved here from Internal Testing forum [move by] CJ.

From DHS:

Earx wrote:
on the falcon the double vbl bug is caused by insufficient termination on the vga interface. hence, the vbl signal bounces back from the monitor to the falcon's hardware.

some vga monitors or adapters have higher resistance so the bug doesn't occur (probably as with the atari engineer's monitor).

the same thing could be affecting your mega ste. that's the only thing i can come up with.

HOLY F*ING MOLY!  Hit it out of the park on the first shot!!

It's my goddamn SCART cable!   AHHHHHHHH!  the madness!    :D

VBL_INTR.PRG plays correctly when connected to a trusty old C1084S.  When I plug in the SCART setup, I suddenly get the wacky music.  And it changes on the fly if you plug or unplug it.  It's like some electronics carnival trick from hell.   :o

Actually the SCART cable by itself doesn't cause it, I have to connect the cable to the SCART switchbox, or directly to the component converter for it to cause it.

Of course this is a different problem as I need the SCART setup to work with my modern display, but at least it is quantifiable now.

Thanks for all your help guys, you are the best!  :)

Or.. pack it all away and put the falcon there instead. There. problem solved :)

CJ wrote on 05.02.09 at 02:36:11:

Or.. pack it all away and put the falcon there instead. There. problem solved :)

Yes there is always that too.  If I had a way to hook the Falcon to the component inputs on the display I use for this stuff, I probably would have done that.

Anyhow, I (sort of) fixed the issue in the interim until I can get a pro opinion on the right way to do things.   I separated my H&VSYNC tied inputs to SCART 20, and left HSYNC there, while moving VSYNC to SCART 11 to create a sync on green signal which my component converter accepts.  I think I made the picture a bit dingier looking, but at least VBL music and routines play at the right speed now!!   8-)

remowilliams wrote on 05.02.09 at 03:25:18:

CJ wrote on 05.02.09 at 02:36:11: Or.. pack it all away and put the falcon there instead. There. problem solved :) Yes there is always that too.  If I had a way to hook the Falcon to the component inputs on the display I use for this stuff, I probably would have done that. Anyhow, I (sort of) fixed the issue in the interim until I can get a pro opinion on the right way to do things.   I separated my H&VSYNC tied inputs to SCART 20, and left HSYNC there, while moving VSYNC to SCART 11 to create a sync on green signal which my component converter accepts.  I think I made the picture a bit dingier looking, but at least VBL music and routines play at the right speed now!!   8-)

Anything wrong with just hooking it up on a VGA monitor? Anyway, component is pretty easy on the falcon. Just soldering 2 wires..

Two wires for component?   :-?

Anyhow yeah, the display I use in the 'classic' area here is a 15Khz component capable CRT.  I can use it with RGB outs from lots 'o' my classic consoles and computers (like *gasp* my Amigas  ;D, and even my Speccy +2)

Yes.. two wires. Made a few of those to record my videos from the falcon. Here's the schematics.

http://alive.atari.org/alive14/composit.php

Christos wrote on 05.02.09 at 21:22:30:

Yes.. two wires. Made a few of those to record my videos from the falcon. Here's the schematics. http://alive.atari.org/alive14/composit.php

Ah, composite video - yeah that's different.  Component is YPbPr.  Like RGB but a bit different.

Thanks for the link though, I didn't know the Falcon had that.  ;)

Aha, I thought that's what component was..  Anyway, i think the falcon is meant for vga

Yeah the Falcon is 31.5Khz RGB/VGA.  Great in most senses for using modern displays (not so great for my specialized classic setup).

VGA of course became a pain in the ass for legacy software, but I see people working on that little problem now.   8-)

So for posterity, or in case someone cares, or there is someone out there who has luck like I do...   :D

I seem to have solved the dingy video problem that was caused by creating a SCART sync on green.  

Excepting ground, here is the final config:


Code (]ST                  SCART

HSYNC      ----[100[ch937):

]-----      20 RED      ----[150Ω-----      15 BLUE      ----[150Ω-----      7 GREEN----[150Ω-------- 11                     / VSYNC----[150Ω-----/ AUDIO                  2&6

I'll change the title of the thread so it doesnt make you out to be a drug addict :)

Thanks CJ for the topic change.  In addition to my substance abuse vindication, hopefully a lost soul or two out there might find just the info they are looking for.  :)


CJ wrote on 31.01.09 at 23:22:38:

Ok, I was just discussing this with GGN and he thought you meant his intro (big D-Bug logo moving in a circle, text over it) and I thought you all meant my intro (static D-Bug logo, wobbly text over it) However, we both concluded it doesnt matter as they both use standard trap calls to read the keyboard. I do, however, know that the strobing/disjointed text you are describing does indeed happen on my intro when the falcon is exhibiting the very well known twinsync bug, but this doesnt explain the MSTE problem.

As far as the 'twinsync' issue - you called it, and indeed the intros work correctly as they should now.