TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
苦渋のナイコン時代
ここだけ永久に1995年なスレ【Win95 OSR 5】
最強対決ＰＣ対ＭＺ
ロードランナー
バボさんについて語るスレ
アセンブラの開発ツールを教えろ
1983年末にスプライトあるPCは実現できる part3
動体保存ノウハウ
パソコンミニ ネクスト次章 Part.3(実質3)
●NECのVU55L使ってる奴まだいる？
究極の8ビット機を妄想するスレ Part 9
- 1 ：
- できるだけ実在するデバイスのみで、究極の8ビット機を妄想してみよう。
ただし現状のPC界を見てもわかるとおり数値的なスペック追求のみでは無意味と知れ。
お前らの妄想力＆創造力に期待する！
前スレ：
究極の8ビット機を妄想するスレ Part 7
https://matsuri.2ch.sc/test/read.cgi/i4004/1560227682/
究極の8ビット機を妄想するスレ Part 8
https://matsuri.2ch.sc/test/read.cgi/i4004/1562275959/
VIPQ2_EXTDAT: none:vvv:1000:512:: EXT was configured
- 2 ：
- >>1
犬と6502とマカーは禁止ってちゃんと書いとけよ…
- 3 ：
- z80と8080も禁止しろ
- 4 ：
- じゃ6809も追加で
- 5 ：
- 3.5インチFDDの普及はソニーと初代Macintoshのお陰やで
MSXはその後、他の国産パソコンは長いこと5.25インチを使い続けた
X68000ですら5.25インチフロントローディングの愚を犯した
- 6 ：
- AppleやMacには市場を左右するほどのシェアなど無かった
- 7 ：
- X68が出たころに5インチ以外のFD採用は「愚」と言われるだけじゃねーの？
ソニー主流だったのは確かだが、企画設計段階だった辺りではアメリカの横やりがあったりして規格がきまってないなどの不透明感あったし、
X68が発売された後も3.5インチFDは5インチFDと比べると割高感バリバリだったし流通量も少なくてエンドユーザがメディア調達に労力を割かなきゃいけないとか「設計者バカだろ」と言われるのがオチだろ。
- 8 ：
- 486GRを買った時にFDDを3.5インチにしたら、メディアが高いだろ馬鹿かってクソミソに絡んで来たアホが居たな
無意味なオートイジェクトにコスト掛けるのも馬鹿じゃねえのって思うけどね
- 9 ：
- ググる先生に聞いたら486GRって92年かよ。
その時代で3.5インチの選択は十分「あり」だろ。
ワープロ専用機、ノートPCは3.5インチの2HDが主流だったし、オフィス街のコンビニだと置いてあった店もあったんじゃないかな？
MSXは3.5インチだったし（ぐぐる先生に聞いたら3インチや5インチもあったらしいが見たことない・・・
- 10 ：
- 当時の事を知りもしない奴が、思い込みで決めつける。
このスレずっとこんなだ
- 11 ：
- 日本じゃ5インチFDDはDOS/V機ですら無視できなかったんだがなあ
486自作では5インチFDDを付けてた人多かったぞ
3.5インチだけで良くなったのはWindowsからだ
- 12 ：
- そもそも3.5インチはMSXが採用したから普及したんだよ
出る台数が違うんだから
ワープロも一体型はスペースの問題で3.5インチ一択
- 13 ：
- 3.5インチディスク使って初めて分かる5インチディスクのほうが省スペースだということ。
- 14 ：
- >>11
多かったと言うほど多くはなかったよ
90年代にPC屋に居たけど5インチ増設する客なんて月に1人いるか居ないかくらい
3モードの3.5インチにする人はかなり多かったけど
- 15 ：
- >>12
MSXとワープロ専用機で3.5"FDDが使われててやたら遅かったから、3.5"FDD自体が遅い扱いされてたな
とんだ濡れ衣だった
- 16 ：
- 98の場合はPC-9821Aｐ、As、Aeが3.5インチで一気に3.5インチが広まったな
1993年ごろか
1992年は微妙な時期
1992年当時は、まだ外付けの3.5インチドライブは
MSXやDOS/Vの720Kの9セクタフォーマットが読めなかったんだよな
本体内蔵のなら問題なく読めた
(FDD外付け用のインターフェースに識別するための信号が無かったのが原因）
後になってから手動のスイッチで切り替える3モードの3.5インチ外付けFDDが出たけど
- 17 ：
- それにIBMがDOS/V 4.0を出したのが1990年で日本で普及しだしたのが1991年だろ？
それまでAT互換機の自作はあまり普及してなかったはず
- 18 ：
- 1992年から1995年は1年違うだけでまるで世界が変わっていく感じだった
- 19 ：
- >>9
> その時代で3.5インチの選択は十分「あり」だろ。
それにもかかわらずに文句言ってきたアホがいるって話だろ
- 20 ：
- >>18
HDD容量なんかもあの頃はすごい勢いで拡大してたな
メインストリームの容量が
93年 300MB
95年 500MB
96年 1200MB
97年 2000MB
98年 3000MB
みたいな勢いで増えていった
メモリは93年頃には4MBが標準で98年でも32MB程度だったから、そこまで巨大化した印象はなかったが
- 21 ：
- PC-9801FAを買った人は1年後にPC-9821Apが出たことを嘆き
PC-9821Apユーザはメモリが13.6MBまでしか増設できないことを嘆き
PC-9821Ap2ユーザは1年後に
Pentium100MHzのPC-9821Xa10が出てPCIバスの時代になったことを嘆いた
- 22 ：
- Pentium100MHzのPC-9821Xa10じゃなくてPentium133MHzのPC-9821Xa13でした
Windows 95プレインストールマシンはもう、Pentiumが当たり前で当然、拡張バスはPCIバス
ISAバスにもプラグアンドプレイが導入されてIRQやI/Oポートなどの設定に悩む必要がなくなったな
- 23 ：
- XaはPCIバス2つにCバス3つか
- 24 ：
- >>22
plug and pray なんて言われてたな
糞みたいなPnPならジャンパで固定できた方がましだと
- 25 ：
- >>19
98互換機ではねーよ。既存ソフトが5インチディスクばかりなのに3.5インチドライブ買ってどうすんだよ。
3.5インチドライブPCを選べるのは5インチドライブ持ってる人か、最初から3.5インチを採用してた機種シリーズだけ。
- 26 ：
- >>24
> plug and pray なんて言われてたな
懐かしいな
> 糞みたいなPnPならジャンパで固定できた方がましだと
安心して使えるようになったの21世紀なってからの印象
- 27 ：
- >>25
ああこういう先見性のないバカっているんだな
まだ>>8に絡んできたアホの方が説得力あるわww
- 28 ：
- >>27
先見性ってアホか。パソコンで大量の既存ソフト資産捨てるほうがむしろ先見性ねーわ。頭悪杉。
シャープのMZなんか3インチだの3.5インタだのQDなんか採用したものだから結局統一できず、
最後までだらだらとテープ資産を捨てられなかった。NECも最初の3.5インチ機は全く売れず、
何も知らず雑誌に騙されて買ったアホはすぐに買い換えか５''FDDを追加するしかなかった。
富士通に至ってはメディアの価格差が何倍もある時代から3.5インチ採用したものだから高性能なのに不人気のまま終わった。
- 29 ：
- 先見性だの革新だの言ってるのはまたアホマカーだろうな。一生シングルボタンマウスでも使ってろや
- 30 ：
- >>27
先見性が有ったなら、3.5"FDDは1.44MBが残って1.2MBは困るんだから98では3.5"は選ばないだろ
- 31 ：
- 考えてみると、フロッピーは2HDの次のデファクト規格が出てこなかったのが残念だったな
88VAで採用された10MBの規格とかも普及しなかったし
- 32 ：
- 海外はZip、日本ではMOかな
- 33 ：
- >>20
日本は1991年頃でもHDDはSASI 20MB～40MB程度だった
- 34 ：
- >>29
1ボタンマウスは1983年頃はまだGUIもマウス操作も一般には未知の領域だったので、一般人に実際に開発機で複数のマウスを触らせて操作感の迷いが少ない1ボタンが採用された
- 35 ：
- マカーはアホだからな。
複数ボタンのマウスも使えないんじゃキーボードとか絶対に無理だよな。
- 36 ：
- >>28
既存資産って
98なんて5インチも3.5インチもフォーマット同じなんだからコピーすればよかったろ
90年頃には3.5インチドライブ増設して使ってたわ
- 37 ：
- いや右クリック相当がキーボードなしではできないから実質両手使わないと何もできないのがマックw
革新的過ぎて笑える仕様w
- 38 ：
- >>36
この板は若者がくるところじゃないっスよw
- 39 ：
- >>36
突っ込みどころ満載だなw
- 40 ：
- >>28
シャープの3インチとかアホすぎるだろw
過去の資産を山ほど持ってるならともかくFD自体もそこそこ売られてたし手荒に扱っても大丈夫な3.5''にするのは何らおかしくないわ
- 41 ：
- ソフト資産軽視の切り捨て王といえばアップル。あなたマカーですね。
- 42 ：
- いろんなとこから外付けドライブ出てたしな好きな方選べ
- 43 ：
- なんか当時の日本を知らない馬鹿がすげー暴れてる。
前にAplleII使ってたというマカーだろう。
- 44 ：
- そうか?妙に頑張ってるお前だけが浮いて見えるが
- 45 ：
- >>43
お前の周辺だけが当時の日本じゃないぞ
- 46 ：
- FDDの普及もCP/Mの普及もジョブスのおかげということを正当化するために捏造を重ねるマカー。
- 47 ：
- >>45
過去のソフト資産のいらない当時の日本人ねぇ。マカーしか思いつかねぇw
- 48 ：
- >>47
こういう人が未だに98とか使ってんだろうな
- 49 ：
- >>41
いやその当時に新規でPC買う奴普通にいただろ
>>8とかもそうだと思う
- 50 ：
- >>48
今までずっとアップルだったの？
おまえは立派だよ。自慢していいよ。何度切り捨てられても変わらぬジョブス愛。
騙されてると分かってても愛し続けるなんて普通の人にはなかなかできないよ。
しかもこんなスレチですべての普及はジョブスのおかげと必死の工作。
- 51 ：
- >>49
普通にいるだろうね。Mac選ぶ人って新規ばかりだと思う。そして思うんだろうね、
あれ？なんか周りと違う・・・って。そして、いや自分の選択は間違っていない。
まわりが間違っているんだ。ジョブスは絶対に正しいんだって。
- 52 ：
- >>50
PC98でも3.5inchが主流になったけどみんな過去の資産を捨てたわけね
- 53 ：
- なんだろ、この何でもかんでもMacとかに関連付ける奴…
何かよほどのトラウマでもあるんだろうなwww
- 54 ：
- Appleに異様な劣等感を持ってる人っていたよね
- 55 ：
- 90年にナイコン族やめた俺のファースト16ビットパソコンは3.5インチモデルだったがこれといった不便も不自由もなかったな。
スニーカーネットｗの対応がちょっと面倒だっただけで。
- 56 ：
- ほんと。何かあるとジョブスが発明した、普及させただからなぁ。
FDDの話になるとアップルガーそしてCP/Mもアップルガーってw
もう話題も日本限定にしようぜ。北米の話を毎回持ち出されても知らんがな。
- 57 ：
- BSや、ベーシックマスター、PET2001、TRS80と比べて完成度が異次元だものしょうがない
- 58 ：
- >>40
X1Dの頃はまだ規格が混沌としてたから、大方ドライブ提供してた日立にでも騙されたのだろう(笑)
- 59 ：
- >>52
馬鹿左翼乙w
- 60 ：
- シャープは目の付け所がズレてるからな。自社で三部門が別々にパソコン作ってるとかw
- 61 ：
- >>54
日本のPC市場で一度もトップシェアとってないのになんでそんなに上から目線なのか。むしろマカーの劣等感の顕れではないか。
- 62 ：
- 昔のシャープのポケコン用高級ブルジョアオプションとしてFDDがあったんだが、
これが2.5インチクイックディスクで、子供心に疑問を覚えていたのを思い出した
あれが3.5インチ2DDだったら、ランダムアクセスできる上に容量もずっと大きくて、しかも遥かに高速だったのに…
- 63 ：
- >>61
これが劣等感の見本ね
- 64 ：
- PC-9801FAまでの98は外付け増設用のFDDインターフェースが標準で付いてたから
簡単にFDD増設できたんだよな
ディップスイッチで内蔵FDD、外付けFDDの切り替えもできたしね
- 65 ：
- マカーに劣等感だとw
圧倒的な日本語環境、圧倒的なソフト資産、圧倒的な開発環境、圧倒的な周辺機器、圧倒的なCPUパワー。
う～ん、すべて劣ってて高価なMacが全然羨ましくないんだが。
- 66 ：
- 1992年頃だともう外付けの3.5インチ2ドライブのFDDが3万円以下だったよな
5インチ2ドライブが4万円以下
- 67 ：
- ユーザーは金があるならメモリやHDD増設したかった。3.5インチFDD増設需要なんて聞いたことないな。
CPU速度もどんどん速くなってたわけだし、5インチ→3.5インチの移行は新機種の買い替えが大半だろう。
- 68 ：
- >>66
内蔵ドライブならジャンク屋で1000円くらいで出てたからケーブル作って繋げてたぞ
- 69 ：
- 売れたから広告にもある程度のスペース取って載ってるわけだが
- 70 ：
- Windows 3.1用のソフトは3.5インチFDDが普通だったと思うぞ
- 71 ：
- 当時のWindows3.1用のソフトって？
- 72 ：
- 筆ぐるめ
- 73 ：
- ExcelとかWordとか一太郎とか花子とかParadoxとか
Visual BasicとかVisual C++とかBorland C++とか
- 74 ：
- Windows 3.1も3.5インチのメディアのなら持ってるが
5インチのメディアなんてあったっけ？
- 75 ：
- 98FAが92年、格安BXが93年、Win3.1が93年、一太郎6が95年。
この辺りで3.5インチ移行が加速したんだな。
32bit時代ですよ。
- 76 ：
- >>74
つまり5インチFDD乗ってる16bitPCじゃWindows3.1は糞遅くて使い物にならないから相手にしてないってことだな
- 77 ：
- 1995年だともう、CD-ROMの時代だな
- 78 ：
- >>74
無いんじゃない？
Windows3.1確か3.5インチFD16枚だった記憶。95の時は24枚だったなあ…
5.25インチFDD積んでるWindows PCは見た事ないなあ。いや、どこかには存在したんだろうけど
Windows3.1以降のソフトは、ほぼ3.5インチFDかCD-ROMだったね。
- 79 ：
- Win95のFD版は数十枚もあったからな。ソフト配布メディアとしては小容量すぎて寿命を終えた。
後は小さなデータの一時持ち出し用としての需要。USBメモリが普及するまで。win98、2kあたりまでか。
BIOS、ドライバインストール用途もあったか。
- 80 ：
- >>76
うろ覚えだけど286って日本語版Windowsは3.0までしか対応してなかったような…。英語版3.1はギリ動く。
まあまあ実用的な日本語版Windows3.1は386以降でやっと対応だった気がするよ。もし間違ってたらすまぬ。
98ノートでもWindows対応したのは386SX積んだNSシリーズ以降だし
- 81 ：
- >>80
実用的だったかどうかは知らないがCPUアクセラレータで
Cyrixの486SLCに乗せ替えれば一応動いたはず
I/Oデータやメルコなどからアクセラレータボード出てたはず
- 82 ：
- 一太郎Ver5 for Windowsが出たのは1993年の年末
Windows 3.1日本語版がたしか1993年の5月だったはず
- 83 ：
- >>79
当時はCD-ROM付いてても直接ブートできないマシンも多かったからOSインストールにFDは必須だったよ
なのでXPでもFDのブートディスクを作成できたりした
- 84 ：
- V30でWindows動かした記憶があるな。3.1だと思ってたけど3.0だったのかな。
- 85 ：
- Windows 3.1は386以降専用だよ
実用的に使うには486が必要かな
- 86 ：
- 486機のDOSレベルの実用速度にするにはWindowsだとPen2、セレ 400MHzくらい必要かな
- 87 ：
- >>84
3.1はリアルモード(8086)が廃止されて英語版でも286でないと動かないな
3.0なら動くことになっているはずなので可能性はあるけどどんな事になるのか…
- 88 ：
- お前らスレ違いの話題大杉
- 89 ：
- >>87
USA版のWindows 3.1はStandard Modeで286は動く。
国内販売版は>>85の言う通り。
- 90 ：
- 前からわかっていたけど説明しよう
9 極の 8 ビット 機スレ スレタイの"極の"と"ビット"はノイズなので消去する
つまりここは98機スレだったんだよ
- 91 ：
- Namco System 1
Main CPU: Motorola M6809 @ 2.048 MHz
Sub CPU: Motorola M6809 @ 2.048 MHz
Sound CPU: Motorola M6809 @ 1.536 MHz
Namco System 2
Main CPU: Motorola 68000 @ 12.288 MHz
Sub-CPU: Motorola 68000 @ 12.288 MHz
Sound CPU: Motorola M6809 @ 2.048 MHz
からすると、ナムコのシステムＩのゲームを完全再現できるくらいのＰＣが
現実的な「究極の８ビットホビーパソコン」じゃないかと思う
- 92 ：
- 8ビットCPUでも50MHzくらいならFPGAで作れるんだし、
マルチCPUを配線する大変さと比べりゃFPGAでCPUから作った方が現実的
つか作られ同人ハードが売られてる現実そのもの
- 93 ：
- ﾅﾑｺｶﾞｰ ｽﾌﾟﾗｲﾄｶﾞｰ言ってるガキオヤジは結局スプライトのオバケが載ってりゃそれでいいんだろうし
BG2面と16色スプライト数十個もあれば満足するんだろう
メガドラがたった7MHzの68kでやってたくらいの処理なら、50MHzのZ80なら余裕で屁が出る
- 94 ：
- スプライトのお化けは今時の車載向け画像チップで余裕で実現出来る
- 95 ：
- スプライトって画像出力直前のチープな重ね合わせ回路だろ。
- 96 ：
- 最初にアタリが作ったのなんて、走査線ごとの割り込みで走査線ごとにソフト描写してたくらいで、
回路も要らない
ソフトの代わりに回路を使いスプライト数を増やし
走査線ごとにじゃなくフレーム全体でソフト描写し
GPUが描写してCPU負荷も回路も要らなくなって、
Windowsの機能として使われてるだけの実体はないスプライトになった
- 97 ：
- 最新技術でBGスプライト専用チップを作ったら無駄に豪華だろうな
- 98 ：
- スプライト衝突割り込みもいろんな条件が設定できるようにして欲しい
- 99 ：
- FPGA言う人は
周波数でけでなく他のスペック無いの？
クロック速いだけ言われても
あっそ、としか。
- 100 ：
- メーカーの完成品の話じゃないんだから好きなGPUで好きに拡張すりゃ良いでしょ
- 101 ：
- ホビーパソコンなら電源onでBASIC立ち上がってすぐにLチカできるレベル出なきゃオッサンは納得しないぞ。
- 102 ：
- >>64
PC-9821Afまでは1MB FDDインターフェース付いてる
MATE-Aで省略されるのはAp2/As2以降
- 103 ：
- >>97
つまりフレームバッファへの描画機能ってことになるから、
2000年前後の2Dグラフィックアクセラレーターの時点で
だいたい必要な性能上限に到達しちゃってるような気がする
- 104 ：
- https://i.imgur.com/je9Kens.jpg
- 105 ：
- GPUも8bitで。PCエンジンは反則負け。
- 106 ：
- 究極の8万円機を妄想したほうがマシ
- 107 ：
- あの頃は消費税なかったもんな…
- 108 ：
- そのかわり物品税というものがあったらしい
- 109 ：
- 売買で一律に課税する消費税よりも奢侈品に限って課税する物品税の方がまだ理に適ってるな
- 110 ：
- 奢侈品の定義でもめるくらいなら一律でいい
- 111 ：
- 一律ゼロ％が計算簡単だぞ
- 112 ：
- >>110
一律にしたはずの消費税の除外品でもめてるじゃん？
物品税の方が正しいと思うがなあ。
- 113 ：
- >>112
だｓから除外品なんかなくして一律にしろって言ってんだよ
- 114 ：
- 庶民の食料品から10%も取るようなクソ政府は他にないだろ
それ以前に腐ってるところも無いことはないが
- 115 ：
- 消費税導入時にちょっと調べただけで、当時の世帯収入で年900万以下は出費増える金持ち優遇政策ってのがすぐにばれたっけ。
試算の仕方で９００万が多少上下したけど貧乏人ほど税負担が増えるしかけには変わりがない。
世帯年収300万だと１５％～２０％ぐらいの出費増って試算もあった（消費税３％なのに）
そのぐらいの年収層って社会人になって一番勢いがある若手独身者なんだけど、結婚のための貯蓄ができなくなってたわけ。
- 116 ：
- 自民党の失政が少子化の原因というわけだな
もっと言えば大蔵省の性だろうが
- 117 ：
- >>115
いるよねこういう人
- 118 ：
- 消費税以外のすべての税をなくしてくれるなら消費税10％でもいいけどね。
住民税とかガソリン税とか自動車重量税とか。
- 119 ：
- 消費税を語るスレになりました。
- 120 ：
- 8bitは非課税にしたらいい
あとメインメモリ1MB以下も非課税
クロックは100MHz以下非課税
- 121 ：
- >>120
それは課税のセンスないわ。
高税をかけるべきは環境負荷の高い奢侈品や奢侈な輸入品、のちの社会的費用（医療費等）を高めるもの等であって、
16ビットイコール贅沢品なわけじゃあない。そんな課税をしたら日本はPC後進国になるよ。
- 122 ：
- z80に課税して6502に補助金を出せば
八方丸くおさまる
- 123 ：
- 国はカネとることしか考えないからなぁ。
仕事なくなって生活保護の相談に行ったら窓口で追い解されたっけ。
失業中の減税措置とかもあるらしいんだが、ハロワではひとことも説明なくて後から知ったけど「申請しないほうが悪い」のひとことですまされて100万ぐらいよけいに税金払わされたよ。
貧乏人はRってのが官僚や政治家、公務員が認識してる国是だからしかたないけどね。
同じころに足悪くして（そのせいで失職したんだが）医者に車いすレンタルの補助制度が市町村にあるから申し込めって言われて福祉課にいったら窓口の若造に「お前には補助制度使えない」って根拠もなく断られたっけね。
今なら安物だったら2万もしないで買えるけど、その当時は安くても5万とかして無職の身障者には高くて買えなかったわ。
それ考えりゃ「食料品の消費税の１０％ぐらいでガタガタ抜かすな、日本は元からそういう国だ」になっちゃうわ。
- 124 ：
- >>121
ス・・・ ス・・・ スレタイ・・・ｗ
16bitは20%、32%は40%、64bitは80%課税で
- 125 ：
- 6502も6809も消えて6811の進化版のようなSTM-8が残った
速度もアドレッシングモードも充実して65/68の不満がほぼ解消
- 126 ：
- 98とかMS-DOSは戦略物資等輸出規制品なんだよな
- 127 ：
- 今でもっ？
- 128 ：
- ココム規制だからな
- 129 ：
- ベトナムが今でも面倒
- 130 ：
- 取り敢えずパラメータシートください
- 131 ：
- 別表の何番よ？
- 132 ：
- 究極の、と銘打つからにはゲームだけでなくビジネスにも使えるスペックが必要だな。
- 133 ：
- 何やらす気だよ会社潰れるわ
- 134 ：
- ハーバードアーキテクチャはちょっと…
- 135 ：
- 自己書き換えできないもんネ
- 136 ：
- ココム規制が更に厳しくなって行き、アメリカ、EU、北欧、日本、台湾、韓国、ではAT互換機、
ロシア、中国、インド、他途上国も8ビットCPUまでってな世界なら、
ビジネス用途にも8ビット機が使われていたかねえ
それとも低性能なx86を中国で作って使うようになってるか？
ソ連はクローンx86作ってクローン互換機も作ってたが、
量産性で8ビット機中心のままで終わったが
- 137 ：
- マルウェア対策としてみるならハーバードアーキテクチャの採用はアリだと思うんだが
セキュアと柔軟性はトレードオフの原則があるわけで・・・
個人的にはパソコンならノイマン型でいいと思うよ。
- 138 ：
- 速度は落ちるけどデータRAM上のコードを実行できるCPUは多い
- 139 ：
- https://www.4gamer.net/games/452/G045232/20190723063/
>僕が持っていたのはPC-6601です。3.5インチのフロッピーディスクドライブが
>初めて内蔵になった機種でした。
>僕は立教大学出身なのですが，あそこって派手好きでミーハーな学校なんですよね。
>「SFが好き」だったり，「ボードゲームやってる」や「PCを持っている」みたいなやつは，
>“根暗”と言われて大学生活が終わってしまう（笑）。
>だから，友達が家に遊びに来るときは，PCを布で隠したりしていました。
いくら究極のマシンがあっても当時はこんな扱い・・
- 140 ：
- 現在でもリアルでPCいじってる何て言いたくないな
- 141 ：
- スマホに仮想PC入れればバレない。
- 142 ：
- マシン語がじかうち出来るほどシンプルだけど関数電卓程度の計算能力がありアドレッシングモードは64bitとか
- 143 ：
- アキュムレータが8ビャbトで、メモリ＝iアドレス）が64ビット？
延々と伸びてる紙テープの上を走るチューリングマシンを連想したｗ
- 144 ：
- 今でさえ64bitアドレスバスのCPUは存在しないのに。
- 145 ：
- 今さら実在のバイナリから派生したコードなんか直打ちできたところで何の価値もないし
CASLのインタプリタでも載せるのか(そういうポケコンが昔あったね。クラスメイトとこれはインタプリタに過ぎないいやこのポケコン自体がCASLで動いてるんだと無意味な論争から殴り合いに発展した思い出)
そんなならもうPythonでも載せて好きに使えばその方が有益じゃないのか
と思ったらmicroPython搭載の関数電卓なんていう正にオレ向けな製品が
- 146 ：
- CASLはレジスタ幅16bitだったか
まあアセンブリ弄るにしても8bitはもうマゾすぎるよな
32bitならコンパイラ任せでいいじゃんてなるし
アセンブリ直書きで個人でも手が回る大きい方ギリギリの箱庭が16bitって事か
CASLは知らんけどCAP-Xの頃にレジスタやメモリ上のbitの並びが常識と逆(LSBが15でHSBが0)というところに抱いた生理的嫌悪感がどうしても最後まで抜けなかった
それに比べたらエンディアンなんて些細な問題だ
些細だがビッグエンディアンはR
- 147 ：
- 現代のパーツで作るとこうか？
メインCPU RL78/G14(100pin)
サブCPU RL78/G14(100pin) (グラフィック描画用)
メモリ SRAM64KB＋バンク切替SRAM 1MB
記憶装置 microSD
音源 YAMAHA YMZ294
異論は認めるが入手性を優先した
今はホビー用途のCRTC/VDPが無いのでCPUに肩代わりさせるしか無かろう
- 148 ：
- >>147
VDPならYAMAHAのでいいだろ
ttp://device.yamaha.com/ja/lsi/products/graphic_controller/
最初から8ビットマイコンと接続するのを想定してる
- 149 ：
- eZ80の24bitアドレスでpush・popも3バイトってのは良い所ついてる
あくまでも8ビットって利点を生かしてるアドレス幅で良い
- 150 ：
- RL78は自称16bitだけど実質8bitの8080系だから問題ないか
- 151 ：
- アドレスもデータバスも24bitにすれば全て解決
- 152 ：
- BBC Microは優秀やったんな
- 153 ：
- いま思いついたんだけどアドレスデーターの任意なプリフェッチとか良さそうだな。
PF 10 00 00 00
2A 12 22
とやればHLレジスターに10001222の内容がロードできて、そのまま
22 12 24
とやれば10001224にHLレジスターの値をストアーできるとか
すでにあるんかな？
- 154 ：
- 言いたいことは想像出来るが
例がさっぱり分からん
- 155 ：
- PFがMMUやセグメントなのかしらMMUもセグメントもさわったこと無いけど
- 156 ：
- その程度ならバンク切り替えでええやん。
- 157 ：
- >>146
HSB?
ひょっとしてLSB = Lowest Significant Bitって覚えちゃったのか？
- 158 ：
- MSB
- 159 ：
- バンク切り替えおじさんうざい
究極なのにそんな低レベルはいらない
- 160 ：
- 究極なら全メインメモリ(64Kとか128Kとか適当に)をオンチップで
レジスタ並みの速度にしたらいいんじゃないの
- 161 ：
- まあ今時ならメガ単位でも積めるっちゃ詰めるが、そんなに内部アドレスバス広くて内部アドレス演算が一度にできるとなると8ビットCPUと言って良いのかどうか？
内部アドレス演算だろうが最小単位時間で演算できるのは8ビットまでじゃないと卑怯なような
つかアドレス演算結果を流用するプログラム高速化ってな16ビットCPU化の裏技になってしまいそうだ
- 162 ：
- >>159
馬鹿なのか。MMUとバンク切り替えも実装は同じだろ。
- 163 ：
- >>162
バンク切り替えおじさんの理解だとそうなるのか
- 164 ：
- ページングな仮想メモリでもなきゃバンク切替えだろ、MMUと名乗ってても。
名前だけ変えたところで実態はごまかせんよ。
- 165 ：
- その理屈ならページングもバンク切り替えだけどなあ
- 166 ：
- バンク切り替えはマッピングし直したりしないだろ
- 167 ：
- んだねファミコンのカセットのバンク切り替えやってるだけのチップもMMUって呼ばれてて紛らわしい
- 168 ：
- ファミコンのはMMC
- 169 ：
- おぅ確かにググってもMMCしか出てこない勘違いしてたゴメンナサイ
- 170 ：
- >>166
意味不明。MMUはマッピング機能つけたバンク切り替え。バンク切り替えしょぼい拡張にすぎない。
- 171 ：
- MMUってメモリー管理ユニットの総称だからバンク切替もセグメント方式もページング方式も含まれる
実装が同じとかは馬鹿としか言いようがない
- 172 ：
- CPUとメモリ間のアドレスバスにSN74LS670Nを入れたらマッピング
CPUとつながっていないメモリのアドレス線にラッチを付けたらバンク
- 173 ：
- >>170
意味不明なら黙ってろ
- 174 ：
- バンク切り替えもマッピングといえばマッピングなわけだし、この馬鹿たちは何の議論をしてるのだろう。
無知がバンク切り替えはとんでもない低機能でMMUがとんでもない高機能かのように勘違いしてるが、
汎用ロジックで簡単に実装できるレベル。PCエンジンやMZ2500はむしろ低機能な部類の質素なMMU。
>>173
ほんと理解できてないおまえが黙ってろってかんじ。
- 175 ：
- じゃあ汎用ロジックで仮想メモリ実装してみろ
- 176 ：
- バンク切り替えおじさん大活躍だなｗ
- 177 ：
- >>176 ←みんなから馬鹿にされすぎてもはや煽ることしかできないW
- 178 ：
- MMUならなんでもできるんだ!!!って奴がいて面白い。
アセンブラは全く書けないのがよく分かる。AI連呼厨に似てる。
- 179 ：
- >>178
> MMUならなんでもできるんだ!!!って奴がいて面白い。
どこにいるんだ？
> アセンブラは全く書けないのがよく分かる。AI連呼厨に似てる。
お前の周りが低レベルなだけだろw
- 180 ：
- Z80はリロケータブルのコードを楽に書けるわけではないから、結局、
メモリを自由にマッピングできてもコードやデータのアドレスは決め打ちで書くしかない。
MZ2500のwikipedia見てもどれだけ高機能なソフトが書けるかではなく、
> 他の機種と同じような配置でビデオメモリをマッピングすることでソフトウェアの移植についてもしやすくなっていた。
などというなんというか後ろ向きな使い方を自慢している。
- 181 ：
- >>179
自分のことを言ってるのだという自覚があるから反応するんだぜw
- 182 ：
- >>180
ウィキペでもZ80や80系をリロケータブルなコードが書けないのがさも8bitにあるまじき大欠陥かのように糾弾してるけど、
8bitでリロケータブルなコードを楽に書けるCPUって6809くらいしか無いよな。
そう、出るのが遅すぎて全く普及しなかった、商業的に失敗した、自称だけは最強の、あの6809。
- 183 ：
- MZ2500は、カタログスペックだけは威勢がいいんだけど
実装がいまいちわかってねーなーって残念無念の総合デパートみたいな環境でなあ…
シャープのコンシューマ向け8bit機は、結局X1turboが無難だった。
turbo以前を買っちゃったユーザーは完全に踏み台だったし、turbo全盛という時期も正味で2年も無かったけど。
turbo3/Z/X68000という発表時期ずらしトラップのえげつなさも凄かった(酷かった)
- 184 ：
- >>181
ごめん、俺>>171だし
で、「MMUならなんでもできるんだ!!!」って奴はどこにいるんだい？w
- 185 ：
- >>180
リロケータブルじゃないからこそ、MMUがいると思うんだけどなあ
- 186 ：
- 日本人がホビーパソコンに求めていた機能を全て盛り込むとFM TOWNSっぽいものが必要になるのでは
8bitでは明らかに性能不足
最低H8でRAM 1MB無いと厳しいレベル
- 187 ：
- >>185
おまえがそう思うのならそうなのだろう。おまえの中ではなw
- 188 ：
- >>185
何に使うん？w
- 189 ：
- 結局32bit環境でも各プロセス毎のアドレス空間は0番地からスタートだし
リロケータブルオブジェクト？なにそれ何の意味があるの？(鼻くそほじりながら)…ってなるのわかってるしな
MSDOSがCP/M由来のレガシーで0x100番地スタートだったくらいで16bit環境でも基本0番地スタート
86系はセグメント相対化があったからMSDOSやCP/M86の16bit環境でもロード即実行で子プロセス起動とかサックサクだったけど
68k系はCP/M68kやHuman68kでもロード時にジャンプアドレス書き換えてやらないと実行できなくてかったるかったねえ
なんでリロケータブルに書けなくしたんだろうね68k系
前座の6809は16bit相対ジャンプ可能だったのにね！
- 190 ：
- 究極の8bit環境、80系まあZ80系で考えるなら俺はユーザープロセス毎に16bit仮想空間割り当てる方向で100番地スタートで設計するわ
フルリロケータブルバイナリなんか実現する意味ある？±7bit相対ジャンプあれば十分じゃん？
- 191 ：
- リロケータブル系命令は有るにこしたことはないが、無くても何とかなる（ヘッダにリローケーションテーブル必須）からなぁ
Z80の場合はJR系命令は2バイトだから、3バイトのJP命令より1バイト分お得、ぐらいの意味しかなかった
>>190
Z80系の場合、前半32kBがROM、後半32kBがRAMというのがハード設計が一番楽なので
バンク切り替え機構必須の0100Hからではなくて、8000Hからにしたいところだねぇ
- 192 ：
- >>189
DOSもEXEはセグメント書き換えてたけどね
- 193 ：
- メモリ空間の半分をROMで埋めるのが一般的で設計しやすいとかもう無茶苦茶だな
64KBオールRAMでさらにMMUでプロセス毎に0番地始まりのオールRAM空間割り当てだろうが
- 194 ：
- セグメントレジスタにOSから初期アドレス振られるだけの処理が、実行バイナリを全部舐めてジャンプアドレス書き換える処理と等価だったとでも言うのか
- 195 ：
- やっとおまえらもアセンブラレベルでは
68kのフラットよりセグメント方式の8086のほうかスマートな設計だと理解してくれたか。
- 196 ：
- 8KB単位で自由にマッピングできればさぞすごいことができそうだが実はそれほどすることもない。
386も超高機能なセグメント機構をもっているが使われることはなく、
いつも1セグメントオールフラットでしか使われない。
- 197 ：
- 32bit以降の大抵の環境ではページメモリ4KBが一般的な実装だと思うが…何故に8KBなのかと
386の32bitセグメントは俺も神機能だと思うけどねえ…
- 198 ：
- Windowsはメモリ少ないと4KBだけど今時のメモリ環境なら2MBやで。TLBが簡単に溢れるから。
- 199 ：
- いずれにしても8KBにする説明にはなってないね
- 200 ：
- Z80環境でフルリロケータブルなモニタ(バイナリエディタ)やアセンブラ/逆アセンブラとかあったけど
自己書き換えするような汚い実装してるか、相対ジャンプを継いで済ませてたりだったな
元々メモリの隙間にねじり込んで工作しようってツールだから、元からバイナリ自体がコンパクトだし
リロケータブルモニタの中には実行中の移動すら実装してるものもあった
64KBしかないメモリ空間内で常にリロケータブルなバイナリが書けないと困る用途ってどんなだ？
7bit相対で十分じゃんな？
- 201 ：
- そこ重要？シャープに直接聞けばいいんじゃね。当時64kbitチップが安かったんじゃねーの。
- 202 ：
- > 64KBしかないメモリ空間内で常にリロケータブルなバイナリが書けないと困る用途ってどんなだ？
ハンドアセンブルしてるから
- 203 ：
- >>202
まずアセンブラを書こう
- 204 ：
- MSXのスロットは16KB単位、DOSのEMSも16KB単位。なぜにMZ2500の8KBに過剰反応したんだ？
- 205 ：
- >>200
モリターｗｗ
- 206 ：
- >>194
実行バイナリの書き換えも発生するけどね
- 207 ：
- >実行バイナリの書き換えも発生
kwsk(お前の妄想でないなら)
- 208 ：
- EXEは先頭にセグメントの書き換えテーブルがあってコード内でのセグメント値を指定してる部分はロード時に書き換えられる
- 209 ：
- > 64KBしかないメモリ空間内で常にリロケータブルなバイナリが書けないと困る用途ってどんなだ？
いかにもコード書いたことない人の質問だな。メモリが少ないからリロケータブルで書きたいのだ。
多数の共通ルーチンがあって、メモリに余裕がないから必要なときにロードしたいが
アドレス固定なら自由にロードできないだろう。
- 210 ：
- サブルーチンをいちいちリロケータブルで書いて随時ロードしたい用途とは具体的に？
オブジェクト単位でソース分けてリンク時に結合＆配置では不味いのか
- 211 ：
- >>208
NTとかで使うPEやNEヘッダは実行バイナリすらヘッダに収まるけど、少なくともMSDOS用のexeのヘッダは各セグメントの初期値が書いてあるだけで、起動時に書き換えられすらしない
つまり何言ってんだお前すぎる
- 212 ：
- Win32以降のexeはフラットメモリ空間だけど、仮想アドレス/メモリ下なのでどのプロセスも自分自身は0x00000000～の空間が割り当てられて見えてるし、ジャンプアドレス等を起動時に実アドレスに書き換える必要もない。
DOSのexeは仮想アドレスや仮想メモリの仕組みを持たないが、ジャンプや参照にはセグメント相対か絶対アドレス(BIOSやI/Oなど)を使うので、ジャンプアドレスや参照アドレスをロード時に実アドレスに書き換える必要がない。
いずれも、フラットメモリモデルで仮想アドレス(仮想メモリ)機能が無く、ジャンプアドレス等をロード時に実アドレスに書き換えなければ起動できない、不自由で非効率な16bit環境とは無縁の話だな
- 213 ：
- >>210
Windowsで言うところのDLL全般がそうじゃないの？
CRTとか全モジュールに結合してたらFDパンパンだよ
- 214 ：
- >>210
笑えるw リアルでコード書いたことないんだなw
- 215 ：
- Win32のページサイズも知らなかった人がいろいろ語ってて面白い。
- 216 ：
- >>213
8bit環境だよ？たったの64KBしかないメモリ空間で何をダイナミックリンクするの？馬鹿なの？
- 217 ：
- >>214
具体性のない煽りだけの無能が湧いてきたなあ
普通はソース単位でオブジェクトにしてリンカで結合して実行バイナリを作るんだけど、まあハンドアセンブルくらいしかした事ないおじさんにはわからないよね
- 218 ：
- >>215
8bitスレなので32bit環境の説明をいちいちしないだけ
それでMSDOS環境でEXEの実行バイナリのジャンプアドレスを頭から舐めて書き換えるんですか？しないでしょ？何言ってんの馬鹿なのお前
- 219 ：
- >>218
そんで8KBはどこから出てきたんだっけ？
- 220 ：
- 分割アセンブルやリンカも知らないくせにリロケータブルバイナリに拘るオッサンてほんと何なんだろうな…マウントモンスターかと思ったがマウントになってないし、逆張りキチガイにしても逆張りにもなってない…まあキチガイなのは間違いないが
- 221 ：
- >>219
MZ2500らしいよ
それで何で8KBにこだわるのかは結局説明がないままだな
- 222 ：
- >>216
8bit環境だからこそだよ
ストレージ容量をなんとかするための仕組みだろ、ダイナミックリンクなんか
- 223 ：
- >>221
一人で発狂して拘ったのはおまえだろ、ナイコンさん (JP)w
> 197 名前：ナイコンさん (JP)[sage] 投稿日：2019/08/09(金) 22:34:37.20 H
> 32bit以降の大抵の環境ではページメモリ4KBが一般的な実装だと思うが…何故に8KBなのかと
- 224 ：
- 8KBは実際にZ80でMMUを使ってる実在パソコンの例なだけだろ
実物を例にしてるだけなのだから、Z80での他の例を出して行くなら分かるが、
32ビットCPUの例を出しても、話としてまた実物に戻るってだけのような
- 225 ：
- なんか急に生き生きするときあるなあ
- 226 ：
- >>222
それでストレージ容量の節約のためにダイナミックリンクを行っていたという環境とは具体的に？
ああ誰も知らない糞みたいなマイナー環境なんか持って来てもブチRよ？
- 227 ：
- >>223
おれは後の高度なページマッピングを行う環境ではページサイズ4KBが主流になったという事実を挙げたのみで
件の御仁がページサイズ8KBに拘る理由は俺にもわからんのだが何故俺に詰問する？相手を間違ってねーか？そして馬鹿だろキチガイ
- 228 ：
- >>224
実在したと言っても全く普及せず、市場に影響を残す事もなく、後続も続かなかったマイナー機種のバンクメモリのサイズが8KBだったというだけだしなあ
- 229 ：
- >>228
だからなんでそんなにページサイズ8KBが気に入らないんだよw 問題視してるのはおまえだけなんだよw
SuperMZのMMUは8KBだった。ふーん、妥当なサイズかなぁ、で終わりなんだよ。
- 230 ：
- >>211
DOSのヘッダには再配置テーブルのポインタがあるだろ
- 231 ：
- >>212
今時のOSはセキュリティ上、コードもスタックもヒープもランダム配置で実行時のアドレスを前持って特定できないぞ、JP君。
- 232 ：
- >>212
オフセットは書き換える必要ないけどセグメントは書き換える必要があるぞ
- 233 ：
- 即レスくれるからって大喜びでウソ八百並べる奴らはさすがに白けるな
- 234 ：
- 嘘ばかりってMIPS君じゃね？
- 235 ：
- ブーイモで検索すると碌なレスがないw 白けるとか以前にスレ汚し
- 236 ：
- >>234
つまり平気でウソ八百を並べる6502キチガイということだな
- 237 ：
- >>217
みんな、バンク切り替えだの、MMUだのと、64KBで収まらないレベルの話をしている。だがしかし、
キミのその手順だとその実行バイナリは64KBに収まっている。キミは一体全体何の話をしているのだ？
おじさんにはキミの言ってることが全く理解できないよ。
- 238 ：
- >>211
MSDOS のEXEはロード時にJMP先書き換えるリロケートが必要
実際にROM化作業したから本当
- 239 ：
- セグメントレジスタを変更する命令は書き換える必要があって当然だな
- 240 ：
- >>211
ちょっとはググってから出直してこいよ…
.com形式ならセグメントは固定だけど.exeだと実行中にセグメントレジスタ変更するからその部分はリロケーションが必要
http://bytepointer.com/download.php?name=msdos_encyclopedia_article4_program_structure_exe_com.pdf
- 241 ：
- >>240
ちょっとググってもPEの事しか出てこないからそれで知ったかしちゃったんだろうな
- 242 ：
- また(JP)が大恥晒しただけだったなｗ
- 243 ：
- ジジイって職場で呼ばれるような俺が、若造扱いされてた頃はEXEヘッダの詳細はともかく「何のためにあるのか、どのような働きするのか」は一般教養レベルとうか常識レベルで「知っててあたりまえ」だったんだがなぁ・・・
これがいわゆる「いまどきの若い者は」ってヤツか？
- 244 ：
- >>243
逆に8bitで世界がとまってて、ヘッダとかエンベローブとか言われると
パニック起こしちゃうんだと思う
ダイナミックリンクですら否定的みたいだし
- 245 ：
- z80で止まってるのも似たようなもんだけどな
- 246 ：
- >>244
ダイナミックリンク？オーバーレイから勉強しろ
- 247 ：
- 電子手帳ETのアプリはZ80のリロケータブルコードが必要だった
オーバーヘッドが大きいけれど何とかなる
- 248 ：
- >>246
バンク切り替えみたいな奴だよねｗ
- 249 ：
- 嫌味を嫌味とわからん奴には何言っても無駄と思う。
アドレス変換もバンク切り替えとか言うような奴にとってはオーバーレイもバンク切替えだろうから。
- 250 ：
- (JP)の次は (ｱｳｱｳｳｰ)か。無能の煽りはほんと見っとも無い。
- 251 ：
- アドレス変換もバンク切り替えなんてどっから出てきたんだ？
- 252 ：
- 8bitでバンク切り替え、MMUの議論すれば8086のセグメント機構がすべての問題を解決してくれる夢のようなCPUだと理解できるだろう。
フラットなメモリモデルが便利に見えるのはあくまでチープな仕様のC言語から見た結果にすぎない。
Cではメモリ操作はポインタ、つまりアセンブラで言えばインデックスレジスタで操作するだけだからな。
- 253 ：
- 言ってないことを捏造して言ったことにするって8bitでC言語は普通に使われた君だね。
- 254 ：
- >>252
farポインタｗｗ
- 255 ：
- よくセグメントには64KBの壁があるという避難する馬鹿がいるがそのとおりだ。
だがそれは16bitCPUなんだから元から64KBを超えるデータ、アドレスの操作は不得意で当然なのだ。
しかし8086はよく考えられている。flabel、farprocの存在だ。これにより安々と64KBの壁を越えてJMP、CALLができる。
もちろんセグメントレジスタを操作すれば64KBの壁も越えてデータに触れる。そのCによる処理系依存のアホ実装がfarポインタだ。
- 256 ：
- >>237
このスレのタイトルを大声で100回読んでからもう一度考えろ
>>238
ROMに焼くバイナリを書くのに、メモリモデルの設定が不適切なまま気付きませんでした
というお前自身の至らなさ自慢か
>>239-240
DOSのEXEの32バイトのヘッダにあるのは、セグメントレジスタの初期値テーブル。
コード部の0バイト目が実行される際にOS(DOS)がプロセスに渡すセグメントレジスタの値が毎回変わるのは当たり前だ。
セグメントを持たないフラットメモリモデルの環境で、ロードの度に実行バイナリの全てのジャンプアドレスや参照アドレスを書き換えるという、不自由で頭の悪い動作と等価なのか？比べ物にもならんだろうが
>>241
ちょっとぐぐって斜め読みできるなら、お前よりはよほど優秀だな
>>242
出て来ない事がわかってる時しか調子に乗れないんだなあお前は
>>243-244
相手が馬鹿で、無知であって欲しいという願望。何の根拠もない。
>>253
ストローマン論法(案山子論法)という。
- 257 ：
- バンク切替がアドレス変換と言うならまだワンチャンあるかな
- 258 ：
- まあexeにしてもDOSバイナリ(MZヘッダ)とPEヘッダ(NTヘッダ)の区別もつかない、もしくは混乱させるために敢えて混同して語る奴らの連携、意思統一が図られている様には舌を巻くね。
SMSか何かで相談しながらやってるのか。データベースやwikiも共有してそうだ
- 259 ：
- >>244,246
結局、8bitのメジャーなOS環境で実行バイナリをダイナミックリンクする環境は、提示されず終いだしなあ。
32bit以降との区別もつかないアホが言いっ放しかよ…
- 260 ：
- >>256
せっかくPDFまで示してやったのに…w
- 261 ：
- 何も提示せず、お前はダメだ、それは間違いだとしか言わない。
これで騙せたらチョロイよなあまじで
- 262 ：
- largeやhugeモデルでコンパイルして、ジャンプも参照も全部絶対アドレスで、ロード時にリロケーションが行われるようなバイナリ持って来て
DOSのEXEとは全てこうだ！！くらい言うかと思ったら、それすらしないからなあ。
まあ、x86(dos)環境ではtiny/small以外は無能が使う、のひと言で終わりだが。
- 263 ：
- >>256
このスレのタイトルどおり、8bitCPUで64KBを超えるプログラムの話をしているんだが。
おまえは8bitパソコンを使ったことがないのか。市販ソフトは64KB超えるソフトばかりだろう。
- 264 ：
- >>259
8bitのメジャーなOSってw おまえリアルで持ってた8bitパソコンの機種言ってみw
8bitパソコンすら使ったことなくてここで大暴れしてるっておまえMIPS君か？
- 265 ：
- >>256
知らないなら大口叩かなきゃいいのにｗ
EXEヘッダにはリロケーションテーブルポインタがあるだろ？その先に再配置テーブルがあってコード内のセグメント指定してる場所が入ってる
DOSはロードした時にそれを見てロードしたセグメントに書き換える
EXEファイルのコードは仮のセグメントになってるからROM化するときは実際の配置に合わせてセグメントを書き換えてその状態でROM化する
DOSのデバッガとか使ったことないの？
- 266 ：
- 8ビットPCなんて電源オンで即ROM-BASIC起動なのしか知らん。
- 267 ：
- >>261
The relocation pointer table consists of a list of pointers to words within the load module that must be adjusted before the program is given control.
These words consist of references made by the program to its individual segments. These segment address references must be adjusted
when the program is loaded, because it can be loaded at any address.
Each pointer in the table consists of two words. The first word contains an offset from the segment address given in the second word, which in turn
indicates a segment address relative to the start of the load module. Together, these two words point
to a third word within the load module that must have the start segment address added to it (the
start segment address corresponds to the segment address at which the beginning of the
program's image has been loaded).
- 268 ：
- >>262
恥ずかしいからもうやめとけよｗ
- 269 ：
- クリーンコンピュータを馬鹿にしゅるな
- 270 ：
- バグばかりだからクリーンコンピュータにするしかなかった。ソフトが無ければバグもない。
ただしテープ起動ですけどねw
- 271 ：
- >>267
だからDOSのexeでロード時にオフセット書き換えが行われるのはセグメント参照してる部分のみで、
フラットメモリ空間にロードしてジャンプアドレスから参照アドレス全て書き換えなければ動作しない不自由で原始的な環境とは違うんだよ
ロード時にリロケーションが行われるという部分を斜め読みして実体を知らんのはお前の方だ
- 272 ：
- >>258
スレのみんなによってたかっていじめられているという主張をする人をたまに見るけど、本気でそう思ってるの？
- 273 ：
- 8bitスレでDOSってことはMSX-DOSの話？
それともCP/M？
- 274 ：
- MIPS君が「お前MIPSだろう」とやるようになったのか
前スレで不自然に立ち消えた、20年粘着されてる話にも出て来たな。
「喧嘩を売って失敗した時に、その失敗を相手(粘着されてる側)に付け替えるようになった」とかいう
アイムザパニーズみたいなものか
- 275 ：
- CP/MやMSX-DOS(中身はCP/Mだ)ではリロケーションなんか必要ない
MSDOSでも馬鹿な設計しなければ必要ない
- 276 ：
- >>272
前スレに20年粘着されていて、妄想でない証拠にデータ蓄積して頻度とか割り出してるという人が居た
- 277 ：
- 英文を垂れ流せば怯むだろうとでも思ってそうな浅薄さが痛すぎる
自分自身のレベルの低さを自ら暴き立ててしまっている事にも気付けない、哀しい生き物なのか
- 278 ：
- >>271
↓書き換えは起こらないって主張してたのはお前だろ
また誤魔化して逃げるのか？津田大介みたいな奴だな
少なくともMSDOS用のexeのヘッダは各セグメントの初期値が書いてあるだけで、起動時に書き換えられすらしない
- 279 ：
- >>271
> 少なくともMSDOS用のexeのヘッダは各セグメントの初期値が書いてあるだけで、起動時に書き換えられすらしない
> だからDOSのexeでロード時にオフセット書き換えが行われるのはセグメント参照してる部分のみで、
最初と言ってることが違うじゃないですかw
- 280 ：
- >>275
tinyモデル以外は馬鹿な設計だとよｗｗｗｗ
- 281 ：
- よくlargeモデルで遅くなるというがそうではない。
32bitで扱うレベルのコードを16bitの処理系で実行するから遅くて当然なのだ。
- 282 ：
- >最初と言ってることが違うじゃないですかw
32バイトしか無いMZヘッダにリロケーション用のデータなんか無いよ。本当に馬鹿だな
- 283 ：
- >>280
ROMに焼くのにtinyモデル使わないアホが失敗してたよね
まあアホだからなんだけど
- 284 ：
- この板には、言ってないことを捏造して言ったことにする人と、言ったことを言ってないことにする人がいるようだ。
- 285 ：
- >>259
OS-9も知らんのか？
- 286 ：
- MZヘッダの後に必要に応じてリロケート用のポインタアドレスが列挙されるけど、仕様としてはadditionalだしな
まあ68k系のような非効率なフラットアドレス環境のリロケート処理とは意味も性格も違うし、食い下がってる奴らの無理筋感は否めない
- 287 ：
- 6809の実機を持ってるなんて南野陽子のファンぐらいだからな。
- 288 ：
- >>285
知らないね、興味もない
- 289 ：
- >>286
68kのリロケートとDOSのEXEのリロケートの意味と性格の違いを詳しく聞きせてくれ。
- 290 ：
- >>271
> フラットメモリ空間にロードしてジャンプアドレスから参照アドレス全て書き換えなければ動作しない不自由で原始的な環境とは違うんだよ
68Kのことを言ってるのか？
68000ですらジャンプは±32KB内なら相対だし、データはたいていAnレジスタからの相対でアクセスするぞ
Human68KはMS-DOSに倣ってるからリロケーションテーブル持ってるけどほとんど使ってない
そもそもOS-9/68000だと完全ポジションインデペンデントが要求されるし
- 291 ：
- >>282
おい誤魔化すなよ
- 292 ：
- >>288
なら黙ってたほうがいいぞ
恥かくだけだし
ってもう手遅れかww
- 293 ：
- 8086もshort、nearジャンプは相対だから68kと似たようなもの
早く68kのリロケートとDOSのEXEのリロケートの意味と性格の違いを詳しく教えてくれ。
- 294 ：
- >>283
まともなプログラムを書いたことない事が分かった
- 295 ：
- >>282
> 32バイトしか無いMZヘッダにリロケーション用のデータなんか無いよ。
そりゃそうだよ、誰もそんなところにあるなんて言ってないしw
> 本当に馬鹿だな
お・ま・え・が・な
- 296 ：
- >>290
CP/M68k環境だと、ロード時にリロケーション処理が必要な.68kバイナリと、セルフリロケータブルな.RELバイナリの二種類あるようだが？
Human68k環境でも、ロード時にOSによるリロケーション処理が介在するのでロードが遅くて有名な.Xバイナリと、セルフリロケータブルな.Rバイナリの二種類があった。
チャイルドプロセスでネストするような場合は、リロケータブルバイナリのコマンドでないとくっそ遅くて閉口
これが「父のパソコンを超えた」はずのパーソナルワークステーション()の現実
- 297 ：
- >>294-295
こういう全く内容のない、ただ罵声を浴びせたいだけの無能な。
- 298 ：
- スレ伸びてると思ったらアスペで嘘つきのアリエナイクンが暴れてるのかｗ
おとなしく巣に帰って「8ビットでC言語ありえねぇ！」って嘘ついてろよ。
- 299 ：
- ここの(ｱｳｱｳｳｰ)がやっぱり言ってないことを捏造して言ったことにするC言語普通に使ってた君だったかw
さすがアスペで嘘つきなだけあって低脳な煽りレスばかりのはずだw
- 300 ：
- >>296
一生懸命ググってきました？
- 301 ：
- >>297
codeとdataが64KBに収まらないプログラムをROM化するときどうすんだ？
EXEを再配置した状態のバイナリにするかROM化よリンカを自作するか？
- 302 ：
- ほんの数分でぐぐってこうして反論できるなら、お前よりよほど優秀だな俺
- 303 ：
- >>297
MZヘッダ内にリロケーションテーブルがあるなんて言ってる奴はお前以外いないようだけど
EXEヘッダはMZとアディショナルも含めてヘッダだけど
- 304 ：
- >>302
全く反論できていないみたいだけど
- 305 ：
- アスペで嘘つきって言う自覚あったんだねアリエナイクンｗ
そのことを指摘してくる人間はすべて同じ人間に思えちゃうんだろうな。
- 306 ：
- ｱｳｱｳｳｰは相手にしないほうがいいよ。捏造して煽る。こればかりだから。
- 307 ：
- >>306
都合の悪い書き込みが見えないのはアリエナイクンの得意技ですｗ
馬鹿だからバレてないつもりみたいだけどバレバレな自演も君の得意技だったっけね。
- 308 ：
- イチャモンに登場するタームも俺が持ちだしたものから抽出してるだけだし、AIやスクリプトで煽り文作ってると言われても驚かないな
- 309 ：
- ナチュラルに、オウム返しレベルがやっとのレベルの頭の出来で、スレ読み返しても（してないと思うが）覚えてられるだけの記憶力ないし、自分が正義で正しくないと癇癪起こす基地外なんだよ、アリエナイクンって。
アリエナイクンレベルの「基地外特有の支離滅裂さ」はAIやスクリプトで再現するのは難しいと思うぞ。
- 310 ：
- >>307
ｱｳｱｳｳｰ君一味の捏造、嘘つき一覧。
8bitCPUでC言語は普通に使えない → 8ビットCPUでC言語？ ないないありえないっしょ！と普通を削除。捏造スレを立てる。
8bitCPUでC言語開発は普及していた → いくら環境やコンパイラ、開発時期を聞いても答えないで数年間逃亡。
8bitCPUでC言語でセルフ開発していた → 実は16bitパソコンにZ80ボード挿して開発していたことが発覚。しかし開発の詳細をいくら聞いても答えず。
8bitCPUでC言語開発は普及していた → 当時のインターフェース誌のC言語記事に8bit機では普及していないという記事内容あり。
8bitCPUでC言語は普通に使える → 何のコンパイラを使ってて使用した感想をいくら聞いても答えない。
結局、8bitCPUでC言語は普通に使える君は、実際使ってた環境とかコンパイラ聞くと全く答えないで捏造して煽るんだよな。
- 311 ：
- >>297
内容が無い？
御託を言う前に
>> 32バイトしか無いMZヘッダにリロケーション用のデータなんか無いよ。
> そりゃそうだよ、誰もそんなところにあるなんて言ってないしw
に反論するなり謝るなりしなよ
- 312 ：
- >>296
そりゃCP/M 68KとかHuman 68Kは「完全ポジションインデペンデント」を要求しないからね、当たり前
- 313 ：
- 6809とか68kとかマイナー機種に逃げやがって
- 314 ：
- > なんでリロケータブルに書けなくしたんだろうね68k系
とか喧嘩売ってきてやり込められたら
> マイナー機種に逃げやがって
とかw
- 315 ：
- >>308
おい嘘つき
早く言い訳しろよ
- 316 ：
- 何一つ証明も反論もできてない奴に嘘吐きと罵られても、どうしていいのかわからない(鼻くそほじりながら)
- 317 ：
- >>310
48ナイコンさん (ｱｳｱｳｳｰ Sac9-6UAB)2018/12/24(月) 00:35:57.06ID:tNQRpHqma>>49
アリエナイ君の主張ってコロコロ変わってるからねぇ。
「8ビットCPUでC言語は使われてなかった」
「8ビットパソコンでC言語は使われてなかった」
「8ビットパソコンのセルフ開発でC言語は使われてなかった」
「C言語は普及してなかったから使われてなかった」
「8ビットでC言語は使いにくいから使われてなかった」
「高価だから使われてなかった」
雑誌に書かれてないことまで強く主張してる。
どうみても嘘だらけだよ、アリエナイ君の言ってることは。
これのオウム返しですねｗ
頭悪すぎだよ君。
- 318 ：
- 8ビットのスレに16ビットがー！ってやるあたりアリエナイクンはバカ以外の何者でもないんだけどさ。
ほんと、バカだよねぇ・・・
- 319 ：
- 捏造 (ｱｳｱｳｳｰ)煽り君は今激怒してるからレス返さないほうがいいよ。
- 320 ：
- C云々は専用スレあるだろ巣に帰れバカどもが
- 321 ：
- >>318
巣に帰れ
- 322 ：
- >>317
内容からして明らかにおまえが悪意ある捏造してることが分かるな。よくいる人間のクズだな。
- 323 ：
- >>287
タモリファンだっているかも知れないじゃないか
- 324 ：
- >>316
おい鼻くそ
早く言い訳しろよ
- 325 ：
- 煽られてもその程度しかできないバカだからしかたないけど、くだらないしつまらない知性のかけらもない、自作自演と頭の悪い鸚鵡返ししかできない低能っぷりは相変わらずか。
しょせんその程度の低能だったわけだが、ほんとレベル低いな。
- 326 ：
- みんな何でそんなにストレス溜まってんの・・・
風俗でも行って抜いてこい・・・
- 327 ：
- 動物園のように自演も何もかも筒抜けの檻の中で、ターゲットが足掻く様を小突き回して楽しむ場所だからだよ
穴に落とした犬をみんなで棒で殴って楽しんでいる所に、博愛精神なんか持ちださないでくれ。しらける
- 328 ：
- 言っちゃなんだが
どこかの盲腸半島の連中と相通じるメンタリティの持ち主多いよな
…と思っていた
- 329 ：
- 捏造癖があるのはネトウヨだな
- 330 ：
- ぶっちゃけ つまんねえ
- 331 ：
- もうスレタイのままの6809だけでいいよ
- 332 ：
- 6809か。つまらねぇCPUだ
- 333 ：
- >>328
お前みたいな奴な
- 334 ：
- >>332
そう言うのは6809を超えるCPUを出して言わないと単なる負け惜しみにしかなってないぞ
- 335 ：
- 6809はあの集積度での一時的な最高性能を目指し過ぎてて、
確かに同世代の8bitでは高性能高機能高速で最高ではあるが、
16bitも作れるだろって回路規模とそれにより高クロック化できないって、
次に続かない袋小路っぷりがなあ
ちゃんと同一バイナリ互換な16bit CPUが出てくれば生きたろうけども
- 336 ：
- 6809の8MHz版とか出てたらロマンだな
- 337 ：
- 6809を使ったゲームコンソール無いよね
だから何って話ではあるが
- 338 ：
- 6809は他の8ビットCPUと比べて登場時期が遅いという商業的な致命的失敗やらかしてるからな。
- 339 ：
- >>335
> ちゃんと同一バイナリ互換な16bit CPUが出てくれば生きたろうけども
モトローラはバイナリ互換を重視しない会社だからそれはないわな
そもそもだから6809みたいな思いきった設計できるわけだし
- 340 ：
- >>335
>次に続かない袋小路っぷりがなあ
そこに究極感があるのではなかろうか
8086とかが糞の極致のイメージなのはそれだろう
- 341 ：
- コの世界、悪貨が良貨を駆逐する
- 342 ：
- AVRはさらに登場時期遅いけど普及してるからな。そういう問題じゃないんだよ。
- 343 ：
- この後及んでまだ8086の素晴らしさが分からない馬鹿がいるのか。歴史が証明しているというのに。
- 344 ：
- 頻出命令が2バイト命令でデコードサイクル中は2サイクル空回りが大半
2バイトでいいから先読みするとかライトバックレジスタ付けとけば究極だった
- 345 ：
- >>343
ここで主張するってことは
8086は8bit相当だとは認めているんだね。
- 346 ：
- >>345
その質問は340にするべきだな。
- 347 ：
- 8088を8bit扱いしていいなら命令セット敵にも最強だと思うが
- 348 ：
- ふふふ、はたしてそうかな？
68008
- 349 ：
- 68008はバスシュリンクの弊害が大きすぎて
何がなんでも68k系でなければ困る、性能低下や実効性能は二の次、という代物
- 350 ：
- 8088なら、H8の逆に、本当に内部バスやALUも8bitな本当の8bit CPUにしてしまっても、性能低下が低いよな
FPGAで組むのに8bit化して回路小さな互換CPUを作るなんてする酔狂な人居ないもんか
それならこのスレにピッタリになるのに
- 351 ：
- i8086のipはふつうにありますよね。
このスレ的にはalteraのfpga用評価基板de1とかde0がターゲットのzetが
なじみがあるんじゃんないかと。
- 352 ：
- >>335
x86を見るにつけ改良は幾らでも出来たろうね
- 353 ：
- バイナリ互換ってのはソフト資産があってこそだろw
- 354 ：
- 過去のソフト資産切り捨て強制したから見捨てられたんだよな、モトローラは。
- 355 ：
- 性能アップと省電力が出来なくてPPCやめたってのは見たことあるがそれは何の話だろうか
- 356 ：
- >>354
切り捨てたのはアップル。
- 357 ：
- >>350
外部データバスが8bitになることで8086比での性能低下はもちろんあるけど、
86系自体が元々なんというか小回りの利くアーキテクチャなんだろうな。
8bit ALUで86バイナリを解釈しながら実行するプロセッサは面白そうだな
- 358 ：
- 1984年末にはもうX1turboもFM-77もSMC-777Cも出てたのね
- 359 ：
- 8ビットパソコンは事実上のZ80か6809か、の二択になったのはやっぱりソフト資産の量なのかね？
- 360 ：
- >>359
日本のPCメーカーがその二つのセカンドソースやってたから
NECだけはインテルのセカンドソースなのに勝手にZ80互換CPU出してた
- 361 ：
- FM7系が早い段階で3MHz化していればと思わないでもない
- 362 ：
- 8088化で良かったろ
低価格16bit機を早く出せる状況だったのに無駄にして
- 363 ：
- >>362
当時のPCで互換性を捨てるのはホントに世代交代するときだけだろ？
X1→X68
FM77→FM-TOWNS
くらいの進化幅があるならともかく…
- 364 ：
- FMは77じゃなくて77AVからだと思う
無印77はぶっちゃけ産廃
- 365 ：
- >>360
このスレだけでなく何度も言われてるけど、V30(V20)の段階で80(8080)エミュレーションモードがZ80互換だったられば
- 366 ：
- インテル＋ザイログ VS NEC？
日米摩擦がより熱くなってたかもな。
- 367 ：
- >>363
FM-8からの流れで、複数CPUを積めるデザインだから
6809と8088の両方をメインCPUにできる
- 368 ：
- 6809+Z80+8088できたのはFM-11とかだろう
FM-7はZ80カードが挿せたけど、Z80カードと232Cと漢字ROMが併存できなくて3すくみになるとかだったような記憶が
- 369 ：
- MC68C09がパソコンに使えるほど量産できた事は無いのて、
HD63C09を使うしかないが、未定義命令の互換性が無いので、
互換性のためには両方積む必要がある
複数積むなら、Z80カードが出てて、
同人ハードとして8088カードやV20カードが出てたんだから、
やればやれたろ
- 370 ：
- 80年代後半でも8bitに拘ってしまったのが国内メーカーの敗因やな
PC-9801は88から上手くユーザーを吸い上げたが、黒船来航はすぐそこまで来ていた
- 371 ：
- FM-77まではZ80カードが挿せる(専用スロットがあった)らしいけど
77AVからはスロットが無くなってるのか…これは悩ましいな
82年の段階で開発機として11EXを手に入れておくのが良さそう
そこからRAM1MB + 2HDFDDx2まで拡張するのもきつそうだけど
- 372 ：
- >>370
8bitしか出さなかったメーカーは8bitに拘っていたのではなく
既に戦いに負けていて参戦できなかったのでしょう
出さなかったのではなく出せなかった
- 373 ：
- >>372
負けてもなかったような
そもそも海外のような低価格16bitホビーパソコンが出てすらなかった
1990年のMSXturboRくらいで、それでは遅すぎ
- 374 ：
- 16bitのビジネスマシンを出してるメーカーだったら価格破壊な16bitを出す気になれない気持ちは分かるんだよね
業界の後々の利益の確保なんて考えない風雲児だけが低価格高性能機を出せる
- 375 ：
- EPSON 98互換機は正義やったが出るのが遅すぎた
- 376 ：
- >>375
NECから嫌がらせ受けたから、2年くらい早くても結果は変わらないような。
- 377 ：
- でも、98にはゲームソフトが出てないのがホビーユーザーには短所だったから
安い互換機が早く出て市販ゲームが早く増えてたら…
- 378 ：
- 通産省が家庭用は8ビットで十分と計画してしまったので・・・
- 379 ：
- ぴゅう太が出てたんだから言い訳にもならん
- 380 ：
- 妄想が許されるなら、MSX2が出るときにもっとドラスティックな発展をしてて、
たとえばメインCPUに68000(互換性のためにZ80も搭載するメガドラ的構成)を積んでれば、かなり大きなインパクトだったとは思う
ただ、登場時の値段が20万越えそうだから、結局討ち死にになっちゃいそうな予感もする
- 381 ：
- >>380
いや、あの時期にそれが20万で出てたら凄え売れたでしょ？
- 382 ：
- メモリをケチって主記憶128KB(内、24～96KBはVRAM共用)
クロック周波数はZ80とHD68000どちらも3.579545MHzで駆動、簡易アセンブラ付きマシン語モニタ内蔵
FDD無し149800円、2DD FDD1基搭載で198000円くらいでなんとかなるかな？（欲しくねえ）
- 383 ：
- ホビーパソコンと言いつつ16ビットはかなりPC98に浸食されてたからな、NEC自身も含めてDOS時代にホビー用パソコンをヒットさせるのは厳しかろう。
為替レートのおかげでDOS/Vが(日本円では)比較的安価に手に入るように成ってなければ日本はズーとコンシューマ機の天国だっただろう。
- 384 ：
- 98なんてホビー用パソコンだろ
- 385 ：
- まともにホビーパソコンとして98も使われてたなら、
もっと早くCD-ROMが普及してたわ
- 386 ：
- アクションゲームに若干不向きなだけで、RPG、SLG、ADVあたりだったらPC98で万全というか最先端なんだよなぁ
15万か20万でホビーマイコンの新機種だそうとしても、PC98中古と比較されたときにそれを振り切れる魅力あるかというと・・・
MSX2は29800円路線で正解だと思う
- 387 ：
- >>385
？？？
CDROMが普及してないとホビーパソコンではないと
- 388 ：
- AT互換機はホビー用途でもっと先に普及してた
サウンドブラスターに安いCD-ROMドライブ繋げられて
相対的にホビー用途での利用者数の多さを表してた
- 389 ：
- 1988年頃はもうPC-9801と88mkIISR勢が主流になってた
ここに他の機種が食い込むのは容易ではなかった
X68000とFM TOWNSはNEC系とユーザーがあまり被ってなかったから多少生き延びられた
- 390 ：
- CD-ROMが普及するのは90年以降やで
そもそもCD-ROMを使いきるようなコンテンツも無かった
- 391 ：
- CD-Rが出るまではCD-ROMドライブは人気なかった。
CD-RはMOと比べても安価なバックアップメディアだから売れた。（ナニをバックアップするかはともかく
HDDをI/Fボードごと買い替える時代だったから古い（小さい）ドライブから新しいドライブへデータ移すのにCD-R経由でやろうっていうユーザが多かったのもあるだろう。
「ついでにバックアップにもなるし」っていう理由もあっただろうし。
なんでかSCSIのCD-Rドライブが売れてたな。
- 392 ：
- MOやPDにはお世話になったなぁ
波動がゆんゆんと漂う感じだったけど
- 393 ：
- >>391
CD-Rが普及し始めたのは90年代後半でメディアが1枚千円切ってきた頃からだろ
当時はATAPIがまだ標準化してなかったから実質SCSIしか選択肢はなかった
イメージ作成用にHDDに1GBくらいの空き領域、できれば連続した領域が必要だったけど当時の大容量HDDか2GB程度だったから
CD焼き専用に1GBくらいのドライブ1台付ける人も多かった
そんな調子だったからHDDのデータ移動にわざわざCD焼く人なんていなかった
- 394 ：
- >>393
普及したの90年代後半・・・？
CD-R/RWと勘違いしてたりしない？
もしかしてPC98シリーズが9821になってCD-R(RWだったか？）を標準装備したから「普及した」ってことになるの？？
それとも95年には3代目のドライブ使ってた俺って、普及する前から使ってたってことか？
俺の周りはPCマニアというかPCオタクが多かったが93年ぐらいからCD-Rドライブ使い出して95年には持ってないほうが珍しかったからてっきりそれが当たり前だと思ってたわ。
- 395 ：
- AT互換機のDOS環境で98より優位な前提で話する奴は90年代半ば以降、95年±2年くらいの話してる
93年頃はハイエンドがWin3.1になってようやく使い物になり出した頃
まだDOSで一太郎とLotusで使ってるユーザーが主流
97年に入るともうWin95が当たり前で、今更DOSかよまだ98使ってんのかよって世相
VM21互換の98環境は1990年±3年くらいが黄金期
- 396 ：
- 俺も92～3年頃には98のDOS環境でCD-ROMドライブ使ってたけど
これはHDDがSCSIだったのでCDROMドライブの増設が楽だったというだけ
93年に486のAT互換機を組んだけど、CDはIDE(ATAPI)ではなくサウンドブラスター16につなぐいわゆるミツミドライブ
これ安いから普及しまくったけど後で要らなくなっても切り離す手段がパターンカットしか無くて、使わなくなってもI/O占有し続けて後のplug&playを妨げる元凶の主犯格という難物だった
- 397 ：
- >>394
勘違いしてるのはお前だ
- 398 ：
- CD-RWが出たのは90年代後半だもんな
- 399 ：
- >>394
一部のマニアが付けてる事を普及しているとは言わない
- 400 ：
- アニメで言うとどのあたりの時期に普及したんだろう？
セーラームーンとかマリーベルとかヤダモンとか姫ちゃんのリボンとか、そのあたり？
- 401 ：
- 92～94年頃のTOWNS以外のCDROMの普及はそもそもコンテンツ不足で、
Windows3.xやMac向けにshockwaveでオーサリングしたクソみたいな3Dアニメ紙芝居が偉そうな価格で売られていた程度
あとは電子辞書や図版入りの百科事典くらいか
フリーソフトの収録CDが書籍扱いで出るようになった頃にはWin3.1だったと思ったし、その収録ソフトもDOS用が主体
初期の386BSDやLinuxの回覧は、泣く子も黙るフロッピー50枚組みとかだった
- 402 ：
- パソコン雑誌の雑誌付録は95年には既にCD-ROMだったがなぁ。
普及してなきゃそんなことしないで、付録付けなくするだけだろ。
- 403 ：
- 「ぼくが持ってなかった時期に、普及しているはずがない。」
「ぼくが買えたのが〇〇年。だから、この年が普及元年。」
いつものガキオヤジ・ロジックだろ
- 404 ：
- 80年代後半～1990年くらいだとFD数枚で済んでた時代でまだCD-ROMは不要
TOWNSは野心的だったが、88MCでは結局無用の長物になってしまっていた
だからこのスレ的にもあまり実りある議論にならない
- 405 ：
- 百科事典は重要コンテンツだったが、
普及原動力はエロビデオCDだろ
- 406 ：
- >>405
VHSビデオデッキが普及した一因もエロビデオだからな
やはり下半身に訴求するのが最短ルートだな
- 407 ：
- OS/2使いだったオレ、雑誌のCD-ROMにお世話になった。
OS/2マガジン以外だとソフトの入手が面倒な田舎者でなぁ(今はソンナコトナイけど)
20世紀は「三軒、家が並んでたらマチと呼ぶ」レベルの田舎で、雑誌付録のCD-ROMはありがたかった。
- 408 ：
- 88VAの互換性が高ければ勝てた
- 409 ：
- 雑誌付録にCD-ROMはあれがアレした事が大きかったようにおもう
3.5インチFDも付属して良いようになった付録に金属がどうたらっていうアレ
- 410 ：
- 3.5インチだと金属シャッターは書籍扱いには付録にできてても、
雑誌扱い付録は炭素繊維シャッターじゃなきゃ無理だってのな
雑誌は再生紙化できないと
- 411 ：
- >>402
CD-Rだった？
- 412 ：
- >>403
俺がCDRドライブ買ったのはCDRメディアが3000円くらいになった頃だけど全く普及はしてなかったぞｗ
- 413 ：
- そもそもFDは１枚１枚書かないと駄目だけどCD-ROMだとCDと同じ設備で大量生産可能だから発行部数の多い雑誌だとCD-ROMしかない
- 414 ：
- >>403
ガキ・ロジックは正しい。ガキは貧乏だからな。ガキが買える頃は普及期。
- 415 ：
- オッサン・ロジックでは80年代には8bit機でC言語での開発は普及してたらしいからな、ｱｳｱｳｳｰ君によるとw
当時のマイコン雑誌の記事で全否定されたけどw
- 416 ：
- c言語の普及を否定してる当時の雑誌の記事なんてひとつも出てこなかったようだけど
- 417 ：
- >>416
> インターフェース誌によると、8bitCPUにはアセンブラが有用であり(86/5 p200)、
> 8bitCPUでCはまだそれほど普及していない(86/6 p221)という記事
いきなり全否定で妄想オジサンかわいそうと思うけど、インターフェース誌の86年6月号の221ページだってさw
- 418 ：
- >>417
それデマみたいよ
- 419 ：
- インターフェースなら組み込み雑誌なんだから組み込み開発の話だしな
パソコンアプリの開発とは別なんだから、どうだろうが意味が無い
- 420 ：
- さぁ、ｱﾘｴｰﾙ君、ｱｳｱｳｳｰ君の捏造座談会が始まりした。
- 421 ：
- >>420
早速否定されて悔しかった？
- 422 ：
- 捏造ﾌﾞｰｲﾓ君登場です。盛り上がって参りました。
> インターフェース誌によると、8bitCPUにはアセンブラが有用であり(86/5 p200)、
> 8bitCPUでCはまだそれほど普及していない(86/6 p221)という記事
> それデマみたいよ
ブーイモ君がウラを取ったようです。さて彼の画像upを待ちましょうw
画像加工に時間がかかるので少しお待ちくださいw
- 423 ：
- >>422
悪魔の証明って奴？
- 424 ：
- ページ数指定で簡単にウラとれる。デマと本人は言ってるんだからウラ取りしたのでしょう。
してなかったら大変なことですよ。
風説の流布ですよ。インターフェース誌に訴えられますよ。
- 425 ：
- 普及してないと、当時のC言語記事の第一人者がそう言ってるからな。そうなのだろう。
後はCDROMだな。メジャーなパソコンが標準搭載してからが普及期だと思う。つまりPC98だ。
- 426 ：
- CD-ROMはPC/AT互換機が先じゃね？
だいたい8bit機にはCD-ROMの扱いは重すぎる
PCエンジンは例外だしそれも1990年以降だな
- 427 ：
- CD-ROMはMacが一番普及が早かったような
スレチ
- 428 ：
- C言語の記事は他雑誌にもあるにはあったが
大体入門用のお勉強記事で実用的なもんはなかったような
文字だけ扱ってればいいような手抜きソフトくらいでしか使いみちがない
- 429 ：
- C言語ネタはここ↓行ってやってくれないだろうか？
長々とグダるのでｗ
8ビットCPUでC言語？ないないありえないっしょ！ 4
http://matsuri.2ch.sc/test/read.cgi/i4004/1532613479/
- 430 ：
- >>426
出始めは1倍速だから、別に重いなんて事もない
データも遅さに見合った軽さじゃなきゃ、ロードに時間がかかりすぎるし
- 431 ：
- 捏造隔離スレだしな。ここで捏造合戦は勘弁してもらいたい。
しかも雑誌を名指しで記事内容をデマとかシャレになってない。
- 432 ：
- CDROM普及はWindowsから。ハイ終了。
- 433 ：
- Windowsのバージョンいくつだろうね
3.1は大量のFDでインストールした覚えがある
- 434 ：
- Windows3.xプリインストールのデスクトップ機は、構成をよほど切り詰めない限り等速～倍速くらいのCD-ROMドライブ搭載が相場だったような
386末期～486全盛期
CD-ROMドライブはMacが普及させたとか無い
MacやAppleには市場を左右できるほどのシェアなど無い
いつもの安定の捏造史観
- 435 ：
- Win3.0が91年(日本語版は3.0A～)、3.1は93年。リリースがこうなので実際にユーザーが増えて来るには半年かそれ以上かかる
いや俺はいつも発売日ゲットだったから違う等とほざく時点でそいつはマイノリティ
- 436 ：
- ＞CD-ROMドライブはMacが普及させたとか
「が」じゃないよ「では」だよｗ
Macユーザ内「では」だよ
そういう意味ではTownsユーザは100%普及と言えるが
- 437 ：
- 優良錯誤をねらった文言を並べ、それを指摘されると相手の責任に転嫁するのがマカー論法。
ウソがバレるとウソついた個人が悪いのであってアップルやマックに非はないと言い残しては消える
まあまたすぐ（いくらでも）仕切り直して現れる訳だが
- 438 ：
- 製品出た時期とか、OSをCDで配ったとか
いやそれは普及したことにならないとか
読み方でどうとでも取れるしね
はい、すいません
＞まあまたすぐ（いくらでも）仕切り直して現れる訳だが
はい
アンチ心に火をつけてしまったのだろうか？
- 439 ：
- 4倍速ドライブあたりが普及期じゃないのかね
個人的にはWindows3.1とWindows95の間あたりの記憶
- 440 ：
- >>439
体感としては、一番効いたのはやっぱり倍速になったときだったな
シークタイムと転送速度の両方が高速化してたから、感覚的には倍どころか三倍とか四倍に感じた
ネオジオCDも最初から倍速CDを積んでれば案な悪評もたたなかったろうに…
- 441 ：
- >>439
95年位にパソコン屋にいたけどCD搭載機は標準が2倍速で上位機種が4倍速って感じ
2倍速のPCをプラス1万円位で4倍速に換装サービスとかやってた
プレクスターが選別品で作った6倍速とか出してた頃
- 442 ：
- AT互換機では1991年のWin3.0とSound Blaster Proとミツミドライブとの定番組み合わせだな
エロJpegを見るのに普及と
日本ではアニメ絵のエロだからフロッピーで十分だった
- 443 ：
- 正に「Shockwaveでオーサリングしたクソコンテンツ」が横行していたという訳だな。
動画はRealPlayer。
320x240とか、下手をしたら240x180くらいの、切手かよ…ってサイズの。
- 444 ：
- >>441
95年夏モデルで一番廉価タイプのFMV-DESKPOWER一体型(実売16万)を買ったけど、内蔵CDドライブは四倍速だったよ。
メーカー毎で色々違うのかもしれないけど。
- 445 ：
- CD-ROMが普及した時期は兎も角、8bit機にCD-ROM必要かい？
FD1枚に余裕で収まるメモリ空間しか無いのに
16bit機ですらCD-ROMは必要とされて無かったのに
- 446 ：
- >>444
夏モデルで4倍速が標準になったのかもしれないねぇ
>>445
メモリが少ないからこそ、外部に無限の領域が欲しい気もするけどなあ
紙芝居ゲームなんかはCD-ROMから読んでいれば8bit機でもいけそうな気がするよ
- 447 ：
- >>444
IBMだね
富士通はついてたかもしれない
acerで作ってた安かろう悪かろうの時代だな
- 448 ：
- CDだと音楽を自前音源で処理しなくていいからあるだけありがたい、とか。
なんかインポーズするようにしとけば動画も8bit機でいける。
がなんでわざわざ8bitでやってるのかだんだん分からなくなってくる。
- 449 ：
- 「究極」の考え方次第だけど、なんでもかんでもごてごてつければいいわけじゃない、
というあたりがCD-ROM要らない派の意見だと思うわけです。
>>448は要らない派に行く分岐点みたいなものですね。
個人的には＋αがないとさびしいけど、動画の表示のようなところまでは
期待していないので、単なる高速テープ扱いでいいんじゃないの？派
- 450 ：
- 早送り巻き戻し再生がコントロールできるカセットが付いてれば十分って事だな
- 451 ：
- PC-8801MCという大失敗機もあるし
- 452 ：
- MCはTOWNSに対抗するベースとして選ばれたんだろうが、88最期のあがきというかNECもやる気なくてテキトーなのがまるわかりだよ。
メインストリーム？の98は社内政争があったんだろう、9821の企画が持ち上がってただろう時期の98FAという駄作。
PC88はMA／FA、PC98はRA21(51でもいいけど)までがNECの絶頂期だったと、今でなら言えるｗ
- 453 ：
- 8ビットPCでCD-ROMなら、OSにMSX-DOSのようなDOS互換のファイルシステム持たせてISO9660に対応させる。
PCエンジンなどの家庭用ゲーム機でやってたような、オーディオCD使ってトラック１に警告音声メッセージ、トラック２以降にデータというのもいいんじゃないかな。
CD-ROMなら12㎝で650Mとか700M、8㎝で210Mなんだし対応すれば使い道は広がるでしょ。
- 454 ：
- PCエンジンをベースにしたパソコンって
いい感じにならないの？
- 455 ：
- >>454
良い感じだと思うのだが、それを主張するとマカー呼ばわりされて話が進まない
- 456 ：
- >>454
コア構想で実現性は高かったんじゃね？
キーボードは子供のころに玩具ショーのニュースで映ったのを見たことあるので、モックレベルでは存在した＝構想としては存在した、はず。
FDDも88FHの2Dドライブか88MHの2HDドライブを流用すれば・・・
あとはHuCARDにBASIC書いたROMとワーク用のRAMを提供すればファミリーBASICよりはマシなPCモドキになるとおもう。
- 457 ：
- >>454
PC化はメーカーにとってリスクしか無く、メリットが全く無い
ゲームで遊べれば良いなら、ゲーム機のままで良い
特にPCエンジンは、CDROM2でもメモリが少なすぎて話にならない
メガCDでさえPC化する意義が無かったのに
マカー扱いされるとか被害妄想も大概にしろ
単に馬鹿だと指摘されるとされているだけだ
- 458 ：
- 紙芝居専用のユーザーを舐めたハード支援のないマシンもあったな
- 459 ：
- 動画はインポーズすればってのも意味不明だな
なにかPCの外部で勝手に読んで伸張してくれるものがあるとでも妄想しているのだろうか
それもうCD-ROM単体の話ではなくなるよね
少なくともその動画インポーズ？処理用のハードウェアだけで8bitPCのロジック規模を超える
バッファRAMも64KB以上搭載とかだろう
動画伸張エンジンの世話をするマイコンが32bitなんて事にもなりそうだ
8bit機本体より高性能で、RAMも大容量な外付けの動画エンジン
- 460 ：
- 専用ハードなしではmpegもmp3の再生も無理、jpeg展開も数分の6502にCDROMつけてなにを保存するの？w
- 461 ：
- CD再生ディジタルフィルターがすでにZ80数千個分の演算能力持ってるんだからちょっと使わせてくれよ
- 462 ：
- PCEの実機動作環境がCDってのは利点よねPCだけで開発できる
- 463 ：
- 88MCはCD-ROMの大容量を活用できる機能が本体になかったことと、それが原因で対応ソフトがないって状況から失敗作になりさがったわけだが、
8ビットPCでも単純にCD-ROMのような大容量メディアが読めるってだけで意味があると思うんだがねぇ。
MSX2+にCD-ROM付けてIS9660読めるようにしたらどうなんだい？
X1ターボZIIかZIIIにCD-ROMつけてC-DOSIIで読めるようにしたら？
そこまでやれば88MC のような酷い失敗作とはならんだろ。
商業的な成功は望めないがｗ
- 464 ：
- >>457
CD-ROM2でもって、最低限の最初のハードであって、パソコン用なら最大限に拡張しても良くてよ
メインメモリSRAM64Kバイト＋ADPCM用DRAM64Kバイトが少なすぎるなら、
SUPER CD-ROM2のメインメモリSRAM256Kバイト＋ADPCM用DRAM64Kバイトで良いんだし
メインメモリはDRAM2Mバイトの拡張もされてたんだし
SRAM256Kバイト＋DRAM2Mバイトのメインメモリで少なすぎるパソコンって言われるのはハードル高くないか？
- 465 ：
- >>459
当時はレーザーディスクのアナログビデオをスーパーインポーズして背景画面にするゲームも有ったんだよ
MPEG1を再生するビデオCDプレーヤーが有ったから、ビデオCDプレーヤー兼用CD-ROMドライブを繋ぐ形にすれば、
ビデオ動画を背景にしたゲームは成り立つ
周辺機器の方がパソコン本体よりも高性能な部分があるのは当たり前でもあるし
CD音声を8ビットCPUで直接扱うのが無理な以上は同じだ
- 466 ：
- もうパチンコ台みたいなハード構成にすればいいじゃん
- 467 ：
- >>460
え？普通に非圧縮の画像データ入れればいいじゃん？逆になんでこんな話題でMP3やJPEGが出てくんの？
別にどっち派でもないけど、君の叩き方はおかしいよ
- 468 ：
- >>467
データ圧縮は保存容量を減らすだけじゃなくてデータ転送量を減らす意味も大きいからな
- 469 ：
- >>467
で？
- 470 ：
- >>469
何が言いたいの？で、しか言えねえんなら黙ってれば？
- 471 ：
- >>468
そうね。なんらかの圧縮はした方が良いよね。ただ8ビットCPUでCD-ROMって話をしてるときに、MP3だとかmpegだとかjpegだとかトンチンカンな事言い出す、>>460 はアホだなあって思う
- 472 ：
- >>470
は？
- 473 ：
- >>471
6502の性能をリアルで知らないアホは黙ってたほうがいい。
- 474 ：
- CDROMに非圧縮の画像データ入れるのか。6502を使ったことないんだなw
- 475 ：
- 8bit機ならVRAMだって、せいぜい64kBだろ（320x200x256色）
CD-ROM 600MBなら無圧縮でも9000枚以上入る
圧縮必要ないだろ
- 476 ：
- 8bitパソコンにCD-ROMなんて
PC-Engineのシーディーロムロムみたいな話になってきてるねｗ
あれはあれで需要があったよね
- 477 ：
- CD-ROMはマスクROMと違って再販がしやすいからソフトメーカーにとってはメリット大きいよね
- 478 ：
- 静止画なら無圧縮でVRAMにDMA転送って楽して良いだろ
- 479 ：
- >>468
それは伝送路の圧縮でよいのであって、mp3やjpegみたいなめんどくさい圧縮を使う意味はないだろ
- 480 ：
- >>477
コピーされ易くなると言うでかいデメリットがあるけどな
- 481 ：
- >>479
なぜjpegが作られたと思ってんだよｗ
- 482 ：
- バス速度がどの程度になるかわからんが、どうせ8ビットバスだ、転送レートなどたかが知れてる。
小細工が必要なJPEGやMP3など使わずに単純な構造のデータを使ったほうがいい。
画像は256色BMPだろう、ソフト負荷的に。
しかし、ハードウェアデコードするならぶっちゃけ何でもよい。
オーディオはオーディオCDをドライブが直に鳴らすならMP3は要らない。
MP3のようなソフト負荷が（それなりに高い）形式つかうぐらいならWAV形式のほうがマシだろう。
しかし、ハードウェアデコードするならぶっちゃけ何でもよい。
- 483 ：
- PC-Engineはのシーディーロムロムはどうしてたんだろうね
- 484 ：
- 8bitでなんかやる、っていう議題が無理スジなお楽しみスレで
「それは無意味」「それは無理」「意味ない」
って言ってる『否定クン』の存在って何
- 485 ：
- 否定できる俺スゲー君の精神安定剤なのでスルーでいいかと
- 486 ：
- SFでさえ最低限の科学的根拠の説明があるのに、技術的な説明が碌にないから全否定されるんだよw
CDROM内の無圧縮画像を6502で表示だって？w
- 487 ：
- PCエンジンなんてゲーム機ですら出来る事をDMACだろうがブリッタチップだろうが積めるパソコンでできない方が説得力ない
2HDフォーマットにもDMA使うのにCD-ROMには使わせないって話の方が変
- 488 ：
- >>486
「なぜできないのか？」の一言もなしにただただ否定するだけのあなたも同じレベルですよｗ
- 489 ：
- CD-ROMでDMAってw
- 490 ：
- １倍速でも150kB/s (1byte/6.7μs) だから8bitだとCPUでの転送はかなり苦しい
- 491 ：
- PCエンジンだとCD-ROMからのAD-PCMにDMAを使ってて、
対象をAD-PCM用DRAMだけじゃなくVRAMにもできてた
- 492 ：
- CDから直接VRAMへ、か。それなかなかイイね。
表示処理中にCPUが別なことできるのはイイよ。
- 493 ：
- >>467
圧縮データを展開せんと表示出来んがな
jpeg出てきたのは90年くらいだし当時のターゲットマシンは68030Macやで
それくらい計算量的に重たい処理なので、単体のZ-80Hとかでも無理くさい
(jpeg表示に時間かかっていいなら…)
jpegは人間の視覚の錯覚を利用して色を散らす必要があるので、最低256色出力出来ないと綺麗な表示にならん
今の感覚で考えない方がええし、80年代末期に8bit CPUに何でもかんでも機能追加しても重くて使いものにならんかったから滅びたんやで
性能は今のPICやAVRより低いんや
- 494 ：
- もしゲームパソコンみたいなのを想定するなら68000 10MHzでもギリギリの処理かな
8bitに計算量やデータ転送量が必要となる処理は載せても使い物にならんよ
- 495 ：
- >>493
> 圧縮データを展開せんと表示出来んがな
だから「非」圧縮でっていう話なんだが…
JPEGの仕組みとかはざっくりわかってるからいちいち説明しなくていいよ
- 496 ：
- CD-ROMドライブを音声端子経由で接続してﾋﾟｰｶﾞｰしとくのはどうだろう？
- 497 ：
- スーファミのCDドライブ付きマジコンで全タイトルが１ＣＤに入ってるやつあったような
そんな使い方もできる
- 498 ：
- PCEはBGとSPなんだから8MHz6502といえどMPEGで動画なんぞ元々無理
- 499 ：
- 8bitPCだと、実在機で最速と思われる88系の8MHz機でも
等速150KB/secの読み取りで処理がほぼ飽和するよね。
バッファRAMとI/O処理用のマイコンを搭載したインターフェイスカードでも介在させて、データはDMAでやり取りするか。贅沢だなあ
本体側のCPUでPIOで転送してたら、本当にただ「読むことはできる」だけだな
読みながら何かをすることは無理だ。
- 500 ：
- メモリバスの転送帯域とか全く考えられないゲームキッズなんだろ
CD-ROMでスーパーインポーズとか言い出すし、CDに動画機能なんか無いと指摘されるとLDの動画と重ね合わせると言い出すし、挙げ句の果てに1フレーム64KBの画像を無圧縮で転送すれば動画機能になるなどと
等速で毎秒150KB、3フレームにもならない
150KB/secの読み取りでCPUは飽和するのに、さらにVRAMに書けという
しかも64KBしかメモリ空間が無いのに1フレーム64KBのパックドピクセルVRAMを処理しろという
もう何もかもデタラメだ
- 501 ：
- >>500
ビデオCDって動画が入ってるんじゃないの？
- 502 ：
- PCE系のホビーPCというのは技術的にはそんなに悪くない気がするが、
問題は88と技術の系統が全く違うことなんだよな…
そっちがヒットしたとして、「じゃあ88はどうするの？」という問題が発生して、66の二の舞いになってしまう。
もっと88に近い技術を使っていれば、88が飲み込んでしまうこともできたかもしれないが、
さすがにPCEを88に統合するのは無理筋すぎる。
- 503 ：
- >>501
VideoCDに入っているMpeg1動画を伸張するために必要な機能と性能を列挙してみよう
- 504 ：
- 「伸張処理が重すぎるから無圧縮にしよう、Jpegについては理解しているので、今更細かいツッコミは不要だ(ｷﾘｯ」…ってのもすごいな
誰もツッコミ入れてないのもすごい
すごすぎてツッコミの入れようがないというやつか
- 505 ：
- >>503
ビデオCDプレイヤーに入ってる、で良いよ
液晶ディスプレイに入ってるとか周辺機器の機能を一々上げてもキリがない
- 506 ：
- 動画コーデックの事詳しい人ってそれほど居ないんじゃないの代わりにツッコミ入れてたもれ
- 507 ：
- >>505
もう一度最初から、今度は日本語で書き直してくれ
無理なら英語でも構わんが、それ以外の言語は読めない
- 508 ：
- 動画コーデックがどうこう以前に、CDから読み取ったデータがどのような経路で伸張エンジンまで運ばれ、伸張された各フレームの画像がどれだけの帯域で、それがVRAMに運ばれる経路と帯域はどれだけ必要なのか
という算数ができない奴が、インポーズだのビデオCDだの言ってる
彼のぼんやりした妄想の世界では、データは突然湧いて出たり、必要に応じて跡形もなく消えて目的地に移動していたりするらしい。
それらの経路や収支から移動させられない、そもそも読み込みに追従できない・書き込みが追いつかないといった指摘があってもその意味を理解できないので、
「とにかく何でも否定するやつら」からのイチャモンとしてしか認識できないのだろう。
自分がどれだけ無根拠な妄想を並べ、あまつさえそれで他の意見を遮ったり、愚弄しているという認識自体がないのだ。
- 509 ：
- >>507
そうやって都合の悪い書き込みは読めない素振りをしだす訳だ
悪い癖だぞ
- 510 ：
- ＞ 悪い癖だぞ
w そんなにはっきり言わなくても・・・
MSXでもパイオニアが出してたレーザーディスクの出力をインポーズして
自機だけスプライトで描くシューティングとかあったじゃんね
あと最近スマホ版が出た？タイムギャルとかもビデオ画像インポーズじゃね？
- 511 ：
- >>509
動画の伸張機能を持たないCD-ROMドライブ単体では再生することのできないビデオCDの動画を再生するために、追加で必要となる機能と性能を列挙しろ…という命題に対して
「ビデオCDプレーヤーに入っている」
「液晶ディスプレイに入っている」
「周辺機器の機能を一々上げても(原文ﾏﾏ)キリがない」
等と書かれても、日本語のような単語が並んでいるだけで、文章として意味をなさない。
- 512 ：
- (ﾌﾞｰｲﾓ) 飛ばしてんなあ！ ぶんぶん！
- 513 ：
- LDの動画はNTSCのアナログ信号をそのままPWMで記録しているもので、出力に際してCPUは介在しないし、動画データがデータバスを通る事もない
- 514 ：
- ストレージでDMA転送ってFDDやHDD、MO、CDでやってる機械がすでにあるから否定するもんじゃないだろ。
83年スレとちがって予算縛りないんだしいくらでも豪華な周辺つけたってかまわんはずだ。
実現するデバイスを可能な限り使ってればｗ
否定だけしたい人は専用スレがたってるようだし、そっちでひとりごと呟いててくれよ。
- 515 ：
- >>511
スーパーインポーズ付きのVIDEO CD再生コントローラつければいいだけじゃん
そもそも CD接続するインターフェース、コントローラすら定義されてないのにｗ
- 516 ：
- 本体より強力なサブCPUとしてハイエンドPC相当の構成を並べるやつはスレ荒らしと認識されていたように記憶しているのだが、
後付けで何でも付ければいいだろホイ論破ｗｗｗｗってのはもう、口先だけでも勝とうとして自ら退場して行くアホだろう
口先すら勝てないのがお前ら、正にお似合いの末路だな
- 517 ：
- それでは将軍様、無改造PC-ENGINE CDROM2にて、拙僧が用意いたしましたこちらのmpeg1ビデオCD「四畳半襖の裏張り」を再生して見せてください。さすればたちどころに論破されて見せましょうぞ…!!
- 518 ：
- 今考えてみると、FM-TOWNSのDAPS系ゲームをPCEに移植して動かしたデータイーストは、地味に技術力あったのかもな
さすがにフル画面じゃなかったが、推定160x120くらいの解像度で動画を動かしてたし
- 519 ：
- >>511
「ビデオCDプレーヤーに入っている」
だけで、一つの文でしょ
これが分かれば十分
受け答えとして>>503の、
＞VideoCDに入っているMpeg1動画を伸張するために必要な機能と性能を列挙してみよう
に対して、ビデオCDプレーヤーというVideoCDの再生ハードを挙げて、使えば良い、ってだけ
全て入ってるから再生されてる映像信号だけを受け取れば良いって事
音声は同じくプレーヤーで再生して音声だけ受け取る動作も有るでしょ
やってる事は音声信号と映像信号との違いなだけ
- 520 ：
- まあ8bitじゃないけどレーザーディスクの画像の上にテキストをスーパーインポーズするボードは作ったことある
一時流行ったレーザーディスクカラオケの歌詞を入れる装置みたいな奴（英語の学習機器だったけど）
デジタル側の処理はμPD7220使ってたから8bitでもできると思う
- 521 ：
- >>517
現実の8ビットゲーム機スレを立てて、そっちでやってね
- 522 ：
- やれるものならやってみろだが、おれ熟女モノでは抜けないんだよね…
CDロムロムにビデオCDプレーヤーを貼り付ければ再生できるんだろ？是非やって見せてくれよ
過去スレでスプライトキチガイ除けに8001にファミコンをガムテープで貼ったの渡して追い返すって話もあったな
同じ奴の匂いがする
- 523 ：
- 本気で「横にビデオCDプレーヤーを並べてガムテで貼れ」という話になっていて俺は
- 524 ：
- 最初のころはメガドラのメインCPUはZ80、68000はサブCPUって言い張るようなのばかりだったからなぁ・・・
そんなのはダメと言われるのは当然だわなぁ・・・
でもインテリジェントなドライブを禁止するのとは別だよなぁ・・・
そこんところがわかんないのは否定だけの人ぐらいだろうなぁ・・・
- 525 ：
- LDの再生コントロールやテロップ入れるくらいならMSXでできるけど
それは「MSXが動画の再生(伸長)機能を持っている」とは言わんしなあ
MSX2(+DOS2)ならSCSI経由でCD-ROM媒体も読めるが、本当にただ読めるだけで恐ろしい遅さだし
- 526 ：
- 行き着くところまでいくと、
「ここに6809とMMU、それにメモリ1MBを積んだメインボードがあります。そこにPCIe変換チップを経由して、現代の技術で作られたGPUを接続します」
みたいな話まで可になっちゃうしなあ
実際に作ったと言われたらロマンだし全力でリスペクトするが、
かといって妄想をあれこれ披露するスレでこの手の話を始められると白けてしまうのは否めない
- 527 ：
- 88MCにmpeg1デコードカードを挿して再生とかも、実現する奴が居たらアホだなあ(褒め言葉)とは思うけど虚無感しかない
- 528 ：
- 頭ごなしにただただ否定するから白けるだけさねｗ
- 529 ：
- 話の流れとしては、大きく脇道に逸れてただけだしな
>>448の
＞がなんでわざわざ8bitでやってるのかだんだん分からなくなってくる
が大元で出来ても8bitでやる事かどうかなのに、できないって逸れてただけであって
- 530 ：
- 否定されるような事しか言えない自分を顧みた事は無いのかって話
まあ無いからこそ、歳だけ取って頭はガキのままなのだが
- 531 ：
- >>526
CD繋ごうって時点で仕方がない
SCSIドライブなんて絶滅したしSATAドライブを8bitで直接ドライブなんて現実的じゃない
そうすると数MBくらいのバッファを持ったCD用コプロセッサをつないで
一旦バッファに読み込んでから後でDMAとかでメインメモリに転送すればいい
- 532 ：
- まあ最低限度、右から左へ渡すだけでもメインCPUのデータバス経由でデータが移動しないものは、「処理した」とは認めたくないね。
- 533 ：
- >>532
処理しなくてよい周辺機器はありがたい、って処理しない話から始まってますし
- 534 ：
- >>533
？？？？
そもそもCD-ROMについてアホな事言い出したのは>>385
自分が参入したのが「処理しなくてよい周辺機器はありがたい、って処理しない話」からだとすると、
追い詰められた挙げ句にビデオCDプレーヤーを横に並べれば良いみたいな話まで行ったアホとの整合性が取れるな
語るに落ちるとは正に
- 535 ：
- >>534
その横に並べれば良い話の方が、良く分からん
横に並べてもフレーム単位での選択ができないだろ
ビデオディスクプレーヤーも、パソコンからどの画面を出すとか再生とか逆再生とか操作できるからゲームが成り立った訳で
- 536 ：
- 俺はISO9660が読めれば～から参入ｗしてるが・・・
読むだけでも大容量メディア読めたら何かに使えて便利じゃね？ってノリなんだわｗ
オーディオCDの「どのトラックを再生するのか」の制御をして実際に音はハード（ドライブ）が再生する仕掛けでいいと思うんだよ。
PCでもゲームやら百科事典的なソフトのなかにはそういう使い方してるのもあるわけだし。
「サウンド再生が制御できる」で割り切ってしまえばそれでおしまいだろ。
ビデオCDだってドライブからの出力をインポーズ表示するのが、できないよりできたほうが良いだろうに、なんで否定するかねぇ。
- 537 ：
- そういや昔単体でVCD再生できるCDドライブがあったな
- 538 ：
- 色々と遅すぎて2DなFDDからの読み込みが間に合わず
2Sになってしまった悲しい機種が生まれるくらいには
当時の8bitなCPUの性能って余裕なかったという
（というか、間に合うことが売りになるCPUがあったり）
- 539 ：
- まずデータバスの帯域があってその上にメモリの速度、さらにPIOならI/O命令の実行速度(実行クロック数)がある訳で
8bitCPU縛りならバス幅とひと掴み分のデータ量は固定だから算数の計算も楽だが、それすらもできないガキオヤジが妄想ばかり逞しくする
- 540 ：
- HDDでも8bitCPUがボトルネックになるだろうw
周辺ハードでなんとかしようというPCエンジンの方向ってw
もう究極の8bit機ではなくて、究極のCPU縛りスレでええやん
- 541 ：
- HDDだと最低でも数MB/sだから8bitだとメモリーのバンド幅を使い切るレベルだな
- 542 ：
- 8ビットパソコンがファイル読むだけで他に何もできなくなるシチュエーションってなんだ？
そんなデカいデータを連続して読み続けなきゃいけないと言う想定がおかしいって事に気付けないのがそもそもおかしい。
お前ら、8ビットパソコン使ったことないだろw
- 543 ：
- んー キミら8bitどのへんからなの？
(ヤフオクで中古を買ったとかはナシで
俺は初代PC-6001を出てすぐ買った。1981年12月ぐらい。もちろん定価。
なお、カセットテープのロード中はロードが終わるまで何もできなかった。
右上に＊が点滅する。
ドアドアは、ロード中に画面動かしていてびっくりした。
以上。
- 544 ：
- >>542
CDを読み込む処理手順を考えてみろ
- 545 ：
- 88みたいにサブCPUの載ったI/Fに丸投げできない環境では、CDやHDDどころかフロッピー読むだけでビジーだよね。
- 546 ：
- うん、544が俄ユーザなのは解った。
否定派は否定したいだけの嘘付き野郎ばかりってことだわ。
- 547 ：
- つか8bitにそんな重たい機能付けても使えんだろ
X1turboZIIや8801MCの二の舞や
- 548 ：
- >>525
MSX2のV9938にはカラーバスの入力ピンがあって、CPUやメモリバスを介在せずにキャプチャ用の映像信号を入力できて、任意のタイミングでscreen8(256x192x8bpp)へ静止画としてキャプチャできたけど、これですらも10FPSも無かった。
もちろん、画像として引き出せるのは256色の静止画1枚だけ。
60KB「も」ある画像なんて、VDP内でコピーしても数秒かかるし、狭くて遅い8bitバス経由でフロッピーやHDDに退避/読み込みしようものなら数十秒も掛かるという代物で。
…ええと、mpeg1動画だったっけ？数Mbpsの。はは、ヨタ話にしても剛毅な話だねえ
- 549 ：
- >>502
88VAやPC-FXがもっと売れていたら歴史は変わっていたのか(笑)
- 550 ：
- >>548
スーパーインポーズってRAMにコピーしたりしないんだ
映像だけ重ね合わせ処理してRAM使わない
- 551 ：
- >>543
>>ドアドアは、ロード中に画面動かしていてびっくりした。
それはP6初代機版のドアドア？
初代機版のドアドアのロードって画面関係は1バイト書き換えをひたすらやってるだけじゃん
CLOADで右上に＊が点滅するのだって1バイト書き換えだし
初代機版のドアドアのロード中の画面ってそんなにびっくりする事かねぇ
画面なんかよりずっと音楽が鳴っている方がびっくりしたけど
まあテープのロードは一方向通信だから
取りこぼしのないようにどうしたってCPUがほとんどそっちにばかりかかりっきりになってしまうけど
双方向通信のハードならまた違ってくるよね
- 552 ：
- >>551
あ ごめん 勘違い その通り「音楽が出続けてること」に驚いた だ
（35年前のことなので・・・ｗ 画面が動いてると記憶違い
これをやってるソフトはあまり無かったような
なおP6の普通のカセットロードはサブＣＰＵが担当してて、
メインCPUはサブ待ちで何もしてなかった はず
- 553 ：
- Ｐ６のテープロードの処理
（１） サブＣＰＵが1バイト分を読むのを待つ
（２） メインＣＰＵに1バイト届いたら
（３） エラーだったらエラールーチンに飛ぶ
（４） エラーでなければメモリに落とす
（５） （１）に戻ってループする
メインCPUは（１）で1バイト分読む間は確かに待っているだけだけど
（２）～（５）の処理はメインCPU側でやる事でしょう
（２）～（５）の処理時間に少しだけ余裕があるから
その間に右上の＊を点滅させたりするような簡単な処理はできる
- 554 ：
- >>550
V9938のカラーバス入力はスーパーインポーズじゃないよ？
俺はスーパーインポーズの話はしていないのだが？
- 555 ：
- >>553
FIFOが数バイトでもあれば、楽だっただろうにねえ…。
シリアルなんかもそうだけど、FIFOが載って割り込みで起こしてくれる環境があるか無いかで天地の差だなまじで
- 556 ：
- >>554
その元の>>525 の方のはスーパーインポーズの話じゃないかな？という説明ね
MSX2とMSXとは別の話でのMSXでの話な訳だし
- 557 ：
- >>556
「スーパーインポーズの話はしていない」というのに、それはスーパーインポーズの話だからと食い下がるキチガイ
日本語が読めない(フリをしている)奴ばかりなぜこう大量発生するんだ
- 558 ：
- こんな異常な連中がゾロゾロ居るとも思えないので、
固定の数人かせいぜい数十人くらいからの持ち回りで回してるんだろうな
お前は観察される側なんだよ
- 559 ：
- >>558
きちがいの代表格はお前だよ
- 560 ：
- ここも懐古厨がマウント取るだけのクソスレに成り果てたな
いい加減現実に気づけ
- 561 ：
- マウントキチガイが目先の口プロレスに勝とうとして「自分から反則技出して退場して行くアホ」
っていうのがまだツボに嵌まっていて、通勤電車の中でうっかり思い出し笑いしそうになった
- 562 ：
- 究極ではないが、理想的な(標準的な)8bitパソコンは昔のBBC microとか日本ならPC-8001mkIIかなと思っているがどうだろうか
ここから肉付けしていけばよいのでは
連文節変換程度の日本語処理とかさせたいならCPUは8086以上が必要となるけれども
単漢字変換なら8bitでもなんとかなる
- 563 ：
- >連文節変換程度の日本語処理とかさせたいならCPUは8086以上が必要となるけれども
ならねえよ
変換用の辞書をROMで持てればZ80機でいけるし
漢字が2バイトだからレジスタ幅も16bitでないと～みたいのは正にニワカホイホイ
- 564 ：
- 4bitでもでけるよ
- 565 ：
- 史実で連文節変換用のROM搭載していたのは88の8MHz機MH/MAクラス
それか辞書ディスクをRAMディスクに上げて使えたX1turbo
これでゲーム用の低解像度(320x200)モードつけてグラフィック画面のオフセット(スクロール)つけて
あとはCPUどれだけ速くしてRAMをどれだけ盛れるかくらいか
- 566 ：
- > 漢字が2バイトだからレジスタ幅も16bitでないと～
なんて思ってるのは>>563だけだろ…
辞書ROMが64KBに収まらないとかは考えた事もないのかよw
- 567 ：
- 究極の一つの形はFM-11AD2+改だと思うんだがなー
NECにこだわる人って自分が持ってた奴が究極じゃないと気に入らないんだろうなあ
- 568 ：
- >辞書ROMが64KBに収まらないとかは考えた事もないのかよw
なんで64KB縛り？もっと大容量でいいだろ
- 569 ：
- >>566
漢字ROMは高速ROMをWord接続にしてビデオコントローラが直接参照するようにすればいいだろう
- 570 ：
- >>568
お前は一体何を主張してるんだよ…
>>569
漢字ROMと辞書ROMの区別もできないのかよw
- 571 ：
- >>566
フロッピーに辞書を置いてた時には、頭文字入力時に直ぐに該当シリンダにヘッド移動してシークタイムを短縮してたもんじゃで
頭文字ごとのバンク切り替えくらい楽な処理
- 572 ：
- >>571
頭文字毎にデータ量がバラバラだからバンク切替にするとROM領域が無駄になる
そもそもROMならシークタイムはないからそんな無駄な処理はいらん、普通にB-Treeとかのデータ構造で充分
- 573 ：
- JISコードで指定できるなら辞書なんかいらなくね？
- 574 ：
- 全角半角混雑考えるとシフトJISのが良いけどな。
記号使えなくなるけど。
- 575 ：
- 連文節入力してるヤツっ入力遅すぎ。たいていローマ字入力だし。
単文節で変換、確定していくほうが絶対にはえーよ。
- 576 ：
- 区点入力か単漢字でいいよもう
- 577 ：
- 8086でもatokは糞遅い。当時は辞書はFD上だしな。
HDD or RAMディスク導入までは実用的な速度は出ない。
速いのは漢字VRAMあったから表示だけ。
- 578 ：
- >>574
シフトJISだと16進数になってしまう
JISコードなら0101～9494なのでテンキーだけで入力できる
- 579 ：
- MSXの漢字フォントと変換辞書はROMに持ってたな単文節だったが変換も速かった
x86が必要ってどゆことよ
- 580 ：
- 88MHは辞書はFDにあったけどクソ重いとは思わなかったな。
ワープロ検定1級レベルの入力には追従してくれなかったけどw
- 581 ：
- 頑張れば出来るのとそこそこ実用的な速度で使えるのは違うと思うのだがそこは区別しませんか
8bitでも今時のAVRやRL78なら処理に余裕があってもZ80Hだと厳しいというのはある
- 582 ：
- P6に4KBくらいのバッファとSCSIインタフェース付きのカートリッジを用意したら面白そう
- 583 ：
- >>573
そりゃコード入力だと辞書はいらんわなw
>>575
それ当時の話？
ならいいけど、今もその認識だと老害すぎるぞ
- 584 ：
- タウンズ2のデモで開発課長と担当者がFPAGで伸張させたスターウォーズのxwingの取り込み動画デモを見せてもらった。
今から思うと規格勧告前のjpegを力技でモーションjpeg化していたのかも。
ソースのデータはMOから読み込みしていた。
8ait時代で画像を頑張っていたのはリバーヒルのJBシリーズかなぁ。
- 585 ：
- >>579
MSXの日本語変換はメガROMで512kBとか
かなりの大容量じゃなかったか？
- 586 ：
- >>584
それって5インチＭＯじゃなかった？ｗ
- 587 ：
- >>583
連文節は論理的に遅いね。変換確認を戻らなきゃならん時点で脳みそリソースを無駄遣いしてる。
いくら精度が高くなってもどうにもならんね、これは。しかもミスってたらもう致命的。単文節はそれがゼロ。
- 588 ：
- 8bitスレでローマ字入力なんているわけないやん。そんなヤツがいたらそいつは8bit機持ってねーよ。
- 589 ：
- MSXでローマ字入力だったけど
- 590 ：
- >>565
MSX-JEも連文節変換だけど。
ソニー/HALNOTEのはEG-BRIDGEのZ80版で
賢かったけど変換がちょっと遅かった。
松下のMSXが内蔵させていたVJE-80は速かったけど
ちょっと馬鹿だった。
https://uniabis.net/pico/msx/msxjp/
- 591 ：
- >>588
普通に打ってたぞ
>>589
MSX2の時に導入されたな
- 592 ：
- >>591 ←16bit工作員発見
- 593 ：
- >>589 ←おまえ前にMSXで大嘘ついて暴れてたよな。MSXテープ時代にC言語使ってたって。
- 594 ：
- >>587
老害は早めに去れよ、邪魔
- 595 ：
- MSX2をMSXとして語る馬鹿は消えてもらいたい。
だいたいFDD付き格安MSX2買ったガキって8bitPC時代が終わった89年以降に購入してるから話がかなりズレる。
- 596 ：
- >>594
ボケてるのかレス遅すぎ。連文節のせいだなw
- 597 ：
- MSXの話をしてるのに話題に入ってきて全否定して実はMSX2の話だったってパターンは何度も見た。
全部同一人物だと思う。
- 598 ：
- 早く究極の8bit機をお願いします。
- 599 ：
- しかし、よくZ80で連文節変換なんてできるな
俺がコード組んだら当たり前のようにMByte級のワークメモリを使っちゃうと思うわ
- 600 ：
- 出来ても実用になりません
- 601 ：
- ディスクキャッシュやRAMディスクキャッシュを使えずフロッピー上に辞書を置いて変換する98よりは
辞書をROMで持つMSX-JE環境のほうが変換速度は快適だったよ
3.58MHzという遅さで、さらにシステム化レベルでバンク切り替えが乱発されるという想像を絶するようなクソ環境でも、フルソリッドステートなればこそだ
10MHzのバンクメモリ上にファイルシステム経由でアクセスしなければならなかった98のDOS環境でも、RAMディスクに辞書を置いたときの快適性は、のちにSSDが普及してくるまで20年以上再現が困難だった
連文節辞書だと辞書ROMの容量が無駄になるとかも意味不明
- 602 ：
- PC88でユーカラ（ユーカラ＋、だったかな？）使ってたことあるけど、ローマ字入力してましたぞｗｗｗｗｗ
N88-日本語BASICで日本語入力もローマ字入力してましたぞｗｗｗｗｗ
ワープロ全盛の時代（の終りごろ）とはいえ、8ビットPCでワープロとか今からすると狂気の沙汰に近いものがあるな。
- 603 ：
- なんかキチガイがいるな
8ビットにローマ字入力は無理って言ってるからMSX2の実例上げたまでなのに
ちなみにMSX2は85年発表ね
>>595
自分はHB-F900使ってたからそれには当てはまらないなw
そもそも格安のディスク付きMSX2が出たのは87年暮れだよ
- 604 ：
- 辞書は1文字目をキーにしたハッシュリスト、2文字目以降の単方向リストかな。
学習機能もたせないなら2文字目もハッシュリスト、3文字目以降をB木か単方向リストで検索するのが簡単そうだ。
メモリバカ食いするけど。
- 605 ：
- >>595
MSXで高速で漢字が使えたっていう時点で2+だって判れよ知らないなら黙ってればいいのに
- 606 ：
- 2+で日本語環境が整備される以前、漢字ROMすら載っていないMSX2でも
半角カナ/かなの入力がローマ字カナ変換で出来たんだけど
2+と悟れとか89年以降とか言ってる奴らは一体
- 607 ：
- めんどくせーな混同してんじゃねーよ579=605他は別の人
- 608 ：
- あとMSX-JEやら整備されたのは確かに2+の時なんだけど(ゲームキッズ視点ではVDPの小改修で終わったかのように語られがちだが、2+はソフトウェア環境の整備が大きかった)、
2+に日本語処理用のハードウェアカーソルとかが追加された訳ではないので、MSX-JEやDOS2をMSX2に持ってくれば、日本語に関しては動作速度も含めて全く同等に動作する。
まあ、現実にはもう3.58MHzつらいよ、TurboR持って来い…ってなる訳だが
- 609 ：
- >>607
区別する必要がない程にお前もデタラメ言ってるので、同じく背中から撃たせてもらった。
恨むなら己の甘い認識を恨め
- 610 ：
- まあ究極の8bit環境ならRAMもメガバイト単位で積んでるだろうし
日本語入力用のIMも、変換用の辞書データも全部オンメモリ動作できるだろ
日本語の表示をどうするのかいまだに統一見解がないけど、まあRAMも含めて数十～数百MHzで動作してるなら
スクロールレジスタとマルチプレーンR/W付きのプレーナVRAMへ直書きでも実用上十分な応答速度はあるだろう
- 611 ：
- >>606
悪いが馬鹿は黙ってて。
- 612 ：
- やなこった
誰がお前になんか従うものかよ
MSX2の半角カナ/かな入力がローマ字変換で可能だった話書いたのも結局俺じゃん
くだらねえ条件を勝手に設定して争ってるどちらもバカだし無知だよ、両方R
- 613 ：
- >>602 >608
で、おまえらはローマ字入力なの？w 8bitパソコンユーザーなのに？w
- 614 ：
- 実在する石の中で最強の8bitCPUを探そうとすると、やっぱりez80一択になるんだろうか
- 615 ：
- N88日本語BASICやワープロソフトで使えるからってローマ字入力する低脳馬鹿はおらんやろ。
他のBASICやゲーム、ソフトではカナが強要されるんだからw
入力効率のいいカナ覚えてるのにわざわざローマ字入力する馬鹿もいないだろう。
- 616 ：
- おれはキーボードは昔からずっとASCII配列派なので。
現に、日本語入力以前にショートカットとかムチャクチャになるし、OADG配列は日本(人)の生産性を低下させている元凶の一つだと思うよ。
まあちょっと難しい話だったかな。お前のレベルじゃ理解できなくても仕方ないか
- 617 ：
- >>615
88には魔法使いの妹子という同人ソフトがあってですね…
- 618 ：
- このひとさっきからなにいってるかまったくかいできないや
- 619 ：
- 推察するに、人はみな自分をタイピングがとても遅く無能呼ばわりするが、
それは日本語キーボードのせいだと言ってるのだと思う。
- 620 ：
- 16bit、DOS時代にMSX2+で青春過ごしていろいろ歪んでしまったのだろう。
- 621 ：
- ローマ字カナ変換は確かに打鍵数で不利となるし実際タイピング競技でもカナ入力とは勝負にもなっていないが、それで入力される日本語の文章の品質とは何の関わりもないどころか、見ての通りこのスレにおいては逆相関さえ指摘されるところではある。
- 622 ：
- >>621
おまえのパソコン遍歴聞きたいなぁ。Windows以前までの購入機種一覧挙げてくれw
- 623 ：
- 英語キーボードとか言ってるんだからDOS/Vからの新米君で、
レス内容からしても8bit時代の話なんて知らないよ、そいつ。
- 624 ：
- >>622
ぴゅう太
- 625 ：
- >>624
おまえの話はどれもこれも嘘だらけだな。
- 626 ：
- お前に個人情報を語って与えるメリットが全く無いからな
いつどこから豊富な経験を元に斬り込まれるか怯えてろ
- 627 ：
- ローマ字入力だと頭が混乱しやすいのかしらしかも駄文書き連ねて自画自賛とかおめでてーな
- 628 ：
- 生まれながらに聾なしとはともかくとして、普通、語を音として脳みそが認識する速度による制限のが先にきちゃうから
だので、ローマ字入力はかな入力に対して別に遅くはならないのよな、現実には
- 629 ：
- >>628
> 語を音として脳みそが認識する速度による制限のが先にきちゃうから
それお前だけw
- 630 ：
- >>614
ただあれもALUは24bit演算なんだよな
高速のZ80ですって言えば確かにそうなんだけど
- 631 ：
- 渡された原稿をただ早打ちできるだけが取り柄で、自分で文章を考える必要がなく、知的労働とは無縁な奴ほどカナ入力を誇るよね。
- 632 ：
- > 渡された原稿をただ早打ちできる
技術者でこんな仕事させられてる奴みたことないな。おまえの職場は一体全体どういうところなのだ。
- 633 ：
- 明らかに8bitパソコンを持ってなかった奴がこのスレにいるということはよく分かった。
- 634 ：
- ぴゅう太は16bitだったな
- 635 ：
- >>んー キミら8bitどのへんからなの？
>>おまえのパソコン遍歴聞きたいなぁ。Windows以前までの購入機種一覧挙げてくれw
>>明らかに8bitパソコンを持ってなかった奴がこのスレにいるということはよく分かった。
君、寒いよ
オレも含めてまわりは皆、君と同じ老人しかいない板にきて老外をきどられてもねぇ・・
老人の場にきたら若人の事など忘れて肩の力抜いて話そうぜ
- 636 ：
- 8bitPCで、C言語使ってた、ローマ字入力してた豪語するのに
環境聞くとなぜか答えない人ってたぶんDOS/Vユーザだと思う。ASCII配列派とか言ってるしw
- 637 ：
- 明らかに昔の8bitPCを知らない。30代後半の無職だろうな。
- 638 ：
- >>630
結局「究極の8ビット機」の定義によるんだよね
・8ビットマイコン全盛時期に実在したデバイスなのか今時点で存在するデバイスなのか？
・メーカーが8bit CPUとして売ってるものに限るのかデータバスが8bitならいいとするのか？
・etc…
まあそもそも「究極」の定義が人によるけどね
- 639 ：
- >>636
> 8bitPCで、C言語使ってた
またそれ？
専用スレあるからそっちでやってくれ
そっちでボコられたからってこっちで暴れるなよw
- 640 ：
- ぴゅう太から始めてぴゅう太mkII、TurboRってな16bitホビーパソコンこだわり派が可能性としてはあり得るのか
- 641 ：
- >>614
メーカー販売に限定しなければ、同人ハード50MHz6502も対抗できるかと
こっちはパソコンになってるし
100MHz版を目指してるってな更なる向上余地も有るし
- 642 ：
- 可能な限り実在する、の縛りあるけど年代縛りないし実現可能なデバイスてんこ盛りな「オレスゲーマシン」を極めるのもよかないか？
極められたらそれはそれで「究極」だし。
あり物買い物だけでやるのもありだし。
コンセプト決めないであれこれやるのが一番ダメだわ。
- 643 ：
- きっちり条件決めてあっても6502キチガイやスプライトキチガイが街宣始めるんだぜこの板
- 644 ：
- 8ビットパソコンでスプライトはあっても良いとはおもうが、
CPUから見えるグラフィックVRAMはプレーン方式を推すわ。
CPUは個人的嗜好でZ80系だけど。
- 645 ：
- いくらでもゲート数注ぎ込めるならX68000以上のスプライトマシンでも何でも好きにすればいいけど
それサブCPU Core i9 GPU GFX2080…みたいのと何が違うの？って話になるしな
VRAMはメモリ空間が64KBしか無いのに320x200x8bppとかやるともう数バイトのデータのやりくりすらバンク切り替え挟むの？馬鹿なの？としか思えないんで
パックドピクセルキチガイは算数しかできなくて自分でプログラムコード書いた事がない逆張りキチガイだと思ってる
スレ内や板内でピックアップしたキーワードで煽り文生成して投下する人口無能説すらありえる
- 646 ：
- 適切なグラフィック難しいのは確かだが、
電卓で2.8 inch 320x240-pixel (16-bit color)まで来てるからなあ
eZ80のアドレス空間の広さは有るだろうけど、最低でも電卓に劣るのは違うだろうっ問題が
- 647 ：
- >>639
というかDOS/V君はなんで過疎スレだったここに来たの？ キミ今までいなかったよね。
昔からこのスレの住人みたいな顔しないでくれる？
- 648 ：
- 64KB以内でも、メモリ配列がVRAMそのものじゃなく、
特定の矩形でCPUからアクセスできる可変配置ができれば、
プログラムは十分に組みやすい
GPUサポートは違うとは感じるが、そう言うメモリアクセスサポートは欲しい所
- 649 ：
- VRAMの操作が矩形のコピペ（まあ要するにゲーム）なら
任意の矩形区間を16KBくらいのウィンドウにできれば良いみたいな考えなんだろうけど
当時のグラフィックってまずはグラフ図形ありきなので結局プレーン分割してでも1画面が1バンク見えてないとつらいって意識が真っ先に来るはずなんだよね
98なんかそれで4バンク全部メモリ空間に貼っちゃったのは、今にして思えばやりすぎだろう(同時に見えるのは1バンクあれば良い)…ってなるけど
プレーンVRAMはそういう要請でできてる
線分からラスタライズするのもプレーンの方が相性いいしな
- 650 ：
- どうして懐古厨って現実見ないでオワコン如きでマウント取りたがるのかね
理解不能
- 651 ：
- あと8086ならVRAMが64KBのセグメント境界さえオーバーしなければ1プレーン32KBだろうとパックドピクセルの320x200だろうと好きにすればいい
VRAMと出し入れするデータもプログラムコードもスタックもVRAMに割り当てるセグメントとは別にあってアクセスできるから64KBさえ超えなきゃいいんだけど
メモリ空間自体が16bit(64KB)しか無い8bit環境では、VRAMが64000bytes(10進で)取ってしまったらあと1535bytesしか開いてないんですよ
ベクタ空間とスタックで256ずつとか取ったら、あと1KBしか無いの。
これで収まるだろ64KBに!!何が問題なんだよ!!!!(絶叫)…ってのが、パックドピクセル君の「わかってない」所。
矩形ウィンドウ君もわかってないな。
- 652 ：
- まとめると、
・少なくともVRAMはバンク内で全ピクセルを俯瞰できることが必須条件
・VRAMバンクでメモリ空間を全部埋め尽くしたら超扱いにくい(当然読み書きも遅くなる)。VRAMバンクは多くてもメモリ空間の半分、せいぜい1/4までにして欲しい
まあ史実の8bit御三家が判で押したように640x200ドットプレーンでVRAM1バンク16KBという構成だったのは、正に「そういうこと」なんですよ
- 653 ：
- ドット単位で描くとなると、パックドやプレーンの違いよりも、
16bitでのX座標Y座標直接指定は欲しいかな
VDPに任せてアドレス計算自体をしない方が良い
メモリ空間に直接見えてる利点よりも座標指定出来ない負担の方が重くなる
- 654 ：
- >VDPに任せてアドレス計算自体をしない方が良い
ならCPUからVRAM直視できなくても構わんて話になる
VDPが無限に高速ならそういうのもアリかもね
俺は嫌だけど
- 655 ：
- >>647
基地外早速降臨ww
- 656 ：
- C言語君は自分の失敗を俺になすり付けようとしても毎回見透かされてて嗤う
とにかく転嫁先が必要なので今回DOS/V君という新キャラを捏造してみた、という辺りか
- 657 ：
- Windowsのページサイズも知らずDOSのexeはリロケイトしないとか言ってたJP君は8bitパソコンを持ってたのかい？
DOS/V君は聞いても機種すら言わないんだよ。困ったもんだね。
嘘つき君というのはどうしてどいつもこいつも使ってた環境言わないのかね。
環境言うたびにMSXと言ってたのにtorboRで16bitだったとか、PC98+Z80ボードだったとかそんなのばかり。
- 658 ：
- (JP)君はキチガイ発言ばかりだからすぐわかるね
- 659 ：
- >Windowsのページサイズも知らず
いつ言った
言ってもいない事を言ったように書く・自分の失敗を他人に付け替えるキチガイこそお前だろうが
>DOSのexeはリロケイトしない
(プログラマが意図して非効率な指定をしない限り)実行前のリロケート処理など無い
- 660 ：
- 使用機種なんか答えて、みすみす手の内を晒す訳がないだろ
あるいは、答えたとしても正直に書く馬鹿がいるとも思えない(ぴゅう太はどうかと思うが)
馬鹿が適当な事書いてたら速攻で叩かれるという恐怖心でこの場を支配する重要機密だわ
素人なので詳しくないのですが～からの一発論破が俺の得意技なので、頑張ってホラ吹いてた叩かれてくれや
- 661 ：
- ここはビルド時のメモリモデルすら理解できてない奴らばかりだからな…
- 662 ：
- x86、DOSになると口が軽くなるのに、8bit環境になると途端に口が重くなるんだよな。
持ってた機種言ったぐらいで個人情報なんて特定されねーし、そもそも手の内ってなんだよw
8bitでC言語は普通に使える!! → 開発環境は？ → 言えない!!
8bitでローマ字入力、ASCII配列キーボード → 何の8bitパソコン → 言えない!!
嘘つきじゃなければなんなんだ。隠すほどのことかよw
- 663 ：
- >>659
まだそんなでたらめ言っているのかｗ
- 664 ：
- 偉そうに言ってるけどexeのオプションヘッダの再配置テーブルの存在を知らなかっただけだろｗ
最近だとちょっとググったくらいだとPEヘッダの話ばかりでDOSのexeヘッダの
解説しているページはほとんど出てこないから
211 名前：ナイコンさん (JP)[sage] 投稿日：2019年08月10日(土) 00:57:00.81
>>208
NTとかで使うPEやNEヘッダは実行バイナリすらヘッダに収まるけど、少なくともMSDOS用のexeのヘッダは各セグメントの初期値が書いてあるだけで、起動時に書き換えられすらしない
つまり何言ってんだお前すぎる
- 665 ：
- >>586
5吋MOだったよ。
辞書をFDからメモリに置くのは然程速く無いと思う。
ただ少し使ってFDに戻ると遅さに愕然となる。
きょうびTVやモニタ出力はキツイだろうな。
120fpsとかになってるからなぁ。
- 666 ：
- 横からだけどMS-DOSのexeは書き換えるよね
今からでもアクセスしやすい本で言うと「Ｗｉｎｄｏｗｓはなぜ動くのか」って本とかに書いてある通り。
ま、それを受けても「それは○○とは言わない」みたいに言葉の定義をずらして逃げることはいくらでも可能だけどね
- 667 ：
- >x86、DOSになると口が軽くなるのに、8bit環境になると途端に口が重くなるんだよな。
CP/MやWindows,Linuxについてもゴリゴリ書いてるけどねえ
見てないか、理解できないかなんだろう
見えてる世界が君の全てだ
それが君の限界だ
>8bitでC言語は普通に使える!! → 開発環境は？ → 言えない!!
このスレか過去スレで言及してるよ
>8bitでローマ字入力、ASCII配列キーボード → 何の8bitパソコン → 言えない!!
このスレに書いてあるよ
むしろC言語ありえない君の遍歴こそ晒して欲しいね
まず身をもって手本として欲しい(含み笑い)
- 668 ：
- このマウント爺は何がしたいんや…
- 669 ：
- >偉そうに言ってるけどexeのオプションヘッダの再配置テーブルの存在を知らなかっただけだろｗ
>最近だとちょっとググったくらいだとPEヘッダの話ばかりでDOSのexeヘッダの
>解説しているページはほとんど出てこないから
自分で晒しているつもりの書き込みでWindowsとMSDOSのヘッダの違いについて言及した上で
MSDOS用のexeヘッダ(MZヘッダ)ではプログラマが指定しない限りリロケートテーブルは必須ではない(リロケーションは行われない)と書いているのだが
- 670 ：
- ＞(含み笑い)
いや…背筋が凍ったわ
暗黒微笑の使い手がいる
- 671 ：
- >>666
だからこういう半可通が茶々入れて来るの本当に勘弁してくれねーかなあ
自分でメモリモデルをアホみたいな設定にしない限りリロケーションは必須ではないんだよ
32バイトのMZヘッダのどこにリロケーション情報が書いてある？示してみろ
できないニワカは黙ってろすぎる
- 672 ：
- >>671
オレはその論争の発端を見てないからなんとも言えないけど
最初から「自分でメモリモデルをアホみたいな設定にしない限りリロケーションは必須ではない」って言ってたの？
だったら君が正しいね
そういう条件（「すべての何々～」とか）を限定せず、フツーに「MS-DOSのexeはジャンプ先を書き換えるよね」って誰かが言ったらオレなら「うん」って答えるね
過去ログを漁る元気はないので以上です
- 673 ：
- >最初から「自分でメモリモデルをアホみたいな設定にしない限りリロケーションは必須ではない」って言ってたの？
そうだね
普通はsmallかtinyでビルドすると思うんだけど、ROM化するのにmediumやcompactやら使ってROM化に失敗するようなアホもいるので
デフォでリロケートするバイナリ作ってた間抜けも居るんだろうね。彼にとってはそれが普通なのかもしれない。
でも俺から見たらOSやコンパイラの仕様も理解できていない間抜けだし、その間抜けの設定はデフォルト動作ではない
- 674 ：
- >>669
どこに？はじめは書き換えないって言い張ってたよね
exeの再配置はDOSの持っている標準機能でcomとは違う大きな特徴のひとつなのに
- 675 ：
- >>189 (おれ)
>>192 (ニワカ、EXEの一部は～という書き方なら俺も見逃してやったところだが)
>>208 (ニワカ、同上。断言したので許さん)
>>211 (おれ、C言語アリエナイ君が何故かここから得意になって晒すが意味不明)
- 676 ：
- >>671
> 32バイトのMZヘッダのどこにリロケーション情報が書いてある？示してみろ
そりゃできんわなw
MZヘッダにリロケーション情報があるって言ってる奴なんていないし
唯一 >>191 に
> （ヘッダにリローケーションテーブル必須）
って書いてあるけど32バイトとか書いてないしMZヘッダの話じゃないしねぇ
- 677 ：
- >MZヘッダにリロケーション情報があるって言ってる奴なんていないし
でもexeはロード時に必ずリロケーションされるらしいですよ？
リロケーションヘッダのないexeを作れない無能にはそうなんだろうけど
無能が自分の限界をOSやコンパイラや世界の限界だと思い込んでいるだけだ
- 678 ：
- 先週：(JP)はEXEの仕組みも知らない！16bit環境を知らないWindows以降の新参者に違いない！8bitでC言語使ったなどと嘘もつく訳だ！
今週：(JP)はローマ字カナ変換していたから、8bit機は使った事がないはずだ！8bitでC言語使ったなどと嘘もつく訳だ！
C言語アリエナイ君って、もしかして…いや、本当にもしかしたらなんだけど…馬鹿なの？中卒？
- 679 ：
- 必死に取り繕ってるJP君ﾜﾛﾀｗｗｗ
exeのリロケート機能はＯＳがサポートしている機能なのに
使ってはいけない事になっているらしいぞｗ
ｔｉｎｙとかsmallしかコンパイルできないコンパイラ使ってたんじゃないの？ｗｗｗ
- 680 ：
- >>667
今言いなよ。なんで言えないの？
- 681 ：
- >>677
> でもexeはロード時に必ずリロケーションされるらしいですよ？
しれっと「必ず」とか言ってて笑うわ
指摘されて誤魔化すのに必死やんw
- 682 ：
- >>677
現実のソフトウェアの世界で「○○する」という場合は
「○○自体をすることを確認する」も含めての表現だよ？
リロケートも同じ話で、「リロケートする」んだよ
リロケーション情報が無ければできない（しない）
当たり前の話じゃないか
そういう日本語の機微を利用してコンパクトに話を進めてるのに
そういうくだらないところに絡んでくるのは邪魔だからやめてくれよ
- 683 ：
- 画面は640x200x4bppが基本として、ハイレゾ・ローレゾでどんだけ面白い機能つけるか、だね。
ローレゾにして画面数増やしてダブルバッファ、トリプルバッファができるようにするとか、
表示開始一番ずらしたスクロール対応とか。
40×12でいいから漢字が表示できるテキストVRAMも有れば面白いかも。
モノクロになるけど縦400ラインあれば漢字も40x25で表示できるし。
- 684 ：
- >>681
重箱の隅をつついてマウント取り合うキチガイスレなので俺も重箱の隅を地獄の底まで追い詰めて突きますよ
刺すか刺されるか、始めたのはお前らだからな。俺という鬼を生んだ事をあの世で後悔しろ
- 685 ：
- >>682
暗黙のうちに例外を認めないと書いてるくせに、日本語の機微とか言い出したよ。
例外を認めるなら先に書いとけ。後出しは何言っても負け
- 686 ：
- >>684
追い詰められてて必死やんw
- 687 ：
- > 俺という鬼を生んだ事をあの世で後悔しろ
www
- 688 ：
- 現在の状況：
(JP)囲まれて若干不利。矛先を攪乱できるかが勝負。
ここはひとつ過去ログの引用で正当性を主張したいところ。
MSDOSのリロケートの話、8bitスレで必要？
- 689 ：
- キモトサン、>>684をなんとかしてくれよw
- 690 ：
- あんまし煽ると ネオ麦茶みたくなるから やめたげて
- 691 ：
- 最近は無能先生やろ
- 692 ：
- >>685
例外はリロケートが絶対にされないexeだから
exeのリロケートは例外処理ではなく標準仕様
- 693 ：
- JP君は知らなかったって認めちゃえば楽になれるのにね
- 694 ：
- 昨晩俺に煽られて黙っちゃったイモ= JP なん? 怒って鬼になったとか惨めすぎてウケるんですけど
- 695 ：
- >>692
MZヘッダ8バイト目のheader paragraphsのデフォルト値は2(=ヘッダ長32bytes)
26バイト目のrelocationtable offsetと6バイト目のrelocation itemsのデフォルト値は0(0x0000)
デフォルト状態では3パラグラフ以降のリロケーションテーブルは「用意されない」
はい残念ー!!
- 696 ：
- 古い開発環境探してきて展開してみたけど
LSI-CからだとMASMのオブジェクトをリンクできなくて何やるんだったけ状態だな
思い出すのにちょっと時間かかりそうだ
VZのショートカットももう完全に忘れてるな…
- 697 ：
- >>695
つまり使用する場合はそこにポインタが入るって説明？
リロケーションテーブルを使わない特定の条件以外はリロケーションされるよって言いたいわけね
残念だったねｗ
- 698 ：
- 今のexeファイルはMMUをいじればいちいちリロケートする必要がないから、わざわざやらないんじゃないのかな？
- 699 ：
- いつのexeの話してんだ？
- 700 ：
- >>693
何も材料なくてとりつく島もない時に、とりあえず身柄だけ確保してそうやると
これが案外転ぶんだってね、昔刑事物で見たわ
- 701 ：
- まとめてMS-DOSリロケートスレ立てて移動してくれ
- 702 ：
- グラフィックはプレーン方式で640×200×4bppでいいのかな？
1プレーン16kバイトで4プレーンで、RGBIじゃなくてパレット使って16384色中16色とかでもいいかな？
いいことにしよう、はい、決定ｗ
バンク（プレーン）選択に2ビット使うけどセレクタに4ビットなり8ビットなり割り当てれば複数持てるよ、やったね！
4プレーン1セットとして、セレクタ4ビットなら4セット、セレクタ8ビットなら64セットも選べちゃう！
・・・。64セットものメモリ実装するかどうかは別として、セレクタに8ビットぐらい割り当てたほうがツブシが利きそうだな。
グラフィックの次はテキスト画面だｗ
テキストはグラフィックと重ね合わせで、テキストがまえ、グラフィックが後ろ。
PC98のテキストとグラフィックの位置関係をぱｋ・・・リスペクトだ。
テキストとグラフィックの重ねあわせするハードって非力なCPUだと重宝するから漢字をグラフィックに描くというのはナシにしたい。
- 703 ：
- 77AVに劣る所が有るようじゃなあ
24bit色中4096色パレットでしょ
- 704 ：
- 「パックドピクセル＝256色」と思い込んでるのは
VGAやPC-9821しか知らないのかな？
64KB程度のメモリ容量を考えれば、
「256色」でなく、2ドット1バイトの「16色」なのが妥当
SMC-70／777という実機も出ていたのに
- 705 ：
- そうね
- 706 ：
- >>695
> 26バイト目のrelocationtable offsetと6バイト目のrelocation itemsのデフォルト値は0(0x0000)
どこのページに書いてあるんだ？
http://bytepointer.com/download.php?name=msdos_encyclopedia_article4_program_structure_exe_com.pdf
そもそも省略不可のパラメーターのデフォルト値とか意味不明だし
ちなみにオーバーレイみたいなあまり使われない奴だとp.122に
1A-1BH(Overlay Number) This word is normaly set to 0000H,
みたいに書いてある
> はい残念ー!!
お前がなw
- 707 ：
- 4プレーン方式の方が使い方の自由度が高い
- 708 ：
- パックドピクセルはなー。
256色以上ならメリットでてくるけど4bpp程度なら一画面が見渡せないって制限のせいで使いにくくなるから却下。
どうしてもパックドピクセルやりたいなら320x100x4bppなら16kに収まるから、ローレゾモードでどうぞ。
用途的にローレゾはゲームだろうしその方がいいかも。
メモリ空間狭い8ビットCPUでパックドピクセルは不向きなんだから割り切れ。
- 709 ：
- パックドピクセルの場合、横方向のハードウェアスクロールを導入しようとするとえらく面倒になるんだよな
となるとやはりPCGを……
- 710 ：
- 失礼した
×パックドピクセルの場合
○ビットプレーンの場合
- 711 ：
- パレットでいいよ
- 712 ：
- 支援ハードからはパックドピクセルに見えてCPUからはプレーンに見えれば丸くおさまるな。
VRAMに2P-RAMはRAMの速度的に間に合うのかわからんが、間に合うなら回路もそんなには複雑にならんだろ、たぶん。
- 713 ：
- >>708
320＊200，16色で32KB
メインメモリ内じゃ厳しいけど
X1やSMCみたくI/O空間を64KBにしてマッピングすれば問題無いよ。
てか上の機種は実際そういう仕様だし。
- 714 ：
- ちなみに上で言った仕様というのはVRAMの確保場所
- 715 ：
- 9821のがそうだね
VRAM自体はパックドピクセルで、CPUからはパックドピクセルとプレーンとの2種類でアクセスできるって
8ビット機なら、VRAM側が64ビットなり、8倍速アクセスなりなら問題ない
DRAMの高速アクセスモードにCPUが対応してないので高速さでカバーできるだろう
- 716 ：
- これは単純なCRTCみたいなのじゃなきゃダメとかGDCみたいな高機能な奴もありとか
なんか縛りはあるの？
- 717 ：
- グラフィック関連も8bit縛り。PCエンジンみたいなインチキは許されない。
- 718 ：
- 8ビットVRAMって少ないなあ
- 719 ：
- >>716
そこを今探ってるんだと思う
なんでもありなら今のPCをサブにすれば現在の最高速度まで行ける訳で
でもたぶん大多数の人は「それは違う」と思ってるだろうし
- 720 ：
- CPUがZ80なのにGPUがnVidiaとか妄想にしてもありえん(笑)
- 721 ：
- 必要に応じてパックドピクセルとプレーンと選んでアクセスするのが落とし所かな？
メモリウィンドウは16k縛りでプレーンモードで指定プレーンは画面まるっとみえる。
パックドピクセルモードだと画面の4分の1だけ見える、みたいな変則的な構成になるけど。
- 722 ：
- VRAM側はいいとしてやはりCPU側のデータバスは8bitだよね
nVidiaとかがどうなってるのかは知らんけど
- 723 ：
- 初期のテキストVRAMからして画面出力側は16bitバスだからねえ
- 724 ：
- CPU側はデータバス8ビット縛りで良いと思うよ。
8ビットパソコンなんだし。
- 725 ：
- もし Z80 そのものの改造が許されるのなら
メモリ空間 64kB、I/O 空間 64kB に加えて、第2メモリ空間 64KB を追加したい。
第2メモリ空間はデータ専用で、コードは実行できないが、VRAM+α 用と割り切れば十分。
具体的には MREQ#, IORQ# に更に M2REQ# が加わる感じ。
これを滅多に使われない HALT#ピンとの兼用ピンにして、0EDH の空きにピン切り替え命令を追加することで切り替え可能にする。
同様に 0EDH の空きに、第2メモリ読み書き専用の LD2 (HL),A と LD2 A,(HL) の２つの命令も追加する。
この２つの命令のみ、MREQ# でなくて M2REQ# がアサートするようにする
HD64180が出る前に、ザイログが(失敗したZ800ではなくて)これぐらいの小改造版 Z80 を出してくれてればよかったのに。
- 726 ：
- DMAを付けて第1メモリ第2メモリI/O間でデータ転送できるようにしよう
- 727 ：
- Z80 DMA は無改造なら
第1メモリ ⇔ I/O 間
第2メモリ ⇔ I/O 間
第1メモリ ⇔ 第2メモリ間
のトータル3つが必要になるな
いかんな、これはｗ
かといってCPU側にDMA機能まで持たせるとなると、
もうそれはHD64180もどきになっちまう
- 728 ：
- 200ラインかインターレス400ラインアナログテレビに映るなら無制限に高性能でいいんじゃね派
- 729 ：
- 高速SRAMで8x8のスプライトを2000個表示可能
テキストモードは1文字1スプライトで敷き詰める
- 730 ：
- >>716
FM型のツインCPUは可能性を感じるんだが、あれもっと練り込んだ設計にしてればもっと強力だったんじゃないかなあ
- 731 ：
- CPU ８個、うち１個メイン、７個サブ、それぞれメモリ持つ
メインとサブで共有メモリ持つ
とかでいんじゃん？
足りなければ１６個でも３２個でも
- 732 ：
- >>729
ただし水平方向は8個までの制限ががが
- 733 ：
- チラリズムよねたまらんち
- 734 ：
- >>725
> 同様に 0EDH の空きに、第2メモリ読み書き専用の LD2 (HL),A と LD2 A,(HL) の２つの命令も追加する。
命令追加するぐらいならバンク切替とか簡易MMU乗せるほうが全然楽だろ
> この２つの命令のみ、MREQ# でなくて M2REQ# がアサートするようにする
>
> HD64180が出る前に、ザイログが(失敗したZ800ではなくて)これぐらいの小改造版 Z80 を出してくれてればよかったのに。
- 735 ：
- >>734
それだとDIP 40ピンパッケージに収まらない
DIP 48ピンとか64ピンにしてもいいのなら、その通り。
- 736 ：
- 共有メモリはlock信号あるようなCPUでもなきゃいろいろ大変。
調停とか占有とか
- 737 ：
- デュアルポートRAMにしよう
- 738 ：
- 今時のSRAMなら64KB満たすのも超余裕
ガンガン積んだらええ
- 739 ：
- >>735
？
ピン数気にするならマルチプレクスすればいいだけでしょ
8086/8088 も 40pin パッケージだし
- 740 ：
- >>706
>そもそも省略不可のパラメーターのデフォルト値とか意味不明だし
MZヘッダのヘッダ長は最小(デフォルト)時で2パラグラフ(32bytes)
省略不可なので最小ヘッダ長は0x0002だし、リロケーションテーブルが存在しない場合オフセット及びアイテム数には0が書かれなければならない。
すなわち「リロケーションが行われず、リロケーションテーブルも用意されないデフォルト状態のパラメータは0」
必死に解釈こね回してリロケーションが行われないexeは存在し得ない(ので俺が間違っている)ということにしたいのはわかるが、まあ無理筋にしても無理。
これだけ根拠を積み上げられても、イヤイヤしてれば負けないとでも思っいるのか？そろそろ諦めて楽になったら？
- 741 ：
- JP君がかわいそうになってきた
- 742 ：
- DP-RAMで排他制御はソフトでやるなら余裕で実現可能だね。
ただあまりCPU数増やせないと思うんだよねー。
ざっくりだけど8までいったら逆にパフォーマンス落ちそうな予感する。
- 743 ：
- 出来損ないのハーバードアーキテクチャみたいな妄想に、アホ共がイイネしてるのマジ嗤う
32bitでも64bitでも広帯域のメモリバスにして、普通にマルチプロセッサ環境にすればその方がスマートだろ
まあそうなるとバスの調停やMMUやI/Oコントローラのロジック規模は明らかにCPUコアより複雑かつ大規模になりそうだけど、
CPUコアさえ8bitALU/8bitデータバスならokという縛りなら、その条件から逸脱しない範囲でどうとでもなるわ。
出来損ないのピクセルシェーダや機械学習用エンジンみたいなプロセッサだけど、やりたいなら止める理由はないな。失敗する様を眺めてもみたいわ。
- 744 ：
- グラフィックも、どんな設定にしても陳腐化は免れないので
16KBのバンクからアクセスするのに都合のいい形なら
表示能力は好きにしろ(何百バンク束ねて高解像度多色でもスプライトでも別にどうでもいい)
ただ、スプライトASICやGPUの仕様策定でスレを浪費するなら、他所でやれ(ここから出て行け)、と言っておく。
- 745 ：
- >>740
> すなわち「リロケーションが行われず、リロケーションテーブルも用意されない状態のパラメータは0」
これは正しい
ただそれをデフォルトと言うのはバカでしかない
> 必死に解釈こね回してリロケーションが行われないexeは存在し得ない(ので俺が間違っている)ということにしたい
誰もそんなことは言ってない
リロケーションしないと言ってた>>211とかが必死になってるだけ
まあそれこそ無理筋だが
> これだけ根拠を積み上げられても、イヤイヤしてれば負けないとでも思っいるのか？そろそろ諦めて楽になったら？
お前がなw
- 746 ：
- >ただそれをデフォルトと言うのはバカでしかない
いやお前が馬鹿だし、無理言ってんだよ
MZヘッダはヘッダ長32bytes。その後ろにリロケーションテーブルが付くのは必須ではない。なぜならリロケーションは必須ではないからだ。
これを必死でなんとか覆そうとするなら、むしろ見てみたいぞ。30年来の常識が屁理屈で覆る瞬間をなｗ
- 747 ：
- まあ考慮の必要もない程のレアケースな例外を
反例として持ち出して対等かのように語ってきた連中が
今回それを許さないというダブスタに挑戦している
(そこをJPが突いて無双している)ということはわかるが…無理筋だな
- 748 ：
- >>747
レアケースじゃないよ
DOSのEXE適当に見てみなよリロケーションテーブルあるファイルの方が多いから
- 749 ：
- MS-DOSのリロケートネタはもう下火だから
わざわざ蒸し返さなくてもええんやで・・・
最後に書いたほうが負けやで・・・
- 750 ：
- ALU8bit データバス幅8bit縛りで、周辺もそれ以上は反則(CRTCやVDPやコプロで16bit～等は禁止)だが、
それらの駆動クロックは縛られていないので、まあそっちで稼ぐしかなさそうだな。
CRTCやVDP内部のカラーバスまで8bitで縛られると、カラーパレットも256色が上限となるが…まあスプライト横何個とか言ってる連中には理解できないか
CPUについては、高クロック駆動の8bitCPUとメモリで仮想8bitCPUで多重化する方向の方がまだマシな気がするね。
仮想Z80でTPA60KB～のCP/M80環境を多重起動可能な究極の8bitなんかあると楽しいね
仮想モニタ自体が拡張Z80環境で動作していて、ユーザープロセスからの例外やI/Oは全部トラップさせる
MSDOSなんかよりよほど複雑で面白そうだ(作るのは。使い勝手は知らん)
- 751 ：
- グラフィック画面はもう決まったからw
640x200x4bppで24ビット色中16色だからw
プレーン、パックドピクセル併用？だからw
だからアリエナイ君と好きなだけDOSの話題で盛り上がって下さいアリエナイ君を抑えててくださいオナガイしますw
- 752 ：
- パックドピクセルで画面さわるとき、640x50x4bppを4面のモードと、320x100x4bppを4面のモードがあると面白そうだな。
（上のほうでもさらっと言われてたけど）640x200x4bppの中の任意の320x100x4bppの矩形でアクセスできるモードもあると使い勝手向上する、絶対。
プレーナーモードだと4プレーン同時アクセス機能もあるといいね、PC98のGDCのようなのだとしても無いよりあったほうがいい。
DMAはメモリ＝I/O間×３、メモリ＝メモリ間×１ぐらいあればよくね？
FDDで1ch、HDD・SD・CF・CDで1ch、Ether（LAN)デバイスやSIO、PICに1chぐらいの割り当てで。
- 753 ：
- Z80が16MHzぐらいで駆動してくれて、
320x200の4096色カラーがあれば、後は何もいらない。
- 754 ：
- あんまりVRAM大きく使うとストレージ容量との兼ね合いが・・・
究極とはいえ8bit機なんだから、FDも2Dかせいぜい2DDでしょ？
解像度低いMSXですらディスク版のADVプレイしてると画像読み出しでえらく待たされたような気がする
・・・もしかして想定されてる究極の8bit機って、１枚絵を表示するのにライン引きやらペイントやらで
数十秒～数分かかるようなやつ？
- 755 ：
- 「必須ではない」と「デフォルト」は関係ないだろ
関係付けるほうが無理筋だよ…
それが証拠に>>746はデフォルトには触れられないしw
- 756 ：
- >>754
2HDをありにすると、なにか無理がでるのだっけ？
- 757 ：
- Z80ならSMC-777Cあたりのスペックが妥当では
それ以上機能付けても重い
- 758 ：
- >>756
DMA転送が必要
- 759 ：
- 8ビットPCで2HD搭載実機があるから2HDが無理とか説得力ないね
DMAのせた8ビットPC実機があるからDMAなしの前提もおかしいね
- 760 ：
- GVRAM容量？
画面サイズがCGA、DCGA相当だからCGA4bppとして1画面で64k。
裏3面の4面構成で256k。
全画面サイズのベタデータだとかさばるな。
でもFDDは2HDのインテリドライブでDMA転送するしベタデータをCDから読めば容量も無問題。
と、いうことにしようｗ
4面16プレーン分あったって、1面分ぐらいは裏RAMのキャッシュ的な使われ方するんだし。
FD15枚とかいうADVゲームがあったっけねぇ、そういえば。
納得だわ。
- 761 ：
- ？？？
- 762 ：
- >>729
それなんてMZ-1500?
- 763 ：
- 多重スクロール＋デカキャラの源平が6809＊2で動いていたから
取り敢えずはそれが再現できるくらいのスペックは欲しい
- 764 ：
- シングルCPUじゃ厳しくね？
- 765 ：
- プレーン限定デザインとして、各プレーンごとのサブCPUってのは綺麗なデザインになるとは考える
データだけ別でプログラムは共通化できるし
プレーン1枚で48KBでも良いだろうし
- 766 ：
- >>763
FM-77シリーズ辺り以降がもっとゲーム特化してたら…という感じかな？
- 767 ：
- >>758
で、それがなにか問題なの？
Intel 8237, Z80 DMA, MC6844のように各社からDMAC出てたのにDMA使っちゃダメとか意味わからん
- 768 ：
- ローレゾモードでパックドピクセルモードで書き換えながらダブルバッファ方式で2画面使って交互表示だと…
それでも多重スクロールは厳しいかな？
できそうな気はする。
- 769 ：
- https://www.ningenkankeitukare.com/entry/0098.html
- 770 ：
- >>744
8bit機さわってて一番文句ある部分じゃね>ビデオチップ
逆にCPUなんてスーファミソフトがBASICで書ける程度でお腹いっぱい
- 771 ：
- CPUは8bit 16コアもあれば十分だな
- 772 ：
- モノコアで十分だがあえていうならそこら辺は開発環境が全然だからな
スレッド発行が基本単位の言語が欲しい所
- 773 ：
- 全部アセンブリで書くんだよ…
マジか
- 774 ：
- Modula2とか
C言語とかいうとまた荒れる
- 775 ：
- 実装によってスレッドとは限らんが、並行動作を言語仕様に含んでるものとしてAdaとかOccamとかもあったな
いずれもフル仕様だと8bitではかなり厳しい気がする
クロスコンパイル前提ならC++20にasync, awaitが入るらしいからそれを待つのが最も現実的かも
- 776 ：
- Z80H 8MHz×2
ディスク等アクセス用 RAM64KB
メインCPU バンクメモリRAM128KB
640×400 8色 or 640×200 64色 or 320×200 4096色
PCG, 漢字テキスト
OPM+OPNA
- 777 ：
- 777
- 778 ：
- どうせなら16MByteぐらい積んだら
RAMディスクとかいろいろ使いであるでしょｗ
- 779 ：
- 低能や無能というレベルをはるかに下回るバカ丸出しの煽りしかできなくなったか・・・
- 780 ：
- ちゅうか現実を認めたくないおまいらのような懐古原理主義者共が
オワコンごときでマウント取ってるだけだろ
そのお山もドンキで売ってるような低価格ノートに負けるような砂山だけどな
- 781 ：
- >>780
はーはいはい、すごいね、えらいね。
空気読めない基地外さんのいうことは正しいね。言ってる本人にとってだけは。
馬鹿で無能で基地外なんだからあんたは黙ってろｗ
- 782 ：
- >>780
懐古する板でそんなこと言われてもｗ
- 783 ：
- 否定君は満点でなきゃ零点と同じだ、みたいな思想してんだね。
余裕がない人生の惨敗者の底辺老人みたいだな。
- 784 ：
- >>780
性能を追い求めているのではない
8bitパソコンのシンプルさは今のmicro:bitに通じるものがある
シンプルなコンピューターは理解もし易い
- 785 ：
- 究極の進化形がichigojamみたいな20$PCなのかというと
なんかチガウってことでこのスレでグダグダ言ってるわけで
- 786 ：
- まぁまぁ
ここは俺の顔を立てて矛を収めろや、ガキ共。
- 787 ：
- とりあえずメモリはSRAMにしてリフレッシュサイクルをなくそう
- 788 ：
- 先ずはSRAM 1MB積むところから
- 789 ：
- SRAM16MB600円台で済むのか
- 790 ：
- CPUのアドレス幅が16ビットだと1Mはなんとかなりそうだけど、限界はどれくらいかな？
32kをバンク切替で256バンクまで可能とかやったアイオーデータ機器はチャレンジャーだと思う。
ゲジゲジパッケージびっしりの拡張ボードぇ…
- 791 ：
- 1ページ4KBで256ページだとメモリ空間は1MB、65536ページで256MB
ページサイズ16KBだと256枚で4MB、64kページで1GB
ページ数なんて256あれば十分じゃねえの？マッピング情報の管理と格納もしんどいし
…と思っていたが、メモリいくらでも積めるなら64kページあってもいいな
- 792 ：
- メモリだと思うからアレであってファイルシステムとかDBだとか
soup的なストレージだと思えば
何ならパワーオフしても消えない仕様でヨロシ
テープから読み込む手間がなくなる！
- 793 ：
- ストレージはもう今からやるなら最低限FAT32の読み書きが前提で、SDHCとか挿して使うんだろ？
なんならSDXCで2TBまで行ったって構わんのだし
- 794 ：
- FAT32対応、ただしファイル名はショート形式（8.3形式）に限る。
になっちゃいそうだね。
- 795 ：
- 8bitだったらSJISよりUTF-8の方が扱いやすい気がしないでもない
- 796 ：
- 漢字VRAM実装するからutf8は却下
- 797 ：
- KL5C8012(8bit/10MHz)とかTMPZ84C015(8bit/12MHz)とかBUSサイクルでいえば無符号16bitで桁溢れもなしで、
メモリも連続しているとしてx+y=zの計算したら
川崎が23サイクル(2.3μse)で東芝は84サイクル(7μsec)になるね。
- 798 ：
- 漢字ROMの配置は区点コードにしておくと、SJISとEUC-JPはコードずらすだけでいいから割と楽。
コードが16ビット固定になるのも処理が楽になるしハード構成も複雑にならない。
史実のワープロ専用機や漢字ROMのせたPCが区点コードを漢字ROMのアドレス割り振りの基本にしていたのはちゃんと理由がある。
UTF-8→区点ベースのコードに変換、の処理がかなり重いしメモリ食うからUTF-8はなしの方向で・・・
それに日本語主体の処理を想定すればJIS/SJISとUTF-8と比べるとUTF-8にするメリットってデメリットを打ち消すほどじゃないと思うんだ。
とくに非力な機械で扱うなら。
- 799 ：
- 区点コードになったもう一つの、そして70年代当時としては重要だと思う、理由を思い出した。
実用になるコード体系が、区点しかなかったからだ。
- 800 ：
- >>796
汎用性の低い漢字VRAMはいらん
- 801 ：
- 区点コードなら辞書とかにも載ってるから便利だしな
- 802 ：
- そこは漢字TVRAMではなく画面全体を埋め尽くせるPCGって形で
2000文字PCGの256色パレットならパレットで分離して16000文字分
漢字も表示できる
- 803 ：
- 8ビットパソコンで漢字ROMと漢字VRAMの組み合わせは有用。
グラフィックとテキストの重ね表示をハードでやれるのはかなり便利。
PCGの外字をそれぞれ2000字ぐらい使えるようにしておけばフォントの加工もそれなりに対応できるしね。
8ビットや16ビットのパソコン使ってたらそのあたりは説明するまでもないはずだけどなぁ
- 804 ：
- >>802
高速なRAMが要求されるから2000文字分とか超高価になる
- 805 ：
- >>803
そういう日本人らしい頭の固い汎用性の低い機能は要らん
AMIGAを見習え
- 806 ：
- あみがーw
アミガのVRAMなんて漢字表示に見習うべきものなんて何もないじゃんw
- 807 ：
- >>804
MZ-1500って別に超高価なんかじゃあ無かったぞ
定価89800円
1000文字テキストとPCG1024パターン8色だったのを、
2000文字テキストとPCG2048パターン256色に拡張するだけでどれだけ高価になると思った？
- 808 ：
- >>807
ざっくり32倍
- 809 ：
- 1984年でなので3年後には4倍容量で2倍速でも同じ値段
1987年には出せるよ
- 810 ：
- >>806
漢字の表示にしか使えない機能に金とトランジスタを使うなら
もっと汎用性の高い機能に振り分けろって意味だろ
- 811 ：
- >>810
漢字表示ハードが無くてもそこそこ動くようになったのは486以降だぞ
- 812 ：
- ASCII文字と日本語だけ扱えれば良い環境なら、ShiftJISやEUCは正に低負荷で済むから俺も支持する。
utf8が使いたい場合はアプリ側で対応なりコンバートなりすればいい。毎度可変長コードなんか繰りたくない。
漢字TVRAMは遅い環境でこそ効果絶大なので、テキスト/グラフィック出力を内蔵するなら漢字TVRAMはマスト。
余談だが、ANK1文字を8x16ドット(全角漢字1文字16x16ドット)で表現する場合、
1920x1080ドットフルHDは240x67.5となり、TVRAMのコード空間が16KBバンクに収まる。
(アトリビュートは別バンクになるが、アドレスは変わらんのでアクセスは楽だろう…)
- 813 ：
- いまさらAMIGAから見て習うものなんて、ほとんど何も思いつけんなー
- 814 ：
- 高解像度のフルカラー表示は、64x64ドットのブロック単位で1ドット4バイト(RGB+α)並びでアクセスすれば
16KBバンクに綺麗に収まるな
64x64ドットブロックをMZ1500のように再配置できても面白いのかもしれんけど、具体的な使い道は思い付かないや
まあ意味ないようならバンクの並びは固定で
目指せ4kいくぞ8k
- 815 ：
- >>807
256色PCGなんてどんだけ高速なRAM要求されると思ってんだ
容量も桁違いだ
- 816 ：
- SJIS環境なんて趣味で使われてる以外絶滅したようなもんだしなUTF8のが
世界標準で環境またいでも平気だし変換不要だと地味に便利
システムコールで文字列表示することを徹底すればPGに負担はない
- 817 ：
- >>815
256色PCGって言っても、帯域としては256色グラフィックと同じだ
グラフィックならシーケンシャル性能だけで良く、PCGはランダムアクセス性能が必要な違いだけで
それも8ドット×8bit色の64bit単位なので、64bitRAMでも16bitx4バーストアクセスでも良くランダム性能で困るほどじゃない
- 818 ：
- 全角文字が2バイト固定か、主流が3バイト(最長で5バイト～)の可変長か、ってのはプログラマからすればえらい違いだ
遅い環境でそんな面倒くさいロジック弄りたくない
英語と日本語だけ考えればいいならSJISかEUCでいいよ、i18nなんか考えなくていい
- 819 ：
- 8x8ドットに256色振るなんて頭悪いだろ
16色カラーパレット16バンクにして16色PCGでいいんだよ
- 820 ：
- ドット打ちすれば分かるけどPCGって8*8dotキャラ内で16色も使い切らない4色(複数パレット)で十分なくらい
- 821 ：
- >>819
漢字表示にも使える汎用性を目指したゲーム性能なのだから、8x16ドットが良いだろう
8x8や16x16の方が綺麗ではあるがテキストとの兼用な汎用性を考えるとな
- 822 ：
- 可変長文字コードなんて扱いたくないな
- 823 ：
- グラフィック画面がない場合の代用なら悪くないスーファミも256色BGあるし
- 824 ：
- スプライトとBGでもあるまいし、PCGなんて単色で256キャラ分あればいいよ
- 825 ：
- PCから持ってきて一々変換PCに持っていくのにも一々変換とかかったるいな行き帰りでふた手間ですわ
- 826 ：
- >>817
PCGとグラフィックを同列に語るとはこんな馬鹿初めて見た…
- 827 ：
- そもそも8bitパソコンなら第二水準までの漢字ROMで十分やろ
それ以上は重くなるし要らん
- 828 ：
- 文字列ライブラリを標準で提供して文字配列操作を自前で書く必要が無ければいいのである
サーチ分割比較挿入諸々
- 829 ：
- >>826
MSXでは兼用だぞ
- 830 ：
- >>826
日立S1はそれが出来るんだな(笑)
- 831 ：
- >>826
16bitゲーム機もね
- 832 ：
- >>824
PCGで表示する座標を一文字毎に可変にしよう
- 833 ：
- >>829
単色PCGやんけ
- 834 ：
- 8x8ドットを8bppで持つ自体がバカだって言われてるのに、わかんない人だなー
まあバカだからね
- 835 ：
- >>825
nkf移植すれば済む話だろ
CP/M互換なら既にあるか
- 836 ：
- >>800
子供は黙ってろ。
- 837 ：
- >>816
貴様はどんだけマイナーOS渡り歩いたんだw
- 838 ：
- まあビットマップグラフィックに比べてPCGならbppがワンランク多くてもメモリ効率や処理負荷的には可ってのは分かる
でもハードウェア的に実現可能かは重要だ
それにビットマップグラフィックだったら256色なんて16ビットCPUでも重いと思うよ、amigaやataristでも60fps出せないカックカクやろ
256色ビットマップなんてスイスイ扱えるのは32ビット世代からやん
ビデオチップで補助するってならそれもう周辺チップが32ビット級で8ビット機といえないしCPUだけ遅いのアホみたい
- 839 ：
- >>834
グラフィックとしても使えるPCGって汎用性が売りなのだから、256色をPCGとしてのみ考えなくて良いんだよ
- 840 ：
- 妙にリアルな絵文字も表示できるな
- 841 ：
- >>835
>>825
- 842 ：
- >>839
別にグラフィックとして使えなくて構わないし、グラフィックは別にあるのに無駄なもん付けなくていい。
PCGは付けるにしても単色でいい。ANK文字のフォントパターンをユーザー定義可能でいいだろ
どうせ漢字もCRTCが表示時に読むフォントパターンもROMじゃなくて(CPUとは別バスの)RAMにしようぜってなるし
- 843 ：
- >>842
BG二画面は無駄じゃない
- 844 ：
- そういうのはスプライトASICに言ってくれ。テキスト側に持って来ないで。あっち行って。
- 845 ：
- >>844
漢字表示兼用だからテキストなんだよ
- 846 ：
- 漢字のフォントパターンがCPUバスを通る時点で負け
フォントはCRTCしか知らなくていい
CPUは文字コードだけ繰っておけ
- 847 ：
- 8bppのグラフィック画面をMZ-1500のように8x8や16x16ドット単位で再配置できると、何かに使えそうな気がする
けど具体的に思い付かないや
漢字の表示に使う？漢字TVRAMあれば要らないでしょ
MZ1500方式だと表示するものを一度はグラフィックに書く羽目になるし
- 848 ：
- >>847
漢字だけでも複数書体使うのにも便利だよ
PC98はブラウン管表示用と液晶表示用とで漢字ROMを別フォントにしてた
そういうのも対応自由度が高いし
- 849 ：
- PCGで漢字って速いからね漢字専用ハードなんて不要なくらいに
CPU転送しても全然問題ない
- 850 ：
- 今作るんだったらutf8だな
流石にJIS第一水準、第二水準だけでは漢字が足らん
それとアクセント付きアルファベットの要望も満たせる
utf8からutf16への変換は難しくないんだから
サロゲートペアは除外してBMP部オンリーならTVRAM方式でも十分に可能
utf8で悔しいのはひらがな・カタカナだけでも2バイトにできなかった点だな
アメリカ人に任せずに日本人がunicode作ればよかったのに
- 851 ：
- 全角文字1文字を表示するためにCPUが操作しなければならないデータは
漢字TVRAMの場合句点コード(2バイト)と表示アトリビュート(普通1バイト)を左右半身ずつ、つまり6バイト
8色PCGの場合、8x16バイトフォント×3プレーン×左右半身で2倍の96バイト。表示だけで16倍も書かなければならない。
さらに、句点コードからフォントパターンのアドレスを求め、ROMから32バイト引いて来る処理が余計にかかる。
PCGで漢字表示って速い？…具体的に実装されていた環境をついぞ知らんのだが？
- 852 ：
- もともと当初想定されていたunicodeであれば、16bitで世界中の文字を収容できた筈なのに…
中国は漢字の割り当て(中国だけで現用漢字が4～5万もあり、全ての収容は不可能と言われた)を削る事すら呑んだというのに
ハングルとかいう気持ち悪い記号を使う連中が、論理上の全組み合わせパターン19.2k文字空間をよこせとファビョり出してご破算
現実に使われているのは2000文字程度だというのに、盲腸半島の連中ときたら中国のメンツすらへし折りやがった
俺ら多バイト文字言語圏のユーザーがutf8なんてクソみたいなコードを使わされる事になった元凶は、朝鮮人だぜ
朝鮮滅ぼしてもう一度16bitunicode策定しようぜ
- 853 ：
- トロンコードでも使わないと日本語の漢字でも足りないから
- 854 ：
- 日本語を扱う範囲ならUTF-8にするメリットないよ。
日本語関係はJISのコピーだから。
可変長コードを採用するメリットより、デメリットのが大きい。
- 855 ：
- CRTCが可変長コードから漢字ロムのオフセットに変換
テキストRAMは一文字4バイトで確保しないといけないな
- 856 ：
- 世界標準から外れる事の大きいメリットって何かしら
SJIS慣れてるから書きやすい?化石コードの再利用?害悪でしか無いじゃん
- 857 ：
- よほどマイナー道を歩んできたんだなw
- 858 ：
- >>850
UTF-8ってエンコードだよ？意味分かって書いてる？
- 859 ：
- UTF-8は文字コードが可変長だからあかん
8bitにはそれに適した文字コードでないと処理が重くなる
8bit CPUがクロック50MHzくらいでバンク切替のメモリ空間1MBあれば解決とか思ってないかい
今ある技術から切り捨てる部分がないと性能が死ぬで
- 860 ：
- >>852
今から作るんなら32bitで設計するだろ
中国の政体はともかく、漢字を省略して嬉しいのは頭の弱い欧米人だけだ
- 861 ：
- TCP/IPやUSB、Bluetoothを載せろとか言い出しそう
今はUARTやSPIやI2Cを上手く併用するのだよ
- 862 ：
- >>854
unicodeの漢字部はJIS X 0208だけでなく
JIS X0212, 0213 も含まれているから大幅に漢字増えてる
夏目漱石とか芥川龍之介とかの明治期に書かれた小説を
表示させたい場合、第三水準漢字が必要になる
あと、元SMAP 草なぎ剛の"なぎ"もね
>>858
もちろん分かって書いてるよ
>>859
シフトJISだって可変長コードなんだが？
- 863 ：
- 層の違いも理解してないとかネットワークの知識ゼロかよ。
- 864 ：
- さっきからずっとシフトJISに否定的な奴って
DOSも触らず、Windowsも触らずに生きてきたんだろうかw
- 865 ：
- >>858
ああ、書いてから気付いた
テキストデータとしてはutf8形式で持つが、
TVRAMに表示させるときはutf16形式に変換させて固定長にする必要がある
言葉が足らなかった、すまん
- 866 ：
- >>864
わかる?出来うる限り避けてきたよ
- 867 ：
- >>861
USB 1.1ぐらいはあっても良いかも
- 868 ：
- >>866
売れない、使えない仕様を作る達人さんですね。
- 869 ：
- >>861
でもUSBのマスストレージは読み書きできた方がいい
…USB I/Fのロジック規模がCPUを超える？
知らんがな
- 870 ：
- MSDOSやWindowsで使っていたSJISなんか穢らわしくて嫌だというSJISアレルギーなら、EUCしろよ。半角カナもいけるぞ
まあ俺はCP/M上位互換OS以外念頭にないのでSJIS上等だが
(SJISは本来CP/M80環境で日本語処理するために作られた文字コード体系。Microsoftは関係なかった)
- 871 ：
- 世界的に統一されてるんだからUTF8でいいんじゃないのなんでそんな化石文字コード押すの
- 872 ：
- ここ化石板なんですよ。
- 873 ：
- OSにContikiでネット対応までは見込んで良いだろうな
TCP/.IPとWebブラウザはこれで対応できるんだし
- 874 ：
- 8bitCPUでブラウザは動かせるんですか～？
- 875 ：
- 化石なのはいいけど文字コードまで化石だと利便性損ねると思うよ
- 876 ：
- 化石の文字コードは低スペックに特化した結果なのだよ。
JISじゃ糞重く面倒だからSJISが勝利したのだ。EUC？ アホですね。
- 877 ：
- まあ漢字TVRAMは句点コードを受け付ければいいよ
俺はOSの内部処理はSJISかEUCで書くけど、アプリはutf8でも16でも好きにすればいい
- 878 ：
- >>870
嘘言うな
考案者の当時マイクロソフト在籍の山下氏の発言がネットで拾えるから見てこいや
三菱Multi16のCP/M86上のBASIC実装にあたって考案されたので思いっきりマイクロソフトも絡んでるしCP/M80用でもない
- 879 ：
- >>871
unicodeの体系がおかしいんだよ。JISを無視して無茶苦茶な順序で並べやがるから、ソートがとんでもなく面倒なことになった。
そういう文化の押しつけをするような奴を喜んで使うとか、日本人として頭おかしいだろ。
- 880 ：
- JIS第４水準まで対応したら中国語も日本語フォントでほぼ代用できるしもとから英語ロシア語ギリシャ語が表示できるからUTF-8でなきゃダメという理由がない。
半島の猿人が使う文字が表示できないぐらいだなな。
8ビットパソコンでUtf-8を採用する技術的メリットないし運用上のデメリットもほとんどないしSJISでええやん。
- 881 ：
- 文字コードはSJISで良いとしても、改行コードはLFだけにして欲しいし、
^ZがEOFみたいなクソ仕様はやめて欲しいぞ
- 882 ：
- 漢字でソートする自体設計ミスだろう世界統一されて結構なことじゃん
可搬性の悪いガラパゴス文字コードなんて終わってる
- 883 ：
- 仕様がタコのUTFコードをありがたがる基地外ｗ
UTFって新しかろうが、世界共通だろうが、タコな仕様という事実は変えられないんだよねぇ。
チョウセンヒトモドキがバカやったのがトリガーでグダグダになっちゃったから。
- 884 ：
- >>882
ふりがなでソートしろって？８ビット機で？
- 885 ：
- UTF推しのやつって「世界共通」しか言えないあたりバカで低能なのがまるわかりだったｗ
非力なCPUでメモリ空間も狭いんだからSJISかEUC-JPを採用するのは妥当な判断だが、そんな程度もわからんとかバカとか低能だし、無知なのがまるわかりだわ。
- 886 ：
- PCでもスマホでも未サポートが多いじゃん大事なことだからもう一回言うが可搬性が悪い
滅びゆく規格だよ多少メモリー食っても今はストレージも速いから体感差ないだろ
- 887 ：
- >>883
朝鮮関係なくグダグダだろ
そもそも世界中の文字を16ビットに収めるってのがアルファベット圏の間抜けの思いつきだから
中国語と日本語で同じ漢字だから共通にしようとかほとんど知恵遅れ
- 888 ：
- ネトウヨきもちわる
- 889 ：
- いい加減IBM PCに負けたことを認めろ
- 890 ：
- レトロ界隈、増えたよな833みたいなネトウヨ。
40,50代に多いという話も頷けるつーか。教育の失敗
- 891 ：
- >>888
中国は中国、日本は日本で漢字の使われ方が違ってきてるんだからきちんと文化的にも分けるべきで、
どっちが上とかそういう話ではないのにネットウヨとは当てはまらんだろ
- 892 ：
- >>878
そうなんだ
でもそれが本当かもしれないけど見つからないや残念
- 893 ：
- AXのJEGAやJVGAのように
TVRAMにShiftJISコードを書いたら漢字を表示してくれるCRTCがマジで欲しいな
AXのはソフトウェアで実装してたけど、フルロジック化したのが欲しい
正に80年代の夢の一つが叶う
- 894 ：
- μPD7220いわゆるGDCを使うんじゃダメ？
- 895 ：
- ディスコンティニュ〜
- 896 ：
- UTF8は処理面倒だし1文字のバイト数が１～12の可変長って「ばかなの？」だし、
8ビットCPUで処理させるんだしUTF8は却下でいいじゃん。
漢字ROMの配置はJIS X 0213でいいじゃん。
3バイト固定で面倒なことないし。
- 897 ：
- 第一、第二水準の16ドットフォント漢字ROMはそれぞれ128KBに収まってたんやし、それくらいで扱えるデータ量にしないと8bit/16bit CPUには荷が重い
GUI上でベクトルフォントとかは高速な16bit CPUにも処理が重い(遅くても表示に特化するだけなら可能)
CPUに初代Pentiumくらいの処理能力をイメージしてるなら議論が噛み合わないので止めた方がいい
- 898 ：
- EthetnetフレームやTCP/IPの処理も重たい
今の高速8bitマイコンでも外部との通信はシリアル通信のみなのには理由がある
- 899 ：
- >>894
いいと思う
68系な俺としてはHD63484(ACRTC)を使いたい所だけどこいつは16bitバスなので使うならHD6345(CRTC)だけど描画機能が貧弱だからやはりμPD7220Aになるかな
- 900 ：
- 900
- 901 ：
- LAN周りは直にEtherドライバを叩くのはきびしいというかほぼ無理だろ。
そこで反則的な術「内蔵モデム」を使おうｗ
インテリドライブ＋DMAとは違うから黒に近いグレーというか、グレーに近い黒だけど。
ありものとしては（そして俺が使ったことあるのは）CPUからシリアルポートに見えるX-Portってやつがラントロニクス社からでてる。
いちおうTCPだけじゃなくてUDPも対応してる。
1セッションしか張れない外付けTCP/IPスタックとでもいうべきか。
RJ45コネクタな見た目のシリアル＝TCP/IP変換コネクタだけど、CPUからはシリアルポートでつながったモデムに見える。
X-Port（ラントロニクス）のページ
ttp://www.lantronix.jp/products/xport.html
使ったことないけど、物理形状が違う姉妹品
ttp://www.lantronix.jp/products/xpico.html
ほかのメーカーからもこの手のデバイスでてるし、使わない手はないと思う。
- 902 ：
- モデムのATコマンドでWifi飛ばせるESP8266があってだな
- 903 ：
- カセット端子を（アンプ挟んでで）つないで、片方でロード片方でセーブをやって、
ファイル転送もどきをやったことを思いしだした
テープに保存して読むのより半分の時間で済むという画期的アイディアｗ
若かった
- 904 ：
- >>897
いやいや、TVRAMに2バイト書き込むだけだぞ
8bitCPUでも余裕
フォントの展開とかはVideo回路の方が面倒みてくれる
2バイトなので、その気になれば65536文字まで扱える
全角16x16フォントなら32バイト×65536文字＝2MB＝16Mbitだから
それ程無茶な話でもない
- 905 ：
- やっぱり低解像度は正義
PC8001 ポッピングパニック POPPING PANIC レトロゲーム - YouTube
ttps://www.youtube.com/watch?v=6l48xhquSPE
- 906 ：
- >>904
空間全部にROM実装とか贅沢すぎ・・・でもないか。
フラッシュROM１つで済むしね２Mバイトなら。
CPUからフォントデータが読めるといいかな。
1文字分32バイトでいいんだけど文字種単位でやろうとするとキリル文字３３文字、ひらがなカタカナが50文字超えになるから切り上げて64文字分
これだとメモリウィンドウが2kバイトになる。
- 907 ：
- >>906
表示期間中はVideo回路がフォントROMをフルに使うから
CPU側がアクセスできるのは非表示期間のみなので使い勝手は悪い
そもそもVideo回路が勝手に表示してくれるんだから
CPU側がフォントROMを直接アクセスする必要が無いと思うが
- 908 ：
- >>896
utf8は1～4バイト長の範囲な
5～12バイト長のutf8は無い
- 909 ：
- >>907
フォントデータの直読み機能はないよりあったほうが、程度だよ。
98だったか88だったか、その両方だったか。
NECのパソコンがフォントデータの読出しをI/Oポートたたいてゴニョゴニョという面倒だった思いしかない
- 910 ：
- UTF-8は５～６バイトのエンコードも「今は」不正なエンコードになったが、無くなってはない。
合成文字が存在するので1文字目に合成文字の1文字目の判定と、後続文字の合成文字の2文字目の判定をしなきゃならん。
UTF8のコードの文字判定だけさせるなら8ビットCPUでもいいだろうが他にも色々な処理をする前提ではUTF8採用はバカとしか言えんわ。
- 911 ：
- >>910
合成文字はJISにもあった
そもそもJIS漢字にアクセント記号付きアルファベットや丸付きの数字が無かったのは合成前提だったから
まぁ第三水準で追加されたけどね
- 912 ：
- 不正コードは対応しなくてもいい文字列に問題があるならそっちを直せってだけだし
豆腐が表示される程度だろ
ガラパゴスコード押すやつもバカよねまあここでムダに見煽り合っても結局はシステ
ム周り書いた人の決定に従うしか無い
- 913 ：
- >>844
VAはスプライト側にテキストの機能盛り込んでてRAMも共有
水平スプライトオーバーするとテキスト画面も壊れるという仕様ｗ
- 914 ：
- 日本人が苦労して作り上げたものをガラパゴスとか言う奴ってなんなん？
そんなに毛唐が作ったものがありがたいんだったら、なんでこんなスレにいるんだ？
- 915 ：
- 独自の進化を遂げたって意味でしょガラパゴス
- 916 ：
- ハードに合わないとさんざん言われてるのに技術的な裏付けなしでUTF8推すしか能のないバカはR。
運用上のメリットの説明もまともにできないでUTF8推すだけのバカはR。
UTF8が良い、UTF8にしろ、と言うなら区点推し、JIS推し、SJIS推しを説得しろ。
できなきゃ死んでろ。
- 917 ：
- 1バイト目がすぐわかる
- 918 ：
- 何回も書いてんだろバカお前がR 可搬性が悪い将来性がない
- 919 ：
- JIS推し、SJIS推ししてる奴はそうすればいいじゃん
将来性もないのにバカだとは思うけど信者を説得するとか無駄なことをしてもしょうがないw
- 920 ：
- 可搬性とは？
外に出す話ならアプリが勝手にやればいい話だろ
なんで内部コードにわざわざエンコード／デコードが必要なUTFを使うんだ？
- 921 ：
- 「究極の8ビットパソコン」からデータを持ってきた側、あるいは持っていく側で変換可能なのだし、Windows系ならSJISはそのまま使える。
既存のツール類でもSJIS＝UTF-8変換できるので運用においても「UTF-8でなければならない」というクリティカルな理由にはならん。
「可搬性確保のため」にUTF-8を採用するデメリットは「処理およびハードの複雑さを抑制する」ためにJIS系（区点、SJIS、EUC-JP)を採用するメリットを下回るので、UTF-8は却下という結論は変わらないな。
- 922 ：
- 軽くまとめててみた（まとまってないことが纏められたとも・・・
CPU：8ビットCPU。モノコア前提だけどマルチCPUも話題になってはいる。
Z80系(Z80H、改造Z80、eZ80…）推しの人、6809系（6309系）推しの人がそれぞれ複数。6502系（6502互換）推しの人。あと6502連呼の基地外が一人w
OS：CP/M上位互換（Z80系CPU推しの人たち）、OS-9（6809系推しの人たち）ぐらい？
メモリ：64k以上。MMUつかって1M案、バンク切替えで2～4M案。「メガ単位乗せろよ」的な煽りする無責任なバカも居る。
画面：
グラフィック：(ピクセル数と発色数はほぼ決定)
640×200×4bpp 4ビット／ピクセルのパックドピクセル、プレーン方式共用 16777216色中16色。CPUから見える範囲は16kバイト。
サイズのバリエーションとして640×400、320×200、320×100。
スプライト16x16。漢字外字兼用？
VDPなどの支援ハードあり、詳細未定。サブCPU、ヤマハのGC、μPD7220A。
テキスト：
グラフィックとは別画面で重ねテキスト・グラフィック重ね合わせ可。
漢字TVRAMあり、PCGあり（外文兼用で2000字）
漢字フォント用のメモリは2Mバイト。データはスカスカだけど2M確保しておくｗ
フォントROMの割当てはJIS区点コード。
登録フォントの範囲はJIS X 0208:1997？ JIS X 0213:2004？
日本語変換：詳細未定
単漢字方式（文字コード入力）案、単文節変換でFDに辞書案。連文節変換でROMに辞書案。
ストレージ：
FDD インテリジェントドライブ。2D/2DD/2HD対応、3.5inch、5.25inch（ドライブとメディアがあれば・・・）
HDD SCSI？ATA？USB？ 対応するが詳細未定
CD インテリジェントドライブ。ドライブ自体のオーディオ再生、VCD動画再生を制御して、動画出力はインポートして表示可能。
VCDのインポートは重合わせとか合成とかスクショとるとかは対応しない方向（GVRAMに取込むには処理速度が間に合わないので）
各ストレージデバイス（ドライブ）とのデータ転送はDMA使う前提。
サウンド：
OPNA。PC88やX68にも使われてたから特に説明要らない、と思う。ADPCM用のメモリのサイズはMaxの256k。アタリポートあり。
LAN/無線LAN：
X-Port、ESP8266を搭載。CPUからはシリアルにつながったモデムに見える。
- 923 ：
- >>921
日本語が変だった。
×「可搬性確保のため」にUTF-8を採用するデメリットは
〇「可搬性確保のため」にUTF-8を採用すデメリットは
×「処理およびハードの複雑さを抑制する」ためにJIS系（区点、SJIS、EUC-JP)を採用するメリットを下回るので、
〇「処理およびハードの複雑さを抑制する」ためにJIS系（区点、SJIS、EUC-JP)を採用するデメリットを下回るので、
酒飲みながら書くとおかしくなるなｗ
- 924 ：
- あれれ・・・？
また違ってるｗｗｗ
UTF8採用のメリットはJIS採用のデメリット下回るんだよｗｗｗ
それが結論ｗ
- 925 ：
- デフォルトでユニコードならそういうムダなアプリ設定も変換もいらなくなる
エンコードの手間ったって分岐が一個増える程度フォント拾うのも大した手間じゃないし
win mac linux スマホ ネット上のデフォルトだし JIS系なんて時代錯誤
- 926 ：
- 分岐一個は無理っぽいが0-15のテーブル4つ用意してORすればいいのか
重いってことは無さそうだがな
- 927 ：
- 1文字ごとにそれ
- 928 ：
- それこそGDCがハードでやってくれればいいんじゃね
- 929 ：
- 俺もUTF8の利点が国際化と可搬性だけじゃ納得されてやれん。
16bitユニコードだとASCIIで無駄使いがでるし64kしかメモリ空間がないCPUでは致命傷レベル。
利点として運用的な面なしか挙げられない時点でUTF8の負け確定。
- 930 ：
- 8bit機より遥かにリッチな環境でnkf一発で変換できるんだから
遅くてプアな環境では低負荷で都合のいいやり方でやらせてもらえばいいんだよ
だいたいフォント(漢字ROM)が区点コード並びなんだからそれをシフトするだけで済むShiftJISやEUCは時代と仕様による要請でもあった
時代性しか考えずutf8なんか推すアホがおかしい
- 931 ：
- >>922
乙！
でもめっちゃ使い勝手悪そう(笑)
最優先はCPUの高クロック化とバンク切替とRAMディスク込みでメモリをどれだけ載せられるかかな
- 932 ：
- UTF-8推しは8bitの実機を触った事が無いのだろう
- 933 ：
- UTF16の欠点はUTF8には当てはまらんだろ半角は1バイト印象操作してまで必死だねぇ
- 934 ：
- GDCにメガロム持たせんならUTF8フルスペックで絵文字まで余裕で載せられるがな
RAMにPCGパターンの方が潰し効くけどな絵文字もカラフルになるってばよ
- 935 ：
- ビデオCD搭載とか正気かよ
VCDドライブのマイコンの方が強力じゃん？
320x240x24bpp30fpsをインポートってそんな広帯域のデータバスがどこにあるんだよ
- 936 ：
- グラフィックも640x200固定ってマジなの
今時FullHD環境を考えられないのはさすがに頭おかしいよ
640x400を3倍で1920x1200だけど
640x360(x3倍)モードくらい想定しないのか
映像出力もHDMIかDisplayPortだろう
- 937 ：
- 「やったらー！！！」
「！？？」
「やってやらー！！！」
「！？？」
「8bit機でもフルHD採用してやらー！！！」
「・・・メモリはどうするんだ？最低６メガは必要なんだぞ？」
「単色だー、単色なら256kBで済む、これなら8bit機でも何とかなる！」
「マジかい・・・」
- 938 ：
- TVRAMが16KBバンクに収まると聞いて
フルHD対応しない手はないと思ったね
GVRAMはまあ頑張れ
- 939 ：
- 単色プレーナVRAMがいけるなら、マルチバンク化すれば多色化できる。
多色化できるなら、いずれスプライトとBGも乗るだろう…おれは興味ないけど。
- 940 ：
- 珍妙なモデム？搭載も反対だな
ただ16bytesFIFOのUARTでも乗せときゃいい、それこそ16550互換UARTとかな
バッファが貯まったら割り込みで起こしてくれれば極楽環境だわ
- 941 ：
- 画面サイズは「めもりがー！」って騒いで「640x200なら16kに収まるし」「しゃーないそれにしよう」と繰り返されるから640x200は決まったようなもんだ。
色数はも8bpp（やそれ以上）が挙がっては「VRAMがI/Oポートの先にあれば」「描画が間に合わねくね？」、「プレーン数増やそうぜ」「1ドット書くのだけでも時間かかるぞ」が繰り返されて4bppに落ち着いてるから決まったようなもん。
8ビットCPUなマシンで24ビットRBGのフルHDやQWUXGAが実現できるなら誰もCGAサイズにしねーよｗ
- 942 ：
- 1983年縛りなら640x200もわかるんだけど
このスレはそんな縛りは無いしな
CPUから直視可能なメモリ空間が64KBしか無いからVRAMバンクは大きくても16KBまでにしてくれ、というのは当然の要請だが
VRAMバンクを4枚までにしてくれなんて俺は頼んでない
16KBx256バンクのVRAMがあってもいいじゃねーか
それで仮にメモリバス200MHzノーウェイトでもフルフィルに要する時間とか考えたら負け
- 943 ：
- FullHDはグラフィック対応しないで、テキストとセミグラフィックで良いだろう
まあ一番普通であって使える年数も長いモニターに対応しないのも何だし
240桁135行ならMZ-700のゼビウスよりもゲームになる
- 944 ：
- まあ今時の環境で考えるなら16:9モニタ前提で、640x360/320x180は盛り込むべき
8bitバス/8bitCPUからの取り回しを考えれば4プレーン16色はバランスいいと思うけどね
あとは16KBを64x64ドットでRGBα各8bitのウィンドウとしてアクセスとかすれば
何百バンクあってもいいなら2kどころか4kや8k解像度すら射程距離
まあ書き換え速度は気にするな表示できることが肝要だ
FullHDでも640x360の3倍ストレッチや960x540の2倍角表示で回す方向も考えたらどうだ
まあ仕様を詰めるのにこのスレ使われるのも迷惑だが
- 945 ：
- ちなみに24ドットフォントの方がきれいに割り切れる
でも男なら16KBバンクギリギリの16dot表示だろ
- 946 ：
- https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Elizabeth_of_Russia_as_Olympic_goddess_by_L.Caravaque_(1710s,_Russian_museum).jpg
- 947 ：
- >>935
スーパーインポーズと静止画取り込み用のデジタイザだよ
- 948 ：
- どう見ても8ビットじゃ無理なことを実現したいなら自作板にでもいけよ。
最新のマザボつかってLinuxいれてオレスゲーしてろよ。
Linuxならインストーラー任せで突っ込んでもUTF-8対応だぞ。
- 949 ：
- >>947
VCDの映像とスーパーインポーズ → NTSCやPALのアナログ信号の入出力を新規に取り付けるのですか？頭おかしいよ
VCDの映像出力をデジタイズ → デジタイズした320x240x24bppx30fpsのスチル画像データを伝送するバスは何処に？頭おかしいよ
- 950 ：
- 毎秒6.5MB以上を読んで書けないといけないので、ノーウェイトかつ1クロックで動作できたとしても14MB/sec以上の8bitバスが必要。しかもビデオCDの映像のスチルデータバスをVRAMへ押し込むだけでバスが飽和する
頭おかしいよ
- 951 ：
- 頭ごなしの否定ではなく、出来る方法を考えるべきだ(ｷﾘｯ)…とか言っておいて
出来る方法を考えられない人々
出来ない理由は感単に数字が出る
- 952 ：
- 目上視線で頭ごなしに否定しかしないバカに言われても説得力ないんですけどぉｗ
まぁ、馬鹿で無知で基地外の否定君には建設的な意見出せってのは無理だね。
自分の意見以外は入らない特殊な目と脳してるようだしぃｗ
- 953 ：
- そんなにビデオCDが見たければ、それこそサブCPU Core i9 GPU GTX2080世界だな
個人的にTCP/IP対応はシリアルの先にラズパイでもぶら下げる事になるのかと思ってるけど(だからスレにも書かないで来た)
珍妙なxmodemだかなんだかを仕様にぶち込もうみたいのも本当に萎える
一方で、ビットマップグラフィックは1bppでもいいから最大解像度フルHD対応しようぜ…みたいな方向は好きだ
- 954 ：
- データバスはすべて8bit縛りです。無理な仕様は諦めましょう。
- 955 ：
- 自分の望む回答しか見えないタイプ
- 956 ：
- Full-HD(1920x1080)のモノクロなら254kになるから16kバンク16ページでギリ収まる。
24ビット色だと384ページ必要になってしまうので実用性ないけどな。
- 957 ：
- 敵は狭量な小人物に決まっていると思い込むばかりで、自分が評価に足る人物たり得ていないという厳しい可能性については思いもよらない無能
だからお前は馬鹿なのだ
- 958 ：
- >>949
スーパーインポーズって別にコンポジット限定じゃないぞ
アナログRGBでのスーパーインポーズだって有った
ビクターのMSXとかさ
TMS9928の色差出力からRGB作って21pinアナログRGBとのスーパーインポーズさせてた訳
- 959 ：
- まあFHDは1bppいければ十分でしょ
多色グラフィックは640x360上限で、480x270や320x180、240x135とか付けて正数倍ストレッチで出力できればいいよ
正数倍表示をフルスクリーンのみではなく、FHDの任意の位置に表示できればなおいいが
CRTCへの要求は高くなるがCPU側は無理がない
- 960 ：
- >>958
それモニター側の機能ですよね
今時VCDやLDからのアナログ入力を付けろとでもいうのか
もうスーパーインポーズとVCDはNG入れろ
- 961 ：
- 横240x135だと長辺が256以下になるから、ゲームキッズおじさん待望のスプライトも実装しやすくなるんじゃね
BGも縦横スクロール自在だぞよかったな
スプライトの仕様策定はよそでやってくれ
まあこのスレもう終わるが
- 962 ：
- >>960
ビデオ録画用のスーパーインポーズ編集だから外部合成だよ
MSXで出来てた事も出来なくて究極かよ
- 963 ：
- >>962
はい。21世紀の今となってはLDもビデオCDも、それらの動画出力とのスーパーインポーズ機能を持つブラウン管モニターも、供給メーカーがありませんので。
- 964 ：
- アナログでやる → 今時もう機材が無い
デジタルでやる → デコードや伝送コストを考えられない無知、無能、禿、水虫、いんきんたむしの無職童貞の妄想
頭おかしいよ
- 965 ：
- >>963
ブラウン管依存じゃないぞ
単なるアナログRGBの信号処理
時代を問わないスレであって、有る特定年代のデバイス同士を組み合わせて出来れば妄想出来るスレだろ
最新の究極となるとフロッピーは止めようってなるがな
- 966 ：
- つーか(ﾌﾞｰｲﾓ)の理想ってどんなのか聞きたい。逆に。
- 967 ：
- >>965
CRTならRGB側が抜き色の時だけアナログ映像に切り替える単純な回路で実現できるが、
液晶モニタ等のデジタル化された表示パネルではアナログ入力もモニター内でデジタイズしなければ表示のしようもなく、しかも合成処理もデジタルで行う羽目になって、
同等の結果を得るための演算コストやゲート規模が文字通りに桁違いなんですが…
まあ、理解できていないからこそ言える妄想ですよねー
- 968 ：
- もう寝ちゃうから、最後にちょっと怖いこと言っていい？
VCDおじさんが、なぜDVDやBDではなくVCDなどという日本ではろくに普及すらしなかった半端な規格に拘泥する理由ってさあ…
まあ、BDはおろか、DVDすらCPUデコードにはSIMD命令SSEの載ったPentium3が必要だったので、8bit機でできる訳がないことは理解しているからだと思うのだが…
VideoCDに関しては、うまくすればできるのでは…と、本気で思ってるんじゃねーかな…うわっ怖ぇ！言っちゃった！マジで頭おかしい！！
- 969 ：
- >>967
ビデオテープ録画編集なのに、そんな処理でどうするのよ？
- 970 ：
- (ﾌﾞｰｲﾓ)さんって、苦手
- 971 ：
- 俺もこの技術音痴のくせにプライドと承認要求ばかり高い無能野郎、ほんと嫌い
お前みたいのが来ていいスレじゃないんだよ
ボクの機嫌取れよ、技術的に無茶苦茶な事言ってても流せよ、オレを褒めろよ、相手してくれなかったら差別されたとゴネるぞ
…リアルでもいるわこういう無能オヤジ。オールドPC界隈は特にな
- 972 ：
- オレを拒絶するなー!!
…いや、するよ。全力で。迷惑だもん。
許容してもらえる余地が、どこかにあるとでも思ってるのか？ねえよ。身の程を知れよ
トイレに起きてキモイもん目にしてしまったので、手加減なしの本音をﾌﾟﾘｯと排泄。まあそういうことなんで
- 973 ：
- モニターはコンポジット入力を想定してるのかな
今はコピーガードの観点からS端子もほぼ絶滅しているので、HDMIかHDSUB15pinのアナログRGBくらいしか選択肢が無いのも辛い
- 974 ：
- テキスト、グラフィック、スプライト、独立３画面設計
- 975 ：
- >>955
> 自分の望む回答しか見えないタイプ
それならいいんだけど、自分の望まない回答に言いがかりつけるタイプだから…
- 976 ：
- >>965
フロッピーは要らんだろ
どうしても必要ならばUSB経由でいいよ
- 977 ：
- >>971
他人に技術音痴と言う前に、ビクターのMSXがどうやってスーパーインポーズした動画をビデオテープに録画てしてるのか解説してよ
ブラウン管で出来てるテープも、ブラウン管でテープに磁気記録してるテープも知らんので
- 978 ：
- Full-HDのディスプレイに出力するためにピクセル数減らしますって本末転倒。
- 979 ：
- >>975
気に入らんものを叩き潰して何が悪い
- 980 ：
- >>977
ビクターのMSXとか興味ないんで
MSXでできるならMSXでやっててくれる？
ここは21世紀で、MSXのスレじゃないんで
いまさらコンポジットビデオの入出力なんか要らねえよ
- 981 ：
- >>980
否定するために、できない技術は思い付けても、できる技術は思い付けない無能だったか
- 982 ：
- >>981
そもそも要求性能すら見積もれない無知無能に、これだけ法外な性能が必要になるので無理だよおバカさんと言ったら、俺様の妄想を実現できない無能めと罵られた月曜日の朝。
この不条理なんとする
つうか馬鹿のくせに偉そうにしてるのはなんでなの？何様のつもり？
- 983 ：
- フロッピーもCDビデオドライブもutf8もコンポジットビデオ合成も全部要らないよ
これ推してる奴らはわかっててわざと邪魔したくて言ってるだろ
- 984 ：
- あーあ言っちゃった…
>>983
- 985 ：
- >>979
でもお前毎回叩き潰されてるやんww
- 986 ：
- >>985
事実なら俺が叩き潰されたという案件すべて提示して見せろ
- 987 ：
- >>982
RGBでスーパーインポーズしてたMSXが実在してたよって説明に、頓珍漢な技術音痴な間違った技術解説をするから悪い
- 988 ：
- スーパーインポーズはモニタ側の機能で、MSXでLDやVHDの映像と合成して実現していたゲーム等は、少なくとも単純な方法では合成結果を録画することはできないはず。
「ビクターのMSX」でMSXの映像出力とビデオテープの再生映像を合成して別のデッキで録画することが本当にできていたとすれば、
それはスーパーインポーズではなくアナログのクロマキー合成という機能で、21世紀の今では製造できるメーカーはもう無いと思うよ。
MSX2であれば、外部入力のNTSC信号をカラーバスにパススルーして、MSX2のグラフィックと合成した結果をコンポジットビデオに出力する機能がVDPに標準でついていたので、
実際にソニーや松下がこの機能を活用したハイエンド機を投入していたし(ビクターが出していたかは知らない。彼は「ビクターのMSX」と言っているので、MSX2ではないだろう。当然V9938の機能も前提とはならない)、
MSX2ではないが、この機能を流用した一般消費者向けのテロッパーが製品化されたりもした(MSX2の死滅後に)。
いずれにしても、究極の8bit機にV9938を搭載するのでもなければ低コストで実現することは困難だし、今更アナログのクロマキー合成機能とコンポジットビデオの入出力を搭載するなんて気違い沙汰だと思う。
しかも映像ソースがLDやDVDでもなしに、ビデオCD？不毛な論争としても不毛すぎる。人格的に未熟で負けを認めて謝れないなら、黙ってスレから去って欲しい。
- 989 ：
- X1のスーパーインポーズもモニターの機能だったね
むしろX1の凄いところは、デジタル8色でキャプチャするオプションが実在したところ
8色のディザリングを行いながら0.5FPSくらいでVRAMへ転送するという
凄いは凄いけど、何に使えるのかはよくわからなかった
- 990 ：
- >>987
俺のスーパーインポーズの説明が技術的に誤りであったという根拠の提示が無いようだが？
- 991 ：
- >>989
あったなあビデオキャプチャボード。
ビデオキャプチャと言いつつ、撮れるのは静止画のみ。
それもデジタル8色のガビガビの画像で、これでどうしろと…って代物だった。
Oh!MZ誌で大はしゃぎで特集されていたのを、微妙な顔しながら眺めてたわ
- 992 ：
- MSXもNG入れた方がいいのかね
程度の低い奴が多すぎる
- 993 ：
- FM-77AV40あたりでも
スーパーインポーズ→ビデオデジタイズで
静止画取り込み出来てたはず
4096色だか26万色だか知らないが。
- 994 ：
- >>990
スーパーインポーズはモニタ側につけなくてはならない技術ではないし
タイミングがシビアなだけでそこさえハードウェア支援をすればそんな難しい機能でもない
あなたの説明はスーパーインポーズの原理を到底理解しているとは思えないものだったから
- 995 ：
- 現実に実在したMSXでもX1でも、スーパーインポーズはモニター側の機能で実現していた訳だが？
実在しなかった架空の仕組みですスーパーインポーズは同等の結果を得る事もそれはできるだろうね、
具体的な方法の提示がないから君が頭の中でしている妄想が現実に機能するかどうか判断のしようもないけどね。
そもそもにして商品券として実在していたスーパーインポーズの実装はおろか、スーパーインポーズとクロマキー合成の区別もついていないアホの愚痴から
「お前はスーパーインポーズと仕組みを理解しているように見えない!!(ｷﾘｯ)」…と大見得切られてもですね、その、大変失礼ながら、失笑しかできない(爆笑!!)
- 996 ：
- >>967 の説明であってんじゃないの
UTF8押しの俺が言うのも何だが おはよ
- 997 ：
- >>988
https://www.msx.org/sites/default/files/download/2015/10/victor_hc-6_pamphet.pdf
このビクターのHC-6のカタログでは2万円のスーパーインポーズアダプターで、
アナログRGB出力をビデオテープに録画できると宣伝してる
映像のビクターの宣伝なんだから間違っては無いはず
廃れたロストテクノロジーとは言えと、アナログRGBとして当時は使えた技術って事ですね
まあビデオ入力をモニターのRGB出力でRGB化してからRGB合成って、
合成後がリアルタイムでの確認できなそうですが
低価格化で仕方なかったのか？
- 998 ：
- それでその「ビクターのMSX」というのはコンポジットビデオの入出金とビデオ合成の回路が外付けされていたりしたんですかね？そもそも実在したのか？
スーパーインポーズで実現しているLDゲームのゲーム画面を録画しようとして一筋縄で行かず、結局管面撮影した…なんて話もあるくらいなのにな。
MSX2のVDPを流用したテロッパーが価格破壊した結果、貧乏な地方TV局なんかで使われていた(発色と文字フォントでMSX2由来とわかるらしい)という話しは俺も聞いたけど、MSX1の話じゃないし。
- 999 ：
- 間違ってんのはモニターの機能ではなくアナログ信号の合成できる性質とVDPの信号切り替え機能でやってるってこと
- 1000 ：
- >>998
カタログだけで実機が無いって、そこまで疑い出したらネット上での対話できませんよ
実機の前での対話のみになってしまう
- 1001 ：
- 2ch.scからのレス数が1000に到達しました。
きょうはじめてぼくんちにぱそこんがやってきました
おまえらの作った／改造したハード教えてください
マイコンに使ったお金、今ごろ貯めていたら…
りさぷ～のＰＣ
今でもX680x0ユーザー全員集合 Part 57
【広島】松本無線に来てた人のスレ【同窓会】
PC-9821/9801スレッド Part84
８インチ・フロッピーの思い出
なぜ288＊224のPCが出なかったのか？
VAXだろ、やっぱ
--------------------
【分離】為替板キボンヌ【独立】
【BS】バトルスピリッツ デッキ診断スレ 1ターン目
【こうや・9000系】南海電鉄､車輌専用スレ18【平成完走へ】
韓国さん大卒の就職率が11％79％が就職できていない
8文字限定しりとり Part6
【原発】原発情報4079【放射能】
中部横断自動車道が完成するまで語り続けるスレ5
【衝撃】モー娘。佐藤優樹が同級生を転校に追い込んだ話は事実だった
【2016】同志社大学ラグビー部 part126【BREAK】
■■■DRAGON GATE総合スレPart283■■■
済州の集団暴力◆フランス報道｢韓国人は醜悪で無様｣
雑談 タケシ・パウダー・オダ
俺達は重度のドライブ依存症[3万㌔/年以上] #2
【PS4】Fallout4 フォールアウト4 Vault274【FO4】
【どーして】何かと割に合わない役回り【ピアノ編】
■iTSCOM■イッツコム 15
■■■【3代目】レクサス LEXUS IS 43■■■
【万座四万伊香保】群馬の温泉9【水上老神猿ヶ京】
台湾人は所詮シナチョン
【Download】- μTorrent質問スレ Part24
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
