2023年1月31日火曜日

いいものみっけ

 どうせc言語でdosboxなどのエミュで簡単なグラフィックスのプログラミングを楽しむなら同じようなソースでwindowsやできればmacosでもやりたいと思っていた。

しかし最近よく使われているライブラリーでGLUTや後継のfreeGLUT、GLFWでは本来のグラフィックスの部分にいくまでにソースが複雑になりすぎる。もっとシンプルに書けるものが無いかと探していた。

さらにネットをさ迷っていたら見つかりました!
その名は「EGGX」ですよ。

正式にはEGGX / ProCALLですが主にunix系のグラフィック表示環境のx11を対象としたライブラリーみたいです。教育の現場で結構使われているみたい。

windowsでもWindows版EGGXもあるしソースもあるのでvisual studio からも利用できるかもしれないけどエミュの上のcと同じような手触りで書こうと思うと若干の違和感。で、wslですよ。せっかくwindows11上でwsl2を入れているのでWSLgが使えるのを利用しない手はない。

あとはeggxを入れればgccはwslのubuntuに最初から入っているのですぐにもcでグラフィックスを楽しめるはず。
早速やってみるとしよう。

インストールしてexamleをいろいろmakeしてみると日本語のfontsでエラーはでるしいろいろとwarningはあるものの問題なく動く。
mandelbrotのサンプルがあったので表示範囲と繰り返し回数を調整してだしたものとしばしばdos/v系でだしているものを並べるとこんな感じ
ソースも極めてシンプルで高度なことをやろうとすると積み上げが多くなって大変かもしれないけどC#erがdos系エミュの前検証用にwindowsでやってみるにはうってつけな感じなので採用。


2023年1月29日日曜日

macos版のdosvaxj3のコンパイル

 自分のmacbook pro(macos x mojave)でdosvaxj3のコンパイルをしたいと思って試行してみたがどうにもうまくいかない。
なんか32bitのオブジェクトがどうとか言っているようにも思うがxcodeのコンパイルも初めてに近いくらいのどビギナ状態なのでとりあえずは放置なのだ。

windowsべったりでいろんな環境での経験値も低い上に英語力も低いのでエラー内容からどの点を直せば良いのかもわからない始末。

現在のxcodeのバージョンが怪しいと思うのだが・・

ちょっとwindowsのc言語のgraphicのコーディング環境整備に逃げるかも・・

2023年1月25日水曜日

dosエミュ系での開発評価用ソースを決める

 何やら高尚なことを言おうとしていると思われるかもしれませんが複数環境でどの環境が使っていて楽しいかを知るのに基準となるソフトをいくつか決めてそれのソースの書きやすさとコンパイルや実行速度でみたらどうかと考えたので一応基準を決めたら良いかと

まずはretropc界隈でベンチマークの基準となっているmandelbrot集合をコンソールへ出力するBASIC言語のプログラムをlsi-c試食版で出してみる。

BASICのソースをできるだけ逐語訳的にc言語に書き換えたものがこちら

#include <stdio.h>

int main()
{
int x, y, i ;
float ca, cb, a, b, t ;

for (y = -12 ; y <= 12; y++) {
for (x = -39; x <= 39; x++) {
ca = x * 0.0458 ;
cb = y * 0.08333 ;
a = ca ;
b = cb ;
for(i = 0; i <=15; i++){
t = a*a - b*b + ca ;
b = 2 * a * b + cb ;
a = t ;
if ((a * a + b * b) > 4) break;
}
if (i<16){
printf("%X",i);
}else{
printf(" ");
}
}
printf("\n");
}
}



ここからグラフィックを使う本格的なものに発展させていこうと思う。
実行すると流石に1秒もかからずに終わるので時間計測の部分も考慮すること。

2023年1月22日日曜日

macのdosbox事情、あるいはベンチマーク

 先日来、動かしているdosエミュレータのdosboxとdosbox-xとdosvaxj3だけどmacでも動かしてみたい。
(実は、過去のアップ記事をご覧いただけばわかりますがすでに動かしているのあります。)

残念ながらdosvaxj3についてはmac向けのバイナリーが配布されてないので動かせない。
(ソースからコンパイルできるほどの根性がない)
また1/4時点のベンチマークの時のdosbox0.74では手持ちのcのグラフィックの入ったオブジェクトでは描画がされなかったので表に書けなかったけど今回の0.74-3では描画できたのでそれについて書きます。(ちょっと残念な点も含めて)

dosbox-xも最初はグラフィックが出なかったのだけど先日、同じと思われる版をダウンロードしてみたら出たのでとりあえずdosboxとvga設定にしたdosox-xを比較してみる。

dosbox0.74−3
 speedtst  464286 parrots  172.1XT
   mandel-c.exe  1533.78秒

