HC-88でプログラミング! その12

HC-88サブシステムの制御が奪えない!

f:id:PocketGriffon:20201108160717j:plain

ここんところ、どハマりしてた!(T-T)

 

スレーブCPU(6301)側のシステムを乗っ取って、メインCPU(Z80)とのやりとりを独自プロトコルで動くようにしてしまえ!…と思ってチャレンジしていたのですが、なぜかメインCPUとのやりとりがうまく行かない(T-T)

 

仕組みとしては、Z80側から「とある通信ポート」に書き込むと、6301側にIRQ割り込みが掛かる単純なもの。そこにはプロトコルも何もなくて、まさに直結!

6301側のIRQ割り込みを独自のモノに書き替えて拾ってみようとやっていたのですが、なぜか2度目以降のIRQが掛からなくなってしまう…。

 

良くあるパターンとしては、CPUのフラグレジスタ以外にもI/Oポート側に割り込みEnableフラグがあり、そこを読んだり書いたりしてあげないと次の割り込みが発生しない…という仕組み。HC-88でもそういう仕組みがあるのかと思いソースを相当読み込んだのだけど、それらしいポートが見つからない。

もうね…6301側のプログラムを穴が空くほど見た!

おかげで曖昧だったらシーケンス制御のフラグもなんとなく解析出来たw

f:id:PocketGriffon:20201108223051j:plain

 

だめだ…どうやっても制御が奪えない…。デバッガがあるわけではないので、プログラムを実行してみてダメだったら考える…という作業の繰り返し。そもそもメイン側が停止してるのかサブ側が停止してるのかすら知る方法がない。

サブ側は制御が動いてたら画面を変化させる事でなんとなく分かるけど、メイン側は画面もサウンドも担当していないので、動いてるって知るよしがないw

 

うーん…悔しいけど分からん…やるだけやったし後悔はしないレベルまで来たぞ…。

そう思い始めて「諦めました」ブログを書き始めてたw

 

突破口

HC-88のサブシステム(6301)側は、ワリと常に割り込みを受け付けていて、CPU命令のSLP(スリープ)で停止をしていても、すぐに起きてしまう。定期的に掛かっているので、おそらくタイマー割り込みだろう。

 

プログラムのシーケンスは奪っても割り込みは(IRQ以外は)そのままにしてある。一気に全部やるのは無理だし、特に止めなくても良いサービスもあるからだ。

ただ、通常のシーケンスを奪ってるということは、Z80側からの通常のSLAVEコールなどは受け付ける事は出来ず、入ってきたらまず間違いなくデッドロックとなる。

でもそこは自分でコード書いてるから、さすがにそんなプログラムは書いてない。

 

テストでやっていたことは、キー入力を受け付けて、押されたキー情報を6301側にデータとして送りつける…そんな単純なプログラムだ。そこにSLAVEコールが入る余地が無い。

    ld c,#1
    call BDOS

キー入力を待ち、答えがAレジスタに戻ってくるCP/MのBDOSコールだ。

 

……あれ?

なんか嫌な予感が…。#1ってエコーバックしなかったっけ??記憶が曖昧!!

手元にあるCP/Mの書籍を見ても、詳細が書かれてるモノとそうでないモノがあって、何を信用したら良いの?!

仕方ないので、ぱぱっとテストプログラムを組んで試してみると……エコーバックした!!

これだ!!(TOT)

 

つまりこういう事だ。

Z80側のプログラム開始

・6301側へプログラムを送り込む→実行開始

 (この時点でサブシステムは乗っ取られている状態)

・そこに通常コールの1文字表示処理が来てしまう

・想定していない手順で動こうとするとのでZ80側が無限ループ

一言で表すのならば「バグ」という…orz

 

その後も続くよ不具合は

上の問題を修正する事が突破口となり、もう少し先へ進んだ。IRQ割り込みは問題なく届くようになり、6301側は独自ルーチンで動くようになった!

…が、その後も安定せず…。なぜかいきなり停止してしまう症状に悩まされた。

 

6301側はメモリの内容を(専用のプログラムを組まない限りは)確認する術はなく、何が起きたのかをアタマの中でシミュレーションし、どんな問題が起こりうるのかを探っていく。

なにせシステムそのものを乗っ取っているわけだから、何が起きても不思議はない。暗中模索というか五里霧中というか、手探り感が半端ない!

停止するたびにシステムのプログラムを見ていくので、イヤでも中身に詳しくなるw

 

HC-88にどんなバージョンがあるのか分からないが、ROMのバージョン違いを考えたら、出来ればROMアドレスに直結のプログラムは組みたくない。RAMに用意されているフックを利用しながらシステムを組んでいる関係上、どうしてもソースは冗長になりがちだ。

ソースを探りつつ、原因を特定していく…。そしたら不思議な現象が出てきた。

    clr WorkArea

 

この1行を削るとうまく行き、追加すると停止(おそらくハングアップ)する。

なんで???こんな簡単な命令でダメになるなんて??

実はここで指定したワークエリアが実際には使われていて、なんらかのタイミングで数値を拾ってハングアップしているのか?clr命令を実行する時の注意があるのか??

もうね、散々っぱら調べたw 使ったことのないシステムの、使ったことの無いCPUの命令だ、不具合が出る可能性は無限大にある。

 

そして分かった驚愕の事実(TOT)

アセンブラのバグだった!!!

そう、私が自作したアセンブラが原因だったのだw もう、ふつーに使ってて自作した事すら意識が薄くなっていたんだけど、ここに来て久々の巨大バグヒット!

clr ワークエリア」はエクステンドアドレッシングの3バイト命令に変換されるべきところを、なぜか4バイト命令だと勘違いしてコードを出力しようとしていた。結果、4バイト目は出力されずに汚れた1バイトとなり、それがたまたま未定義コードだったために、6301の未定義命令トラップ($FFEE)へ飛びハマってしまっていた…というのが真相だった。

たかが1バイト、されど1バイト、である(T-T)

 

ようやくメドが立ってきた!

よーやくZ80→6301の高速ハンドシェイクが実現出来そうな目処が立ってきた!実際の性能評価とサンプルプログラムはこれからとなるが、なんとなく良い結果が出そうな手応えは感じている。

また次回以降に楽しいご報告が出来るかと思う!

 

ところで…今回、HC-88での開発をヘビーに行ってみたけれども、いくつかの注意点と利点が分かってきた!

 

RAMドライブはマジ便利!

