2023年3月23日木曜日

ああ、アホかと

昨日の固定小数点のmbasicのプログラムが間違っていた。

数値の積を出すときに3bitずつシフトする計算にしていたけど5bitずつだと思う。

6:10で表現すると1は1024で2は2048になり各々32で割ると32と64になるので掛けると 2048となり正しくなる

これで求め直すと下図を得た

割と良いのでは?
プログラムはこんな風ですね。(無事debugできた)



ちょっと実機(cpm8266)で試してみよう。
結果は3分49秒で素直に浮動小数計算をしたよりもかなり遅い。
やはり乗算前に小数点を補正するためにシフトでなく割り算の命令が4行も増えたこととdevide by zeroのエラーを避けるためにその各行がifで場合分けしてるのが重くのしかかっていると思う。c言語みたく素直な符号付右シフトがあれば速くなると思うんだけど・・・

で、hitech-cでやってみた。
最初はwondows 11の上でcpmコマンドでコンパイルして実行。
ちょっといびつで上下が非対称になっているけどそれが固定小数での誤差の味と思おう。
因みにmbasicとの違いはhitech-cのintが32bitなので6:26の固定小数点で計算しているため精度がかなり違う。もちろん同じ実行ファイルなら環境が変わっても答えは同じ。
cpm8266でやってみたら。当然ながら同じ結果を得た。
実行時間は12.2秒でhitech-cで浮動小数計算を使った版の3.6倍になりました。(ただし画面は似てるけどmbasicとは非なるモノなのでそこは愛嬌で・・)

一応、それなりに満足できる結果を得たのでこの話題はとりあえず終了。
次なる遊びを考えることにする。さて次は何をするかな?

浮動小数で遅いなら固定小数でやるため欲しい範囲を調べてみた。

 サイズ4byteの浮動小数の演算で遅いなら8bitcpu(=z80)でも固定小数ならどうかなって考えたら気になって16bitの掛け算の計算がそこそこ速いならあとは右シフトとか前もっての各定数の計算なので割と高速化できないかと思って例のasciiartの計算で発散時の整数部がどれほどになるかを調べてみた。ソースは元のbasicにちょっと手を加えて以下

これでmxが最大いくつかわかるはず
36は結構厳しい値。2のべき乗で整数部を決めるとすると
32<=36<=64 だから6bitも必要になる。16bitで計算しようと思うと小数部が10bitしか取れない。0.001も正確には出せないってことになる。
でもそこは我慢して6:10の固定小数点計算でasciiartを計算するプログラムをmbasicで書くとして定数を求める。

まず0.0458≒0.0449(6:10で46)で様子を見る。
次に0.08333≒0.08300(6:10で85)とする。
最後に発散を見る4は4096で良し。掛け算をする前に掛ける2つの数字を各3bit分右シフトすることになるので8で割れば良いと思う。
これで良いと思って書き換えたのが下記

残念なことに90行の2*AA*BBでオーバーフローしてしまうのでさらに制度が落ちるけど実験なので8:8で小数の分解能1/256でやってみる。
本来の結果を再掲すると下図

かなり精度が落ちて形が崩れているのがわかる。

道は遠い、今一歩力及ばす。がんば 俺!

2023年3月20日月曜日

cp/mでの最初のCのプログラムは

やっぱりasciiartでした。 hitech-cでコンパイルしました。
結果は44秒と流石に過去最速。mbasicの3.6倍は嬉しいですね。
結果は

windows11でtera termで実行した画面ですがturbo pascalの時と同じ場所に空白(=未集束)がありますね。どっちが正しいんだろ。
ソースは

先回、ソースをテキストで貼って行間に1行ずつ余分な空白が入るのを手作業で取ったらなんだか変になったのでサクラエディタの画面を貼りました。同じソースをbds-cでコンパイルしようとしたらヘッダがbドライブに無いとか言って叱られたのでそちらはサスペンド状態です。

2023年3月19日日曜日

cpm8266 他の言語でもasciiartしてみた

 前の投稿であげたretroPC界の基本ベンチマークともいうべきasciiartのソースプログラムはこちらで紹介されている。ソースは著作権的にどんな扱いか不明なので一応リンクだけ
http://haserin09.la.coocan.jp/Images/asciiart_0.gif

実行結果は前の投稿で示してある。まあ文字通りキャラクタでmandelbrot集合を描いたもの。
cpm8266のcp/mのmbasic85で実行した結果が2分40秒。
microsoftのBasicCompilerであるBASCOMでコンパイルしたオブジェクトで実行すると1分10秒で約2.3倍の高速化。 当然結果も同じ。

これをturbo pascalにポーティングしたソースが下記

program asciiart;
var x,y : integer;
         i : integer;
   ca,cb,  a,b,t : real;
 begin
   for y:=-12 to 12 do begin
      for x:=-39 to 39 do begin
         ca:=x*0.0458;
         cb:=y*0.083333;
         a:=ca;
         b:=cb;
         i:=-1;
         repeat
           i:=i+1;
           t:=a*a-b*b+ca;
           b:=2*a*b+cb;
           a:=t;
         until ((a*a+b*b)>4.0) or (i>15);
         if i=16 then write(' ')
                   else begin
                          if i>9 then i:=i+7;
                          write(chr(i+48));
                 end;
     end;
     writeln;
   end;
