REV 3 - REV 5 - The beginning (ST536)

[ijor]

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.

Is there any reason why you can't just cache the whole ram? Working more like shadow ram than cache, so that you actually never need to read from ST-RAM.

[exxos]

Is there any reason why you can't just cache the whole ram? Working more like shadow ram than cache, so that you actually never need to read from ST-RAM.

He already did just that. https://www.exxosforum.co.uk/forum/viewt ... =76&t=3682

[ijor]

Is there any reason why you can't just cache the whole ram? Working more like shadow ram than cache, so that you actually never need to read from ST-RAM.

He already did just that. https://www.exxosforum.co.uk/forum/viewt ... =76&t=3682

I don't understand. If it is already implemented then why there is cache miss and cache refill. If you shadow the whole ram you never need to refill the cache. Or these are two different pieces of hardware?

[exxos]

Or these are two different pieces of hardware?

Anders is working with the original TF536r2. It was just a proof of concept but didn't take that direction any further. He mentions just that in the post about moving to ST-RAM caches instead. https://www.exxosforum.co.uk/forum/viewt ... =10#p83271 I ported those changes to my ST536 project in this thread. I have never seen the software/firmware for the "whole RAM cache" and no clue what Anders did to achieve it. Using 030 caches gives a nice bump in speed for doing "not a lot". So worth adding, like I did today.

[exxos]

I've done a tweak to the IDE code. Sometimes the ST would intermittently just get stuck in a resetting loop after the Atari logo. As I don't have a LA to figure it out, I've made the assumption I was latching the MFP register to fast. Maybe the latched regs were getting zero for the mono signal causing the reboot. The extra delay seems to have solved it anyway. I'll do more testing before I release the new Jed. That one will have the STram cache enabled and must use maprom19. I'll include it in the zip download anyway.

I've had it running all day. Been running FrontBench and GB6 and copying files from floppy to IDE. Had it testing STram and Alt-ram for a couple hours also. Nothing has tripped up.

TOS206 needs then caches on desktop turning off if your using floppy or ACSI drives. I will see if I can get flashyclock working next, I want to try to compile TOS206 again with the cache fixes turned on. It didn't seem to make any odds when I turned on a lot of the pak fixes. Other than medium res got messed up simehow. So not sure what's going on there. But I think we really need a fixed 206 now these days. Or just use EMUTOS.

[agranlund]

The extra delay seems to have solved it anyway.

I have some extra delay in there on the old tf536r2 as well :)

[sporniket]

I have never seen the software/firmware for the "whole RAM cache" and no clue what Anders did to achieve it.

Hum, is the "whole RAM cache" expression a shortcut to say something like :

• software side, as early as possible, copy the whole ST-RAM to the start of Alt-Ram (optimisation : only copy the strategic lower part -vectors and system variables- and highest part -memory management stuff-, as long as destination address = address in st-ram + start of alt-ram), then instruct the 68030 MMU to map the whole ST-RAM to the Alt-RAM (it's better to only have 512k or 1Mb of ST-RAM)
• cpld side, capture any write that occurs at the start of the Alt-Ram to report the writing in ST-RAM too

edit : if the caching is started through a program, then the backup of the whole ST-RAM in Alt-Ram is needed. If the cpld can be instructed to NOT reproduce writes to Alt-Ram into St-ram during this process, it would be better.

[exxos]

@sporniket yeah I'd assume a total ram read would have to be done to altram. Then all writes happen to both STram and altram.Reads go direct to alt-ram.

@agranlund would be better to explain what he did.. A lot of info is in his other thread as well.https://www.exxosforum.co.uk/forum/viewt ... 682#p54278

[sporniket]

ha yes, I was catching up on this thread.

[exxos]

GB6 tests with blitter installed.

A bit of a mixed bag really. The blitting test sees a 224% speed. But this is probably only useful for games which do a lot of blitting. Which I assume is not really that many. Pretty much overall, things are a bit of a hindrance.

IMG_0486.JPG

When the blitter is not allowed to access ROM, all the text on the desktop is "black boxes". Normally I see this in GB6 as well in some tests. However the only test which seems to be malfunctioning the first test where the floppy icons are missing in this test... I'm not really sure where this problem stemming from as it is using @agranlund's BLITFIX software.

IMG_0489.JPG

I also had to do a patch to the TF536 buffers as I needed to flip the RW direction so blitter could access ROM.

Another slight problem is the PLD is out of space so in this test I had to remove the IDE autoboot code.. But I'm not concerned exactly about this because the missing logic for the blitter could be done with a couple of external logic gates. But overall I am not really sure it is worth the hassle of supporting the blitter.

EDIT:
A random thought that maybe the blitter still trying to access the on-board ROM. So I let the blitter access that and now the floppy icons are back..

So I think for some reason the blitter cannot access the full ROM range when its in alt-ram.. @agranlund ?