Why VGA framebuffer was limited to 64kB window?ISA Extension cards using more than 64kBGame Boy DMG to VGAConverting SCART to VGA/JackAcorn Electron to VGA/HDMI?Which graphics adapters outputted S-Video over VGA?Mapping more than 64kb of address spaceChoosing a VGA card for the IBM 5162?Do all VGA cards implicitly support CGA and EGA?Does a final version of the IBM VGA XGA Technical Reference Manual exist?How can a Z80/8080/6502 use VGA?What are the HSync and VSync frequencies of these common VGA tweak modes?

Why does there seem to be an extreme lack of public trashcans in Taiwan?

When to use и or а as “and”?

What is the logic behind charging tax _in the form of money_ for owning property when the property does not produce money?

Why is long-term living in Almost-Earth causing severe health problems?

Is it true that "only photographers care about noise"?

Do SFDX commands count toward limits?

How to handle when PCs taste a potion that is actually poison?

Etymology of the expression "to entertain an idea"

What do I need to do, tax-wise, for a sudden windfall?

How to avoid typing 'git' at the begining of every Git command

Was planting UN flag on Moon ever discussed?

Traceroute showing inter-vlan routing?

That's not my X, its Y is too Z

Are the guests in Westworld forbidden to tell the hosts that they are robots?

Make Gimbap cutter

How many sets of dice do I need for D&D?

How to generate list of *all* available commands and functions?

In American Politics, why is the Justice Department under the President?

If absolute velocity does not exist, how can we say a rocket accelerates in empty space?

As easy as Three, Two, One... How fast can you go from Five to Four?

Deciphering old handwriting from a 1850 church record

Why are ambiguous grammars bad?

How can powerful telekinesis avoid violating Newton's 3rd Law?

What is this object?



Why VGA framebuffer was limited to 64kB window?


ISA Extension cards using more than 64kBGame Boy DMG to VGAConverting SCART to VGA/JackAcorn Electron to VGA/HDMI?Which graphics adapters outputted S-Video over VGA?Mapping more than 64kb of address spaceChoosing a VGA card for the IBM 5162?Do all VGA cards implicitly support CGA and EGA?Does a final version of the IBM VGA XGA Technical Reference Manual exist?How can a Z80/8080/6502 use VGA?What are the HSync and VSync frequencies of these common VGA tweak modes?













6















VGA framebuffer was fixed to 64kB at A0000h. Right after that there’s MDA/CGA framebuffer at B0000h. I am not sure, but I recall VGA did have to support CGA and its framebuffer, but was there any reason why VGA couldn’t use eg 128kB (ie segments A and B) as linear framebuffer for modes such as 320x240x8b?



ModeX and others do imply all VGA boards must’ve had more than 64kB of video ram on board, but it had to be accessed via bank switching. Since VGA would need to claim ownership of B segment for CGA compatibility (but this is not needed if using VGA display modes), I cannot see any reason why they did resort to bank switching.










share|improve this question







New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 1





    Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

    – Curt J. Sampson
    Jun 5 at 0:29











  • Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

    – dirkt
    Jun 5 at 5:43















6















VGA framebuffer was fixed to 64kB at A0000h. Right after that there’s MDA/CGA framebuffer at B0000h. I am not sure, but I recall VGA did have to support CGA and its framebuffer, but was there any reason why VGA couldn’t use eg 128kB (ie segments A and B) as linear framebuffer for modes such as 320x240x8b?



ModeX and others do imply all VGA boards must’ve had more than 64kB of video ram on board, but it had to be accessed via bank switching. Since VGA would need to claim ownership of B segment for CGA compatibility (but this is not needed if using VGA display modes), I cannot see any reason why they did resort to bank switching.










share|improve this question







New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 1





    Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

    – Curt J. Sampson
    Jun 5 at 0:29











  • Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

    – dirkt
    Jun 5 at 5:43













6












6








6