end.

そしてこれをコンパイルして実行してみた結果がこちら(macのターミナルのscreen)

ちょっと見てみるとわかるけど1行目の中ほどの7Aの後に空白(=収束しない)ができている。
turbo pascalのfloat変数は6byte,mbasicのそれは4byteと精度が異なるので結果が異なることがあるようだ。また変数のサイズが大きいせいかBASCOMほど高速化せず実行結果は1分40秒とmbasicの1.6倍にとどまる。
次はc言語でやってみたい。

無理くりpascalのソースを貼って整形したらブログのソースがタグまみれになって文字サイズが途中変ですね。

2023年3月18日土曜日

とっかかりはいつもの

 asciiartをcpm8266で実行してついでに実行時間も計測してみた。

手押しのストップウォッチで2分40秒ほどだった。
(windows11+tera termでもmacos+screenでも同結果)
asciiartの結果サイトで見てみるとz80の6MHzと8MHzの中間ぐらいの数値なので概ね7MHzクロックでz80が稼働しているようなイメージかなって思う。でもesp8266をarduino ideでコンパイルすると当然ながらずっと速くなる。実行速度が文字通り桁違いに速いのでこちらは計測部分も組込んであります。
2分40秒(=160秒):163msec -> 981.6倍 つまりesp8266でz80をエミュレートするのにそれくらいのオーバーヘッドがあるってこってすね。もちろんarduinoはコンパイルしてくれてるのでcpmエミュレータ上のmbasic85と比較しても全然意味はないけどプログラミングにかかる手間とか考えると大差ないので現代の環境は1970年代半ばごろのPCで行っていたプログラムの実行速度を1000倍の速さに押し上げるってことです。1000円もしない見た目ワンチップのモジュールでこれができるのが凄い。
逆に言えば1970半ばには遅いとは言え今日の使用に耐えうるかもしれないプログラミング環境の原型があったのが凄いです。

じっくりと鑑賞していきましょう。




春到来

 春になるとハードウェアをいじりたくなるんですね。

でもなかなか半田ごてを握ってというとそれをする時間や元気が(おっと、視力も)なかったりするんで出来合いのガジェットを使っていろいろといじることでお茶を濁すことになります。

先回cp/mのことを書きましたがPCでcpm executorでPCでやるというのが最も楽なのですがそれではあまりにも近道すぎる気もするのでちょっとだけハードを擦ってcp/mのエミュレータをのせたガジェットで遊ぶことにします。(実は以前から時々遊んでました。)

それはcpm8266っていうのでgithubにソースごと上がってますがesp8266ってモジュールの開発キットにエミュレータを乗せてPC側のターミナルソフトでコントロールするって感じです。

画像の手持ちのはamazonで買ったhi-letgoって中国ので当時2つで1,300円くらいで買いました。今同じものはamazonに載ってないですが基板のパーツのレイアウトが見た目ほとんど同じのがありました
cpm8266をwindows11のteratermでつないだ画面がこちら



こんな小さな見た目ですがPCとの間を115200bpsでシリアルで通信してターミナルでいろいろ遊ぶことができます。仮想のFDD(容量250KBとはいえ)がA:からO:まで15台このチップの中にはいっています。
当時、かなり高額で手に入らなかったのに現在フリーで配布されているソフトウエア達を自由に入れて遊べるというの昔日を知る身にとってはかなり来るモノがあります。

とりあえず以前mbasic,bascom,turbo pascal3は遊んでたんですが結構間が開いているので操作などを思い出しつつ今回はhi-tech cも導入してcの高速性(?)を楽しみたいと思います。



2023年3月15日水曜日

隘路からの脱却

 はっ、と気が付けばwindows64bitのc言語が面白くてどんどん本来の「古代電脳」から離れて遊んでました。

ここいらでちょっと原点に立ち返ってcp/mでの開発にしばらく身をやつしたいと思います。
DOS系のC言語もやりたいんですがハマりたいテーマがすぐに見えてこないので8bitの狭い世界でも歩くうちにまた楽しいことを思いつくと思ってやります。

cp/mと言えば mbasic, turbo pascal, c言語(これは絞れない。 hitechが優勢ですか?)
の3大言語とアセンブラだと思うのですがこれにwindowsでのexecutorやesp系のcpuをコアにしたハードウェアエミュレータで楽しむというのが今となっては基本でしょうかね。
z80でディスクを持っててメモリーが64kBのマシンを物理的に持っていても維持するのがめっちゃ大変そうな気がしますね。(ビンテージを持つことにも面白さや価値があるとも言えますが)

ちょっとずつ書いていこうと思います。

2023年3月4日土曜日

復調!

 2月の半ばに風邪を引いた。幸いなことにインフルでもコロナでもなかった。
でも回復に時間がか掛かった。歳だなあ。

で、念願のjulia描画のモーションgif化にやっとたどり着けた。

結果を貼っておく、うまく再生できるといいな。



月日が経つのは・・・

 姉妹Blog共々、7月の更新を忘れてました。 ちょっと色々あって古代電脳というか手続き型のプログラミングへの熱意が薄れてこのブログをどうするか考えてしまってます。 日々、いじればまた関心も高まると思うのでちょっと冷却期間に入ります。