GVP Impact Series II HD8+ much slower with TerribleFire 536

[StompinSteve]

Originally Posted by Thomas Richter

Thus, please throw out "CPU FastROM". That is deprecated, and provides only disadvantages over the more compatible "MuFastROM".
I neither recommend any of these CMQ-"improvements".

Ok i'm back on, what was basically my pre "throw mmulibs overboard" config. I'll gladly sacrifice an ounce of performance for a pound of stability and data-integrity.

I put the 68030 library from the latest MuLibs distro back in Libs: as well as the mmu.library from the same release.
I now have this in my start-up sequence:

Setpatch
MuFastRom On Protect Head
MuFastZero On MoveSSP=FastSSP

I need the "head" parameter otherwise the A500 crashes during boot. Probably due to the 8MB "GVP HD+ RAM" and the 64MB RAM on the TF. It's my only Amiga where I need that parameter.

[SpeedGeek]

Originally Posted by thebajaguy

At the end of the day, I believe the CIIN issue should be protected against with the MMU - when possible. There are system configurations that are unlikely to run into it - yes - but you will never know a dirty cache read of hardware happened until data is corrupted, or the system suddenly crashes. The MMU could have prevented it. In the 68EC030's case, the TTX register setting preventing data caching over the <16MB address space does the same (with potential performance impact likely).

If the OS structures end up in ChipRAM because the AddMem for the accelerator 32-bit FastRAM is done later than AutoConfig time, I prefer an MMU remap of the low memory area solution (MuFastZero functionality). The benefits to OS response and I/O performance are noticeable, and it's more compatible than using MoveSSP and VBR remap solutions. It's less important to remap this memory space with the MMU if some 32-bit FastRAM is present at OS setup time, and the OS makes use of it.

I prefer using an on-card Kickstart remap over the MMU - when it is available. This saves potential (minor) MMU lookup table hits. The MMU may be the only option in some cases, though.

I have come to prefer that ALL 16-bit RAM, in a system where there is a data cache on a 32-bit CPU accelerator (and it loads 4x 32-bit longwords, burst hardware protocol, or just 4x normal longword sequential accesses) be set to nocache. 4x longword load (or save) is a high penalty to pay for any high % of cache misses, and/or a single or double longword (at most) retrieval or push. If the RAM priority is last-use (typical), and is used mainly for a DMA-CPU copy buffer, the cache has no value. It's effectively shared RAM for I/O data, and will never cache-hit.

My problem with OS 3.1's CPU FastROM solution is that it does not solve CIIN with the MMU when it does FastROM remap. It's a no-frills version of SetCPU that does Kickstart remap with the 68030 CPU, and toggles the CPU cache and burst registers on and off. It won't address remapping system structures that end up in ChipRAM (the late AddMem of FastRAM issue mentioned above). It has no cache-setting contingencies for other shared memory expansion options. In a perfect system, it can be the fastest Kickstart remap solution, but the perfect system, with software/drivers that avoid the corner-case CIIN flaw, are hard to define.

SetCPU offers a little more versatility, solving CIIN and fixing the Bridgecard's shared RAM issue (with Janus 2.1, but not earlier versions) if caching and FastROM is enabled after the drivers load. It doesn't provide a MMU-based solution for the low-memory OS structure in ChipRAM use case mentioned above. It doesn't handle EC processor cases. RTG cards (w/shared RAM) may have issues with it's cache-mapping choices on them - it was designed before they became popular. It's ideal use case is a 68030 accelerator with some AutoConfig FastRAM on it - like the C= A2630 or similar.

MuLibs then becomes the Swiss Army knife solution, but will be slightly less efficient in some configurations because of the additional functionality. It's the only safe solution for the 68EC030. It can be paired with a few other OEM or 3rd party tools/solutions to improve on some of it's inefficiencies, but care and understanding are needed so as to not duplicate a function or cause a conflict.

All of this is focused on the 68030, and it's use in A500/A2000 24-bit motherboard use cases. The A3000/A4000 with their native 32-bit FastRAM and 32-bit ROM, and 32-bit CPU slot, warrant a different approach than the slower 16-bit data bus on the classic 68K systems. The 68040/68060 MMU, varied memory and bus access designs, and the behavioral differences from the 68030, are also different use cases than for the above opinion/solutions. The need for the CPU library to address their behavior has to be different than the 68030, and tailored for the different busses in each.

