cp/mでグラフィクス

cp/mで結構遊ばしてもらっている。

しかしちょっと残念に思っていたのが基本的にターミナルで動かすのが前提のcp/mではグラフィックスが出せないということ

でエスケープシーケンスで色だけでも付けてみたのがこちら

これは昨年11月に遊んでいたasciiartにエスケープシーケンスで色を付けたもの

（遊びちょろっと書いてで吟味をしてないので上記の結果がえられるのはwindows上のcp/m-executorのみでcpm8266などで動かしてteratermなどで受けると結果が異なる）

今回こんなページ「BASICで3Dグラフィック」を見つけた

teratermのtek4010のエミュレートの機能を使ってグラフィックを出力する試み

で、ドはまりした。

このページの最初のカラー版asciiartのときも同じ症状でうまくいかなかったのだがcp/mのmbasicでうまく動いてくれないのである。

その動作から推察するにターミナルの(横の)文字数を80桁とか決め打ちして書かれていてbasicのprint文でエスケープシーケンスのために改行せずに80桁以上の文字列を送り込もうとすると途中でcrlfを挟んでいるような感じである。

仕方がないのでhitech-cとturbo pascalで記述して描画したのが下図
(心なしか陰線処理に失敗している気もするけど・・）

w-room02上のcpm8266環境でturbopascalで8分,hitech-cで7分くらいで描けるようだ。

だがmbasicだと表示の途中で画面の左に中途半端なエスケープしそこないの文字が出る。この症状冒頭のasciiartカラーでも出たのだ。

別のbasic処理系で試してみようと思ってbbcbasicというのをダウンロードしてみたけどかなり書き直しが必要なようでちょっと保留。

上記のBASICで3Dグラフィックのページの方たちはgrant basicなるmbasicの亜流のようなbasicで記述しておられるようなのだが・・・
これで直線と点なら自由に描画できそうなのでmandelbrotの描画にも挑戦しようかと頭をよぎったけど90x90で8100ポイントの上記の描画で7分とか掛かるのなら640x480とか半分として320x240でも76800ポイントの描画だと少なくとも10倍はかかるので当面はX。

ちょっと中途半端なことになってしまったが今回の実験記述はここまで、・・

一応自分の備忘録としturbo pascal で書いて気付いたことをメモっておく。

１）TPにはbit演算のANDがないのでinlineで書く必要アリ。

　　何十年ぶりのz80(というか8080しかわからないのでそれ)の機械語でした。

２）TPの16進数は$で始める（忘れてました）

３）TPにビットのシフトもないのでBASICを参考に2のべき乗で割り算

３）などは昔は当たり前だったと思うけど最近の言語では専用の命令があるものね

cは今も昔もあんまり変わらなくて楽 =>>5とか & | とか0x1Bとか今も同じ。

言語間はbasicと行き来するよりはc <->tpの方がかなり楽だとは思った。

cp/mのmbasicで大きなプログラム書くのは相当骨が折れるけどcやtpならある程度までは書けそうな気もする。

でもvisual studioでcpp書いてるとIDEさんに叱られなくなったら少なくともコンパイルは通るレベルまでtypoとか変数の型間違いとかが無いってのは別次元に楽ですね。

で、tpとVS見比べてると進歩がすごいとは思うけどCPUの進化ほどでは無い気もする。

cp/mをesp8266で走らせてて考えたこと。

単にsirial portで単独のプログラムが走るのを楽しむだけであればエミュレータである必要は無いのでarduinoのIDEでボードとして認識させれば動きは速いはず。asciiartはesp8266で2分くらいかかるのがarduinoのものをコンパイルして食わせてなおかつボーレートを8266標準と思われる115200bpsにしたら160msec.ぐらいだった。750倍の処理速度だ。

多分 nucleo ST32-f401reとか wio terminalなども同じく速いと思うのでこれも興味の対象である。

このあたりの強みはarduinoで1度書いたソースを自動でコンパイルして各々のボードに送り込めば動くということ

素晴らしい！・・・but,6/6現在esp8266でのtekエミュ画面への書込みは失敗！

見事なり、忘却の彼方

今日は270ｓでWSLの設定をした
ubuntuの最新を入れるところまでは一本道なのでコマンドラインまでは何の迷いもない
しかし問題なのはこれからなのだ、この1年と少しの間m-bookことマウスコンピュータのMB-G550SNを使ってきてwindows10の世界にすっかりはまっていた。インストールした最初の頃にどうにか動くようにしたっきりWSLを触ってなかったので諸設定をすっかり忘れている。
結果としてx-windowが開かない。VcXsrvで使うソフトになにがあったのかも忘れている。X11で使うターミナルソフトがどれだったのかもわからない。
幸い昔のOSと比べると試行錯誤するのも速いしシステムが全落ちするわけでもないし何より色々とエラーの情報が表示もされるのでそれを糸口にたどっていけるのは助かる。そのコマンドで出たエラーメッセージをWindows側でググって手を打てたりもする。最悪でも現状入れ始めたWSLの上のUbuntuなどのディストリを丸捨てしたところで半日も掛からないのだ。そもそもWSLは発展途中の環境でもありいろんな人が情報を発信してくれているので助かる反面バージョンの違いなどを考えるとうのみにできないことも多々ある。でもこれだけきれいに忘れているとどれが正しそうなネタなのかも判断が付きにくい。最近いじったのはちょっと前のことで、wslでcpm8266を準備するときにコマンドラインは使ったのだけど色々忘れてるもんだ。

何より恐ろしいのは、今回は普段使いの開発環境にLISPとかちょっと弄るのに便利かと思ってWSLを入れようとしてそれでいろんな大切なこととかインストールの肝とか忘れていることに気が付けたけど本当はもっと大事なことを知らないうちに忘れててそれに気づきもせずに生きてるのかなって思う。

あのう、誰か僕をご存じの方、僕って本当は誰ですか?

※※もしかしたらだけど日本語化あれこれが上手くいかないのはここの情報のようにWSL1にUbuntu20.04を入れたことが原因なのかもしれない。明日さっそく消して再挑戦しよ
(200517) 結局、ubuntu 20.04を消してubuntu 18.04LTSを入れてやったらx11の起動もfcitx-mozcを利用した漢字変換も成功！
引っ掛かりどころは2点
１）dbus-uuidgen > /var/lib/dbus/machine-idでdbusを通す。
２）fcitx-autostartを忘れないこと
※これbashでログイン時に自動でやる記述を探ること！[課題]

wsl=Windows Subsystem for Linuxってことはこれって大好きなEmuじゃん！

PCエミュレータの方向性

最近は以前にも増してベンチマークオタクっぽく行動している
まあ分野はレトロなものが多いけど

で、各種PCエミュレータのお世話になっているのだが・・
以前から感じてはいたがエミュレータには２つの方向性がある

eFMR-50とかneko-projectのnp21とかはビンテージPCの再現を優先して製作されているもので実際のPC上で動かしていたゲームとかがその時の感覚で動く。
開発などに使うための逃れも用意されていてeFMRの場合だとメニュー>control>CPUx16とかを指定すると確かにCPUBENCH(-f指定)で指定通りの結果がでるので内部でCPUの実行の速度を上げていることが確認できる。ただ当方の環境だけかもしれないがキーボードをスキャンするタイミングがめっちゃシビアになってなかなか思う通りのタイピングが出来ないので使うとすればeFMR-50についていえばCPUx1での利用で、となる。

もう一つのエミュの方向性は当時のPCの仕様を今のハードウェアで実行するとどうなるか
（つまり現代的なcore iなんちゃらのclock 3GHzクラスのCPUだとどうなるか）
みたいな動きをするものもある。
その環境で種々の科学計算やコンパイルとかの実作業をするのなら大変ありがたい動きをするものである。反面、リアルタイムなゲームとかを実行するときには動きが速すぎて面白くもなんともなくゲームオーバーということになるのかもしれない
手持ちのPCエミュのなかではanex86がこのタイプのように思う。またDOSBOXやvirtualBoxの中にインストールしたPC-DOSも実PCの環境の影響を反映する。
（こうしたエミュ達は逆に普段は、かっとんで動いてゲームとかの時にエミュ先のビンテージPCの速度にタイミングを合わせるような設定があるのかしら？ゲームとかやらないせいか調べたことがないなあ）

これを検証するために往年の２つのベンチマークcpubenchとdskbenchを実施した

すべて実行は270S(c:SSD)上
EmuPC名	／テスト名	CPUBench		DSKBench
	キー反応	RATIO (vs PC98)	所要 時間(秒)	Seq Write	Seq Read	Rand Write	Rand Read
eFMR-50(486)	普通	15.18	4.55	0.08	0.07	0.27	0.23
CPUx2	普通	30.57	2.26	0.04	0.03	0.13	0.11
CPUx4	やや反応悪	60.61	1.14	0.02	0.02	0.08	0.06
CPUx8	かなり無反応	121.22	0.57	0.01	0.01	0.04	0.03
CPUx16	ほぼ無反応	246.78	0.28	0	0.01	0.01	0
eFMR-50(386)	----	9.69	7.13	0.11	0.1	0.42	0.35
eFMR-50(286)	----	4.01	17.21	0.21	0.18	0.72	0.62
anex86	----	153.55	0.45	0.02	0.01	0.09	0.04
DOSBox	----	265.76	0.26	0	0	0	0
virtualbox DOS/V	----	6910	0.01	0.01	0	0.03	0.02

当ブログの主のような利用方法ならeFMR-50を使うのなら486でCPUｘ2(or x4)辺りで使うのが好ましいのかな

DOSBoxのDSKBenchが速いのは素のSSDの速さを測っているのだからか

それにしてもvirtualBoxのDOS/Vの速さは際立つ

またエミュレートは原器に忠実な方が好ましいときにはeFMR-50は極めて忠実な設計がなされていると思われる。WinkipediaではFMR-50HE2がi386sx@20MHz,
FMR-250L4だとCPUはAm5x86@133MHz！判断しずらい！

cpubench添付のCPURACE.TXTによれば4.55秒は80386DX@25MHz( on J-3300)ほどの速度でありCPUx2の2.26秒は80486DX@25MHｚ( on PC-H98 model 100)のスピードと同じとなる（ちなみにCPUBenchの実行速度が母艦をm-bookに替えてもほとんど同じだったこともeFMRの設計が原器忠実再生を目指すものだとうかがわせる）

ま当ブログの方向性から行けばvirtualBoxの利用が正解なのかな？

（環境設定の手軽さだとDOSBoxも捨てがたい）

悪ノリの果てに

久しぶりに酒を飲んでいい気分
つい調子に乗って秋月に
1)Wio Terminal
2)STM32 Nucleo Board STM32F401
を発注してしまった。

wioは今日たまたまnetで見て種々のインターフェースが充実していて楽しそうなので欲しくなった。開発はarduinoのIDE(エディタ＋コンパイラ＋serial writer)を使うみたいだし・・
Nucleoはcp/mもあって楽しそうだしarduino互換のPINでいろいろ試せそうなので…
（あ、SDが付かないとcp/m出来ないのか？）
最近はc-lang系やpythonでの開発が気にならないので余計に楽しいのか？
基本的に楽しそうだと欲しくなるのかな？
この分だと前から楽しそうだと思っているkumanのLCDも欲しくなる。
arduinoに乗せてあれやらこれやら、ムフフな・・あれ？自制が効いてない
どうなりますことやら

嗚呼、またやってしまった

C#という言語とVB.NETという言語はバックボーンを.netとする2卵生双生児のようなものである。
で、コンパクトな書き方ができるっていう理由でC#を使うようにしてきた。
しかし本当にVB.NETでC#と同じ速さが出るのか体感したくてちょっと書いてみた。
またしてもmandelbrot描画なのだ。

これが速い方、で次が

こちらが遅い方。この２つの画面、ソースは2，3行違うだけ
で、実行速度は199倍（ま、ほぼ200倍やね）の差がついた。

※厳密なことを言えば遅い方のpictureBoxのgraphicに書く方はsetpixcelが使えなかったのでdrawLineで元のx,yからx+1,y+1に直線を引いてみたらちょっと黒い発散しない領域が侵食されて見える。これは速度とは無関係

どうしてこんなに速度差がでたのかというと遅い方はpictureBoxのcreategrphicsで得たグラフィックアエリアにそのまま描画をしたもので1ドットごとに画面の再描画がされていると思う。一方速い方はべつに画面と同サイズのビットマップを用意してそちらに書いてからpictureBoxに張り付けた。忘れていたなあダブルバッファリングとか・・・
で、295msはc#のオブジェクトよりも速い。
(さらにコンパイルされたbinのreleaseのフォルダのexeで試すと160ｍSで更に速い)

VB.NETといえどもBASIC・・どういう訳か書いていて肩の力が抜ける気がするのはなぜなのだろう。原点回帰のようなものか？
ただifの直後の丸かっこがないとか各行末に;がないとかのせいで全体が見やすく感じるのとvisual studioのエディタが強力でfor,ifなどの終端部分をほとんど補ってくれるのでさほどend系のタイピングが多くないこともわずらわしさの解消になっているのかも・・

※visualbasic.netとc#は本来全く同じコードを吐くことのできる言語なのだけどvisualbasic.netのほうがVBから流れてきたユーザを考慮して敷居が低くなるような配慮があちらこちらにあるようだ。その１つが①Microsoft.Viasual.Basic ②System ③System.Collections ④System.Collections.Generics ⑤System.Data ⑥System.Drawing ⑦System.Diagnostics ⑧System.Windows.Forms よく使いそうな8つのライブラリーをあらかじめImportするようになっている(逆に言えばこれら以外が必要になった時に最初はものすごく悩むだろうね)

