2019年11月16日土曜日

old pc emulator

最近8bit osのcp/mにすっかり気を奪われていた。
プアなcpuでもうまく設計すれば実用的なことが出来るんだといまさらながら感心することしきり。

では少し進めてdos時代のpcのエミュレータはどうだったかディスクの隅をつついてanex86とeFMR-50をひきだしてasciiart.basの動作を比較してみた。
同じ結果は得られているようだけどeFMR-50だと65秒のところがanex86だと1秒とかなりの差がついている

これだけ差が開くとなかなか遅い方で各種の実験を行うのも辛い
ただHP dv6で実験していたころはこの手のエミュを実行するとすぐにCPUファンが唸りだしたが現行の開発機だと同時に動かしても全く
問題が無い。各々のエミュでCPUコアの1つがそれぞれ100%に張り付くけど裏でメモリ食いのchromeで資料を調べても平気なもんである。

まあしばらくは燃えないので新たなテーマを思いつくまではDOS系は塩漬けかな?

2019年11月13日水曜日

cpm8266 vs cp/m executor

windows10 のcmd上で動くcp/m executorでコマンドの実行時間を計測する方法
D:\>のようなプロンプトに対して
powershell -Command "Measure-Command { ここに計測したいコマンド}" とする。
cp/m executorの場合だとcpm [cp/mのコマンド+パラメータ]となるのでそのように打つと所要時間がわかる。
例えばsingle board computer界隈ではasciiartという名前で打ち切り回数15回のキャラクターベースのマンデルブロー集合の描画でそのcpuの処理速度を見るのだけど。概ねz80の8MHzで2分30秒くらいの時間が掛かっている。これを計測してみよう。

まずは通常の実行、mbasicでasciiat2.basというプログラムを実行。
これの実行時間を計測してみる。
cpm mbasic asciiat2.bas の部分を先ほどの呪文で挟んで・・
出た! 1.42秒か。なるほど

ではcpm8266ではどうかな、こいつはcp/m2.2なので時計とか無いからストップウォッチで測るので誤差1秒くらいあるけど関係ないくらい遅いから。さて
最初のコマンドの窓とフォントの設定が異なるのでちょっとイメージが違うけど同じ文字の結果が得られている。実行時間は手元のSWで2分39秒なのでexecutorの110倍以上の差がついたことになる。
このBASICのソースをbascomでコンパイルしたものだと実行時間は1分10秒で2倍以上高速になる。tpでソースを直してコンパイルしたものは
1分40秒でインタープリターよりは速いがbascomの生成したものよりは遅い結果になった。basicの浮動小数が4バイト単精度なのに対してTPが6バイトの浮動小数なのも影響しているかもしれない。
ちなみにwinのexecutorではbascom 447mS,tp 183mSとなり逆転している。このくらい速くなるとbascomの起動用の外部コマンドbrun.comの起動時間が足を引っ張り出すのかもしれない。

目下の問題はエミュでHiTech-cの浮動小数doubleがからむソースのコンパイルに失敗するということ
まあz80でCってあんまり重要視してなくてTPとPascalが動けば十分だとも思うしアセンブラのほうが触りたいのかなって自己分析してる
mon80を使って機械語に触れたいかな?あとはtpのbdos命令とかで十分か? cのコンパイル問題はじんわりと解決していこう

(19/11/14 am11:30) hitech-c の問題1つは解決
変数宣言を最近のCみたいに{}の途中ではできない様だ。
pascalがprocedure や function宣言部とbeginの間にvarで変数宣言部を持つかのように{の直後に変数宣言をかためる必要がある。
あとは実行は出来てもprintfで内容が出ないで%fだとfと出るのでこの部分だけだ。

(19/11/22 pm8:57) hi-tech cでコンパイルできない問題が解決
浮動小数を扱うにはコンパイル時に-LFを指定しないといけない見たい
(link floating numbersみたいな感じなのか、library findなのか?)
で、asciiartを作成した見た。
時間はwin-cpmで107msでcpm8266で44秒
TPやBascomよりも高速である。

ちなみに各コンパイラのオブジェクトサイズを見ると
turbo pascal :: 9KB
hi-tech c :: 8KB
BASCOM :: 1KB(ただし実行にbrun.com 16KBが必要)


2019年11月12日火曜日

cpm8266 - その後

ESP8266で動くcp/mのエミュレータで遊んでいた。
完成度も高くていろんな言語をとっかえひっかえ試している。

小さなファイルの授受はwindows10上のWSLのminicomを使ってxmodem経由で行う。
あんまり理由はわからないけど15kB以上のファイルを送ったりできない。しかたがないので上記のエミュcpm8266のセットアップ途中で使ったファイル転送ツールESPTOOLのexeを配布イメージから生成できるのでそれを利用してwindowsとesp8266との間で全dskイメージとoドライブ部分専用のuploadとdownloadをするcmdを作成してやり取りすることにした。
個々のファイルについてはcpmtoolsguiを用いて操作をする。

これでwindows10のcp/m executorとのシームレスな感じのやり取りができるし複数ファイルの扱いだとxmodemよりも面倒が少ない。

言語としてはmbasic および コンパイラ、turbo pascal、アセンブラについてはどちらでも実行できるのだけどc言語についてはhitech-cがcpm8266側のドライブ容量が241kBしかないので入れられない。
hitech-cに精通しているユーザなら何とかやりようがあるのかもしれないけど、にわかユーザには荷が重い。ここはwindows側でコンパイルして実行ファイルを送ることで我慢するとしよう。
コンパイルって時間が掛かるしソース編集との間を行き来しやすい方が断然効率が上がるのでエミュの価値が高い。

まあ実行速度はcpm8266がz80@8MHzぐらいなのでかなり遅いし・・
(実機に沿った速度と考えれば悪くない。cp比は高いよね)

コンパイル後の実行ファイルと言えばturbo pascalの生成した実行ファイルもendのアドレスを指定してコンパイルすることで転送しても動いてくれるようになりました。

2019年11月10日日曜日

趣味の方向性 - cp/m,turbo pascal,c and c#

このところエミュレータを利用したcp/mの開発にはまっていた。

Windows上のエミュレータ(cp/m executor,etc)しかり
外部SoCのcp/m環境(cpm8266)しかりなのである。

windows上の方が実行が速くて楽なんだけど環境を構築する必要もなくてどうも実感が湧かないというか本来の目標に向けての予行演習以上の意味が見いだせない。
勿論、実機で動く実行ファイルを作るクロス開発環境があると思えばそれで充分役立ちはする。
外部環境のcpm8266は小さな3x5cmのボードが1つのPCになることを想うと面白くはあるがつまるところこれも本物ではなくてエミュレートであるためもうひとつワクワクする感が少ない。

次のステップを考えたい。思いつくテーマは
1)Z80観察日記・・ブレッドボードでCPUの動きを見る
2)AVRなどチップで遊ぶ・・arduino活用
3)C#でraspberry piを開発する
4)nucleoなどほかの環境をいじる
5)raspberry pi zeroでハイレゾの音楽
悩ましくも楽しい葛藤

dosvaxj3が更新されていた。

 最近、エミュレータ系をあまり触っていなかったのだけど久しぶりに見てみたらタイトルのようにdosvaxj3が更新されていた。 on emulatorでセルフにcなどのソースを書いて実行するのに母艦側の特定のフォルダをドライブとしてマウント出来たり普通に母艦のimeで漢字が入力でき...