Tag Archives: Memory addressing

vivo Virtual RAM For V21, V21e, X60 : How Does It Work?

The vivo V21 series and X60 smartphones now support Virtual RAM / Extended RAM technology!

But what exactly is vivo Virtual RAM, and how does it work?

 

vivo Virtual RAM : How Does It Work?

First introduced in the vivo V21 series, vivo Virtual RAM is basically virtual memory that computers have been using for decades.

When our computers begin to run out of memory, it can use some of our HDD / SDD storage as virtual memory.

While storage speeds are many times slower than RAM speed, this is better than running out of memory, which would cause the app to stop working, or worse, crash the operating system.

vivo Virtual RAM uses the same concept – it utilises 3 GB of the smartphone’s internal storage as virtual memory.

This effectively gives the operating system and apps more memory to use. If your vivo smartphone has 8 GB of RAM, then Virtual RAM expands that to 11 GB.

To improve performance, vivo also borrowed the PC virtual memory technique of swapping out inactive apps into the extended RAM space, so active apps have access to the much faster RAM.

The Virtual RAM technology was introduced in the V21 series, and will soon be added to their flagship X60 smartphone.

 

vivo Virtual RAM : How Useful Is It?

That really depends on how you use your smartphone.

If you only use a few apps at the same time, you will probably never run out of memory.

vivo smartphones now come with a lot of memory – 8 GB, and even games like PUBG Mobile and Asphalt 9 use less than 1.2 GB of RAM!

But if you use many apps simultaneously, or switch between them often, this could help prevent slow loading.

According to vivo, turning on Virtual RAM on an 8 GB smartphone will allow you to cache up to 20 background apps simultaneously.

 

Recommended Reading

Go Back To > Mobile | Tech ARP

 

Support Tech ARP!

If you like our work, you can help support us by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!


RW Queue Bypass from The Tech ARP BIOS Guide

RW Queue Bypass

Common Options : Auto, 2X, 4X, 8X, 16X

 

Quick Review of RW Queue Bypass

The RW Queue Bypass BIOS setting determines how many times the arbiter is allowed to bypass the oldest memory access request in the DCI’s read/write queue.

Once this limit is reached, the arbiter is overriden and the oldest memory access request serviced instead.

As this feature greatly improves memory performance, most BIOSes will not include a Disabled setting.

Instead, you are allowed to adjust the number of times the arbiter is allowed to bypass the oldest memory access request in the queue.

A high bypass limit will give the arbiter more flexibility in scheduling memory accesses so that it can maximise the number of hits on open memory pages.

This improves the performance of the memory subsystem. However, this comes at the expense of memory access requests that get delayed. Such delays can be a problem for time-sensitive applications.

It is generally recommended that you set the RW Queue Bypass BIOS feature to the maximum value of 16X, which would give the memory controller’s read-write queue arbiter maximum flexibility in scheduling memory access requests.

However, if you face stability issues, especially with time-sensitive applications, reduce the value step-by-step until the problem resolves.

The Auto option, if available, usually sets the bypass limit to the maximum – 16X.

 

Details of RW Queue Bypass

The R/W Queue Bypass BIOS option is similar to the DCQ Bypass Maximum BIOS option – they both decide the limits on which an arbiter can intelligently reschedule memory accesses to improve performance.

The difference between the two is that DCQ Bypass Maximum does this at the memory controller level, while R/W Queue Bypass does it at the Device Control Interface (DCI) level.

To improve performance, the arbiter can reschedule transactions in the DCI read / write queue.

By allowing some transactions to bypass other transactions in the queue, the arbiter can maximize the number of hits on open memory pages.

This improves the overall memory performance but at the expense of some memory accesses which have to be delayed.

The RW Queue Bypass BIOS setting determines how many times the arbiter is allowed to bypass the oldest memory access request in the DCI’s read/write queue.

Once this limit is reached, the arbiter is overriden and the oldest memory access request serviced instead.

As this feature greatly improves memory performance, most BIOSes will not include a Disabled setting.

Instead, you are allowed to adjust the number of times the arbiter is allowed to bypass the oldest memory access request in the queue.

A high bypass limit will give the arbiter more flexibility in scheduling memory accesses so that it can maximise the number of hits on open memory pages.

This improves the performance of the memory subsystem. However, this comes at the expense of memory access requests that get delayed. Such delays can be a problem for time-sensitive applications.

It is generally recommended that you set this BIOS feature to the maximum value of 16X, which would give the memory controller’s read-write queue arbiter maximum flexibility in scheduling memory access requests.

However, if you face stability issues, especially with time-sensitive applications, reduce the value step-by-step until the problem resolves.

The Auto option, if available, usually sets the bypass limit to the maximum – 16X.

Recommended Reading

[adrotate group=”2″]

Go Back To > The Tech ARP BIOS Guide | Home

 

Support Tech ARP!

If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!


DOS Flat Mode from The Tech ARP BIOS Guide

DOS Flat Mode

Common Options : Enabled, Disabled

 

Quick Review of DOS Flat Mode

The DOS Flat Mode BIOS feature controls the BIOS’ built-in extended memory manager.

