← 前のページ | 1 2 3 4 5 6 7 8 9 | 28 | 次のページ →

289. サイバーの事TMK 2000年10月24日(火) 15:16

はんかつさん、morさん、M.Kamadaさんレスありがとうございます。

>Oh!X持ってるかな?>TMKさん

Oh!Xは毎月買っていたのですが、既に手元にはないのでした。(^^;

技術資料よろしくお願い致します。>M.Kamadaさん

290. Re: サイバーの事M.Kamada  2000年10月24日(火) 19:13

TMKさん、こんにちは。

> 技術資料よろしくお願い致します。>M.Kamadaさん

ダウンロードのページに置いておきましたのでどうぞ。

291. Re^2: サイバーの事TMK 2000年10月24日(火) 22:56

M.Kamadaさん、こんばんわ

> > 技術資料よろしくお願い致します。>M.Kamadaさん

>

> ダウンロードのページに置いておきましたのでどうぞ。

ありがとうございます! 頂いて参ります。

また、レスを頂きました皆様、本当にどうもありがとうございました。


286. サイバー棒の資料(追加)mor 2000年10月24日(火) 01:22

みなさんはじめまして。

資料ですが、電クの拾四號にありました。(AJOY.Xのソース付き)

バイナリだけでもよければアフターバーナーにもおまけで入っています…。

あと、すぐ手に入る範囲では、田圃さんのページにサイバーマウスのドライバがあったはずです。(使用目的が違うので一部省略されているかもしれませんが)

# どうでもいいんですが、AJOY.FNCは見つかりませんでした。(たしかこれもAJOY.XのIOCS $F2を使わずに自前で操作していたはず…)

288. Re: サイバー棒の資料(追加)M.Kamada  2000年10月24日(火) 06:39

morさん、こんにちは。

> 資料ですが、電クの拾四號にありました。(AJOY.Xのソース付き)

月刊電脳倶楽部14号、確認しました。

(パーフェクトコレクション1に入っています)

アナログジョイスティックドライバAJOY.Xと、そのソースと、

技術資料が載っていますね。

「シャープ提供」ということですが、パブリックドメイン

になっているので、あとで転載しておきますね。>TMKさん


285. サイバースティックの資料はんかつ 2000年10月23日(月) 20:32

鎌田さん今晩は はんかつです。

皆さんお忙しいようなので書かせていただきます。

サイバースティックの資料ですが、

Oh!X 1989年7月号C調言語講座PRO-68K

「サイバースティックを使うのである」に載っております。

電脳倶楽部にものったはず。

補足が、Oh!X 1990年5月号ラジコンスティックの製作及び

outside X68000に掲載されています。

287. Re: サイバースティックの資料M.Kamada  2000年10月24日(火) 06:39

はんかつさん、こんにちは。

> 皆さんお忙しいようなので書かせていただきます。

> サイバースティックの資料ですが、

> Oh!X 1989年7月号C調言語講座PRO-68K

> 「サイバースティックを使うのである」に載っております。

> 電脳倶楽部にものったはず。

Oh!X 1989年7月号、確認しました。

故・祝一平氏の小気味良い文章に見覚えがありました。

> 補足が、Oh!X 1990年5月号ラジコンスティックの製作及び

> outside X68000に掲載されています。

補足情報まで確認ありがとうございます。

こちらは桑野さんが書かれていますね。

Oh!X持ってるかな?>TMKさん


277. 訂正:ローテート命令の出力法KQ  2000年10月21日(土) 00:49

ごめんなさい、もっと楽に書けます。

#define ROL (data,n) (data << n | data >> (sizeof (data)*8 - n))

#define ROR (data,n) (data >> n | data << (sizeof (data)*8 - n))

ですね。ただし、dataは unsigned 型じゃないといけません。

すいませんでした。

279. Re: 訂正:ローテート命令の出力法M.Kamada  2000年10月21日(土) 02:14

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ではどうかな?

280. ローテート命令を作るマクロM.Kamada  2000年10月21日(土) 02:41

マクロの書き方にこだわってみました。:-)

