[リストへもどる]
新着記事

タイトルRe^8: NRTDRVのリモート再帰転送
記事No283   [関連記事]
投稿日: 2009/07/21(Tue) 12:35
投稿者管理人
>専用DLL使用版のNRTDRVをようやく公開できました!
NRTDRVの更新&公開、ありがとうございます。

RTS-DSRフロー対応はまだやってないです。自分の必要がないもの
で腰が重くなります。やれば半日仕事なんですが...

とにかく、これで1台でもX1の実機環境が増えることを願います。

>・設定できて、その速度での通信にも対応している
>・設定できるが、その速度での通信には対応していない
>・設定できない(エラーを吐く)
>という三種類の挙動がありそうですね。

多くのUSBシリアルでは、設定できないボーレートは設定
可能な近似値に自動調整されるので上記の2には、

・設定できるが、違うボーレートに設定される

というのが含まれます。
ですから、プログラム側のシーケンスとしては、ボーレート設定
後にリードバックして実際の値を確認するのが正解のようです。

200Kbpsを超えるとレベルコンバータの性能も問題になってきま
す。これはチップベンダ提供のドライバでは検出できないので、
実際に試してみるしかないですね。

それとは関係ないですが、ボーレートを手入力できるターミナル
ソフトって見かけませんね。組み込みだと106Kbpsとか中途半端
なボーレートが必要になったりするんですけど。

タイトルRe^7: NRTDRVのリモート再帰転送
記事No282   [関連記事]
投稿日: 2009/07/19(Sun) 09:52
投稿者なるっち
ご無沙汰しております。たいへん遅くなってしまいましたが、
専用DLL使用版のNRTDRVをようやく公開できました!

DLLは評価版とのことですが、完璧に動作していますので、
ご厚意に甘えて同梱させていただいています。
PC側のCTSレベルによるレディー状態の検出についても、
こちらでも正常動作を確認できました。

このような素晴らしい環境を実現してくださって
本当にありがとうございます!


それにしても、Win32APIのUSART対応がそこまで怪しかったとは…^^;
各動作に統一性がない上、エラーも吐かずにデータを取りこぼすとは
じつに恐ろしいです。
Windows上での通信プログラムの難しさを痛感してしまいますね。


あっ、PL2303のボーレートは実際には自由に設定できるのですね!

ということは…大きく分けて、
・設定できて、その速度での通信にも対応している
・設定できるが、その速度での通信には対応していない
・設定できない(エラーを吐く)
という三種類の挙動がありそうですね。

この辺の知識は皆無に等しいもので、先日は解釈を間違ってしまって
たいへん失礼しました…。


しかし、フロー制御方法の違い、ドライバによる挙動の違い、
I/Fのレスポンスの速度によるデータ取りこぼしの有無などなど…
本当にシリアル通信は一筋縄ではいかないっぽいですね。

そのような中、HSSIOのような素晴らしい開発環境をご制作された
管理人様の技術力のすごさを益々実感する次第です。

タイトルRe^6: NRTDRVのリモート再帰転送
記事No281   [関連記事]
投稿日: 2009/06/30(Tue) 20:17
投稿者管理人
専用DLLの方は評価版ということで、メールの方で直送させていただきました。
以後は、NRTDRVのあぷろだを利用させていただきます。

>最初、rts=hsのために、Win32APIの関数を叩く部分だけでも
>DLL化していただけたら
Win32APIのUSARTサポートは、実際使いづらいんですよ。
今でこそ不要になりましたが、制御やタイムアウトの方法を95系とNT系で
分ける必要があったり、バッファ管理やノンブロッキング処理もドライバ
依存でインタフェースによって挙動が異なったりと統一性がありません。

最近のメジャーチップでも、フロー制御が掛かる環境でDOS窓のCOPYコマンド
を使うとエラーなしでデータの欠落を起こすものもや、受信側がSTOPビット
を全く無視するものなど、問題がいろいろと潜んでます。

ターミナルソフト作る人は大変だと思う。本当に。

>X1のレディー状態までチェックできるようにしていただけたら
PC側のCTSレベルで判定してますが、管理人の環境では旨く動いてます。
ブロッキング転送なのは変わっていないので、通信中にケーブルを
引っこ抜くとハングしてしまいますけど。

>PL2303でググってみると「標準的なボーレートのみ対応」という
>話が出てきますね。
でも、実際には設定できるみたいです。DOS窓から
mode COM4 baud=125000

のように設定してみると分かります。
どう扱われるかはドライバ次第ですが、USBシリアル系では近似値に設定
されるものが多いです。レガシーCOMはエラーを返します。
表示された数値が実際に設定されたボーレートになります。
実際にその速度になったかどうかも、またドライバー次第なのですが...

タイトルRe^5: NRTDRVのリモート再帰転送
記事No280   [関連記事]
投稿日: 2009/06/30(Tue) 07:20
投稿者なるっち
X1hss.dllを再構築していただけるとは恐縮です!
最初、rts=hsのために、Win32APIの関数を叩く部分だけでも
DLL化していただけたら(もしくは僕のほうでDLL化できたら)と
思っていましたが、インタプリタ自体の遅さがネックとなると
X1hss.dllとしてご用意いだけたら安定動作しそうですね〜。

