BIOSによる表示

Question

こんばんわ。お世話になります。
今, 自分はフロッピーをさした状態でPCの電源を入れるとそのフロッピーに格納されているプログラムが動くようにしたいと思っています。
その手始めとして, 文字を表示させたいのですが, どうもよくわかりません。
今までに自分は
mov ah,0
mov al,03
int 10h
で画面設定をし, 
mov ax,b800
mov es,ax
mov di,0
mov byte ptr es:[di],41
mov ax,ff00
int 10h
hlt
なんてアセンブラを書きましたがwindows付属のdebugではこれはコンパイルできません。コンパイルできたと仮定して, これをrawriteでフロッピーに書き込むつもりです。
現在, 私のもとにある最も簡単なアセンブラはdebugです。nasmもありますが, 不勉強のため 使い方が良くわかりません。
有効なソースをお教えください。よろしくお願いします。

anisol · Accepted Answer

funi2さんのユーザ情報を拝見させていただいたところ、かなりコンピュータに詳しい方のようですね。以下の回答は釈迦に説法かもしれませんが、御了承を。

DOS/VのINT 10Hについて私も調べてみました（参考URL1）。funi2さんは擬似テキストバッファへの書き込みを行っていたようですが、そのアドレスが正しく設定されていないことが問題だったようです。AH=FEHでアドレス取得すると正しく表示できます。

■例1.
0100 MOV AH,00 ;ビデオモード設定                              
0102 MOV AL,03 ;テキストモード 80×25                             
0104 INT 10                                 
0106 MOV AX,B800                            
0109 MOV ES,AX                              
010B MOV DI,0000                            
010E MOV AH,FE ;擬似テキストバッファ先頭アドレス取得
0110 INT 10                                 
0112 MOV CX,0001 ;再描画文字数                            
0115 ES:                                   
0116 MOV BYTE PTR [DI],41                   
0119 MOV AH,FF ;画面表示の更新                              
011B INT 10                                 
011D HLT                                   
011E JMP 011D ;念のため（外部割込みなどでHLTから抜けることがあるため）


文字列の表示はAH=1301Hでできます。
■例2.
0100 MOV AH,00                              
0102 MOV AL,03                              
0104 INT 10                                 
0106 MOV DL,00 ;書き込む桁位置                              
0108 MOV DH,00 ;書き込む行位置                        
010A MOV BL,07 ;属性　背景黒、文字灰色                             
010C MOV BH,00 ;ページ番号                             
010E MOV CX,0008 ;文字数                           
0111 MOV AX,CS                              
0113 MOV ES,AX ;ES←CS, ESは文字列のあるセグメント
0115 MOV BP,0120 ;文字列のアドレス、絶対アドレス
0118 MOV AX,1301 ;カーソル移動をともなう文字列表示
011B INT 10                                 
011D HLT                                    
011E JMP 011D                               
0120 DB 'piyopiyo'                               

・フロッピーへの書き込みをしなくても、debug上でテスト実行ができます。例2.ではg=100,11dとします（gはgoコマンド）。g=xxxx,yyyyでxxxxは実行開始アドレス、yyyyはブレークポイント（ブレークポイントの命令は実行されない）。
・debugではラベルが使えないため、アドレス指定は絶対アドレスになることに御注意。またu（unassemble, 逆アセンブル）コマンドが便利です。
・lighteningさんの御指摘「ブート時にBIOSコールは使えます」ありがとうございます。なおdebugではcomモデルしか書き込めず、exe2binは必要ありません。
・先の私の回答で、書きこみバイト数の指定をcxだけで行いましたが、bxで書き込みセグメント長が指定されます。bxを0000にすることをお忘れなく。
・すでにご存知かもしれませんが、"bootable hello world program"として参考URL2のソースコードが参考になります、アセンブラの表記がdebugと異なることに注意してください。

実は私のパソコンは情けないことにフロッピードライブがないため、ブート時の実験はできません。すみません。

参考URL1.
DOS/V INT 10h 私的 REFERENCE
http://hp.vector.co.jp/authors/VA003720/lpproj/int10h/int10h.htm

参考URL2.
Unios
http://www.netspace.net.au/~gok/resources/

参考URL：http://hp.vector.co.jp/authors/VA003720/lpproj/int10h/int10h.htm, http://www.netspace.net.au/~gok/resources/

anisol · Answer

今時アセンブラに興味を持ってくれる人がいるなんて、私はうれしい、ほんとに感激です。

このプログラムはdebugでアセンブルはできるはずですよ。debugで a と入力し、次のように打ち込んでみてください。

mov ah,0
mov al,03
int 10
mov ax,b800
mov es,ax
mov di,0
es:
mov byte ptr[di],41
mov ax,ff00
int 10
hlt

