MACよ、君は正しかった。 ― 2018年04月19日 19:53
Super AKI-80に搭載したモニタ-ープログラムは、Digital ReserchのMACを使ってアセンブルしていました。 ROMにプログラムを焼く時は、秋月電子で購入した、Leaper-3(パラレルポートで使用するタイプ)を使っています。 MACでアセンブルしたままのHEXファイルだと、ライターにファイルを読み込む時に、いつもエラーになります。 ファイルを見てみると、最後のレコードに問題があるのがわかりました。最後のレコードがいつも、
:0000000000になってしまいます。正しくは、EOFを示す
:00010000FFになるはずなのですが。理由が分からないし、時間もなかったので、エデイターで、毎回、書き直していました。
今日、MACのマニュアル"CP/M MACRO ASSEMBLER LANGUAGE AND APPLICATIONS GUIDE (Revision of Novenver 1980)"に掲載されているサンプルプログラムを 眺めていて、何か違うなと。サンプルプログラムは、下記のようになっています。
org 100h ;transient program area bdos equ 0005h ;bdos entry point wchar equ 2 ;write character function ;enter with ccp's return address in the stack ;write a single character(?) and return mvi C,wchar ;write character function mvi e,'?' ;character to write call bdos ;rwrite character ret ;return to the cpp end 100h ;start address is 100hEND文に開始アドレスが書いてあります。これをアセンブルして出来上がったHEXファイルは、
:080100000E021E3FCD0500C9EF :00010000FFと、正しくEOFレコードを書き出しています。
END文から開始アドレスを削除してアセンブルすると、
:080100000E021E3FCD0500C9EF :0000000000見事、これまでの状態が再現されました。ここでした。END文に開始アドレスを付けるのが正解でした。
「MACよ、君は間違っていなかった。 間違っていたのは、わたしの方だった。」とつぶやきながら、納得しました。
マニュアルを疎かにしてはいけないと、肝に銘じた一件でした。
コメント
_ kuninet ― 2018年10月28日 09:41
_ Kida ― 2018年11月14日 17:54
kuninetさん、
レスありがとうございます 。カメレスでごめんなさい。
資料を探したところ、20年ぐらい前にインテルのftpサイトから入手した"Intel Hexadecimal Object File Format Specification Revision A,1/6/88"が出てきましたので、フォーマットを確認しましたところ、End of File Recordは、
":00000001FF"
でした。
テストのため、MACに付属のSAMPLE.ASMを、ASM、MACとSLRのZ80ASMでアセンブルしてみました。結果は次のようになりました。
ASMの場合
:080100000E020E3FCD0500C9FF
:00010000FF
MACの場合
:080100000E020E3FCD0500C9FF
:00010000FF
Z80ASMの場合(Z80ASM付属の8080.MACマクロライブラリーをインクルードしています)
:080100000E020E3FCD0500C9FF
:00010001FE
ご指摘のとおり、MACではレコードタイプ"01"のレコードは出力されません。インテルフォーマットに忠実なのは、Z80ASMだけでした。
幾つかの他の資料に当たってみたところ、この様なものが見つかりました。
1. インターフェイス 1988/1 別冊付録「主要OBJ/LOADモジュール要覧」の32ページには、インテルフォーマットのファイル終了レコードの表があり、そこでは、REC TYPは、"01"となっています。これは、先のインテルの仕様通りです。
2. ところが、1982年に出版されたMark Dahmkeの"Microcomputer Operating Systems(邦題「マイコンOS」)"の57ページの"Intel hexadecimal ASCII data format"の図には、レコードタイプのフィールドが"Unused(set to zeros)"となっています。
想像するに、CP/M-80の時代には、CP/M 1.4のころから続く拡張されたフォーマットがあり、互換性維持のため使用され続けたのではないでしょうか。
書き込みありがとうございました。勉強になりました。
レスありがとうございます 。カメレスでごめんなさい。
資料を探したところ、20年ぐらい前にインテルのftpサイトから入手した"Intel Hexadecimal Object File Format Specification Revision A,1/6/88"が出てきましたので、フォーマットを確認しましたところ、End of File Recordは、
":00000001FF"
でした。
テストのため、MACに付属のSAMPLE.ASMを、ASM、MACとSLRのZ80ASMでアセンブルしてみました。結果は次のようになりました。
ASMの場合
:080100000E020E3FCD0500C9FF
:00010000FF
MACの場合
:080100000E020E3FCD0500C9FF
:00010000FF
Z80ASMの場合(Z80ASM付属の8080.MACマクロライブラリーをインクルードしています)
:080100000E020E3FCD0500C9FF
:00010001FE
ご指摘のとおり、MACではレコードタイプ"01"のレコードは出力されません。インテルフォーマットに忠実なのは、Z80ASMだけでした。
幾つかの他の資料に当たってみたところ、この様なものが見つかりました。
1. インターフェイス 1988/1 別冊付録「主要OBJ/LOADモジュール要覧」の32ページには、インテルフォーマットのファイル終了レコードの表があり、そこでは、REC TYPは、"01"となっています。これは、先のインテルの仕様通りです。
2. ところが、1982年に出版されたMark Dahmkeの"Microcomputer Operating Systems(邦題「マイコンOS」)"の57ページの"Intel hexadecimal ASCII data format"の図には、レコードタイプのフィールドが"Unused(set to zeros)"となっています。
想像するに、CP/M-80の時代には、CP/M 1.4のころから続く拡張されたフォーマットがあり、互換性維持のため使用され続けたのではないでしょうか。
書き込みありがとうございました。勉強になりました。
※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。
トラックバック
このエントリのトラックバックURL: http://kida.asablo.jp/blog/2018/04/19/8829570/tb
CP/MのMACでアセンブリしてて、HEXファイルにEORが出なくて悩んでいて、こちらを見つけました。
ただ私の環境では、ちょっとまだうまくいってなくて...^^)>
END文のアドレス指定だとIntelHEXのアドレスフィールドにアドレスは入りますが、レコードタイプはあいかわらず0x00のままですよね?
今、こちら↓のgithubで公開されている機械語モニタを、自分のマイコン上で動作させて実験していました。LコマンドでIntel HEX形式をロードできるのです。
https://github.com/chapmajs/glitchworks_monitor
":"に続くレングス2桁が"00"(ゼロバイト)だったらEXITするという処理に変更するしかないのかなぁと思い始めていたところでした。
レコードタイプを0x01で出力できました??