ST536 STE EDITION

[exxos]

ok, sorry I missed that part

Problem is TOS decides between blitter or cache in the desktop menu.. But then somewhere when it accesses blitter, it decides to turn caches off.. but getting them to turn back on again is difficult as TOS won't let you do it from the desktop menu anymore. So I think it gets confused over if it has a blitter or not as the menu uses the same variables. Where and how no idea...

[exxos]

I have been searching through the source code and I really cannot find any explanation as to how TOS turns off the caches when blitter is enabled.

BUT even that doesn't entirely make sense because according to GB6 and SI.CPX the cache is still enabled. But according to the desktop menu it is disabled and it will not let me enable it again until the blitter is turned off.

So it seems the cache desktop option, is doing something else other than actually disabling the caches.. but its prettymuch doing the same thing.

Not entirely following how the menu system works in TOS either. So I can't figure out how the cache menu click is even processed in the first place :roll:

My only thought is to remove the blitter stuff out of the menu system altogether see that resolves the problem.

EDIT:

Nope that didn't help :roll:

[exxos]

I wonder if I'm looking at something wrong with all this.. Maybe the cache menu is a red-herring on the desktop as the caches look to be enabled still everywhere else.

So I'm wondering if there's simply a huge ton of cache clearing happening during blitter access and resulting in the appearance the caches are disabled...

[Cyprian]

@exxos can you share the TOS ROM image and provide instruction on how to reproduce this issue? I can try it with Hatari debugger.

[exxos]

@exxos can you share the TOS ROM image and provide instruction on how to reproduce this issue? I can try it with Hatari debugger.

Yeah I'll do that now... Though I didn't think Hatari worked with anything but 404...

[Cyprian]

@exxos can you share the TOS ROM image and provide instruction on how to reproduce this issue? I can try it with Hatari debugger.

Yeah I'll do that now... Though I didn't think Hatari worked with anything but 404...

Hatari works great with any Atari ROM, e.g. 1.x/2.x/3.x/4.x/EmuTOS/MagiC

[exxos]

Hatari works great with any Atari ROM, e.g. 1.x/2.x/3.x/4.x/EmuTOS/MagiC

I will have to try that again sometime then as it always seemed stuck on only working with 404 last time I tried it, maybe it was fixed in later versions..

I did a video..(still uploading) but ended up confusing myself towards the end... as turning the blitter on/off started having no effect on the speed test in GB6.. when at first it did..

These are the files you will need.

STE536.zip

[exxos]

@Cyprian

I think what might be confusing me is GB6 likely turns caches on by default, so its basically doing the same as TOS cache being turned on. But that aside, why won't the caches behave in the menu or in benchmarks when blitter is enabled.. Even when desktop cache is OFF, they are again enabled in SI.CPX and GB6.. but the scores are low, like they are disabled. Something else is going on somewhere..

[Cyprian]

I see three issues here:
1) "BLITTER.ACC" crashed several times :)

STE030.png

2) TOS Desktop cache/blitter settings conflict with BLITTER.ACC settings somehow. I suspect that the Desktop's "Options" menu is using its internal variable for cache/blitter status, instead of checking if cache/blitter is really enabled/disabled. I'll try to check it in Thorsten's source code.
3) the ALT RAM/TT-RAM benchmark figures - 723% with the BLiTTER Enabled vs 826%/767% with the BLiTTER disabled
Here it may be that BLiTTER collides somehow with the 030 bus. BLiTTER can address entire 24bit address space (including hardware registers), maybe the accelerator doesn't like it.

[exxos]

I see three issues here:
1) "BLITTER.ACC" crashed several times :)

Strange, never crashed once for me.

2) TOS Desktop cache/blitter settings conflict with BLITTER.ACC settings somehow. I suspect that the Desktop's "Options" menu is using its internal variable for cache/blitter status, instead of checking if cache/blitter is really enabled/disabled. I'll try to check it in Thorsten's source code.

Not simple to work out what's doing what.. Turning Blitter on just always cause TOS cache menu to forced into unticked. I mean what's preventing that from being enabled? It's not even greyed out for disabled..

3) the ALT RAM/TT-RAM benchmark figures - 723% with the BLiTTER Enabled vs 826%/767% with the BLiTTER disabled
Here it may be that BLiTTER collides somehow with the 030 bus. BLiTTER can address entire 24bit address space (including hardware registers), maybe the accelerator doesn't like it.

I did a wonder something similar but don't see what or why. I don't think these issues happen until BLTFIX is loaded.

But blitter shouldn't really even be used during TTram benchmark anyway.