AT互換機でのメモリマップ

  • PCIデバイスとかPCカードとかを使うときに、空いている空間を確認したいこともあるだろうということで・・・
  • 0x00000000 - 0x0009ffff : RAM
    • AT互換機では、この部分がフル実装されていないものはない? -- ATになったのって、286マシンからでしたっけ?(こめんと欄参照)
  • 0x000a0000 - 0x000bffff : ビデオアクセス用アドレス空間
  • 0x000c0000 - 0x000c7fff : ビデオBIOS?
  • 0x000c8000 - 0x000dffff : 各種カードのROMがあったりなかったり?
    • 0x000d0000 - 0x000dffffはたいてい空いている
  • 0x000e0000 - 0x000effff : 拡張BIOS(ここが空いている場合もある?)
  • 0x000f0000 - 0x000fffff : BIOS
  • 0x00100000 - 0x00efffff : RAM (これに満たない可能性もある)
  • 0x00f00000 - 0x00ffffff : RAMもしくはISAホール(どちらになるかはBIOSの設定などによる)
    • 286の場合は、0x00fffff0からの16バイトにリセットジャンプ命令もあると思われる
  • 0x01000000 - メモリが尽きるまで : RAM
  • メモリが尽きたところ - 0xffffffef : PCIデバイスなどのメモリマップトI/Oに利用可能な領域
    • やっぱり0xfffff000からはBIOSのミラーがあって、利用できないのかな?
  • 0xfffffff0 - 0xffffffff : 386以降ではここにリセットジャンプ命令がある

ソフトウェア的用途区分

  • 0x00000000 - 0x000003ff : リアルモード用INTベクタ
    • もちろんこれはIDTを変更すれば変更できるが、とりあえず標準的にはこのアドレスが使われる。
    • 0x00000300 - 0x000003ffはBIOS用スタック?
  • 0x00000400 - 0x000004ff : BIOS用ワークエリア?
  • 0x00007c00 - 0x00007dff : ブートセクタが読み込まれるアドレス
  • 0x0009fc00 - 0x0009ffff : ACPI用ワークエリア(の場合がある)
    • 0x0009fc00から始まっているという保障は全くない。本来ならBIOSに問い合わせるべき。個人的には最悪でも0x0009efffまでは勝手に使っても平気なんじゃないかと思ってはいる。--K
    • っていうか、僕はこれを無視してこの辺を好き勝手に使っているような気が・・・。大丈夫なのか?OSASK!
  • ISAホールがなければ、16bit-PCICで利用可能なメモリ領域は、0x000c8000~0x000dffffのどこかになるでしょう。

