Jeans & Development https://www.rad51.net/jeans/ コンピューターのことなどを綴ったメモ (旧:目から鱗 w/SQLite) ja Jeans CMS © Weblog http://backend.userland.com/rss https://www.rad51.net/jeans/skins/jeans/images/jeans2.gif Jeans & Development https://www.rad51.net/jeans/ ドメインを変更しました https://www.rad51.net/jeans/?itemid=983
なぜ「rad51」なのかについて、特に大きな理由はありません。私の仕事関係の単語から空いているものを探すと、こうなりました。Rad51 蛋白質は、私が研究している相同的組み換え反応において中心的な役割を果たすもので、このドメインが空いていたのは正直びっくりしました。なお、「recfor」も、仕事関連です(RecFOR 蛋白質複合体)。

新規ドメインの立ち上げに合わせて、Jeans CMS で使用しているプログラミング言語、PHPの新規バージョンへの対応も検討し、現在の所 PHP 8.3 で動くように微修正しました。興味がおありでしたら、GitHubのレポジトリー:

https://github.com/kmorimatsu/jeanscms

の、リリースではなく最新のレポジトリーを試してみて下さい。]]>
General https://www.rad51.net/jeans/?itemid=983 Mon, 06 May 2024 14:14:13 PDT ITEM983_20240506
コロナ禍において、どのような情報を信用すればよいのか https://www.rad51.net/jeans/?itemid=969
そんな中、「ワクチンはどうすればよいのか」「マスク着用にはどういった注意が必要なのか」など、個々人の判断でどうするかを決めなければいけない事柄が多々あります。本来ならば、「政府発信の情報を信用すればよい」となるのが一番良いですが、なにしろ統計改ざんまで行ってしまう日本政府ですから、平気で間違った事を言いかねません。何が正しくて何が間違っているのか、一般市民には簡単には判断できないのが現状です。

私個人は、かつて感染症研究も行った事がある生物学者なので(注:現在の専門は感染症ではありません)、経験と知識に基づいて、政府情報やその他情報の何が正しくて何がおかしいのか、かなり判断できます。しかしながら、「ここがこうだからこれはダメ、こちらは問題ない」と一言で説明できるようなものではないので、同様の判断を行うのは一般の方々にはなかなか難しい事だと思います。

そこでこの記事では、どういった事に注意すれば、少しでもより正しい情報を得られるのか、私なりの考え方をまとめてみる事にしました。

明らかに間違った情報

まず、明らかに間違っている情報について述べます。ここで述べる「間違った情報」を発信している場合、個人であれ団体であれ、その情報源を100%信用することはやめたほうが良いです。正しい事も言っているかもしれませんが、間違った事も言っていることが明らかだからです。

その「間違った情報」とは、ずばり「PCR検査をやりすぎると医療崩壊を起こす」といったたぐいの物です。こういった主張は「PCR抑制論」とも呼ばれます。PCR抑制論は主に2つの間違った根拠に基づいています。2つの間違った根拠とは、「PCR検査は擬陽性が出やすい」と「PCR検査は感度が低い」です。これらは、PCRに関してある程度の経験がある研究者・技術者なら、簡単に間違いだと気が付く事柄です。この記事ではなぜそれが間違いなのかの詳細な説明は割愛します(リクエストがあれば、別途記事にするかもしれません)が、なぜか日本では、この間違った根拠によるPCR抑制論がかなりの幅を利かせてきました。

従って、「PCR抑制論」を展開する、あるいは過去に展開していた情報源は、まず疑ってかかってください。正しい事も言っているかもしれませんが、間違いも含まれているからです。この中には、政府の新型コロナウイルス感染症対策分科会も含まれます。尾身会長はかつて、「無症状者にPCR検査しても感染は抑えられない」などと発言する、いわゆるPCR抑制論者の一人でした。その後「攻めのPCR検査」などと言って若干修正する姿勢を見せてはいるものの、かつての主張の間違いを認めて修正したとは聞いていません。分科会の他のメンバーでは、舘田一博氏が、「軽症例を全て検査していては、それこそ医療崩壊につながりかねません」と発言していた、典型的なPCR抑制論者です。彼も、その後の自身の感染に関して「今、冷静に考えると、なぜもっと早め早めに、PCR検査をやらなかったのかと思う」と言っておきながら、かつての主張の間違いを修正するそぶりは見られません。そもそも、分科会がPCR検査体制拡充の必要性をちゃんと進言していれば、日本の検査体制が先進国で最低レベルである現状は無かったはずです。

非政府の団体では、コロナ専門家有志の会がPCR検査抑制論を展開しています。今でも『本当は感染していないのに「陽性」と結果がでる(偽陽性)こともあります』と主張するページが修正されていません。コロナ専門家有志の会とそのメンバーは、間違いを主張する可能性があると思ってください。他にはこびナビがありますが、メンバーらによる議論を見ると、PCR検査による擬陽性の件で明らかに間違った議論がされていて、PCR検査抑制論者だと見てよいです。間違った事を主張する可能性があります。その他、PCR抑制論を展開する人たちは全員、「正しい事も言っているかもしれないが、間違った事も言う」と判断することをお勧めします。

個人の情報発信を100%信用することは禁物

PCR抑制論者が信用できないのなら、PCR推進論者が信用できるのでしょうか?残念ながらそんな簡単な事ではありません。一部の自治体が政府の方針に逆らって、PCR検査体制の拡充や積極的疫学調査を大々的に行っている所がありますが、そういった自治体の情報は日本政府よりは信頼性は高いものの、場合によっては間違いが含まれている可能性が排除できません。ましてや、個人の情報発信を100%信用するというのは、危険な事だと思います。

パンデミックのさなかで、世界中で情報があふれています。その中には正しい情報もあり、間違った情報もあります。学術論文でも、COVID-19関連は、査読(論文の真偽を評価する手続き)前の物が最新情報としてあふれていますし、査読を通った論文でも、内容に問題があって後に取り下げになったものが多数あります。こういった情報をちゃんと評価するのは、技術的にも難しく、かつ、骨の折れる作業なのです。一個人が、それを問題なくこなせているとは、あまり考えないほうが良いです。

WHOも、すべてが信用できる情報源ではない