debugでは数値は暗黙のうちに16進数です。また es: などのセグメントオーバーライドは分けて入力します。入力し終わったら、rcxでレジスタcxを変更して100（書き込みバイト数256byte）にし、nfilename.com（nはnameコマンド）とファイル名を入力した後、wで書きこんでください。DOSモードでfilenameが実行できたらしめたものですが。

でも、これをフロッピーのブート領域に書きこんでも実行できるかどうか…。BIOSは起動後、フロッピーのブート領域（多分0トラックの第1セクタ）から「ローダ」（loader）というプログラムをまず読み込みます。ローダはコンピュータの初期設定などを行い、MS-DOSのプログラムを読み込んでメモリに割り振った後、MS-DOSに実行を移します。これで初めてMS-DOSのシステムコールやBIOSコールがまともに使える状態になるので、必要な準備が整っていないローダの段階でBIOSコールがうまく使えるかはわかりません。

また、悲しいかな私はPC-9801のハード、BIOSの知識しかありません。int 10はDOS/Vパソコンでどんな意味を持つのか知らないので、このプログラムが正しいかわかりません、ごめんなさい。できるだけ助力はしたいのですが…。

lightening · Answer

「IBM PC & DOS/V 活用ハンドブック」（CQ出版社）という本にブートストラップローダのサンプルが載っています。
かなり古い本なので手に入るかどうか分かりませんが。

補足としては
　・COMモデルの形式で作成、EXE2BINを通さないといけないようです。
　・ブート時にBIOSコールは使えます。

それにしても懐かしい話題で私も感激です。

igmp · Answer

No.1である程度解決しているようですし、既にご存知かとは思いますが
参考程度に一言。

DOS/V(IBM系)パソコンのBIOSコールでは、"int 10h"はVideo(表示関連)で、
"int 13h"がフロッピー、またはディスクとなっています。

anisol · Answer

暴走ですか…。大変でしたね。MS-DOSの時代は、アセンブラプログラムの暴走でリセットをかけることなどはいつものことでしたが、Windowsはかなり丈夫なので注意喚起することをすっかり忘れていました。

（例えばCLI（割り込み禁止）はWindows上のDOS窓では無視され、Ctrl+Alt+Delのキーボード割り込みは利いているし、割り込み禁止してからHLT命令をかけると一般保護例外になったり…。Windows98ではそうなるのですが、Windowsの種類によっては暴走に弱いかもしれません。funi2さんのお使いのWindowsは何でしょうか？）

全画面表示になってしまったら、まずAlt+Enterを試してみてください。暴走した場合は普通はCtrl+Cは利きません。Ctrl+Alt+Delを試してみて、利かなかったらやむを得ず電源断です。

プログラムは一応実行できることを確認してから、逆アセンブルしてできたソースファイルを載せたのですが、くれぐれも入力ミスや実行アドレスの間違いには御注意を。u100で逆アセンブルして確認するとよいと思います。

ローダの実行中はWindowsの管理下にないので、暴走したら電源断しか手段がありません。くれぐれも慎重に。うまくいくことを願っています。（本当は私がやってみたいのだが、安物パソコンゆえにフロッピードライブが…）

alfeim · Answer

直接そのプログラムとは関係ないのですが、Windows下でAssemblerを組む上での注意を・・・
Windows9x(Me含む)ではVxDのVMM(VirtualMachineManager)とVPIC(VirtualProgramableController)が動いており、マシンネイティブなリソースに直接アクセスする事はまず不可能です。
だいたいのアクセスにおいてVMMかVPICの仲介が入ります(VMMは仮想86マシンの管理、VPICは仮想割り込みコントローラです)。この仲介があるため、CLI命令はVPICにトラップされ、その命令を発行した仮想マシン内のみで無効になっていると思われます(それ以前にCPUがユーザモードで走っているでしょうから、単に無効命令としてトラップされているだけかもしれません)。
また、anisonさんがおっしゃったHLT命令は特権命令なのでユーザモードでは例外トラップされて実行できないはずです(そのため一般保護違反が発生する)。