いろいろ調子に乗ってc#のmandelbrot描画で目下最速のアンマネージドアレィのさらなる高速化を狙ってparallel化してみた。
使用前

所要時間：42ｍS　立派！これをparallel化すると

なんですと！この他にも妙に歪んだものや２重化のものなど実行のたびに様相は変わるがどうしてこうなった！

ちょっと悔しかったので他の環境に逃げてしまった。

次の画像はLSI-C試食版と簡易グラフィクスライブラリを使ったもの

描画の所要時間は5.5秒くらいで16bitCPUのMS-DOS系のエミュレータの実行速度とは思えないほど高速だ。LSI-Cもグラフィクスライブラリーも使い方も明快だしドキュメントも日本語でしっかりとあるので使いやすい。強いて言えばvirtualboxのスクリーンショットがちょっと取りにくかったけどこうして画像を得ました。

そしてvisual studioでC++を使ってDxLibと組み合わせてみた。

流石のスピードです。速い方のPC m-bookで計測すると26mSecと出る。やっぱりゲーム作成を意識したライブラリーは速いこと

(200519)

またやってしまったと言えば、またしてもおもちゃを買った。

wio terminalというガジェットである。

日本製しかこの手のものが無かったときはしばしば数万円単位で散在してたが昨今の傾向として某大国の影響なのか安くなった。

この内容で@3,700円は実にお買い得なのである。

さっそく開封の儀もそこそこにarduinoのIDEに環境を作ってmandelbrotを入れてみた。一部描画関数の呼び方などを修正するだけなのですぐに実働までこぎつけた。

320ｘ240の2.4"LCDが内臓なのでarduinoとかよりも断然楽しい。

描画時間1.8秒ほどはこの手のものとしてはそうとう速いと思う。

実はLCDのサイズをうっかりコピペ元のVGA向けのソフトのままで動かして画面に期待した画像の1/4のエリアが映っていたときは驚いた。

しかし描画範囲を超えて計算させてもエラーで止まるわけでもなくしれっと描き切るあたりは面白い。またスピードもさほど変わらない。

描画時間が1830mSecと出ているがなにも描画しない画面の初期化だけを測定しても400ｍS以上かかるのでこの数値はかなりのものだと思う。

またいろいろと遊んでいくことになろう。

現代的スクリプト開発事情(pythonで)