どこで、そういった膨大な量の情報を吟味し、種々選択し、一般市民に情報提供しているでしょうか?先にも述べた通り、日本政府の情報発信には明らかな間違いも含まれており、それは期待できません。WHOはどうでしょうか?残念ながら、今のWHOが発信する情報にもろ手を挙げて賛成することは、私には出来ません。どういう理由か知りませんが、発信情報に偏りがみられ、その原因は政治的な事だと思っています。典型的なものとしては、2020年にパンデミックが始まった当初、WHOは "First, COVID-19 does not transmit as efficiently as influenza, from the data we have so far." (まず、COVID-19は、これまでのデータから、インフルエンザほど効率的に感染しません。)という、非常に楽観的な見通しを示していました。これは、世界的なパンデミックを引き起こした原因の一つとも言ってよいWHOの判断ミスですが、その後、この見解が明確に修正されたというニュースを私は知りません。最近の、ワクチンのブースター接種に関しても、主張の偏りがみられます。彼らが言っていることはおおむね良いのですが、時々間違っていると考えた方がよさそうです。

アメリカ CDC の情報はおおむね信用できる

アメリカ CDC (疾病対策センター) は、アメリカ連邦政府所管の、感染症対策の総合研究所です。アメリカ国内だけでなく、世界的な感染症対策においても一定の活動を行っており、感染症に関するプロの集団です(職員数、およそ1万5千人)。トランプ政権下においては、CDCはあまり信用できる機関ではなく、2020年2月にはCOVID-19に関して明らかに間違った認識を示しており、 2020年3月には使えないPCR検査キットを配布するなど、ミスが続いていました。しかし、2021年にリベラルなバイデン政権が発足してからは、見違えるようになりました。リベラルは、科学をとても重視する政治的派閥なので、それが良い方向に行っているように見えます。少し前の話になりますが、同じくリベラルなオバマ政権の頃、CDCがアフリカでのエボラ出血熱のアウトブレイクに対処した時(2014-2016)も、彼らの行動を頼もしく思っていたことを思い出します。

アメリカに居住している人ならば無料の日本語支援サービスもありますが、今この記事を読んでいる多くの方は日本に居住しているでしょうから、使えません。ただ、最近はwebの翻訳ツールが充実しており、例えばGoogleの翻訳ツールを使えば、CDCのwebページを日本語で閲覧できます。

