MikeOS - simple x86 assembly language operating system
x86 operating system MikeOS is an operating system for x86 PCs, written in assembly language. It is a learning tool to show how simple 16-bit, real-mode OSes work, with well-commented code and extensive documentation. Features: A text-mode dialog and menu-driven interface Boots from a floppy disk, CD-ROM or USB key Over 60 system calls for use by third-party programs File manager, text editor, ima
アセンブラで開発された16ビットOS"MikeOS 1.0"登場 | エンタープライズ | マイコミジャーナル
16日(米国時間)、MikeOSの最新版にして初の1系リリースとなる「MikeOS 1.0」が公開された。MikeOSはアセンブラで開発されたx86 PC向けの16ビットOS。CD-ROMまたはフロッピーディスクから起動して動作する。テキストベースのダイアログドリブンUI、コマンドライン、FAT12のサポート、PCスピーカサポート、基本的なDOS .COMプログラムサポートなどの特徴がある。 MikeOS 1.0ではコードのクリーンナップが実施されたほか、簡単にビルドするためのスクリプトの提供、新しいシステムコールの追加、バグの修正が行われている。また、MikeOSを実行/ビルド/変更するためのドキュメントガイドが追加されている。MikeOSは汎用OSを目的として開発されたものではなく、学習向けに開発された色が強い。実装されている機能も基本的なものだ。学習に使うには適度なサイズで興味深いプ
起動するまでの長い道のり メモリ管理編(2) メモリ・マップ取得の巻 - Outlandish Watch
ページングのことを書こうかと思ったが、まずマシンに何MBのメモリが搭載されているのか分からないと始まらない。それに、実はメモリ領域にも使えるところと使えないところがある。そういった情報も必要だ。 今回は、ACPIのファンクションを使ってメモリの領域情報を得る方法について解説する。 今回のソース setup.s memorymap.d startup.d メモリ量を得るには メモリがいくつ搭載されているか調べるには、またまたBIOSファンクションを使わなければならない。BIOSファンクションを使わないで調べる方法もあるらしいけど私は良く知らない。 メモリ量を調べるBIOSファンクションにも何種類かある。まずint 12hというファンクションがある。これを使うとKB単位でメモリ量が分かる。ただ、16ビットの数値で返ってくるので最大で64K*1K=64Mバイトまでしか分からない。いまどき64MB
Nachos
General Nachos Documentation Introduction Frequently Asked Questions Ports Known Bug List Thomas Narten's Nachos Roadmap Overview paper A Quick Introduction to C++ Alternate Nachos assignments (for Nachos 4.0) Releases nachos-4.0.tar Note: nachos-4.0 does not have compelling advantages relative to nachos-3.4 for most users. See README-4.0 in the tar file for the complete skinny. It is also in beta
自動車の電子制御用OSを日本メーカー共同で独自開発 | スラド
読売新聞に 経済産業省と自動車メーカー10社と共同で自動車の電子制御用OSを開発という記事が掲載されている。 次世代にむけたElectronic Control Unitの制御用OSということのようで、 ようするに経産省が予算をつけてJasParの枠組みで共同開発する話のようだ。 以前には日経から トヨタが自動車搭載用の標準ソフトウエアを独自開発というネタが出ていたが、JasParということはこの絡みもあるのかもしれない。 読売では、PC世界でのWindowsに対抗する日の丸OSという構図を持ち出して、既にISO17356にもなっている OSEK/VDX 仕様への対抗的な動きのように書かれているが、 AUTOSARも巻き込んでの主導権争い的な政治的側面が強いようにも思える。 全く独自の仕様と実装を一から作るという可能性はさすがにないような気がするが、どうだろうか。 TOPPERSプロジェク
セグメントレジスタのメモ。 - ボクノス
Mona本読んでて気になった所。 セグメント・・・。 ちと理解が足らない所なのでセグメントレジスタについてまとめておこう。 まず、セグメントレジスタの特徴。 16ビット時代の遺産。サイズは16ビット。 メモリを1Mバイトに拡張するための苦肉の策。 OS作る人以外はいじる必要なし。 プロテクトモードでは使用法が異なる? nasmの場合、segment:offsetの形で書く。 計算方法は、 リニアアドレス = segment * 16 + offset ブートの場合、0x07C00に飛ぶので、CS:SIは、0x07C0:0x0000となる。 CS コードセグメント SI(実行ポインタ)が参照する DS データセグメント mov等が参照する SS スタックセグメント push,pop,call,retなどスタック関連の時参照する ES エクストラセグメント おまけ FS,GS 名前なし? おま
起動するまでの長い道のり D言語編(1) 関数呼び出しの巻 - Outlandish Watch
不完全ながらプロテクト・モードに移行し、通常の32ビットコードを使う準備ができた。ここでいよいよD言語を導入していくことにする。 モジュール階層の準備 D言語のソース・ファイルをこれから追加していくわけだが、そのためにモジュール階層をまず用意することにする。モジュールとは、Javaで言うパッケージとほとんど同じものだ。ファイルパスでx/y/z.dというソースファイルは、モジュールで言うとx.y.zに属することになる。1ソースファイルが1モジュールとなる。で、x.y.zというモジュール階層を作る場合はxとyディレクトリを掘らなければならない。 ここではoutlandish.os以下に各ソース・ファイルを置くことにした。つまり各ソースファイルはoutlandish.os.XXXというモジュールを作ることになる。というわけで、outlandish/osディレクトリを掘る。 ソースコードの追加 と
起動するまでの長い道のり プロテクト・モード移行編(1) セグメンテーション薀蓄の巻 - Outlandish Watch
プロテクト・モードへの移行は起動処理の山場の一つだ。リアル・モードからプロテクト・モードに移って初めて32ビットのコードが動き、64KBの壁を破って4GBまでの全メモリにアクセスできるようになる。 x86系CPUでプロテクト・モードに移行するには、最低限セグメンテーションと割り込みディスクリプタテーブルを初期化する必要がある。だが、割り込みを禁止した状態ならばとりあえずセグメンテーションさえ設定すれば大丈夫だ。 今回は、プロテクト・モードにおけるセグメンテーションについて解説しようと思う。 プロテクト・モードにおけるセグメンテーション プロテクト・モードのセグメンテーションは、リアル・モードのそれと何が違うか。本当に違う。まったく違う。別物なんじゃないかと思うくらい違う。実際に別物だ。 リアル・モード時にはぶっちゃけ64KBの壁をどうにか超えるためのオフセットに過ぎなかった。ある意味後ろ向
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