VGA framebuffer was fixed to 64kB at A0000h. Right after that there’s MDA/CGA framebuffer at B0000h. I am not sure, but I recall VGA did have to support CGA and its framebuffer, but was there any reason why VGA couldn’t use eg 128kB (ie segments A and B) as linear framebuffer for modes such as 320x240x8b?



ModeX and others do imply all VGA boards must’ve had more than 64kB of video ram on board, but it had to be accessed via bank switching. Since VGA would need to claim ownership of B segment for CGA compatibility (but this is not needed if using VGA display modes), I cannot see any reason why they did resort to bank switching.










share|improve this question







New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











VGA framebuffer was fixed to 64kB at A0000h. Right after that there’s MDA/CGA framebuffer at B0000h. I am not sure, but I recall VGA did have to support CGA and its framebuffer, but was there any reason why VGA couldn’t use eg 128kB (ie segments A and B) as linear framebuffer for modes such as 320x240x8b?



ModeX and others do imply all VGA boards must’ve had more than 64kB of video ram on board, but it had to be accessed via bank switching. Since VGA would need to claim ownership of B segment for CGA compatibility (but this is not needed if using VGA display modes), I cannot see any reason why they did resort to bank switching.







ibm-pc memory-layout vga






share|improve this question







New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question







New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question






New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked Jun 4 at 21:15









tuomastuomas

1434




1434




New contributor



tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




tuomas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









  • 1





    Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

    – Curt J. Sampson
    Jun 5 at 0:29











  • Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

    – dirkt
    Jun 5 at 5:43












  • 1





    Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

    – Curt J. Sampson
    Jun 5 at 0:29











  • Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

    – dirkt
    Jun 5 at 5:43







1




1





Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

– Curt J. Sampson
Jun 5 at 0:29





Use of dual monitors, one VGA and one monochrome/Hercules, was not at all uncommon in the early '90s, in my experience. (I certainly did it for many years myself, and not just for software development. It's handy just like being able to have two terminal windows open is handy now.) By that point monochrome graphics cards and their monitors were very cheap, so adding a second card and monitor was a small part of the computer's total cost.

– Curt J. Sampson
Jun 5 at 0:29













Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

– dirkt
Jun 5 at 5:43





Also note that both EGA and VGA had a way to write into different planes at once with mask registers etc., so it should in theory have been possible to access 4 planes mapped into a single 64 KB segment for a total of 256 KB framebuffer. Though those modes were not popular, so I'm not sure at the moment if there were ever enough bits in the corresponding registers to actually do that.

– dirkt
Jun 5 at 5:43










3 Answers
3






active

oldest

votes


















4














The VGA design is inherited directly from the EGA design, though with a few extra features. Most considerations apply equally to both.



Although it is possible to treat the EGA or VGA memory as four banks of 65,536 octets, the EGA was designed to let it be treated more usefully as 65,536 groups of four octets, where each group had a single assigned CPU address. Within each group of eight pixels, each pixel would use one bit taken from each octet. The EGA and VGA have a 32-bit buffer that gets loaded from all four groups of pixels whenever an address is read, and each write will store to each group of 32 pixels a pattern which is based upon the value written, the value of some configuration and parameter registers, and the contents of the buffer.



This made it possible to perform many kinds of read-modify-write operations on a group of pixels at a time. The CPU would read a byte, ignore the result, and then write a value that indicated how the group of bytes should be modified. The display card would then combine the value in the buffer with the value that was read and store the modified result to all 32 bits. This allowed for bytes in display memory to be updated with a single read-modify-write sequence.



Alas, a couple aspects made this design far less useful than it could have been. They largely boil down to the fact that for various technical reasons, reading display memory is extremely slow, and every action on a group of 32 pixels would require four individual read-write sequences. If the computer had enough "main" RAM to maintain a copy of the screen, building the display contents in RAM and blindly outputting to the display would almost always be faster than trying to use the display's hardware to expedite the process. On slow machines the display hardware could offer some speed advantage, but as main-CPU speed increased the extra display hardware became more and more useless.



Still, the designers of the EGA and VGA had expected that the ability to update multiple bytes at once would be useful, and thus designed their architecture to facilitate it.