Google翻訳経由でCDCのwebページ (https://www.cdc.gov/)の閲覧は、こちら

調べたい事柄の英語のスペルが分かっていれば、CDCの該当ページを検索することができます。例えば、オミクロン株とワクチンに関して知りたければ、「site:cdc.gov omicron vaccine」で検索すれば、次のページがヒットします。

Omicron Variant: What You Need to Know
Google翻訳なら、こちら:オミクロンバリアント:知っておくべきこと

こういった方法で、CDCが何を言っているのか調べて、参考にすればよいと思います。誰かの情報が、CDCの情報発信と合致していれば「なるほど、そうなのか」と解釈し、相対していれば「ん、なんか怪しいかも」といった具合です。

コロラド氏について

"Hiroshi Makita"と言う人がCOVID-19に関して情報発信しており、「コロラド先生」の名で通っていることは知っていたのですが、特にこの人の発言を追いかけているわけではありませんでした。ところがある日、彼のあるTWが目に留まっておかしいだろうと思い、それにコメントしたことでちょっとしたやり取りになりました。

2022-03-24-twitter.png

そのやり取りの後の私の結論は、

2022-03-24-twitter2.png

と書いた通りで、話をしても意味のない人という評価です。しかしながら、「ちゃんと反論するべき」「反論がみんなのためでもある」というコメントをいただきましたので、ちょっとここでいくらか述べてみる事にします。

まず、問題点を整理します。そもそものMakita氏の主張はこうです。

 ・オミクロン株ではワクチンによる感染回避効果はない

これに対して、私はこう述べました。

 ・従来株に比べて感染回避効果が低いだけで、無いわけではない

それに対するMakita氏の返答はこうです

 ・ごく短期間、50%程度の有効性があるともされるが、わずか数週間
 ・その後は抗体依存性感染増強が疑われており、感染回避はできないと評価

これに対して私が、

 ・抗体依存性増強のリスクをはっきりと示した例は無いはず
 ・CDCはワクチンを打った場合のメリットがリスクを上回ると評価

と返したところ、いきなり長々と元々の問題提起とは異なる件に関してずらりとTWを述べた挙句、池乃めだかよろしく「今日はこのぐらいにしといたろ」的な「お引き取り下さい」で締めたわけです。加えて、「あなたは論文を読めない」という烙印を押してきました。私がこの人に「話をしても意味のない人という評価」を下したのは、先に書いた通りです。

ここでは、そもそもの彼の主張「オミクロン株ではワクチンによる感染回避効果はない」に主に的を絞って、議論してみます。彼の一連のTWを読んでみると、「感染回避効果はない」と結論付ける根拠は、次の通りです。

 ・短期間、50%程度の有効性があるともされるが、わずか数週間
 ・その後は抗体依存性感染増強が疑われている
 ・50%以下の有効性は実用ワクチンではない

一つ一つ、見ていきましょう。せっかくMakita氏がイギリスの報告書を参考文献として引いてきたので、その報告書をもとに見る事にします。図1bです。

2022-03-24-uk1.png

日本でも主流の、ファイザー・ビオンテック社のワクチンを、1回目・2回目に接種した人のデーターです。四角がデルタ株に対する発症予防効果、丸がオミクロン株に対する発症予防効果で、横軸は2回目接種からの経過週数です。なお、この報告書でも記述がありますが、感染予防効果を評価する場合、発症予防効果を見るのが普通です。デルタ株に対しては25週を過ぎても60%の発症予防効果があるのに対し、オミクロン株に対しては15週目までに20%弱まで下がりますが、ゼロにはなっていません。私が「従来株に比べて感染回避効果が低いだけで、無いわけではない」と言った通りです。ただし、Makita氏が言った「50%程度の効果が数週間」も正しいことが分かります。

次に、ブースターを接種した場合の効果を見てみましょう。

2022-03-24-uk2.png

同じく図1bですが、"BNT1632b2 booster"の項目を見てください。ファイザーのブースターを接種後の、デルタ株およびオミクロン株への発症予防効果のグラフです。2回目接種後と同じく、5-9週で50%ぐらいまで落ちているのが分かります。ただし、15週を超えるデーターを見ると、40%の予防効果を残しており、2回接種後に比べて長持ちしていそうです。

さらに、2回目まではファイザー、3回目にモデルナのワクチンを接種した場合のデーターを見てみましょう。

2022-03-24-uk3.png

一番右側、"mRNA-1273 booster"のデーターがそれです。14週目まで、60%以上の発症予防効果を維持していることが分かります。

Makita氏の主張「50%程度の有効性があるともされるが、わずか数週間」では、数週間たてば効果はほぼゼロになるというニュアンスですが、実際のデーターを見ればそうではない事が分かると思います。私が「従来株に比べて感染回避効果が低いだけで、無いわけではない」と最初に述べたのはこういった事で、これを「感染回避効果はない」と表現するのは、「聞き捨てならない」としたのです。

次に「抗体依存性感染増強」についてです。英語で ADE (antibody-dependent enhancement)と言いますが、これはデング熱などで見られます。しかしながら、COVID-19で大規模なADEが見られたという報告を私は知りません。臨床試験でも通常使用でも報告が無い以上、ADEは起こらないか、起こったとしても非常に低い頻度だと思われます。Makita氏は「疑われており」と表現しているので、どこかの論文でその可能性を指摘した類の事なのでしょう。論文の"discussion"のセクションなどでは、そういう議論が「可能性の一つとして」なされることもあります。いずれにせよ、私の「COVID-19のワクチンで抗体依存性増強のリスクをはっきりと示した例は無いはず」との指摘に対してMakita氏は何も答えなかったので、彼が何をもって「疑われており」としたのかはっきりせず、そういったはっきりしない事を根拠に「感染回避はできないと評価するほかない」と断ずるのは、科学的ではありません。

最後に、「50%以下の有効性は実用ワクチンではない」についてです。これについては、二つ議論があります。まず第一に、たとえ発症予防効果が非常に低いとしても、重症予防・死亡予防の効果があれば、それは十分実用ワクチンだという事、第二は50%以下の感染予防効果には実用性はないのかという事です。

まず、第一の議論から。同じく、イギリスの報告書で、入院予防効果についてみてみましょう。

2022-03-24-uk4.png

一番左が、ファイザーのワクチン接種後の、入院予防効果の時間経過です。20-24週目までオミクロン株の感染に関する入院予防効果が50%を超えた状態が続くことが分かります。真ん中のグラフがファイザーのブースターを、右がモデルナのブースターを接種後です。いずれも、80-90%の高い予防効果が得られることが分かります。グラフを見る限り、数週間で効果がなくなってしまうという事ではなさそうです。

二つ目の議論は、50%を切る感染予防効果が実用的なのか実用的ではないのかという事です。仮に、感染予防効果が33%と仮定して考えてみます。個人のレベルで見れば、3回感染の機会があった場合に、2回は感染で1回だけ感染回避という計算です。確かに、この数字だけ見れば効果はかなり低いように見えます。しかし、家族全体で見ればどうでしょうか。本人が直接外で感染して帰ってくるケースでは、同じように感染は3回に2回です。しかし、感染は家族内でも起こります。この場合、最初の一人が感染する確率は3分の2ですが、この最初の一人を通じて二人目にも感染する確率は同じく3分の2です。なので、自分は直接感染していないけれど、家族を通じて感染する可能性は、3分の2の二乗でおよそ0.44になります。実際には、ワクチンの重症化予防効果が高ければ放出するウィルス量も少ない可能性があるので、家族間の感染は3分の2より低いかもしれません。このように、家族が全員ワクチンを打っていれば、たとえ50%を切る感染予防効果であっても、家族全体では一定の感染予防効果を期待できます。

以上より、「50%以下の有効性は実用ワクチンではない」は非科学的な解釈です。

その他のコロラド氏の発言について

その他のMakita氏の発言について見てみます。

2022-03-24-colorado1.png

ここで「あなたは論文が読めない」と烙印を押してきた理由は不明です。最初の方で述べた通り、数多あるCOVID-19関連の論文をすべてチェックするのは一個人には不可能で、その意味では私もすべての論文に目を通しているわけではありません。時々、気が向いたときにCOVID-19関連の論文を読んでみる程度です。だからと言って、私が「論文を読めない」とされるのは、心外です。先にも述べた通り、発表される論文は玉石混交で、ある論文にどれぐらいの意味があるかを見極める目が必要であり、そのためには自分自身が何報か論文を書く必要があると思っています。ではこの"Hiroshi Makita"と言う人が、どれぐらい論文を書いた経験があるのかと思ってPubMedで検索してみました。「Hiroshi Makita」と言う検索語で調べると一報だけ出ましたが、100人ほどの著者の一人で、どう見ても論文の全体像を構築した著者ではありませんでした。医学・生物系以外の論文だとPubMedでは検索にかかってきませんが、分野が違うと、生物系の論文をちゃんと読めるのかどうかは疑問が残ります。或いは、"Hiroshi Makita"はペンネームで本名ではないのかもしれませんが、そうであれば何とも言えません。なお、PubMedで私のフルネームで検索すると、主だった論文はすべて表示されました。ただし、20年以上前の古い論文は表示されなかったので、彼の論文は20年以上前の物のみの可能性もありますが。

2022-03-24-colorado2.png

オミクロン株に関しては、日本でもかなりの感染者数です。2022年3月現在で人口当たりの一日の感染者数はアメリカを超えており、国ごとに異なると言っても、今の日本ではアメリカと同じような状況だと考えるべきです。加えて、日本では検査数が圧倒的に不足しているので、発表される陽性者数よりも多くの感染者がいるとみるべきで、そのことはMakita氏もわかっている筈です。CDCの見解を参考にしない理由にはなりません。

2022-03-24-colorado3.png

チェリーピッキングと言うのは、Makita氏も言っている通り、自分の都合の良いようにデーターをつまみ食いする事なのですが、彼のやっている

 ・10週以上にわたって50%以上の効果が続く条件があるのに、数週間で50%以下と断言してみたり
 ・実際には報告が無いADEについて、疑ってみることで、ADEがあたかも現実に存在するかのような論理展開をしてみたり
 ・50%以下であろうともある一定の効果があるものを効果が無い(つまりゼロだ)と言ってみたり

するような事が、まさにチェリーピッキングです。私は、このTwitterでの議論の中で具体的な論文なりデーターなりを出さなかったので、私の今回のTwitterでの言動はチェリーピッキングには当たりません。なぜMakita氏が私との話の中でチェリーピッキングを持ち出してきたのかは不明です。もしかしたら、「自分もチェリーピッキングをしてしまわないか」という心配が、心のどこかにあるのかもしれません。

最後に

ここまで、COVID-19に関して、どういった情報を信用すればよいのかを述べてきました。私の結論は、

 ・日本政府の見解や個人の情報発信はすべて参考程度にとどめる
 ・大事なことに関しては、CDCがどう言っているかで確認する

です。政府見解や個人の情報発信がすべて間違っていると言っているわけではない事に注意してください。それらの情報の多くが正しくても間違いが含まれている可能性があって、それを確認するのが、CDCの情報発信です。アメリカの政権が代われば今後どうなるかはわかりませんが、少なくともバイデン政権が続く限りは大丈夫そうです。]]>
General https://www.rad51.net/jeans/?itemid=969 Thu, 24 Mar 2022 20:13:23 PDT ITEM969_20220324
COVID-19データーを自動解析してグラフにする https://www.rad51.net/jeans/?itemid=967 NHKの特設サイト・新型コロナウイルスは、全国や都道府県別のグラフがあり、生データーもcsvファイルで提供されているので、便利です。