このような理由があるため、上記質問のようなプログラムのテストはWindows下ではまともにテストできないとおもっておいた方がよいかとおもいます。なのでできればMS-DOSやPC-DOSのようなマシンリソースに直接アクセスできるOS(あれをOSと呼ぶのに抵抗がある人もいるでしょうけど(^^;)を利用する事をオススメします。MS(PC)-DOSかであればExtenderや仮想86モードを利用したプログラムが無い限り、マシンリソースに直接アクセスできますので。

anisol · Answer

CLI, HLTなどに関してはalfeimさんのおっしゃる通りだと思います。私の書き方が悪かったです。CLIについては昔のWindows（Windows 3.1？）では実行スピードを上げるため、あえて本当に割り込みが禁止されるという話を本で読んだことがあったので、あのような書き方をしました。HLTに関しては、Windows 98では「親切にも」一般保護例外のメッセージを出してくれる、というふうに書くべきでした。Windows 2000のDOS窓では単純にHLT命令は無視されるだけに対して、Windows 98ではCLIの後のHLTの時だけ一般保護例外で警告してくれることが親切（おせっかい？）に感じたもので。

また、funi2さんに誤解を与えたかもしれませんが、Windowsが暴走に強いというのは「DOS窓の中で暴走してもWindowsの機能自体には影響しない」という意味です。例えば無限ループをDOS窓で実行すると（先のプログラムのHLT, JMP 011Dのように）Ctrl+Alt+Delの強制終了でしか終了できませんが、他のプログラムには何も影響ないはずです。再度DOS窓を立ち上げてdebugを実行してもかまわないと思います。先ほどもめちゃくちゃなINTを実行したり、I/Oポートにでたらめな数値を書き込んだりしてみましたが、Windowsの機能には何も異常がなく、今メモ帳を使っています（ただし昔のWindowsとPC-9821の組み合わせではマウスの動きが変になったりする影響があった）。

ですからDOS窓のdebugで暴走した場合、強制終了を掛ければすぐにまた作業のやり直しができるので、簡単なプログラム（せいぜいBIOSコールを使う程度でI/Oポートはいじらない）ならWindowsのほうがデバッグしやすいと思うのですが…。ただし、Windows Meは特別ヤワなのかもしれません。

ハードに直接アクセスするような場合は、alfeimさんのおっしゃる通り、MS-DOSを使ったほうがやりやすいと思います。まあアセンブラはハードを直接いじれることが醍醐味のひとつでもあるので、Windowsの管理下のアセンブラは面白くない、とも言えるかもしれませんね。暴走もアセンブラの魅力です？

（追伸　piyopiyoの文字化けは解決されたでしょうか？心配です）

alfeim · Answer

>暴走することはあってもほかのwindowsのプロセスに影響を与えることはない。 
>DOS窓のプロセスをkillして, 再起動すれば元のように使えるようになる。 

についてですが9x(Me)ではユーザアプリケーション同士のメモリ保護は働きます
が、kernelのメモリ保護機能が無いため、暴走時にkernel空間のメモリを書き換えると暴走する可能性があります(このへんはNT/2000/Xpではちゃんと保護されている)。
というわけなんで、不味いときにはやっぱり固まります(^^;
(NT系でもリアルタイムOSではないのでユーザプロセスのプライオリティを高くして無限ループに突っ込ませれば固まってしまいますが・・・)

>DB 'a'とDB 41を比較してみたのですが， DB 'a'は61と書き込まれています。 
>DB 41はもちろん41と書き込まれています。No.4では41で見事にAと表示された

あってますよ？
小文字の'a'は0x61ですし大文字の'A'は0x41です(ASCIIコード時)
OS内からちゃんと表示できて、ブートローダから出来ないって事は初期化部分が不味いような気がします。手元にATに関する資料が無いのではっきりとした事が言えないですが・・・

>P.S. テスト用のマシンが欲しい...いちいちリブートするのは飽きた...

Virtual PC for Windowsなどの仮想AT互換機を用意してみるというのはどうでしょう？ちとお値段が張りますが(199ドル)ブートシステムから動作するので、ブートローダの実験も出来るはずです。これなら暴走しても仮想マシン内だけの問題なのでアプリケーションを終了させれば(理論上は)OSに問題はないはずです。

参考URL：http://www.zdnet.co.jp/news/0107/02/virtualpc.html

alfeim · Answer

や、別にVMWareでもいいんですけど、この前新しいVerの紹介見てたらどうもWindows9x/Meを土台に動くVerが見つからなかったので・・・
たしか以前のVerではあったとおもったのですが・・・

あ。名前にだまされた(笑)
VMware for Windows NT and Windows 2000
なんて名前だからてっきりHostOSがこれだけかと思ってしまった(^^;
昔は9xにも対応してたはずなのにと思ったんですが(^^;

LinuxではVMWare Expressがありますね。
こっちの方が安いようです。動作速度はどれくらいなのか見た事無いので知らないですが・・・Windows版の方は知り合いがCeleron 300(Aでない方)に目盛り256MBで使っていたのを見た事がありますが、結構な速度で動いていました。フルスクリーンにすればPen100程度の速度ぐらいはあったようです。
#新VerではDirectXのサポートはどうなっているんだろう？

>リアルタイムOS
fnui2さんのおっしゃってるのは「プリエンプティブマルチタスク」の事ではないでしょうか？
プリエンプティブマルチタスクではタイマを利用して実行プロセスを切り替えます。たとえプロセスが暴走していようが、while(1)；であろうと関係ありません。
それに対してノンプリエンプティブマルチタスクではタイマによる切り替えではなく、各プロセスが自発的に制御をOSに返すまで実行権を握る事が出来ます。ようするに一つのプロセスが暴走すればOSが固まってしまうOSがそうです(ex. Windows　3.x、MacOS 9など)
それに対してリアルタイムOSというのは一部のイベント(だいたいは割り込みですね)に対して「一定時間以内に処理を完了し実行権をOSに返す」事が出来るOSです。たとえば工業機械のロボットのように暴走した場合、人命に関わるような装置の場合、強制停止ボタンがついてるのが普通ですが、これがリアルタイムOSでなかった場合、強制停止ボタンを押しても「OSがビジーです・・・(略)」とか言って装置が止まらなかった場合、とんでもない事になる事はわかりますよね？
当然こういう場合、装置は決められた時間内に停止する事が求められるわけで、こういう分野でリアルタイムOSが利用されます。
また、これらのOSはほとんどが一つのOSにしめられています。
それはTRONの工業規格版であるiTRONと呼ばれる製品が利用されており、我々の廻りにあるほとんどの工業製品でOSが必要なものはこれで動いているはずです。

>Xが起動しない
それはご愁傷様です(^^;
うちのビデオカードもマイナー所(3DLabs Oxygen VX1)なので以前BeOS試したら見事にモノクロ画面でした(^^;
Xを使いたい、というだけであればWindows下でも動きますよ

＞いや, 本当はlinuxとかFreeBSD使いたいんですよ。 
私の場合、UNIX系のCUIシステムは利用したいが、GNOMEは重いので嫌(笑)、という結果、Cygwin環境によってほとんどUNIX on Windowsな環境になってしまいました(笑)(上記URL参照)。

anisol · Answer

こんにちは。
alfeimさんの御指摘「Windows 9xではカーネルのメモリ保護機能が働かない」にはびっくりしました。これではOSとは言えないような気が…。Windowsが馬鹿にされる理由がよくわかりました。また、割込み禁止して無限ループに入れるとWindows 98は固まってしまうことが判明。もうちょっとタフと思っていたのですが…。いろいろ勉強になりました。

piyopiyoの文字化けの件、お騒がせしました。アドレスの問題をすっかり忘れていました。comモデルでは0100番地からプログラムが配置され、0000～00FF番地まではMS-DOSの作業領域（PSP, Program Segment Prefix）として使われます。

ところで、ちょっと気になったのはdebugで最初にCSレジスタを07B0に設定していることです。こうするとa100で07B0:0100番地から書き込みされることになります。DOS窓では問題ないかもしれませんが、MS-DOSではここはMS-DOSのシステムが置かれている可能性があり、書き込み中に暴走する恐れがあります。debugを起動したときに設定されるCSが空きメモリを示しているので、CSは変更する必要はないです。comファイルは書き込んだプログラムのセグメントの情報は入っていません。

BXは書き込みセグメント長を指定します。つまり BX*10H+CX が書き込むバイト数になります。debug起動時にはBX=0000となっていますが、gコマンドで何か実行した場合、BXレジスタが変更される可能性があるため、設定しなおす必要があります。なお、rコマンドで表示・変更されるレジスタはもちろん現在のCPUのレジスタではなく、gコマンドでプログラムを実行するときに代入されるものです。もうひとつ、CXはCS:0100からの書き込みバイト数なので、例えば012B番地まで書き込みたいときはCXを002BとすればOKです。

それでは、アセンブラの世界を充分に楽しんでください。また何かありましたら質問してください。（とは言っても、自分もアセンブラ／プログラミング初心者で、まともなプログラムを書いたことはないのですが…）

BIOSによる表示

今時アセンブラに興味を持ってくれる人がいるなんて、私はうれしい、ほんとに感激です。

「IBM PC & DOS/V 活用ハンドブック」（CQ出版社）という本にブートストラップローダのサンプルが載っています。

No.1である程度解決しているようですし、既にご存知かとは思いますが

funi2さんのユーザ情報を拝見させていただいたところ、かなりコンピュータに詳しい方のようですね。

この回答への補足

暴走ですか…。

直接そのプログラムとは関係ないのですが、Windows下でAssemblerを組む上での注意を・・・

CLI, HLTなどに関してはalfeimさんのおっしゃる通りだと思います。

この回答への補足

>暴走することはあってもほかのwindowsのプロセスに影響を与えることはない。

や、別にVMWareでもいいんですけど、この前新しいVerの紹介見てたらどうもWindows9x/Meを土台に動くVerが見つからなかったので・・・

こんにちは。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング