Talk:Conventional memory

message: I've removed this passage:
::# Note that it is neither a limitation of the PC nor of MS-DOS itself, but only the combination of the two. Non-DOS operating systems such as Xenix and Netware did not suffer from the restriction, nor did MS-DOS running on Non-PC compatible X86 computers. == == ==
It was very much a limitation of the pre-386 PC, if 'PC' is defined in this era as IBM systems using Intel chips.  The article itself acknowledges this point and this passage subsequently contradicts it. --Yst 23:46, 2 July 2006 (UTC)
replies: text: I agree with what you say, but am guessing there was some glimmer of truth within that ill-written paragraph.  Maybe it was that Xenix, Netware, and on some machines, MSDOS could use 1 MB instead of 640K.  Or maybe it was that on 286s some of these could use 16MB (maybe only by VM swapping or something).  I imagine that no OS used 16MB on 286s for normal memory since the 286 architecture was so amazingly broken in this respect. -R. S. Shaw 22:15, 4 July 2006 (UTC)
replies: text: MS-DOS could use 1 mB of RAM on 8088's, but it required some serious hacking (and soldering on the motherboard) to do so.  I don't believe XENIX could use any more than DOS could, simply because it was 100% a hardware problem.  I know for a fact that MS-DOS can address much more than 640K, but it can't on an 8088 because of a hardware limitation.  And yes, Windows/286 could address 16MB as it was specifically designed FOR the 80286.  --AndreniW 02:34, 5 July 2006 (UTC)
thread_title: Removed

message: Shouldn't this: 1024 KiB of memory (220 bytes) read: 1024 KiB of memory (210 bytes)? Unless I've got it all wrong. Please clarify. -- Ynhockey (Talk) 22:22, 28 April 2007 (UTC)
replies: text: No, because 1 KiB = 1024 (or 210) bytes, and so 1024 Kib = 1024×1024 bytes or 220 bytes. -R. S. Shaw 05:20, 29 April 2007 (UTC)
thread_title:  Confused 

message: Considering the low acceptance of the "binary prefixes" within the industry, and their general unfamiliarity outside of it, I propose reverting the March 6th change of units.  Opposing views? Cnj 19:26, 25 June 2007 (UTC)
replies: text: I've spent the last couple days reading the articles on Intel's past microprocessors and I agree that the binary prefixes should be changed to the more-familiar SI prefixes.  I've been dabbling with computers since 1980 and majored in computer science in college, yet this is the first place I've ever seen the binary prefixes used.  Granted, they may be more accurate, but from what I've seen these articles are directed to the general reader and therefore should be kept as clear as possible.  Using the SI prefixes would mean a couple less articles people would have to read and the inaccuracy is only about seven percent at the GB level. KadrianBlackwolf 04:55, 28 June 2007 (UTC)
thread_title:  Unit Prefix 

message: Isn't this a Unix utility? 130.101.100.100 12:39, 24 September 2007 (UTC)
thread_title:  Setty 

message: The main reason for the 640kb barrier was the need to preserve functionality of legacy code. Linux has no such barrier since it has no need to preserve space for legacy software.
Microsoft spent years trying to break Windows of its 640k legacy code, but it lingered on as device drivers (MSCDEX, DOSKEY, SCSI board drivers, etc) with Win 3.1, Win 95, Win 98 and Win ME. I believe Windows NT was really the first Microsoft OS to break away from the 640k barrier. Of course many old programs would not work under NT, but oh well.
DMahalko (talk) 23:26, 31 December 2007 (UTC)
replies: text:  Wrong. I started with Minix and Linux .91 kernel which still used PC ROM BIOS calls e.g. Interrupt 10 for console screens. Non x86 like Alpha, MIPS, and Power PC systems used ARC ("Advanced RISC Computing") architecture that emulated PC BIOS on boot. Itanium sucked so Intel came up with EFI to avoid using 16bit x86 instructions on boot: x86 16bit boot code had to in first 1MB of memory. The 640K hardware limit is due to Video Card memory space being placed at 640K plus for ISA compatibility (which also limits dual monitor capability). Not all, but most newer video cards use PCI memoryspace. Amazingly many brand new motherboards include Floppy and IDE interfaces which require 8-bit DMA buffers in first 1MB of memory. And last I checked, most Linux distributions use an ISA (1982 standard) compatible boot loader from disk startup sector. (There are loaders that boot directly to 32-bit mode. Some x64 Linux distros do include those.) Shjacks45 (talk) 16:33, 16 March 2012 (UTC)
thread_title:  Should mention linux and other non-DOS operating systems 