dosbox-x 
   speedtst  318182 parrots 118.0XT
   mandel-c.exe  173.84秒

素のエミュレート性能としては対XT比が172と118でdosboxの方がdosbox-xよりも45%ほど高速と出ているのだがmandelbrotの描画時間が9倍もかかっている。
なにやらSDLの呼び出しの部分でかなりのオーバーヘッドが掛かっているのかと思われる。
もしかしたらdosboxが32bit用でdosbox-xが64bit用のオブジェクトであることが関係しているのかもしれない。
今すぐに明確な原因を提出は出来ないけど一応グラフィック出力の確認くらいには使えそうで嬉しく思う。速度の問題はおいおい解決するかもしれない。またdosvaxj3のmacos向けのバイナリーも手に入るかもしれない。

ちょっと「かもしれない。」の多い希望的な観測だけの結果になったけどmacos上でも最低限使えるdos環境があることを実感できたことはよかったと思う。

2023年1月21日土曜日

dosのソフトはなんで書く、cで書く

 特段目標もなくmsdos(freedos)・・面倒なのでdosのソフトを書いてみたいということで環境を考えた。

漢字は表示はしても入力はimeの設定ができないエミュもあるのでしたくない。(出来ない)

で、ソースは母艦側(windows,macos)側で用意する。
コンパイルは状況によるがエミュ上で行う。(どうせあまり大きなソースは扱わない。)

結果が見えるものの方がプログラミングのミスもわかりやすいのでgraphicsを扱いたい。
pc-dosのエミュ、pc98のエミュ共に使えるのはlsi-c330c試食版が良いと思った。
下はmacのdosbox-xでlsi-cでコンパイル、実行をしたところ


今、ネットで入手できるlsi-cでanex86などHDイメージがaのドライブ名で起動する環境ではlccでパスのエラーが出てしまう。なにやらcドライブに固定されたものがあるのかしら?

幸か不幸かmac,win共通で走るdosbox-xはzドライブで起動したのち、好きな母艦のフォルダを好きなドライブ名にマッピングしてそこにc:とかできるので上記の問題を避けることができた。
っていうかこちらで出来ているので、より98らしい環境でエラー吐かれると思ってなかった。

幸いコンパイル後のオブジェクトはドライブ名に依存していないようなのでanexでも動かすことができるようだ。

ibm-pcのエミュ環境では上のようなこともなくごく当たり前にコンパイルしてグラフィックスを楽しむことができる。

標準のグラフィック画面の解像度なども異なるのでそのあたりも考慮しつつ慣れたmandelbrotぐらいから動かしていこう。

2023年1月19日木曜日

freedos1.3 on vmwareの日本語入力設定に難航

 この記事を参考に日本語の入力設定をしてみたのだがdevice=c:¥fep¥msimei.sys・・・の行でエラーを吐いてimeの設定が効かず結果としてalt+全角キーでimeが起動しない。
まあ読み込めてないから当然ではあるけど・・・

※この記事も参考にさせてもらってます。
http://dosmania.blog.fc2.com/blog-entry-14.html

まあコピーが二度手間になったりするけどvmsmount.exeで仮想ドライブが使えるので絶対に必要でもないけどubasic32とかでも日本語入力できるとちょっとしたことをするのに便利そうなのにちょっと残念ではある。

時間をみて色々と試行してみたい。

この話題継続

2023年1月14日土曜日

vmware上のfreedosとdosvaxj3との比較

 vmware上でfreedos/v環境が整ったのでもう一つの常用エミュ環境であるdosvaxj3との比較をしてみた。

emuratoremu-osspeedtst(parrots)speedtst(rate)Mandel(lsi-c)Mandel(ubasic)
vmwarefreedos45,500,00016,870.614.839.606
dosvaxj3dos/v679,104251.886.4463.814

いずれもメイン開発機のwindows11PCでの数値で母艦はcpuがcore i5-8500でまあ今時のCPUとしては遅い方。
初代ibm-pcのXT比で16870倍と252倍とあるけどCで書いたMandelbrotの描画時間で見ると14.8secと86.4secで5.8倍程度の差である。
(でも片方で1時間かかる処理が10分で終わると考えると見過ごせない気もする。)
多分msdos-playerでもしも実行できれば早いと思うけど流石にグラフィックは出ないのでこれはあきらめる。

PC98系のときに一応測ったBASICだが当然dos/v系では動かないので多倍長演算のubasic32を使って同じmandelの描画をしてみる。
結果はvmwareが40秒、dosvaxj3が464秒で12.5倍の差。
dosvaxでc言語のオブジェクトを動かすよりもvmawareでインタプリタを動かす方が速いとは凄いね。ともあれ実機で同じソフトを動かすと気が遠くなるほど時間が掛かると思うのでこの環境で開発をいろいろやってみるのは面白いと思う。