share|improve this answer






























    6














    When VGA was designed and released, it had only maximum of 256 kbytes of video memory. The memory of VGA is arranged to have 32-bit interface to the VGA chip to have four byte planes in parallel. Therefore there are only 64k addresses of 32-bit video memory, and data of up to four planes can be accessed with a single CPU access.



    The VGA board can be configured for a 128k framebuffer at A0000h, but both 64k segments will access the 64k addresses of video RAM identically. The trick that makes standard Mode 13h look linear is implemented in hardware, it only uses every fourth address of video memory, and automatically selects the plane based on lowest 2 CPU addresses. Unchained modes need manual plane selection in software when writing to video memory. It would have taken extra logic to make the whole video memory look like linear, and this was just not so important as it already was quite complex and it was enough make it compatible with EGA.



    So in short, the VGA hardware is made to have four bytes accessible via single CPU address so there are only 64k memory addresses the CPU can access.






    share|improve this answer






























      3














      In the 16-bit 8086, addressing of the memory space was done with a two-register pair Segment:Offset. The Segment register (there were four of them) addressed the high 16 bits of the 20-bit addressable memory, and the Offset register addressed the low 16 bits. So The effective address was computed in the CPU by:



      EA = 16 * Segment + Offset


      So, in order to address more than 64k of memory at once, software would have to change the segment register as well as the offset. This was very inefficient in the CPU, and it was much better to limit memory block access to 64k at a time. The video card designers recognized this, and built the hardware with bank switching so that software would not have to change the CPU segment register to address the whole display memory.






      share|improve this answer























      • Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

        – tuomas
        Jun 4 at 21:26






      • 1





        @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

        – Greg Hewgill
        Jun 4 at 21:47






      • 1





        Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

        – Stephen Kitt
        Jun 4 at 21:49






      • 4





        Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

        – Leo B.
        Jun 4 at 22:06






      • 1





        Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

        – Raffzahn
        Jun 4 at 22:22











      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "648"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );






      tuomas is a new contributor. Be nice, and check out our Code of Conduct.









      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11234%2fwhy-vga-framebuffer-was-limited-to-64kb-window%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      The VGA design is inherited directly from the EGA design, though with a few extra features. Most considerations apply equally to both.



      Although it is possible to treat the EGA or VGA memory as four banks of 65,536 octets, the EGA was designed to let it be treated more usefully as 65,536 groups of four octets, where each group had a single assigned CPU address. Within each group of eight pixels, each pixel would use one bit taken from each octet. The EGA and VGA have a 32-bit buffer that gets loaded from all four groups of pixels whenever an address is read, and each write will store to each group of 32 pixels a pattern which is based upon the value written, the value of some configuration and parameter registers, and the contents of the buffer.



      This made it possible to perform many kinds of read-modify-write operations on a group of pixels at a time. The CPU would read a byte, ignore the result, and then write a value that indicated how the group of bytes should be modified. The display card would then combine the value in the buffer with the value that was read and store the modified result to all 32 bits. This allowed for bytes in display memory to be updated with a single read-modify-write sequence.



      Alas, a couple aspects made this design far less useful than it could have been. They largely boil down to the fact that for various technical reasons, reading display memory is extremely slow, and every action on a group of 32 pixels would require four individual read-write sequences. If the computer had enough "main" RAM to maintain a copy of the screen, building the display contents in RAM and blindly outputting to the display would almost always be faster than trying to use the display's hardware to expedite the process. On slow machines the display hardware could offer some speed advantage, but as main-CPU speed increased the extra display hardware became more and more useless.



      Still, the designers of the EGA and VGA had expected that the ability to update multiple bytes at once would be useful, and thus designed their architecture to facilitate it.






      share|improve this answer



























        4














        The VGA design is inherited directly from the EGA design, though with a few extra features. Most considerations apply equally to both.



        Although it is possible to treat the EGA or VGA memory as four banks of 65,536 octets, the EGA was designed to let it be treated more usefully as 65,536 groups of four octets, where each group had a single assigned CPU address. Within each group of eight pixels, each pixel would use one bit taken from each octet. The EGA and VGA have a 32-bit buffer that gets loaded from all four groups of pixels whenever an address is read, and each write will store to each group of 32 pixels a pattern which is based upon the value written, the value of some configuration and parameter registers, and the contents of the buffer.



        This made it possible to perform many kinds of read-modify-write operations on a group of pixels at a time. The CPU would read a byte, ignore the result, and then write a value that indicated how the group of bytes should be modified. The display card would then combine the value in the buffer with the value that was read and store the modified result to all 32 bits. This allowed for bytes in display memory to be updated with a single read-modify-write sequence.



        Alas, a couple aspects made this design far less useful than it could have been. They largely boil down to the fact that for various technical reasons, reading display memory is extremely slow, and every action on a group of 32 pixels would require four individual read-write sequences. If the computer had enough "main" RAM to maintain a copy of the screen, building the display contents in RAM and blindly outputting to the display would almost always be faster than trying to use the display's hardware to expedite the process. On slow machines the display hardware could offer some speed advantage, but as main-CPU speed increased the extra display hardware became more and more useless.



        Still, the designers of the EGA and VGA had expected that the ability to update multiple bytes at once would be useful, and thus designed their architecture to facilitate it.






        share|improve this answer

























          4












          4








          4







          The VGA design is inherited directly from the EGA design, though with a few extra features. Most considerations apply equally to both.



          Although it is possible to treat the EGA or VGA memory as four banks of 65,536 octets, the EGA was designed to let it be treated more usefully as 65,536 groups of four octets, where each group had a single assigned CPU address. Within each group of eight pixels, each pixel would use one bit taken from each octet. The EGA and VGA have a 32-bit buffer that gets loaded from all four groups of pixels whenever an address is read, and each write will store to each group of 32 pixels a pattern which is based upon the value written, the value of some configuration and parameter registers, and the contents of the buffer.



          This made it possible to perform many kinds of read-modify-write operations on a group of pixels at a time. The CPU would read a byte, ignore the result, and then write a value that indicated how the group of bytes should be modified. The display card would then combine the value in the buffer with the value that was read and store the modified result to all 32 bits. This allowed for bytes in display memory to be updated with a single read-modify-write sequence.



          Alas, a couple aspects made this design far less useful than it could have been. They largely boil down to the fact that for various technical reasons, reading display memory is extremely slow, and every action on a group of 32 pixels would require four individual read-write sequences. If the computer had enough "main" RAM to maintain a copy of the screen, building the display contents in RAM and blindly outputting to the display would almost always be faster than trying to use the display's hardware to expedite the process. On slow machines the display hardware could offer some speed advantage, but as main-CPU speed increased the extra display hardware became more and more useless.



          Still, the designers of the EGA and VGA had expected that the ability to update multiple bytes at once would be useful, and thus designed their architecture to facilitate it.






          share|improve this answer













          The VGA design is inherited directly from the EGA design, though with a few extra features. Most considerations apply equally to both.



          Although it is possible to treat the EGA or VGA memory as four banks of 65,536 octets, the EGA was designed to let it be treated more usefully as 65,536 groups of four octets, where each group had a single assigned CPU address. Within each group of eight pixels, each pixel would use one bit taken from each octet. The EGA and VGA have a 32-bit buffer that gets loaded from all four groups of pixels whenever an address is read, and each write will store to each group of 32 pixels a pattern which is based upon the value written, the value of some configuration and parameter registers, and the contents of the buffer.



          This made it possible to perform many kinds of read-modify-write operations on a group of pixels at a time. The CPU would read a byte, ignore the result, and then write a value that indicated how the group of bytes should be modified. The display card would then combine the value in the buffer with the value that was read and store the modified result to all 32 bits. This allowed for bytes in display memory to be updated with a single read-modify-write sequence.



          Alas, a couple aspects made this design far less useful than it could have been. They largely boil down to the fact that for various technical reasons, reading display memory is extremely slow, and every action on a group of 32 pixels would require four individual read-write sequences. If the computer had enough "main" RAM to maintain a copy of the screen, building the display contents in RAM and blindly outputting to the display would almost always be faster than trying to use the display's hardware to expedite the process. On slow machines the display hardware could offer some speed advantage, but as main-CPU speed increased the extra display hardware became more and more useless.



          Still, the designers of the EGA and VGA had expected that the ability to update multiple bytes at once would be useful, and thus designed their architecture to facilitate it.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jun 5 at 15:57









          supercatsupercat

          9,2801245




          9,2801245





















              6














              When VGA was designed and released, it had only maximum of 256 kbytes of video memory. The memory of VGA is arranged to have 32-bit interface to the VGA chip to have four byte planes in parallel. Therefore there are only 64k addresses of 32-bit video memory, and data of up to four planes can be accessed with a single CPU access.



              The VGA board can be configured for a 128k framebuffer at A0000h, but both 64k segments will access the 64k addresses of video RAM identically. The trick that makes standard Mode 13h look linear is implemented in hardware, it only uses every fourth address of video memory, and automatically selects the plane based on lowest 2 CPU addresses. Unchained modes need manual plane selection in software when writing to video memory. It would have taken extra logic to make the whole video memory look like linear, and this was just not so important as it already was quite complex and it was enough make it compatible with EGA.



              So in short, the VGA hardware is made to have four bytes accessible via single CPU address so there are only 64k memory addresses the CPU can access.






              share|improve this answer



























                6














                When VGA was designed and released, it had only maximum of 256 kbytes of video memory. The memory of VGA is arranged to have 32-bit interface to the VGA chip to have four byte planes in parallel. Therefore there are only 64k addresses of 32-bit video memory, and data of up to four planes can be accessed with a single CPU access.



                The VGA board can be configured for a 128k framebuffer at A0000h, but both 64k segments will access the 64k addresses of video RAM identically. The trick that makes standard Mode 13h look linear is implemented in hardware, it only uses every fourth address of video memory, and automatically selects the plane based on lowest 2 CPU addresses. Unchained modes need manual plane selection in software when writing to video memory. It would have taken extra logic to make the whole video memory look like linear, and this was just not so important as it already was quite complex and it was enough make it compatible with EGA.



                So in short, the VGA hardware is made to have four bytes accessible via single CPU address so there are only 64k memory addresses the CPU can access.






                share|improve this answer

























                  6












                  6








                  6







                  When VGA was designed and released, it had only maximum of 256 kbytes of video memory. The memory of VGA is arranged to have 32-bit interface to the VGA chip to have four byte planes in parallel. Therefore there are only 64k addresses of 32-bit video memory, and data of up to four planes can be accessed with a single CPU access.



                  The VGA board can be configured for a 128k framebuffer at A0000h, but both 64k segments will access the 64k addresses of video RAM identically. The trick that makes standard Mode 13h look linear is implemented in hardware, it only uses every fourth address of video memory, and automatically selects the plane based on lowest 2 CPU addresses. Unchained modes need manual plane selection in software when writing to video memory. It would have taken extra logic to make the whole video memory look like linear, and this was just not so important as it already was quite complex and it was enough make it compatible with EGA.



                  So in short, the VGA hardware is made to have four bytes accessible via single CPU address so there are only 64k memory addresses the CPU can access.






                  share|improve this answer













                  When VGA was designed and released, it had only maximum of 256 kbytes of video memory. The memory of VGA is arranged to have 32-bit interface to the VGA chip to have four byte planes in parallel. Therefore there are only 64k addresses of 32-bit video memory, and data of up to four planes can be accessed with a single CPU access.



                  The VGA board can be configured for a 128k framebuffer at A0000h, but both 64k segments will access the 64k addresses of video RAM identically. The trick that makes standard Mode 13h look linear is implemented in hardware, it only uses every fourth address of video memory, and automatically selects the plane based on lowest 2 CPU addresses. Unchained modes need manual plane selection in software when writing to video memory. It would have taken extra logic to make the whole video memory look like linear, and this was just not so important as it already was quite complex and it was enough make it compatible with EGA.



                  So in short, the VGA hardware is made to have four bytes accessible via single CPU address so there are only 64k memory addresses the CPU can access.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jun 5 at 6:23









                  JustmeJustme

                  1,034310




                  1,034310





















                      3














                      In the 16-bit 8086, addressing of the memory space was done with a two-register pair Segment:Offset. The Segment register (there were four of them) addressed the high 16 bits of the 20-bit addressable memory, and the Offset register addressed the low 16 bits. So The effective address was computed in the CPU by:



                      EA = 16 * Segment + Offset


                      So, in order to address more than 64k of memory at once, software would have to change the segment register as well as the offset. This was very inefficient in the CPU, and it was much better to limit memory block access to 64k at a time. The video card designers recognized this, and built the hardware with bank switching so that software would not have to change the CPU segment register to address the whole display memory.






                      share|improve this answer























                      • Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                        – tuomas
                        Jun 4 at 21:26






                      • 1





                        @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                        – Greg Hewgill
                        Jun 4 at 21:47






                      • 1





                        Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                        – Stephen Kitt
                        Jun 4 at 21:49






                      • 4





                        Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                        – Leo B.
                        Jun 4 at 22:06






                      • 1





                        Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                        – Raffzahn
                        Jun 4 at 22:22















                      3














                      In the 16-bit 8086, addressing of the memory space was done with a two-register pair Segment:Offset. The Segment register (there were four of them) addressed the high 16 bits of the 20-bit addressable memory, and the Offset register addressed the low 16 bits. So The effective address was computed in the CPU by:



                      EA = 16 * Segment + Offset


                      So, in order to address more than 64k of memory at once, software would have to change the segment register as well as the offset. This was very inefficient in the CPU, and it was much better to limit memory block access to 64k at a time. The video card designers recognized this, and built the hardware with bank switching so that software would not have to change the CPU segment register to address the whole display memory.






                      share|improve this answer























                      • Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                        – tuomas
                        Jun 4 at 21:26






                      • 1





                        @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                        – Greg Hewgill
                        Jun 4 at 21:47






                      • 1





                        Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                        – Stephen Kitt
                        Jun 4 at 21:49






                      • 4





                        Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                        – Leo B.
                        Jun 4 at 22:06






                      • 1





                        Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                        – Raffzahn
                        Jun 4 at 22:22













                      3












                      3








                      3







                      In the 16-bit 8086, addressing of the memory space was done with a two-register pair Segment:Offset. The Segment register (there were four of them) addressed the high 16 bits of the 20-bit addressable memory, and the Offset register addressed the low 16 bits. So The effective address was computed in the CPU by:



                      EA = 16 * Segment + Offset


                      So, in order to address more than 64k of memory at once, software would have to change the segment register as well as the offset. This was very inefficient in the CPU, and it was much better to limit memory block access to 64k at a time. The video card designers recognized this, and built the hardware with bank switching so that software would not have to change the CPU segment register to address the whole display memory.






                      share|improve this answer













                      In the 16-bit 8086, addressing of the memory space was done with a two-register pair Segment:Offset. The Segment register (there were four of them) addressed the high 16 bits of the 20-bit addressable memory, and the Offset register addressed the low 16 bits. So The effective address was computed in the CPU by:



                      EA = 16 * Segment + Offset


                      So, in order to address more than 64k of memory at once, software would have to change the segment register as well as the offset. This was very inefficient in the CPU, and it was much better to limit memory block access to 64k at a time. The video card designers recognized this, and built the hardware with bank switching so that software would not have to change the CPU segment register to address the whole display memory.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jun 4 at 21:20









                      Greg HewgillGreg Hewgill

                      2,3591315




                      2,3591315












                      • Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                        – tuomas
                        Jun 4 at 21:26






                      • 1





                        @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                        – Greg Hewgill
                        Jun 4 at 21:47






                      • 1





                        Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                        – Stephen Kitt
                        Jun 4 at 21:49






                      • 4





                        Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                        – Leo B.
                        Jun 4 at 22:06






                      • 1





                        Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                        – Raffzahn
                        Jun 4 at 22:22

















                      • Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                        – tuomas
                        Jun 4 at 21:26






                      • 1





                        @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                        – Greg Hewgill
                        Jun 4 at 21:47






                      • 1





                        Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                        – Stephen Kitt
                        Jun 4 at 21:49






                      • 4





                        Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                        – Leo B.
                        Jun 4 at 22:06






                      • 1





                        Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                        – Raffzahn
                        Jun 4 at 22:22
















                      Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                      – tuomas
                      Jun 4 at 21:26





                      Do you have a source for this? I don’t recall MOV reg to seg being really slow on 8088. Quick lookup around internets says it was 2 cycles, same as any MOV between registers. I could imagine it being a bit slower on 286+ with all the segment descriptor magic happening behind the scenes.

                      – tuomas
                      Jun 4 at 21:26




                      1




                      1





                      @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                      – Greg Hewgill
                      Jun 4 at 21:47





                      @tuomas: Just thought of another reason - it was possible to have multiple display adapters in the same machine simultaneously, so you could (for example) debug a game by running the game on the VGA and the debugger interface on a separate monochrome screen.

                      – Greg Hewgill
                      Jun 4 at 21:47




                      1




                      1





                      Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                      – Stephen Kitt
                      Jun 4 at 21:49





                      Programs which would benefit from a larger framebuffer would be manipulating more than 64K of data anyway, so I doubt the pointer arithmetic is a factor. In any case segment loading is faster than bank switching.

                      – Stephen Kitt
                      Jun 4 at 21:49




                      4




                      4





                      Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                      – Leo B.
                      Jun 4 at 22:06





                      Setting up DS and ES appropriately, then using a segment override prefix and a conditional jump over it solves the problem of addressing more than 64k at a time with minimal code bloat.

                      – Leo B.
                      Jun 4 at 22:06




                      1




                      1





                      Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                      – Raffzahn
                      Jun 4 at 22:22





                      Move between segment register and 16 bit register was always 2 clocks (3 on a 486 and up to 12 or so on a Pentium). From memory somewhat slower (12 on 8088 5 on 286). It only got terrible slow with virtual addressing on a 286.

                      – Raffzahn
                      Jun 4 at 22:22










                      tuomas is a new contributor. Be nice, and check out our Code of Conduct.









                      draft saved

                      draft discarded


















                      tuomas is a new contributor. Be nice, and check out our Code of Conduct.












                      tuomas is a new contributor. Be nice, and check out our Code of Conduct.











                      tuomas is a new contributor. Be nice, and check out our Code of Conduct.














                      Thanks for contributing an answer to Retrocomputing Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11234%2fwhy-vga-framebuffer-was-limited-to-64kb-window%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Get product attribute by attribute group code in magento 2get product attribute by product attribute group in magento 2Magento 2 Log Bundle Product Data in List Page?How to get all product attribute of a attribute group of Default attribute set?Magento 2.1 Create a filter in the product grid by new attributeMagento 2 : Get Product Attribute values By GroupMagento 2 How to get all existing values for one attributeMagento 2 get custom attribute of a single product inside a pluginMagento 2.3 How to get all the Multi Source Inventory (MSI) locations collection in custom module?Magento2: how to develop rest API to get new productsGet product attribute by attribute group code ( [attribute_group_code] ) in magento 2

                      Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

                      Magento 2.3: How do i solve this, Not registered handle, on custom form?How can i rewrite TierPrice Block in Magento2magento 2 captcha not rendering if I override layout xmlmain.CRITICAL: Plugin class doesn't existMagento 2 : Problem while adding custom button order view page?Magento 2.2.5: Overriding Admin Controller sales/orderMagento 2.2.5: Add, Update and Delete existing products Custom OptionsMagento 2.3 : File Upload issue in UI Component FormMagento2 Not registered handleHow to configured Form Builder Js in my custom magento 2.3.0 module?Magento 2.3. How to create image upload field in an admin form