2018.8.7
前へ
次へ
ホームページトップへ戻る


16ビットマイコンボードの製作

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
いつか使ってみるつもりで入手してそのまま置いてあった16ビットCPUのことを思い出しました。
AMD社のAM188です。
その名の通り、CPUコアは80188互換の16ビットCPUです。
そのAM188を使った16ビットマイコンボードの製作記事です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

[第67回]



●MV、CPをセグメント指定可能に(2)

前回はMVとCPをセグメント指定可能にしてテストをしたところ、摩訶不思議な結果になってしまいました。
[F000]の指定はROMのはずなのに、そこにMV(MOVE)できてしまうという夏の夜の怪談話です。
んな訳はないのでありまして、ただのバグでありました。

実は。
つまらないバグのため、[F000]の指定が無視されていただけでありました。
するとどういうことになるかといいますと。
デバッグのため、システムプログラムをRAMにロードしてそこでテストをしていました。
ほとんどが同じ内容のシステムROMで起動して、その後にRAMにデバッグ用のシステムプログラムをロードして、そしてRAMのシステムプログラムに切り換えて実行します。
このときそのROMの0100〜(セグメントベースはF000)には本来のシステムプログラムが入っていて、そしてRAMの0100〜(セグメントベース0000)にもデバッグ用のシステムプログラムがロードされています。

そういう状況のところで、前回はMV、CPの[F000]のセグメント指定がバグのために無視されたために従来のMV、CPと同じ機能が働いたのでした。
従来の機能では対象となるセグメントベースはRAMの0000です。
デバッグのためにRAMの0100〜01FF[0000]にロードされていたシステムプログラムを8100〜81FF[0000]にコピーしてそれをCP(COMPARE)したところを、[F000]のROM上での操作だと思い込んでいただけのお粗末でした。
もとはといえばROMのセグメントである[F000]に対してMVコマンドのテストをすること事態が無意味なことで、そこにはND80Z3.5のシステムのようになんとなく0000〜7FFFがROMで8000〜FFFFがRAMという思い込みがあったようです。
勿論AM188システムの場合にはセグメントベースアドレスがF000の0000〜FFFFはROMなので、MV 0100,01FF,8100[F000]という使い方自体が誤っていたのでした。

プログラムのバグを修正して、RAMのセグメント上でテストを行いました。

8086BASICのデータエリアのセグメントベースは[0000]です。
テストのためにあらかじめセグメントベース[1000](ここもRAM上にあります)の0100〜にテスト用データを書き込んであります。
MVのCOPY先のアドレス8100〜810Fの値を確認しました。
そのあと機能拡張したMVコマンドで0100〜010C[1000]を8100〜[1000]にコピーしました。
そのあとで結果をDMコマンドで確認しました。
セグメントベース[1000]に対してMVコマンドが正しく実行されたことが確認できました。
最後に機能拡張したCPコマンドを実行しました。
CPコマンドは指定したメモリ範囲を比較して不一致のところを検出します。
CPコマンドもセグメントベース[1000]に対して正しく働きました。

16ビットマイコンボードの製作[第67回]
2018.8.7upload

前へ
次へ
ホームページトップへ戻る