ただ、生データーは、週前半の値が週後半の値に比べて少なくなるなど、そのままでは感染状況などを把握しづらいです。Excel等の表計算ソフトを利用するなど、ある程度の計算を行うと、生データーよりも見やすいデーターのグラフが書けたり、実効再生産数を計算できたりします。私もExcelを用いてデーター解析を行っていたのですが、日々公表される最新のデーターは手作業で打ち込みせざるを得ず、手間がかかっていました。

そこで、そういった計算を自動で行うwebサイトを構築することにしました。ブラウザーでアクセスするだけで、生データーを計算して、さまざまなグラフを表示することが出来ます。次のURLにアクセスしてください。
https://www.rad51.net/projects/covid19/covid19.html

下の図は、表示されるグラフの一例です。
2021-02-23-positives.png

このグラフはいろいろな所で使われる陽性者数の推移のグラフで、おなじみだと思います。最近は、振れが激しい生データーだけでなく、7日間平均の値も同時に出すものが増えてきました。ですので、ここではあまり説明はしません。

次のグラフは、最初のグラフと同じですが、縦軸を対数表示にしたものです。
2021-02-23-log.png
通常表記のグラフでは、感染が指数関数的に拡大している時や、逆に指数関数的に収縮している場合などは、プロットが曲線になり、良くわかりません。そういった場合、対数グラフを見ると、指数関数的な変化を起こしているときは直線的に値が変化するので、分かりやすいです。

3番目のグラフは、実効再生産数を表示します。
2021-02-23-ern.png
実効再生産数は、一人の感染者が、次に何人の人に感染させているかの値です。COVID-19の場合は、5日間で何倍に増えるかで計算されることが多いようです。この値が1なら感染者数は横ばい、2なら5日間で2倍に(1か月でおよそ64倍)、0.5なら5日間で半分に(1か月でおよそ1/64)なります。ここでは、7日間平均の陽性者数のデーターを用い、5日前の値と比べることで、計算しています。速報値は、平均値は使わず7日前の値との比較を5/7乗することで計算しています。

最後のグラフは、死者数を表示します。
2021-02-23-death.png
死者数のデーターは、感染者数のデーターよりおよそひと月程遅れて出ますので、将来の感染者数がどのように推移するかの予測にはあまり役立ちません。ただし、過去に公表された陽性者数が本当に感染者数を反映しているのかを検証するのには、非常に役に立ちます。例えば、ある月に陽性者数が減少しているにもかかわらず次の月に死者数が同じように減っていなければ、その「ある月」の陽性者数のデーターを疑ってみる必要があります。つまり、検査の取りこぼしがあって、検査せずに陽性者とみなされていない感染者が多数いたかもしれません。また、日本ではCOVID-19の死亡率がおよそ1.6%ですから、それよりも高い死亡率が出た場合なども、検査せずに陽性者とみなされていない感染者が多数いたことを示唆するデーターです。

ページの一番下には、表示範囲を調整するためのスライダー、CSVファイルをダウンロードするためのボタン、都道府県別のデーターを表示するためのリンクがあります。
2021-02-23-tools.pngスライダーは、右に動かせば直近の日付だけを表示、左に動かせば全体表示です。「Save CSV file」ボタンを押せば、CSVファイルをダウンロードできるので、別途、表計算ソフトで解析できます。また、都道府県名をクリックすれば、全国レベルでなく、都道府県別のグラフを表示します。

Webアプリケーションの技術的なことに関して

グラフを表示するこのページは、HTML5とサーバーサイドスクリプトを用いた、Webアプリケーションとして作成しました。グラフの表示は、それ用のCartd.jsというライブラリーを用いて、簡易に実装しています(すごく便利です!)。サーバーサイドでは、PHPを用いてNHKのページからCSVファイルを取り込んで、それをJavascriptに変換しています。ソースコードを公開してGitHubに置きましたので、興味のある方は見てみて下さい。ごく簡単なプログラムで、ソースコードはコメントを含めても400行未満です。

一応、セキュリティーチェックもしてあります。入力はCSVファイルと、都道府県番号の二つです。前者はNHKのサイトから来ますが、NHKの該当ページが万一ハッキングされた場合の事を考えて、対処しています。後者に関しては、入力値を整数値に変換することで、対処することが出来ます。いずれにせよ、仮に脆弱性があったとしてもXSSで、サーバーサイドでの任意コード実行や、サーバーの情報漏洩など(例えば、ディレクトリートラバーサルとか)の最悪レベルのセキュリティーホールは、起こりえないと思います。]]>
General https://www.rad51.net/jeans/?itemid=967 Tue, 23 Feb 2021 15:27:29 PST ITEM967_20210223
MachiKania webの紹介 https://www.rad51.net/jeans/?itemid=965