今は1回目の実行時だけダイアログを出すようにしていますが、
X1のレディー状態までチェックできるようにしていただけたら
この辺の処理分けもスマートになりそうで嬉しい限りです。

さらに、USBシリアルのボーレートの件も調べてくださって
ありがとうございます!
PL2303でググってみると「標準的なボーレートのみ対応」という
話が出てきますね。
改めて調べてみると予想以上にいろんなチップがあるようで
驚きます。その中でもFT232系とCP2102が定番らしいので、
これらのチップで設定できるとなれば心強いですね。

あと、アップローダーの件はメールさせていただきました〜。

タイトルRe^4: NRTDRVのリモート再帰転送
記事No279   [関連記事]
投稿日: 2009/06/29(Mon) 21:05
投稿者管理人
>取り急ぎ再アップしました。
>http://nrtdrv.sakura.ne.jp/arc/nrtdrv/NRTDRV_090629_test.LZH
ありがとうございます。

>それから、HSPの遅さに起因する可能性の仮説にもかなり納得です。
>x1term.exeで成功する理由も辻褄が合いますね。
少しx1hss.asを最適化したのですがX1hss.dllを使う方向に切り替えます。
HSP標準のCOMポートサポートが思ったほど小回りが効きかないのと、hpsext.dll
を同梱するなら専用DLLでも変わらないですから、x1term.exeと同等の速度と
安定度が得られる専用DLLの方が分がよさそうです。

CTS入力のセンスでX1のレディー状態をチェックできるので、それも盛り込
んでみます。

あと、USBシリアルでX1のボーレートに合わせる件ですが、FT232RLとCP2102では
X1側の125000bpsに設定できることを確認しました。
少し古いPL2303は12800bpsになるので、これは厳しいかもしれません。

># ふと、NRTDRVのサイトに関係者用アップローダーを設置するのも
># いいかな?なんて思ったりもしました。
これがあると、とても助かります。

タイトルRe^3: NRTDRVのリモート再帰転送
記事No278   [関連記事]
投稿日: 2009/06/29(Mon) 20:41
投稿者なるっち
ご、ごめんなさい!
こちらで安定稼働する状態に持っていくことができなかったもので、
ほとんど動作チェックできていませんでした(汗)。
動作確認と的確なご指摘、本当にありがとうございます。猛省です…。

さっそく管理人様のGRAM転送コードを組み込ませていただきまして
EveryTransfer=1のバグに関しても修正させていただきましたので、
取り急ぎ再アップしました。
http://nrtdrv.sakura.ne.jp/arc/nrtdrv/NRTDRV_090629_test.LZH

それから、HSPの遅さに起因する可能性の仮説にもかなり納得です。
x1term.exeで成功する理由も辻褄が合いますね。

そして、メールでのやりとりのご提案もありがとうございます!
掲示板の新着投稿を僕とのやりとりで埋め尽くしてしまっていて、
申し訳なく感じている所でした。

# ふと、NRTDRVのサイトに関係者用アップローダーを設置するのも
# いいかな?なんて思ったりもしました。

タイトルRe^2: NRTDRVのリモート再帰転送
記事No277   [関連記事]
投稿日: 2009/06/29(Mon) 15:48
投稿者管理人
なるっち様へ

> とりあえず、ほぼそのまま組み込ませていただいたバージョンを
> テスト版としてアップしておきますね。
> http://nrtdrv.sakura.ne.jp/arc/nrtdrv/NRTDRV_090628_test.LZH

LOADM,IOCS_Iを1度しか転送しない為、ので、2度目以降のブートができません。
(EveryTransfer=1の挙動も変です)

LOADM.COMは8000-FFFFのバッファにGRAMを使い、実行時にメモリに転送して実行する為、
LOADM.COMとIOCS_I.COMの転送を1回のみにする場合は、IPLPATCH.BINのREBOOTを、
下記のようにしてくださいませ。

;リブート、曲を停止してからIPLローダへ飛ばす
REBOOT:
CALL STOP
;CTC割り込みはしっかり止めます
DI
LD BC,1FA0H
LD A,3
OUT (C),A
OUT (C),A
INC C
OUT (C),A
OUT (C),A
INC C
OUT (C),A
OUT (C),A
INC C
OUT (C),A
OUT (C),A
EI
;PALET OFF
LD BC,1000H
OUT (C),C
INC B
OUT (C),C
INC B
OUT (C),C
INC B
OUT (C),C
DI
;再ロード時の為、LOADM,IOCSのB800-CFFFをGRAMへ転送
LD BC,0B800H
COPY_GRAM:
LD A,(BC)
OUT (C),A
INC C
LD A,(BC)
OUT (C),A
INC C
LD A,(BC)
OUT (C),A
INC C
LD A,(BC)
OUT (C),A
INC C
JP NZ,COPY_GRAM
INC B
LD A,B
CP 0D0H
JR C,COPY_GRAM
;HSS IPLローダへジャンプします
LD SP,0000H
JP 0B820H