pythonをいきなり再開した
昨日あたりに書いていたpythonでexcelをやったりしようかなって思って

でちょっと目についたのでpythonでmandelbrotをしようとしたが足りないライブラリーがあることに気づいた。って言うかvostro 270sの方ではエラーが出た。
しかしながらさすがに現代的な環境（pythonのライブラリー管理の力だが）、コマンドプロンプトで実行しようとしてライブラリーが無いってエラーがでたらpipでそのライブラリーをその場でinstallするだけで実行できてしまう。

なんと便利な事なのだろう。まあcp/mとかmsdosの頃には常にネットにつながったPCというイメージすらないのだけど・・・

※上記のmandelbrot描画でvostro 370sで意外な弱点を発見した。　このPCのCPUはcore i3-3240(2core HTにより4スレッド)なのだが描画中にタスクマネージャで負荷観察すると異常に時間が掛かるというもの。もしかしたらWindowsの更新が飛んできているのかもしれないのでもう少し条件を変えて様子を見ることにする。

で、スクリプトの開発でも同じく便利な環境が当たり前のように揃う。

下はVusualStudio Codeでpythonの開発をしているところ

（qiitaのhttps://qiita.com/dario_okazaki/items/4ba70e8a7ee1a6b024e8　に従って画面の様子を見ているだけです。)
もうね、pysimplegui 便利すぎて怖いです。

エクスプローラでフォルダを右クリックしてCODEで開いて新しいファイルを作成して（この場合だとWebからコピペして）ctrl+shift+@でターミナルを開いて今入れたコードをpythonで実行している

まだターミナルのshがpowershell一択なので設定が必要なのだけどpython実行できるから良いかと・・・

ノスタルジーに駆られてcp/mやらmsdosやら触ってるのもいいけど最新の環境で実開発に役立てるのも大事だと最認識した次第です

ネットでググりながらなら書けるというレベルでは実に心もとないのでpythonやc#なら呼吸をするように書けるレベルを目指したいです

（おこがましいがVBAやTurboPascalやｃならそこそこ）

でリハビリとしてBASICで数行のコードがpythonでどうなるのか見ます

BASIC習い始めてしばしば最初の頃に出てくる直線で書くモアレ画像

このソースは

 1000 'モアレな直線  save "moare.b99",a
 1010 width 80,30:console ,,0:cls 3
 1020 for x=0 to 639
 1030   line(x,0)-(639-x,479),x mod 7+1
 1040 next
 1050 a$=input$(1)

さてこれをpythonで書いてみましょう。
標準？の描画ライブラリーtkinterを使って

さて同じ結果が得られたがソースは

# coding: utf-8
from tkinter import *

root=Tk()
root.title("直線でモアレを表現する")
root.geometry("640x480")
canvas=Canvas(root,width=640,height=480)
canvas.create_rectangle(0,0,640,480,fill='black')
canvas.place(x=0,y=0)
colors=['black','blue','red','magenta','green1','cyan','yellow','white']
for x in range(640):
    canvas.create_line(x,0,639-x,479,fill=colors[x % 7 + 1])

mainloop()

良い感じなのではないかしら・・ オブジェクト指向がからまずに数行なら迷わずに書ける
BASICの実質5行がpythonで12行は多いと思うかもしれないけどほぼ命令の対応は取れていると思うので細かい説明はしない
このあたりは流石に入門言語BASICの領域なのでそちらに分があるなあ

次の課題はこれだ(俗にバーンズリーのシダ[wikipedia])

あれ？！python+excelからどんどん離れてるぞ！

感化

最近cとか(よりCPUに近い表現をできるという意味で)低位な言語を触っているとc#やpythonなどの(より抽象的で人間の思考に近いという意味で)高位な言語で随分と楽をしているなあと感じる。
pythonのジェネリックなlistやc#のenumerableなLINQ( to object)はちょっと触りだすともはやいかにループを書かずに処理を進めるかに注力してしまう麻薬のような存在のように思う。　c.f. https://qiita.com/memakura/items/6b3e6e06eae51725fd5d
c#のバージョンが上がって3.0になった2008年ごろにLINQが言語仕様に含まれるようになって馴染むのにそこそこの時間を有したが今はいかにLINQに向いたリストを用意するかとかデータベースのORMを用意するかがシステムの保守性に大きく影響を与えるようになったとも感じる。

