09 April 2024, 22:41 | #61 | |||
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 43
Posts: 934
|
Quote:
Quote:
If you enable the MMU by using something simpler, like remap the kickstart to fast using the 3.1 "Cpu FASTROM", at least I have not been able to measure a slowdown. Just so nobody chimes in and says "but the system will get faster by doing that, it is not a valid test": tested this on an A3000 030@25MHz with the kickstart rom timing jumper set to the fastest setting, which means fastmem and rom has the same number of waitstates and the rom is 32-bit, so remapping kickstart to fast does not give a performance benefit. The tests I did can be seen in the original thread I linked to: https://eab.abime.net/showthread.php...37#post1587137 Even if mmu.library is set to use the same 32kB page size as "Cpu FASTROM", you can measure a slowdown (much smaller than with default 1kB), so reasonably the MMU config or table must be fairly complicated in the mmu.library case compared to the "Cpu FASTROM" case, else it should not result in a slower system. Just remapping the kickstart rom should also reasonably be way less advanced than what a generic mmu library does. Quote:
If you do the latter and remove 68030.library but keep mmu.library, it will stop being forcefully loaded by C:SetPatch at beginning of boot via 68030.library. So the MMU will not be enabled unnecessarily at boot, but if you want to run say MuForce you can still start it. If you do an "Avail flush" after stopping MuForce, mmu.library will expunge itself cleanly and disable the MMU, restoring performance. Last edited by patrik; 09 April 2024 at 22:50. |
|||
09 April 2024, 23:02 | #62 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
There is nothing "complicated" in the setup. Actually, quite reverse, there is something "complicated" with "CPU FastROM" - the "trick", if you want to say so, is that it enables the TTx registers outside the 24-bit address space where the MMU is bypassed. This is "sometimes" correct, but not always. It is not correct if there is something to do for the MMU in the 32-bit address space, for example if an expansion maps there that does not support caching. Thus, it is not a generally working or advisable solution. A typical example is if you have a Z-III graphics card with a blitter which modifies the memory bypassing the CPU. In "most cases" the conflict between the blitter and the CPU would not be noticed due to the miniature cache of the 68030, but that does not make the approach correct. It would neither work if you have 32-bit I/O registers in 32-bit memory (example: The CVision3D) which cannot be cached because they change "under the feed" of the CPU which attempts to cache them. |
|
09 April 2024, 23:36 | #63 | |
Registered User
Join Date: Apr 2013
Location: Norway
Posts: 258
|
Quote:
Code:
3.0 (29.4.22) · faster rolled Autovec But it requires a double reboot now. Not a huge problem, but if it can be avoided, that would be nice. I guess the solution would then be to get the Blizkick module working, or are there any other approaches? Thanks again for your excellent posts! |
|
10 April 2024, 08:10 | #64 | |
Registered User
Join Date: Oct 2017
Location: Amsterdam
Posts: 231
|
Quote:
That's when I started my experiments to find out the correct order to reach the performance level I was used to. I learned the correct order and what commandline options to use for BlizKick and for LoadModule as previously stated, but both methods rely on MuTools. There is actually a third method (and a fourth thanks to patrik) that I experimented with back then, but it has a couple of flaws: - Huge commandline with EXTRESBUF - The EXTRESBUF value is cherrypicked and most likely needs finetuning - BlizKick doesn't properly support 3.1.4+ (3.1 ROM is mentioned for instance in WB About) The major benefit here is that the individual BlizKick modules work again (BBlank, LocalFast and NoClick in below example). I can't remember exactly, because it has been a while, but I believe this only needs a single reboot as well. The line in question is: Code:
C:BlizKick * EXTRESBUF=600000 audio.device battclock.resource bootmenu card.resource console.device exec.library FastFileSystem FileSystem.resource gameport.device graphics.library icon.library input.device intuition.library keyboard.device layers.library mathffp.library mathieeesingbas.library Ram-Handler ramdrive.device scsi.device Shell-Seg syscheck timer.device trackdisk.device utility.library workbench.library BBlank LocalFast NoClick QUIET One sidenote: I'm using a 3.1 ROM here, not entirely sure what the above does when having a 3.0 ROM version as you previously stated.. |
|
10 April 2024, 08:30 | #65 |
Registered User
Join Date: Dec 2016
Location: Italy
Posts: 769
|
I own a Blizzard 1230mkIV and I use Blizkick:
C:Blizkick Devs/Kickstart/Kick47111.A1200 MuMove4K SpeedyIDE QUIET SetPatch QUIET C:MuFastZero FastExec FastSSP QUIET With these lines I get 32BitRam usage for all libraries except for: expansion.library (FAST RAM) exec.library (FAST RAM) but system works well. If I use FastExec: C:Blizkick DEVS/Kickstart/Kick47111.A1200 SpeedIDE QUIET C:FastExec FastEXP FastSSP REBOOT I have 2 reboots, the system seems works as first but I have all libraries/devs in 32BitRam, also: expansion.library (32BitRam) exec.library (32BitRam) What is the difference from Fast Ram and 32BitRam from first and second solution ? Thanks. Last edited by DanyPPC; 10 April 2024 at 08:51. |
10 April 2024, 08:39 | #66 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Without knowing the details, hard to say. Thus, to answer your question, I would need the base addresses of the libraries, and the output of MuScan.
|
10 April 2024, 10:25 | #67 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
And about LONG vs ULONG "dos/dos.h defines it to be a LONG".
This is buggy, must be ULONG. File length cant be negative value. This is logical. Amiga OS 3.9 handle this as ULONG, and can display file sizes up to 4GB. But You perhaps know this. |
10 April 2024, 11:28 | #68 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
Again, there is one crucial thing you do not seem to get: This does not fix old software, and it is not just "for showing file lengths". Thus, this is not a "generally working" way of how to make "long files work". After all, it is just one bit. How a file system reacts on such long files is probably yet another issue. |
|
10 April 2024, 13:15 | #69 | |
Registered User
Join Date: Dec 2016
Location: Italy
Posts: 769
|
Quote:
https://eab.abime.net/attachment.php...1&d=1712747586 https://eab.abime.net/attachment.php...1&d=1712747654 These from FastExec 3.0: https://eab.abime.net/attachment.php...1&d=1712747697 https://eab.abime.net/attachment.php...1&d=1712747711 OT: I have a doubt and I don't know if it is related to OS 3.2. I have a 16GB Internal CF card formatted and prepared with OS 3.2 (3 x partitions 1GB + 7GB + 7GB). I use Blizkick to map Kick 47.111 but in hardware I own Kick 40.068 (3.1). My doubt is, why if I boot (first start) to shell (boot without s-s), so I'm using Kick 3.1 I can see and use the 3 partitions ? I know that Kick 3.1 can use up to 8GB with updated FFS and only 2GB x partition. Could this be related to OS 3.2 prepared and installed mode ? Sorry for the OT. Last edited by DanyPPC; 10 April 2024 at 13:58. |
|
10 April 2024, 14:57 | #70 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
Quote:
|
||
10 April 2024, 15:00 | #71 |
Registered User
Join Date: Dec 2016
Location: Italy
Posts: 769
|
Many thanks Thomas for the clarification
|
10 April 2024, 15:24 | #72 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
Quote:
Same bug/limitation was for HD partition sizes, it was defined as LONG not ULONG. Then for older kicks You can see negative values as partition sizes. For all partitions greater than 2GB. Someone fixed old software which shows wrong partition sizes? No. Except new programs or new program versions. Same will be for 2GB limit for file sizes. Newest programs can handle (show) file sizes as ULONG, even if this is buggy declared as LONG in dos.h. This is called progress. Now for Amiga You can connect f.e PiStorm. This is another progress, hardware progress. Very fast CPU and very fast graphic cards. But with Amiga OS/kickstart limits (size of memory and size of files) from 1985 year. No true software progress, except some visuals. |
|
10 April 2024, 16:18 | #73 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Consider programs showing disk content. For large files, they will just show the wrong number. Consider a copy program that allocates buffers or space on the target according to the size in the file info block. We cannot fix them, but we can avoid that major havoc happens if you use such programs. For example, by not showing them in the directory unless the right function is called, or by creating an error if you attempt to get information on them with the wrong functions.
A little bit more care is needed. Progress? Amiga? Let's be real, please. This is really a historic system, and not a productive environment. There is not really a use case for such large files. Will you view DVDs on the Amiga? No. Burn them? No. |
10 April 2024, 16:26 | #74 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
It seems that P5 had worked around the CVision3D Board issue with their 030 CGX driver. I didn't find anything in the CVision3D manual requiring anything but the 030 CGX driver. |
|
10 April 2024, 16:49 | #75 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
From the manuals I have, it says that you are supposed to run "Enforcer QUIET". |
|
10 April 2024, 17:25 | #76 | |
Registered User
Join Date: Oct 2017
Location: Amsterdam
Posts: 231
|
Quote:
Currently that brings us to 4 methods to get exec in Fast when using our Blizzard cards: 1 reboot - LoadModule + MuMove4K + MuFastZero - BlizKick + MuMove4K + MuFastZero - BlizKick extravaganza commandline in combination with LocalFast (and the possibility to disable the mmu stuff (?), haven't tested this yet) 2 reboots - BlizKick + FastExec (and the possibility to disable the mmu stuff) |
|
10 April 2024, 17:30 | #77 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
The CVision643D manual I used was from here: http://amiga.resource.cx/exp/cybervision643d I see nothing about using "Enforcer" in the English part of the Manual. Was it in the German part or were you using a different manual? |
|
10 April 2024, 17:37 | #78 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Sigh. This is *not* how early termination page descriptors work. Again, each *page* allocates an entry, and not *each descriptor*. Yes, that's silly, but that's how the 68030 MMU works.
|
10 April 2024, 17:45 | #79 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
It sounds like you are reading or understanding this differently than me. I am not referring to early termination of table descriptors, rather early termination of the MMU tables.
|
10 April 2024, 17:46 | #80 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
68030UM, page 9-34. Read it. Please. There is no advantage in early termination - in terms of memory, yes. In terms of speed, no. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Slow performance with AmigaOS 3.1.4 in WinUAE 4.2.1 | matsp888 | support.WinUAE | 15 | 13 January 2020 03:15 |
Accurate performance? | epoxxy | support.WinUAE | 1 | 25 October 2015 14:22 |
Getting more performance out of my A1200 | Devlin | support.Hardware | 4 | 18 December 2013 18:17 |
PSPUAE Performance | tonyyeb | support.OtherUAE | 73 | 27 January 2011 16:45 |
How do I get the best WB performance? | Rabbit80 | support.Apps | 27 | 01 July 2009 11:29 |
|
|