![]() |
![]() |
#81 | ||
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,110
|
Quote:
Similar like copy files with long file names (from SFS or PFS) to OFS or FFS diskette is impossible without file renaming. You want to protect Amiga users against make stupid things. This is bad way. Quote:
Previously Amiga limitation was too slow CPU. Now limitations are old Amiga kickstarts standards like 2 GB file length limit and 2GB memory limit. |
||
![]() |
![]() |
#82 | ||
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
Quote:
Quote:
Code:
Q: Why does the CV3D install disk say that I need to run enforcer if I have a Amiga 2000 with a 030 card? A: Enforcer is needed for all machines that have a 030 and run the CV3D in Z2 space. The problem is that the io register space is in Z2 space with a2000 and Z2 space is always cachable if no enforcer is running, since this space also intended for memory cards. The CV3D io register space interferes with that caching stuff. This is not a problem for a3000 and Z3. Also the 040 and 060 always installs a mmu table at setpatch point (68040.library does that) - the cache is invalidated for z2 space and CV3D works fine. This is what enforcer does for the 030. |
||
![]() |
![]() |
#83 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 61
Posts: 850
|
Quote:
There is a way to reduce the number of possible ATC entries with the 1st level MMU table by limiting the number of bits used, which determine the size of the address space managed by the MMU. Hence, effectively allowing early termination of the MMU tables, which will affect the ATC performance. Last edited by SpeedGeek; 11 April 2024 at 20:59. |
|
![]() |
![]() |
#84 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 61
Posts: 850
|
Quote:
![]() But this really makes no sense because the Z2 I/O space is non-cachable. The real problem with the 030 is that long word aligned longword writes ignore the CIIN signal. The same problem should affect either Z2 I/O space or Z3 I/O cards. This problem can be worked around in hardware or software, but developers didn't always do that, so Enforcer was the quick fix back then. Is it possible that the real problem in Z2 mode is the CV643D mapping 4MB of graphics RAM into the Z2 Fast memory space? Note: Normally, this is not a problem for an output only device. Last edited by SpeedGeek; 11 April 2024 at 21:00. |
|
![]() |
![]() |
#85 | ||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
Quote:
Which, in effect, does not make any difference because... Quote:
...of this. The affected register is the "blitter" status, a 32-bit register aligned to a 32-bit boundary. Thus, P5 apparently received a defect report from a user, found that enforcer fixed it, and added it to the FAQ without really understanding the cause of the problem. Quote:
Quote:
What the mmulib and the enforcer do is to only map those regions as cachable that appear in the memory list, and thus not the CV3D video RAM and the video registers. Side information: The GVP EGS 110 has no blitter, and thus can enable caching for video RAM. Thus, GVP added a "startup tweak" to be run before setpatch which added "dummy" memory regions into the exec memory list. |
||||
![]() |
![]() |
#86 | |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
Quote:
|
|
![]() |
![]() |
#87 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
Not that I know of. The register mapping of the CV3D is rather unorthogonal and depends on whether the card is operating in Z2 or Z3 space (or even in PCI space), but the blitter(accelerator) control register is both read and write at the same memory space.
|
![]() |
![]() |
#88 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 61
Posts: 850
|
Quote:
Whether you prefer to call it a region or an address space really makes no difference. What is important to remember, is that for Zorro2 there are designated cachable and non-cachable address spaces. Zorro2 Fast memory expansions use the cachable address space and Zorro2 I/O expansions use the non-cachable address space. For Zorro3 expansions, the are no designated cachable and non-cachable address spaces, each board or device determines it's cachable functionality. BTW, I have a Picasso II+ which maps 2MB of graphics RAM into the Zorro2 cachable space. I would expect that, the blitter register is mapped into the Zorro2 non-cachable space. So, I don't know why P5 would do such sloppy design work when they had a proven good design example available in Germany. ![]() |
|
![]() |
![]() |
#89 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 540
|
Quote:
Data structures succeed in shaping code more than code in turn manages to shape data structures. We are stuck with operating system components, on multiple levels, which were designed to use signed 32-bit integers to represent anything between quantities, positions and distances. While the constraints imposed by having to use signed numbers are not beyond fixing and even clever workarounds, it is ugly business even trying to make progress. New fixes for old code will not translate into more robust or predictable behaviour unless that old code is rebuilt from the source code, or maybe patched in the right places. Such fixes, for example if file size reporting is concerned, will have to work in context with the code that builds upon them. For example, the runtime library that ships with your 'C' compiler will expect signed integers for size and position information and glitch into undefined behaviour without even trying. You could fix that, but you would have to go over the runtime library source code (if you have it) with a microscope and somebody to assist you in verifying that the changes are sound. Sounds like work to me (avoid it if you can). There is the potential that such fixes and workarounds will get you somewhere, and you better consider how much this effort will be worth it to you. Retroactively changing data structures and APIs is unlikely to yield improvements because software just does not expect such changes to be possible. Furthermore, software and even operating system code, as a rule, practically never ever checks if the parameters for an arithmetic operation to perform are in the expected range, or if the operation results in an arithmetic overflow. Mostly, such code assumes that the parameter values will be in range because, for example, a storage device will never be so large that its size cannot be reliably represented by a signed 32-bit integer (largest disk size for a 1986 era Amiga was 26 * 512 * 8 blocks, i.e. 106,496 * 512 = 54 MBytes). Indeed, the Amiga operating system was not designed to be stable or resilient. There was just not enough RAM or ROM space available to make it so. Also, the burden to restart the system after even the nastiest avoidable crash was rather low (if you could stand the sound of the disk likely getting sawed in half by the Disk-Validator while the boot process was still in progress). The "prime example" for that is the RAM handler which is expected to run out of available memory long before unchecked integer arithmetic overflows will start to bite. This was a reasonable assumption in 1986 and still is, but long before signed/unsigned 32-bit integer arithmetic trouble enters from stage left, you are already deep into undefined behaviour because RAM handler will have stopped making sense of its own bookkeeping information. This is the "default mode" for the Amiga default ROM file system, too, and reliably unreliable tools such as HDToolbox. Up until fairly recently, HDToolbox did not know its own limitations and just went over the rails instead, corrupting your hard disk partition information like it was supposed to do that. The same can still be said about the Amiga default ROM file system. Same goes for the scsi.device and the trackdisk.device. Turns out you can ship an operating system if you just stop checking for so many error conditions, freeing up enough ROM space for everything to fit into it. This puts the burden on the developer to be extra cautious and make no mistakes whatsoever when writing the code, avoiding the conditions under which undefined behaviour will invariably result. Guess who knew that these rules applied or managed to apply them ![]() So, what can you do? Make the software and the ROM code more resilient, have it validate the parameters it receives before blindly committing to them and making a mess. That is doable, but will invariably eat either RAM or ROM space like popcorn. Add new APIs and data structures which complement and extend the existing ones, avoiding the ambiguity that comes with signed/unsigned integer operations. This is what was done in the AmigaOS4 dos.library, which has replacements for the signed 32-bit-integer-constrained Examine/ExNext/ExAll functions, etc. Invariably, you will have to go through the entire operating system and its tools & shell commands, cleaning them up. That takes the kind of grit and courage which is easily mistakable for stupidity ![]() |
|
![]() |
![]() |
#90 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
Quote:
Quote:
|
||
![]() |
Currently Active Users Viewing This Thread: 2 (0 members and 2 guests) | |
Thread Tools | |
![]() |
||||
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 |
|
|