When enabled, DOS programs can run in protected mode without the need of an extended memory manager.

When disabled, DOS programs require an extended memory manager to run in protected mode.

It is recommended that you enable DOS Flat Mode if you use the MS-DOS operating system and run protected mode DOS programs.

However, if you use a newer operating system that supports protected mode (for example, Windows XP, disable DOS Flat Mode.

 

Details of DOS Flat Mode

In real mode, MS-DOS (Microsoft Disk Operating System) cannot address more than 1 MB. It is also restricted to memory segments of up to 64 KB in size.

These limitations can be circumvented by making use of extended memory managers. Such software allow DOS programs to make use of memory beyond 1MB by running them in protected mode. This mode also removes the segmentation of memory and creates a flat memory model for the program to use.

Protected mode refers to a memory addressing mode supported since the Intel 80286 was introduced. It provides the following benefits over real mode :

  • Each program can be given its own protected memory area, hence, the name protected mode. In this protected memory area, the program is protected from interference by other programs.
  • Programs can now access more than 1 MB of memory (up to 4 GB). This allows the creation of bigger and more complex programs.
  • There is virtually no longer any segmentation of the memory. Memory segments can be up to 4 GB in size.

As you can see, running DOS programs in protected mode allows safer memory addressing, access to more memory and eliminates memory segmentation. Of course, the DOS program must be programmed to make use of protected mode. An extended memory manager, either within the program or as a separate program, must also be present for the program to run in protected mode. Otherwise, it will run in real mode.

Please note that even with an extended memory manager, MS-DOS does not actually run in protected mode. Only specifically-programmed DOS programs will run in protected mode. The processor switches between real mode and protected mode to handle both MS-DOS in real mode and the DOS program in protected mode.

[adrotate group=”1″]

This is where Gate A20 becomes critical to the computer’s performance. For more information on the effect of Gate A20 on the memory mode switching performance of the processor, please consult the Gate A20 Option BIOS feature.

The DOS Flat Mode BIOS feature controls the BIOS’ built-in extended memory manager.

When enabled, DOS programs can run in protected mode without the need of an extended memory manager.

When disabled, DOS programs require an extended memory manager to run in protected mode.

It is recommended that you enable DOS Flat Mode if you use the MS-DOS operating system and run protected mode DOS programs.

However, if you use a newer operating system that supports protected mode (for example, Windows XP), disable DOS Flat Mode.

Go Back To > The Tech ARP BIOS Guide | Home

 

Support Tech ARP!

If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!


Memory Hole At 15M-16M – The BIOS Optimization Guide

Memory Hole At 15M-16M

Common Options : Enabled, Disabled

 

Quick Review

Certain ISA cards require exclusive access to the 1 MB block of memory, from the 15th to the 16th megabyte, to work properly. The Memory Hole At 15M-16M BIOS feature allows you to reserve that 1 MB block of memory for such cards to use.

If you enable this feature, 1 MB of memory (the 15th MB) will be reserved exclusively for the ISA card’s use. This effectively reduces the total amount of memory available to the operating system by 1 MB.

Please note that in certain motherboards, enabling this feature may actually render all memory above the 15th MB unavailable to the operating system!

If you disable this feature, the 15th MB of RAM will not be reserved for the ISA card’s use. The full range of memory is therefore available for the operating system to use. However, if your ISA card requires the use of that memory area, it may then fail to work.

Since ISA cards are a thing of the past, it is highly recommended that you disable this feature. Even if you have an ISA card that you absolutely have to use, you may not actually need to enable this feature.

Most ISA cards do not need exclusive access to this memory area. Make sure that your ISA card requires this memory area before enabling this feature. You should use this BIOS feature only in a last-ditch attempt to get a stubborn ISA card to work.

 

Details

Certain ISA cards require exclusive access to the 1 MB block of memory, from the 15th to the 16th megabyte, to work properly. The Memory Hole At 15M-16M BIOS feature allows you to reserve that 1 MB block of memory for such cards to use.

If you enable this feature, 1 MB of memory (the 15th MB) will be reserved exclusively for the ISA card’s use. This effectively reduces the total amount of memory available to the operating system by 1 MB. Therefore, if you have 256 MB of memory, the usable amount of memory will be reduced to 255 MB.

Please note that in certain motherboards, enabling this feature may actually render all memory above the 15th MB unavailable to the operating system! In such cases, you will end up with only 14 MB of usable memory, irrespective of how much memory your system actually has.

[adrotate banner=”4″]

If you disable this feature, the 15th MB of RAM will not be reserved for the ISA card’s use. The full range of memory is therefore available for the operating system to use. However, if your ISA card requires the use of that memory area, it may then fail to work.

Since ISA cards are a thing of the past, it is highly recommended that you disable this feature. Even if you have an ISA card that you absolutely have to use, you may not actually need to enable this feature.

Most ISA cards do not need exclusive access to this memory area. Make sure that your ISA card requires this memory area before enabling this feature. You should use this BIOS feature only in a last-ditch attempt to get a stubborn ISA card to work.

 

Support Tech ARP!

If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!

AGP ISA Aliasing – The BIOS Optimization Guide

AGP ISA Aliasing

Common Options : Enabled, Disabled

 

Quick Review

The AGP ISA Aliasing BIOS feature allows you to determine if the system controller will perform ISA aliasing to prevent conflicts between ISA devices.

The default setting of Enabled forces the system controller to alias ISA addresses using address bits [15:10]. This restricts all 16-bit addressing devices to a maximum contiguous I/O space of 256 bytes.

When disabled, the system controller will not perform any ISA aliasing and all 16 address lines can be used for I/O address space decoding. This gives 16-bit addressing devices access to the full 64KB I/O space.

It is recommended that you disable AGP ISA Aliasing for optimal AGP (and PCI) performance. It will also prevent your AGP or PCI cards from conflicting with your ISA cards. Enableit only if you have ISA devices that are conflicting with each other.

 

Details

The origin of the AGP ISA Aliasing feature can be traced back all the way to the original IBM PC. When the IBM PC was designed, it only had ten address lines (10-bits) for I/O space allocation. Therefore, the I/O space back in those days was only 1KB or 1024 bytes in size. Out of those 1024 available addresses, the first 256 addresses were reserved exclusively for the motherboard’s use, leaving the last 768 addresses for use by add-in devices. This would become a critical factor later on.

Later, motherboards began to utilize 16 address lines for I/O space allocation. This was supposed to create a contiguous I/O space of 64KB in size. Unfortunately, many ISA devices by then were only capable of doing 10-bit decodes. This was because they were designed for computers based on the original IBM design which only supported 10 address lines.

To circumvent this problem, they fragmented the 64KB I/O space into 1KB chunks. Unfortunately, because the first 256 addresses must be reserved exclusively for the motherboard, this means that only the first (or lower) 256 bytes of each 1KB chunk would be decoded in full 16-bits. All 10-bits-decoding ISA devices are, therefore, restricted to the last (or top) 768 bytes of the 1KB chunk of I/O space.

As a result, such ISA devices only have 768 I/O locations to use. Because there were so many ISA devices back then, this limitation created a lot of compatibility problems because the chances of two ISA cards using the same I/O space were high. When that happened, one or both of the cards would not work. Although they tried to reduce the chance of such conflicts by standardizing the I/O locations used by different classes of ISA devices, it was still not good enough.

Eventually, they came up with a workaround. Instead of giving each ISA device all the I/O space it wants in the 10-bit range, they gave each a much ISA device smaller number of I/O locations and made up for the difference by “borrowing” them from the 16-bit I/O space! Here’s how they did it.

The ISA device would first take up a small number of I/O locations in the 10-bit range. It then extends its I/O space by using 16-bit aliases of the few 10-bit I/O locations taken up earlier. Because each I/O location in the 10-bit decode area has sixty-three16-bit aliases, the total number of I/O locations expands from just 768 locations to a maximum of 49,152 locations!

More importantly, each ISA card will now require very few I/O locations in the 10-bit range. This drastically reduced the chances of two ISA cards conflicting each other in the limited 10-bit I/O space. This workaround naturally became known as ISA Aliasing.

Now, that’s all well and good for ISA devices. Unfortunately, the 10-bit limitation of ISA devices becomes a liability to devices that require 16-bit addressing. AGP and PCI devices come to mind. As noted earlier, only the first 256 addresses of the 1KB chunks support 16-bit addressing. What that really means is all 16-bit addressing devices are thus limited to only 256 bytes of contiguous I/O space!

When a 16-bit addressing device requires a larger contiguous I/O space, it will have to encroach on the 10-bit ISA I/O space. For example, if an AGP card requires 8KB of contiguous I/O space, it will take up eight of the 1KB I/O chunks (which will comprise of eight 16-bit areas and eight 10-bit areas!). Because ISA devices are using ISA Aliasing to extend their I/O space, there’s now a high chance of I/O space conflicts between ISA devices and the AGP card. When that happens, the affected cards will most probably fail to work.

[adrotate banner=”5″]

There are two ways out of this mess. Obviously, you can limit the AGP card to a maximum of 256 bytes of contiguous I/O space. Of course, this is not an acceptable solution.

The second, and the preferred method, would be to throw away the restriction and provide the AGP card with all the contiguous I/O space it wants.

Here’s where the AGP ISA Aliasing BIOS feature comes in.

The default setting of Enabled forces the system controller to alias ISA addresses using address bits [15:10] – the last 6-bits. Only the first 10-bits (address bits 0 to 9) are used for decoding. This restricts all 16-bit addressing devices to a maximum contiguous I/O space of 256 bytes.

When disabled, the system controller will not perform any ISA aliasing and all 16 address lines can be used for I/O address space decoding. This gives 16-bit addressing devices access to the full 64KB I/O space.

It is recommended that you disable AGP ISA Aliasing for optimal AGP (and PCI) performance. It will also prevent your AGP or PCI cards from conflicting with your ISA cards. Enableit only if you have ISA devices that are conflicting with each other.

 

Support Tech ARP!

If you like our work, you can help support our work by visiting our sponsors, participate in the Tech ARP Forums, or even donate to our fund. Any help you can render is greatly appreciated!