MachiKania webは、MachiKania type M相当の物を、webアプリケーションとして実装したものです。以下のリンク先で、実行できます。

USキーボード通常画面
USキーボード大画面
JPキーボード通常画面
JPキーボード大画面

MachiKaniaはMicrochip製の32ビットのマイコンを利用した小サイズのマイクロコンピューターで、ケンケンさんと私Katsumiの共同開発です。type Ntype Ztype Mと三種類あります。NTSCのビデオモニターに、カラーの文字やグラフィックスを表示することが可能です。また、オブジェクト指向プログラミングが出来るBASICコンパイラーを搭載しており、類縁のマイコンと比較して、非常に高速にプログラムを実行することができます。

ここでは、MachiKaniaのシリーズの中から、現時点で最も高機能なtype Mとほぼ同様の動作を行うものをwebアプリケーションとして実装したものを、紹介したいと思います。記事最初の方にリンクがありますので、実行する際はそちらをクリックしてください。

32ビットのRISCのCPUであるMIPS32を、JavaScriptでエミュレートしています。MachiKaniaはMIPS32用のコードを作成するコンパイラー言語ですが、このMIPS32エミュレーターにより、このコンパイラーの作成するコードをそのまま実行できるようになっています。

基本的には、MachiKania type Mと使い方はほぼ同じです。ただし、以下の点でtype Mと異なります。

 1.実行速度が、type M のおよそ 1/20。
 2.I/O が使えない。
 3.80 文字幅表示でのフォントサイズが、6x8 ドット。
 4.MMC カードの代わりに、ZIP アーカイブを用いる。

BASIC プログラムを入力した後、「 F4 」キーを押せば、実行することができます。「 F1 」キーや「 F2 」キーで、プログラムをロードしたりセーブしたりすることができます。

MMC カードの代替になる ZIP アーカイブのやり取りは、「 Load Disk Image 」と「 Save Disk Image 」の二つのボタンで行います。MachiKania 上で SAVE したファイルを取り出したい場合は「 Save Disk Image 」を、PC 側で用意したファイルを MachiKania で使いたい場合は、「 Load Disk Image 」を押してください。

「 KanaLock 」ボタンは、JP-キーボードで使用する際、カナ文字を入力するときに押してください。

「 Break 」ボタンは、プログラムの実行を停止する場合に押してください。

「 Links 」を押せば、MachiKania のユーザーマニュアルの閲覧などの、さまざまなリンクが表示されます。

ソースコードはGitHubに上げています。ほとんどのファイルのライセンスはLGPLですが、一部LGPLライセンスでないもの(MachiKania ライセンスなど)が含まれているので、ご注意ください。]]>
プログラミング https://www.rad51.net/jeans/?itemid=965 Sat, 22 Aug 2020 16:57:20 PDT ITEM965_20200822
Cygwinを使ったFuzix v0.3のビルド https://www.rad51.net/jeans/?itemid=963
gcc-core
gcc-g++
make
patch
bison
flex
libboost-devel
git
zlib
zlib-devel

SDCC-3.9.0のビルドとインストール
Fuzix ver 0.3のビルドは、SDCC-3.6.0やそれ以前のものではうまく行かない。2019年現在の最新版の3.9.0を使う必要があった。ただし、以前も書いたように、デフォルトのSDCCではKernelのビルドができないので、パッチを当てなければならない。用意されているパッチは3.5.0用のものなので、3.5.0と3.9.0のソースコードを比較して、パッチを作り直した。パッチファイルのZIPアーカイブ「sdcc-3.9.0.patch.zip」はここからダウンロードできる

SDCC-3.9.0のソースコードを、ここからダウンロードし、展開する。先の通りダウンロードしたパッチファイルも解凍して「sdcc-3.9.0.patch」を同じディレクトリに置いて、適応する。三回ファイル名を聞かれるので、「sdcc-3.9.0/src/z80/gen.c」「sdcc-3.9.0/src/z80/main.c」「sdcc-3.9.0/src/z80/z80.h」を入力する。
tar xjvf sdcc-src-3.9.0.tar.bz2
patch<sdcc-3.9.0.patch

configureし、ビルドする。無事に終われば、インストールする。
cd sdcc-3.9.0
./configure --prefix=/usr --disable-pic14-port --disable-pic16-port --disable-mcs51-port --disable-r2k-port --disable-r3ka-port --disable-tlcs90-port--disable-ds390-port --disable-ds400-port --disable-hc08-port --disable-s08-port --disable-stm8-port --disable-ucsim
make
make install

Fuzix v0.3のビルド
Fuzixソースコードを取得し、ver 0.3のものに巻き戻す。Makefileを編集する。
「TARGET=z80pack」のところ、
「TARGET=tomssbc-rom」とする。
git clone https://github.com/EtchedPixels/FUZIX.git
cd FUZIX
git checkout cacbe5238588d352768ab95951c46d09879ba310
(Makefileを編集)

私の環境では、このままmakeすると、「find.c」のビルドでエラーが出て停止した。よく分からないので、このファイルのビルドをスキップする事にした。「Applications/MWC/cmd/Makefile.z80」の8行目で、「find.c」を削除し、次のように書き換えた。
SRCS  = ac.c almanac.c at.c col.c cron.c deroff.c du.c ed.c make.c \
	moo.c pr.c tar.c ttt.c units.c

全て準備が整ったので、いよいよビルドする。
make

ただし、アプリケーションはビルドできる事を確認するだけでオブジェクトは使わないので、アプリケーションのビルドが始まったらキャンセルし、「make kernel」としてカーネルのビルドを最後に行なうか、Makefileの72行目を「all: stand ltools libs kernel」として(appsを削除)、アプリケーションのビルドをスキップしても良いかも知れない。その場合は、上記の「Makefile.z80」の編集は必要ない。

Hello Worldプログラムをビルドしてみる
以上のプロセスが無事終了すれば、Fuzix ver 0.3用のアプリケーションを作製する環境が整った事になる。Hello Worldプログラムを作製してみた。

hello.c
#include <stdio.h>

int main(/*int argc, char* argv[]*/) {
  printf("Hello World!\n");
  return 0;
}

Makefile
all: hello.c
	/opt/fcc/bin/fcc -O2 -mz80 -c hello.c
	/opt/fcc/bin/fcc -O2 -mz80 hello.rel -o hello