/* ローテートマクロの定義(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_)); })

281. Re: ローテート命令を作るマクロAC-YOUCH  2000年10月21日(土) 03:43

KAMADAさん、KQさん、こんにちわ。

gcc上でのローテート命令の生成は 以前某所とか某所で質問したり

自分で色々やってみたんですがうまくいきませんでした(^^;

singnedがらみかな?

結局その時は asm文でローテート命令を直接記述する方法をとりました(汗

ちょっと引っぱり出して書きなおしてみてみます。

283. Re^2: ローテート命令を作るマクロM.Kamada  2000年10月23日(月) 01:00

AC-YOUCHさん、こんにちは。

> gcc上でのローテート命令の生成は 以前某所とか某所で質問したり

> 自分で色々やってみたんですがうまくいきませんでした(^^;

> singnedがらみかな?

signedだったか、GCCが真里子版だった、かな?

292. Re^2: 訂正:ローテート命令の出力法KQ  2000年10月25日(水) 01:49

ご指導ありがとうございます(^^。まさにそのとおりです。

>Charlie版(2.6.3)では、16ビットローテートが

>swapになりませんでした。2.95.2ではどうかな?

ちゃんとswapを出力しますにょ。さすがに同じバージョンの

GCCのインテルCPUの最適化にはとてもかないませんが・・・。

ちなみに、もうG++も Objective Cもうごいてます。

(どっちも約一日で移植できました。)

あとは実機に持っていかなければいけないのですが、

Cを移植するときよりは大変ではないんですぐ動くと思います。

Javaはやっぱり難しいかなという感じです。コンパイラは

ともかくlibgcj.aを書いてくれる人がいないんで。

OSの仕様とか、POSIXスレッドとか、GCとか・・・。

293. Re^3: ローテート命令を作るマクロKQ  2000年10月25日(水) 02:17

>

> signedだったか、GCCが真里子版だった、かな?

>

signedだと算術右シフト演算されてしまいますからね。

ashift命令が内部で生成されると思うのでローテート命令には

なりません。ローテートなら最適化しなくてもrotate,rotatert

が生成されると思います。こういうところは結構融通が利かないかもしれません。

高速インラインmemcpyルーチンを書いたときにちゃんと

型のサイズを判定してコピーするんでちょっとびっくりしました。

ソース上は4バイトごとにコピーしてるのに元がchar型だと1

バイトずつコピーするっていう感じです。

インテルCPUだとこのサイズもできるだけ4バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。

くやし~(T^T;

ただし、そういうソースを書かなければいけないのだけど・・・。

294. Re^3: 訂正:ローテート命令の出力法M.Kamada  2000年10月25日(水) 07:02

KQさん、こんにちは。

> ご指導ありがとうございます(^^。まさにそのとおりです。

あ、あれは、読んでいただいている皆さんのために

補足として書かせていただきました。

それから、説明を忘れてしまいましたが、マクロを

書き換えたのはROR(*p++,1)のような場合に副作用

のある引数が2回評価されないようにするためです。

この手の原因のバグは発見しにくいので予防策です。

> ちゃんとswapを出力しますにょ。

えらいにょ。

> さすがに同じバージョンの

> GCCのインテルCPUの最適化にはとてもかないませんが・・・。

稼動実績が多いと進歩も速いのでしょうね。

> ちなみに、もうG++も Objective Cもうごいてます。

> (どっちも約一日で移植できました。)

> あとは実機に持っていかなければいけないのですが、

> Cを移植するときよりは大変ではないんですぐ動くと思います。

もう慣れちゃってるって感じなのかなぁ。すごいです。

私は古いGCCのDSP56K用のソースを拾ってきてcc1だけ

X68kで動かしたことがありますが、最近のは複雑で…。

> Javaはやっぱり難しいかなという感じです。コンパイラは

> ともかくlibgcj.aを書いてくれる人がいないんで。

> OSの仕様とか、POSIXスレッドとか、GCとか・・・。

OSの仕様といっても、「そもそもOSの機能が少なすぎる」

なんてことになったりしないかな。

295. Re^4: ローテート命令を作るマクロM.Kamada  2000年10月25日(水) 07:02

KQさん、こんにちは。

> 高速インラインmemcpyルーチンを書いたときにちゃんと

> 型のサイズを判定してコピーするんでちょっとびっくりしました。

> ソース上は4バイトごとにコピーしてるのに元がchar型だと1

> バイトずつコピーするっていう感じです。

68000のアドレスエラーを避ける仕掛けが働いて

いるから?

68000のときはソースとデスティネーションの

アドレスの奇遇が一致しているときと一致して

いないときで分けて、一致しているときだけ

ロングワード転送に。(常套手段)

> インテルCPUだとこのサイズもできるだけ4バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。

> くやし~(T^T;

GCCの最適化は、68K用の最適化のノウハウが他の

アーキテクチャにも活用されていると聞いたことが

あります。

でもスーパースカラのスケジューリングに関しては

68K以外のアーキテクチャのほうが対応が進んでいる

のでしょうね。

> ただし、そういうソースを書かなければいけないのだけど・・・。

結局、Cのソースを書く人間がコンパイル結果を

予測できるようでないと、コンパイラの最適化は

最高の結果をもたらすことができないと思います。

最適化が最高の結果でなくても多くの人は満足して

しまいますが、私は満足できない人です。

297. 開発効率の問題では?KQ  2000年10月25日(水) 14:32

> 68000のアドレスエラーを避ける仕掛けが働いて

> いるから?

> 68000のときはソースとデスティネーションの

> アドレスの奇遇が一致しているときと一致して

> いないときで分けて、一致しているときだけ

> ロングワード転送に。(常套手段)

>

インラインアセンブラを使っているわけではないので、

ソース上はそうなっているんですが・・・。

>

> GCCの最適化は、68K用の最適化のノウハウが他の

> アーキテクチャにも活用されていると聞いたことが

> あります。

GNUツールは元々Motrola 68000シリーズとナショナル

セミコンダクタの32000シリーズをベースにサポートされる

ので68000のコードの出力は多分一番最初のGCCからあった

はずです。たぶんそれをもとにいろいろなCPUへ移植された

のでしょう。

>

> 結局、Cのソースを書く人間がコンパイル結果を

> 予測できるようでないと、コンパイラの最適化は

> 最高の結果をもたらすことができないと思います。

> 最適化が最高の結果でなくても多くの人は満足して

> しまいますが、私は満足できない人です。

効率、移植性や再利用が必要かどうかなどによるでしょう。

私にいわせるとC++はいらないとなってしまいますしね(^^。

OOPをしたいならシンプルなObjective Cで十分ですから。

でも、「選択肢は多い方がよい」というのが私の最終的な結論です。

298. DSP56kのGCCってどこ?KQ  2000年10月25日(水) 14:48

Kamadaさんどうも

>

> もう慣れちゃってるって感じなのかなぁ。すごいです。

> 私は古いGCCのDSP56K用のソースを拾ってきてcc1だけ

> X68kで動かしたことがありますが、最近のは複雑で…。

>

DSP56Kって最近のリリースには含まれてません。

もしあるとしたらどこにありますか?

(dsp16xxならあるけど・・・)

>

> OSの仕様といっても、「そもそもOSの機能が少なすぎる」

> なんてことになったりしないかな。

どうなんでしょう?FreeBSDでもソースにぱっちをあてないと動か

ないくらいなので現状ではGCJはLinuxしかサポートしていないん

でしょう。

300. Re: 開発効率の問題では?M.Kamada  2000年10月25日(水) 17:32

KQさん、こんにちは。

> インラインアセンブラを使っているわけではないので、

> ソース上はそうなっているんですが・・・。

(char)→(int)のキャストが効かないということ?

やはりGCCのアドレスエラーを避ける仕掛けが強すぎるのかな?

> > 最適化が最高の結果でなくても多くの人は満足して

> > しまいますが、私は満足できない人です。

>

> 効率、移植性や再利用が必要かどうかなどによるでしょう。

効率、移植性や再利用を考えても、「どこで満足するか」

ではなくて「どこで妥協するか」になってしまうのが

私の性分でして。不便な性分(笑)です。

> 私にいわせるとC++はいらないとなってしまいますしね(^^。

> OOPをしたいならシンプルなObjective Cで十分ですから。

> でも、「選択肢は多い方がよい」というのが私の最終的な結論です。

そうですね。選択肢が多いのはよいと思います。

好きな選択肢が消えてゆくのは寂しいです。

301. Re: DSP56kのGCCってどこ?M.Kamada  2000年10月25日(水) 17:32

KQさん、こんにちは。

> DSP56Kって最近のリリースには含まれてません。

> もしあるとしたらどこにありますか?

> (dsp16xxならあるけど・・・)

MotorolaがポートしたGCCなので、マイナーなバージョン

なのだと思います。MAC命令や並列転送も吐きます。

Googleなどで「DSP56K GCC」を検索すれば出てきます。

http://www.idiom.com/free-compilers/

から辿るのがわかりやすいかも知れません。

2月24日の日記も参照されたし。


274. ローテート命令の出力方法KQ  2000年10月20日(金) 20:03

始めまして、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でも出力可能です。

シフト命令、ローテート命令の最適化テンプレートはかなり

増えているんで、以前に比べるとそこそこいいコードを出力

すると思います。


273. サイバースティックとかTMK 2000年10月20日(金) 11:17

始めまして、TMKと申します。

 サイバースティックの資料を探しているのですが、お持ちの方はいらしゃいますでしょうか?

 アタリポートの信号制御方法とか、X68のレジスタの制御方法とか。。


271. Re^2: ROM BIOS/IOCS.Xのバグというか変な仕様LeDA 2000年10月20日(金) 09:49

すみません、このネタは昔書いた資料の中にあったものを

再検証せずに上げてしまいました。

今再度調べたところ、

・画面右端で表示すると(0,y+1)とならず(画面幅,y)となる

・そのまま表示を続けると次の座標が(1,y+1)になる

でした(v1.2 ROMにて)。

B_LOCATEに(画面幅,y)を与えると無視されます。

また、その位置で改行させたいときは0x0dのみでいけます。

(0x0aは不要。)

情報は間違ってましたが、(0,y+1)が存在しないのはやはり

おかしいです。

当時X1でも開発をよくしていたもので、このような座標の変化は

「バグ以外の何者でもない!!」と思っていたのでした。

(X1ではちゃんと0,y+1になります。)

ということで、上げたものは間違いですので出来れば、

削除してください。

275. Re^3: ROM BIOS/IOCS.Xのバグというか変な仕様M.Kamada  2000年10月20日(金) 21:04

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になります。)

確かにカーソルが画面外の座標を示すのは不自然ですよね。

「画面の右下隅に文字を表示したいとき」以外に

これといった効能はなさそうですし。

未公開機能と仕様バグの分類に悩んでしまいます。


268. いろんな仕様LeDA 2000年10月19日(木) 10:33

ついでなので、バグに近い仕様に付いてもう1つ。

Humanのファイル名比較は、標準では8+3バイトなので、

以下のようなファイル名は同じとみなされます。

123456_8

123456_9

このとき、'8'は0x8257,'9'は0x8258なので、

8バイト目になる0x82までが一致しているので

同じと判定されるわけです。ファイル名だけ見れば

絶対に違うはずなのになぜ一致してしまうのか、

昔これでえらく悩んでしまいました。

TwentyOne導入後はなくなりましたが。

Human上では常識かもしれませんが、忘れている人も多いと

思いましたので一応書きました。

・・・バグじゃないけど隠れ仕様みないな情報がいくつか

あるんですけど、そういうの書く気ないですか?>Kamadaさん

270. Re: いろんな仕様M.Kamada  2000年10月20日(金) 01:58

LeDAさん、こんにちは。

> ・・・バグじゃないけど隠れ仕様みないな情報がいくつか

> あるんですけど、そういうの書く気ないですか?>Kamadaさん

未公開機能は未公開機能として分類します。

「仕様なのかも知れないけれど、正しい挙動とは思えない」

というときは、「仕様バグ」として不具合情報に含めます。

「仕様バグ」かどうかは、独断と偏見も交えて判断します。

未公開機能がバグっているときは不具合情報にも入れます。

例えばMC68030のデータキャッシュのライトアロケーション

モードの変な挙動は、マニュアルに明記されていますが、

仕様バグだと思います。


264. キーボード未公開機能?AC-YOUCH  2000年10月18日(水) 14:54

もしかしたら公開機能だったかもしれませんが

LEDの明るさを調節するモードってありませんでしたっけ?

勘違いかな?

266. Re: キーボード未公開機能?M.Kamada  2000年10月18日(水) 17:01

AC-YOUCHさん、こんにちは。

> もしかしたら公開機能だったかもしれませんが

> LEDの明るさを調節するモードってありませんでしたっけ?

キーボード制御コードの$54~$57ですが、これはシャープが

資料を提供している「X68000データブック」に書いてあるので、

未公開ではないと判断しました。

他にも気付いたところがありましたら教えて下さい。

よろしくです。


259. IP接続サービスHiroi Makoto  2000年10月15日(日) 22:55

鎌田さん、こんばんは。

IP接続サービスで常時接続できない問題は、

Cマガジン8月号の「フィンローダのあっぱれご意見番」

にも書かれています。鎌田さんの日記を読んで思い出し

ました。フィンローダ氏は「1ヶ月ほどの間に2回経験

している」そうです。せっかくの常時接続サービスなの

ですから、きちんと対応してほしいですね。

それではまた。

260. Re: IP接続サービスM.Kamada  2000年10月16日(月) 02:53

広井さん、こんばんは。

> IP接続サービスで常時接続できない問題は、

> Cマガジン8月号の「フィンローダのあっぱれご意見番」

> にも書かれています。鎌田さんの日記を読んで思い出し

> ました。フィンローダ氏は「1ヶ月ほどの間に2回経験

> している」そうです。せっかくの常時接続サービスなの

> ですから、きちんと対応してほしいですね。

あ、やっぱり問題になっていますか。

356日接続しっぱなしにできるようにするためには

システムの保守のやり方を根本的に変えなければならず、

そこまで対応できていないということなのではないかと

思います。(憶測です)

そうでなければフレッツ・ISDNに対応したプロバイダが

これほど急激に増えるはずがありません。

結局、フレッツ・ISDNは、常時接続サービスではなくて、

単なる料金定額サービスらしい、ということで。

それにしても、接続がいきなり切れて困るのは従量制でも

定額制でも同じことなので、せめてどういう条件で切れる

のかはっきりさせて、接続開始から一定の時間は切れない

ようにするなどの工夫をして欲しいです。

まあ、今一番の不満は「64kは遅い」ということですけど。


253. 未公開じゃないかも知れませんが春麗 2000年10月13日(金) 15:58

鎌田さん、こんにちは。

日記を読んでいてフと思い出しましたが、たしかOPT2押しながら

起動すると何か良い事(?)があったような。僕でも知っている

ので未公開じゃないと思いますが…。

記憶がほとんどないですが、確かROMデバ(?)だったかなんだった

か…X68が2台あると幸せ(?)になれるとかなれないとか。

何だったかなぁ…。

256. Re: 未公開じゃないかも知れませんがM.Kamada  2000年10月13日(金) 17:33

春麗さん、こんにちは。

> 日記を読んでいてフと思い出しましたが、たしかOPT2押しながら

> 起動すると何か良い事(?)があったような。僕でも知っている

> ので未公開じゃないと思いますが…。

> 記憶がほとんどないですが、確かROMデバ(?)だったかなんだった

> か…X68が2台あると幸せ(?)になれるとかなれないとか。

>

> 何だったかなぁ…。

ROMデバッガですね。

ROMデバッガは存在そのものが未公開だと思います。

ROMデバッガは起動方法が3通り(手動も含めると4通り)

あります。

257. Re^2: やはりROMデバでしたか春麗 2000年10月14日(土) 04:12

こんにちは。

> ROMデバッガですね。

> ROMデバッガは存在そのものが未公開だと思います。

あぁ、やっぱりROMデバでしたね。家に帰ってから調べてみま

した。いや、なんか妙~に気になってたもので(笑)。【プログ

ラマーのためのX68000環境ハンドブック】に載ってました。

いやはや、これでグッスリ眠れます。

学生の頃はアセンブラしかできなかったので、よく参照していま

した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」

なんて、ちょっと感慨深いものを感じました。今じゃ、C言語

にどっぷり頭まで浸かっています。ははは…

258. Re^3: やはりROMデバでしたかM.Kamada  2000年10月15日(日) 04:39

春麗さん、こんにちは。

> 学生の頃はアセンブラしかできなかったので、よく参照していま

> した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」

> なんて、ちょっと感慨深いものを感じました。今じゃ、C言語

> にどっぷり頭まで浸かっています。ははは…

同じようにCを理解しているつもりでも、アセンブラの

経験があるかどうかでCの理解度は大きく差がつきます。

Cを使うとき、「アセンブラの経験がない人には負けない」

という自信を持ちましょう。

たとえCの海にどっぷり浸かっていても、アセンブラは

いつもその足元、海の底のほうに広がっているものです。

その海に潜れる深さがCへの理解の深さです。

ときどき底まで潜ってみてはいかが?

海底散歩も楽しいかも知れません。

261. Re^4: 海底散歩春麗 2000年10月16日(月) 18:11

こんにちは。

> 同じようにCを理解しているつもりでも、アセンブラの

> 経験があるかどうかでCの理解度は大きく差がつきます。

先日の日記にもありましたが(関数のポインタへの配列の

定義うんぬん)、初心者の頃はポインタの代入や計算で、

よくワーニングを出して、その度に、

「move.l d0,a0でいいやん、move.l d0,a0で!」

「キャストめんどくせー!」

とかいろいろ唸ってました(笑)。

> ときどき底まで潜ってみてはいかが?

> 海底散歩も楽しいかも知れません。

制作中の2D格ゲーでは、スプライトダブラ(358個だからダ

ブラじゃないか…)などの肝心な部分は海底を歩いてます。

でも、ヘボなので、ノーマルX68での動作保証は諦めました。

※ 060turbo使ってると、速度感覚がマヒします(苦笑)。

262. Re^5: 海底散歩M.Kamada  2000年10月17日(火) 22:34

春麗さん、こんにちは。

> 先日の日記にもありましたが(関数のポインタへの配列の

> 定義うんぬん)、初心者の頃はポインタの代入や計算で、

> よくワーニングを出して、その度に、

>

> 「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でさえ這うように遅くなります。

263. Re^6: Wall春麗 2000年10月18日(水) 13:22

こんにちは。

> -WallでWarningが出ないようにすることに燃えてしまい、

> ふと気付くと効率の悪いプログラムになっていたり。

エッ、そうなんですか。僕は、Wallつけてコンパイルしてい

ますが、特に速度的に効率が悪いとは感じた事はないです。

重要なループ以外は、最適化を気にせず組んでます。

> 「関数へのポインタの配列の定義」は、Warningどころか

> Errorになってしまう人が結構いるのではないかと。

僕も一発コンパイルは自信がないです(プログラマなのに)。

void (*proc[])( void *arg ) = { foo1, foo2, foo3....};

こ、こんな感じでしょうか。何も見てないので自信ないです。

> スプライトダブラもハードの限界を超える発想ですよね。

> 水平32個の限界があるので、スプライトの数を増やす

> だけでなく、どのように並べるかも工夫が必要ですね。

済みません、358個じゃなくて384個の間違いでした。ダブラ

エンジンを開発した当時は既にXSPがあったのですが、XSPは

一切参考にしませんでした(下らないプライドですが)。

で、後から、ドキュメントを見てみると、管理方法や高速化、

問題点などほぼ同じでした。やはり考える事は同じなんだなぁ

と思いました(ベースとなる原理が同じなので当然ですが)。

でも、僕のダブラの完成度はXSPの足元にも及びません(苦笑)。

265. Re^7: WallM.Kamada  2000年10月18日(水) 17:01

春麗さん、こんにちは。

> エッ、そうなんですか。僕は、Wallつけてコンパイルしてい

> ますが、特に速度的に効率が悪いとは感じた事はないです。

> 重要なループ以外は、最適化を気にせず組んでます。

コードの効率というよりもデータ構造の効率を考えたとき、

Cの文法の範囲で表せないデータ構造を使いたくなることって

ありません?

アセンブラで書くようなデータ構造をCで模倣しようとして

unionやビットフィールドを使って無理矢理書いたものの、

Warningをなくすことができず、結局無駄の多いデータ構造に

変更してしまったりして、「ああ、ぬるい、ぬるすぎる…」

なんて嘆いたり。

他にCで効率が悪くなることと言えば、「ローテート命令を

使いたいとき」とか。

> 僕も一発コンパイルは自信がないです(プログラマなのに)。

> void (*proc[])( void *arg ) = { foo1, foo2, foo3....};

> こ、こんな感じでしょうか。何も見てないので自信ないです。

お見事。

この場合、関数へのポインタの配列の参照は

proc[n](&arg);

ですが、定義のときだけ必要になる括弧を間違えやすい

と思います。

> 済みません、358個じゃなくて384個の間違いでした。

あ、やっぱり。中途半端な数だなぁとは思いました。(笑)

> ダブラエンジンを開発した当時は既にXSPがあったのですが、

> XSPは一切参考にしませんでした(下らないプライドですが)。

> で、後から、ドキュメントを見てみると、管理方法や高速化、

> 問題点などほぼ同じでした。やはり考える事は同じなんだなぁ

> と思いました(ベースとなる原理が同じなので当然ですが)。

> でも、僕のダブラの完成度はXSPの足元にも及びません(苦笑)。

XSPは汎用性を持った完成度の高いものですよね。

でも、384出せればたいしたものだと思います。

X68000版の「キャメルトライ」は偉大でした。

それを再現できるエミュレータも凄いと思います。

267. Re^8: 関数へのポインタHiroi Makoto  2000年10月18日(水) 20:41

鎌田さん、春麗さん、こんにちは。

アセンブラの腕前は錆ついたままだが、Cは大丈夫だろう

と思っていたのですが、それも怪しくなってきました。

関数へのポインタの配列は、けっきょく、Zしーモンキー

を見て確認しました(苦笑)。うーん、あの頃はパワーが

あったなあ。最近、Perl を使うことが多かったので、

すっかり堕落したようです(笑)。リハビリしないとダメ

ですね。

それではまた。

269. Re^9: 関数へのポインタM.Kamada  2000年10月20日(金) 01:58

広井さん、こんにちは。

> アセンブラの腕前は錆ついたままだが、Cは大丈夫だろう

> と思っていたのですが、それも怪しくなってきました。

普段使っていないと忘れてしまいますよね。

「関数へのポインタの配列」は機能番号からサブ

ルーチンを選択する場合などに使いますが、あまり

使用頻度は高くないかも知れません。

> 最近、Perl を使うことが多かったので、

> すっかり堕落したようです(笑)。

Perlは強烈な省略言語ですからねぇ。

あればっかりじゃ…。

272. Re^10: 忘れる…春麗 2000年10月20日(金) 11:01

広井さん、鎌田さん、こんにちは。

> > アセンブラの腕前は錆ついたままだが、Cは大丈夫だろう

> > と思っていたのですが、それも怪しくなってきました。

>

> 普段使っていないと忘れてしまいますよね。

僕は、BASICはもうスッカリ忘却の彼方です。OKの

あとに”.”ピリオドがついてたらコンティニュー

可能とかツマンナイ事しか覚えてません(笑)。

でも、アセンブラって月日が経っても命令表さえあ

れば何とかなりますよね(自転車と同じで)。それ

に何か一つでも(極めずとも)それなりに習得して

おけば、違うCPUでも何とかなりますよね。

僕はZ80と68kしかやっていなくても、8086の仕事は

できたし(セグメントはイヤでしたが)、VUの最適

化も楽しめました。

> 「関数へのポインタの配列」は機能番号からサブ

> ルーチンを選択する場合などに使いますが、あまり

> 使用頻度は高くないかも知れません。

数が少なければswitchでササッと書けるし、その

方が追加や変更など都合の良い場合もありますから。

特に、見た目に分かり易いですし(スパゲッティは

論外ですが)。

個人主観ですが、見た目は重要だと思っています

(速度重視の場合は仕方ないですが)。

276. Re^11: 忘れる…Hiroi Makoto  2000年10月20日(金) 22:05

春麗さん、こんにちは。

> それに何か一つでも(極めずとも)それなりに習得

> しておけば、違うCPUでも何とかなりますよね。

そうですね。どの CPU にしても原理的には同じ(フォン

・ノイマン・アーキテクチャ)なので、ひとつの CPU で

マシン語プログラムが組める人は、ほかの CPU でも何とか

なるでしょう。

> 僕はZ80と68kしかやっていなくても、8086の仕事は

> できたし(セグメントはイヤでしたが)、VUの最適

> 化も楽しめました。

私の場合、マシン語は Z80 -> 8068 -> 68k と経験

しましたが、68k に触れた時は目からウロコが落ちま

した(笑)。

> 個人主観ですが、見た目は重要だと思っています

> (速度重視の場合は仕方ないですが)。

メンテナンスを考えれば、ソースは読みやすいほうが

よろしいかと思います。

278. Re^12: 忘れる…M.Kamada  2000年10月21日(土) 01:48

春麗さん、広井さん、こんにちは。

> そうですね。どの CPU にしても原理的には同じ(フォン

> ・ノイマン・アーキテクチャ)なので、ひとつの CPU で

> マシン語プログラムが組める人は、ほかの CPU でも何とか

> なるでしょう。

確かに、アーキテクチャが違っても基本的な考え方は

同じなので、何とかなる場合が多いと思います。

しかし、アーキテクチャにはそれぞれ個性があるので、

私はその個性を大事にしたいです。

プロセッサ関連のリンクを増やしているのは、

「プロセッサにはいろいろなアーキテクチャがある」

ということを知ってもらいたいためでもあります。

282. Re^13: 忘れる…Hiroi Makoto  2000年10月21日(土) 20:14

鎌田さん、こんばんは。

> > マシン語プログラムが組める人は、ほかの CPU でも何とか

> > なるでしょう。

>

> 確かに、アーキテクチャが違っても基本的な考え方は

> 同じなので、何とかなる場合が多いと思います。

> しかし、アーキテクチャにはそれぞれ個性があるので、

> 私はその個性を大事にしたいです。

そのとおりですね。コンパイラを使うにしても、最適化

技術が進歩しているとはいえ、使用する CPU のアーキ

テクチャを理解していないと、凄いプログラムは作れない

と思います。まあ、私が作るプログラムは軟弱なものばかり

なので、偉そうなことは言えませんが(笑)。

STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、

興味深いリンクが多いですね。画像検索エンジン Charlotte

は、画像ファイルのプレビューが表示されるので、とても

便利です。これからも期待しています。

それではまた。

284. Re^14: 忘れる…M.Kamada  2000年10月23日(月) 01:00

広井さん、こんにちは。

> > しかし、アーキテクチャにはそれぞれ個性があるので、

> > 私はその個性を大事にしたいです。

>

> そのとおりですね。コンパイラを使うにしても、最適化

> 技術が進歩しているとはいえ、使用する CPU のアーキ

> テクチャを理解していないと、凄いプログラムは作れない

> と思います。まあ、私が作るプログラムは軟弱なものばかり

> なので、偉そうなことは言えませんが(笑)。

「アーキテクチャを知る必要がある」ということよりも、

単純に「このアーキテクチャを考えた人は凄い!って

思えるようなアーキテクチャがいろいろあって面白い」

という理由で、私はマイクロプロセッサのアーキテクチャ

に興味を持っています。

いずれは自分で設計してみたいし。

> STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、

> 興味深いリンクが多いですね。画像検索エンジン Charlotte

> は、画像ファイルのプレビューが表示されるので、とても

> 便利です。これからも期待しています。

ありがとうございます。

CharlotteはR.V.R.Homepageの

「ゲームプログラミング日記」で知りました。

私もロコちゃんは好きです。(笑)


252. X68の未公開機能M.Suzuki 2000年10月13日(金) 11:58

X68の未公開機能ですが、一時期ハマっていた

SX-WINDOWの.CGAファイルに関する情報なら有ります。

IVMを隅々まで調べて作った資料だったりします。

私のページに有りますので、適当にリンクしてやって下さい。

P.S.

FSX.xの未公開コールとかも知ってるけど、

資料としてはまとめてないです(^^;

255. Re: X68の未公開機能M.Kamada  2000年10月13日(金) 17:33

M.Suzukiさん、こんにちは。

> X68の未公開機能ですが、一時期ハマっていた

> SX-WINDOWの.CGAファイルに関する情報なら有ります。

> IVMを隅々まで調べて作った資料だったりします。

> 私のページに有りますので、適当にリンクしてやって下さい。

ありがとうございます。

SX-WINDOW関係の資料は解析結果にもとづいているものが

多いですね。

> P.S.

> FSX.xの未公開コールとかも知ってるけど、

> 資料としてはまとめてないです(^^;

FSX.Xを完全に解析した人って、何人くらいいるのかな。

私は、KeyWitchをやっていた頃に、キー入力回り

(SXCON.Xを含む)を見たくらいです。

A-line処理を高速化しようとして68000の変な挙動を発見

した頃から、興味の対象がFSX.Xから逸れていきました。


243. ページリニューアルみかぜ  2000年10月10日(火) 21:36

こんにちは。

新しいページ、かっこよくなっていいですね。

CG文字のアンチも奇麗に見易くなってますし、

レイアウトもトータルイメージもいいです。

でもCG文字はBMPよりもGIFファイルの方が

ページが軽くなっていいかもです。

1ファイル6KBくらい(プロフィール、の文字)

ある文字だと、アナログモデムだとちょい辛いかもです。

あれなら256色で十分ですし。

こっちで試しにGIF化してみたら、半分くらいになりました。

ではでは。

244. Re: ページリニューアルM.Kamada  2000年10月10日(火) 21:58

みかぜさん、こんばんは。

> 新しいページ、かっこよくなっていいですね。

> CG文字のアンチも奇麗に見易くなってますし、

> レイアウトもトータルイメージもいいです。

ありがとうございますぅ。

> でもCG文字はBMPよりもGIFファイルの方が

> ページが軽くなっていいかもです。

> 1ファイル6KBくらい(プロフィール、の文字)

> ある文字だと、アナログモデムだとちょい辛いかもです。

> あれなら256色で十分ですし。

> こっちで試しにGIF化してみたら、半分くらいになりました。

> ではでは。

にょにょ? 画像は全部GIFになってるにょ。

プロフィールの文字(profile.gif)は3436バイトだにょ。

245. Re^2: ページリニューアルみかぜ  2000年10月10日(火) 22:08

> にょにょ? 画像は全部GIFになってるにょ。

> プロフィールの文字(profile.gif)は3436バイトだにょ。

プロフィールは今見直したらGIFでした。

申し訳ないです。私が見た時日記のCGだけフォント

タイプが違ってたから過渡期だった???

今見直した所、日記と更新記録はダウンロードすると

今もBMPになってしまいますが、これは……IEのせい?

246. Re^3: ページリニューアルM.Kamada  2000年10月10日(火) 22:17

みかぜさん、こんばんは。

> プロフィールは今見直したらGIFでした。

> 申し訳ないです。私が見た時日記のCGだけフォント

> タイプが違ってたから過渡期だった???

> 今見直した所、日記と更新記録はダウンロードすると

> 今もBMPになってしまいますが、これは……IEのせい?

IEの画像キャッシュの更新のタイミングが変なのかも。

diary.gifは2115バイト、history.gifは3416バイトです。

247. Re^4: ページリニューアルみかぜ  2000年10月10日(火) 22:58

たびたびすいません

> IEの画像キャッシュの更新のタイミングが変なのかも。

あ~なんかその辺の可能性が高い気がしてきました。

先日キャッシュがとんだばっかりだし、

ちょっと前に見た時はレイアウトは変ってたけど、

背景が水色だったので……しばらく後でリロードを

かけたら黒になりました。

うむむ……とりあえず無意味な事いって混乱させましたね。

申し訳ないです。

248. Re^5: ページリニューアルM.Kamada  2000年10月11日(水) 01:09

みかぜさん、こんばんは。

> > IEの画像キャッシュの更新のタイミングが変なのかも。

>

> あ~なんかその辺の可能性が高い気がしてきました。

> 先日キャッシュがとんだばっかりだし、

> ちょっと前に見た時はレイアウトは変ってたけど、

> 背景が水色だったので……しばらく後でリロードを

> かけたら黒になりました。

CSSだけキャッシュの更新が遅れたのかな。

STUDIO KAMADAにはBMPフォーマットの画像ファイルは

置いていない(更新中も含めてアップロードしていない)

ので、BMPになっていたらそれはキャッシュだと思います。

お使いのマシンの時計、あってますよね?(念のため)

うちのIEも以前キャッシュがおかしくなって、

キャッシュをすべて消去したことがあります。

キャッシュの機能がないとオフラインで読んだり

書いたりするときに不便ですが、キャッシュが悪さを

していると障害の原因がわかりにくくて困るんですよね。

> うむむ……とりあえず無意味な事いって混乱させましたね。

> 申し訳ないです。

いえ、たとえ間違っていたとしても、気付いたところを

報告していただけるのは嬉しいものです。

これからもよろしく。

249. Re^6: ページリニューアルみかぜ  2000年10月11日(水) 01:33

KAMADAさんこんにちは。

> STUDIO KAMADAにはBMPフォーマットの画像ファイルは

> 置いていない(更新中も含めてアップロードしていない)

> ので、BMPになっていたらそれはキャッシュだと思います。

そのようですね。早とちりしてしまいました。お恥ずかしい。

> うちのIEも以前キャッシュがおかしくなって、

> キャッシュをすべて消去したことがあります。

> キャッシュの機能がないとオフラインで読んだり

> 書いたりするときに不便ですが、キャッシュが悪さを

> していると障害の原因がわかりにくくて困るんですよね。

常時接続だから基本的に必要無いんですが、

いつも見ているページが、いざ、ふいに無くなってしまった

時などで、溜まっているキャッシュから無理矢理サルベージ

させる事があるので、あんまり切りたくないんですよね。

難しい所ですが。

ではでは。

250. Re^7: ページリニューアルM.Kamada  2000年10月11日(水) 05:02

みかぜさん、こんにちは。

> 常時接続だから基本的に必要無いんですが、

うちは昨日やっと(ほぼ)常時接続になりましたが、

回線速度が遅いので、最近見たページを開くのに

かかる時間がキャッシュの有無でだいぶ違います。

みかぜさんのところは常時接続でしかも回線速度が

速いんですよね。いいなあ。

> いつも見ているページが、いざ、ふいに無くなってしまった

> 時などで、溜まっているキャッシュから無理矢理サルベージ

> させる事があるので、あんまり切りたくないんですよね。

> 難しい所ですが。

なるほど。そういう使い方もありましたか。

IEのキャッシュの実体の部分がもうちょっと探しやすく

なっているとよかったかも。


241. びっくりしました!Hiroi Makoto  2000年10月10日(火) 19:42

鎌田さん、こんばんは。

STUDIO KAMADA にアクセスしたら、黒を基調とした

ホームページに変わっていたので、びっくりしました。

やっぱり X68000 は黒なのでしょうか。かっこいいです。

新しいバナー、輝いていますね。さっそくリンクで

使わせていただきます。

242. Re: びっくりしました!M.Kamada  2000年10月10日(火) 20:06

広井さん、こんばんは。

> STUDIO KAMADA にアクセスしたら、黒を基調とした

> ホームページに変わっていたので、びっくりしました。

> やっぱり X68000 は黒なのでしょうか。かっこいいです。

ありがとうございます!

X68000だから黒というわけではないのですが、確かに

X68000ユーザのページは背景が黒い所が多いですね。

> 新しいバナー、輝いていますね。さっそくリンクで

> 使わせていただきます。

よろしくです。

バナーのURLと大きさが以前と違うのでご注意下さいませ。

古いバナーも残してありますが、新しいのと比べると

やはりしょぼいバナーだったんだなぁと。(笑)

あ、五芒星の背景が水色のままだ。


239. XCの不具合に付いてLeDA 2000年10月10日(火) 15:47

ここに発表されている「XCの不具合」ですが、

>IOCTRLFDCTL()が正常に動作しない

はXCのNewKitでは修正されていると思います。

(DOS4413.S;93-09-15 12:00)

逆に、IOCTRLRTSET(DOS4411.S)にて

  move.w #$11,-(sp)

というのが間違いで、

  move.w #11,-(sp)

のはずです。

240. Re: XCの不具合に付いてM.Kamada  2000年10月10日(火) 16:00

LeDAさん、こんにちは。

> ここに発表されている「XCの不具合」ですが、

> >IOCTRLFDCTL()が正常に動作しない

> はXCのNewKitでは修正されていると思います。

> (DOS4413.S;93-09-15 12:00)

>

> 逆に、IOCTRLRTSET(DOS4411.S)にて

>   move.w #$11,-(sp)

> というのが間違いで、

>   move.w #11,-(sp)

> のはずです。

情報ありがとうございます。早速、追記しておきます。

他にも気付いたところがありましたらご指摘下さい。

よろしくお願いします。

251. Re^2: XCの不具合に付いてLeDA 2000年10月12日(木) 15:35

> 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の変更はありますが。)

254. Re^3: XCの不具合に付いてM.Kamada  2000年10月13日(金) 17:33

LeDAさん、こんにちは。

> 採用、ありがとうございます。

> こんなマイナーなバグ、普通は見つからないのかもしれませんが、

> たまたま自作のソフトで使う機会があったので見つけてしまいました(自作デバイスドライバのバグ取り中に)。

リトライ回数なんて普通は変更しませんからねぇ。

> 私の知る限り、V2.1→NewKitでの唯一のバグ取りです。

> (追加ライブラリや__main.Sの変更はありますが。)

XCのライブラリには結構バグがあったと思うのですが、

NewKitでは修正されているところが多いかも知れませんね。


237. CMOS Checksum Badけんじょ 2000年10月10日(火) 10:05

鎌田さん、こんにちは。

ページデザインが突然変わってたのでビックリしました ^^;。

クールな感じで良いですね。

で、日記にあったタイトルの件ですが、これ、確かBIOS設定が

保存されているSRAMの内容のチェックサムエラーということだっ

たかと思います。

何かのタイミングでSRAM内容が壊れたのか、若しくはSRAM用の

バッテリがへたってるのかも知れません。

238. Re: CMOS Checksum BadM.Kamada  2000年10月10日(火) 14:33

けんじょさん、こんにちは。

> ページデザインが突然変わってたのでビックリしました ^^;。

> クールな感じで良いですね。

早速のご感想、ありがとうございます!

ビックリしていただけで嬉しいです!

そろそろタイトル画像を変えたいなあと思って落書き

していたら、なんだかいい感じのが描けてしまったので、

急に変えてみたくなったの。(^^;

> で、日記にあったタイトルの件ですが、これ、確かBIOS設定が

> 保存されているSRAMの内容のチェックサムエラーということだっ

> たかと思います。

> 何かのタイミングでSRAM内容が壊れたのか、若しくはSRAM用の

> バッテリがへたってるのかも知れません。

情報ありがとうございます。

なるほど。

最近、落雷対策と部屋の模様替えとハングアップのために

電源を切ったことが多かったから、電池切れなら納得。

そういえば、ふたを開けたときに、見慣れたボタン電池の

2032が見えて、「こんな電池で大丈夫なんかいな」と

思ったんだっけ。

あのあとエラーは出ていないけれど、電池を取り替えて

おこうかなあ。


235. おっはー&堀江さんVFC-LINK 2000年10月8日(日) 01:18

慎吾ママは実際に、おはスタに出演していました。

とわいえ私は当日談をその後の「サタスマ」で見ただけですが。

また堀江さんは実際に「ラジオ番組中に他のキャスターを肩叩きする」

なる罰ゲーム(?)を与えられて、「や、ほんと上手だったよ」と

冨永み○なさんに言わしめた人です(^^;

236. Re: おっはー&堀江さんM.Kamada  2000年10月8日(日) 04:08

VFC-LINKさん、こんにちは。

> 慎吾ママは実際に、おはスタに出演していました。

> とわいえ私は当日談をその後の「サタスマ」で見ただけですが。

あ、やっぱり。

おはスタで「慎吾ママまた来てくれー」って叫んでいたので、

一度は出たんだなあと思っていました。

それで、そのあとほったらかし? みたいな感じ。(笑)

> また堀江さんは実際に「ラジオ番組中に他のキャスターを肩叩きする」

> なる罰ゲーム(?)を与えられて、「や、ほんと上手だったよ」と

> 冨永み○なさんに言わしめた人です(^^;

ラジオですかぁ。う~ん、イメージ、イメージ。

ごほうびになでなでしてもらえたのかなぁ。(んなわけないか)


229. 遅ればせながら五芒星M.Hayashi  2000年10月4日(水) 04:43

久しぶりです。こんばんは。

分かったーと思い答え合わせしたら、

数え間違いで9個しかできてないのに答え見てもーたぁ。

でも、もう少し考えていても、

あんなの思い付かなかったかったと思います。

できれば答えを見ずに一週間くらい悩みたかったところですが。

(あれをプログラムで解く方が、普通に紙と鉛筆で解くより難解だと思いました。)

232. Re: 遅ればせながら五芒星M.Kamada  2000年10月5日(木) 06:01

M.Hayashiさん、こんにちは。

> 分かったーと思い答え合わせしたら、

> 数え間違いで9個しかできてないのに答え見てもーたぁ。

あー、そのパターンは悲しいかも。

他のかたも気をつけてくださいまし。

> でも、もう少し考えていても、

> あんなの思い付かなかったかったと思います。

アプローチの仕方を一度思い込んでしまうと、

なかなかそこから抜け出せないんですよね。

> できれば答えを見ずに一週間くらい悩みたかったところですが。

私は高校生の頃に、ある数学の証明問題を10日かけて

解いたことがあります。

時間がかかればかかるほど、最終的に解けたときの

喜びは大きくなりますね。

フェルマーの最終定理の証明は350年かかったそうで。

> (あれをプログラムで解く方が、普通に紙と鉛筆で解くより難解だと思いました。)

完璧なプログラムが書ける頃にはプログラムの注釈に

答えが書いてありそうな気もしますね。(笑)

しかし、「アルゴリズムは穴だらけだけれど、答えが

見つかればラッキー」くらいの気持ちでプログラムを

書いてみるのも、ひとつのアプローチだと思います。

特に、アタマで考えていて煮詰まってしまったときは。

プログラムで答えが見つからなくても、「答えは

こういうパターンではない」ということがわかるので、

ヒントが得られるかも知れません。


221. 間違いでしたHiroi Makoto  2000年9月30日(土) 16:16

鎌田さん、どうもです。

すいません、五芒星の問題ですが数え間違いました。

うーん、はずかしいよう(泣)。

ここで、ギブアップします。答え教えてください(笑)。

それでは。

223. Re: 間違いでしたM.Kamada  2000年9月30日(土) 19:40

広井さん、こんにちは。

> すいません、五芒星の問題ですが数え間違いました。

あらら、残念。

> ここで、ギブアップします。答え教えてください(笑)。

では、そろそろ答えを発表することにしますか。

もう少し粘ってみようという人は見ないようにしてください。

五芒星の問題の答え

http://homepage2.nifty.com/m_kamada/gif/pentagram_a.gif

224. Re^2: 間違いでしたHiroi Makoto  2000年9月30日(土) 20:54

鎌田さん、こんにちは。

> では、そろそろ答えを発表することにしますか。

> もう少し粘ってみようという人は見ないようにしてください。

>

> 五芒星の問題の答え

> http://homepage2.nifty.com/m_kamada/gif/pentagram_a.gif

なるほど(ポンと手を打つ)、これは一本とられました。

これだからパズルはやめられませんね(笑)。

十分に楽しませてもらいました。

ありがとうございます。


218. 五芒星の問題春麗 2000年9月28日(木) 10:53

鎌田さん、こんにちは。僕は、未だにX68で2D格ゲーなんぞを作ろう

としている、諦めの悪い春麗と申す者です(060turbo使ってます)。

五芒星の問題、やっと解けました。休憩時にこれを会社で見たのが間

違いでした。その時はちょっとトライしてみて3分では解けなかった

ので、すぐに意味を終了して仕事に戻りました。が、何故か五芒星の

問題が頭の中でグルグルしてロクに仕事が手に付きませんでした。

耐え切れず、画像をPaintで貼り付けて、直線ツールであーでもな

いこーでもないと悩み続けて…なんかパズルの合間に仕事やってたよ

うな…(苦笑)。

「絶対、線分の交点を通り三角形を二分する直線を引くはずだ」など

と自分の思い込みにハマっていたのですが、何気なく引いたら10コ

できました。

日記でこれをプログラムで解いたとありますが、僕にはサッパリ分か

りませんでした。パズルの解法関係の知識が皆無とはいえ、プログラ

マとして恥ずかしい限りです。しょぼーん。

219. Re: 五芒星の問題M.Kamada  2000年9月28日(木) 22:14

春麗さん、こんにちは。

> 鎌田さん、こんにちは。僕は、未だにX68で2D格ゲーなんぞを作ろう

> としている、諦めの悪い春麗と申す者です(060turbo使ってます)。

夢や目標は簡単に捨てられるものではありませんよね。

エミュレータもどんどん良くなっていることですし、

頑張って作ってください。

> 五芒星の問題、やっと解けました。

やった! 報告第1号です!

> 休憩時にこれを会社で見たのが間

> 違いでした。その時はちょっとトライしてみて3分では解けなかった

> ので、すぐに意味を終了して仕事に戻りました。が、何故か五芒星の

> 問題が頭の中でグルグルしてロクに仕事が手に付きませんでした。

> 耐え切れず、画像をPaintで貼り付けて、直線ツールであーでもな

> いこーでもないと悩み続けて…なんかパズルの合間に仕事やってたよ

> うな…(苦笑)。

いやー、すっかりハマらせてしまいましたね。

このパズル、有害だったかなあ。(笑)

> 「絶対、線分の交点を通り三角形を二分する直線を引くはずだ」など

> と自分の思い込みにハマっていたのですが、何気なく引いたら10コ

> できました。

おお、いいヒントが出ました。

他の人も挑戦してみてください。

> 日記でこれをプログラムで解いたとありますが、僕にはサッパリ分か

> りませんでした。パズルの解法関係の知識が皆無とはいえ、プログラ

> マとして恥ずかしい限りです。しょぼーん。

落ち込むことはありませんよ。

五芒星の問題はコンピュータにやらせるには少々

とっつきにくいのですが、あまり難しく考えることは

ありません。

「五芒星に直線を2本描き加えた図形」の中にある

「内側に線を含まない三角形」を数えるためには、

「五芒星に直線を2本描き加えた図形」をどのような

データ構造で表現しておくと都合がよいか、考えて

みてください。

直線は通過点を2個所固定すれば一意に定まります。

2個所の通過点の選び方はさほど多くはありません。

2本目の直線の通過点の候補は1本目と少し違います。

220. Re^2: 五芒星の問題Hiroi Makoto  2000年9月30日(土) 14:47

鎌田さん、こんにちは。

すっかりはまっていた五芒星の問題、

やっと解けました! とてもうれしいにょ(笑)。

五芒星の内部を分割するだけでは解けないところがポイント

ですね。とても面白いパズルです。

五芒星のパズルでは、数字を配置する問題もあります。

頂点と交点が10ヵ所ありますが、そこに 1 から 10 までの

数字を配置します。すると、直線上に4つの数字が並びますが、

その和が n 本の直線で等しくなるような配置を求めます。

3本の直線で等しくなる配置は、ある本で見かけたことが

ありますが、5本の直線全部が等しくなる配置はあるので

しょうか? もしかすると、解がないかもしれません。

そのうちに挑戦してみようと思います。

222. Re^3: 五芒星の問題M.Kamada  2000年9月30日(土) 19:33

広井さん、こんにちは。

> 3本の直線で等しくなる配置は、ある本で見かけたことが

> ありますが、5本の直線全部が等しくなる配置はあるので

> しょうか? もしかすると、解がないかもしれません。

> そのうちに挑戦してみようと思います。

3分間プログラミングでてきとーに調べてみたのですが、

5本全部等しくすることは不可能ではないかと。

力ずくではなくてスマートに証明できないかなあ。

225. Re^4: 五芒星の問題Hiroi Makoto  2000年9月30日(土) 21:20

鎌田さん、こんにちは。

> 3分間プログラミングでてきとーに調べてみたのですが、

> 5本全部等しくすることは不可能ではないかと。

> 力ずくではなくてスマートに証明できないかなあ。

五芒星では解がないとのこと、調査ありがとうございます。

スマートに証明できると凄いですね。

ちなみに、六芒星の場合は解があります。

パズル雑誌では、マジックスターという名前のパズルで

登場することがあって、プログラムしたことがあります。

六芒星の場合、1 から 12 までの数字を配置しますが、

自分が調べた結果では、重複解をのぞくと 80 通りの解を

見つけました。解はもっと少ないと思っていたので、

意外な結果でした。

それではまた。

227. Re^5: 五芒星の問題M.Kamada  2000年10月4日(水) 04:41

広井さん、こんにちは。

> 五芒星では解がないとのこと、調査ありがとうございます。

ちなみに、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本のとき何通りできるかは数えてみていません。

231. Re^6: 五芒星の問題Hiroi Makoto  2000年10月4日(水) 22:13

鎌田さん、こんにちは。

> ちなみに、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 通りの解を見つけました。

プログラムは私のHPで公開する予定なので、検証よろしく

お願いします。

4つの数字の和は、20, 21, 23, 24 の4通りもあるで、

意外な結果でした。

六芒星では4つの数字の和が 26 の場合しか調べて

いませんが、26 以外にもあるかもしれませんね。

それではまた。

233. Re^7: 五芒星の問題M.Kamada  2000年10月6日(金) 05:37

広井さん、こんにちは。

> 私もプログラムしてみました。数字の配置にたいする

> 回転解や鏡像解を除くと、168 通りの解を見つけました。

> プログラムは私のHPで公開する予定なので、検証よろしく

> お願いします。

168通りで合っています。

> 4つの数字の和は、20, 21, 23, 24 の4通りもあるで、

> 意外な結果でした。

値が決まっていないところがあるわけですから、

そこで吸収できるのでしょう。

> 六芒星では4つの数字の和が 26 の場合しか調べて

> いませんが、26 以外にもあるかもしれませんね。

6本全部一致するときは26だけです。

234. Re^8: 五芒星の問題Hiroi Makoto  2000年10月6日(金) 13:37

鎌田さん、こんにちは。

> > 私もプログラムしてみました。数字の配置にたいする

> > 回転解や鏡像解を除くと、168 通りの解を見つけました。

>

> 168通りで合っています。

検証していただき、ありがとうございました。

間違いがなくて良かったです(笑)。

> > 六芒星では4つの数字の和が 26 の場合しか調べて

> > いませんが、26 以外にもあるかもしれませんね。

>

> 6本全部一致するときは26だけです。

さっそく調べていただいて、大感謝です!

どのパズルでもそうですが、最初に考えた人は

すごいですね。

それではまた。

← 前のページ | 1 2 3 4 5 6 7 8 9 | 28 | 次のページ →