REV 3 - REV 5 - The beginning (ST536)

All about the ST536 030 ST booster.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Thu May 05, 2022 10:36 pm 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.
exxos wrote: Sun May 01, 2022 12:18 am 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)

exxos wrote: Thu May 05, 2022 10:36 pm 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.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Sat Apr 30, 2022 4:59 pm 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.
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: REV 3 - The beginning

Post by 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:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Fri May 06, 2022 12:19 am 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)
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: REV 3 - The beginning

Post by exxos »

agranlund wrote: Fri May 06, 2022 12:42 am 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 .
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Fri May 06, 2022 12:55 am 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.
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: REV 3 - The beginning

Post by 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
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Fri May 06, 2022 9:51 am @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.
exxos wrote: Fri May 06, 2022 9:51 am 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?
exxos wrote: Fri May 06, 2022 9:51 am 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)
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: REV 3 - The beginning

Post by exxos »

agranlund wrote: Fri May 06, 2022 1:01 pm I take it you are building TOS206 but with P68030 defined?
Yep.
agranlund wrote: Fri May 06, 2022 1:01 pm 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.

agranlund wrote: Fri May 06, 2022 1:01 pm 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: REV 3 - The beginning

Post by agranlund »

exxos wrote: Fri May 06, 2022 1:37 pm That was what I was diagnosing the past couple of weeks. It was a nightmare to work though it all.
I bet!
exxos wrote: Fri May 06, 2022 1:37 pm 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:
exxos wrote: Fri May 06, 2022 1:37 pm @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.
exxos wrote: Fri May 06, 2022 1:37 pm 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.
Post Reply

Return to “ST536 030 ST ACCELERATOR”