clean:
	rm *.rel
	rm *.map

「make」すれば「hello」というファイルができるので、UCPによりディスクイメージに取り込めば、実行できる。
2019-11-09-hello.png
これで、Fuzixのカーネルを改変したりアプリケーションを開発したりする環境が、全て整った事になる。]]>
Fuzix https://www.rad51.net/jeans/?itemid=963 Sat, 09 Nov 2019 19:10:12 PST ITEM963_20191109
Cygwinを使ったFuzixのビルド https://www.rad51.net/jeans/?itemid=962
gcc-core
gcc-g++
make
patch
bison
flex
libboost-devel
git
gitやSDCCもcygwin上でインストールしないとうまく行かない。gitに付いてはcygwin用のバイナリーが使えるが、SDCCに付いてはビルドが必要である。

SDCCのビルド
SDCC ver 3.6.0 のソースコードをここからダウンロードして、展開し、configureする。
tar xjvf sdcc-src-3.6.0.tar.bz2
cd sdcc-3.6.0
./configure --prefix=/usr --disable-pic14-port --disable-pic16-port --disable-mcs51-port --disable-r2k-port --disable-r3ka-port --disable-tlcs90-port--disable-ds390-port --disable-ds400-port --disable-hc08-port --disable-s08-port --disable-stm8-port --disable-ucsim

このままmakeすると「info-recursive」が見つからないというエラーで停止するので、「support/sdbinutils/bfd/Makefile」を次のように修正する。
151行目「info-recursive 」を削除
RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
	html-recursive install-data-recursive \
	install-dvi-recursive install-exec-recursive \
	install-html-recursive install-info-recursive \
	install-pdf-recursive install-ps-recursive install-recursive \
	installcheck-recursive installdirs-recursive pdf-recursive \
	ps-recursive uninstall-recursive

1832行目「info-recursive 」を削除
info:

ビルドし、インストールする。
make
make install

z80packのインストール
先の記事と同じように行える。ただし、「Makefile.linux」ではなく「Makefile.cygwin」を使う。
tar xzvf z80pack-1.24.tgz
cd z80pack-1.24/cpmsim/srcsim
make -f Makefile.cygwin
cd ../srctools
make

Fuzixのビルドと実行
後は、先の記事と同じように行える。ただし、Cygwinでは、「sudo」は必要ない。
2019-11-07-z80pack.png

当面、Fuzix用のアプリケーションの開発はこの環境で行なおうと思っている。

(追記)
この条件でz80pack上でFuzixを実行すると表示が乱れる。ただ、この不具合はCygwin用のz80packの方にあるようだ。CygwinでビルドしたFuzixをLinux上のz80packで実行すると、正常動作する。

なお、Cygwin上でsdcc-3.6.0でビルドした場合と、Ubuntu上ででsdcc-3.6.0でビルドした場合とで、両方とも動作するものの、作製されるオブジェクトが異なる。同じバージョンのコンパイラーを使っていても、何かが微妙に違うらしい。その事が影響するのか、Cygwin上でパッチを当てたsdcc-3.5.0を使ってTom's SBC用のカーネルをビルドしても、動作しなかった。]]>
Fuzix https://www.rad51.net/jeans/?itemid=962 Thu, 07 Nov 2019 16:44:33 PST ITEM962_20191107
FUZIX Kernelのビルドに挑戦 https://www.rad51.net/jeans/?itemid=961 一つ前の記事では、先人の教えにしたがって、Fuzix ver 0.1のビルドを行なった。現在使用しているFuzixは、ver 0.3で、Tom's SBC 用に構築された物である。これのビルドもできるようにしておきたい。色々試したのち、ようやくビルドできるようになったので、メモ。

Fuzix用SDCCのビルド
ここが一番のミソなのだが、Z80用Fuzixのビルドには、SDCCを少し修正して使っているらしい。ソースコード中、次のように書かれている。
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/patches
SDCC:

	This patch adds 

	1. Helpers to cut down the size of C code for function entry. Right
	   now the __enter and __enter_s must be in common memory.

	2. An option --external-banker that keeps 4 byte stack offsets for
	   arguments so the linker can patch up banked binaries. Unbanked
	   code is called via push af call foo pop af
このパッチを当てて、オプション「--external-banker」を有効にしないと、Tom's SBC用のKernelがちゃんとビルドできない。なので、まずパッチを当てたSDCCのビルドから始める。

SDCCのビルドに必要なツールをまずインストール。
sudo apt install bison
sudo apt install flex
sudo apt install libboost-dev

SDCC ver 3.5.0 のソースコードをここからダウンロードして、展開する。パッチファイル(SDCC)をここの「Raw」ボタンから取ってきて、同じディレクトリーに置き、パッチを当てる。複数回ファイル名を聞かれるので、「sdcc-3.5.0/src/SDCCglue.c」「sdcc-3.5.0/src/z80/gen.c」「sdcc-3.5.0/src/z80/main.c」「sdcc-3.5.0/src/z80/z80.h」と入力する。
tar xjvf sdcc-src-3.5.0.tar.bz2
patch<SDCC

SDCCのビルドとインストールを行なう。なお、別のSDCCを予めインストールしてあった場合は、そちらは削除しておく事。
cd sdcc-3.5.0
./configure --prefix=/usr --disable-pic14-port --disable-pic16-port
make
sudo make install

Kernelのビルド
Fuzixソースコードを取得し、Kernelをビルドする。Makefileはビルド前に編集する。
「TARGET=z80pack」のところ、
「TARGET=tomssbc-rom」とする。
git clone https://github.com/EtchedPixels/FUZIX.git
cd FUZIX
(Makefileを編集)
sudo make kernel

このビルドは、Fuzix ver 0.3においての物なので、それより後のバージョンではうまく行かないかも知れない。その場合は、
git checkout 9d5f38b410a11c31aa9967fa88831d2db76bccaf
として、2019年11月現在のレポジトリーか、
git checkout cacbe5238588d352768ab95951c46d09879ba310
として、ver 0.3のレポジトリーに巻き戻してから、make kernel すればよいだろう。

