FrontBench: using Frontier as a benchmark (Discussion thread)

[atari030]

50 mhz VGA, I didn't expect it to be that high tbh. Right now it is 14mb + 16mb RAM as I can't fit the 128MB under the hood now its back in its original case.

Seeing the other results, its interesting the difference between my MegaSTE and Darklords too. PAL vs NTSC?

[Badwolf]

50 mhz VGA,

Oh, wow. If that's VGA (60Hz), then you should get even higher results at 50Hz RGB.

I didn't expect it to be that high tbh. Right now it is 14mb + 16mb RAM as I can't fit the 128MB under the hood now its back in its original case.
Seeing the other results, its interesting the difference between my MegaSTE and Darklords too. PAL vs NTSC?

Yep, which is why I always ask about the screen refresh rate.

Basically at 50Hz the intro sequence is aobut 30 seconds longer => more frames.

BW

[atari030]

Makes sense. I'm running it in RGB mode now.

[atari030]

Jesus H.... 6528

[Badwolf]

Jesus H.... 6528

Love it!

BW

[alexh]

OK, well I've just tested Frontbench on my TF536 set-up with MAPROM_C.PRG and PAK/3 TOS 3.06 and I'm getting identical results with the "standard" firmware. All very stable.

I'm a newb at these benchmarks. Does FrontBench run in alt-RAM in the TF536-ST?

[Badwolf]

OK, well I've just tested Frontbench on my TF536 set-up with MAPROM_C.PRG and PAK/3 TOS 3.06 and I'm getting identical results with the "standard" firmware. All very stable.

I'm a newb at these benchmarks. Does FrontBench run in alt-RAM in the TF536-ST?

Providing you set the program flags appropriately, yep.

It's one of the few games that can exploit fast ram -- this isn't because it's really clever, it just sets a fixed screen address (in ST-RAM)!

BW

[atari030]

It's not co-pro compatible is it? I've used Frontier as my default test program on my Atari's for years. Brilliant coding.

[Cyprian]

This is technically software I'm distributing, but not the final product you want as I'm not sure of its legal status: you're going to have to do some work. Instructions as below.


FrontBench is the full shareware version of Frontier modified to count frames between two specific places in the intro sequence. A faster computer/memory combination should be smoother and thus able to draw more frames between these two points.

It's not a rigorous benchmark, but it's a decent representation of an AltRAM-supporting game that is heavy on memory access and CPU load. It provides a good visual feedback too. Frontier does not use an FPU.

Please note, Frontier uses the vertical blank to time the intro sequence. The sequence is therefore shorter on 60Hz machines. This will give a frame count ~17% lower than on an otherwise identical configuration running at 50Hz. This needs to be taken into account when comparing results.

Well done @Badwolf
Can you please describe what was changed and how you found free space for the code?

[Badwolf]

It's not co-pro compatible is it? I've used Frontier as my default test program on my Atari's for years. Brilliant coding.

No, it doesn't use anything other than stock 68k instructions.

Well done @Badwolf
Can you please describe what was changed and how you found free space for the code?

No free space hunting. The code's just moved along a bit whenever some more space was needed with the bigger routine tacked on the end.

At every buffer swap it increases the frame counter by one and at a suitable place during the intro drawing it uses the game's own text render code to print a count to the screen.

It also keeps track of every VBL and after 50 it calculates an FPS. This is technically wrong as it doesn't take into acount VGA and NTSC modes. It's also why frame counts are higher on PAL versions as the intro simply takes longer to run.

It's based on a combination of a partially commented disassembly found online, my own work and clues from glFrontier.

I then created the patch process by manually comparing the binary output of my build and the shareware version and itemised the bytewise changes.

BW