はんかつさん、mor さん、M.Kamada さんレスありがとうございます。
＞Oh!X 持ってるかな？＞TMK さん
Oh!X は毎月買っていたのですが、既に手元にはないのでした。(^^;
技術資料よろしくお願い致します。＞M.Kamada さん
TMK さん、こんにちは。
> 技術資料よろしくお願い致します。＞M.Kamada さん
ダウンロードのページに置いておきましたのでどうぞ。
M.Kamada さん、こんばんわ
> > 技術資料よろしくお願い致します。＞M.Kamada さん
>
> ダウンロードのページに置いておきましたのでどうぞ。
ありがとうございます！ 頂いて参ります。
また、レスを頂きました皆様、本当にどうもありがとうございました。
みなさんはじめまして。
資料ですが、電クの拾四號にありました。(AJOY.X のソース付き)
バイナリだけでもよければアフターバーナーにもおまけで入っています…。
あと、すぐ手に入る範囲では、田圃さんのページにサイバーマウスのドライバがあったはずです。（使用目的が違うので一部省略されているかもしれませんが）
# どうでもいいんですが、AJOY.FNC は見つかりませんでした。（たしかこれも AJOY.X の IOCS $F2 を使わずに自前で操作していたはず…）
mor さん、こんにちは。
> 資料ですが、電クの拾四號にありました。(AJOY.X のソース付き)
月刊電脳倶楽部 14 号、確認しました。
（パーフェクトコレクション 1 に入っています）
アナログジョイスティックドライバ AJOY.X と、そのソースと、
技術資料が載っていますね。
「シャープ提供」ということですが、パブリックドメイン
になっているので、あとで転載しておきますね。＞TMK さん
鎌田さん今晩は はんかつです。
皆さんお忙しいようなので書かせていただきます。
サイバースティックの資料ですが、
Oh!X 1989 年 7 月号 C 調言語講座 PRO-68K
「サイバースティックを使うのである」に載っております。
電脳倶楽部にものったはず。
補足が、Oh!X 1990 年 5 月号ラジコンスティックの製作及び
outside X68000 に掲載されています。
はんかつさん、こんにちは。
> 皆さんお忙しいようなので書かせていただきます。
> サイバースティックの資料ですが、
> Oh!X 1989 年 7 月号 C 調言語講座 PRO-68K
>「サイバースティックを使うのである」に載っております。
> 電脳倶楽部にものったはず。
Oh!X 1989 年 7 月号、確認しました。
故・祝一平氏の小気味良い文章に見覚えがありました。
> 補足が、Oh!X 1990 年 5 月号ラジコンスティックの製作及び
> outside X68000 に掲載されています。
補足情報まで確認ありがとうございます。
こちらは桑野さんが書かれていますね。
Oh!X 持ってるかな？＞TMK さん
ごめんなさい、もっと楽に書けます。
#define ROL (data,n) (data << n | data >> (sizeof (data)*8 - n))
#define ROR (data,n) (data >> n | data << (sizeof (data)*8 - n))
ですね。ただし、data は unsigned 型じゃないといけません。
すいませんでした。
KQ さん、こんにちは。
> #define ROL (data,n) (data << n | data >> (sizeof (data)*8 - n))
> #define ROR (data,n) (data >> n | data << (sizeof (data)*8 - n))
>
> ですね。ただし、data は unsigned 型じゃないといけません。
おお、確かに gcc2 だとローテート命令になりますね。
ありがとうございます。
使うときは、マクロの名前の直後を詰めて、
式の中の data や n は括弧で括っておくとよろしいかと。
Charlie 版（2.6.3）では、16 ビットローテートが
swap になりませんでした。2.95.2 ではどうかな？
マクロの書き方にこだわってみました。:-)
/* ローテートマクロの定義（GCC 用）*/
/* data は unsigned であること */
#define ROL(data,n) ({ \
typeof(data) _data_ = (data); typeof(n) _n_ = (n); \
(_data_ << _n_ | _data_ >> (sizeof(_data_)*8 - _n_)); })
#define ROR(data,n) ({ \
typeof(data) _data_ = (data); typeof(n) _n_ = (n); \
(_data_ >> _n_ | _data_ << (sizeof(_data_)*8 - _n_)); })
KAMADA さん、KQ さん、こんにちわ。
gcc 上でのローテート命令の生成は 以前某所とか某所で質問したり
自分で色々やってみたんですがうまくいきませんでした (^^;
singned がらみかな？
結局その時は asm 文でローテート命令を直接記述する方法をとりました (汗
ちょっと引っぱり出して書きなおしてみてみます。
AC-YOUCH さん、こんにちは。
> gcc 上でのローテート命令の生成は 以前某所とか某所で質問したり
> 自分で色々やってみたんですがうまくいきませんでした (^^;
> singned がらみかな？
signed だったか、GCC が真里子版だった、かな？
ご指導ありがとうございます (^^。まさにそのとおりです。
>Charlie 版（2.6.3）では、16 ビットローテートが
>swap になりませんでした。2.95.2 ではどうかな？
ちゃんと swap を出力しますにょ。さすがに同じバージョンの
GCC のインテル CPU の最適化にはとてもかないませんが・・・。
ちなみに、もう G++ も Objective C もうごいてます。
(どっちも約一日で移植できました。)
あとは実機に持っていかなければいけないのですが、
C を移植するときよりは大変ではないんですぐ動くと思います。
Java はやっぱり難しいかなという感じです。コンパイラは
ともかく libgcj.a を書いてくれる人がいないんで。
OS の仕様とか、POSIX スレッドとか、GC とか・・・。
>
> signed だったか、GCC が真里子版だった、かな？
>
signed だと算術右シフト演算されてしまいますからね。
ashift 命令が内部で生成されると思うのでローテート命令には
なりません。ローテートなら最適化しなくても rotate,rotatert
が生成されると思います。こういうところは結構融通が利かないかもしれません。
高速インライン memcpy ルーチンを書いたときにちゃんと
型のサイズを判定してコピーするんでちょっとびっくりしました。
ソース上は 4 バイトごとにコピーしてるのに元が char 型だと 1
バイトずつコピーするっていう感じです。
インテル CPU だとこのサイズもできるだけ 4 バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。
くやし～(T^T;
ただし、そういうソースを書かなければいけないのだけど・・・。
KQ さん、こんにちは。
> ご指導ありがとうございます (^^。まさにそのとおりです。
あ、あれは、読んでいただいている皆さんのために
補足として書かせていただきました。
それから、説明を忘れてしまいましたが、マクロを
書き換えたのは ROR(*p++,1) のような場合に副作用
のある引数が 2 回評価されないようにするためです。
この手の原因のバグは発見しにくいので予防策です。
> ちゃんと swap を出力しますにょ。
えらいにょ。
> さすがに同じバージョンの
> GCC のインテル CPU の最適化にはとてもかないませんが・・・。
稼動実績が多いと進歩も速いのでしょうね。
> ちなみに、もう G++ も Objective C もうごいてます。
> (どっちも約一日で移植できました。)
> あとは実機に持っていかなければいけないのですが、
> C を移植するときよりは大変ではないんですぐ動くと思います。
もう慣れちゃってるって感じなのかなぁ。すごいです。
私は古い GCC の DSP56K 用のソースを拾ってきて cc1 だけ
X68k で動かしたことがありますが、最近のは複雑で…。
> Java はやっぱり難しいかなという感じです。コンパイラは
> ともかく libgcj.a を書いてくれる人がいないんで。
> OS の仕様とか、POSIX スレッドとか、GC とか・・・。
OS の仕様といっても、「そもそも OS の機能が少なすぎる」
なんてことになったりしないかな。
KQ さん、こんにちは。
> 高速インライン memcpy ルーチンを書いたときにちゃんと
> 型のサイズを判定してコピーするんでちょっとびっくりしました。
> ソース上は 4 バイトごとにコピーしてるのに元が char 型だと 1
> バイトずつコピーするっていう感じです。
68000 のアドレスエラーを避ける仕掛けが働いて
いるから？
68000 のときはソースとデスティネーションの
アドレスの奇遇が一致しているときと一致して
いないときで分けて、一致しているときだけ
ロングワード転送に。（常套手段）
> インテル CPU だとこのサイズもできるだけ 4 バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。
> くやし～(T^T;
GCC の最適化は、68K 用の最適化のノウハウが他の
アーキテクチャにも活用されていると聞いたことが
あります。
でもスーパースカラのスケジューリングに関しては
68K 以外のアーキテクチャのほうが対応が進んでいる
のでしょうね。
> ただし、そういうソースを書かなければいけないのだけど・・・。
結局、C のソースを書く人間がコンパイル結果を
予測できるようでないと、コンパイラの最適化は
最高の結果をもたらすことができないと思います。
最適化が最高の結果でなくても多くの人は満足して
しまいますが、私は満足できない人です。
> 68000 のアドレスエラーを避ける仕掛けが働いて
> いるから？
> 68000 のときはソースとデスティネーションの
> アドレスの奇遇が一致しているときと一致して
> いないときで分けて、一致しているときだけ
> ロングワード転送に。（常套手段）
>
インラインアセンブラを使っているわけではないので、
ソース上はそうなっているんですが・・・。
>
> GCC の最適化は、68K 用の最適化のノウハウが他の
> アーキテクチャにも活用されていると聞いたことが
> あります。
GNU ツールは元々 Motrola 68000 シリーズとナショナル
セミコンダクタの 32000 シリーズをベースにサポートされる
ので 68000 のコードの出力は多分一番最初の GCC からあった
はずです。たぶんそれをもとにいろいろな CPU へ移植された
のでしょう。
>
> 結局、C のソースを書く人間がコンパイル結果を
> 予測できるようでないと、コンパイラの最適化は
> 最高の結果をもたらすことができないと思います。
> 最適化が最高の結果でなくても多くの人は満足して
> しまいますが、私は満足できない人です。
効率、移植性や再利用が必要かどうかなどによるでしょう。
私にいわせると C++ はいらないとなってしまいますしね (^^。
OOP をしたいならシンプルな Objective C で十分ですから。
でも、「選択肢は多い方がよい」というのが私の最終的な結論です。
Kamada さんどうも
>
> もう慣れちゃってるって感じなのかなぁ。すごいです。
> 私は古い GCC の DSP56K 用のソースを拾ってきて cc1 だけ
> X68k で動かしたことがありますが、最近のは複雑で…。
>
DSP56K って最近のリリースには含まれてません。
もしあるとしたらどこにありますか ?
(dsp16xx ならあるけど・・・)
>
> OS の仕様といっても、「そもそも OS の機能が少なすぎる」
> なんてことになったりしないかな。
どうなんでしょう ?FreeBSD でもソースにぱっちをあてないと動か
ないくらいなので現状では GCJ は Linux しかサポートしていないん
でしょう。
KQ さん、こんにちは。
> インラインアセンブラを使っているわけではないので、
> ソース上はそうなっているんですが・・・。
(char)→(int) のキャストが効かないということ？
やはり GCC のアドレスエラーを避ける仕掛けが強すぎるのかな？
> > 最適化が最高の結果でなくても多くの人は満足して
> > しまいますが、私は満足できない人です。
>
> 効率、移植性や再利用が必要かどうかなどによるでしょう。
効率、移植性や再利用を考えても、「どこで満足するか」
ではなくて「どこで妥協するか」になってしまうのが
私の性分でして。不便な性分（笑）です。
> 私にいわせると C++ はいらないとなってしまいますしね (^^。
> OOP をしたいならシンプルな Objective C で十分ですから。
> でも、「選択肢は多い方がよい」というのが私の最終的な結論です。
そうですね。選択肢が多いのはよいと思います。
好きな選択肢が消えてゆくのは寂しいです。
KQ さん、こんにちは。
> DSP56K って最近のリリースには含まれてません。
> もしあるとしたらどこにありますか ?
> (dsp16xx ならあるけど・・・)
Motorola がポートした GCC なので、マイナーなバージョン
なのだと思います。MAC 命令や並列転送も吐きます。
Google などで「DSP56K GCC」を検索すれば出てきます。
http://www.idiom.com/free-compilers/
から辿るのがわかりやすいかも知れません。
2 月 24 日の日記も参照されたし。
始めまして、KQ です。
満開ネットではレスありがとうございました。
> 他に C で効率が悪くなることと言えば、「ローテート命令を
> 使いたいとき」とか。
これは 68000 の GCC(1～2.6.3) での話ですよね？
最近のコンパイラならどのコンパイラでも
#define ROL(data,n,type) (data<<n|data>>(sizeof (type)*8-n))
#define ROR(data,n,type) (data>>n|data<<(sizeof (type)*8-n))
でローテート命令を出力できます。
（式がミスっていたらごめんなさい）
もちろん、GCC 2．95.2 でも出力可能です。
シフト命令、ローテート命令の最適化テンプレートはかなり
増えているんで、以前に比べるとそこそこいいコードを出力
すると思います。
始めまして、TMK と申します。
サイバースティックの資料を探しているのですが、お持ちの方はいらしゃいますでしょうか？
アタリポートの信号制御方法とか、X68 のレジスタの制御方法とか。。
すみません、このネタは昔書いた資料の中にあったものを
再検証せずに上げてしまいました ｡
今再度調べたところ、
・画面右端で表示すると (0,y+1) とならず (画面幅 ,y) となる
・そのまま表示を続けると次の座標が (1,y+1) になる
でした (v1.2 ROM にて）。
B_LOCATE に (画面幅 ,y) を与えると無視されます ｡
また、その位置で改行させたいときは 0x0d のみでいけます。
（0x0a は不要 ｡)
情報は間違ってましたが、(0,y+1) が存在しないのはやはり
おかしいです ｡
当時 X1 でも開発をよくしていたもので、このような座標の変化は
「バグ以外の何者でもない !!」と思っていたのでした ｡
（X1 ではちゃんと 0,y+1 になります。）
ということで、上げたものは間違いですので出来れば、
削除してください ｡
LeDA さん、こんにちは。
> 今再度調べたところ、
>・画面右端で表示すると (0,y+1) とならず (画面幅 ,y) となる
>・そのまま表示を続けると次の座標が (1,y+1) になる
> でした (v1.2 ROM にて）。
画面の右端まで表示したときに、次の文字を表示するまで
改行を遅延させるのが X68000 の IOCS の仕様なのだと思います。
コードを見ても、わざわざそうなるように書かれています。
少なくともコーディングのバグによる挙動ではありません。
そのような仕様になっている主な理由は、「画面の
右下隅に文字を表示しやすくするため」だと思います。
> B_LOCATE に (画面幅 ,y) を与えると無視されます ｡
B_PUTC や B_LOCATE が (画面幅 ,y) を返すのに、
B_LOCATE にその座標を与えられないのは変ですね。
この点は仕様バグと言ってよいと思います。
> また、その位置で改行させたいときは 0x0d のみでいけます。
>（0x0a は不要 ｡)
改行に限らず、カーソルが (画面幅 ,y) にあるときは
カーソルが (0,y+1) にあるときと同じ挙動をするように
作られています。
改行を遅延させているだけなのですから当然ですね。
> (0,y+1) が存在しないのはやはりおかしいです ｡
> 当時 X1 でも開発をよくしていたもので、このような座標の変化は
>「バグ以外の何者でもない !!」と思っていたのでした ｡
>（X1 ではちゃんと 0,y+1 になります。）
確かにカーソルが画面外の座標を示すのは不自然ですよね。
「画面の右下隅に文字を表示したいとき」以外に
これといった効能はなさそうですし。
未公開機能と仕様バグの分類に悩んでしまいます。
ついでなので、バグに近い仕様に付いてもう 1 つ ｡
Human のファイル名比較は、標準では 8+3 バイトなので、
以下のようなファイル名は同じとみなされます ｡
123456_ ８
123456_ ９
このとき、' ８ ' は 0x8257,' ９ ' は 0x8258 なので、
8 バイト目になる 0x82 までが一致しているので
同じと判定されるわけです ｡ ファイル名だけ見れば
絶対に違うはずなのになぜ一致してしまうのか、
昔これでえらく悩んでしまいました ｡
TwentyOne 導入後はなくなりましたが。
Human 上では常識かもしれませんが、忘れている人も多いと
思いましたので一応書きました ｡
・・・バグじゃないけど隠れ仕様みないな情報がいくつか
あるんですけど、そういうの書く気ないですか ?＞Kamada さん
LeDA さん、こんにちは。
>・・・バグじゃないけど隠れ仕様みないな情報がいくつか
> あるんですけど、そういうの書く気ないですか ?＞Kamada さん
未公開機能は未公開機能として分類します。
「仕様なのかも知れないけれど、正しい挙動とは思えない」
というときは、「仕様バグ」として不具合情報に含めます。
「仕様バグ」かどうかは、独断と偏見も交えて判断します。
未公開機能がバグっているときは不具合情報にも入れます。
例えば MC68030 のデータキャッシュのライトアロケーション
モードの変な挙動は、マニュアルに明記されていますが、
仕様バグだと思います。
もしかしたら公開機能だったかもしれませんが
ＬＥＤの明るさを調節するモードってありませんでしたっけ？
勘違いかな？
AC-YOUCH さん、こんにちは。
> もしかしたら公開機能だったかもしれませんが
> ＬＥＤの明るさを調節するモードってありませんでしたっけ？
キーボード制御コードの $54～$57 ですが、これはシャープが
資料を提供している「X68000 データブック」に書いてあるので、
未公開ではないと判断しました。
他にも気付いたところがありましたら教えて下さい。
よろしくです。
鎌田さん、こんばんは。
ＩＰ接続サービスで常時接続できない問題は、
Ｃマガジン８月号の「フィンローダのあっぱれご意見番」
にも書かれています。鎌田さんの日記を読んで思い出し
ました。フィンローダ氏は「１ヶ月ほどの間に２回経験
している」そうです。せっかくの常時接続サービスなの
ですから、きちんと対応してほしいですね。
それではまた。
広井さん、こんばんは。
> ＩＰ接続サービスで常時接続できない問題は、
> Ｃマガジン８月号の「フィンローダのあっぱれご意見番」
> にも書かれています。鎌田さんの日記を読んで思い出し
> ました。フィンローダ氏は「１ヶ月ほどの間に２回経験
> している」そうです。せっかくの常時接続サービスなの
> ですから、きちんと対応してほしいですね。
あ、やっぱり問題になっていますか。
356 日接続しっぱなしにできるようにするためには
システムの保守のやり方を根本的に変えなければならず、
そこまで対応できていないということなのではないかと
思います。（憶測です）
そうでなければフレッツ・ISDN に対応したプロバイダが
これほど急激に増えるはずがありません。
結局、フレッツ・ISDN は、常時接続サービスではなくて、
単なる料金定額サービスらしい、ということで。
それにしても、接続がいきなり切れて困るのは従量制でも
定額制でも同じことなので、せめてどういう条件で切れる
のかはっきりさせて、接続開始から一定の時間は切れない
ようにするなどの工夫をして欲しいです。
まあ、今一番の不満は「64k は遅い」ということですけど。
鎌田さん、こんにちは。
日記を読んでいてフと思い出しましたが、たしか OPT2 押しながら
起動すると何か良い事（？）があったような。僕でも知っている
ので未公開じゃないと思いますが…。
記憶がほとんどないですが、確か ROM デバ (?) だったかなんだった
か…X68 が２台あると幸せ (?) になれるとかなれないとか。
何だったかなぁ…。
春麗さん、こんにちは。
> 日記を読んでいてフと思い出しましたが、たしか OPT2 押しながら
> 起動すると何か良い事（？）があったような。僕でも知っている
> ので未公開じゃないと思いますが…。
> 記憶がほとんどないですが、確か ROM デバ (?) だったかなんだった
> か…X68 が２台あると幸せ (?) になれるとかなれないとか。
>
> 何だったかなぁ…。
ROM デバッガですね。
ROM デバッガは存在そのものが未公開だと思います。
ROM デバッガは起動方法が 3 通り（手動も含めると 4 通り）
あります。
こんにちは。
> ROM デバッガですね。
> ROM デバッガは存在そのものが未公開だと思います。
あぁ、やっぱりＲＯＭデバでしたね。家に帰ってから調べてみま
した。いや、なんか妙～に気になってたもので（笑）。【プログ
ラマーのためのＸ６８０００環境ハンドブック】に載ってました。
いやはや、これでグッスリ眠れます。
学生の頃はアセンブラしかできなかったので、よく参照していま
した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」
なんて、ちょっと感慨深いものを感じました。今じゃ、Ｃ言語
にどっぷり頭まで浸かっています。ははは…
春麗さん、こんにちは。
> 学生の頃はアセンブラしかできなかったので、よく参照していま
> した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」
> なんて、ちょっと感慨深いものを感じました。今じゃ、Ｃ言語
> にどっぷり頭まで浸かっています。ははは…
同じように C を理解しているつもりでも、アセンブラの
経験があるかどうかで C の理解度は大きく差がつきます。
C を使うとき、「アセンブラの経験がない人には負けない」
という自信を持ちましょう。
たとえ C の海にどっぷり浸かっていても、アセンブラは
いつもその足元、海の底のほうに広がっているものです。
その海に潜れる深さが C への理解の深さです。
ときどき底まで潜ってみてはいかが？
海底散歩も楽しいかも知れません。
こんにちは。
> 同じように C を理解しているつもりでも、アセンブラの
> 経験があるかどうかで C の理解度は大きく差がつきます。
先日の日記にもありましたが（関数のポインタへの配列の
定義うんぬん）、初心者の頃はポインタの代入や計算で、
よくワーニングを出して、その度に、
「move.l d0,a0 でいいやん、move.l d0,a0 で！」
「キャストめんどくせー！」
とかいろいろ唸ってました（笑）。
> ときどき底まで潜ってみてはいかが？
> 海底散歩も楽しいかも知れません。
制作中の 2D 格ゲーでは、スプライトダブラ（358 個だからダ
ブラじゃないか…）などの肝心な部分は海底を歩いてます。
でも、ヘボなので、ノーマル X68 での動作保証は諦めました。
※060turbo 使ってると、速度感覚がマヒします（苦笑）。
春麗さん、こんにちは。
> 先日の日記にもありましたが（関数のポインタへの配列の
> 定義うんぬん）、初心者の頃はポインタの代入や計算で、
> よくワーニングを出して、その度に、
>
>「move.l d0,a0 でいいやん、move.l d0,a0 で！」
>「キャストめんどくせー！」
>
> とかいろいろ唸ってました（笑）。
あるある。
それでキャストをつけまくる癖がついてしまい、今度は
他の人に「お前、キャスト多すぎ」なんて批判されたり。
-Wall で Warning が出ないようにすることに燃えてしまい、
ふと気付くと効率の悪いプログラムになっていたり。
「関数へのポインタの配列の定義」は、Warning どころか
Error になってしまう人が結構いるのではないかと。
> 制作中の 2D 格ゲーでは、スプライトダブラ（358 個だからダ
> ブラじゃないか…）などの肝心な部分は海底を歩いてます。
スプライトダブラもハードの限界を超える発想ですよね。
水平 32 個の限界があるので、スプライトの数を増やす
だけでなく、どのように並べるかも工夫が必要ですね。
> でも、ヘボなので、ノーマル X68 での動作保証は諦めました。
>※060turbo 使ってると、速度感覚がマヒします（苦笑）。
10MHz の 68000 と 50MHz の 68060 ではワーストケースで 100 倍
以上の速度差がありますから、68000 で動かすものを 68060
で作ると、動作速度の違いに愕然とすることがありますね。
68060 で I/O の書き込みウェイトを活用して最適化した
プログラムは、68030 でさえ這うように遅くなります。
こんにちは。
> -Wall で Warning が出ないようにすることに燃えてしまい、
> ふと気付くと効率の悪いプログラムになっていたり。
エッ、そうなんですか。僕は、Wall つけてコンパイルしてい
ますが、特に速度的に効率が悪いとは感じた事はないです。
重要なループ以外は、最適化を気にせず組んでます。
>「関数へのポインタの配列の定義」は、Warning どころか
> Error になってしまう人が結構いるのではないかと。
僕も一発コンパイルは自信がないです（プログラマなのに）。
void (*proc[])( void *arg ) = { foo1, foo2, foo3....};
こ、こんな感じでしょうか。何も見てないので自信ないです。
> スプライトダブラもハードの限界を超える発想ですよね。
> 水平 32 個の限界があるので、スプライトの数を増やす
> だけでなく、どのように並べるかも工夫が必要ですね。
済みません、358 個じゃなくて 384 個の間違いでした。ダブラ
エンジンを開発した当時は既に XSP があったのですが、XSP は
一切参考にしませんでした（下らないプライドですが）。
で、後から、ドキュメントを見てみると、管理方法や高速化、
問題点などほぼ同じでした。やはり考える事は同じなんだなぁ
と思いました（ベースとなる原理が同じなので当然ですが）。
でも、僕のダブラの完成度は XSP の足元にも及びません（苦笑)。
春麗さん、こんにちは。
> エッ、そうなんですか。僕は、Wall つけてコンパイルしてい
> ますが、特に速度的に効率が悪いとは感じた事はないです。
> 重要なループ以外は、最適化を気にせず組んでます。
コードの効率というよりもデータ構造の効率を考えたとき、
C の文法の範囲で表せないデータ構造を使いたくなることって
ありません？
アセンブラで書くようなデータ構造を C で模倣しようとして
union やビットフィールドを使って無理矢理書いたものの、
Warning をなくすことができず、結局無駄の多いデータ構造に
変更してしまったりして、「ああ、ぬるい、ぬるすぎる…」
なんて嘆いたり。
他に C で効率が悪くなることと言えば、「ローテート命令を
使いたいとき」とか。
> 僕も一発コンパイルは自信がないです（プログラマなのに）。
> void (*proc[])( void *arg ) = { foo1, foo2, foo3....};
> こ、こんな感じでしょうか。何も見てないので自信ないです。
お見事。
この場合、関数へのポインタの配列の参照は
proc[n](＆arg);
ですが、定義のときだけ必要になる括弧を間違えやすい
と思います。
> 済みません、358 個じゃなくて 384 個の間違いでした。
あ、やっぱり。中途半端な数だなぁとは思いました。（笑）
> ダブラエンジンを開発した当時は既に XSP があったのですが、
> XSP は一切参考にしませんでした（下らないプライドですが）。
> で、後から、ドキュメントを見てみると、管理方法や高速化、
> 問題点などほぼ同じでした。やはり考える事は同じなんだなぁ
> と思いました（ベースとなる原理が同じなので当然ですが）。
> でも、僕のダブラの完成度は XSP の足元にも及びません（苦笑)。
XSP は汎用性を持った完成度の高いものですよね。
でも、384 出せればたいしたものだと思います。
X68000 版の「キャメルトライ」は偉大でした。
それを再現できるエミュレータも凄いと思います。
鎌田さん、春麗さん、こんにちは。
アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
と思っていたのですが、それも怪しくなってきました。
関数へのポインタの配列は、けっきょく、Ｚしーモンキー
を見て確認しました（苦笑）。うーん、あの頃はパワーが
あったなあ。最近、Perl を使うことが多かったので、
すっかり堕落したようです（笑）。リハビリしないとダメ
ですね。
それではまた。
広井さん、こんにちは。
> アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
> と思っていたのですが、それも怪しくなってきました。
普段使っていないと忘れてしまいますよね。
「関数へのポインタの配列」は機能番号からサブ
ルーチンを選択する場合などに使いますが、あまり
使用頻度は高くないかも知れません。
> 最近、Perl を使うことが多かったので、
> すっかり堕落したようです（笑）。
Perl は強烈な省略言語ですからねぇ。
あればっかりじゃ…。
広井さん、鎌田さん、こんにちは。
> > アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
> > と思っていたのですが、それも怪しくなってきました。
>
> 普段使っていないと忘れてしまいますよね。
僕は、BASIC はもうスッカリ忘却の彼方です。OK の
あとに”.”ピリオドがついてたらコンティニュー
可能とかツマンナイ事しか覚えてません（笑）。
でも、アセンブラって月日が経っても命令表さえあ
れば何とかなりますよね（自転車と同じで）。それ
に何か一つでも（極めずとも）それなりに習得して
おけば、違う CPU でも何とかなりますよね。
僕は Z80 と 68k しかやっていなくても、8086 の仕事は
できたし（セグメントはイヤでしたが）、VU の最適
化も楽しめました。
>「関数へのポインタの配列」は機能番号からサブ
> ルーチンを選択する場合などに使いますが、あまり
> 使用頻度は高くないかも知れません。
数が少なければ switch でササッと書けるし、その
方が追加や変更など都合の良い場合もありますから。
特に、見た目に分かり易いですし（スパゲッティは
論外ですが)。
個人主観ですが、見た目は重要だと思っています
（速度重視の場合は仕方ないですが）。
春麗さん、こんにちは。
> それに何か一つでも（極めずとも）それなりに習得
> しておけば、違う CPU でも何とかなりますよね。
そうですね。どの CPU にしても原理的には同じ（フォン
・ノイマン・アーキテクチャ）なので、ひとつの CPU で
マシン語プログラムが組める人は、ほかの CPU でも何とか
なるでしょう。
> 僕は Z80 と 68k しかやっていなくても、8086 の仕事は
> できたし（セグメントはイヤでしたが）、VU の最適
> 化も楽しめました。
私の場合、マシン語は Z80 -> 8068 -> 68k と経験
しましたが、68k に触れた時は目からウロコが落ちま
した（笑）。
> 個人主観ですが、見た目は重要だと思っています
>（速度重視の場合は仕方ないですが）。
メンテナンスを考えれば、ソースは読みやすいほうが
よろしいかと思います。
春麗さん、広井さん、こんにちは。
> そうですね。どの CPU にしても原理的には同じ（フォン
>・ノイマン・アーキテクチャ）なので、ひとつの CPU で
> マシン語プログラムが組める人は、ほかの CPU でも何とか
> なるでしょう。
確かに、アーキテクチャが違っても基本的な考え方は
同じなので、何とかなる場合が多いと思います。
しかし、アーキテクチャにはそれぞれ個性があるので、
私はその個性を大事にしたいです。
プロセッサ関連のリンクを増やしているのは、
「プロセッサにはいろいろなアーキテクチャがある」
ということを知ってもらいたいためでもあります。
鎌田さん、こんばんは。
> > マシン語プログラムが組める人は、ほかの CPU でも何とか
> > なるでしょう。
>
> 確かに、アーキテクチャが違っても基本的な考え方は
> 同じなので、何とかなる場合が多いと思います。
> しかし、アーキテクチャにはそれぞれ個性があるので、
> 私はその個性を大事にしたいです。
そのとおりですね。コンパイラを使うにしても、最適化
技術が進歩しているとはいえ、使用する CPU のアーキ
テクチャを理解していないと、凄いプログラムは作れない
と思います。まあ、私が作るプログラムは軟弱なものばかり
なので、偉そうなことは言えませんが（笑）。
STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、
興味深いリンクが多いですね。画像検索エンジン Charlotte
は、画像ファイルのプレビューが表示されるので、とても
便利です。これからも期待しています。
それではまた。
広井さん、こんにちは。
> > しかし、アーキテクチャにはそれぞれ個性があるので、
> > 私はその個性を大事にしたいです。
>
> そのとおりですね。コンパイラを使うにしても、最適化
> 技術が進歩しているとはいえ、使用する CPU のアーキ
> テクチャを理解していないと、凄いプログラムは作れない
> と思います。まあ、私が作るプログラムは軟弱なものばかり
> なので、偉そうなことは言えませんが（笑）。
「アーキテクチャを知る必要がある」ということよりも、
単純に「このアーキテクチャを考えた人は凄い！って
思えるようなアーキテクチャがいろいろあって面白い」
という理由で、私はマイクロプロセッサのアーキテクチャ
に興味を持っています。
いずれは自分で設計してみたいし。
> STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、
> 興味深いリンクが多いですね。画像検索エンジン Charlotte
> は、画像ファイルのプレビューが表示されるので、とても
> 便利です。これからも期待しています。
ありがとうございます。
Charlotte は R.V.R.Homepage の
「ゲームプログラミング日記」で知りました。
私もロコちゃんは好きです。（笑）
X68 の未公開機能ですが、一時期ハマっていた
SX-WINDOW の .CGA ファイルに関する情報なら有ります。
IVM を隅々まで調べて作った資料だったりします。
私のページに有りますので、適当にリンクしてやって下さい。
P.S.
FSX.x の未公開コールとかも知ってるけど、
資料としてはまとめてないです (^^;
M.Suzuki さん、こんにちは。
> X68 の未公開機能ですが、一時期ハマっていた
> SX-WINDOW の .CGA ファイルに関する情報なら有ります。
> IVM を隅々まで調べて作った資料だったりします。
> 私のページに有りますので、適当にリンクしてやって下さい。
ありがとうございます。
SX-WINDOW 関係の資料は解析結果にもとづいているものが
多いですね。
> P.S.
> FSX.x の未公開コールとかも知ってるけど、
> 資料としてはまとめてないです (^^;
FSX.X を完全に解析した人って、何人くらいいるのかな。
私は、KeyWitch をやっていた頃に、キー入力回り
（SXCON.X を含む）を見たくらいです。
A-line 処理を高速化しようとして 68000 の変な挙動を発見
した頃から、興味の対象が FSX.X から逸れていきました。
こんにちは。
新しいページ、かっこよくなっていいですね。
ＣＧ文字のアンチも奇麗に見易くなってますし、
レイアウトもトータルイメージもいいです。
でもＣＧ文字はＢＭＰよりもＧＩＦファイルの方が
ページが軽くなっていいかもです。
１ファイル６ＫＢくらい（プロフィール、の文字）
ある文字だと、アナログモデムだとちょい辛いかもです。
あれなら２５６色で十分ですし。
こっちで試しにＧＩＦ化してみたら、半分くらいになりました。
ではでは。
みかぜさん、こんばんは。
> 新しいページ、かっこよくなっていいですね。
> ＣＧ文字のアンチも奇麗に見易くなってますし、
> レイアウトもトータルイメージもいいです。
ありがとうございますぅ。
> でもＣＧ文字はＢＭＰよりもＧＩＦファイルの方が
> ページが軽くなっていいかもです。
> １ファイル６ＫＢくらい（プロフィール、の文字）
> ある文字だと、アナログモデムだとちょい辛いかもです。
> あれなら２５６色で十分ですし。
> こっちで試しにＧＩＦ化してみたら、半分くらいになりました。
> ではでは。
にょにょ？ 画像は全部 GIF になってるにょ。
プロフィールの文字（profile.gif）は 3436 バイトだにょ。
> にょにょ？ 画像は全部 GIF になってるにょ。
> プロフィールの文字（profile.gif）は 3436 バイトだにょ。
プロフィールは今見直したら GIF でした。
申し訳ないです。私が見た時日記のＣＧだけフォント
タイプが違ってたから過渡期だった？？？
今見直した所、日記と更新記録はダウンロードすると
今も BMP になってしまいますが、これは……ＩＥのせい？
みかぜさん、こんばんは。
> プロフィールは今見直したら GIF でした。
> 申し訳ないです。私が見た時日記のＣＧだけフォント
> タイプが違ってたから過渡期だった？？？
> 今見直した所、日記と更新記録はダウンロードすると
> 今も BMP になってしまいますが、これは……ＩＥのせい？
IE の画像キャッシュの更新のタイミングが変なのかも。
diary.gif は 2115 バイト、history.gif は 3416 バイトです。
たびたびすいません
> IE の画像キャッシュの更新のタイミングが変なのかも。
あ～なんかその辺の可能性が高い気がしてきました。
先日キャッシュがとんだばっかりだし、
ちょっと前に見た時はレイアウトは変ってたけど、
背景が水色だったので……しばらく後でリロードを
かけたら黒になりました。
うむむ……とりあえず無意味な事いって混乱させましたね。
申し訳ないです。
みかぜさん、こんばんは。
> > IE の画像キャッシュの更新のタイミングが変なのかも。
>
> あ～なんかその辺の可能性が高い気がしてきました。
> 先日キャッシュがとんだばっかりだし、
> ちょっと前に見た時はレイアウトは変ってたけど、
> 背景が水色だったので……しばらく後でリロードを
> かけたら黒になりました。
CSS だけキャッシュの更新が遅れたのかな。
STUDIO KAMADA には BMP フォーマットの画像ファイルは
置いていない（更新中も含めてアップロードしていない）
ので、BMP になっていたらそれはキャッシュだと思います。
お使いのマシンの時計、あってますよね？（念のため）
うちの IE も以前キャッシュがおかしくなって、
キャッシュをすべて消去したことがあります。
キャッシュの機能がないとオフラインで読んだり
書いたりするときに不便ですが、キャッシュが悪さを
していると障害の原因がわかりにくくて困るんですよね。
> うむむ……とりあえず無意味な事いって混乱させましたね。
> 申し訳ないです。
いえ、たとえ間違っていたとしても、気付いたところを
報告していただけるのは嬉しいものです。
これからもよろしく。
KAMADA さんこんにちは。
> STUDIO KAMADA には BMP フォーマットの画像ファイルは
> 置いていない（更新中も含めてアップロードしていない）
> ので、BMP になっていたらそれはキャッシュだと思います。
そのようですね。早とちりしてしまいました。お恥ずかしい。
> うちの IE も以前キャッシュがおかしくなって、
> キャッシュをすべて消去したことがあります。
> キャッシュの機能がないとオフラインで読んだり
> 書いたりするときに不便ですが、キャッシュが悪さを
> していると障害の原因がわかりにくくて困るんですよね。
常時接続だから基本的に必要無いんですが、
いつも見ているページが、いざ、ふいに無くなってしまった
時などで、溜まっているキャッシュから無理矢理サルベージ
させる事があるので、あんまり切りたくないんですよね。
難しい所ですが。
ではでは。
みかぜさん、こんにちは。
> 常時接続だから基本的に必要無いんですが、
うちは昨日やっと（ほぼ）常時接続になりましたが、
回線速度が遅いので、最近見たページを開くのに
かかる時間がキャッシュの有無でだいぶ違います。
みかぜさんのところは常時接続でしかも回線速度が
速いんですよね。いいなあ。
> いつも見ているページが、いざ、ふいに無くなってしまった
> 時などで、溜まっているキャッシュから無理矢理サルベージ
> させる事があるので、あんまり切りたくないんですよね。
> 難しい所ですが。
なるほど。そういう使い方もありましたか。
IE のキャッシュの実体の部分がもうちょっと探しやすく
なっているとよかったかも。
鎌田さん、こんばんは。
STUDIO KAMADA にアクセスしたら、黒を基調とした
ホームページに変わっていたので、びっくりしました。
やっぱり X68000 は黒なのでしょうか。かっこいいです。
新しいバナー、輝いていますね。さっそくリンクで
使わせていただきます。
広井さん、こんばんは。
> STUDIO KAMADA にアクセスしたら、黒を基調とした
> ホームページに変わっていたので、びっくりしました。
> やっぱり X68000 は黒なのでしょうか。かっこいいです。
ありがとうございます！
X68000 だから黒というわけではないのですが、確かに
X68000 ユーザのページは背景が黒い所が多いですね。
> 新しいバナー、輝いていますね。さっそくリンクで
> 使わせていただきます。
よろしくです。
バナーの URL と大きさが以前と違うのでご注意下さいませ。
古いバナーも残してありますが、新しいのと比べると
やはりしょぼいバナーだったんだなぁと。（笑）
あ、五芒星の背景が水色のままだ。
ここに発表されている「XC の不具合｣ ですが、
＞IOCTRLFDCTL() が正常に動作しない
は XC の NewKit では修正されていると思います ｡
(DOS4413.S;93-09-15 12:00)
逆に、IOCTRLRTSET(DOS4411.S) にて
move.w #$11,-(sp)
というのが間違いで、
move.w #11,-(sp)
のはずです。
LeDA さん、こんにちは。
> ここに発表されている「XC の不具合｣ ですが、
>＞IOCTRLFDCTL() が正常に動作しない
> は XC の NewKit では修正されていると思います ｡
> (DOS4413.S;93-09-15 12:00)
>
> 逆に、IOCTRLRTSET(DOS4411.S) にて
> move.w #$11,-(sp)
> というのが間違いで、
> move.w #11,-(sp)
> のはずです。
情報ありがとうございます。早速、追記しておきます。
他にも気付いたところがありましたらご指摘下さい。
よろしくお願いします。
> LeDA さん、こんにちは。
>
> > ここに発表されている「XC の不具合｣ ですが、
> >＞IOCTRLFDCTL() が正常に動作しない
> > は XC の NewKit では修正されていると思います ｡
> > (DOS4413.S;93-09-15 12:00)
> >
> > 逆に、IOCTRLRTSET(DOS4411.S) にて
> > move.w #$11,-(sp)
> > というのが間違いで、
> > move.w #11,-(sp)
> > のはずです。
>
> 情報ありがとうございます。早速、追記しておきます。
> 他にも気付いたところがありましたらご指摘下さい。
> よろしくお願いします。
採用、ありがとうございます ｡
こんなマイナーなバグ、普通は見つからないのかもしれませんが、
たまたま自作のソフトで使う機会があったので見つけてしまいました (自作デバイスドライバのバグ取り中に)｡
私の知る限り、V2.1→NewKit での唯一のバグ取りです ｡
(追加ライブラリや __main.S の変更はありますが ｡)
LeDA さん、こんにちは。
> 採用、ありがとうございます ｡
> こんなマイナーなバグ、普通は見つからないのかもしれませんが、
> たまたま自作のソフトで使う機会があったので見つけてしまいました (自作デバイスドライバのバグ取り中に)｡
リトライ回数なんて普通は変更しませんからねぇ。
> 私の知る限り、V2.1→NewKit での唯一のバグ取りです ｡
> (追加ライブラリや __main.S の変更はありますが ｡)
XC のライブラリには結構バグがあったと思うのですが、
NewKit では修正されているところが多いかも知れませんね。
鎌田さん、こんにちは。
ページデザインが突然変わってたのでビックリしました ^^;。
クールな感じで良いですね。
で、日記にあったタイトルの件ですが、これ、確か BIOS 設定が
保存されている SRAM の内容のチェックサムエラーということだっ
たかと思います。
何かのタイミングで SRAM 内容が壊れたのか、若しくは SRAM 用の
バッテリがへたってるのかも知れません。
けんじょさん、こんにちは。
> ページデザインが突然変わってたのでビックリしました ^^;。
> クールな感じで良いですね。
早速のご感想、ありがとうございます！
ビックリしていただけで嬉しいです！
そろそろタイトル画像を変えたいなあと思って落書き
していたら、なんだかいい感じのが描けてしまったので、
急に変えてみたくなったの。(^^;
> で、日記にあったタイトルの件ですが、これ、確か BIOS 設定が
> 保存されている SRAM の内容のチェックサムエラーということだっ
> たかと思います。
> 何かのタイミングで SRAM 内容が壊れたのか、若しくは SRAM 用の
> バッテリがへたってるのかも知れません。
情報ありがとうございます。
なるほど。
最近、落雷対策と部屋の模様替えとハングアップのために
電源を切ったことが多かったから、電池切れなら納得。
そういえば、ふたを開けたときに、見慣れたボタン電池の
2032 が見えて、「こんな電池で大丈夫なんかいな」と
思ったんだっけ。
あのあとエラーは出ていないけれど、電池を取り替えて
おこうかなあ。
慎吾ママは実際に、おはスタに出演していました。
とわいえ私は当日談をその後の「サタスマ」で見ただけですが。
また堀江さんは実際に「ラジオ番組中に他のキャスターを肩叩きする」
なる罰ゲーム (？) を与えられて、「や、ほんと上手だったよ」と
冨永み○なさんに言わしめた人です (^^；
VFC-LINK さん、こんにちは。
> 慎吾ママは実際に、おはスタに出演していました。
> とわいえ私は当日談をその後の「サタスマ」で見ただけですが。
あ、やっぱり。
おはスタで「慎吾ママまた来てくれー」って叫んでいたので、
一度は出たんだなあと思っていました。
それで、そのあとほったらかし？ みたいな感じ。（笑）
> また堀江さんは実際に「ラジオ番組中に他のキャスターを肩叩きする」
> なる罰ゲーム (？) を与えられて、「や、ほんと上手だったよ」と
> 冨永み○なさんに言わしめた人です (^^；
ラジオですかぁ。う～ん、イメージ、イメージ。
ごほうびになでなでしてもらえたのかなぁ。（んなわけないか）
久しぶりです。こんばんは。
分かったーと思い答え合わせしたら、
数え間違いで９個しかできてないのに答え見てもーたぁ。
でも、もう少し考えていても、
あんなの思い付かなかったかったと思います。
できれば答えを見ずに一週間くらい悩みたかったところですが。
（あれをプログラムで解く方が、普通に紙と鉛筆で解くより難解だと思いました。）
M.Hayashi さん、こんにちは。
> 分かったーと思い答え合わせしたら、
> 数え間違いで９個しかできてないのに答え見てもーたぁ。
あー、そのパターンは悲しいかも。
他のかたも気をつけてくださいまし。
> でも、もう少し考えていても、
> あんなの思い付かなかったかったと思います。
アプローチの仕方を一度思い込んでしまうと、
なかなかそこから抜け出せないんですよね。
> できれば答えを見ずに一週間くらい悩みたかったところですが。
私は高校生の頃に、ある数学の証明問題を 10 日かけて
解いたことがあります。
時間がかかればかかるほど、最終的に解けたときの
喜びは大きくなりますね。
フェルマーの最終定理の証明は 350 年かかったそうで。
>（あれをプログラムで解く方が、普通に紙と鉛筆で解くより難解だと思いました。）
完璧なプログラムが書ける頃にはプログラムの注釈に
答えが書いてありそうな気もしますね。（笑）
しかし、「アルゴリズムは穴だらけだけれど、答えが
見つかればラッキー」くらいの気持ちでプログラムを
書いてみるのも、ひとつのアプローチだと思います。
特に、アタマで考えていて煮詰まってしまったときは。
プログラムで答えが見つからなくても、「答えは
こういうパターンではない」ということがわかるので、
ヒントが得られるかも知れません。
鎌田さん、どうもです。
すいません、五芒星の問題ですが数え間違いました。
うーん、はずかしいよう（泣）。
ここで、ギブアップします。答え教えてください（笑）。
それでは。
広井さん、こんにちは。
> すいません、五芒星の問題ですが数え間違いました。
あらら、残念。
> ここで、ギブアップします。答え教えてください（笑）。
では、そろそろ答えを発表することにしますか。
もう少し粘ってみようという人は見ないようにしてください。
五芒星の問題の答え
http://homepage2.nifty.com/m_kamada/gif/pentagram_a.gif
鎌田さん、こんにちは。
> では、そろそろ答えを発表することにしますか。
> もう少し粘ってみようという人は見ないようにしてください。
>
> 五芒星の問題の答え
> http://homepage2.nifty.com/m_kamada/gif/pentagram_a.gif
なるほど（ポンと手を打つ）、これは一本とられました。
これだからパズルはやめられませんね（笑）。
十分に楽しませてもらいました。
ありがとうございます。
鎌田さん、こんにちは。僕は、未だに X68 で 2D 格ゲーなんぞを作ろう
としている、諦めの悪い春麗と申す者です（060turbo 使ってます）。
五芒星の問題、やっと解けました。休憩時にこれを会社で見たのが間
違いでした。その時はちょっとトライしてみて３分では解けなかった
ので、すぐに意味を終了して仕事に戻りました。が、何故か五芒星の
問題が頭の中でグルグルしてロクに仕事が手に付きませんでした。
耐え切れず、画像を Paint で貼り付けて、直線ツールであーでもな
いこーでもないと悩み続けて…なんかパズルの合間に仕事やってたよ
うな…（苦笑)。
「絶対、線分の交点を通り三角形を二分する直線を引くはずだ」など
と自分の思い込みにハマっていたのですが、何気なく引いたら１０コ
できました。
日記でこれをプログラムで解いたとありますが、僕にはサッパリ分か
りませんでした。パズルの解法関係の知識が皆無とはいえ、プログラ
マとして恥ずかしい限りです。しょぼーん。
春麗さん、こんにちは。
> 鎌田さん、こんにちは。僕は、未だに X68 で 2D 格ゲーなんぞを作ろう
> としている、諦めの悪い春麗と申す者です（060turbo 使ってます）。
夢や目標は簡単に捨てられるものではありませんよね。
エミュレータもどんどん良くなっていることですし、
頑張って作ってください。
> 五芒星の問題、やっと解けました。
やった！ 報告第 1 号です！
> 休憩時にこれを会社で見たのが間
> 違いでした。その時はちょっとトライしてみて３分では解けなかった
> ので、すぐに意味を終了して仕事に戻りました。が、何故か五芒星の
> 問題が頭の中でグルグルしてロクに仕事が手に付きませんでした。
> 耐え切れず、画像を Paint で貼り付けて、直線ツールであーでもな
> いこーでもないと悩み続けて…なんかパズルの合間に仕事やってたよ
> うな…（苦笑)。
いやー、すっかりハマらせてしまいましたね。
このパズル、有害だったかなあ。（笑）
>「絶対、線分の交点を通り三角形を二分する直線を引くはずだ」など
> と自分の思い込みにハマっていたのですが、何気なく引いたら１０コ
> できました。
おお、いいヒントが出ました。
他の人も挑戦してみてください。
> 日記でこれをプログラムで解いたとありますが、僕にはサッパリ分か
> りませんでした。パズルの解法関係の知識が皆無とはいえ、プログラ
> マとして恥ずかしい限りです。しょぼーん。
落ち込むことはありませんよ。
五芒星の問題はコンピュータにやらせるには少々
とっつきにくいのですが、あまり難しく考えることは
ありません。
「五芒星に直線を 2 本描き加えた図形」の中にある
「内側に線を含まない三角形」を数えるためには、
「五芒星に直線を 2 本描き加えた図形」をどのような
データ構造で表現しておくと都合がよいか、考えて
みてください。
直線は通過点を 2 個所固定すれば一意に定まります。
2 個所の通過点の選び方はさほど多くはありません。
2 本目の直線の通過点の候補は 1 本目と少し違います。
鎌田さん、こんにちは。
すっかりはまっていた五芒星の問題、
やっと解けました！ とてもうれしいにょ（笑）。
五芒星の内部を分割するだけでは解けないところがポイント
ですね。とても面白いパズルです。
五芒星のパズルでは、数字を配置する問題もあります。
頂点と交点が１０ヵ所ありますが、そこに 1 から 10 までの
数字を配置します。すると、直線上に４つの数字が並びますが、
その和が n 本の直線で等しくなるような配置を求めます。
３本の直線で等しくなる配置は、ある本で見かけたことが
ありますが、５本の直線全部が等しくなる配置はあるので
しょうか？ もしかすると、解がないかもしれません。
そのうちに挑戦してみようと思います。
広井さん、こんにちは。
> ３本の直線で等しくなる配置は、ある本で見かけたことが
> ありますが、５本の直線全部が等しくなる配置はあるので
> しょうか？ もしかすると、解がないかもしれません。
> そのうちに挑戦してみようと思います。
3 分間プログラミングでてきとーに調べてみたのですが、
5 本全部等しくすることは不可能ではないかと。
力ずくではなくてスマートに証明できないかなあ。
鎌田さん、こんにちは。
> 3 分間プログラミングでてきとーに調べてみたのですが、
> 5 本全部等しくすることは不可能ではないかと。
> 力ずくではなくてスマートに証明できないかなあ。
五芒星では解がないとのこと、調査ありがとうございます。
スマートに証明できると凄いですね。
ちなみに、六芒星の場合は解があります。
パズル雑誌では、マジックスターという名前のパズルで
登場することがあって、プログラムしたことがあります。
六芒星の場合、1 から 12 までの数字を配置しますが、
自分が調べた結果では、重複解をのぞくと 80 通りの解を
見つけました。解はもっと少ないと思っていたので、
意外な結果でした。
それではまた。
広井さん、こんにちは。
> 五芒星では解がないとのこと、調査ありがとうございます。
ちなみに、4 本までならできます。
1+3+9+10=23
10+2+6+5=23
5+7+3+8=23
8+9+2+4=23
4+6+7+1=18
とか。
4 本のとき何通りできるかは数えてみていません。
鎌田さん、こんにちは。
> ちなみに、4 本までならできます。
> 1+3+9+10=23
> 10+2+6+5=23
> 5+7+3+8=23
> 8+9+2+4=23
> 4+6+7+1=18
> とか。
> 4 本のとき何通りできるかは数えてみていません。
私もプログラムしてみました。数字の配置にたいする
回転解や鏡像解を除くと、168 通りの解を見つけました。
プログラムは私のＨＰで公開する予定なので、検証よろしく
お願いします。
４つの数字の和は、20, 21, 23, 24 の４通りもあるで、
意外な結果でした。
六芒星では４つの数字の和が 26 の場合しか調べて
いませんが、26 以外にもあるかもしれませんね。
それではまた。
広井さん、こんにちは。
> 私もプログラムしてみました。数字の配置にたいする
> 回転解や鏡像解を除くと、168 通りの解を見つけました。
> プログラムは私のＨＰで公開する予定なので、検証よろしく
> お願いします。
168 通りで合っています。
> ４つの数字の和は、20, 21, 23, 24 の４通りもあるで、
> 意外な結果でした。
値が決まっていないところがあるわけですから、
そこで吸収できるのでしょう。
> 六芒星では４つの数字の和が 26 の場合しか調べて
> いませんが、26 以外にもあるかもしれませんね。
6 本全部一致するときは 26 だけです。
鎌田さん、こんにちは。
> > 私もプログラムしてみました。数字の配置にたいする
> > 回転解や鏡像解を除くと、168 通りの解を見つけました。
>
> 168 通りで合っています。
検証していただき、ありがとうございました。
間違いがなくて良かったです（笑）。
> > 六芒星では４つの数字の和が 26 の場合しか調べて
> > いませんが、26 以外にもあるかもしれませんね。
>
> 6 本全部一致するときは 26 だけです。
さっそく調べていただいて、大感謝です！
どのパズルでもそうですが、最初に考えた人は
すごいですね。
それではまた。