うまく行けば、pratform-tomssbc-romディレクトリに、「fuzix.com」という、64Kbのファイルが構築される。]]>
Fuzix https://www.rad51.net/jeans/?itemid=961 Sun, 03 Nov 2019 23:28:26 PST ITEM961_20191103
FUZIXのビルドに挑戦 https://www.rad51.net/jeans/?itemid=959 FUZIXをビルドしてみようというwebページで、FUZIXのカーネル・ツール・ディスクイメージのビルドの方法が紹介されており、参考にしてみたので、メモ。

この記事は「2017年4月現在のビルド方法」との事なので、最新のFUZIXソースコードのビルドには適応できない。少し修正をする必要があった。大まかに、以下の順で作業を進めた。

SDCCのインストール
SDCCはビルド済みの物をインストール。32 bit Linux用のものをダウンロード。
>tar xjvf sdcc-3.6.0-i386-unknown-linux2.5.tar.bz2
>cd sdcc-3.6.0
>sudo cp -r * /usr

z80packのインストール
変更無し。
>wget http://www.autometer.de/unix4fun/z80pack/ftp/z80pack-1.24.tgz
>tar xzvf z80pack-1.24.tgz
>cd z80pack-1.24/cpmsim/srcsim
>make -f Makefile.linux
>cd ../srctools
>make

外部ユーティリティのコンパイル
2017年4月現在のFUZIXでビルドする必要があるので、Git cloneを当時の物に巻き戻す必要がある。
>git clone https://github.com/EtchedPixels/FUZIX.git
>cd FUZIX
>git checkout 475c397296e87406420c0ccd54c21fa2e3dd5003
>cd Standalone
>make

カーネルのコンパイル
変更無し。Makefileとdevtty.cは、指示の通り編集。
>cd ../Kernel
>(Makefileとdevtty.cを編集)
>make

クロス開発用ツールのコンパイル
変更無し。
>cd ../Library
>make
>sudo make install

ライブラリのコンパイル
変更無し。Makefileは、指示の通り編集。実行に時間が掛かる。
>cd libs
>(Makefileを編集)
>make
>sudo make install

内部ユーティリティーのコンパイル
変更無し。実行に時間が掛かる。
>cd ../Applications/util
>make

ディスクイメージの作成
変更無し。指示の通りcreatedrivesを編集。
>cd ../../Kernel/platform-z80pack
>(createdrivesを編集)
>./createdrives

FUZIXをz80packで動かす
変更無し。
>cp drivea.cpm drivei.cpm ~/z80pack-1.24/cpmsim/disks
>cd ~/z80pack-1.24/cpmsim
>./cpmsim

2019-11-01-fuzix.png

(以下、追記)
Tom's SBC用FUZIXのビルド
残念ながら、まだTom's SBC用のFuzix(FZ/KM midi, FZ/KM webで使っている物)のビルドには成功していない。ただし、上記の方法で得られたFuzixアプリケーションは、Tom's SBC用のFuzixで走る。なので、上記の操作でとりあえずFuzixアプリケーションをビルドする環境は整った事になる。
(追記)
Tom's SBC用のKernelのビルドに成功したので、次の記事を参照。]]>
Fuzix https://www.rad51.net/jeans/?itemid=959 Thu, 31 Oct 2019 18:09:11 PDT ITEM959_20191031
Fuzix ディスクイメージ編集ツール、UCPの使い方 https://www.rad51.net/jeans/?itemid=957 http://www.fuzix.org/)で配布されていて、そのまま使う事ができます。FZ-KM webやFZ-KM midiでも、ここから取得される「tomssbc-0.3.ide」を使っています。

これらのディスクイメージファイルを用いてFuzixを起動すれば、Fuzix内部でファイルのやりとりをする事ができますが、このままではFuzix外部とのファイルのやりとりができません。例えば、Z80用のアプリケーションは、CソースコードをSDCCを用いてコンパイルして作製しますが、この様にして作られたアプリケーションをディスクイメージファイルの中に取り込む事ができなければ、Fuzixで利用できません。

Fuzixでは、その為のツールとして、UCPを用意しています。ここでは、UCPのWindowsにおける使い方について見てみます。

Fuzix用のUCPは、GitHubのレポジトリーにソースコードがあります。Cygwin等でコンパイルすれば「ucp.exe」が得られますので、それを利用する事ができます。手っ取り早く使いたい人は、予めコンパイルした物を用意しましたので、それを使って下さい。

このucp.exeを用いると、本家サイトから得られる「Filesystem Images」を編集する事ができます。しかし、「Bootable Images」(FZ-KMで利用している、Tom's SBC用のtomssbc-0.3.ideもこちら)を編集するには、少し工夫が必要です。

Tom's SBCは、RC2014ファミリーのPCです。GitHubレポジトリーのRC2014用のKernelのディレクトリーには、次の様な記述があります。

As ucp and fsck.fuzix support offsets in the format path:offset you can access the first file system with ucp foo.cf:1049600 if it starts at block 2048 of the CF card as normal.

ですので、このディスクイメージファイルをucp.exeで編集する際は、「ucp tomssbc-0.3.ide:1049600」と入力して下さい。次のような画面になり、編集が可能になるはずです。
2019-10-28-ucp1.png
(画像は、クリックすれば拡大表示されます)
このオフセット値は、プラットフォームごとに違うようで、例えばMTX用の物は「1048576」なのですが、これに関する記述は見つけられませんでした。「1048576」という値は、Tom's SBC用のイメージとMTX用のイメージのファイルサイズの差から計算された値です。1048576 = 0x100000 なので、むしろこちらの方が普通で、IDE用の「1049600」が特殊なのかも知れません。

無事にUCPが起動できれば、Linuxコンソールと同様に扱う事ができます。「?」とタイプすれば、利用可能な命令の一覧が表示されます。
2019-10-28-ucp2.png
これらの命令の中では、「get」と「put」が特殊な物で、この機能のためにucpが用意されています。「get」は、Fuzixディスクイメージに新規ファイルを取り込む機能、「put」はディスクイメージからファイルを取り出す機能です。

下の例では、「/usr/games」ディレクトリーの一覧を表示後、「put」で「startrek」というファイルを取り出し、「get」で取り出したファイルを「startreka」という名で取り込みました。
2019-10-28-ucp5.png

このままではファイルモードが「666」なので、実行型ファイルの場合は「chmod」を使って「755」に変更します。
2019-10-28-ucp7.png
2019-10-28-ucp8.png

この様にすれば、Fuzixを起動した後に、「/usr/games/startreka」が実行できるようになります。この例では既にあるアプリケーションをコピーしただけですが、「get」を用いて自分で作製したアプリケーションをFuzixに取り込む事ができますし、Fuzix実行後に作製されたファイルを「put」を用いて取り出す事もできます。

さぁ、これでFuzix用のアプリケーションを開発して、Fuzix上で実行する環境が整いました。何を作ろうかな?]]>
Fuzix https://www.rad51.net/jeans/?itemid=957 Mon, 28 Oct 2019 13:40:04 PDT ITEM957_20191028
FZ/KM web の紹介:Fuzixをwebアプリケーションで実行 https://www.rad51.net/jeans/?itemid=955
FZ/KM webは、HTML5による、Fuzixの実行環境です。実行すると、以下のような画面になります。
2019-10-11-fuzix3.png