タイトルRe^2: NRTDRVのリモート再帰転送
記事No276   [関連記事]
投稿日: 2009/06/29(Mon) 13:22
投稿者管理人   <support[あっとマーク]fpgapark.com(成形して下さい)>
なるっちさん

早速のNRTDRVへの組み込み、ありがとうございます。
時間が空き次第、管理人の所でも試させていただきます。

>ただ、hex125さんの環境(ノートPC+USBシリアル+X1turboZ)では
>データ転送の途中で停止してしまうようでして…
hex125さんの環境(=USBシリアルのIC or 型番)がわかるとよのですが。
こちらで不具合が再現できれば、対応できると思います。

>x1term.exeと比べると転送速度がかなり遅くなってしまっていたそうなので、
インタプリタでエンコードを行なっているので、ハイスペックのPCでないと
処理が間に合わないのかもしれません。
はやり、通信部分は専用DLL版にした方がよいのかもしれませんね。
以前にCOMブリッジを書いてるはずなので、ソースをサルベージしてみます。

よろしければ、メールでもやりとりをさせていただけないでしょうか?
テスト版を修正する度にweb経由というのも面倒ですので。

タイトルRe: NRTDRVのリモート再帰転送
記事No275   [関連記事]
投稿日: 2009/06/28(Sun) 16:02
投稿者なるっち
うおぉおお!!!!!
まさか実稼働のシーケンスまで仕上げていただけるとは!
ありがとうございます!
ここまで作っていただけるなんて想像だにしていなかったもので、
ものすごく感激です。どんなに感謝してもしきれません!(感涙)

ただ、hex125さんの環境(ノートPC+USBシリアル+X1turboZ)では
データ転送の途中で停止してしまうようでして…
2回試して2回とも止まってしまったそうなので、確率が厳しそうです(涙)。
症状から察するに、管理人様もドキュメントに書かれている通り、
通信エラーによってハングしているのかもしれません。
(x1hss_send実行中に止まるのですが、タイミングは毎回変わるようなので…)

ちなみに、NRTDRV.EXEのほうにも組み込ませていただきまして、
これもhex125さんのほうで試していただいたのですが、
5回試して1回だけ成功したものの基本的には同症状のようです。

さらに、成功したという1回に関しても、x1term.exeと比べると
転送速度がかなり遅くなってしまっていたそうなので、
純粋な転送エラーではなく別の不具合がある恐れもありそうです。

モジュール内の通信処理には特に問題らしい問題は見当たらないので、
もしかしたら、hspext.dllのCOM関連命令そのものに
環境依存の不具合があるのかな?なんて思ったりしました。
そうだとすると打つ手なしかも…(泣)。


とりあえず、ほぼそのまま組み込ませていただいたバージョンを
テスト版としてアップしておきますね。
http://nrtdrv.sakura.ne.jp/arc/nrtdrv/NRTDRV_090628_test.LZH
前バージョンに上書きしてご試用いただければ幸いです。
iniで「UseX1HSS=1」「UseX1term=0」とすると有効になります。

あ、少しだけモジュールに手を加えさせていただきまして、
プログレスバーの位置をいじらせていただいたり、
転送後に毎回プログレスバーを消すようにしてみたりしました。
あと、IPLPATCHはHSSと非HSSで共用するようにしています。

タイトルRe^16: NRTDRVの実機リモートブート
記事No274   [関連記事]
投稿日: 2009/06/28(Sun) 15:51
投稿者なるっち
うお!こんなにも小さなアダプタがあるとは…かなりビックリです。
教えてくださってありがとうございます!
僕の手元にあるアダプタは昔ながらの三角形っぽいやつなので、
時代の進歩に驚愕です^^;

そして、管理人様のシリアルアダプタが充実しているのは
お仕事で使っておられるからなのですね。納得です!

しかも最新ARM系環境にシリアル接続でISP書き込みですか!
すごい…
決してシリアル=レガシーではないんだなって実感できて、
なんだか嬉しくなります。

自作変換でLANケーブルをLAN接続以外に流用するアイディアも
素晴らしすぎます!
そういえば確かにLANケーブルって何気に8芯なんですね。
目の付け所と、それを実際の形にされるセンスが素敵です。

ところで、僕もすっかり109キーボードに慣れてしまったので、
昔の機種を改めて触ると却って戸惑うことが多いです^^;
割と近年まで触ってたはずのX68000ですら一瞬悩んだりして…。
キータッチは当時の機種が自分的に大好きなんですけどね。

もしX1用キーボードをUSB変換するとなると、改造の難易度に加えて
Deleteとかを紛れ込ませる場所も難しそうですよね。
INSDELキーにBackSpaceとDeleteのどちらを割り当てるかで
物議を醸す予感がします(笑)。

おっと!ほとんど余談になってしまいました^^;
失礼しました〜。