こめんと欄

  • DOS/Vマシンでは640kb搭載を期待してOKです。 真のPC/ATはフル実装されていないことも有ります。→http://www.funkygoods.com/mb/pc_at_fl/pc_at_fl.htm -- .mjt 2003-07-12 (土) 17:58:12
  • 最近の機種は640KBの最後がACPI等のワークになってるので要注意 -- 2003-07-12 (土) 18:18:10
  • さっそくのコメントをありがとうございます! -- K 2003-07-12 (土) 19:04:59
  • このワークってだいたい何バイトくらいなのでしょうか?1KB?4KB?64KBくらい???・・・目安というか、上限が知りたいなあと(下限は0バイトです)。 -- K 2003-07-12 (土) 20:26:25
  • 上限はBIOSから取得するしか・・・以前調べた時は1KB程度だった記憶があります。 -- 2003-07-13 (日) 03:48:31
  • 情報ありがとうございます。 -- K 2003-07-13 (日) 11:44:52
  • Linuxのbootsect.Sを見ると, 512Kしかローメモリのないシステムもありうるのでint 0x12で確認しようとか書いてありますよ。 -- I.Tak.? 2003-07-18 (金) 19:17:49
  • 0x000CC000 - 0x000CCFFF 4KB Intel EtherカードのPXE BIOSが使っていました。 -- not-a? 2004-02-13 (金) 18:40:50
  • メモリを汚さずに正確なメモリサイズを測定するのはこれでできるのかな?(Windows NT DDK用だがinp,outpを使用しているので他のプラットフォームでも使用できると思われる…DumpBaseMemory/DumpExtendedMemory参照) http://www.windowsitlibrary.com/Content/356/10/2.html -- 名無しさん 2004-09-16 (木) 17:24:35
  • それは非常に古い方法で、拡張メモリが最大64MBまでしか認識できないという問題があります。 -- K 2004-09-16 (木) 20:31:41
  • 最近のPCでは、拡張BIOSワークの位置は0040h:000Chに書いてあります。(BIOSコールでメモリサイズをとるのが正しいやり方ですが) -- 名無しさん 2004-10-17 (日) 23:27:51
  • ↑0040h:000Ehの間違いです。 -- 名無しさん 2004-10-17 (日) 23:28:35
  • 拡張BIOSワークのサイズは拡張BIOSワークの先頭に書いてあります。 -- 名無しさん 2004-10-17 (日) 23:32:51
  • 386以降ではリセットした瞬間にA20マスクが外れて0xfffffff0から制御を始めるとの理解でよいでしょうか。 -- 名無しさん 2005-05-29 (日) 09:36:21
  • いえ、リセットするとA20GATEが復活します。それで、CPUは0xfffffff0をアクセスしているつもりになっていますが、実際のアドレスは0x000ffff0になっていると思います。ここはBIOSのミラーなので、全く同じリセットジャンプ命令があります。 -- K 2005-06-01 (水) 02:43:06
  • 0x9fc00-0x9ffff(というか、0x40e-0x40fが指定するセグメント)を使うのはやめたほうが良いですよ。最近拡張されたBIOS(ATA、APM、ACPI、MP等)がここを使うことが多いです。 -- 名無しさん 2005-06-03 (金) 20:58:10
  • 表形式でメモリーマップ書いてみました。 -- satoshiokita? 2006-04-17 (月) 14:54:09
  • myメモ。[アドレス幅] ram/640k, vram/128k, Vbios/32k, rom/96k, eBios/64k, bios/64k, ram/64k -- pen 2006-04-18 (火) 08:14:35
  • あれ、ramの所の 0x00efffff って一桁少ない? -- pen 2006-04-18 (火) 08:17:29
  • ram/14M・・か。 -- 名無しさん 2006-04-18 (火) 08:24:38
  • コンベンショナルメモリ(640KB)の最後の1KB(0x9fc00-0x9ffff)が拡張BIOSワークエリアに割り当てられているか確認できるっぽい四つの手段。 1)int 0x12 の結果が639KBとなる。 2)0x040eからの1wordが0x9fc0である。 3)int 0x15 AH=0xC1が成功しESに0x9fc0が入る。 4)int 0x15 AX=0xE820 が成功し0x9fc00-0x9ffffを予約領域と認識する。 -- 名無しさん 2006-06-15 (木) 14:22:50
  • Wikipediaの「XMS」の項によると、ROMの刺さっていない箇所に、ページングを使わず物理的にRAMを出現させる方法があるとのこと。どこかに詳細な資料は無いでしょうか。 -- 名無しさん 2006-06-15 (木) 15:16:12
  • ACPIのワークサイズ取得はint 0x15を使ったほうが楽。アドレスとサイズが使用禁止の場所も含めて取得できます。 -- skyblue 2012-07-26 (木) 19:14:55
  • Sun VB で確認したところ1GB~3GBまで1GB単位で確認したところ、0x9fc00まではRAMとして認識していました。 4MBから2倍単位でも同様に認識していました。 確認方法はINT 15h AX=E820のACPIファンクションコールで確認しました。 -- skyblue 2012-10-09 (火) 20:03:21
  • 0xe0000からVRAM領域であることをqemuで確認 -- skyblue 2014-01-16 (木) 10:08:51

コメントお名前NameLink

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2014-09-05 (金) 11:42:47 (1755d)