27512on2532 V01L02 ROM変換基板

　試作したROM 2532-27512変換基板を改版しました。

試作V01L01からV01L02の修正点：

・スリム化

・2532のVppをVddに接続する端子を追加。これにより2732~27512に対応したROMライタなどで2532の読み出しが可能。

回路図

部品表：

・28ピンICソケット 中央に桟がないタイプ https://akizukidenshi.com/catalog/g/gP-06740/

・24ピン連結ソケット　または12ピン1列連結ソケットx2 https://akizukidenshi.com/catalog/g/gP-01758/

・スライドスイッチ x4(任意)　https://akizukidenshi.com/catalog/g/gP-12723/

　はんだ付けは両面から行うためやや面倒です。まずICソケットをはんだ付けし、次に連結ソケットをはんだ付けするとうまくいきます。

　2532 ROMを読み出す用途にも使用できます。この場合はVpp-Vddをショートし、24ピンICソケットと28ピン連結ソケットを使用してください。

　boothにて配布予定です。

→販売開始しました。2532-27512変換基板セット2枚

ROM 2532 - 27512変換基板

　MZ-80CやCBM3032(PET2001)には4Kバイト、2532タイプのROMが使われている。この頃のPROMは2732タイプと2532タイプのピン配列があって、後の2764、27128、27256、27512タイプは2732のピン配置を元にしている。

　この時期、2732でなく2532が好んで？使われた理由は不明だけど、故障した2532タイプのROMを交換するには入手困難で手持ちのPROMライターでは書き込みも対応していない。代わりに中古で入手しやすい2764〜27512や新品で入手できるW27C512を使うために変換基板を作成した。

回路図：2532に27512の各信号を対応させ、あまったアドレスA12~A15を外部でセレクト。

配置配線：秋月D基板サイズで取り付け穴まで用意したが、そこまで必要ではなかった。

基板：

組み立て例：2532ソケットに27C256を取り付け。これはCBM3032のCGROMの代わり。

2764,27128,27256ではVppをしっかり"H"レベルにしていないと正常に動作しないことがある。これらのVppは27512ではA15、ピン1に対応する。

　逆に24ピン側にICソケットを、28ピン側に連結ソケットをはんだ付けし、ROMライタで2764などの設定にして2532のデータを読み出すこともできる。当初これを想定していなかったので2532のVppはオープンのまま(2532を取り付ける基板側で処理されていることを想定)。なので2532のピン21-Vppをピン24-Vccとショートさせる改造が必要になる。

　MZ-80CはCGROMとモニタROMの２つで場所も離れているので問題ないが、CBM3032はBASIC ROMが4個並んでいてこのままでは使えない。ICソケットを継ぎ足してゲタにし高さを調整すればささらないこともないが、作り直しますかね……

【ポリエステル製】のぼり ちゃんぽん 絶品 No.YNS-2532 （三巻縫製 補強済み）

のぼりストア

PASOPIA(PA7002)のマスクROM TMM2364Pのタイミング

　PASOPIA(PA7012)の分解写真と予防保守の続き。内蔵のOA-BASICは$0000-$7FFFに位置し、8KバイトのROM 4個で構成されている。これを追っていくと写真左上のLS139でデコードされ、右下-右上-左下-左上の順に$0000~、$2000~、$4000~、$6000~に対応する。

　最初のROMは普通のUV-PROMで残りはマスクROM。出荷直前にパッチでも当てる必要があったのだろうか。これらを前回作ったROMリーダで読んでみる。するとマスクROMが読めない。正確には常に同じ値になってしまう。

/CEを変化させてないのがいけないのかなと /CE="H"、アドレス設定、/CE="L"、データ読み出し の順で

やってみたら読み出せた。これはどういうことかな？

TMM2364Pのデータシートを見てみるとVpp(1)="H"、CS1(27)="H"、CS2(26)="H"、/OE(22)="L"にする。それぞれ基板上ではそのように接続されていた。

(CS1/CS2のenableはプログラマブルらしいがここでは"H"と判断できる)

となると/CEの挙動が通常のPROMとは異なることになる。

　データシートをみると/CEの立ち下がりでアドレスをラッチして後はOutput Enableに出力を任せるような動作だった。

　となるとTMM2364PがROMライタTL866CSで読めなかった理由も推測できる。Device IDを厳密に見て弾いたのか、あるいはTL866CSが/CEを変化させないでenableにしたまま、というのが考えられる。

　また、はまってしまった。

ROMリーダのスケッチもアップデートしときました：

https://gist.github.com/houmei/7ce0aef4632cebb38876423c84b843cb

Arduino MEGA直結ROMリーダーのトラブル

※追記　27512(64Kバイト)まで対応のソフトができました → readROM27512.ino Intel HEX対応

　ROMライタTL866CSでは読めないマスクROM(TMM2364P)があったので、Arduino MEGA用のアダプタを作った。秋月電子の片面D基板、ピンヘッダははみ出るので少しけずっている。

　Vcc-GND間に3.3μFの電解コンデンサと0.1μFのセラミックコンデンサ。

　ROMの端子とArduino MEGAのピン番号の対応は以下のとおり。27512の場合はROM(1)がA15、ROM(27)がA14、ROM(26)がA13。

あとpin52にタクトスイッチを繋いでGNDに落としている。これはPROMダンプ開始用。

Arduino MEGA pinout diagram(pdf)

　さて、こんな単純な配線なのにArduinoスケッチを書いて読み込んでみるとデータが化ける。なぜだ。

データの読み込みが不安定な時点で以前の経験を思い出すべきだった。

PROMで*PGMをオープンにしていると読めないことがある

ここでやるべきだったのはアドレスと制御線の見直し、ソフトでの初期化だった。

　解決までの顛末は以下のスレッドにある。

ほうめい　マイコンで遊んでばっかりで@houmei

とても単純なつくりなんだがTL866CSで読んだ値と微妙に異なるのはなんでだ https://t.co/xhrrgp22OA

2020/06/05 21:42:02

　さて、解決までには間違った道をどんどん進んでいっているのだが以下に整理しておく。

・ハードウェアの絞り込み

PROMの2764/マスクROMのTMM2364P/W27C512で読み込み時のデータ化けが発生する。W27C512に特定のパターンを書き込んだものを調査対象とする。

・Arduino MEGA 2560のバリエーションによるものかどうか

互換品を3つ持っていたのでそれぞれで確認。どれも同様に発生するのでArduino MEGA個別についてまわる問題ではない。1枚を選んで調査対象とする。

・類似例の調査

どこかのだれかが同じようなことをしていないか検索。あった。

Reading a Parallel ROM with an Arduino(The Oddbloke geek Blog)

これによるとほぼ同等のハードウェア構成で成功している。ブレッドボード上にPROMを載せてジャンパ線でArduino MEGAに繋いでいるので電気的にはより条件が悪いはずだが動いている。

・土台の確認

上記、The Oddbloke geek Blogのコードをこちらのボード向けにピンアサインを変更し、ダンプを5回実行して結果を比較。5回とも問題なし。

ここまででソフトウェアの違いに問題点が隠されているとわかった。前後してデータ化けの発生率が変わるようなコードの変更（主に時間的なタイミング）をいじっては観測を繰り返している。挿入するディレイによって化け方の頻度が変わるなど、ハードウェアのピンが浮いているような指摘を受けている。

・知恵を借りる

デバッグの状況は適時tweetしていた。こまめに書くことで気付くこともあるし、識者からのツッコミもある。このあたりで泥沼にハマっていたら@mkogaxさんよりコードの初期化漏れの指摘が。

PROMのA15についてArduino MEGAからの出力設定はされていても値が設定されていなかった。この状態で確認したらA15はオープンだった。修正し、ダンプを10回とって比較したら全部OK。

以下は23行目に初期化の抜けがあるコード。

https://gist.github.com/houmei/526371f9e76a9313210b80b3060fd2eb

　ということで思考の過程を整理してみました。動物が沼にはまってもがいている様子がわかると思います。突っ込んでくれた皆さんどうもありがとうございました。

　ちゃんとしたPROM読みのコードは次回。

KEYESTUDIO Mega 2560 R3 ATMEGA2560 マイコン 開発ボード + USBケーブル キット for Arduino アルディーノ アルドゥイーノ アルデュイーノ メガ 互換

keyes

SORD M5 ROMカートリッジ調査

　SORD M5のROMカートリッジについて。

　基板上にM5E-00の文字。レジストなしの両面基板。SRAM 6116(2Kx8)のパターンが2つ、ROM 2764(8Kx8)のパターンが2つ、16pinのTTL、RAMのアドレスデコード用74LS139のパターンが1つ。

右の方からRAM0、RAM1、ROM0、ROM1と呼ぶことにする。BASIC-IやゲームのROMはROM0に直接はんだ付けされている。これはBASIC-Iの写真でROMのラベルにはM5 BA4と書いてありますね。

RAM0の*OE(SRAM/ROM共通)は471(470pF)のコンデンサでGNDに接続してある。信号のタイミングを遅くして調整しているのだろうか。

BASIC-Gカートリッジ内部構成(RettoPC.net)を参考に見ていくとBASIC-Gも同じ基板。ただし16KバイトあるのでROM0/ROM1を使用し、SRAMも4Kバイト分実装している。

RAMのアドレスデコードは以下のとおり。

　カードエッジの端子は以下のとおり。ただし必要のない*IORDなどは端子ごと削除されている。

　次回はSRAMを32K、ROMを512Kからソフトを選択できるよう改造します。

PROMで*PGMをオープンにしていると読めないことがある

　ハマったのでメモ。

　パラレル接続のPROMは容量が違っても互換性があるようにピン配置にを決めてある。

　さて、この28ピンパッケージでVppやP#(*PGM)をオープンにしたままでROMの種類を変えていたらリードできないものがあった。使ったのはいずれも富士通製のUVEPROM。

　Vpp,*PGMをオープンにしたままでの結果は以下のとおり。

MBM2764　読める

MBM27C128　読めない

MBM27C256　読める

　データシートを確認してみると、リード時ではVppはVccと同じ、*PGMはVIH(=Hレベル)とあった。追加実験としてMBM27C128で*PGMを4.7KΩでプルアップしたらリードできた。

　ということでサボってハマってしまったという話でした。

富士通(FUJITSU) UV EPROM 32K 2732A-30Z MBM2732A-30Z-G

￥ 980

検証の計画ーEPROMの二度焼きは有効かどうか(実験なし)

　ツイッターを楽しんでたらPROMの二度焼きに関する話題が流れてきた。ROMに対する書き込みを確実にするために同じデータを二回書くと解釈した。これはまじないのたぐいだが上司がこれを本気にし一回だけの書き込みで大丈夫かどうか心配しだして検証を依頼された、という感じで検証の計画を考えてみる。
（なお実験は一切ありません）

☆現在の部署の設備環境でROMを書き込む時に二度焼きは必要か？
→ROMが化けると製品納入後にトラブル発生の可能性がある。
→二度焼きをすることによりデータが確実に書き込めるという主張。しかしその根拠はない。
→一回の書き込みより二回書き込んだほうが良さそうな雰囲気を感じるが、それは製造やコスト上影響があるほどのことなのか？
→落とし所は、一回の書き込みで充分ですよという客観的な内容。

　ROMの書き込みとデータ保持に関するしくみのおさらい。ROMはFETのゲート部分に電荷を溜めることによってFETのON/OFFを行い、これでデータを表現する。
Floating gate MOSFET(Wikipedia)
　ROMライタがFloating Gateを飽和されるほど充分に書き込んでいれば問題ないし実際そうなんだろうけど、それでも疑うというのであれば検証するしかない。(実は答えはここで出ている。Floating Gateに溜まっている電子の量が一回の書き込みでしきい値を越えていれば上書きしても無意味)


　検証対象、検証に必要な機材を検討する。
・ROMライター　量産で使用するもの。
・PROM。複数のメーカーより同一ロットを複数個。
・ROMサイズ分のランダムなテストパターン。
・ROM読み出しの治具。マイコンで走査する、またはROMライターのVerify機能を使う。

　データ化けがより起こりやすいパラメータの検討。
・データの読み出し速度
・データの読み出し　順かランダムか
・動作電圧　±5%、±10%
・温度

　パラメータは振りやすいものからいじっていく。例えば温度を-10℃にしたいときはチャンバーが必要になりおおげさでこれはやりにくい。動作電圧等は振りやすい。データの読み出し速度は実際の製品で使う速度に合わせておく。
　データの読み出し方向については、治具が簡単になる方向にしておく。例えばランダム読み出しをしようと思えばマイコンを採用してコードを書いたり、と治具の設計が複雑になり治具のデバッグになってしまう恐れがある。

