MACよ、君は正しかった。2018年04月19日 19:53

ROMライター Leaper-3

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 100h
END文に開始アドレスが書いてあります。これをアセンブルして出来上がったHEXファイルは、
          :080100000E021E3FCD0500C9EF
          :00010000FF
と、正しくEOFレコードを書き出しています。

END文から開始アドレスを削除してアセンブルすると、

          :080100000E021E3FCD0500C9EF
          :0000000000
見事、これまでの状態が再現されました。ここでした。END文に開始アドレスを付けるのが正解でした。

「MACよ、君は間違っていなかった。 間違っていたのは、わたしの方だった。」とつぶやきながら、納得しました。

マニュアルを疎かにしてはいけないと、肝に銘じた一件でした。

コメント

_ kuninet ― 2018年10月28日 09:41

こんにちは。有用な記事をありがとうございます。
CP/MのMACでアセンブリしてて、HEXファイルにEORが出なくて悩んでいて、こちらを見つけました。

ただ私の環境では、ちょっとまだうまくいってなくて...^^)>
END文のアドレス指定だとIntelHEXのアドレスフィールドにアドレスは入りますが、レコードタイプはあいかわらず0x00のままですよね?

今、こちら↓のgithubで公開されている機械語モニタを、自分のマイコン上で動作させて実験していました。LコマンドでIntel HEX形式をロードできるのです。
https://github.com/chapmajs/glitchworks_monitor

":"に続くレングス2桁が"00"(ゼロバイト)だったらEXITするという処理に変更するしかないのかなぁと思い始めていたところでした。
レコードタイプを0x01で出力できました??

_ 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のころから続く拡張されたフォーマットがあり、互換性維持のため使用され続けたのではないでしょうか。

書き込みありがとうございました。勉強になりました。

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://kida.asablo.jp/blog/2018/04/19/8829570/tb