exxos's Atari, Amiga & retro forum

exxos wrote: 19 Apr 2022 16:46 Struggling with the ST_RAM decode for the cache.. the fitter managed it after like 10mins though!

Why not to use a bigger CPLD, at least for developing purposes? There is a compatible XC95288XL variant with twice the capacity. You could later decide if it's worth the extra cost, or optimize for the smaller model.

ijor wrote: 19 Apr 2022 17:06 Why not to use a bigger CPLD, at least for developing purposes? There is a compatible XC95288XL variant with twice the capacity. You could later decide if it's worth the extra cost, or optimize for the smaller model.

Yeah, I would have to build another board and really don't have the time or motivation for soldering stuff anymore.

exxos wrote: 19 Apr 2022 16:35 Normal version.
Cache version.
Thing is, there is no ST-RAM cache code in my 536 yet....

Could still make sense. The 68030 doesn't care about the CIIN pin when it comes to writes.
(It will also actually ignore the pin even on reads, if what it attempts to read is already in the cache)
The only case it actually cares about that pin is when the cpu is doing a read from something that is not in the cache already.
Personally I find it a bit crap/odd.. but that's what Motorola decided :)

So with maprom not cache-inhibiting ST-RAM, writes will actually make the data end up in the cache.
And subsequent readbacks from these will retrieve from cache if they're still in it..

The firmware change is needed so cpu-reads can put things in cache too.

exxos wrote: 19 Apr 2022 16:35 With ST-RAM cache enabled in code:
Oddly seems slower. :shrug: I might have screwed the code up :shrug:

You should be able to verify if your firmware side is working by running Gembench from ST-RAM.
If everything is working it should give you an integer-division score of 1729 exactly like when you run it from alt-ram.
You should also notice a pretty nice speed boost in Hard Drivin, Driller or other 3D games that has to run from ST-RAM (remember have cache enabled in TOS)


But the result you got actually mirrors my result so I think it's working?
My previous best result in Gembench (run from alt-ram, have st-ram relocation enabled in maprom) became slower with ST-RAM cache enabled.
Possibly things fighting over space in the cache, causing additional misses which makes some of the tests slower than if it had no cache. Don't really know :)
All my other variations of Gembench tests became quicker with ST-RAM cache enabled though, sometimes by quite a bit.

There is really no "best everywhere" when it comes to caches, especially when dealing with software that was written before caches existed.

Having a cache can easily be detrimental to performance if the software is cache-unfriendly enough.
A miss costs 8x of what a normal read does. A hit on the other hand, is extremely fast.
A miss fills 16 bytes into the cache though, potentially allowing for multiple subsequent hits unless the software is "jumping all over the place" in memory and constantly trashes the cache..
It all depends on the software and what ratio of hits/misses it produce.

Generally speaking, it'll most likely give you an overall net gain.

For things dealing mostly with alt-ram I don't think you'll gain anything though.
Maprom is already relocating a bunch of the low st-ram to fastram so that area wont benefit from the cache.
Running something from ST-RAM is where it will make a huge difference.

I think it's absolutely worth it.
Most games are unable to run from altram, and these can get a pretty huge boost in performance.
The few that are alt-ram optimised (are there any other than Frontier?) are sufficiently fast already so even if the performance increase is zero or if it makes a benchmark a small bit slower I think it's worth it for bumping the performance on the lower-end of the spectrum?

agranlund wrote: 19 Apr 2022 17:36 The few that are alt-ram optimised (are there any other than Frontier?) are sufficiently fast already so even if the performance increase is zero or if it makes a benchmark a small bit slower I think it's worth it for bumping the performance on the lower-end of the spectrum?

Yeah that is what I meant earlier. It's kind of like sacrificing a fraction speed on something which is already running insanely fast in alt-ram anyway, and giving a speed bump on the slower stuff in ST-RAM instead.

I just found your other results and mine look identical pretty much.

So this is GB6 run in ST-RAM cache stuff all on.


Pretty insane really as its almost as fast as running in alt-ram!


This test I turned off the caches in GB6 (lazy I know :lol: )



Then if we take "caches off" as the default reference file. This is what the actual boost of enabling both caches brings.



Basically about 25% increase on display which sounds about right :) VDI SCROLL actually runs 10% slower it seems.

So are you done now doing cool stuff so I can go back to sleep :D :lol: :chairsmack:

Is this the thread we are posting interest in the new rev TF536 with the working IDE?

What would be the amount of assembly required in the this revision? SMD work? SMD looks do-able .. I have not tried it or practiced it..

Thanks

James

Bikerbob wrote: 19 Apr 2022 18:13 Is this the thread we are posting interest in the new rev TF536 with the working IDE?

What would be the amount of assembly required in the this revision? SMD work? SMD looks do-able .. I have not tried it or practiced it..

There is no new revision of the board.. The rev5 have been on sale in the store for some time.. As to discussing assembly stuff, please open up a new thread... @PhilC Built mine up for me anyway.

exxos wrote: 19 Apr 2022 18:07 Pretty insane really as its almost as fast as running in alt-ram!

Yeah I am genuinely surprised how big of a difference the tiny L1 made!
And now that we have that, it would be nice with an L2 as well :lol:

agranlund wrote: 19 Apr 2022 18:53 Yeah I am genuinely surprised how big of a difference the tiny L1 made!
And now that we have that, it would be nice with an L2 as well :lol:

Indeed! but technically you already kind of did that with the "caching" of whole of ST-RAM thing in that other thread :)

Even though progress is slow, the FPGA chips @Icky and I are working on will be a proper bus speed up. So all this booster malarkey will be a thing of the past ;) I did have some random thoughts the other day towards the 16Mhz bus speed up mod a few of us did on the H4 a while back. But really need to invent a cloning machine and the 500 hour work day first...

exxos wrote: 19 Apr 2022 18:15 There is no new revision of the board.. The rev5 have been on sale in the store for some time.. As to discussing assembly stuff, please open up a new thread... @PhilC Built mine up for me anyway.

Oh.. so is it just a new firmware that allows the ide to work now???

OK, I saw that PHILC has put his building on hold.. is there a way to see what is on the board? and what I need to do still?

James

Bikerbob wrote: 19 Apr 2022 19:34 Oh.. so is it just a new firmware that allows the ide to work now???

For the rev5 yes.

Bikerbob wrote: 19 Apr 2022 19:34 is there a way to see what is on the board? and what I need to do still?

Most the info is on the website https://www.exxosforum.co.uk/atari/last/TF536/index.htm

This guy has a lot of build info https://www.exxosforum.co.uk/forum/viewt ... =94&t=5263