V20-MBCエミュレータの開発 その9

エミュレータ開発の現状報告

あああああぁぁぁ……(断末魔

5日間ほど悩みに悩みに悩み抜いたバグがよーやく分かった!(ToT)

 

まず、動かそうと作業していたTurbo Pascalだけど、起動してコンパイルするところまでは動くようになった!

でもコンパイルし終わって、出来上がったバイナリを実行(Run)しようとすると、なぜかハングアップしてしまう…。どうやらコンパイル時に出力されるバイナリに問題があるらしい…。

…とは言っても実機ではちゃんと動いているので、エミュレータのバグに間違いなのですが…orz

 

で、あれこれ見て修正したんだけど直りきらず原因も全く分からず、時間も掛かりそうな感じがしたので、まず先に別のドライブの動作確認をするかーって気を取り直した。

Cドライブ、Dドライブ…と見ていったんだけど…DIRした結果が実機と違う事に気がついた。

f:id:PocketGriffon:20200831103554p:plainf:id:PocketGriffon:20200831103412p:plain

左(上)が実機、右(下)がエミュレータの実行結果だけど、エミュレータ側はなぜかPRINT.TSTとWINSTALL.CMDの2つしか見えていない。

え?え?なんでこんな事が起こるの???

まぁエミュレータのバグなんでしょうね…(T-T)

 

このバグは現象もハッキリしているし、そんな難しいバグじゃないでしょ…とタカをくくってデバッグ作業を始めたんだけど、これが全く分からない。まーったく分からない。

症状として分かってきたのは、ドライブを入れ替えた際に、中に含まれているファイル数をカウントしているらしいんだけど、そこの数が実際の数よりも少ないという事。

うーん、表示よりも遥かに前のタイミングで出てるバグなのね…。

でもAドライブはちゃんと表示されるのに…。

 

そして修正出来ずに5日が過ぎた…って感じ。途中、2日間は別件が忙しくて何も出来てなかったけどw

この間、逆アセンブルリストと格闘していたおかげもあって、CP/M-86のCCPとBDOSが内部で何をしているのかが大体理解できたww CP/M-80の知識で見ていると、いろんなところが拡張されているなーって印象。

 

そしてようやく分かったバグの原因は、なんとV20エミュレータのバグではなくて、Atmega32Aエミュレータのバグだった!(T_T)

セクターを読んでくる処理での初期化ミスがあり、ドライブが変更されていても「同じセクタは読み込まない」という処理により、壊れたメモリを参照してしまっていた…という、なんとも情けないバグだった(TOT)

f:id:PocketGriffon:20200831104500p:plain

そしてようやく表示されたCドライブ!!(TOT)

長かったよ!!!

 

はー……なんだろ、このくじけそうな開発速度の遅さは(T^T)

仕事だったら許されないミスばっかりだなぁ…と反省。

次に長く掛かりそうなバグに突き当たったら、デバッガみたいな機能を入れようと思った。

コマンドラインからトレースやブレークポイント、メモリダンプが出来る、いわゆるDEBUG.EXEみたいなヤツ。

実行時のメモリが見られないってのがやりづらくて仕方が無い(^^;;

いつもならそういう機能を入れてたんだけど、今回は面倒くさくって(それがダメ)。

 

ATMEGA32Aのアップデートをしたい!

なんと!V20-MBC作者さまより、Atmega32Aのファームウェアアップデートのお知らせが届いた!あくまでも開発バージョンという事なので慎重に対応したい。

 

・ディスクセット2が利用出来るようになった

 今まではディスクセット0がCP/M-80用、1がCP/M-86用だった。

 これに謎の2が追加された。使用用途は明かされていないww

 

・System Tick IRQが実装された

 これは…何に使うのかな…何かMS-DOS移植に必要なのかな(あんまり分かってない)

 ディスク抜きチェックとかクロックデバイスとかアレとかコレとか?

 

…早い話が、MS-DOSを起動するのに都合の良さそうなものが対応された!w

これで後に引けなくなっちゃったぞ!!(^^;;;

嬉しいけど前進するしかないかー!プレッシャー(^^;

 

で…困ったことに私、Atmega32Aのアップデートどころか書き込みの方法すら知らない…。

懇切丁寧に教えてもらえたのでやってみようと思うけれども…ちょっと作業にキリついた時にやってみたい!

作者さま、ありがとう!!(^-^)/

 

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