第71話で直した八つのlampを、イトは箱ごと次の作業台へ運んだ。
ところが、箱を置いた瞬間、左右の壁が床へ沈んだ。
隣から来た二箱も開く。
目の前に残ったのは、切れ目のない24個のbitだった。
111000111000000110000010左端には、細いcyanのstart marker。
その上には、八つのslotを持つ透明なframeが三つ浮いている。
イトは最初のframeをlampへかぶせた。
けれど、frameの中央線と作業台の白い継ぎ目が少しずれている。
「八つずつ入れば、どこから囲んでもbyteでしょ」
イトは三つのframeをつないだまま、右へ一つ滑らせた。
start markerが、frameの外へ出た。
一番右の空いたslotには、作業台が仮の0を点けた。
作業台のdecoderは、このlabだけで使うpalette-badge-v1。
その上のscreenで、青いroute badgeが赤く割れた。
frame offset +1 bit
source bits kept 23
dropped bits 1
temporary bits 1
decoder result ERRORイトの手が止まった。
八つずつ、三箱。
箱の数は合っている。
それなのに、三箱とも中身が変わっていた。
16枚が封をされるまで22秒
作業台の奥で、seal gateが動き始めた。
22秒後、この三つのbyteを使って見学用badgeを16枚封入する。
赤く割れたbadgeを封じれば、16枚とも作り直しになる。
止めたままでも、次の見学班には間に合わない。
ユイはsource railをread-onlyにした。
24個のbitそのものは、これ以上変えられない。
マコトは、ずらす前と後の三箱を並べた。
offset 0 11100011 | 10000001 | 10000010
offset +1 11000111 | 00000011 | 00000100右へ一つずらしただけなのに、縦の境界線が全部変わる。
一箱目だけではない。
二箱目も、三箱目も、別の8bitになっていた。
イト
24個あることは同じなのに、三箱とも違う
ユイ
bitの個数と、どのbitが同じbyteに入るかは別です
マコト
直すなら、dataを変える前にstart markerとframeを見よう
残り17秒。
ピコはframeへ触れなかった。
三つの操作cardだけを、イトの前へ伏せた。
三つの戻し方
A：offset +1のまま、末尾へ0を足す
三つのframeは埋まる。
ただし、先頭のbitを一つ捨て、末尾にsourceになかったbitを一つ作ることになる。
B：screenだけ青いbadgeへ塗り直す
目の前は直って見える。
しかしseal gateへ渡る三つのbyteは、ずれたままだ。
C：start markerへ戻し、offset 0から8 / 8 / 8で囲み直す
sourceの24 bitsには触れない。
frameの開始位置と三本の境界だけを戻す。
残り12秒。
イトはAのtail switchを閉じた。
Bのpaint layerも外した。
「C。bitを直すんじゃない。箱を置いた場所を直す」
1 byteは、8 bits
一つのbitが取れる値は、0か1。
現在一般に使われる一つの byte は、そのbitを八つ並べたまとまりだ。
1 byte = 8 bitsけれど、連続するbit列から好きな八つを拾えば同じbyteになる、という意味ではない。
byte列として読むなら、決めたstartから、重ならない八つずつを、順番どおりに扱う。
start -> [1 2 3 4 5 6 7 8] [9 ... 16] [17 ... 24]この作業台ではcyanのmarkerがstartを示している。
別のfileや通信でも、どこがbyteの始まりかはformatや取り決めに従う。
世界中のすべてのbit列に、見えるmarkerが付いているわけではない。
だからこそ、送る側と読む側が同じ境界を守る必要がある。
イトが三つのframeを左へ戻した
残り8秒。
イトは三つのframeを連結した。
右端の仮0を先に消す。
次に、frame全体を左へ一つ滑らせた。
最初のslotがcyanのstart markerへ重なる。
イトは一箱目の右壁を、8番目と9番目の間へ置いた。
二箱目の右壁は、16番目と17番目の間。
三箱目の右壁は、24番目の外。
重なったbitはない。
取りこぼしたbitもない。
足したbitもない。
input bits 24
byte groups 3
bits per group 8
frame offset 0
changed bits 0
added bits 0
dropped bits 0screenの赤い亀裂が閉じた。
blue route badgeが一枚、seal gateへ滑り込む。
続いて二枚目。
十六枚目まで、赤いbadgeは一枚も出なかった。
sealed badges 16
blue result 16
red result 0
screen repaint 0残り1秒で、gateが閉じた。
Picoが動かしたのは、観測用のcyan lightだけだった。
どのcardを選ぶか決め、仮bitを消し、三つのframeを戻したのはイトだ。
Byte数だけでは、中身までは分からない
gateが止まると、ユイは短いdata stripを二本並べた。
どちらも24 bits。
正しく区切れば、どちらも3 bytesだ。
file sizeをbyteで数える入口は、ここにある。
八つで一箱。
その箱がいくつ続くかを見る。
ただし、3 bytesと分かっただけでは、その中身が絵か、文字か、音かまでは決まらない。
何として読むかには、別のformatやencodingの規則がいる。
KB、MB、GBのような大きな単位や、bit / byteの速度換算は、箱の境界を守った後の話だ。
この作業台で先に直すべきだったのは、容量の呼び名ではない。
最初の一箱を、どこから始めたか。
同じ三箱から、一文字が現れた
封入を終えた三つのbyteが、別の小さな読み取り台へ送られた。
台の名はcharacter-demo-v1。
さっきのclosed fixtureとは違うdecoderだ。
伏せられていたscreenが起き上がる。
そこに、一文字だけ現れた。
あ
イトは、三つのframeへもう一度触れた。
今度はずらさない。
start markerから、一箱ずつ指でたどる。
「byteは8個のbit。でも、八つ数えれば終わりじゃない」
一箱目。
二箱目。
三箱目。
「読む側と同じstartから、同じ順番で囲む。だから三箱を渡せる」
それでも、三箱がなぜ「あ」になったのかは分からない。
screenの下から、まだ伏せられたcode tableが半分だけ出ていた。
イトは開かず、三本の境界線をそろえたまま待った。
次回、ピコルート第73話。
同じbyteを文字として読む約束は、誰が決める？