2019年12月8日日曜日

年末に向けて図書館で借りた書籍

1)Web学習アプリ対応 C言語入門 スマホ・PCを使いスキマ時間で楽々習得
この本でプログラムを作成できるようになる人は凄いと思う。
300ページ以上を割いて本当に入門的なことを書いてます。
でも実践プログラミングのことは何も語られてはいません。
フローチャートって・・・

2)Windows PowerShellクックブック
対話的なshell的処理が出来なかったvbscriptにかわるMSのshell言語
ぼくが使えるpowershellのコマンドはlsとmeasure-commnadの2つだけ
でも今後を考えるともう少しだけ使えるようになりたいです

3)逆引き PIC電子工作 やりたいこと事典
PICのioピンにぶら下がったFETなどのデスクリート部品でステッピングモーターなど動かしてます
PIC16F1778をCで動かして楽しむ本
チップ本体は本日時点で秋月で@240なり
28pinDIPで使いやすければ面白そう

4)Processingをはじめよう
基本的に扱うのが画面とIO(主にマウス)なので
結果がすぐにわかるし楽しい
短いプログラムで飽きずに学べる
変なCの入門書よりもずっと学習が捗りそう

5)Excelで学ぶ進化計算‐ExcelによるGAシミュレーション
なんかツールのDL先を教えられてもねえ

6)PythonでGUIをつくろう─はじめてのQt for Python
ふだん使っているxamlとqmlはどう違う
求めているのとちょっとちがかった

2019年12月4日水曜日

次の目標ー興味の赴くまま

最近、いろいろと試していたcp/m系もちょっと飽きてきた
まあ実機のz80を弄るのができてないのでこの辺りは課題

そもそもソフトで出来ないことを模索したりするので8bitでないと
面白くならないわけではない
で、
1)arduinoでブレッドボードで遊ぶ
2)raspberry pi (zero) でハイレゾ再生環境構築
3)本来のデータベース屋としての実験
などが思い浮かぶが3)をちょっと注力して行こうかと思う

勿論1つのことをやり続けるのは根気や体力も必要で他のことにも
いろいろと気を逸らしながら楽しみたい

まずはC#+MS SQL Serverをやってみるか
(MS Accessとの比較を行いながらになるのか?)

2019年12月1日日曜日

processing に見るプログラム入門への可能性

随分離れている間に以前はたいして使えないと思っていた開発環境などが磨かれて使える安に成長しているのを再発見することがある

ひさしぶりにprocessingに触れてみた
バージョンは上がって3.5.3だ
かなり強力になっていると思う 特に構文のチェック機能はリアルタイムに効いていてエンバグしそうになるのを防いでくれる
(ちょっと五月蠅すぎるくらいだ)
そしてこれをプログラミングの練習環境として見たときに
1)上記のチェック機能でエンバグしにくい
2)見える成果物がターゲットなので自分のコードが正しいかどうか確認しながらすすめやすい
3)基本がjavaなので実行速度も速く安定している
 (思う結果が得られないときに責任が自分にあると信じて調査できる
  結果として原因が見つけやすい
  新しくてマイナーな言語のとき処理系と自分のどちらが悪いか
  見極めが不要だと楽なのです
  また実行が速いといろいろ試す時間が短縮できて助かる)
4)mandelなど点の描画が中心の時に所謂アンセーフな配列である
  pixelsに書き込めるのでここでも早くて助かる
  その構文もシンプル loadPixels,updatePixelsだけで後は
  pixelsと言う1次元配列にcolorを代入すればよい
  (画像を貼ってからloadPixelsしてpixels配列を読みだして
   色情報を得ることもできるし)


外部のファイルや画面のcontrolなどは無いので使える分野は多少
限られるが(loadstringsでは本当に簡単なテキストファイルしか
扱えないので・・・)
凝ったことをしようと思うと直ぐにjavaの出番になるのでそれなら
いっそ最初からjavaを使った方が見通しも良くなる
逆に考えるとprocessingに慣れて発展させたくなってきたら何らかの
IDEを導入してjavaに入っていくというのが正しいアプローチかもしれない。
でもこれってプログラミングに最適なんじゃねって今頃気が付いた
  
  

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で漢字が入力でき...