[Video] A simple 16MHz hack for my STE: why memory access is so important.

[Badwolf]

Morning all,

As I threatened in a previous post, I've used the PLCC to DIP adapter to build a prototype 16MHz switcher for my STE as a demonstration of how this adapter opens up upgrade possibilities for the machine.

Of course, the results are poor. I've spoken of the important of fast memory (be that ROM or RAM) in the past -- benchmarks from my DFB1 development really show that -- but this is great demonstration of that importance.

Just a bit of xmas hols fun, anyway:




BW

[exxos]

16Mhz CPU only. 16MHz only when /AS is high.

16CPU_result.png (14.73 KiB) Viewed 3207 times

50Mhz CPU only.

50MHZCPU_result.png (14.82 KiB) Viewed 3198 times

Even if you take the assumption that ROM is running faster (it isn't in those tests) going to 50MHz where ROM speed is still 127%, the figures jump up again anyway. So its not down to ROM speed up.


64MHz CPU - 32MHz ROM

IMG_4831.JPG (118.8 KiB) Viewed 3193 times

[viking272]

Nice video BW, explains it nicely.

Is Alt-RAM feasible for the next step on this type of hack?

[Badwolf]

16Mhz CPU only. 16MHz only when /AS is high.


16CPU_result.png

...

Even if you take the assumption that ROM is running faster (it isn't in those tests) going to 50MHz where ROM speed is still 127%, the figures jump up again anyway. So its not down to ROM speed up.

In your 16MHz result the ROM is benchmarking there at 127%. Also yours isn't using the blitter (which is, of course, still 8MHz on mine), so your relative percentages will be higher.

I did have a very similar figure in one of my earlier tests (126 to 127% on ROM and 189 to your 193% on CPU). If we look at the VDI Graphics Test (less blitter), again it's close (130 to your 131%) when the ROM speed percentage goes up.

Screenshot 2022-01-14 at 12.34.11.png (804.37 KiB) Viewed 3171 times

I actually intentionally disregarded that switching logic as I thought it must be stealing a cycle from the ROM somehow and might be unstable. Now I'm intrigued as to where that ROM figure comes from. This was obviously a very quick hack so I didn't get the logic probe on it.

We can look at relative figures, to take that ROM factor of the equation:

For the VDI graphics test (seemingly the most cpu intensive display test), I got a 9% speed increase from doubling the CPU clock. You go from 131 to 150%, a 15% speed increase, when tripling the clock (16 to 50).

So even allowing for the different ROM access times, the CPU effect on desktop use is shown to be pretty marginal, I reckon.

I think my conclusion that the ROM figure is where most of the display improvement comes from, particularly when blitter is enabled, is therefore fair.

BW

PS. FrontBench never shifted from ~940 frames with all the different rom speed measurement (I went up to full 16MHz access to the ROMs). That's not surprising as it's primary a measure of RAM speed with a little bit of CPU thrown in.

[Badwolf]

Incidentally, one thing I completely missed from my video (on account of an extended period of brain fade caused by an excess of booze, cheese and chocolate, I suspect) was cache.

@Darklord mentioned it in the previous thread and, of course, it bridges the gap between a faster processor and normal ST-RAM.

I did a little bit of research into the Mega STE's L2 cache but couldn't find much out. Is all the logic done in GALs?

It's something I wouldn't mind having a play with, but it really does look complicated to learn the ropes (what with tags, write through, stalling, hitting, missing and all that good stuff), but it's only fair I mention it in passing.

I wouldn't be at all surprised if very good gains could be had with a decent amount of cache.

BW

[pixelpusher]

Incidentally, one thing I completely missed from my video (on account of an extended period of brain fade caused by an excess of booze, cheese and chocolate, I suspect) was cache.

@Darklord mentioned it in the previous thread and, of course, it bridges the gap between a faster processor and normal ST-RAM.

I did a little bit of research into the Mega STE's L2 cache but couldn't find much out. Is all the logic done in GALs?

It's something I wouldn't mind having a play with, but it really does look complicated to learn the ropes (what with tags, write through, stalling, hitting, missing and all that good stuff), but it's only fair I mention it in passing.

I wouldn't be at all surprised if very good gains could be had with a decent amount of cache.

BW

If you want to improve real world performance in most applications (and not go for something like a fast division - which programmers tried to avoid anyway), then a direct mapped cache is the cheapest solution - even with just 16 MHz. The old mach16 accelerator did something like this (see GAL listings) in the 90s. See: http://atari4ever.free.fr/hardware/zip/mach16.zip

Note however that the public available implementation had trouble with some newer chipset revisions. The principle used there for the direct cache implementation still applies though.

[Steve]

So out in the wild we have adaptors like the MonSTer or LightningST which give AltRAM, then we have 16/32mhz boosters with no AltRAM. What gives? ps I know AltRAM won't give graphics boosts because that is ST-RAM only, but would be awesome for productivity or multi-tasking.

[exxos]

So out in the wild we have adaptors like the MonSTer or LightningST which give AltRAM, then we have 16/32mhz boosters with no AltRAM. What gives? ps I know AltRAM won't give graphics boosts because that is ST-RAM only, but would be awesome for productivity or multi-tasking.

https://www.exxosforum.co.uk/forum/viewt ... 280#p57280

But I stopped working on it a while back. The overall cost of the SRAM would put the thing around £200-£250. Plus lack of general interest. Its one reason I sidetracked to the TF536 for a bit.

[Badwolf]

...a direct mapped cache is the cheapest solution - even with just 16 MHz. The old mach16 accellerator did something like this (see GAL listings) in the 90s. See: http://atari4ever.free.fr/hardware/zip/mach16.zip

Note however that the public available implementation had trouble with some newer chipset revisions. The principle used there for the direct cache implementation still applies though.

Wow, only three GALs!

That's really interesting, though, Pixelpusher. Thanks. I'll have to see if I can pick through what's going on there when I get a minute.

Cheers,

BW.

[czietz]

Wow, only three GALs!

The logic required for caching is not that complicated. The much bigger issue is getting the required tag RAMs.

Even though it's of course not a 1-to-1 replacement, adding Alt-RAM to an accelerator is probably the cheaper (and more easily obtainable) solution today. BTW: While it is not a feature we would advertise or support, I know people successfully ran the Storm ST at 16 MHz bus speed. Therefore, it should be possible to adapt an accelerator to use it.