そもそも自分がよく書く小さな組織向けのシステムでは基本となるデータ構造こそ決まれど実際の処理はしばしば顧客のビジネスの都合で変更される。
その変更を受けれるのにaccessのVBAは実に便利な存在でベースとなるデータ定義、各画面や帳票で共通に使われる処理部品、そしてその画面内だけで有効な処理を封じ込めるのにそれぞれの要素が程よいバランスで存在していたと思う。
（Excelもかつてはシート毎のVBAが今よりも記述しやすくて小さな仕組みを書くのがたやすく感じたが最近はVBAの記述を汎用モジュールの側に書かせようと誘導されているようで窮屈さをかんじる、特にマクロの入ったワークブックの拡張子すら分けるようになり心理的なハードルも上がった）
そのaccessのVBAも前バージョンの機能を他の客用に残したままで特定の顧客用にシステムをカスタマイズするときなどに不便さを感じるのだが・・・

最近はExcelのブックを特定のフォルダ内を渡り歩いては条件に合うものを探して処理するような記述をする案件をいくつか扱ったがサンプルデータでは遅く感じなかったものも実現場では耐えられない速度なのかもしれないと薄氷を踏む思いなのだ。
記述性を考えるとCOMを経由してExcelのブックを実際に開くような処理を記述するよりもpythonなどでopenpyxlを使って書くほうが直接ファイルとしてのexcelワークブックを取り扱うという点で処理速度の面でもメモリーの占有の面でも有利かなって感じている。
同じことはc#にも言えてclosedmxlライブラリーをつかえばexcelワークブックをCOMを経由せずに自由に扱える。(ただし上記のそれぞれのライブラリーは対象がxlsxなので古い拡張子xlsのファイルについては保存しなおしが必要になる。)

せっかくこれらのライブラリーを自由に選択して使える立場にあるのだからこれまでのaccess(もしくはexcel)のvbaを用いてCOMで裏でexcelを使う方式と速度や書きやすさの点を比較してみるのも面白いと感じる

久しぶりのC

何ていやらしいタイトル

冗談はさておき以前は毎日のように書いていたC言語
最近は実験的な記述はC#、以前からの客のフォローはVBAとあっても楽々で書けると思っていた

いやー！甘かったねぇ
structの扱い、どうすんだ　とか　lsi-c試食版のエラーメッセージ情報少なくね　とか　挙句はこれどうしてifで判断できんの？そうかc系列は値の同一比較は「==」やった。これって忘れたらあかん基本中の基本や

※でもえらいもんでstructを頭につけて型指定で宣言とか
パラメータで渡すときは参照なんで&付けるとかエラーを繰り返すうちに思い出してくるもんやな
問題が解決するにつれ不思議な高揚感

忘却　ちょっとこれ　リハビリ必要やわ　でもCは結構楽しい
以前は最初に覚えたまともな構造化言語がTurboPascalだったこともあってpascalマンセーって思ってたんだけどここ数年endって綴るのはrubyとVBAだけで他はカーリーブランケットだったせいか数行のプログラムならいざ知らずちょっと長くなるとpascalの文字数の多さが息苦しさを覚えるようになってきてますわ

まあこの機会に忘れたことを思い出しながらやってみよう
(200502)

結構苦労してなんとか上記のmandelbrot集合を得た

色数は16色で他のサンプルと違う（手抜き）

問題は結構速いと思うvirtualBoxのPC-DOSなのにcで記述してるのに遅い。

ちょうど10秒くらいかかる。ubasicがこのPCで30秒ほどなのでわずか3倍にしかなっていない。dosboxだともっと遅くて243.15秒（と思ったら5倍にはなったのか！？）伸びないのはライブラリーのせいなのか？

同じものをm-bookでやってみるとDOSBoxで84秒、virtualBで6秒足らず

まだまだ挑戦は続く