ST536 STE EDITION

[dml]

BUT IIRC everything in the 536 code is cache inhibited other than TTram access amway..

Is that to play nice with SCSI and floppy DMA access?

Later TOS's (in fact, also the HD disk drivers themselves - HDDriver etc.) solve that by invalidating the cache just before or after a transfer from device-DMA->STRam so there should be no need to disable the instruction or data cache, or inhibit them in HW.

Transfers in the other direction (STRam->DMA->device) don't even matter on the 030 because the data cache is write-through always. It never gets out of sync with RAM on writes.

It's a different situation with 040/060 but 030 is write-through, always in sync with RAM for writes.

[exxos]

Is that to play nice with SCSI and floppy DMA access?

Presumably yes.. Any DMA device could access any STram.. So keeping away from it would make sense as the CPU wouldn't know about it.

Later TOS's (in fact, also the HD disk drivers themselves - HDDriver etc.) solve that by invalidating the cache just before or after a transfer from device-DMA->STRam so there should be no need to disable the instruction or data cache, or inhibit them in HW.

My 206 build has the cache stuff enabled (from TOS306) so it fixes a lot of DMA issues I saw with original 206.

Problem lies in TOS is disabling the caches itself when the blitter is active. So TTram takes like a 120% speed hit, so GB6 sees a drop in scores when running in TTram.

My thought is BLTFIX could set the caches based on blitter access or not.. but really, BLTFIX should actually disable the blitter when not in use to stop TOS from screwing with it all!

EDIT:

Annoyingly..

Code: Select all

assign CIIN = 1'b0; // force cache off

Causes it to lockup at some random point during bootup :roll:

EDIT2:
It works when the CPU is running 8Mhz constant though... weird..

[agranlund]

My thought is BLTFIX could set the caches based on blitter access or not.. but really, BLTFIX should actually disable the blitter when not in use to stop TOS from screwing with it all!

My initial thought is that blitfix should not fiddle with the cache at all, it doesn't feel like something like that belongs there and it would be just confusing and possibly error prone if it involved itself with modifying the cache settings.
It would also make calls to the affected gfx routines slower if it has to do cache logic as well before jumping through to the TOS function.
Right now it's fairly fast in determining which of the two versions it is supposed to call, most of them only a few lines to check the topmost byte of a src or dst address.

I don't have a machine up and running that has a use for blitfix so it's very unlikely I will do anything with that code, but the source is there on github if anyone else wants to change/improve :)

[agranlund]

Code: Select all

assign CIIN = 1'b0; // force cache off

Causes it to lockup at some random point during bootup :roll:

I would be careful with CIIN unless you _really_ know what you are doing, and also considers how it ties together with MMU.

Or rather, the potential need to use the MMU too since CIIN is not really "force cache off", but rather:
"force cache off with caveats, must read and understand the 68030 manual and potentially, depending on your usecase, also use MMU to _actually_ safely force cache off" :lol:

From an Amiga forum discussing CIIN:

The purpose of the CIIN input is to prevent the data read from the memory to be put into the cache. It doesn't prevent the data from the cache to be accessed by the CPU.
...
If data is in the cache there is no way to prevent to access it unless the cache is disabled.
The problem is caused by writing a long-word to long-word aligned address with the WA (Write Allocate) bit set. In this case an entry in the cache is always allocated regardless of the state of the CIIN input and all successive reads from this location will access the data in the cache (unless it's flushed) with no external bus read cycle generated.
Since it's documented it's a feature and not a bug.

Cache inhibiting pages in the MMU table is a good way to be safe since there you can control the CPU's usage of the cache.

[exxos]

My initial thought is that blitfix should not fiddle with the cache at all, it doesn't feel like something like that belongs there and it would be just confusing and possibly error prone if it involved itself with modifying the cache settings.
It would also make calls to the affected gfx routines slower if it has to do cache logic as well before jumping through to the TOS function.
Right now it's fairly fast in determining which of the two versions it is supposed to call, most of them only a few lines to check the topmost byte of a src or dst address.

My new thought was to "tell" TOS to enable / disable the blitter as its kinda doing that itself anyway..and it sets the cache itself.. but that by itself could have a speed impact.. As it would be another TOS call in the mix.

I don't have a machine up and running that has a use for blitfix so it's very unlikely I will do anything with that code, but the source is there on github if anyone else wants to change/improve :)

I would if I could makes heads or tails of it all :lol:

I would be careful with CIIN unless you _really_ know what you are doing, and also considers how it ties together with MMU.

Or rather, the potential need to use the MMU too since CIIN is not really "force cache off", but rather:
"force cache off with caveats, must read and understand the 68030 manual and potentially, depending on your usecase, also use MMU to _actually_ safely force cache off" :lol:

In other words don't screw with it :)

[dml]

Cache inhibiting pages in the MMU table is a good way to be safe since there you can control the CPU's usage of the cache.

I have written some code to set up page tables for this kind of thing on both 040 and 030 processors. It was part of the optional Afterburner040 boot driver I provided to map FastRAM into ROM address space and inhibit caches in cookie'd areas for disk drivers. I did something similar on a smaller scale for 030 to test framebuffer optimizations with the Doom project.

It seems like it would be better to solve problems like this in software via AUTO folder versus trying to complicate the hardware further - as you point out, the MMU is there for that purpose.

[exxos]

I'm looking if I can at least get TOS to just use both blitter and cache but the code looks rather confusing and not even sure if this is just done at startup or "on the fly" even :shrug:

Code: Select all

/*
 * Turn on the cache or bitblt
 */
/* 206de: 00e30446 */
/* 306de: 00e33eac */
VOID ch_cache(P(BOOLEAN) set)
PP(BOOLEAN set;)
{
	int16_t value;
	int32_t data;
	int16_t temp;

	UNUSED(value);
#ifdef BITBLT
	menu_addr[BITBLT].ob_state &= ~DISABLED;
#endif
#if 0									/* take out for sparrow */
	menu_ienable(menu_addr, BITBLT, TRUE);
#endif

#if TP_32 | TP_50 /* CACHE_0X0 | PAK */
	if (m_cpu >= 20)
#else
	if (m_cpu == 30)
#endif
	{
		if (set)
			data = s_cache ? CACHE_ON : CACHE_OFF;
		else
			data = 0xFFFFFFFFL;

#if TP_32 | TP_50 /* CACHE_0X0 | PAK */
		if (m_cpu == 20 && (inq_cache(data) & 0x1) != 0)
			s_cache = TRUE;
		else
#endif
		if (inq_cache(data) == XCA_ON)
			s_cache = TRUE;
		else
			s_cache = FALSE;

		value = s_cache;
	} else
	{									/* turn the blt on  */
		/* blt is there     */
	ch_1:
		if ((temp = Blitmode(-1)) & 0x2)
		{
			if (set)
			{
				Blitmode(cbit_save ? 1 : 0);
				set = FALSE;
				goto ch_1;				/* check status again   */
			} else
			{
				cbit_save = (temp & 0x1) ? TRUE : FALSE;
			}
			value = cbit_save;
		} else
		{
			value = FALSE;
#ifdef BITBLT									/* take out for sparrow */
			menu_addr[BITBLT].ob_state |= DISABLED;
#endif
#if 0
			menu_ienable(menu_addr, BITBLT, FALSE);
#endif
		}
	}

#ifdef BITBLT									/* take out for sparrow */
#if 0
	menu_icheck( menu_addr, BITBLT, value ? TRUE : FALSE );
#endif
	if (value)
		menu_addr[BITBLT].ob_state |= CHECKED;
	else
		menu_addr[BITBLT].ob_state &= ~CHECKED;
#endif
}

Looks like there may be a patch which may help, but hard to tell. The cache is already enabled in the menu anyway.

Code: Select all

/*
 * TP_32: CACHE_0X0: Activate caches for all cpus >= 68020
 *
 * This patch is still experimental. Note also that with this patch active,
 * you won't be able to activate/deactivate the blitter from the desktop
 * when you have a cpu >= 68020.
 */
#ifndef TP_32
#define TP_32 0
#endif

Its pretty weird because I cannot even find anything with really toggles the blitter or cache, other than the menu itself and then doesn't seem to be any code linked about what I can find so far..

All the blitter code seems to have stuff patched for caches anyway. So TOS shouldn't have any real need to even disable the cache when the blitter is on.

[Cyprian]

@exxos
Wouldn't it be better to directly modify Atari TOS source code?
https://github.com/th-otto/tos1x
https://github.com/th-otto/tos3x

[exxos]

Wouldn't it be better to directly modify Atari TOS source code?

That's exactly what I am trying to do..

[Cyprian]

Wouldn't it be better to directly modify Atari TOS source code?

That's exactly what I am trying to do..

ok, sorry I missed that part