REV 3 - REV 5 - The beginning (ST536)

[agranlund]

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 :shrug:

We could make maprom reallocate a new FRB even if one already exists.
Or maybe just have it check if the FRB exists as a separate thing. I can't remember for sure but I think you're assumption is correct in that it only installs the FRB if it also had to install alt-ram.

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.

I think you have a very good point. When it installs the FRB itself it should be >4k but if it's already there it would be good if it double checked and avoided that (or just create and install a new one)

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 :roll:

Yeah the thing is, you can't 100% cache inhibit areas from the hardware side only.
For that you need the PMMU to be properly set up from software. Usually this'll be the task of an operating system.

This has nothing to do with the TF536, it's just how the 68030 CPU works.
The CIIN pin on the 68030 is only cache-inhibit for cpu-reads (and also only if that data is not already in the cache, for whatever reason)
The pin has no effect when the cpu is writing.
Even if you're asserting CIIN for some region, a write to that region will still put the data in the cache.
And since it's now in the cache, a subsequent cpu-reads will get it from the cache even if you assert CIIN..

Combined with DMA this can cause bad-things of course:
1) cpu writes something to a buffer (CIIN does not effect writes, so the data ends up in cache)
2) something is DMA'ed to the buffer
3) cpu reads from the buffer -- it gets the cached data from 1 (CIIN is ignored because the data is already in the cache)

The MMU is needed to avoid things like that example from happening.

[agranlund]

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

All it does is to not flag the ST-RAM mmu pages as cache-inhibited.
This is actually the default mmu setup, same as how TOS3+ and EmuTOS does.

Previous versions of maprom actively disabled L1 for st-ram ranges by tagging it as cache-inhibited, to be in sync with the TF536 which asserted CIIN on st-ram access.

So in a nutshell, it now does nothing to enable it whereas it was previously doing something to disable it.

[exxos]

@agranlund I think there are 2 problems going on.

FRB could be relocated if found. My build of TOS installs it by default, but TOS seems to just shift the bottom end of RAM to make room for the 64k block rather than allocating it. At least that's what it looks like to me.

Code: Select all

/* check wether fast ram buffer is needed */
        tst.l     (_ramtop).w
        beq.s     frbdone
        move.l    #$5F465242,(a0)+ /* '_FRB' */
        move.l    (_membot).w,d0
        move.l    d0,(a0)+
        add.l     #$00010000,d0
        move.l    d0,(_membot).w
        move.l    d0,(_end_os).w
frbdone: 

Relocating 32k as long as FRB isn't in that area should work I think.

Second problem is the FRB will get cached regardless of where it is in RAM. So it would need to look (or know) where the FRB is and cache inhibit that block as well.

I guess it would work if TOS installs FRB and maprom cache inhibits that ram, but then it might be counter productive as maprom originally relocated 32k.. Which could then contain the FRB :lol: :stars:
I can patch TOS not to install the cookie.. Otherwise its going to waste 64k of RAM I think.

I think FRB relocation and cache inhibit FRB would be the last problems to solve ... In theory ;)

Then merge maprom into TOS ;) :hide:

[agranlund]

Second problem is the FRB will get cached regardless of where it is in RAM. So it would need to look (or know) where the FRB is and cache inhibit that block as well.

Assuming the operating system is invalidating the cache after dma it shouldn't be necessary to cache-inhibit the FRB area at all.
After all, neither TOS3/4 nor EmuTOS is cache-inhibiting any st-ram.

But yeah, maybe it's necessary on TOS2. (or even other TOS in combination with the TF536 and maprom. I don't know. I should try and plug in that gotek drive I have here hiding somewhere)

[exxos]

Assuming the operating system is invalidating the cache after dma it shouldn't be necessary to cache-inhibit the FRB area at all.
After all, neither TOS3/4 nor EmuTOS is cache-inhibiting any st-ram.

I did spend a lot of time messing with cache clears all over the place but gave up in the end. Its defiantly cache related when doing DMA but can't figure out what. So inhibiting the FRB was the only idea left which I could think of which may work.

TOS does work out of the box with flushcaches enabled now. Before with caches turned on, as you know, it would go nuts. So that is fixed at least now. I agree that it shouldn't matter about FRB but I can't think of anything else. Unless its upsetting something in lower ram like system variables or something .

[agranlund]

I did spend a lot of time messing with cache clears all over the place but gave up in the end. Its defiantly cache related when doing DMA but can't figure out what. So inhibiting the FRB was the only idea left which I could think of which may work.

TOS does work out of the box with flushcaches enabled now. Before with caches turned on, as you know, it would go nuts. So that is fixed at least now. I agree that it shouldn't matter about FRB but I can't think of anything else. Unless its upsetting something in lower ram like system variables or something .

I think you're right.
Does floppy stuff work when ram relocation is completely disabled in maprom?

If so, it probably shouldn't relocate any ram at all. Or, perhaps just keep it to the lowest 2k or so.
As a "product", I think it's better if it's compatible for all even if that means slightly slower than it could have been for some.
Relocating the first 2k should be safe. That would be just the interrupts and stuff like that and none of TOS's work ram.

Anything above that is mainly for making tos/desktop stuff slightly faster, but as soon as you install NVDI those optimisations immediately start to feel tiny and irrelevant anyway.

