Tanacom-1エミュレータを制作していたんですね。次の記事はFORSEインタプリタの内部構造の解説とか期待していました。
エミュレータでは、かっこいいフロントパネルの入出力もぜひ再現してほしいところです。
昔のマイコンをエミュレータで50機種を再現した武田さんのサイトにて、当時の関係者の厚意で昔の日本電子専門学校の製作教材、MYCOMZ-80A（PC-8001似のパソコン）のROMと説明書が武田さんのエミュレータと一緒に配布されていて、当時の雰囲気が実機を持っていなくても楽しめます。
http://homepage3.nifty.com/takeda-toshiya/
お便り、ありがとうございます。
エミュレータ作って、皆様に、レトロッチックな手作りCPUを体験していただこうと企てておる次第です（笑）。
今、エミュレータは少しづつ形になってきましたが、一進一退の日々です。
やっとBeep音「ピポッ」が出るまで来たのですが、昨日まで動いてくれた「スタートレック」が大暴走しております。
この先、ドレミ〜と奏でていたPWMをPCに出したいのですが、まだ研究中で先例検索しているところです。
＞かっこいいフロントパネル・・・
おー残念ながら、今回はパネル無しでございます（本当は、そんなの作りたいのですが。裏方はCUIベースです）。
さて、ご紹介いただきました武田さんのサイトは、エミュレータ作るに当たって先例検索の際、私も拝見しておりました。
本当すばらしいサイトですね！とても勉強になります。
今回やってみて、エミュレータの世界も奥が深いなと、感じております。
作っていて、完成に近づいていく過程が、とても楽しい一時です。
それでは、早急に、ご披露できるよう頑張ってみます〜！
Tanacom-1エミュレータでシングルコアで問題発生って、一瞬エイプリールフールネタかと思ってしまいました。
HSPのマルチスレッド対応版にしたらどうなるでしょうか。対応したコードに手直しする必要がありますけれど。
＞一瞬エイプリールフールネタかと・・・
大ウケしましたー！(笑)
概要をご説明いたしますと、エミュレータの核になるCUI版エミュレータをVC++で作りまして、ラッパー相当をHSPで作りました。
プロセス間通信として共有メモリでやりとりさせました。HSP版が起動し、その中からexec命令で、外部ファイルであるCUI版エミュを起動させています。
タスマネで観ると、CPU使用率は49対51です。
シングルコアでもちろん動作は出来るのですが、「共有メモリでやりとり」で異常に時間を取られ、TANACOMとしての動作が、話にならないほど低下するのです。
VRAM画面クリアなど一瞬で終わる事が、消去されていく様が１ライン１ライン目で追えるほどなのです。
マルチコアの時は、分担作業？がうまくいっていたのでしょうか、ブンブン動いてくれました。
当方にもっと腕があり、オールVC++で作れれば、何の問題も発生しないのですが、なにせVC++も2010年無償版なもので・・・。
今、当方もう一度考え方を改めておるところです。
エミュレータの核の部分をDLLとして、VC++で作り、HSPから関数として呼び出す方法で、トライしてみようと検討中です。
これならマルチコア関係ありませんので。
取り急ぎ挑戦してみます。
さっそくダウンロードして遊んでみました。CoreDuoT2300の古いノートパソコンでも200MHz相当で問題なく動いています。
ウェイトをかけた状態でもCPUを使い切るため、デスクトップPCで実行した際はCPUファンの轟音に驚きました。
> 「共有メモリでやりとり」で異常に時間
タスクマネージャより短いサイクルでは、共有メモリをアクセスしない側がCPUを100%掴んでしまい、アクセスする側の処理が進まない状態だったのかも。
両方のプロセスを常に全速でぶん回すのでなく、どちらかが共有メモリにアクセスする際、しない側のCPUリソースを解放すれば解決しそう。
＞CoreDuoT2300の古いノートパソコンでも200MHz相当で問題なく動いています。
おーありがとうございます！心強いレポートでございます！！
＞共有メモリをアクセスしない側がCPUを100%掴んでしまい、アクセスする側の処理が進まない状態だったのかも。
うむ、素晴らしい！ご明察です。
前回版をシングルコアで動かした場合、まさにそれが起こっていました。
最初、50対50で動いた両者が、共有メモリ上で通信する際、99対0になり、返事を返す側がタスク割り当て「0」なので
ぼやーっと「あっ、受け取りました」てな反応になり、その後は0対99になったのでしょうか、超低速エミュに
なる訳ですねー。
今回は、VC++を捨て、庶民の味方？であるボーランドC++で、DLL方式にしました。
共有メモリやめて、HSPから拡張ライブラリをコールする形にして、タスク１本でエミュが
動く方式にしました。
＞デスクトップPCで実行した際はCPUファンの轟音に驚きました。
あっ、そうなんですねー。確かにタスマネでは「使用率 100% 」が出ると思います。
エミュのWAIT は、ただループで道草食わせてるだけです( 数100 nSの道草ですので、wait関数やsleep関数が使えず・・・)。
ただ結構、数10命令に１回はDLL からHSPに戻り、「 AWAIT 0 ( HSP命令です、済みません)」を噛ませていますので、
マウスや他タスクの動きをぎごちなくすることは少ないだろうと想定しております。
公開を焦るあまり、取り説が準備出来ないままアップしてしまいました。
これから精を出して「使い方」編を書いていきますので、よろしくお願いいたします。
> 庶民の味方？であるボーランドC++
以前はLSI C試食版共々重宝しました。今ならOpen Watcom C++とか、Digital Mars C++でしょうか。
素直にMS製かgcc使え（笑）っていう話は置いておいて、いろんなコンパイラでコンパイルが通ってワーニングが出ないようにしておけば、バグも少なくなるんですよね。
> 数100 nSの道草ですので、wait関数やsleep関数が使えず・・・
usleep()やnanosleep()を実現するシステムコールがWindowsにはないから、Waitable Timerを使用するんでしたっけ。
e.naka様いつも、いつも貴重な情報ありがとうございます。
Waitable Timer なるものがあるのですね・・・、調べてみます。
以前ご紹介されました「武田さんのサイト」の解説にて、例えば CPU を 10mS分 動かし、VRAM描画やI/O処理をした後、実10mS になるまでスリープ、これを繰り返す・・・的に説明されており、なるほど１命令１命令帳尻合わせするのではなく、時期を見てまとめて、調整すれば良いのだと、気づかされました。
確かに、テレビをディスプレーとしてたレトロ・マイコンでは、約16mSに１回書き換わる画面を見てゲームに熱中していました。
この方式ならば、wait関数やsleep関数が使えそうですが・・・。
Waitable Timer も含めて、トライしてみます。
- YY-BOARD -