REV 3 - REV 5 - The beginning (ST536)

[exxos]

@agranlund I am thinking the DMA 's transfers are getting screwed up because the CPU isn't writing data to the FRB RAM ? Every time I turn the caches off it works fine with floppy ( for this is only when caches in firmware and MAPROM are being used).

I assume the FRB is appointed to a block of memory where the data is dumped from the DMA transfer. So could MAPROM cache inhibit just that block of RAM ?

Oddly there is some catheflush stuff around the FRB cookie stuff, but obviously something is still amiss somewhere.I did try plastering cacheflush stuff all around the floppy routines to no avail either

EDIT:

Actually now I am confused.. As when TOS boots up, the caches are enabled and floppy works fine. Its when MAPROM is run (the C version) when it goes nuts. But wouldn't that just be caching the whole lot like TOS would anyway ?

[exxos]

Thought I would re-test some stuff now TOS is "fixed"

MAPROM 4K (NO CACHE)

IMG_0528.JPG (400.09 KiB) Viewed 3137 times

MAPROM 4K (WITH CACHE)

IMG_0529.JPG (274.75 KiB) Viewed 3137 times

MAPROM19 32K (NO CACHE)

IMG_0530.JPG (386.79 KiB) Viewed 3137 times

As there is "no cache" in MAPROM19 in the above test, floppy drive is working fine with my updated build of TOS206 @agranlund So 32K relocate might well possibly be back on the table now... Also wondering if TOS itself could be forced to use fast ram for its workspace..

I think the only issue is when using the "ST-ram cache" MAPROM options. Again I am assuming at this point, its because its catching the FRB 64K block.. So if that theory is true, if MAPROM can cache inhibit the 64K block as stated by the FRB address.. it *might* all work fine then

The clause for that, is that is my build of TOS206 sets up alt-ram and the FRB cookie internally.. So if the cookie already exists, then the value needs to be read only (and not setup by MAPROM).

[exxos]

One thing I forgot to mention I think, was I tried disabling CIIN on BGACK. Didn't think it would do anything, but oddly it crashed getting to desktop

I have also wondered about turning off the caches in the desktop menu when accessing floppy as that seems to work, though as yet, I haven't found the routines for desktop menu switches yet.

Even so, still confused over what TOS is caching and what maprom is caching .I wonder if TOS is just disabling caches anyway, but maprom is forcing them on all the time circumventing the cache clears or something

I still don't get why flushing caches isn't enough when maprom is running. Unless its incepting those calls and ignoring them or something.

Does anyone get exactly what maprom is doing when it enables L1 for STRAM ranges ?

[exxos]

TOS has a 1024 byte buffer used for floppy things and this one must remain in st-ram (it's a different thing from the _FRB, which also must be in st-ram)
This buffer lives somewhere in the first 32kb region by default, so maprom attempts to find out where it is and ignores that page...

Hmmm 64k http://toshyp.atari.org/en/003007.html#Cookie_2C_20_FRB for FRB.

But dskbufp points to a 1k buffer. So I guess maprom isn't avoiding the actual FRB 64k block for caching then @agranlund ? If that's being cached then could may well explain why the floppy is going nuts.

[exxos]

I thought of a possible workaround for now, at least prove the FRB issue or not. If I reserve 1MB of ram, then reserve ram for the FRB.. Then nuke the 1MB chunk.Then change the firmware to only cache the first 1MB of ram. In theory 1MB games would still get the cached RAM, but stuff higher up like FRB won't get cached as it should be in the 2MB RAM area.. Unless we can reserve ram from the top of ram instead ?

I also wonder if it would be more benifical to not cache fastram. Before people moan, fast ram is already running way faster than STRAM. So it may give a better speed boost overall if we can have more cache hits on STRAM instead.. I guess I could try the idea with FrontBench and see what happens...

[Badwolf]

I thought of a possible workaround for now, at least prove the FRB issue or not. If I reserve 1MB of ram, then reserve ram for the FRB.. Then nuke the 1MB chunk.Then change the firmware to only cache the first 1MB of ram. In theory 1MB games would still get the cached RAM, but stuff higher up like FRB won't get cached as it should be in the 2MB RAM area.. Unless we can reserve ram from the top of ram instead ?

I also wonder if it would be more benifical to not cache fastram. Before people moan, fast ram is already running way faster than STRAM. So it may give a better speed boost overall if we can have more cache hits on STRAM instead.. I guess I could try the idea with FrontBench and see what happens...

I like your FRB idea, but don't know enough about ST-style DMA to be certain how it all works.

A big part of the performance in TT-RAM is the burst mode cachefilling. I think you may be right in the long run, but you have to give people their top-level benchmark stats. That's the selling point!

BW

[exxos]

I like your FRB idea, but don't know enough about ST-style DMA to be certain how it all works.

A big part of the performance in TT-RAM is the burst mode cachefilling. I think you may be right in the long run, but you have to give people their top-level benchmark stats. That's the selling point!

BW

FRB cookie is just a pointer in RAM. AFAIK it can be anywhere in RAM.

It could end up like a 20% drop in TTram speeds for a 5% speedup in STram kinda thing. . With software being a moving target, its not so simple anyway.

I guess really these should be options in a desktop menu in GEM

[exxos]

847% is "default" TTram speed in GB6.

Next disable bursting and RAM ended up at 807%. So 40% drop in speed from 847%. Not huge I guess.. About 5% speed drop in real money.

With D&I caches off, Still 807%

Possible I broke the cache logic, but if 807% is "worse case" then I don't really care at this point anyway.

EDIT:

Looking at previous benchmarks https://www.exxosforum.co.uk/forum/viewt ... 975#p80056

TTram was 858% without caches. A increase of 11%. So caches off in that test are actually better anyway. Hard to work out if bursting is even doing anything at all.

[exxos]

MAP4KC running. My patched firmware I had to use the physical CDIS jumper to load MAPROM and BLITFIX otherwise it would lockup. In fact it would lockup going to desktop on a clean boot .. But anyway..

STram and TTram all cached.

IMG_0533.JPG (373.06 KiB) Viewed 2962 times

STram cached only.

IMG_0535.JPG (353.55 KiB) Viewed 2951 times

More impact that I thought. But with all this running in alt-ram anyway..

FrontBench ST&TTram cached = 2718%
FrontBench STram cached only= 2715%

So... Meh.

EDIT:

FB in STram only = 1015% .

[exxos]

I had a thought to compile TOS and disable the FRB cookie thinking MAPROM would install it higher up in RAM, but I don't think it installed the FRB cookie, assume as it found TOS had already allocated alt-ram

I did wonder about trying to cache inhibit the FRB area in the TF536 firmware, but problem is, it may not always be in the same place, and I am still not convinced cache inhibit works in firmware

I guess the "proper" way would be to figure out how TOS is allocating RAM internally and get it to allocate its workspace in TTram.. assuming that would do the same thing as relocating 4k with maprom does in lower ram

EDIT:

Code: Select all

*  Total buffer requirements are cel_siz + cel2_siz + out_add

#define buf_siz	cell_siz+cell_siz+out_add	/* total byte requirement */


*  for other fonts, above formulae examples should be used
*  to determine  cell_siz  &  buf_siz to allocate a scratch buffer
*

Maybe what the "scratch buffer" does