開発していると、何度もハングアップしてはリセットを繰り返す事になるけれども、HC-88についている拡張ボックスにあるRAMドライブはホントに便利!リセット→BASIC起動→RUN"RSで転送プログラムの実行、そしてバイナリを送り込んでテスト!

f:id:PocketGriffon:20201108234616j:plain

※RS.BASの拡張子は省略が出来る。

滅多な事ではRAMドライブが消えたりしない(一度も消えたことがない)ので、安心してハングアップさせられますw

RAMドライブの整備、そしてバイナリファイルの転送プログラムは作って良かったとマジマジ思う(^^)

HC-88にメモリを増設する! - レトロパソコンであそぼう!

HC-88でプログラミング! その2 - レトロパソコンであそぼう!

 

ハングアップ時のテープ対応

サブシステム(6301)がハングアップした際、ふいにテープが動くことがある。ロックがかかったり巻き戻しされたり、ヘタに上書きされてないかと「ぎゃーっ」てなる事も何度かあったw これはメモリにあるI/Oを勝手にアクセスしてしまうと起こる。

#その前にテープを外しておけよ…って突っ込み大歓迎w

 

テープドライブが動いてしまった場合は、たいていドライブにロックがかかってしまう。無理にテープを取り外したりすると、今度は逆に取り付けが出来なくなってしまう。

こういう時は落ち着いて、BASICで「mount」→「remove」をしてやる。そうすると正常な状態に戻ってくれるのだ。おそらくHC-40でも同等な事が起こるだろう。

 

さぁ、苦しい時間が続いたあとは、楽しいプログラミングをしたいね!

頑張るよ(^-^)/

ではまた次回!(^-^)ノ

 

HC-88でプログラミング! その11

通信アダプタの改良

以前から「Mac→HC-88」の通信はうまく行くのだが、その逆の「HC-88→Mac」への通信がうまく行ってなかった。片方向だけうまく行くなんて…そういえば過去に経験があったな…と思い、調べてみると、どうやらプルダウン抵抗というのを取り付けないとうまく転送が出来ない事があるらしい、という事を知った。

 

まず、普段シャープのポケコンで使ってる通信アダプタはこちら↓

f:id:PocketGriffon:20201101101435j:plainf:id:PocketGriffon:20201101101501j:plain

これはネットにあった情報を元に、秋月電子で材料を買い揃えて同じモノを作った。

ポケコン用USB通信ケーブルを作ろう!

この通信アダプタのおかげでレトロマシンとの9600bpsで接続ができ、開発環境が劇的に変化した。これが無かったらレトロマシンにここまでどっぷりとハマらなかっただろう(^^)

 

長らくコレを愛用していたのだが、HC-40での通信をするようになってカタチ的にハマらなくなってしまった。仕方なく、全く同じ機能だけどカタチが違うものを別途用意した。

f:id:PocketGriffon:20201101102012j:plain

不格好ではあるものの、目的は達成出来るって事で問題なく使っていた。

HC-40では送信も受信も問題なく出来ていたのだ。

 

それが…なぜかHC-88では受信出来るものの送信が出来ないという事態に陥っていた。

↑のリンク先のページに「場合によっては上記以外のTXDやRTSも含め4つ全ての端子をプルダウンするとさらに安定性が増すかも」と書かれていたため、じゃあ…って事で作ったのがこちら↓

f:id:PocketGriffon:20201101102741j:plain

さらに抵抗が増えて攻撃力が増した!!

でも…これでもうまくアップロードが出来ないのだ。

作ったプログラムをダウンロードする分には、HC-88側で受信さえ出来ればいいや…と思い、この問題は後回しにしていた。

 

しかしここにきて、どうしてもメインCPU(Z80)側のプログラムを解析しないといけなくなってきた…。

そのためにはどうしてもメモリの内容を解析せねばならない。でもその肝心のメモリ内容がアップロード出来ないのだ!

前回6301のROMを吸い出したように手作業で移すか…64KBを??

いや現実的じゃない…。打ち込んだバイト数分だけ寿命が縮まるw

 

追い詰められた状況になったので、ようやく重い腰を上げて問題に取り組んでみた!

そもそもプルダウン抵抗ってのが何故必要なのか…すら理解していないので、回路図見たって解決が出来るわけがない(T-T)

…と思い、ふと裏側を見ると…

f:id:PocketGriffon:20201101103235j:plain

本来、抵抗はRXD側に付くものらしいんだけど…どうせ線は繋がってるんだから同じでしょ?という解釈でGND側に付けていた。でももしかしたらこれがダメなのかも…???

気になることは1つずつ潰していこう。

そうして修正したのがコチラ↓

f:id:PocketGriffon:20201101103644j:plainf:id:PocketGriffon:20201101103704j:plain

戦闘力には代わりはないが、抵抗を取り付けてる場所が変わった!

こんなんで効果あったりするのかなぁ……

なんて半信半疑に思いながらアップロードのテストをしたら……

動いた!!!

え?やっぱりGNDに抵抗はダメだったのね??

えー…でもソレって、実はHC-40の通信アダプタの時代から間違ってたww

HC-40で問題なく通信出来てたのは、偶然だった…のか(T-T)

そこはかとない敗北感を味わったよ…orz

 

メモリの内容をアップロードする

よし、これでHC-88のZ80側のメモリ内容をホストへ送る事が出来るようになった!

メモリの内容をテキストに変換して、それをホストへ送る。

f:id:PocketGriffon:20201101104054j:plain

通信落ちを考慮してアドレス+バイナリにしたよ!でもチェックサムないから同じか汗

これを元に戻すプログラムを作って…

f:id:PocketGriffon:20201101104203j:plain

はい、元に戻った〜(^-^)

よーし、ここから必要な箇所を追い掛けていくぞ!

 

バンク切り替えへの道

ところが…解析し始めてすぐに気が付いたんだけど、メモリのトンデモナイ場所へジャンプするコードがたくさん見つかる…。これは……アップロードしたメモリ内容が間違っているのか、通信に失敗してるのか、変換(または逆変換)にミスってるのか…。

可能性がたくさんありすぎて絞りきれない(T-T)

一晩考えて、プログラムを追ってみてようやく分かった事。

あ、これはメモリのバンク切り替えがありそう

ROMカプセルからBASICプログラムをTPAへロードしているという固定概念があったので、別のバンクへ飛ぶなんて事が考慮外になってた!!

 

バンク切り替えか…メモリマップさっぱりわかんないや(T-T)

これはこれで困ったけれども、どうやらバンクを切り替える方法はうっすら分かってきた!

