exxos's Atari, Amiga & retro forum

exxos wrote: 14 Feb 2022 14:11 I think its "lower ram variables" ? I will try and test the original MAPROM later, but it never worked for me. I don't get the speed up either, but thats the results I got.

Long shot: is EmuTOS initialising at 50Hz but TOS to 60?

BW

Badwolf wrote: 14 Feb 2022 14:16 Long shot: is EmuTOS initialising at 50Hz but TOS to 60?

I don't think TOS runs at 60hz, but I will look out for that thanks.

To keep everyone else in the loop a little bit.. It seems MAPROM was the cause of the slowdown with TOS206 :roll: So 3140 ish is the frame count regardless of EMUTOS or TOS206.

Though I did see such slowdowns before when using MAPROM...

https://www.exxosforum.co.uk/forum/viewt ... 785#p61785

As @Badwolf Pointed out, there is no actual OS accessed during the game so it does not make sense by itself why that happens. Again I can only assume that using the 030 MMU for remapping TOS into alt-ram is actually causing a significant slowdown.

I may tidy this thread up later has it seems to have drifted all over the place..

Running with MAPROM installed on the TT gives 2444 frames vs. 2876, so there's a significant slowdown. (15%)

exxos wrote: 14 Feb 2022 17:49 As @Badwolf Pointed out, there is no actual OS accessed during the game

I should say that I'm not asserting there are *no* OS accesses in the game. I just haven't come across any significant ones.

Keyboard, mouse and joystick perhaps?

Anyway, fairly few in the scheme of things, I'd say.

The MAPROM slowdown is indeed an odd one. I would have thought MMU overhead shouldn't exist (MMU already is active for shadow register mapping AFAIK), but I also don't know what I'm talking about. ;)

I've tried a couple of times to follow how the MMU works and Anders' code and haven't yet succeeded!

BW

Interestingly, Uwe Seimet's ROMSPEED 3.11 does not have a slow down. Indeed, it's marginally faster than stock.

Here's a quick qualitative measurement of FrontBench OS accesses.



Spoilers: not many.

BW

I have moved this thread into the general software section as it has turned into a discussion thread.

The software has had a new post generated which is now locked to keep it clean.

The explanation on the other thread about the slow-down isn't quite complete:

The reason for the slow down actually depends upon how the program is rendering the scene.

If the program is rendering directly into ST-RAM then the CPU will have 5/6ths of the processing time as there will be ten extra times when the CPU is unable to access the ST-RAM. This has nothing to do with the speed of the animation. This issue affects any system with shared memory between the CPU and video sub-systems.

If the program were rendering in TT-RAM and then copying the screen memory over to ST-RAM once it had been rendered then it would be affected far less as the rendering stage would not be interrupted by the screen output cycle.

The internal program clock is indeed matched to the screen refresh, so the demo does run at a faster rate, but this has little to do with the frame rendering rate.

I finally got around to setting this up here and ran it on 2 machines:

Atari Mega STe (stock) - 1227 frames

Atari STacy (Pak 68/3 030 @ 40mhz, no FASTRAM) - 3163 frames

BTW, watching the difference in Frontier between the Mega STe
and the Pak 68/3 equipped STacy is like night and day... :)