下はdosvaxj3のubv32とvmwareのfreedosでlsicのコンパイルオブジェクトでMandelbrotを表示した状態。



ちょっとカラーナンバーのマッピングが違ってて緑の色合いが違うけどほぼ同じ結果が得られているのがわかる。

次はfreedosでの漢字入力とlsi-cのコンパイルについて書く。



freeDOS1.3 dos/v化の顛末

 手持ちのエミュレータの中で最も開発環境として高速だと思われるvmwareでfreeDOSの設定をした。英語モードはcd-romイメージを使って下記の要領通りで問題なくインストールできた。
https://no000.hateblo.jp/entry/2019/12/10/234158

しかしdos/v化して日本語表示をする段でいくつか留意すべき点があったので備忘録として記録しておく。

図はvmware playerでfreedos1.3を選んでデフォルトの日本語環境が起動した様子。

1)$fontx用のフォントを作成するのにms-dosだからと思ってms-dos player経由でmkfontを実行したらノイズパターンしか得られなかった。virtualBoのwindows xpの環境にいれて実行してちゃんと見えるfontパターンを得た。

2)規定のメニューで1−5までが使われていたので6として日本語環境が起動できるようにfdconfig.sysを調整した。


3)最初chej jpで日本語に移行したときに画面がスクロールするタイミングでハングアップしたのでディスプレードライバーdispvのオプション/HS=offにしたら一応表示は成功したもののすごく遅いのが気になったのでdドライバーをispvからdspvvに代えたら表示が出来たのでありがたく使わせてもらうことにした。

4)エスケープシーケンスの処理にnansi.sysを使うと日本語が出なくなったのでpansi.sysに差し替えて対応。

以上で日本語の表示はできるようになった。
次に示す方法で共有フォルダーを仮想ドライブのフォルダーにできるので今の所freeDOS側での漢字の変換については慌てて設定する必要性は高くない。

http://www.math.kobe-u.ac.jp/HOME/taka/2021/2021-11-19-FreeDos-on-VMware/
ここで説明されているfdosmount.isoをcdにマウントして中からvmsmount.exeをc:¥とかにコピーしておけばいつでも実行することでvmware側で割り当てた共有フォルダをたとえばe:¥fdosなどのような仮想のドライブの一部として読み書きできるので母艦側のvisual studio codeなどに文字入力や編集の作業を任せることが出来て大変便利。シームレスに母艦のwindowsとゲストOSのfreeDOS側のファイルが扱えることになる。

結果、freedos起動時のメニュー番号6で日本語環境になり放っておけばfilmtnが起動して作業待ちになってくれる環境が出来ました。
(ちなみに日本語キーボードはfreeDOSの標準でインストールされるkeybでjpを指定すれば対応してくれるので以前のように外部からフリーソフトを入れる必要ななくなった)
一応、ツール類を入れたtoolフォルダとlsi-c330c試食版を入れたフォルダにパスを通して出来たautoexec.batに相当するfdauto.batの最後尾部がこちら

実行速度はかなり速いが明日にでもいくつかのソフトで比較してみたい。




2023年1月10日火曜日

レトロなPC環境における基本的な開発言語

 結論から書こう、それはc言語

ついでに言うなら補いとしてアセンブラも使いたい。
とくにcp/mやmsxにも手を広げようとするときにc言語だけでは大きなソースをコンパイルできなかったりするようなのでアセンブラで細かい部分を書くことも必要になるだろう。

またmsdos系でもpc98のlioを扱うときなどはアセンブラの方が効率が良いだろう。

他のCPU(avr,pic,arm cortex,etc)を扱うときもcで書ければ具合が良いしあんまり書かないと思うけどwindowsのソフトも書ける。

当面はdos/x系とpc98系のエミュでlis-c試食版を使って書いていきたいと思う。
その際にマンデルブロー集合をはじめとするグラフィックは欠かせないと思うので簡易で良いので共通のグラフィックライブラリーが欲しいところだ。
当面は環境や母艦でのクロスコンパイルの準備を進めていこう。
(と、言いつつlzhを展開してパスを通すだけなのでlsi-c試食版のemu上の環境はもうできたんだけど)win側でどうするのかを考えていきたい。

そう言えばvmwareのfreedosでまだ日本語の表示機能を設定してなかったので次はそれについて書くつもり。

2023年1月4日水曜日

DOS環境のエミュの速度と環境への考察(なんつて)

 まずは手持ちのエミュたちで簡単なベンチマークを取った。