で、即席でハンドアセンブルしたのがこちらw

f:id:PocketGriffon:20201101104648j:plain

Z80ならばアセンブラもあるから別にハンドアセンブルしなくてもいーじゃん…と思うでしょうけれども、Z80は脳内でバイナリ変換が出来るので、短いプログラムならばハンドアセンブルどこか脳内アセンブルでも作れる。このくらいの長さならぜーんぜん平気(^^;

 

これをBASICに埋め込む。

f:id:PocketGriffon:20201101104826j:plain

よーし、これでバンク切り替えした先のメモリが読めるようになったはずだ!

 

ちなみに転送時間はとっても掛かる。32KBの転送するのにだいたい30分掛かる。64KBで1時間だ。気長に別のプログラムでも組みながら待つことにしようw

 

とりあえずここまで作業が進んだよの報告的ブログでした!

次回から解析していくよ!ちょろっとだけだけど!(^^;;

 

ではまた次回!(^-^)ノ

HC-88にメモリを増設する!

f:id:PocketGriffon:20201030124932j:plain

メモリと言ってもメモリ違い

HC-88のやってみたい事も大詰めを迎えてきた!

今回やってみたのはメモリ増設

メモリはメモリでもメインメモリ(64KB)の事ではなくて、拡張ユニット内に入ってるRAMディスクのメモリの事。

今現在、Aドライブに64KBのRAMディスクがある。これは拡張ユニット(漢字ROMや辞書ROMが入ってる)の中に入っているメモリで、バッテリーでバックアップされている。そのため、よく使うプログラムなどはここに入れてけば、電源ONでいつでも使う事が出来る。

 

そしてこのメモリ…上の写真が拡張ユニットなんだけど、ものすごーく意味ありげに8つのICが刺さる場所があるんですよね…。しかも基板には「ここまでが64KB、全部付けたら128KB」みたいな感じに印刷までされている。

これは……自分で増設せよとのメーカーからのおぼしめしか!?

 

…とは言うモノの、同じまたは同等品のメモリが手に入らなければ、自分には手に負えないように思えた。まぁ64KBあるんだから贅沢言うなって事ですかね……

 

天から舞い降りた奇跡のユニット!

いや言い過ぎだとは思うんですが、このブログにも何度となく登場している「PX-8を所有している知人」から「良かったらコレをどうぞ」と譲っていただいたのがPX-8に取り付ける事の出来るモデムユニット。

f:id:PocketGriffon:20201030130039j:plainf:id:PocketGriffon:20201030130100j:plain

へー、モデムなのに名前は「MULTI UNIT 64」なんだ。何がマルチなんだろ?

f:id:PocketGriffon:20201030130329j:plain

カプラが繋がったり電話線繋げたりなるほどー。

……って?? BACKUP?

このスイッチはどっかで見たことがある!

ウチにある日本語拡張ユニットにもBACKUPってスイッチがある!

まさか!!!

さっそく開けてみる。

f:id:PocketGriffon:20201030130555j:plainf:id:PocketGriffon:20201030130616j:plain

なんと!!!メモリが載ってる!

しかも私が探し求めていたμPD4265Cじゃないですか!!

これは…これは…これはあああああ!!!!(昇天)

 

だがここから長い葛藤が始まる。

このメモリは通信バッファとして用いるメモリなんだろーかと。だとしたら、このメモリを外してしまったら、このモデムユニット自体が使えなくなってしまう。今となっては滅多に手に入らないこんな貴重なユニットを破壊しても良いのだろうか…もしかして歴史的に大切なものをダメにしてしまう可能性だってある…。己の欲望のために大きな犠牲を…ぶつぶつ…

多分15分は悩んだと思う!(をぃ

 

結果的にこう考えた。

・BACKUPスイッチもあるのでおそらく純粋な64KB増設ディスク用のメモリだろう

・モデム部分とは独立をしていて、メモリが無くてもモデムが使えなくなる事はない

・そもそも今の時代、モデムの役割は終わっていると思う+今後も使う事はない

・外観はきちんと元に戻した状態で手持ちのPX-8に取り付けておく(接続はしない)

自分勝手な解釈もあるだろうけれど、当時の機械に対しての精一杯の感謝の意を表した上で、モデムユニットのRAMを漢字拡張ユニットに移植する事にした!

 

RAMを取り外す

まずは何はともあれ、このRAMが取り外せなくては何も始まらない。

こんな足がたくさん生えたチップ、はんだごてで取り外すなんて(私には)無理だ!

というわけで、素人は素人なりに道具に頼るよ!!

f:id:PocketGriffon:20201030131922j:plain

はんだ吸い取り器のTP-100にご登場いただいた!

こういう道具に頼らないと、この手のチップは取り外せる気がしない。

f:id:PocketGriffon:20201030132044j:plain

チップの裏側を見てみる。

この…緑色の線が波打っちゃってるのをたまーに見かける事があるんですが、これって正常なんですかね??だいたい、こういう基板の場合ははんだが取りにくいって感じてるんですが…。

あとこのチップ抵抗?はどうしたらいーんだろ?メモリの横についてる事が多いような気がするので、これも移植するのかな…。

んー…細かい事は考えず、まずはチップを外してみよう!

TP-100さま、お願いします!!

 

f:id:PocketGriffon:20201030132433j:plain

……えーと…もしかして私、激しく破壊工作してますかね???

はんだが古いせいなのか、まーったく取り外せる気がしない!実際、チップを動かしてみてもびくともしない…あかん…これはあかん(T-T)

ちょいと追いはんだしてみましょうかね…

 

全部の足に追いはんだをしつつ考えてみたが、どうもTP-100で抜ける気がしない。ここはあたらな道具に登場いただく事にした!

 

f:id:PocketGriffon:20201030132736j:plain

ヒートガン!

これで暖めながらチップを抜いてみよう!

 

…肝心の作業過程を写真撮り忘れてしまったけれども…

f:id:PocketGriffon:20201030132940j:plain

無事に取り外せました!!

追いはんだしたのが良かったんだと思うけれども、1つ20秒程度の時間で取れました。むしろあんまり長い時間ヒートガンを当ててるのが怖かったので、そのくらいの時間で抜けて安心した(^^;

f:id:PocketGriffon:20201030133923j:plain

取り外した側の基板も綺麗な状態。

よし、これはキチンと組み立てて保管しておこう(^-^)

 

RAMを取り付ける

ヒートガンで取り外したばかりのRAMは、足にはんだがたくさんついていて、このままではチップを挿しこむ穴にハマらない。無理にごりごりしてチップおよび基板を痛める前に、正攻法ではんだを吸い取る。

f:id:PocketGriffon:20201030134523j:plain

↑こんな感じの足。はんだだらけで太っちょさん。

↓はんだを吸い取るとこんな感じ。

f:id:PocketGriffon:20201030134734j:plain

よし、これなら入るかな(^-^) 準備おっけー!

 

f:id:PocketGriffon:20201030124932j:plain

これが漢字拡張ユニット。日本のHC-80にとりつけると漢字が使えるようになる(そして本体はHC-88同等になる?)。

f:id:PocketGriffon:20201030135013j:plain

この部分に取り外したメモリをはんだづけするよ!

 

ここまで来ても不安が拭えない。TP-100でそれなりに長い時間チップを温めてしまった事、最初、ヒートガンを長めに当ててしまった事もあってチップが壊れていないとも限らない。きっと8つのメモリがちゃんと機能しないとダメなんだろうな…とか思うと、ホントに大丈夫だろうか…って気になる。ちなみにこの手のメモリ移植をするのは生まれて初めて。分からない事だらけだ!(T-T)

 

f:id:PocketGriffon:20201030135253j:plain

思ったよりも足がスカスカになってしまったので、マスキングテープでチップが落ちないように固定。それでも緩かったので、チップの足を1つだけはんだづけしつつ、チップの表面をぐいっと押すようにして奥まで入れ込んだ。これでばっちり入ってるはずだ。

 

f:id:PocketGriffon:20201030135456j:plain

綺麗に16個のチップが並んだ!……圧巻(T-T)

なんとなく重量感も増した気がする(当社比)

表面は綺麗に仕上がった!表面は!!

 

f:id:PocketGriffon:20201030135537j:plain

裏は…やっぱり素人はんだづけだ!はんだってどれだけやれば上手になれるんだろ…どうも到達出来るべきところへ到達出来ない感じがしないでもないw センスの問題かもww

 

ちなみにチップ抵抗?は最初からついていた。これはやっぱりメーカーさんからの「メモリを増設せよ」というご意向がww

 

さて、ここまででメモリ増設も出来たから動作確認を…と言いたいところだが、実はひとつ忘れてはいけない事がある。メモリのサイズを示すジャンパーがあるのだ。

f:id:PocketGriffon:20201030135925j:plain

デフォルトでは「64」の方に黒いジャンパーピンが刺さっている。これを付け替え忘れると、おそらく64KBのままになっておおいに悩むことになるだろうw

f:id:PocketGriffon:20201030140124j:plain

よし、これで128KBと認識されるはず。

このピンは、以前分解した際にじっくり基板を見てて気が付いたもの。前に見てなかったら一生気が付かなかったかも知れない。やっぱり分解した基板は良く見とかないといかんね(^^)

 

動作確認

さあ、実際に動かしてみよう!メモリ増設のような大きな事をしたので、ここは迷わずオールリセットだ。本体のリセット、サブCPU側(本体裏にある)のリセット、メモリバックアップスイッチの切り替えなどを行って、HC-88をまっさらな状態にする。

 

そして…どきどきの起動!!

電源はふつーに入った。問題は増設したRAMが認識しているか、だ。

CTRL-HELPでシステムメニューに入る。

f:id:PocketGriffon:20201030140500j:plain

おおおおお!<RAM DISK>がちゃんと128KBになってる!!!

ハード的にはちゃんと増設出来たって事?熱でチップが壊れる事もなく?

これは嬉しい!めっちゃ嬉しい!

まてまて、まだもう少し調べてみよう!

f:id:PocketGriffon:20201030140703j:plain

Aドライブの空きは127KBあると表示された!

f:id:PocketGriffon:20201030140751j:plain

試しにセーブしてFILESしたらちゃんと見えてる!

この後、ロードしたら成功した!

 

これは……メモリ増設に成功したって事じゃないですかね?!

嬉しいなー!ものすごく嬉しい!!(^-^)

ここに今まで作ってきたいくつかのツールを入れておこうと思うし、この先も作ったモノはガンガン入れとこうと思う。幸い、滅多な事でRAMディスクは壊れたりしないので、この先もプログラム開発用のツールを入れまくっていくよ! 夢が広がっちゃう〜(^-^)

 

ここに来て、だいぶ完璧なHC-88に仕上がってきた感じ。

液晶パネル綺麗、テープドライブ正常、メモリ128KB増設…あとは何が出来るんだろ? RS-232Cでホストマシンと繋がってるおかげで、フロッピーディスクの必要性を何も感じてない。ワリとパーフェクトなマシンになったかも。

HC-40共々、これからも可愛がっていこうと思う(^-^)

 

ではまた次回!(^-^)ノ

HC-88でプログラミング! その10

f:id:PocketGriffon:20201029124634j:plain

Twitterに動画をあげたが、無事にタロットカードの絵がドット単位に描画出来るようになった。汎用的な処理ではなく、あくまでもタロットカードが表示出来れば良いという考えの元に作られたもの。プログラム内部で横32ドット縦48ドットの描画に固定されている。

 

HC-40の時にも同じ事をやってみているが、今回との違いを紹介してみたい。

HC-40でプログラム開発してみた その3 - レトロパソコンであそぼう!

 

 HC-40(Z80)版のおさらい

 詳しい事はリンク先を読んで頂くとして、ざっくり言えば水平型VRAM(横8ドットが1バイトに対応しているタイプ)でドット単位にモノを動かす話だ。

単純にVRAMへデータを書くだけではダメで、必要なドット数分だけ横にずらしてやらなくてはならない。今回の場合は横32ドットあるグラフィックが対象だ。

 

Z80の場合はレジスタが(それなりに)豊富にあるため、プログラムでそこまで苦労はしなかった。結局、IX、HLに32ドット分のデータを入れ、シフトして溢れたドット情報をAレジスタで拾う…という、まぁごく普通の方法で実装をした。

  add ix,ix
  adc hl,hl
  adc a,a

1回のシフトに掛かる時間は34サイクルだ。

HC-40のZ80自体が3.58MHzと速い事もあり、タロットカードを10枚動かしてもリアルタイムに動いていた。

 

HC-88(6301版)の実装

Z80版と同じ処理を6301で作ろうとすると、まずレジスタの数が圧倒的に足りない事情がある。これはもうCPUのアーキテクチャの違いなので嘆いたところで仕方が無い(^^;

今ある命令でどう実装するのか…を楽しむべきだ。

 

そう、なんとなくだけれども…6301でプログラミングをしていると、将棋の駒落ち戦を思い出す。主に対戦相手とのハンデだったりするのかも知れないが、実際には1枚落ち2枚落ちと数が増えれば増えるほど自分の難易度が飛躍的に上がっていく。

6301で出来る事(マシン語命令)の範囲でどう攻めていくのが良いのか…を考えると、ものすごく頭を使う事になる。何十年も前に活躍していたCPUなので、世界中に定石がありまくるんだろうけど、そこは敢えて調べずに脳内で考えてみたい(^-^)

 

結局、いろんな命令を組み合わせて考えてみたが、これが一番しっくりきた。

  asld
  rol $02
  rol $01
  rol $00

16bitのDレジスタにタロットカードの右半分のデータを入れておく、左半分はダイレクトページ上の$02、$01にデータを入れ、シフトして出てきたビットを$00で拾う。

これで1回のシフトに掛かる時間は19サイクルだ。最大で7回シフトが発生する可能性があるので、その場合は133サイクル。プログラムにはこのシフト4回のセットを7つ書いてあり、ずれたドットの分に合わせて飛び込み先を変えてやる事でループ展開している。

 

ちなみにシフトの時間が19サイクルって事はZ80よりも速いの!?とか思うことなかれ。残念ながら動いてるクロック数が違う。HC-88のZ80は2.45MHz動作、そして6301は614KHzだ。ほぼ4倍違うので、時間に換算すれば6301の19サイクルはZ80の76サイクルと同等だ。むしろZ80よりも2倍の時間が掛かってると思って欲しい。

 

右端と左端の重ね合わせ処理については、プログラムの自己書き換えを行っている。「プログラムにデータを埋め込む」みたいな言い方をしたりするけれども、こうする事でループ内での条件分岐が無くなり、最短のプログラムで絵が表示出来る。ただし可読性は最悪になるのでケースバイケースだ。

 

前回に引き続き、タロットの描画ルーチンを公開する(一番最後)。興味のある方はどんな事をしているのかを解析して欲しい。プログラムに興味の無い方が見ると異常なレベルでの眠気が来るので、睡眠導入剤として利用してもらうのもアリだw

 

プログラムの自己書き換えは、_C10+1、_C20+1、_C30+1の箇所だ。いずれも元は0が入っていて、このまま読んでも意味不明になるので、適宜プログラムを追って欲しい。

 

ひとつだけイイワケをすると、あくまでも6301初心者が書いてるので無駄はあるだろう。動く事を最優先しているので、そこは許して欲しい。

 

この先は?

HC-88でやりたいと思っていた事がだいぶ実現出来てきたので、少し興味が薄れてきている。もうひとつやるとしたら、メインCPUとスレーブCPUのやりとりの遅さについての調査と改善プログラムの開発くらいだろうか。

それとは別にもうひとつHC-88でやりたいと思っている事があるのでそちらを優先させるかも。これはまだナイショだw

 

V20エミュレータの開発に戻りたいところだけど、実はさらに別のマシンに浮気したくなってる。何度も寄り道して申し訳ないが、興味の赴くままにうろうろする楽しみも趣味の醍醐味だ!←自己肯定

 

ではまた次回!(^-^)ノ

 

↓プログラムソース(1ドット単位のタロットカード描画(32x48ドット)

f:id:PocketGriffon:20201029174427j:plain

f:id:PocketGriffon:20201029174449j:plain

f:id:PocketGriffon:20201029174554j:plain

 

 

HC-88でプログラミング! その9

長かった6301CPUへの道

やっと…ようやくここまで来た!(感涙

HC-80の資料を手に入れて「へー、サブCPU側にプログラムを送れるなんて、FM-7みたいで面白い!ぜひやってみたい!」と思ったのが1年以上も前の事。何せその時はまだHC-80を手に入れてなかったから(^^;; 結構なレアマシンなので、動作品が簡単に手に入るとは思えなかった。

 

いろいろと手を尽くしてようやく手に入れたHC-88。

手に入れてからもいろんな事情で触る事が出来ず、もーガマンならんとV20エミュレータを中断してまで触りだした。マシンのメンテナンスから始まり開発環境を整え…という流れは、このブログでリアルタイムに書いてきたので、なんとなく分かってもらえるはずだ。

そんな道のりだったので感慨深い。じーんときちゃうw

 

タロットカードを表示してみる!

さあ!6301を直接制御してグラフィックを表示してみるよ!

まずは…表示すべきグラフィックデータのフォーマットすら分かっていないので、メインCPUからスレーブCPU(6301ね)を介してVRAMへデータを書き出すテストをしてみた。

 f:id:PocketGriffon:20201027032344j:plain

なるほど、どうやらグラフィックフォーマットはHC-40と同じらしい。データをそのままコピーしてもってきたら表示された。

それにしても………なんでこんなに表示が遅いの…。あまりの遅さにTwitterでご報告。

 

 Z80と6301のやりとりに異常に時間が掛かってしまうっぽい。

私のプログラムの作り方の問題なのかなぁ…分からぬ(T-T)

 

でもこの見せ方は、良心的な読者を詐いているところがある。

実はHC-80にはユーザー定義文字が存在する。PCGと言った方が伝わりやすいかも知れない。VRAMに32キャラクタ分の領域(256バイト)確保されているので、ちゃんとした手順で定義してやれば、BASICのPRINT文の速度で表示させる事が可能なんだと思われる。

おそらく今回作った↑プログラムよりも高速なはずだ。

 

しかし今回やってみたい「事」は伝わったと思う。

6301上で直接プログラムを動かして描画させてみるよ!!

 

いろいろと準備が必要!

まず前回作った画面反転プログラムを可能な限り利用する事とする。

6301CPU側のプログラムコードの先頭アドレスは$8000とした。この領域は、本来ならばユーザー定義文字(PCG)のデータ格納場所だ。今回は使わないので利用させてもらう。

 

次に使用しても良いゼロページについても、前回からもう少しだけ調査を進めてみた。利用して問題なさそうな領域を、もう少しだけ探しておきたいのだ。

6301側のプログラムを追い掛けてみたところ、どうやら$90〜$97までの8バイト付近は利用してもよさそうだと分かった。ここはカセットドライブ関連のワークとなっているようだが、ユーザープログラム実行中には使わない。この8バイト+$D0〜$D3の 4バイト、合計12バイトを確保した。

よし、これで戦える!(^^;

 

れっつ6301プログラミング♪

さて…じっくりと腰を据えて6301でのプログラミングを楽しんでみよう!

アセンブラアセンブラは作ったけれども、プログラムを本格的に作るのは今回が初めて。

そんな初心者が何にハマるのかを解説していってみたいw

 

メモリコピーはどうやる?

まず最初に疑問に思ったのが、インデックスレジスタが1つしかCPUで、メモリコピーはどうやるのが良いんだろう…って事だったw

2つのメモリを扱うワケなので、普通に考えたらインデックスレジスタは2つ必要。でも1つしかない…これは…ベタな方法でなんとかするしかない?

f:id:PocketGriffon:20201027093748j:plain

$D0(ワークエリア)に転送先アドレス、Xレジスタに転送元アドレス、Bレジスタに転送バイト数を入れてコールする。ニーモニックが見慣れないと思うので、同じような事をするコードをZ80でも書いてみた。

一部、Z80には本来無い命令を書いてるのでご注意(←の行)

f:id:PocketGriffon:20201027093952j:plain

00D0hに転送先アドレス、HLレジスタに転送元アドレス、Bレジスタに転送バイト数を入れてコールする感じで書いてみた。incは実際にはないので雰囲気として読み取って欲しい。

Z80の場合は転送数によってはLDIR使った方がプログラム短くなるね。

 

うーむ、6301では1バイト転送するのにこの命令数か…これは慣れていくしかないんだろうな。慣れないニーモニックとも戦いながらパズルを組み合わせていく。

 

やっぱり逆アセンブラアセンブラを先に作って正解だったかも!全く知らないというニーモニックがないのは強み(^^) みんな見た覚えがあるし機能だって理解出来てる。パズルのピースが頭に入ってる状態だ。

 

今回に限って言えばタロットのグラフィックスデータは横32ドット、つまり4バイトのデータが転送出来れば良い。

4バイト転送に機能を限定して作ったのがこちら↓

f:id:PocketGriffon:20201027101843j:plain

↑これはHC-88の実機(6301CPU)で動いてるプログラムをそのまま掲載してる。やっていることは、グラフィックデータ4バイトをVRAMへ転送し、それぞれのアドレスを更新しているだけだ。

途中abxという分かりづらい命令が出てくるが、これはX=X+Bをしてくれる便利な命令。Bレジスタを符号拡張してくれるかどうかまで分かってない(^^;

 

これをZ80で書いてみるとこうなる↓

f:id:PocketGriffon:20201027104024j:plain

……うぬぬ…Z80がものすごーく優秀なんじゃないかと思えてきた(^-^;

 

座標計算はどうやる?

 なんとなく6301の優位性が示せないままテキストが進んでいるが(意図的ではないw)、ここいらで一発、ノーマルZ80では出来ない芸当をお見せしたい。

 

VRAMのアドレス計算において、普通に考えたら乗算が必要となってくる。

HC-88のグラフィックVRAMは横480ドット、8ドットが1バイトなので60バイト構成となっている。VRAMのアドレス計算は、Y*60+Xだ。

本来Xはそのまま足しちゃイケナイw なぜならば、ついさっきも書いた通り8ドット1バイトなので、あらかじめXを8で割ってやらないといけない。ここでは話が面倒なので、そのまま加算する事にする(次回修正する予定)。

 

この一見すると面倒そうな計算、さっきのメモリ転送でも苦戦してた6301でどういうプログラムになるのか…。

f:id:PocketGriffon:20201027110134j:plain

おお!意外に短い!

これは乗算命令(mul)が6301にあるおかげ。mulするとAレジスタ*Bレジスタをして、結果をDレジスタ(AB合体)に格納してくれる。

あと特徴的な命令と言えばxgdx。もーね、ニーモニックが暗記出来ない(^^; 多分、「ExchanGe of D and X registers」なんだと思うけど確信はないw Z80風に言えば「EX DE,HL」だ。あとはさっきも出てきたabxがあるくらい。

 

ここまで作るのに何度となく作り直してる。動作確認は簡単ではない。なにせメインCPUの向こう側にいるCPUなので、ハングアップしたとしてもソースをじっくり見る以外に修正する方法がない。そもそもプログラムが動いてるかどうかの確証すらないのだ。手探り感がものすごい!w これが楽しくてレトロやってると言っても過言では無い(^0^)

 

同じ事をZ80で書くとこんな感じ?

即席で書いてるし動作確認もしていないので、雰囲気でお願いね(^^;

f:id:PocketGriffon:20201027110805j:plain

やっぱり乗算命令は強かった!

Z80でもKC80やR800、HD64180のように乗算命令を持つタイプを使うと、この優位性は一気に逆転する。いつかMSX TurboR(R800)でも書いてみたい。

 

私にしては珍しく、描画プログラム全体を載せてみる気になった。

覚えたての6301で書いたプログラムなので、間違いなく改善点はあるんだろうけれども、まぁ今日の時点ではこれが持ちうるチカラの全てって事で!

f:id:PocketGriffon:20201027111343j:plain

 

 Twitterでご報告しつつ動画を載せてみた。ほぼ一瞬でタロット10枚が描画されているのが分かると思う。本来の6301ってこんな速いんだ!って素直に驚いたw

 

6301アセンブラの使い心地は?

今回のプログラム開発に、先日作った6301アセンブラを実際に用いている。これを作ったおかげですんなりとプログラム開発が……進むと思ったでしょ?(T_T)

実際のところは悪戦苦闘ばかり!

 

まずアセンブラがちゃんとしたコードを出力しているのか信頼性が足りないw 間違ったバイナリを出力している可能性があると常に疑っちゃうのだ!出てきたバイナリとソースコードを1行ずつ照らし合わせていく、逆アセンブラに掛けてみる等、地道な作業が必要だ。

 

開発中に気が付いたんだけど、なんとmul命令がすっぽり抜けていたw アセンブラのプログラム的にはデータを1行追加すれば終わる話なんだけど、他にも抜けているものがないか全チェックするハメになった。そしたら全部で4命令の実装し忘れ。あやうく新しいCPUを創造してしまうところだったw

 

あと使っていて「あ、これは無いとアカン」と思ったのは、ロケーションカウンタ。「今のアドレスを示す」というヤツだ。アセンブラによって「$」だったり「*」だったりまちまち。

    jr nz,$+3

    xor a

    ld b,#nn ←ここにジャンプする

みたいな感じで使う。ジャンプさせたいんだけどラベルを作るほどじゃないんだよな…って時に使ったりする。人によって使用頻度が違う気がするけど、私は相当な頻度で使っちゃう人。これは出力されるプログラムバイナリのサイズを暗記しているから手軽に使えるんだと思う。

 

これは改良せねば…と思うんだけど、記号を何にするかで字句解析部分を変更しないとならんのでちょっとだけ厄介。思わぬバグを引き起こしそう…いっその事、絶対に使わないような記号にしちゃおうかな(をぃ まぁこれも自分しか使わないと思ってるツールだから出来るワザだけどw

 

このあとは?

このあとももう少しだけHC-88使おうと思う。

ドット単位にグラフィックを動かしてみたいというのが1つ。

メインCPUとの通信が異常に遅い原因を調べておきたいというのが1つ。

前者は今の流れでプログラムを追加していけば良い。後者についてはROMのプログラムを変更するのは不可能なので、独自でプログラムを作る際の新プロトコルとして実装するしかないんだろうなーって感じ。

今の遅さだとメインでゲーム動かしてサブで描画ってのが成り立たないくらい遅いw せめてそのくらいまでは使いこなしたいなと思う。

こんな令和の時代にHC-80を使いこなすも何もないんだけどねw

自己満足の世界です!!!(言い切ったw

 

ではまた次回!(^-^)ノ

6301アセンブラの開発

f:id:PocketGriffon:20201025122515j:plain

アセンブラの開発記録っぽいものを書いてみようと思ったけれど…さすがに内容が専門的っぽくなるし、ブログの軽さに合わないかもなぁ…と感じてしまったので、箇条書き的に書いてます。
なんとなくな様子を感じ取ってもらえれば…(^^;;

 

開発したアセンブラ概要

開発したのは、おそらく標準的であろう2パスアセンブラ

 

コード表記については参考になるものが多くなかったので、「HC-20 100%活用法」や「6301マシン語入門」の表記を見て「こんな感じかな?」という感覚で決めている。他のCPUとは違い、カッコがあったり無かったりなどでアドレッシングの違いが出る表記ではない。

 

アセンブル前にソースをcpp(プリプロセッサ)に通す事を前提としている。
そのためcppの機能に頼り切ったアセンブラとなっている。
gcc -E file.asm で出力されたファイルのみアセンブル可能。
cppを通したファイルを引数で渡すもよし、「gcc -E test.asm | ./asm」という感じでパイプで渡すのもOK。

 

cppを通すという事で、#defineマクロ、#include、#ifdef等の条件コンパイルなどがそのまま利用出来る。C系言語に慣れた人であったら違和感のない使い方が出来るかと思う。
ただし別のファイルをincludeした際はエラーの行数表示がおかしくなる。

 

16進数は数値の先頭に$、または最後にh ($FFFF or 0FFFFh)。
2進数は最後にb。0101_1010b のように途中に'_'を入れる事が可能。

 

ラベルは必ず行の先頭に書き、長さは無制限だが便宜上256文字以下とした。最後は':'でしめる事。
ラベルは特別な手続きなしで後方参照が可能。
先頭に'_'を付けるとローカルラベルとなり、その関数(スコープ)内のみで参照が可能。

 

セグメントなどの概念はなく、書いた通りの順番でメモリに出力される。ソースの書き方次第ではコードとデータ、ワークが混在する。

 

分割アセンブルには対応していない。アセンブルするといきなりアドレスが確定したバイナリ(またはテキスト)が出力される。
メモリ範囲は$0000〜$FFFFの64KB固定。

 

開発的な話

開発言語はC言語
コメントや空白行を外した場合の総コード量は1000行以下とコンパクト。

 

字句解析/構文解析にlex/yaccを用い……ようかと思ったが、ツールを使うほど複雑ではないため自前で書いた。BNFが頭に入っていれば難しい話ではない。

 

{式}の解決については、内部で逆ポーランド式に変換して結果を得ている。
これは30年ほど前に書いたモジュールをいまだに使っているw
なんでも良いけどbison/flexと書かないと古い人らしい、今後は気をつけたいw

 

1パス目

1パス目はラベルの登録、仮の構文チェック、命令長の決定等を行っている。
命令長を調べるという事は、結構なところまで解析を行わなければならない。頑張ったらアセンブラ自体を1パスで作れるくらい。でも後方参照ラベルの解決など面倒な部分があるので、無理なく2パスにした…というだけの話。

 

ラベルの管理は、ラベルが出てくるたびに片方向リストで繋げて行ってる。同じラベルがあるか調べる時はハッシュを用いているが、面倒だったのでバイナリサーチなどは使わず線形サーチしてる(ぐげぇ)。なのでラベル数が増えると比例してアセンブル速度が遅くなる。……が、現在のマシンでは気にするレベルではない。プログラマとしては気にしないといけない部分ではあるけれどもw さすがに仕事では手を抜かずに作っているのでご安心を(違

 

ラベル登録時に値を決定したいので、命令長を確定しつつ解析を進めるようになっている。
ただし6301CPUの場合はダイレクトアドレッシング(1バイトの絶対値)とエクステンドアドレッシング(2バイトの絶対値)を区別する方法が、実際の数値が$00〜$FFに収まっているかどうかしか判定基準がない。このため参照時にundefinedな場合は自動的にエクステンドとして処理をしている。ここは書き手に依存している部分。

 

AIM/EOM/OIM/TIMだけは記述が特殊なので、内部でも特別扱いしている。この4つの命令だけがオペランドを3つ持つ。ただし命令長はどのアドレッシングでも3バイトなので、ニーモニックの解析のみで命令長は決定される。

 

2パス目の処理を簡単にするため、ニーモニック解析は1パス目で行っている。疑似命令(ORGやDB/DS/ENDなど)も中間形式に変換してメモリに保管。

 

2パス目

2パス目はコードジェネレートが主な仕事。
1パス目でだいぶ解析が進んでいるので、その結果(1パス目で保存している)を利用しながらコードを決めていく。
2パス目で構文チェックもしているが、手抜き感満載。
おそらく他の人が使ったら度肝を抜くレベルw

 

命令解析については、記述されたアドレッシングを参考にしている。
この部分は…作るアセンブラの対応するCPUによって変えていくとラクな気がする。
ちなみにZ80アセンブラを作った時は、ニーモニック主体で決めていった(LD命令、INC/ANDなどの区分から)。
6301はアドレッシングで場合わけして行った方が圧倒的に解析がラクだったのでそうしただけ。
ちなみに過去に作った6809アセンブラでも、アドレッシング主体で解析した経験アリ。

 

6301はベースとなるマシン語コードから、アドレッシングの違いにより+$10ずつズレていく。
例えば「LDA」を例にしてみると、

コード アドレッシング  表記
$86  イミディエイト  LDA #$12
$96  ダイレクト    LDA $34
$A6  インデックス   LDA $56,X
$B6  エクステンド   LDA $1234

という感じだ。

つまりアドレッシングを解析すれば命令コードは自動的に決まる。命令コードが決まれば命令長も確定する。コード生成の直前までパス1で処理しているので、パス2ではその結果に基づいてコード+オペランドを出力しているだけだ。

 

パス2の段階で未定義ラベルは存在しないはず。
存在しないとなるとそれは本当に未定義ラベルなのでエラーを出力して停止させる。

 

疑似命令(ORGやDB/DW/DS/ENDなど)は最低限しか用意していない。
1バイトのデータ列はDB、2バイトのデータ列はDWで記述し、エリア確保はDSといった単純なモノ。

 

db $01,'A',"Hello",CR,(($10+NUM)*8),$0
dw $01,'A',"Hello",CR,(($10+NUM)*8),$0

 

上の書き方の場合、先頭の$01はdbの場合は1バイト、dwの場合は2バイトで格納される。こういうのを簡単に処理するために、1つのデータを得る処理と、それを何バイトのメモリに格納するのかを別に処理している。

[,]と[,]の間にある{式}を正しく処理してやる事で値が得られる。得られないとしたら、それは未定義シンボルが使われている。

 

最終的に出来上がったコードは、バイナリファイルとして出力するか、そのままC言語でinclude出来るテキストで出力するか、どちらかしかしてない。インテルHEX形式とかそういう豪華な出力仕様は付けていないのだ。

 

パス2自体の作業はとても単純で、ソースコードとしても150行もない。
ただただ機械的にコードを出力しているだけだ。

こんな感じの手抜きアセンブラであり、開発時間も合計で12時間にも満たないと思う。

 

書いてて「この文章の需要はあるんだろうか」と大きな疑問が…(^^;;

まぁ記録にもなるからいいかw

 

ではまた次回!(^-^)ノ

 

HC-88でプログラミング! その8

ゼロページの使用状況は?!

6301(6800)アセンブラの準備も出来たし、さっそく自作プログラムから直接画面を制御するプログラムを書いていこう!

…と思ったけれども、まだ調べないといけない事がいくつか残ってる…。

 

6301で少しでも高速なプログラムを書こうと思ったら、ダイレクトアドレッシング(ゼロページアクセス)が非常に重要らしい。もちろんゼロページが使えなくてもプログラムは組めるが、ほとんどの命令がゼロページアクセスならば1サイクル少ないのだ。ここぞというところには積極的に利用したい。利用したいけど……システム側でガンガン使用しているはずなので、ユーザープログラムでどこを使って良いのかが分からないのだ。

 

そこで、6301CPUのROMを解析して、使われているゼロページの情報をまとめてみた。

f:id:PocketGriffon:20201024232648j:plain

めっちゃ見にくいけれども…

256バイトあるゼロページのうち、前半はメモリがそもそも載ってなくて(I/O領域)、後半の128バイトがRAM、さらにそのうちの赤の部分が未使用らしい場所だ。

現状だと9バイトが空いている…みたい。

「みたい」というのは、あくまでもソースをかるーく眺めて拾い出しただけに過ぎず、プログラムを深く追い掛けていない。プログラム内で何かやっているとしても拾い切れていない。

 

ちなみに青いのはスタック領域。スタックこれしか使ってないの??と思ったけど、どうも複雑な処理をする際にはRAM領域の$97CAに再設定されるらしい。どれだけのエリアが用意されているのか不明なので、ユーザープログラムを実行する際には、独自にスタックエリアを設定した方が安全かも。

 

f:id:PocketGriffon:20201024224748j:plain

実際に該当部分のメモリを見てみてると、なんだかデータっぽい数値が入ってしまっている…。きっとこれは使われてるww

ホントに使われていないかどうかは、破壊してみるしかないかもなー。

例えばシリアル通信は使わないから、その領域を拝借しちゃうとか、そういう姑息な手段をするために調査を進めていこうと思う!

 

あ、↑こんな感じでHC-88の液晶は綺麗になりました!

PX-8の液晶パネルを移植してますが、PX-8ってエムブレムはないんですね…。

 

6301に感じる違和感

なんとなく経験的に違和感を感じる部分です。

アーキテクチャ的にそういうもんだと理解するのが良いというのは分かってますが、やっぱり気になるので書いてみようかと(^^)

 

スタックの初期化で「LDS #$00FF」という値を見た時。

え?$0100じゃないの??ってのが直感的な感想(^^;

PUSHした時に「SPを-1してからメモリへ書き込み」をするのか、「メモリに書き込みした後にSPを-1するのか」という問題だと思うんだけど、後者は珍しい…というか私が知らないだけか??

これはエミュレータ作ろうとしたら真っ先にハマりそうな項目だったので、先に気が付いて良かった。あとスタックを利用したメモリクリアとかのテクニック使う時にもハマりそう。

なんにせよ理解しておく必要があったと思う!

 

割り込み禁止命令のSEI、割り込み許可のCLI

これも感覚的な話だと思うんだけど、SEIは割り込み許可なイメージがww

6301のブート後プログラムの最初に「SEI」が出てきた時の混乱と言ったらw

この先、どうしても割り込みを触るプログラムを作ると思うので、これも意識して使わないと逆に書いてしまいそう。

 

これから6301でプログラムを書いていけば、もっと違和感を感じる事が出てくるのかも知れないけど、それはもうアーキテクチャ的な違いとして覚えていくしかない(^^)

エンディアンが逆ってのもメモリマップを上から書くか下から書くかの違いだと思うし!

昔、1バイトが8ビットじゃないマシンとか、そもそもスタックポインタを持たないCPUなどを触ったことがあるので、それに比べたら6301は可愛い範囲です(^-^)

 

よーし、次回からプログラム書いてみるよ!

とっても楽しみ!

アセンブラデバッグもしなくちゃw

 

あ、アセンブラの作り方に関する質問?がDMにいくつか来ていまして、意外にも作り方に関する疑問が多いんだな…と思ったので、近日中にアセンブラを開発する手順などを箇条書きで書いてみるかもです!

 

ではまた次回!(^-^)ノ