message: Am I right in saying that the DOSBox emulator overcomes the limits of conventional memory for old programs which need it?  Maybe the Conventional memory page should mention DOSBox?  A possible ref link here. TurboForce (talk) 18:01, 7 February 2011 (UTC)
thread_title:  DOSBox and conventional memory 

message: Aside from 64K 8088 segments, the reason for 64k blocks was that one row of 9 DRAM chips made 64 kB, in those days. Once 256K and 1M DRAMs becamse cheaper, it becamse awkward to part out memory in 64 K chunks - one (pair of) SIMMs contained the whole memory space in the processor, so part of the DRAM you'd bought was not accessible because it was overlain by the ROM and video memory, etc. ( If I can find a reference for this I can work it into the article, if no-one beats me to it).  (Did any 8088 machine use SIMMs or were tehy commercially extinct by the time the SIMM came along?) --Wtshymanski (talk) 16:29, 2 May 2011 (UTC)
replies: text: Original C compilers used 16-bit pointers or 64K segments.  A 16-bit CPU register represented 65536 or 64K. On boot, the Program Segment Register was (hexadecimal) FFFF and the Instruction Pointer was 0000 added (pointer offset left by 4 bits) to make FFFF0 which was the first instruction executed on startup (usually a long jump instruction to the beginning of BIOS ROM. It was easier to make symmetrical silicon in those days and chips also cost per pin so addresses were multiplexed: 7 rows by 7 columns gave 2^14 or 16K bits; 8 X 8 = 2^16 or 64K bits; 9 X 9 = 2^18 or 256K bits. Note that the ORIGINAL IBM PC came with 16KB of RAM. See IBM Personal Computer. Shjacks45 (talk) 19:36, 16 March 2012 (UTC)
thread_title: Wasn't supposed to last for 30 years

message: I put some hidden comments about BIOS interrupt 15 as noted in http://support.microsoft.com/kb/91088, and http://support.microsoft.com/kb/95555 information is also useful but link to "Extended Memory Specification Version 3.0" is broken. Windows Himem.sys info at http://support.microsoft.com/kb/89697 for Win3. Also reference Andrew Shulman's "Unauthorized Windows 95" Novell's Knowledgebase re Netware not starting after himem.sys loaded and numerous Linux and BSD wikis. Also see http://support.microsoft.com/kb/86018 for corrections to VCPI and DPMI support in Windows 3.1. (ftp://ftp.microsoft.com/misc1/PEROPSYS/WINDOWS/KB/Q83/3/99.TXT.) Text picture in http://support.microsoft.com/kb/37242 shows memory locations.
The Himem.sys supporting Windows 3.1 V86mgr (Virtual Machine Manager) and Microsoft stance against using Digital Research DOS was an important feature of the Department of Justice AntiTrust Lawsuit aginst Microsoft.
Shjacks45 (talk) 16:00, 16 March 2012 (UTC)
thread_title:  XMS Basis 

message: The correct unit for kilobyte that is being referred to here is "kB" and not "KB".  — Preceding unsigned comment added by Hofniser (talk • contribs) 19:29, 9 May 2017 (UTC)
thread_title:  Incorrect use of the kilobyte unit