手持ちの母艦環境はwindows11のPCとmacbook 2013laterのpro(mojave)
同じdosbox-xでもwindowsだと日本語k/bに対応してるけどmacだと・・
日本製のDOS時代のcpuの速度を見るのがcpubenchでibm-pcでしか動かないのがspeedtst
rateはcpubenchが初代pc9801に対して何倍の速さかを示しspeedtstの方はibm-pc xtに対してのそれ(たまたまほとんど同じスペックのPC比なので同列に見ても良いと思うのだが微妙に比率が異なるのが面白い)
dosbox系はcycles=maxで計測してみた。
実はちょっと測定時にズルをしていてibm-pcでしか動作しないspeedtstを動かすのにdosbox-xでは .confのmachineをpc98からvgaonlyとかに変えて計測している。(内部で本来ibm-pcの互換が98互換にするときにどの程度のオーバーヘッドがあるのかは不明)
普通のwindowsやmacのフォルダがエミュ側からもHDのように見えるのが開発をするのなら必須というかめっちゃ便利な機能。(これが無いと仮想フロッピーをユーティリティソフトを使って余計な手間をかけないとwindowsなど母艦側で見えない。)
dosvaxj3の素晴らしい点はもう一つあって単にzipを解いた状態で日本語の入力環境まで揃うのだけどそれが母艦のIMEを利用しているという点。これってちょっと日本語の入力をしだすとわかるけど本当の大事。
速度でいうとvirtualboxかと思うけど共有フォルダが普通に使えるという点でvmware+freeDos1.3はかなり評価が高いと思う。
自分としてはキーボードドライバーが不自由なmacは何かにつけてメインの開発環境というよりは一応こっちでも動きますよって感じの使い方になるのかしら・・

次はどんな開発言語を使うことになるのかを考えてみたい。
windowsでn88basic互換の新星(?)nl-basicって言うのも出てきたしね。
(ランダムファイルの互換性があれば面白いけどな)

2023年1月2日月曜日

エミュに求める速さ

 基本的にdosbox系のエミュレータには2つの速さが求められると思う。

1つはゲーム実行環境としてのdosboxなら元の実機に忠実な速さが良いかもしれない。
(ゲームにもよるが・・)
そして開発環境としてのdosboxつまりc言語のコンパイルをしたりする環境としてなら速度は速いに越したことはない。
dosboxは基本的にはpc-dosの実行環境だけどdosbox-xはPC98系のソフトのエミュレートも行える。そしてcyclesという実行速度調整のパラメータをmaxに設定すると大抵の実機よりも速い。

もう一つの重要な要素が母艦つまり親となるosとの連携能力かと思う。
つまり共有フォルダなどを通して変換なくファイルのやりとりができると開発環境として使い勝手が格段によくなる。
日本語の扱いを考えてもIMEの変換能力の差やwindowsなどで動くvscodeなどの使い慣れたエディタでプログラムの記述ができるのは実にありがたい。
DOS時代のFEPは今日のWindowsなどのIMEに比べると日本語の入力にかなり手間取る。

こうしたことを踏まえてとりわけ開発という分野でどんな環境を(遊びのためとはいえ)構築すると面白そうかをしばらく考察していきたい。

2023年1月1日日曜日

最初の投稿

 本日よりいにしえのPCに関する個人的な関心を書いて行きたい。

一応の方針としてはエミュレータを中心として古代の(とも言うべき)PCを対象に環境を作ったりその上で動くソフトを探したり少しソースを書いてみたりと気が向くままに行った試行の痕跡を備忘録的に残すこととする。

半年ほど前に手持ちのmacbook(osはmojave)の上でdosbox-xを動かしてみたことがあったのだがその時はPC98設定にしてもn88basicでグラフィックが出なかった。
今回全く同じ版だと思うdosbox-xで試したらなぜかグラフックを含めて動いたのでしばらくはmacの上でPC98のエミュをするのはこちらにしようかと思う。
(速度的なことだけに注目するとこのmacの上でvirtualboxでWindowsXPを動かしてその上でanex86を動かしたほうが何割か速いのだけど共有フォルダというか特定のフォルダをHDとしてマウントできるのでこちらの方を使うことにする。)

下はしばしば好んでベンチマーク代わりに動かすMandelbrot集合の描画の様子。
速度は結構遅いけどそれを言い出すと実機はさわれない。



現状での最も大きな課題はmacだとconfをPC98設定にしてもキーボードがus配列のままで記号系の入力がちょっと困るのだけどなんらかの解決策が見つかるまでは無理やり慣れで使うことにする。
(どっちみちfepを入れたりはしないので日本語は表示はできても入力できないのでc:にマウントしたフォルダ内で母艦側で編集とかして対応する。)

適当にCのコンパイラを探して使ってみたい気もするがmac上ではきついか?
明日からもちょっとずつ気の向くままに書こう。


月日が経つのは・・・

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