始めに

Fuzixに関する解説は、2019年10月現在、日本語ではほとんど見あたりません。srad.jpに『著名Linux開発者Alan Cox、Z80向けに新OS「Fuzix」を公開』とある他は、「FUZIXをビルドしてみよう」という記事が見つけられるぐらいです。

Fuzixは、Alan Cox氏により開発が進められている、Z80など小規模のCPUを搭載したコンピューターで使用する事を前提にした、UnixライクなOSです。2019年現在、最新の情報を得るには、GitHubのレポジトリーを見るのが一番良いようです。2019年10月現在、ver 0.3が公開されており、作者曰く「 It is not yet useful although you can build and boot it and run test application code. A lot of work is needed on the utilities and libraries.」という事なので、まだまだ未完成で改善を続けていくという事のようです。作者はこちらのサイトでも情報発信を行なっていて、最新の情報が得られます。

作者が「FUZIX is a fusion of various elements from the assorted UZI forks and branches...」と述べているように、元々はDoug Braun氏のUZI (Unix: Z80 Implementation)から派生しているようで、たぶん Fuzix のネーミングもそこから来ています。対応するCPUはZ80だけでなく、6502, 6809, 8086, 68000など多岐にわたり、今後の開発が楽しみなOSです。

ここでは、CPUとしてZ80を使い比較的簡単な回路を持つPCの中から、RC2014のファミリーに属するTom's SBCを取り上げて、HTML5に依るwebアプリケーションとしてのエミュレーションを試みました。Fuzixの本家ページでは、Tom's SBC用のKernelのバイナリーがROMのイメージとして公開されており、扱いやすいです。Tom's SBCではコンパクトフラッシュカードをハードディスクの代りに用いていますが、webアプリケーション内では単一のディスクイメージを読み書きするようにしました。

使い方

次のURLにアクセスする事で、実行する事ができます。
https://kmorimatsu.github.io/fuzix/fuzix.html

FZ/KM webは、HTML5による、Fuzixの実行環境です。

HTML5の機能のうち使用しているものは、以下の通りです。


 ・Canvas
 ・FileReader

fuzix.htmlにブラウザでアクセスすると、以下のように表示されます。

2019-10-11-fuzix1.png

黒い画面が、80文字×24行の、ディスプレイです。 その下に、CPUの動作速度を示しています。デフォルト設定では、2 MHzで動作します。 その下、「Set File」のボタンは、ディスクイメージファイルをセットする場合に使用します(後ほど説明します)。 「Help」は、現在閲覧中のヘルプファイルを表示させるときに使います。

ディスプレイに「Waiting for loading disk image」と表示されていますが、この状態ではまだFuzixが使用できません。Fuzixの実行には、別途ディスクイメージファイルを準備する必要があります。Tom's SBC用の 128M bytes の物を使用します。表示の通り、「tomssbc-0.3.ide」をhttp://www.fuzix.org/などから取得して、解凍した後に、「Set File」ボタンを用いてアップロードして下さい。このファイルは、解凍した状態でアップロードできますが、ZIPアーカイブにして容量を減らしてからアップロードする事もできます。次のような画面になるはずです。

2019-10-11-fuzix2.png

「bootdev:」には、「hda1」もしくは単に「1」を指定して下さい。続けて、現在の日付と時刻の入力を求められますが、特に必要無い場合は、そのまま改行します。

2019-10-11-fuzix3.png

「login:」には、初期の状態では「root」を指定して下さい。これで、Fuzixが使用可能になりました。

Fuzixを使用した後、ディスクイメージファイルを保存することも出来ます。まずFuzix上で「shutdown」を行い、下のような画面になるまでお待ちください。

2019-10-11-fuzix4.png

続けて、"Save Disks"ボタンを押すと、ZIPアーカイブダウンロードの状態になります。このZIPアーカイブは、起動時にディスクイメージとして、"Set File"して利用することが可能です。

ここで実行されているFuzixは、ver 0.3で、Tom's SBC用にコンパイルされた物です。

エミュレーションしているPCは、Tom's SBC (https://easyeda.com/peabody1929) に準拠しており、以下のような特徴があります。


 ・CPUとしてZ80を搭載
 ・RAMを64 kbytes搭載
 ・ROMを64 kbytes搭載
 ・リセット時に、0000h-3FFFhの領域にROMが使用される
 ・0000h-3FFFhの領域でROMを使用するかRAMを使用するかは、I/Oポート38hへの書き込みで指定する(0でROM、1でRAM)
 ・ROMのどの領域を使用するかは、I/Oポート3Eh及び3Fhへの書き込みで指定する(3Eh: A15; 3Fh: A14)
 ・I/Oポート00h-03hにZ80-SIOが接続されており、画面への出力及びキーボード入力を行なう
 ・I/Oポート10h-17hに128 Mbytesのコンパクトフラッシュカードが接続されており、ディスクとして認識される

起動時にオプションを付加する事ができます。「fuzix.html?debug=1」にアクセスすれば、デバッグ用のツールボタンが表示されます。また、「fuzix.html?speed=8000000」等とすれば、異なるCPU速度で実行する事ができます(例は、8 MHzで実行する場合)。

追記:ディスクイメージの編集

これについては、別記事を書きました。]]>
Fuzix https://www.rad51.net/jeans/?itemid=955 Fri, 11 Oct 2019 17:07:41 PDT ITEM955_20191011