If you annoy someone enough times you might find the solution you prefer (even if it's not the best solution). Also, you should have considered using the CPU NODATACACHE option on an as needed basis rather than fixing seldom occuring hardware bugs using the shotgun approach.

In any case here is my preferred (but annoyed) solution:

https://eab.abime.net/showthread.php...16#post1593616

[SpeedGeek]

Originally Posted by StompinSteve

Ok i'm back on, what was basically my pre "throw mmulibs overboard" config. I'll gladly sacrifice an ounce of performance for a pound of stability and data-integrity.

I put the 68030 library from the latest MuLibs distro back in Libs: as well as the mmu.library from the same release.
I now have this in my start-up sequence:

Setpatch
MuFastRom On Protect Head
MuFastZero On MoveSSP=FastSSP

I need the "head" parameter otherwise the A500 crashes during boot. Probably due to the 8MB "GVP HD+ RAM" and the 64MB RAM on the TF. It's my only Amiga where I need that parameter.

Oh no! You were already on the right track and now you went backwards! Instead of relying on the incompetent advice of others please make your own determination on what makes your system stable and provides the optimal performance you want to achieve. Thank you!

[Thomas Richter]

Originally Posted by StompinSteve

I need the "head" parameter otherwise the A500 crashes during boot. Probably due to the 8MB "GVP HD+ RAM" and the 64MB RAM on the TF. It's my only Amiga where I need that parameter.

MoveSSP is slightly less compatible, and with MuFastZero On, it does not add anything. If "HEAD" is needed, an output of your memory list would be helpful to have a further diagnosis of the cause. "ShowConfig" will do that.

[Thomas Richter]

Originally Posted by SpeedGeek

Oh no! You were already on the right track and now you went backwards! Instead of relying on the incompetent advice of others please make your own determination on what makes your system stable and provides the optimal performance you want to achieve. Thank you!

Stop irritating people. As you are still not aware what the issue with Move16 is, and what a "context switch" for the 68060 branch cache is, I believe you still need to do some research of what really happens here.



You also need to research better what "CPU FastROM" actually does, and why it is in no sense different to MuFastROM (except that the 3.1 CPU command does not protect the ROM mirror, so it is even inferior).

[SpeedGeek]

Originally Posted by Thomas Richter

Stop irritating people. As you are still not aware what the issue with Move16 is, and what a "context switch" for the 68060 branch cache is, I believe you still need to do some research of what really happens here.

You also need to research better what "CPU FastROM" actually does, and why it is in no sense different to MuFastROM (except that the 3.1 CPU command does not protect the ROM mirror, so it is even inferior).

The 68060 and Move16 discussion is off topic on this thread. There is already numerous 68060 threads and a Move16 thread posted here:

https://eab.abime.net/showthread.php?t=102820

My FastRom2MB tool already provides MMU write protection (for what it's worth). So now it's time for you to stop irritating people.

[StompinSteve]

Originally Posted by SpeedGeek

Oh no! You were already on the right track and now you went backwards! Instead of relying on the incompetent advice of others please make your own determination on what makes your system stable and provides the optimal performance you want to achieve. Thank you!

My System is fast and stable with both approaches.
But I do get the best disk performance with just Setpatch and "cpu fastrom". And as it has no impact on performance and become it is best-practice, I installed the 68030.library from the TF536 floppy (which is the same as the one in the latest MuLibs distro by the way).
But I have no mmu.library in Libs:
Using SysSpeed 2.6, the "Create/Open/DirScan/Delete/SeekRead" test results are higher, and in case of "Seek/Read" significantly higher, than with the MuLibs config I described before.

So sure, from that perspective I, as someone lacking knowledge on this level, says "who needs MuLibs on my 030 when it slows my machine down".
And then someone comes along and throws an elephant in the room called "the CIIN flaw". My brain goes like "uh oh, don't want it munching my data, gotta get them MuLib config back".

Do you know how I feel right now? I feel like that famous Boing Ball, bouncing between several walls. Those walls are you guys. People who make a competent impression and whose arguments make sense to me to a degree, despite my lack of knowledge on this level (As an IT enterprise architect, I design datacenters and super complex stuff but I'm not a software guy).
So tell me, who should I believe. What IS the correct configuration before I go

[Thomas Richter]

As said above, CPU FastROM and MuFastROM work exactly alike, just by different interfaces. Both use the MMU to remap ROM to RAM. There is a bit of fiddling you can try with the MMU page size, and there is more on this in the MMU.guide, see the "Layout" command, and the examples listed there. The question rather is where the remapped ROM ends. If you need a "HEAD" argument for MuFastROM, then it is likely that something else in the system is "strange", but to understand what exactly that is a "ShowConfig" output would be helpful. Anyhow, please understand that the "default" setup that comes with the MMU installation is the "Ford Escord", it will safely bring you from A to B, such that everything works, though not necessarily ideally for all use cases. Just to give you ideas: Larger MMU page sizes will improve performance, but will reduce the ability of debug tools to identify wrong accesses, or - for some Os versions - will even slow down the system noticably if such tools are in use. Thus, there are always some compromises to be made. You can tune your system by means of the mmu.library in many direction, such that the entire framework remains working, but it requires some reading of the MMU.guide. Third-party tools cannot do anything else, it is the same hardware anyhow. Just in a less-integrated way, and without offering an overall architecture of tools that work hand-in-hand. The MuTools try to offer you a very stable and reasonably performing default setting, but still allow you to tune the system if you want to. But as always, "with great power comes great responsibility", and that is reason why not everything is enabled by default.

[StompinSteve]

Mein ShowConfig Herr Richter

[Thomas Richter]

As assumed, there is something wrong with the 64MB block - it is 8 bytes too long and thus the last 8 bytes are actually not RAM. How does it enter the system? If this is an AddMemory, then I suggest to rather move the AddMem to the MMU-Configuration, and to size it correctly. The start should be $40000000, and the size should be $4000000 (count the zeros). If you really want to AddMem outside of the MMU-Configuration, make sure that MuFastZero and MuFastROM should go *behind* the AddMem.

PS: If you really want to set me up by being formal, it should be "Dr. Richter", then.

[SpeedGeek]

Originally Posted by StompinSteve

My System is fast and stable with both approaches.
But I do get the best disk performance with just Setpatch and "cpu fastrom". And as it has no impact on performance and become it is best-practice, I installed the 68030.library from the TF536 floppy (which is the same as the one in the latest MuLibs distro by the way).
But I have no mmu.library in Libs:
Using SysSpeed 2.6, the "Create/Open/DirScan/Delete/SeekRead" test results are higher, and in case of "Seek/Read" significantly higher, than with the MuLibs config I described before.

So sure, from that perspective I, as someone lacking knowledge on this level, says "who needs MuLibs on my 030 when it slows my machine down".
And then someone comes along and throws an elephant in the room called "the CIIN flaw". My brain goes like "uh oh, don't want it munching my data, gotta get them MuLib config back".

Do you know how I feel right now? I feel like that famous Boing Ball, bouncing between several walls. Those walls are you guys. People who make a competent impression and whose arguments make sense to me to a degree, despite my lack of knowledge on this level (As an IT enterprise architect, I design datacenters and super complex stuff but I'm not a software guy).
So tell me, who should I believe. What IS the correct configuration before I go

If your system was affected by the CIIN flaw then how could it be fast and stable with both approaches? After all, you were aware that one approach provided a fix for the CIIN flaw and the other does not.

My recommendation was to make your determination on the matter rather than rely on the advice of others (who are perfectly willing to let you become the Boing Ball for their own selfish purposes). In the end, the correct configuration is the one which provides you (and your system) with the most satisfactory results. In the end, the final decision is and always was yours to make.

[StompinSteve]

Originally Posted by Thomas Richter

How does it enter the system? If this is an AddMemory

I do nothing Prof. Richter
TF536 Memory is/should be fully autoconfiguring should it not?

[StompinSteve]

Originally Posted by SpeedGeek

My recommendation was to make your determination on the matter

If i had any qualifications to do so, I would.

But I have made my decision. I'm going with the "Setpatch + cpu fastrom + 68030.library" constellation.
Nothing else. No mmu-library.
Performance is better this way. The much better Seek/Read values can only really be felt in DOpus when listing large directories. It's a little quicker than with mmu.library and friends.
This is really the only application where the speedboost can be felt. I'm not gonna time WHDload speeds with a stop-watch.

Concerning my concerns concerning the CIIN flaw concerns:
i've been punishing the GVP and the TF for 3 hours now.
I've been copying many hundred Megabytes worth of Quarterbackup files, small and large, back and forth between ZuluSCSI Harddrives (a separate image file on the SD card, each presented as a SCSI device aka "harddisk" to the OS) and thus every (virtual) harddisk saw heavy prolonged reading and writing.
I use a tool that copies, then does a binary compare between the source and copy and so far, no data-corruption has occured. So I CIINk i'm good.

[StompinSteve]

Originally Posted by StompinSteve

Update on the Jitter issue:
Just now, I created my first Quarterback backup of this system since installing the Blizzard Scsi-kit. During the actual backup, the screen goes bananas, in the same way as during the MEMF_CHIP benchmark.

As this never happened before when I was using a IDE CF "Harddisk" and the 1240T in this machine, i'm 100% sure this is related to the Scsi-Kit IV

Update to the update: If I boot from the normal Workbench 3.1 floppy and start Quarterback Backup and do a backup, there is no jitter at all.

Only when Workbench is fully loaded from the ZuluSCSI "HDD" with al the MuLibs tuning and everything, does the Jitter occur during backup.

[Thomas Richter]

Originally Posted by StompinSteve

I do nothing Prof. Richter
TF536 Memory is/should be fully autoconfiguring should it not?

Apparently, they have a bug then in the autoconfig. Worth reporting the issue. There are 8 bytes at the end of the area that are likely not RAM.

[Thomas Richter]

Originally Posted by StompinSteve

If i had any qualifications to do so, I would.

But I have made my decision. I'm going with the "Setpatch + cpu fastrom + 68030.library" constellation.
Nothing else. No mmu-library.

*Sigh* Stop listening to incompetent people. That is not going to work. The 68030.library *needs* the mmu.library.

Originally Posted by StompinSteve

Performance is better this way.

Once again, "CPU FastROM" does exactly the same than "MuFastROM". No difference. You can play with the MMU page size and the "Layout" command in the MMU-Configuration if you think that this makes a difference, but again, this will create issues at other ends, so it is usually not worth doing. Larger page sizes may help to improve the performance of the system in general, but are of disadvantage for the MuEVD shapeshifter video driver. As I said earlier, it is a compromize. You are invited to find the sweet spot for your system if you are in experimental mood, but experimenting by removing system components is not the right sort of experiment. Use the parameters the system has to offer.

[Thomas Richter]

Originally Posted by StompinSteve

Update to the update: If I boot from the normal Workbench 3.1 floppy and start Quarterback Backup and do a backup, there is no jitter at all.

Only when Workbench is fully loaded from the ZuluSCSI "HDD" with al the MuLibs tuning and everything, does the Jitter occur during backup.

Describe what you mean by "jitter", and which video mode you are using.



Note in particular that *some* video modes may require availability of the CPU during the vertical blank, and the CPU may not be able to react if the bus is fully loaded with DMA transfers. In particular, it may be interesting where the blizzard driver ends up in RAM, and whether the TF is really autoconfiguring correctly. In worst case, the SCSI driver ends up in the slow 24-bit RAM, and that RAM may in worst case block CPU access if everything in the system is busy - IOWs, DMA is then so fast that it steals every available cycle on the bus, preventing timely response of the CPU to the video subsystem.

[StompinSteve]

Originally Posted by Thomas Richter

Describe what you mean by "jitter", and which video mode you are using.

Sorry, that message was meant for TheBajaGuy.
But I can repeat our "jittery" conversation from page 4" no problem:

The videomode the "funky display / jitter" occurs with is SuperPlus 800x600

Originally Posted by thebajaguy

-
Originally Posted by StompinSteve.
"An interesting observation: only during all the MEMF_CHIP tests, the screen gets corrupted, bounces all over the place, tears, goes funky, and the speeds at which is does this, is different for each test (4096 byte, 32768 byte etc.).
At the same time, the IndivisionAGAmk3 OnScreenDisplay pops in and out saying that the resolution changed, that Interlace mode is on and off and goes crazy too.
As soon as the MEMF_CHIP benchmark is over, the screen is normal again.
I've never seen this. Only on this A1200 and only now that I run it on SCSI. It must mean that the test-software overwrites an area in chipram that has screenbuffer content in it I guess?"
______________________________________________

TheBajaGuy: I have seen this jitter in other 'benchmark' situations, in times past, but it's been awhile.

As pure speculation, I suspect there may be unexpected 'interaction' between the CPU/Accelerator card having the ChipRAM bus and Alice (or Agnus) memory access while video DMA is stealing access cycles from the CPU.

I've wondered about it, but only someone with the test gear to watch who has the ChipRAM bus / who gives up the bus, and when might be able to tell. I don't think it's software-related.

[StompinSteve]

Originally Posted by Thomas Richter

The 68030.library *needs* the mmu.library.

Thanks. Did not know that. I thought that the 68030.library is something that SetPatch uses and that the mmu.library is only used by other components in the MuLibs suite, like MuFastRom, MuFastZero etc.

If I may make a small (but somewhat related) detour: I noticed that the Phase5 68040.library that came with my Blizzard 1240 is huge compared, to all the other 68040.library files (commodore, the one in the MuLib distro).
The Phase5 version is 88k or so. All the others are much smaller, around half that size.
Can I deduct from that, that the Phase5 library is a self-contained package with much of the functionality inside it, that is normally divided between 68040.library and mmu.library and/or other files?
I'm just curious why the Phase5 version is so large.

[hooverphonique]

Originally Posted by StompinSteve

If I may make a small (but somewhat related) detour: I noticed that the Phase5 68040.library that came with my Blizzard 1240 is huge compared, to all the other 68040.library files (commodore, the one in the MuLib distro).
The Phase5 version is 88k or so. All the others are much smaller, around half that size.
Can I deduct from that, that the Phase5 library is a self-contained package with much of the functionality inside it, that is normally divided between 68040.library and mmu.library and/or other files?
I'm just curious why the Phase5 version is so large.

That can't be the case because the original C= 68040.library is loaded by setpatch, and there is no mmu.library supplied (at least on OS 3.0/3.1).