[exxos]

@agranlund ram relocation was causing issues when I think it was 32k with original TOS206. It's why we went for 4k. But since doing my patched TOS, 32k seems to work again. I tried with the map0k as well and made no odds. So relocation doesn't seem to causes issues with my TOS version. The floppy only goes nuts when the cache maprom is used.

See this post https://www.exxosforum.co.uk/forum/viewt ... 630#p84172

[agranlund]

@agranlund ram relocation was causing issues when I think it was 32k. Its why we went for 4k. But since doing my patched TOS, 32k seems to work again. I tried with the map0k as well and made no odds. So relocation doesn't seem to causes issues. The floppy only goes nuts when the cache maprom is used.

See this post https://www.exxosforum.co.uk/forum/viewt ... 630#p84172

Ah! Thanks for clearing that up, I thought the issue was related to the ram-remapping :)
I'll see if I can get that Gotek hooked up in the weekend to check here too.

I take it you are building TOS206 but with P68030 defined?
Looks like some stuff is hiding behind (TOSVERSION >= 0x300) checks too. I have no idea if it's relevant but a quick find-in-files revealed that this type of check was at least used in dma.inc and floppy.inc, and around some cache related things.

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 :shrug:
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).

Maprom could be made to cache-inhibit the FRB pages for sure. It could also cache-inhibit some low range of st-ram if that helps too?
Is this a problem in TOS206 only or does it happen in PAK306 and EmuTOS as well?

Also wondering if TOS itself could be forced to use fast ram for its workspace..

I think it could, but not trivially so and you're probably in for quite some work :)
You wouldn't want to put system variables in another physical location but you could probably change where some of the private variables live.
The adresses are static and generated at compile time so you'd need to put them at some fixed address in altram and make sure that memory is not trampled by anything.
It's probably the internal vdi stuff that you'd want to move the most, but beware that _dskbuf actually overlays some of the vdi variables.
"common/vars.S" is the one that fills up the bss section (which starts at 0)

[exxos]

I take it you are building TOS206 but with P68030 defined?

Yep.

Looks like some stuff is hiding behind (TOSVERSION >= 0x300) checks too. I have no idea if it's relevant but a quick find-in-files revealed that this type of check was at least used in dma.inc and floppy.inc, and around some cache related things.

That was what I was diagnosing the past couple of weeks. It was a nightmare to work though it all. The floppy will now work with "cache" enabled on the desktop. Whereas with original 206, it did not. This is because I enable the "flushcaches" stuff etc. It was a mess of TP_50 for some PAK stuff, then 0x300 patches.. then removing some PAK stuff as it broke stuff.

Maprom could be made to cache-inhibit the FRB pages for sure. It could also cache-inhibit some low range of st-ram if that helps too?
Is this a problem in TOS206 only or does it happen in PAK306 and EmuTOS as well?

I gave up with PAKTOS. I don't know why, but it was more broken than vanilla 206. I think it assumed it needed a graphics card or something.

EMUTOS also suffers the same problems as my build of TOS. I posted a lot about this over the past couple weeks also.

The floppy problems only now appear when MAPROM_C is used, regardless of OS.

[agranlund]

That was what I was diagnosing the past couple of weeks. It was a nightmare to work though it all.

I bet!

EMUTOS also suffers the same problems as my build of TOS. I posted a lot about this over the past couple weeks also.
The floppy problems only now appear when MAPROM_C is used, regardless of OS.

Ah, interesting. I was wondering if I should make maprom do the cache-inhibit stuff only for 206 but I guess it should do it regardless of OS then :)
Does the problem appear when maprom is not used at all?


So I'm trying to read some of the older posts in the thread and found this:

@agranlund BLITFIX seems to hard disable the cache in the desktop menu, can't turn it on anymore ? Assume by design ?

Blitfix shouldn't touch any cache related things at all, and the option works in standard 206 with maprom + blitfix.
Maybe the custom built TOS is getting confused for some reason?

The only cache related thing would be that the blitter and cache menu option share the exact same menu spot.
Ie; there was never a machine with a 68030 + Blitter in the context of TOS2/3 so they used the same actual option but have it control the setting that was relevant for the machine.
In normal TOS206 it ends up controlling the cache just like it says but maybe the custom TOS gets confused here and doesn't do the right thing when blitfix "enables" the use of the blitter. It's just a wild guess, I really have no idea.

If you are using xcontrol or cops you get options for both blitter and cache in the "general" cpx module.

I had another thought about using patched ROM images., maybe a tweak to maprom. In that if it finds a file eg: TOS.BIN, it would load that into fastram, if the file isn't found, then it copies the ROM to fast ram like normal.

Yes, I do love this idea!
Last time I thought about exactly that I identified two potential problems:

• - MMU. It'll have to reset into the loaded OS, and it's probable that it will initialise the MMU on startup thus trashing the existing rom->ram mapping and everything goes south.
  But I guess that could be very easily verified by looking at TOS sources to see if it performs the PMMU setup always or only on cold boots.

• Blitter. TOS206 blits from rom, so it needs the same content in rom as what's in ram..
  Not a huge deal, blitfix could be made to detect this.