　異常な現象を出やすくするためには、まずTypicalな設定で基準となる動作を確認し、パラメータを１つずつ現象が出やすいと思われる方向へ振る。例えば電圧＋10%で正常動作したら、＋5%ではおそらく出ないだろうという予測ができる。

　異常現象が出ないことの検証は、設定した検証項目すべてをクリアすることで確認するので時間がかかる。
・PROM 同一ロット10個に同じランダムパターンを書き込み、治具により読み出しテストを1個あたり5分×3セット
　このへんで決めた数値は大きければおおきいほどよいのだが、それでは実験が終わらないので聞かれたら次のように答えることにする。
　5分の根拠→ROMのデータ読み込みn周分なので回数的に充分
　3回の根拠→1回じゃでないかもしれないので3回もやれば充分
このへんで決めた実験回数はあとで減らすことができない。減らしたせいで出なかったじゃないかと疑われる可能性がある。


　では以上の設定で実験をやってみたという設定で話はつづく。

・A社のROM 10個について、電圧±10%、温度25℃でパス
・B社のROM 10個について、電圧±10%、温度25℃でパス
・C社のROM 10個について、電圧±10%、温度25℃でパス

　一週間でこれだけ済んで上司に報告すれば、おおよそ「まあ出ないんだろうな」という雰囲気になるのでもう一つパラメータを振って現象が出なければ終了、となりそう。ということで今度は温度を振ってみる。温度を振るためには低い方と高い方を設定して上記のテストを行うか、またはチャンバーを借りて連続的に変化させ連続読み出しを行わせる。

　温度を二点設定する方法：
10℃雰囲気について、前回のテストを行う。
40℃雰囲気について、前回のテストを行う。

　チャンバーを使う方法：
室温→50℃→室温→-10℃→室温を5日間の間で行い、最後まで正常動作することを確認。治具は検証済みのものが複数台あると望ましい。例えば動作電圧をそれぞれ変えたもの。

　チャンバーを使った温度連続変化の方が、動作時間/温度環境ともに厳しくなるのでこれをパスすればおそらくどこからも問題がないと言えるだろう。チャンバーの借用も含めおそらく二週間コースですね。

　　さて、それでもランダムな読み出しでは検証できていないじゃないかという話が出るかもしれない。そんなこともあろうかとランダム読み出しの治具は検証の間に検討を済ましておく。これを実際行うかどうかは上司の判断となる。担当者がこの実験にかかりっきりになる時間もタダではないのだ。

　検証はこういう条件でこれだけの時間行ったことについてOK/NGが言えるので、設定した条件の理由についてはすべて説明ができなければいけない。時間については検証にかかるコストとそれにみあう成果―それはひょっとしたら上司の安心感かもしれないが、周囲が納得できる長さにしなければならない。これはきりがないので充分に相談してゴールを設定する。リソースが有限な箇所は検証も有限なので、やはり最終的にはコストとの調整になる。


　ここまでは異常がないことを前提に話を進めてきた。もし異常な現象が出たのなら、デバッグに切り替わる。パラメータは異常な現象が再現する方向に倒して再現回数を上げ、次に最初のテーマであった二度焼きで改善されるのかどうか比較する。ここで正常動作の方向に倒れれば、はじめて二度焼きは効果がありそうだということが言える。そうなると、一回書き込んだROMで発生するエラーの回数と二回書き込んだROMで発生するエラーの回数で有意な差があるかどうかの検証に変わるだろう。

　二度書きでも改善しない、あるいは差がなければ部品や機材が疑わしくなる。もし部品であるROMそのものに異常が見られたら？大きいメーカーでは部品をまとめて大量に購入するため、購入する部品の評価をする部門を持っていたりするので、そこが検証を引き取ってくれる場合がある。こうなるといま設計している物とは関係がなくなってくるので、開発部門としては別の方式や部品の検討に入らなければならない。

ATMEL AT27C010-70PU ONE TIME PROGRAMMABLE (OTP) EPROM IC (1 piece) [並行輸入品] Tough Guy 売り上げランキング : Amazonで詳しく見る by G-Tools