FrontPage 新規編集検索一覧ヘルプ

Diarys2006

＃私的に身動きとれない為、明日だけど過去形表現(^^;;

2006-9-21

赤待ち(^^;

仕事に追われる毎日なのれすが、これだけは書いておかなくては。

祝！ Nereid復活再生産第２次ロット受付開始！

トラップめは来年のシャア専用[赤]を待つつもりですが、予備用に1枚欲しい気もしますね…。

あ、でも 060TurboX の予算もあるし、やっぱ赤待ち(^^;。

[カテゴリ:x68]

2006-8-31

快適なマウス＆パッド、そして新たなる世界へ

X68kユーザの誰しもが皆、今や入手が困難なアタリ準拠のジョイパッド、そして専用マウスの消耗具合(^^;に日々困っていたかと思いますが、もう、そぉんな悩みからは解放です！

Nereid を挿し、usbjoy.x (plasticさん、あく蔵さん) を利用することで、なんと、巷にあふれる USBマウス, USBジョイパッドが使えるようになってしまうのですっ！

一口に USBマウス, USBジョイパッドと言っても、色々と違いがありますので全てが使えるとは限りませんが、色々試して、動作確認リストを育てていきましょう～（私も (^^;）。

さぁ、X68-USBプロジェクトページでUSBデバイスと握手だ！

[カテゴリ:x68]

2006-8-29

そして時は動き出す

ちょっと業務多忙で落ちていた隙に、060turboX 仮予約が始まっているではないですか！

Nereidの時もそうだったし、いつもタイミングを外してしまう私って一体・・・ orz

それはともかく、ベリグです！1.5日で40人超とはすごい勢いとしか言いようがないですね～。

私的には Nereid も更に1枚欲しいし、68060RC50 も必要だから流石に全機種装備は厳しいですけど(^^;、060turboX/030 を夢見つつ、060turboX/000 に行かせていただきます(^^)/

　『040turbo に手が出なかった、あの時の思いを今ここに！』

[カテゴリ:x68]

2006-8-23

それって、もしかして

なかなか世間に追いつけない今日この頃なのですが、こ、これって、もしかして 060turboX はとってもプログラマブルな DMA にもなっちゃうんでしょうか？！

速報！060turboX追加新機能について(X68K.NETさん)

040turbo本で、キャッシュ書き出し時に長時間取られてしまうことで受信キャラクタを取りこぼすことがある・・・といった話があったと記憶していますが、これだったら FPGA が処理しちゃうから取りこぼし無しの、めちゃめちゃ反応のいい割り込み処理が実現できてしまうのでしょうか（わくわく）。

DMA と聞くと、GRAM クリアだ～とかしかすぐに思いつかないのが自分の底の浅さなのですが(^^;、MC68000コードのサブセットとなると、ある程度複雑な処理まで実行できてしまうということですよね。一般的な割り込み処理は一切まかせてしまってMPU は本来の処理をひた走る・・・う～ん、これは凄いかも！

I love MC68000 ニーモニック☆

read_s() のこと

あや、補足されてましたか^^;

昨日アップしたものは Human68k 上でちゃんと動作するようにしてあります。

EXPERT と 030 、それから実験用の cygwin の3者を交互にサーバにしたりクライアントにしたりして、文字列送受信を試していましたが、server1.x では recv len = -1 が何回か続いた後にようやく受信完了となるのに対し、cygwin上や NetBSD/x68k 上では read() 発行後すぐに文字列が入って来るのですね。

まぁ、すぐに入らないのは処理の問題だろうから良いのですけれど、read() の戻り値が正ならその値だけ読み込んでいて、0 なら未受信、負なら何がしかのエラーだから処理を抜ける・・・という感じで組んでたので、予想と違った動きに？？？となったのでした。

そうか、tcppack-b の sample でなく ftpf.x を見れば良かったのですね(^^;

またちょっと潜水してお勉強しよ～っと。

[カテゴリ:x68]

2006-8-22

ソケット通信を試してみた

68でネットワーク・プログラミングなど試してみようかと、X68000 LIBRARY のソフトウェアと、桑島技研Online の桑島技研ARCHIVES とNereid特設ページより、開発ツール＆ライブラリを入手して四苦八苦してました(^^;

とりあえず、簡単なソケット通信のサンプルを・・・ということで、クライアントから文字列送信し、サーバでそれを受け取り送り返すというよくある物を試しましたが、戻ってくる文字列がめちゃくちゃで全然使えず (--;

cygwin上で同じのをコンパイルして試すと、cygwin がサーバ、68 がクライアントなら問題なく動くのに、逆だと駄目なんですね。

何だろうなぁ・・・やはりサーバ側になるのは無理なのかなぁ・・・などと数日悩んでしまいましたが、結局のところ、read() が戻り値 -1 で返ってきてて、そもそも受信できてなかったというオチでした(^^;

cygwin上では read() ですぐに値が入ってくるのですが、Human68k上では受信データが read_s() で入ってくるまでに結構時間を要するんですね。socklen() や errno などを見つつ、read_s() の戻り値が -1 でも処理を続行するように（読み出しを続けるように）したら何とか動きました。

socket1.LZH 　←いい加減な作りですがとりあえず

ただ、cygwin 上では、何もデータが入ってこなかった場合には戻り値は 0 になるので、read_s() でこの場合に -1 が戻ってくるのは変だなぁと思うんですけどね。（どこかに対策ライブラリとかパッチとかあるのかな？）

なお、NetBSD/x68k で同じプログラムをコンパイルした場合には、受信に時間がかかるなんて事はありませんし、read() の戻り値もまったくもって正常ですので、念のため。

[カテゴリ:x68]

2006-8-18

usbjoy.x 1.2e ですってば

plasticさんのサイトで配布されているusbjoy.x が 1.2e にアップされました！

何が嬉しいかって、手元のUSBマウスのうち今まで動かなかったMA-LS1DS もこの版から利用可能になったのですね～。なんで動かないのかなぁ？と悩んでいる間に利用可能になって、なんともありがたい話です。

ジョイパッドにしてもマウスにしても、とても実用的なものですので、Nereid の USB端子が空いている方は、試してみてはいかがでしょ？(^^)

X68k のクロック

今更ながらですが、X68kのクロックについて。

初代～SUPER,EXPERT II,PRO II までの、要するに XVI より前の機種はMPUとSYSTEMが共通のクロックなので、拡張スロットにも MPUクロックそのままの 10MHz が出ています。

XVI 以上の機種では MPUがより高速なものに変わりましたが、互換性を保つために拡張スロットには従来と同じ 10MHz が出力されています。これは、MPUクロックとSYSTEMクロックが分離されているからです。

なので、MPU をクロックアップした場合、XVI, 030 等は良いのですが、それ以前の機種では拡張スロットまでクロックアップしてしまうのですね^^;。

当然、カードによっては全く動かない物も出てきますので、17.5MHz 駆動の Nereid & EXPERT は、あくまで自己責任です、はい。

・・・20MHz (80MHzのオシレータ) 挿したら本体起動しなかったし^^;

[カテゴリ:x68]

2006-8-15

そしてSASIディスクがこけた(--;

USBマウスがあまりに便利（使ってるのは Logitech の古めの光学式 Wheel Mouse）なので、標準のマウスをはずしてしまったトラップです。

長時間の連続稼動テストということで、SX上で耐久ピンボールを行ってみましたが、今のところ自分のピンボールの腕の悪さを除いては、ほぼノープロブレム。

・・・と思ったら、あれ、ボタン反応しないし画面が固まる？SX上に白帯？あれれれ？

よく見ると HDD LED がずーーっと点きっぱなしで、電源入れ直しても起動してこない。前々から調子悪いなぁとは思っていたけど、ついに内蔵の SASI HDD の動作が怪しくなったようです。考えてみれば年代物ですからねぇ・・・。

しばらく時間おいて冷ましたら起動してきたので^^;、データを吸い出して内蔵 SASI-HDD を取り出し、外付け SCSI-HDD に切り替えましたとさ。めでたし。めでたし。

[カテゴリ:x68]

2006-8-14

FDが動いた～

手元にパナのUSB-FDD（中身はTEAC）があるんですが、これがどうやっても68で使えない(--;

普段は Nereid の NIC 経由でやり取りしているから 3.5inch FDD が今すぐ必要というわけではないんですが、繋がるドライブがあるのなら繋げてみたいのが人情。

そこで、手堅く Y-E Data ドライブの TOSHIBA PA2680U を入手して試してみたら、あっさりと認識 (要 usbfdd-0.4a）するじゃないですか。USB-FDD と一口に言っても、色々違うんですねぇ・・・（しみじみ）。

完全に安定しているとは言えないけれど、これで FD でも受け渡しができるとなると、なんか楽し～。開発された方々に感謝感謝！

しかし、68で使うと、1.44MB の FD メディアって広いですねぇ(^^;

そしてUSBマウスも（うるうる）

なかなか更新の早さについていけてませんが、USBジョイパッド＆マウスドライバの usbjoy.x が v1.2c に更新されています！

無改造の 030-25MHz ではすんなりマウスが使えたので気づかなかったんですけど、v1.2 では EXPERT-17.5MHz のクロックを落としても Nereid 入れ替えても（初期版 SL811 Rev1.2 と白薔薇 SL811 Rev1.5）うまく常駐できないでいたのですね。

v1.2c ではどちらの Rev. でもスムーズに常駐できて使えてとてもい～い感じです。マウスの動きもなめらかになって、純粋に使い心地という点でも良いです(^^)。

これでマウス・デバイス不足の悩みからも解放されそうですね、素晴らしい！

[カテゴリ:x68]

2006-8-5

熱い夏 68の夏

急激に真夏になっちゃいましたね。自分の体よりもマシンの方に扇風機を向けながら【ゆみみみっくす】で遊んでいるトラップでしたが(^^;、そんな事してる間にも x68 USB事情は急展開してるのでした。

X68業界初！USB-JOYPADドライバ登場！(X68K.NET)

え？USBマウスの予定もあり？plasticさんすごすぎるわぁ(^^;。

Nereid, 060TurboX, USBドライバ・・・まさに今年の夏は『熱い』ですね。いずれは赤い基盤のNereid に、68060-75MHz で 3倍早くして、USBでびしばし繋いで、それで、それで・・・（夢は膨らむ）

[カテゴリ:x68]

2006-7-30

機能限定版の罠でした^^;

え～、とりあえず yumimi.x と sstart.r でCD-DA が鳴るようになりました。

まず計測技研の CDDEV.SYS は、機能限定版だったために CD-DA が使えなかったみたい。山崎氏のCDDRV.SYSを使ったら、あっさりとオープニングが聴こえてきました(^^)/

 [config.sys]
 DEVICE=\SYS\CDDRV.SYS /I6

動き出したらエンディングまで！というわけで、元気！元気！元気！が鳴るのも確認できたし、何はともあれ良かった良かった。

・・・で、まだ良くわかってないのが SUSIE v1.21A で鳴らない理由。CDDEV.SYS互換の再生機構はあるんだけど、yumimi.x とかからの呼び出し方が違うのかな？disって見る限りは動きそうな気がするんですけど、ふむむ。

[カテゴリ:x68]

2006-7-29

ゆみみでどってんばってん

時代を遡っているような気もしないではないですけれど、MEGA-CD 版のゆみみみっくすを入手しました。ええ、もちろん X68k上で動かすためだけに・・・^^;。

今更何を語るまでも無いでしょうが、ゆみみ☆えっくすは、メガドライブ MEGA-CD 版のゆみみみっくすを X68k 上でプレイできるGood なソフトです。使用するためには、この他に CD-ROM ドライバと、PCM8 互換品があれば OK。

 [config.sys]
 DEVICE=\SYS\SUSIE.X -ID6 *:

SUSIE.X で CD-ROMドライブを使えるようにし（上記では SCSI-ID 6）、後は次のようにすればプレイできます。

 pcm8a
 ymdrv
 yumimi -G

ESC で一時停止、その状態で q を押すと終了。カーソル or 2,4,6,8 キーで選択して、スペースやリターンで操作です。ところどころ同期が取れず黒い背景が出るとか、スクロール時に動きがぎこちないところがありますが、030クラスなら十分遊べますね。

この他にも幾つかゆみみみっくすプレーヤーがあるようですが、きいちご魔法店の山崎さんの sstart 0.11 は動きが軽快で拡大縮小もとても滑らか！朝寝坊して学校に向かうシーンでちょっと背景画像が抜けるところがあるのが気になったくらいで、全然無理なく楽しめます。

BGM再生のためにはゆみみ☆えっくすの ymdrv を使用しますので、次のようにして起動してください。操作方法も大体同じです(^^)。

 pcm8a
 ymdrv
 sstart

といったわけで、030 で快適・綺麗なゆみみみっくすなのですが、トラップめの環境ではたった一つ問題が・・・オープニングとエンディングの CD-DA が鳴らないのです(涙)。動くオープニングを見ながらアチチッチを聞きたいのですってばぁ～どってんばってん。

SUSIE は v1.21A、CDドライブは TEAC CD-R55S を使ってるんですけど、何か違うのかなぁ。一応、cd2pcmt 使えば鳴る（無論、CDドライブのライン出力から）のは確認取れてますけど。

ふむむ。

[カテゴリ:x68]

2006-7-23

CTTYコマンド

Human68k Command.x 内蔵コマンド。CTTY AUX <Enter> にて標準入出力とエラー出力を補助入出力(AUX)に切り替えることができる。具体的には、次の DOSコールが内部で実行される。

 dup0(3,0)
 dup0(3,1)
 dup0(3,2)

なお元に戻すには、シリアル端末側から CTTY CON <Enter> を行う。こちらも具体的には次のDOSコールが実行される。

 dup0(0,0)
 dup0(1,1)
 dup0(2,2)

さて、本コマンドにより、コンソールではなく、シリアルポートを介して別な端末からの操作が可能となります。DOSコールだけを使って作られたプログラムであれば、これだけで十分いけますね。

ただ、実際に使っていこうとすると、付属のスクリーンエディタ ED.X でさえも満足に使えないことがわかります。DOSコールだけでなく、IOCSコール使ってるんでしょうねぇ。

さすがにハードウェア直接アクセスされてたら困りますが、この辺り、ごにょごにょやったらどうにかならないかな？(^^;

[カテゴリ:x68]

springテーマの色をちょっと変更

そのうちに他のスタイルを試してみるからいいや・・・と放置してたものの、あまりに見づらいのでリンク文字色を今頃になって変更。しばらくこれでいいかな(^^;。

2006-7-19

Mach2で展開を試してみたら

NetBSD 3.0 の pkgsrc.tar.gz 展開を、SCSIカードを Mach-2に変えた以外は先日と全く同じ環境にて試してみました（なお、pkgsrc.tar.gz は約38MB で、展開後は約300MB程度に膨れ上がります）。

あくまで参考値でしかありませんが、内蔵SCSIでは 4時間かかったものが、Mach2 では 2時間半で済んだので、まずまずといったところです。

さすがに lynx をコンパイルし直す気にはなれなかったですが、CPU が速く、高速なディスクアクセスができるようになったら、こうした事も気軽に試せるでしょうね。とりあえず今は、ノーマルでどの程度であったかを肌で感じておこうと思ってます^^;。

しかし、こうして改めて考えると、スペックに対してHuman68k 環境上の快適さって凄いものがありますね。またしばらく Human68k 環境に戻ろうっと！

[カテゴリ:x68]

2006-7-18

続々・Lynxコンパイル

ふぅ、ようやっとlynxのコンパイル＆インストールが終わりました。まだ環境まわりで多少問題はありそうですが、ちゃんとブラウズできてます(^^)。

それにしても make を実行してから約24時間、まる一日かかってしまいました。井崎さんのサイトによると30MHz 環境下で gcc のコンパイルに6時間だったそうですが、lynx ってそんなに大きかったかなぁ？も少し早く終わっても良さそうなものですが。

＃ずっとディスクにアクセスしていることだし、Mach2 にしたら早くなるかな？

あ、なお、バイナリ使うだけならhttp://www.jp.netbsd.org/Ports/x68k/ の News にあるように、m68k すべてで利用できるバイナリ・パッケージがありますので、便利いたしませう。

教訓：自分で make してみてわかるバイナリ・パッケージのありがたみ (-人-)

[カテゴリ:x68]

2006-7-17

続 lynx コンパイル

昨日、あまりにも進まないので途中で止めてしまった lynx コンパイルを再開。よく見ると、ソース・アーカイブを展開する作業 (bzcat) に時間がかかっていた模様。先程 configure が走り始めたから、おおむね 12時間程度かかりましたね。

とりあえず、今日中に終わることを願ってこのまま続行(^^;

[カテゴリ:x68]

2006-7-16

NetBSD 3.0 を入れる

連休に入ったので、長時間かかりそうなもの・・・ということで、NetBSD 3.0 を試してみることにしました(^^;。

NetBSD 3.0 は、x68k 用の ISOイメージが上がっているので、Human68k で CD を使える環境なら導入は結構簡単です。ミラーサイトからイメージ落として、さくっと焼いてしまいましょう。

 ex. ftp://ftp.jp.netbsd.org/pub/NetBSD/iso/3.0/x68kcd-3.0.iso

使用する HDD は、手元で余っていた 4GB のを選択。以前は、Human68k の FORMAT.X で装置初期化した HDD を使ってくださいと言われていたようですが、HDD を丸ごと全部 NetBSD で使うのなら、そのままNetBSD を入れて良いみたいです。ちなみに、250GB の HDD でも fsck に時間がかかるだけで、すんなり入ります。2GB 制限とか 16GB 制限なんてありません(^^)。

CD から netbsd-INSTALL.gz を取り出して展開し、loadbsd.x で起動。

 gzip.x -d netbsd-INSTALL.gz
 loadbsd.x netbsd-INSTALL

あとは、テキストメニューに従って操作していけば、大体数時間でフルインストール完了です。

起動後、/etc/rc.conf 直したりあれやこれやありますが、詳細はまた別途書くとして、現在は pkgsrc 落としてきて試しにコンパイルしてみている最中。

38MB のファイルを tar xzvf で展開するだけでも 4時間ほどかかりましたが、lynx の make にかけている時間は、かれこれもう8時間ほど。

25MHz 無改造（あ、MC68030 への交換と FC2ピン折り済みね）だとこんなとこなんでしょうか？ま、メモリも少ない (12MB）ですからね。コンソールで使う分には結構いろいろできるんですが、X 上げるのはさすがに厳しいし。

というわけで、060TurboX が楽しみです(^^)/

ん？bzcatで止まってる？

さすがに遅いので変だな・・・と思ってみると、bzcat で延々と時間がかかっている様子。裏で mpack を make してみると、それなりに進んでいるみたいので、とりあえず lynx の方は停止しておく。

[カテゴリ:x68]

2006-7-12

あ、びっくし^^;

X68K.NETさんAdmin Diaryに、ここの話が出てて驚いたトラップです。

＃TV をつけて見たら自分が映ってた・・・みたいな感じ^^;

神々のような働きはできずとも、自分にもきっとできることはあるはず。見てるだけでも楽しめる68000ニーモニックで、21世紀もがしがし行きまーす！

とりあえずリハビリ兼ねて基本的なとこからおさらい中(^^)

2006-7-8

想像もできないです(^^;

X680x0 の隙間を埋める活動を展開されているX68K.NETさんの日記によると、060turboX 仮予約の人数が50人を突破とのこと！Nereid復活再生産も始まりましたし、いや～激しく熱いです。

レジスト色を青にするか白にするかアンケートがありましたが、今回のレジスト色は白に決まったんでしょうか？Nereid白基盤は撮影が難しくて表現しづらいんですが、実物のイメージを損なわない綺麗な写真がアップされてるので、ぜひ見てうっとりしませう(^^)。

それはそうと、060turboX 配線し直しって大変なんでしょうねぇ・・・。私だとわずか数本のラインでさえまとまらずに苦しんでいるのに、それが数百本あるわけでしょ？全然想像もできない次元です(^^;。

と、ともあれ、電解コンデンサ交換して待ってます！

BIND.X : オーバレイXファイルの作成・変更

Human68k の実行可能ファイルには、X, R, Z の 3つのタイプがあります。この内、.X ファイルは構造を持った実行ファイルであり、Human68k v2.00 以降では 1つのファイル中に複数のファイルを持てるように拡張されました（オーバレイ X ファイル）。

BIND.X を使うと、圧縮はしないものの LHA や ZIP のような感じで、複数ファイルをひとまとめにでき、Human68k DOSコールの EXEC で、引数 MD の上位バイトにモジュール番号を指定して、自由にモジュールを切り替えてロード/実行できるようになります。

例えば、プログラムを幾つかの部分に小分けしておけば、全体では本体メモリよりも大きなプログラムであっても順々に呼び出すことで実行可能になるよと…いうのが効能ですが、X680x0 のようにメモリ量が多かったり、仮想記憶があるOS (NetBSDとか) だと必要性の薄いものといえます。

とは言え、必要なデータファイル等もまとめて1つにできるとなると便利なので、今にして思えば、もうちょっと拡張されていれば、SX 上のプログラムも複数ファイルに分けずにすっきりできたかも知れませんね。

 A>bind
 X68k Binder v1.00 Copyright 1989 SHARP/Hudson
 使用法：bind [スイッチ] ファイル名 [ファイル名・・]
 	/u	ファイルの更新（ディフォルト）
 	/x	Ｘファイルの取り出し
 	/d	Ｘファイルの削除
 	/l	リスト出力
 	/o file	バインドファイル名指定
 	/t path	テンポラリパス名指定
 
 	/u /x /d /lのスイッチはどれか一つを指定します
 	/lスイッチを付けた時はバインドファイルのみ指定します
 	/oスイッチを省略すると最初のファイルを操作します

 以下、STUDIO KAMADA 情報
 
 /A+R または /A+S の指定で、BIND.X /U で内容を更新できないようにできる
 /A+H または /A+S の指定で、BIND.X /L でファイル名を表示しないようにできる

BIND.X で表示されないファイル名を表示する

Human68k v3.02 の FORMAT.X も BIND.X で作られたオーバレイXファイルですが、BIND /L format.x してみても、次のようにファイル名が表示されません。

 A>bind /l a:\bin\format.x
 X68k Binder v1.00 Copyright 1989 SHARP/Hudson
 =No=         =name=          =length=   =date=   =time=  =at=
    0 -system reserved file- ---------- -------- --:--:-- ----
    1 -system reserved file- ---------- -------- --:--:-- ----
    2 -system reserved file- ---------- -------- --:--:-- ----
    3 -system reserved file- ---------- -------- --:--:-- ----
    4 -system reserved file- ---------- -------- --:--:-- ----
    5 -system reserved file- ---------- -------- --:--:-- ----

バインドされているファイル名がわからないと、BIND /X で取り出すこともできなくて困るので、きっとどこかに情報なりソフトなりがあるのだろうと思いつつも見てみました(^^;。

まず最初に format.x ファイルをバイナリダンプしてみたら、ちゃんと末尾にファイル名が記録されていますし、その名前でファイル取得するとすんなり取り出せます。そうなると、ファイル名を隠しているのはBIND.X それ以外に有りえません(^^;。

そこで、dis で BIND.X を逆アセンブルして見ていくと、見事に先の目隠し文字列がありました。

 L0019e6:
 	.dc.b	'-system reserved file- ---------- -------- --:--:-- ----'

次に、この文字列を表示しているところを探してみます。

 L000cbe:
 	pea.l	(L0019e6)
 	DOS	_PRINT
 	addq.l	#4,a7
 	unlk	a6
 	rts

更に、このサブルーチンを呼んでいるところを探すと次の2行が見つかりました。

 	btst.b	#$01, ($001b,a3)
 	bne	L000cbe

よくはわかりませんが、$1b(a3) は何かのフラグ（アトリビュートでしょう）になってるようであり、1ビット目が立ってれば目隠し文字列表示処理に飛ぶんだとわかります。そこで、修正箇所を最小限にする為に、

 	bne	L000cbe

の部分を

nop

に置き換えて、非表示であっても分岐しないようにしてみました（8bit ディスプレースメントだったので、nop 1個で OK）。これで先の format.x を見てみると、次のようにちゃんと表示されるようになり、目的達成です。

 A>bind /l a:\bin\format.x
 X68k Binder v1.01 Copyright 1989 SHARP/Hudson
 =No=         =name=          =length=   =date=   =time=  =at=
    0 FORMAT.X                      328 93-01-27 10:38:08 A---
    1 FORMAT1.X                    4196 93-03-30  9:07:24 A---
    2 FORMAT2.X                   71946 93-03-30  9:49:24 A---
    3 FMTDPB.FMT                   2488 93-03-30  9:08:26 A---
    4 FMTHD.FMT                    9740 90-05-09 13:18:22 A---
    5 MOFMT.FMT                    2120 92-12-15 15:52:50 A---

以上、BIND.X 3分間クッキングでした。

[カテゴリ:x68]

2006-7-2

GOverHD.x は必須なのですね

さて、前述のように 250GB の HDD を接続しましたが、ファイル・コピーの途中で失敗してしまいました (--;

 SCSI-ID : 0 ... 230 MB （c:20MB,  d:210MB  の2パーティション）
 SCSI-ID : 2 ... 250 GB  (e:900MB, f:2000MB の2パーティション）

こんな構成で d: に入っているファイル群を copyall で f: にコピーしたら、途中で「セクタが見つかりません」の白帯が出て止まるのです。250GB の方のパーティションをサイズを変えながら切り替えていった結果、どうもデータ領域で 1GB を超えたところで失敗している様子。

どこかで聞いた事のある 1GB の壁。もしや・・・と、GOverHD.x 2 を実行して250GB のディスクにも GOverHD 処置を施したら問題なく使えるようになりました。てっきり SCSI-ID の小さい方だけ適用されてれば大丈夫かと思ってましたが、そうじゃ無かったということですか。

やはり、1GB を超えたら GOver.x はお約束なのですね。FORMAT.x の GOver 対応版 FORMATa.x を使うと良いと聞きましたが、どこにも見つからなかったもので (^^;

copyall とバスエラー

NetBSD で X を使う為に 68030のFC2ピンを折りましたが、copyall.x を実行するとバスエラーになることに気づきました。030syspatch を常駐（DEVICE=で組み込む）していると問題はないのですが、何でかなぁと。

そこで db.x 上で copyall.x を動かしてみると、一番最初のサブルーチン・ジャンプでバスエラーが起きています。copyall.x は起動後、自分に割り当てられたメモリの最後のアドレス+1 のロングワード境界をスタックポインタに設定します。

 move.l 8(a0),d0
 andi.l #$fffffffc,d0
 movea.l d0,a0

このマシンは12M実装済みだから USP の初期値は 0xc00000で、最初のスタックアクセスは 0xbffffc になり、ここでこけているわけです。

メモリはあるはずなのに何でこけるのかな？と db.x 上から書き込もうとしてもやはりバスエラー。？？？と思いつつよぉ～く考えてみると、何のことはない、030syspatch がこの領域を 68030 で使うように設定してるんですね（0xbea000 ～ 0xbfffff の領域）。

config.sys から外しても無効にならないので、何故だろう？と悩みましたが、考えてみれば通常は HD から起動（030Syspatch 組み込み）し、その後はCTRL + OPT.1 + DEL でソフトリセットかけているから CPU 自体への設定はそのまま有効だったということのようで。・・・というわけで、ハードリセット（リセットボタン）押して起動すれば、030Syspatch が無くとも copyall が動きましたとさ。

大抵のプログラムだと、自分自身の最後の領域から何キロバイトかをスタックにし、残りのメモリは OS に返却してるから気づかないのですが、copyall.x はメモリ領域全部を取って、その最後にスタックを設定してしまうのでこんな現象が出たわけですね。

気づいてみればそのまんまですが、面白いものです。

[カテゴリ:x68]

2006-7-1

13時間でした

HDXG-40 の中身を Hitachi/IBM IDE 250GB に換装したものを使い、FORMAT.X の装置初期化にどのくらいかかるか試してみました（何て暇人な^^;）。

この前の 13GB のから推測すると、下手したら1日～2日かかるのかなぁと覚悟していましたが、10:00 に始めて 23:00 に終わったから、大体13時間という結果ですね、良かった。

ちょっと領域確保して使ってみた感じでは、内蔵SCSIインタフェースなのであまり速度は出ません（1MB/s）が、とりあえず使えてるみたい。

Human68k で使うと、250GB の先頭数GBしか使えなくてもったいないと言えばもったいないのですけどね・・・。

パーティションとファイルシステム

パーティションを切って、その中に何がしかのファイルシステムを作成する・・・というのが今の一般的な操作ですが、FORMAT.X の場合は、パーティションを切る事とファイルシステムの作成が一緒になって【領域確保】なんですよね。

後に NetBSD のファイルシステムによるフォーマットが出たとはいえ、この当時はファイルシステムは一つしかないし、わざわざ分ける必要は無かったという事でしょうか。

[カテゴリ:x68]

2006-6-27

Nereid は良かですたい！

Nereid （ネレイド）は、X680x0 シリーズに装着して LAN & Memory & USB 機能を付加するインタフェース・カードです（ X68K.NET 参照）。写真のように、本体の拡張スロットにぴったり収まる美しさはまさに絶品！（写真：右スロットが Nereid）

5インチのフロッピーディスクも滅多に見当たらなく、他機種とのデータ交換自体も難しい昨今ですが、LAN にさえ繋がってしまえば物理メディアの制約なしでデータのやり取りができ、ネットワークという共通基盤への仲間入りを果たすことができます。030以上のMPU (with MMU)を積んでれば NetBSD だって動きますし、16MB のメモリもあるし、USB インタフェースも装備となると、現役ユーザなら是非お手元に一枚！って感じです。

さて、かように素晴らしき Nereid ですが、Nereid復活再生産プロジェクトも既に開始が決定しており、もうそろそろ締め切りになっちゃうので LAN未接続の X68 user はお早めに申し込まれてはいかがでしょうか(^^)。

NereidのUSBが熱い

ここに来て USB の方も盛り上がってきてますね～。

X68K.NET管理人さんの日記より

Windows や Linux では、普段ごく普通に使っている USBデバイスですけれど、それだけに、動かせるようにしていく過程なんて滅多に味わえないわけで、非常に面白いことだと思っています。

さすがにこればかりは実機が無いと試しようがない（日本全国飛び回ってるので触れないのです^^;）のですが、ソース読んで気分だけでも参加したいなぁと思ったり。

[カテゴリ:x68]

2006-6-25

大容量ディスク、うまくいかず

X68030 を手に入れて使ってみています。内蔵の SCSI-HDD では容量が少なすぎるので外付けのディスクを装着することにしたのですが、今のところうまくいかず (--;

そもそも今時 SCSI外付けHDD なんて滅多に見かけませんが、アイ・オー・データの HDXG-40 が IDE-SCSI変換基板搭載（つまり、別のIDE-HDDに入れ替えられる）な上、1台を論理的に2台のドライブに見せる機能などついてて便利とのこと。早速入手して中身を 250GB の IDE ディスクに交換してみました。

とりあえず Windows で確認してみる限り、認識・動作とも問題なくマルチドライブ機能も正常なので、それじゃあ・・・と x68 に繋いだところ、一応 250GB の認識はできているものの、format.x の装置初期化が全然終わらず。時間がかかってるだけなのかどうかも？？？。

試しに NetBSD 3.0 を入れてみると問題なく初期化して使えているし、250GB-HDD からのブートもできるのでディスクのせいではないでしょう。ん～、4GB までは Human68k からすんなり使えたんだけどなぁ・・・何かあるのかな？

もうちょっと情報集めてやってみよっと。

13GB で 2時間半でした

さすがに 250GB はでか過ぎたかなぁと思い直し、13GB のディスクでやり直してみました。ディスクからアクセスしている音は聴こえてくるので、一晩放置するつもりで【装置初期化】を実行した結果、約2時間半で完了しました。ふぅ、長かった。

領域確保（パーティション切り）は、安全を考えて900MB, 2048MB の2つの領域を確保。リブート後、内蔵ディスクから copyall で一気にシステムファイルをコピーして起動確認取りましたが、こちらも問題なし。いや、良かった良かった。

・・・しかし、13GB で2時間超だとすると250GB の装置初期化にかかる時間は・・・もしかして丸二日ですか？

必要な情報だけ書き換える簡易版の format.x って無いのかなぁ。さすがに丸二日かけるのは厳しいし。全領域ゼロクリアしてるのかな？もしかして。

何はともあれ、動いて良かった (^^;

[カテゴリ:x68]

2006-6-23

サマータイム【は】不要

メディア等でサマータイムの話が出てたので、思ったことをつらつらと。

北海道で一部サマータイムもどきを実施して効果があったとかで、また今年も大々的にやるそうですが、サマータイム論議とこれとを一緒にして欲しくないですよね、そもそも違うものなんですから。

サマータイム: 時計の針を夏期間だけ1時間早める

北海道のそれ: 出社時刻・退社時刻を1時間ずらす（時計は変えない）

北海道でやってるのは、「時計の針を動かさずに」「会社や学校の開始時刻＆終了時刻を1時間早める」こと。これで効果があったと言われたのは、(1) 夕方の光熱費が減った, (2) 退社後にショッピングとかできる等ですが、それって単に「フレックスタイムなら退社後の時間を有意義に使える」のと同じような話じゃないのかと。

自分だけが早く帰れるからメリットが多くなるのであって、時計を進めて皆が1時間早くなったら、(1) しか残らないでしょう。

そして忘れてはならないのが、日本は意外にも横に長い国だということ。九州に行って驚いたのが夜遅い時間まで外が明るかったことです。考えてみれば当然で、東京よりも遙か西にあるんだから、年中サマータイムしてるようなものです。

逆に言えば、明け方は同じ時刻でも暗いので、そこにサマータイムが導入されたら余計ひどいことになるでしょう。

サマータイムを本当に活かしたいのであれば、日本もアメリカのように複数の時刻を使って（日本標準時を2つか3つに分けて）、その地域に合った時刻体系にしないと意味がないってことになります。

一つの標準時で運行されていることにより多大のメリットがあるのに、それを捨ててまでも導入すべきものですかね？無理・無駄・無意味の3拍子揃い踏みですがな。

いや、それでもなお「明るい内に仕事して暗くなったら帰るのが自然だ」と言うのであれば！江戸時代のように「日の出・日の入り」をベースとした可変時刻体系を使ってはどうだ！それこそサマータイムの究極形でしょ(笑)

ま・・・どっちにしても、深夜でも煌々と明かりがついている日本では何をどうしようと「サマータイムにすれば光熱費が浮く」みたいな話は無いわけで、無意味なもんを導入するくらいなら他のことを模索すべきと思うわけです。

個人的には、通勤ラッシュを避けられるフレックスタイムの方がいいな :-)

補足：時計を1時間ずらすサマータイムにはメリットは感じない。出社・退社時刻をずらす北海道方式は良いと思うが、それをサマータイムと呼称するのは間違いで誤解のもとと思う。

ANA-NOTE

問題なく使えているようで、何か直して入れたといった記述も無い模様。

何でだろ？と cgi 眺めていたら、改行コードが CR+LF だったというオチ。普段からバイナリ転送してるのが仇となったか^^;。

つまらないミスだけど忘れないように記録しとこっと。

NetFront3.1で奇麗に見えなかったので

ふとザウから見てみたら、右側に出していたサイドバーが左に重なって変な表示になってたので、tDiary スタイルのspring にしてみました。

それにしても、京ぽんではちゃんと見えるんだから、もう少しスタイルシートへの対応を良くして欲しいところ。ザウもOpera にすれば済む話ではありますが、入ってるものを無下にするのもあれなので ^^;

2006年以前 2007年 2008年 2009年 2010年 2011年 2012-16年

<< 2024-11 >>
日	月	火	水	木	金	土
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

Diarys2006

software

Contents

Diary

Link

Other