PC-88VA3

1 ：2012/08/21 〜 最終レス ：2013/09/20

前スレ
PC-88VA2
http://ikura.2ch.net/test/read.cgi/i4004/1168522493/
前々スレ
PC88VA
http://bubble5.2ch.net/test/read.cgi/i4004/1041138049/
PC-88VA資料室
http://www.pc88.gr.jp/~va/
PC-88VA Wiki
http://www.pc88.gr.jp/inside88va/wiki/
PC-88VAエミュレーター「88VA Eternal Grafx (VA-EG)」
http://www.pc88.gr.jp/vaeg/

2 ：

2get

3 ：

Vampire Ace

4 ：

次スレがVA4になってしまうのかと思うと今から心配で

5 ：

前スレ落ちたね…　
>>4
VA3 +1 とか…？

6 ：

確かVA3の後、後継機が予定されてたんだよね？
結局ポシャったとはいえコードネームだか仮の名前だかくらいは発表になってたと思うけど

7 ：

VA3に興味ある
どの辺を機能アップする予定だったのかな
98との互換性は更にアップしたんだろうか

8 ：

×VA3に興味ある
○VA3の後継機種計画に興味ある

9 ：

かつての後継機計画自体は知らないけど
とりあえず欲しい機能を挙げてくと
(現在の技術フル稼働というより、さしあたっては当時の技術の順当な延長っぽいスペックで考えて)
テキスト&スプライトVRAMの更なる増量
スプライト&SGPの描画能力の更なる向上(できればテキストがスプライトオーバーで消えなくなると尚ありがたい)
グラフィックの面数やVRAM容量も強化(256色以下モードで4枚、65536色でも640x408フルで2枚とか。あるいはそれ以上)
CPUの高速化&PC-98との互換性強化
で、CPUをどうするかやっぱり困ってしまう
互換性をとるなら、Z80互換モードつきV30上位互換CPUが欲しいところだけど
PC-98互換のためのVRAM移動も兼ねて386系(386かそれ以上)が欲しくもある
(互換性向上をハードでやってくれるのが好ましいけど、無くても386ページング機能でVRAM再配置ならある程度対処できる的な意味で)
とりあえずの理想としてはPC-9801RAのごとく両搭載なんだが…(妄想マシンでコストを考えてもしょうがない？)

10 ：

当時はまだHDDが高価だったから、BIOSのみならずOSの機能の大半もROM化して
16bitPCとしての機能パワーと軽快さをFDDベースの環境で両立させようとした方向性は正しいと思う。
スペックはVA2と同等で軽量コンパクト化、価格帯をかつての8bitホビーPC上位機と同等の15万円台に下げて
VA本来のホビーPCとしての魅力をより広く体験してもらえる普及機が欲しかったかな。

11 ：

オクにVA用のLattice Cが出てたんだな
気付くの遅れて入札できなかった
どんなVA用のライブラリーがあるのか気になる
スプライトとか音関係のライブラリもあっったのだろうか

12 ：

256色モードは固定パレットで、32色モードは8ビット中3ビットも無駄になるということで
どうにも使い辛かったのが…。6万色は更に色々な制限があったし。
32色モードを256色モードに拡張して、パレットを256色使えるように拡張して欲しかったり。
パレット付き256色ならかなりの絵が描けるはず
パレット256色といえば、業務用(アーケード)ゲーム機における8bit後期〜32bit初期くらいの標準的スペックだから
やっぱりそのくらい使えればかなり使いでがあったのではないかと。

13 ：

FMTOWNSみたくなったんだろうね結局

14 ：

似たような位置づけのX68000が最後まで「TOWNSみたい」になった訳では無いところを見る限りでは
そんなにFM-TOWNSそっくりにならずに済んだかもしれないように思えるけども。
まあintelでDOSって共通点がある分はX68000よりPC-88VAの方がTOWNSに近いと言えなくも無いけど…。
PC-88VAには本物のスプライトがあるし(SGPもあるけど)、TOWNSのように　ででん　とCD-ROMを付ける事も無かったろうし
NEC自ら「ハイパーメディア」とやらを宣伝文句とする売り込みをTOWNS並にするでも無し
まあそんなに極端にはTOWNSに似ないような気もする。そういうところではどちらかというとX68000寄りというか。
実際PC-88VAには標準的GUI-OSは出なかったし、X68KもSX-WindowやKo-Windowが選択肢として存在はしたけれど
裸のDOS(Human68K)での利用法が廃れたわけでは無かった。GUIを前面に押し出したTowns-OSとは対照的に。
このまま88VAが続いていたら、X68Kの様に「選択肢の一つとしてのGUI-OS」は出たかもしれないけど
それが事実上唯一の環境、とはならなかっただろうなと。
そういえば三機種中一番「テキストVRAMらしいテキストVRAM」を持ってるのもPC-88VAだったりする。

15 ：

ちなみに
スプライト
・ラスタバッファ式(本物のスプライト)： PC-88VA、X68000
・フレームバッファ式(擬似スプライトと呼ばれる)： FM-TOWNS
テキストVRAM
・文字コードからフォントを表示する機構が備わる本物のテキストVRAM： PC-88VA
・テキストVRAMというものの実態はビットマップVRAM： X68000
・無し。エミュレーションのみ。： FM-TOWNS

16 ：

＞ででん　とCD-ROMを付ける事も無かったろうし
PCエンジンのCD-ROM2を外付けで繋げられるようにはなったんじゃないかな（棒

17 ：

長文書きたがるやつほど中身ない書き込みだよなあ
したがって読まない

18 ：

ノーマル88が高解像度、多色表示、FM音源、大容量メモリ・FDと進化して
8ビットCPUではこれらを扱いきれなくなり16ビット化したのであってX68対抗とかでは無いと思う。
ホビーユーザーがうまく移行してくれれば88MCなんての出さずにVAにCDROMが付いたはず。

19 ：

VA用のSCSIボードとCD-ROMの抱き合わせがあったら良かったのに

20 ：

ノーマル88の後継出すのやめてVAだけにし、NECの底力で198000円にしたら売れたのに

21 ：

まあ88MCにCD-ROMがついちゃったくらいだから
88VAが存続してればCD-ROM内蔵モデルくらいは出たと思うけど。
でもFM-TOWNSみたいなCD-ROMまみれの世界にはならなかっただろうなーと…。
なんかHDD前提時代になってからのPC-98みたいに、CD-ROMも使われるけどそればっかりじゃない状態になってた気がする

22 ：

>>20
N-BASIC削らずにそれがやれていたら、本格的にPC-88VAに移行できてたかもね。
PC-88VAの普及の見通しに自信が持てない→ソフトが出ない→なかなか普及しない→最初に戻る、の悪循環だったから…
これからはホビーパソコンはこれでいくんだ！という覚悟が足りなかったのが成功出来なかった原因かなあ。
成功したあかつきには性能向上のみならず更なる互換性向上を実現した新モデルを出してほしかったなあ。
シルフィードとかソーサリアンとか。

23 ：

>>14
いやいや、VAやTOWNSは既存のPCを機能てんこ盛りに拡張したような感じだけど
X68は全く土台が新しいパソコンという感じ
触れた感覚からしても全然違う

24 ：

OSやディスク周りは98のコピーという印象が強かったが

25 ：

んでも、最終的に勝ったのは既存のPC機能を拡張しまくったAT互換機だべ
68はゲーム機みたいなもんで一世代でお終い

26 ：

>>25
スーパーX68000にはならなかったね

27 ：

X68000XVIにX68030まで出たのに一世代って事は無かろうよ
XVIはともかくX68030はさすがにマイナーチェンジとは言えないはずだ

28 ：

大雑把にはMPUがちょろっと変わっただけだしマイナーチェンジの範疇だろ。

29 ：

ちょろっとかよ
公称16bitCPUから公称32bitCPUになったってのに。

30 ：

ゲーム機の寿命も5年程度
最後にちょろっと変なのを出すこともある
でも実際にその機能は生かされずに終わる

31 ：

X68030が「変なの」「生かされなかったもの」とは到底思えないがなあ
CPUパワーが渇望されてなきゃ060turboなんて生まれるはずもないのに

32 ：

>>31
060turboがバカ売れしたならその通りかもね

33 ：

ユーザー発のキワモノである事考えりゃバカ売れした部類に入れてもいいくらいなんだが

34 ：

>>33
具体的な数字教えて

35 ：

>>33
電倶楽で盛んに紹介されてた、ネットで声の大きい人が頻繁になんか言ってたってレベルじゃないの？
030ユーザーの060turbo所有率とか知ってるなら教えれ

36 ：

俺のティンポなみに極小な数字だろうな

37 ：

ハイパー98との連携とかって無理だったのかな？
互いの機能を載せた拡張ボード差すと互換機化するとか。

38 ：

88VAってNECホームエレクトロニクスじゃないの? H98とは会社が違うだろ。

39 ：

むしろ会社違ってもあったじゃないかそういう補完ボード。
>>25が言うようにAT互換機自体がそうだしさ。

40 ：

>>39
他社のPCでの動作を保証したその手のボードってあったっけ?

41 ：

そもそも同一シリーズでも機種が違う時点で動作保証なんかないだろ。
機能に互換があるなら対応するかはソフトハウスの判断なわけで。

42 ：

ハイパー98って普通の98と何が違ったんだっけ
XAとかXLは超高解像度があった気がするけど

43 ：

普通の98よりハイパー速かった

44 ：

>>41
>そもそも同一シリーズでも機種が違う時点で動作保証なんかないだろ。
FX-GAやTOWNSのボードは、PCによっては動作保証してたり、PCとセットで売ってたりしてたと思った

45 ：

それ、動作検証しているだけで保証じゃないのでは？
動かないソフトがあったら確実に修正してくれるってこと?

46 ：

>>45
ボード売ってる会社が他社のソフトの動作を保証できるわけないべ。常識で考えれ。

47 ：

H98シリーズの特徴
・ノーマル・ハイレゾ両モード対応(H98Sシリーズ除く)
・グラフィックの強化。AGDC、E^2GC搭載、更に256色モード可能(PC-9821とは残念ながら別仕様)
・プリンター端子がフルセントロニクス化し、双方向通信が可能に
・NESA Eバスによる高速な拡張ボードのI/O (従来ボードもNESA Cバスにて使用可能)
細かい点としては
・RGB、プリンタ、FDDのコネクタの形が違うのでH98でないPC-98シリーズのケーブルを使えない
・NESA Eバス用に使用可能なI/Oポートを管理するため、Cバス抜き差しの度に設定が必要(Cバスしか使わないなら不要と思われる)
・RGBコネクタに電源コントロール線も来ているので、専用ディスプレイを使えばディスプレイ側で本体電源を操作できる
・テキスト画面も実はちょっと拡張されている。アトリビュートの拡張と、外字領域の拡大。
・まるで互換性が低いかのような誤解があるが、まず互換性が問題になることは無い

48 ：

>>46
>>41

49 ：

>>48
話の流れ理解すれ

50 ：

>>40が他社だから動作保証があるかって聞いてるから、同一シリーズ（当然同じ会社だ）でも
そんなのねえよって話。

51 ：

そんな物ネーヨ
でも大したことじゃないだろ、脇毛がないのに比べたら
俺、いつ大人になれるの？

52 ：

88VAの後継と言えそうなのは、PC-98GSじゃないかな。NEC-HEだし。

53 ：

PC-98GSはSGP積んでるんだったか

54 ：

後継って言われてもそんなに間があいちゃうとね、、

55 ：

ところが、PC-98GSって何だか開発期間がえらく長かったらしい
PC-88VAの後継機が中止になったのはPC-98GSの開発が決まったからだとか。
その証拠にPC-9801DAの後なのにV30を搭載している。

56 ：

>>55
>その証拠にPC-9801DAの後なのにV30を搭載している。
意味わからん

57 ：

PC-9801RAまではV30搭載してたがPC-9801DA以降はV30が搭載されてない
PC-9801DAより後に出たのにPC-98GSには搭載されている
要するにPC-9801DAよりも前から開発されてたってこと

58 ：

>>57
「PC-98GSって何だか開発期間がえらく長かったらしい」には関係するが、
「PC-88VAの後継機が中止になったのはPC-98GSの開発が決まったからだとか。」とは関係ない話だな。
「その証拠に」がイカンのだろう。

59 ：

するってーとNECの変なシリーズは
87年　VA
88年　VA2/3
89年　98DO
90年　98DO+
91年　98GS
という流れだってことか＠＠

60 ：

>>59
NECの王道シリーズではなく、その変なシリーズが大好きなんだよな。

61 ：

>>55
1987年03月 PC-88VA
1988年03月 PC-88VA2/3
1988年7?月 PC-9801RA2
1989年10月 PC-9801RA21
1990年11月 PC-9801DA
1991年10月 PC-98GS
この当時の88シリーズは年1くらいのスパンでモデルチェンジしてたような気がするので、
VA2/3の後継機の発売目標は1989年03月だったと仮定して、開発中止はその半年前と
仮定すると1988年09月あたりがそのタイミングということになるが、そうすると98GSは
立案から発売までに3年掛かったということになり、そらちょっと「えらく長かったらしい」と
言っても長すぎるんじゃないのという気がする。

62 ：

>>58
「その証拠に」は一行目にかかってる
二行目にかかってると誤解してるのがいかんのでは

63 ：

解釈の曖昧な文章を書くのがいかんのでは

64 ：

日進月歩のPCの世界で3年は長すぎるな
88でも98でもない別機種になるくらいのプロジェクトだろう
その結果がGSだったら超悲しい物語だ

65 ：

VAの後継機について、ここで1考察として語られている
http://www.enpitu.ne.jp/usr4/bin/day?id=41506&pg=20050519

66 ：

>>65
「ブルマに関するあるマニアックな一考察」とかいうのが出てきたんだが……。

67 ：

またかよ
つまんねー荒らししてんじゃねえよ

68 ：

以前、NEC-HEの技術者が書いたPC-98GSに関する論文では、
PC-9801ES（1989年4月発売）をベースに、マルチメディア機能の強化を図った、
というようなことを書いていた記憶が……。
ttp://ci.nii.ac.jp/naid/110003685154
（これだっけ？）
発売時期の割にV30が乗っかってたのは、ESがベースだったからでしょう。
僕は、PC-98GSはPC-88VA後継としての開発ではないけれども、
（MS-Windows 3.0 MME対応の実験的な存在かな）
NEC-HE開発ということでVAの後継っぽい位置付けに結果的になった、
という印象を持ってます。
（もっとも、これは根拠の無い個人的な意見です）

69 ：

>>68
>PC-9801ES（1989年4月発売）をベースに、
開発期間2年半としても異常な長さだな。何でそんな掛かったんだろ?

70 ：

当時は、容量は多いけど書き込みできないCD-ROMというのを
持て余していた感じがあるな。PCでの使い方を模索していたのでは？
8801MCなんてのもやってみたり

71 ：

ESをベースにしたとしても、
発売直後から開発を始めたわけでもないでしょう。
あとは、ソフトウェア側の準備（Windows 3.0＋MME）とか。

72 ：

ESがベースっていう話は>>55の裏付けになるっぽいね
とすると本当に長くかかっちゃったのだろう…
なんでこんなにてこずったんかね。
VASG？に積む予定だった機構を使いまわしてる部分とかもありそうなのに。

73 ：

1990年1月頃にPC-VANで出回ってた噂？だかリーク情報？だかによれば
VA SuperGRAFXの内部構造はかなり後のPC-98GSに似ている物だったっぽい
65536色フル解像度表示可能な画面が従来グラフィックとは別の面として追加されてるところとか
あとPC-98互換モードもつくとか
6月には386SX搭載になるという噂まで出たらしい…
ますますPC-98GSとダブる

74 ：

>>70
思うんだけど、擬似的に多少の空き容量が存在するようにみえて
カスタマイズ可能なCD版RAMドライブとかあっても良かったと思うんだよな。
そうすれば使い勝手は固定ディスクと大差なかった気がするんだけれど。
でもさあ、rom^2では使ってきたメディアだし、富士通にできた事ができなかった
理由ってなんなんだろう？

75 ：

>>74
>できなかった
>理由ってなんなんだろう？
88終了

76 ：

あれだXA後継のつもりでPC-98XAVとかどうだ？
TOWNSのベースマシンもハイレゾ機だったって話だし。

77 ：

88VAじゃなくて98VAでいってほしかったな

78 ：

VAのまま進化してくれればそれで良かったんだろうけども
SRのようにブレイクはしてくれなかった

79 ：

>>74
そういえばそんな一部書換え可能CD-ROMは
セガサターンが採用するってアナウンスしてたなあ…
結局実現しなかったけど。
(セガの予告は大抵実現しないのだ…)

80 ：

そういえばPC-98GSの「GS」って
SuperGRAFXの頭文字取ってひっくりかえしたものっぽいね
本当にそれが由来だったりするかもしれん…
案外PC-98GSには使われてない(VASGで使う予定だった)スプライト機能とかが隠されてたりして…
(VAの従来スプライトと別にVASG専用のスプライト機構が追加される予定だったとか)

81 ：

Graphic
Sound
Visual
Audio
だとしても、似たような命名方式だな

82 ：

PC-98GSはPC-88VA2/3から見るとあまり音源がパワーアップしてないけど
PC-9801から見ると確かにサウンドもパワーアップしてるんだな…。
そう考えるとGraphic+SoundでGSって線も考えられるのか。
音源的に、GSはVA2/3から見て
・OPNAのADPCM用RAM削除
・OPNAとは別にPCM/ADPCM搭載
・DSPでちょこっと音が加工できる
っていうのが違いかな。
細かいことを言えば
・PC-98規格なのでFBEEP音源は無し
っていう違いもあるのか。
あれ？PC-88VAってBEEP音源の音程変えられたっけ？(普通のPC-8801は変えられなかったはず)

83 ：

BEEPの音程変えるのって88mk2に付いてたCMD SINGの事？
FH/MHから削られたって話聞いたような気がする。
あの機能使えるのはmk2の名前が付いた機種(mk2〜FR、MRあたりまで該当？)だとか。
VAもたぶんないんじゃないかな？

84 ：

>>83
それでは無い

85 ：

いまVAのテクマニ(ネットでフリーで出回ってる奴)読んで確認してみた
TCUのカウンタ#1がBEEPの音程とあった
つまりPC-8801(V1/V2)では音程変更できないが、PC-88VA(V3)ではPC-9801と同様に可能という事になる
PC-9801もタイマー用の8253のカウンタの一つがBEEPの音程設定に使われている

86 ：

PC-88VA2の2TD-FDD穴(?)って3.5"ベイとして使えるの？
…いやそこにLS-120かMOのドライブ突っ込めば少しはVA3気分になれるかな？と思っただけなんだけど。

87 ：

あれ飾りで縁取りしてあっただけのような

88 ：

プラスチックだから穴空けるぐらい簡単

89 ：

へー、そうですか

90 ：

蓋が外れる訳じゃないのか…
いちいち別に作るとか、当時は贅沢だったんだな。

91 ：

そういやPC-9801VXあたりに至ってはHDD内蔵モデルとHDD無しモデルで
筐体そのものがサイズから全く別なんだっけか…。
今じゃ考えられんな。

92 ：

同じZ80で60、66、80、88を作っていた頃なんてもっと贅沢だ

93 ：

同じZ80だからいいんだよ
6502、6809、Z80、8085なんてなったら目も当てられん

94 ：

日立辺りが両互換の石開発してたら面白かったのに。

95 ：

そういえば、6809マシンや6502マシンなんかはZ80カードなんかが出てたけど
PC-8801には6809カードみたいな物って無いよね。
8086増設ならあったけど。
PC-9801には68000ボードとかV80ボードとか出てたみたいだ
PC-88VAには無いけど、V50系CPUってCPUコアだけCPUKILLする事は出来ないつくりなんだろうか？

96 ：

X68000にはV30ボードが出てたよ

97 ：

>>95
88も98も、その手のボードって本体のCPU殺さないで動いてるでしょ。

98 ：

>>95
やっぱCP/Mの要望が多かったんでないの、Z80ボード出てたのって
OS-9の要望はナインス、なんちってね

99 ：

>>96
あったのか…
8086系を嫌ってる人の多いイメージのあるX68Kで意外だ…
>>97
そうなの？あまりにレアなんで実物を見たことが無いので知らなかった。
PC-98の場合、特にCバスにさすタイプのCPUアクセラレータ(当然本体CPUになりかわって動く)が出ているので…。

100 ：

>>96
CONCERTO-68K (アクセス)
V30 8MHz RAM512KB 8087ソケット
MS-DOS 2.11対応
VDTK-X68K (アクセス)
V70 20MHz、V70 AFPP、DRAM 2MB、SRAM 128KB

まぁ、68系アクセラレータはいろいろあるけど
H.A.R.P MC68020 20MHz
H.A.R.P-FX MC68030 50MHz
これは、あの天使たちの午後のジャストが発売ｗ

101 ：

VAでUNIX系動かせるようなボードはあったんだろうか？

102 ：

MINIXなら追加ボードなしで動くんじゃないの

103 ：

Xサーバとかどんな実装になるんだろ？

104 ：

V70のっけたボードって何に使ったんだろ。

105 ：

8086リアルモード時代のMINIXなんて本当にオモチャだったんでは。
Xサーバーなんかは動かなかったんじゃないかなー
多分PC-88VAに移植された実績なんかも無いと思う
もしかしたらPC-98になら移植されてた「かも」ってレベルだし。

106 ：

>>104
当時はそれなりに有力視されてたんじゃなかったっけ＜V60系CPU
普通に新CPUを試したいとか演算能力が欲しいとか、もしかしたらPC-UNIXが実現できたらいいな的アイテムだったかも。
確かV70には8086エミュレーション機能もついてなかったっけか
だから頑張ればDOSのソフトを動かす事も理論上は可能だったのでは。
そんなソフトを実際に書いた人が居るかどうかは知らないけど。
とにかく言える事は、実用性はともかく、当時ならそれなりに夢を見る事は出来たハードだったとは思うということ。

107 ：

>>105
>もしかしたらPC-98になら移植されてた「かも」ってレベルだし。
98にはフツーに移植されてアスキーからパッケージ販売もされてた。

108 ：

>>105
>8086リアルモード時代のMINIXなんて本当にオモチャだったんでは。
今も過去もMINIXはOS学習用の教材だよ。
>多分PC-88VAに移植された実績なんかも無いと思う
>もしかしたらPC-98になら移植されてた「かも」ってレベルだし。
98には移植されてたから、VAで動かすのは大した手間じゃないだろ。つか知らないなら引っ込んでろ。

109 ：

違うアーキテクチャへの移植がそんなに「大した手間じゃない」かねえ…
大したもんだ。
じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
凄いね。

110 ：

>じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
>凄いね。
PC-98とPC-88VAとの違いと、PC/ATとPC-98との違いを同一視ってすげえ馬鹿丸出しｗ

111 ：

>違うアーキテクチャへの移植がそんなに「大した手間じゃない」かねえ…
>大したもんだ。
>
>じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
>凄いね。
技術的程度が見切れないとこれぐらいバカなこと言えるのかな？それにしても酷いな。

112 ：

移植作業というものをしたことが無い人だから>>110-111みたいな事が言えちゃうんだろうね…
無知って怖いね。

113 ：

>移植作業というものをしたことが無い人だから>>110-111みたいな事が言えちゃうんだろうね…
無知って怖いね。

114 ：

98スレとか、TOWNS蔑みスレとかであった、機種互換のすっとこどっこいな受け答えが…ここにもきてるのか？

115 ：

>98スレとか、TOWNS蔑みスレとかであった、機種互換のすっとこどっこいな受け答えが…ここにもきてるのか？
無知って怖いね。

116 ：

なんだ荒らしてたのは引用厨LOADALLか。

117 ：

>なんだ荒らしてたのは引用厨LOADALLか。
無知って怖いね。

118 ：

自己紹介乙

119 ：

>じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
>凄いね。
android方式で、エミュを組み込めばおｋ。
問題は16bitで32bit環境以上のエミュレータって、68kのmacbochs位しか
知ってる例がないんだよな。
誰かアプリの足しにと作ってたりしない？

120 ：

しかも68000は命令セット的には32bitっぽいCPUだからなあ…
内部処理が16bitだから16bit CPUだけど
プログラムだけ見りゃ32bitで32bitエミュってるだけなんだろうね

121 ：

今思い出したが、8bitな6502 CPU搭載のAppleIIのBASIC ROMには
16bit CPUのエミュレーターが入ってるんだっけ
実在のCPUをエミュレートするものでは無いけど
数式演算ルーチンのサイズ削減のために
わざわざ仮想16bitCPUのコードで書いてそれをエミュって動かしてるとか。

122 ：

>>120
>しかも68000は命令セット的には32bitっぽいCPUだからなあ…
レジスタ長が32bitというだけ。

123 ：

>>121
SWEET16はバイトコードインタプリタ。エミュレータではない

124 ：

バイトコードインタプリタとエミュレータってそんなに言うほど厳密に区別できるもんじゃないだろ。
エミュレータって原義的には何かの真似してりゃエミュレータなんだから
たとえ実在しない物でも、それを真似するならエミュレータで無いとまでは断言できないはずだ
技術的には全く同じものと言えるしね

125 ：

>>124
>技術的には全く同じものと言えるしね
エミュレータだと、エミュレーションする対象の論理的な部分以外にも、実行速度のような
物理的な部分までカバーしたりするから「全く同じ」は間違い。

126 ：

>>124
>バイトコードインタプリタとエミュレータってそんなに言うほど厳密に区別できるもんじゃないだろ。
バイトコードインタプリタは方式。エミュレータはこの場合はソフトウェア製品。
エミュレータがバイトコードインタプリタで実装されてるとは限らない。

127 ：

>>125
バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
それらのソフトを今(今後)動かす需要は発生しえないとでも？
さらに、仮想CPUとして規定したはずのものが、後になってからネイティブ実行できるCPUが実際に出てくる事もある。
Java VMのバイトコードなんてまさにその例。

128 ：

>>127
>バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
いまどきのJava仮想マシンはJIT当たり前じゃん。何言ってんの？

129 ：

JITとウェイトには何の関係も無いんだが…大丈夫？お屠蘇の飲みすぎで酔っ払ってない？
激重だった頃の「アプリを」、「新しい環境で」実行する時の話だよ？

130 ：

>>129
お前、JITとバイトコードインタプリタの区別もつかんの??

131 ：

>>127
>仮想CPUとして規定したはずのものが、後になってからネイティブ実行できるCPUが実際に出てくる事もある。
そういうの(例: ARM Jazzelle)が出たところで、今あるJava VMがJazzelleのエミュレータになるわけないが?

132 ：

z多かった
Jazzelle
↓
Jazelle

133 ：

>>127
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
Javaで実機固有の実行速度に依存するソフトってちょっと想像つかないんだけど、
どういうののこと言ってんの？

134 ：

>>130
いや、だからJITとウェイトに何の関係もないのになんでJITって単語が出てくるんだって言ってるんだけど。
読解力無さ過ぎ…。

135 ：

>>134
「昔はJavaなんか激重だった〜」「それらのソフトを今(今後)動かす需要は〜」なんて言ってるから
> いまどきのJava仮想マシンはJIT当たり前じゃん。
て言われてんだろ。頭悪いの？

136 ：

>>134
いいから>>133に答えてやれよｗ

137 ：

周辺チップのドライバをCPUが変わる度に書きなおすのは頭悪く見えるから、
擬似コード的なもので書くなんて話は昔からありそうだよ。
javaは詳しくないからわからないけど、ところでVAで動かした事例はあるんだろうか？

138 ：

KVMなら移植すれば動かせるだろ。まあそんなことする物好きもいないだろうが。

139 ：

>>129
JITだろうがワイヤーロジックだろうが大差ないんじゃないか？
この場合のウェイトはビジーループを指しているんだろうし。

140 ：

>>133
激重環境を前提に作られたソフトならウェイトが入ってない事もある
たとえば何かを表示するのひとつ取っても、当時の環境であればどれの上でも
充分読める時間表示できてしまう物であれば、それ以上のウェイトは入れられない場合もあるだろう
そういったソフトなら、速い環境で実行すると読めないなんて事になる
機種ごとに動作速度が違ったPC-98用のソフトなんかでも
PC-9821Raなんかで実行するとウェイト不足でとんでもない速度になりまともに操作できないソフトなんか珍しく無かった
8bit時代みたいに全く同じ動作速度が想定できる環境で無くても
ウェイト不足に陥るソフトなんてゴマンとあるんだよ。
>>135
昔の激重VM環境上で動いていたアプリを、今時の速いVM環境(JITだろうがインタプリタだろうが過去よりはずっと速い)で
動かすって話なんだから、JITであるかJITで無いかは問題の本質に何の関係も無いのだが。
エミュレータにしても、内部がJITかJITで無いかで、ウェイト調整機構の要不要が変わってくる訳では無いのだが。

141 ：

>激重環境を前提に作られたソフトならウェイトが入ってない事もある
>たとえば何かを表示するのひとつ取っても、当時の環境であればどれの上でも
>充分読める時間表示できてしまう物であれば、それ以上のウェイトは入れられない場合もあるだろう
>そういったソフトなら、速い環境で実行すると読めないなんて事になる
>
>機種ごとに動作速度が違ったPC-98用のソフトなんかでも
>PC-9821Raなんかで実行するとウェイト不足でとんでもない速度になりまともに操作できないソフトなんか珍しく無かった
>8bit時代みたいに全く同じ動作速度が想定できる環境で無くても
>ウェイト不足に陥るソフトなんてゴマンとあるんだよ。
98の頃の、タイマーとかでタイミングとってない頃のゲームかなんかで頭の中止まってる人みたいねｗ

142 ：

実行時間が見積もれない環境という意味でJITを持ちだしたんじゃないの？
>>125が指摘しているのはそこだし。

143 ：

>>140
> 昔の激重VM環境上で動いていたアプリを、今時の速いVM環境(JITだろうがインタプリタだろうが過去よりはずっと速い)で
> 動かすって話なんだから、JITであるかJITで無いかは問題の本質に何の関係も無いのだが。
> エミュレータにしても、内部がJITかJITで無いかで、ウェイト調整機構の要不要が変わってくる訳では無いのだが。
で、実際どうやって速度調整してるって主張ですか?

144 ：

>>123
この場合むしろロングコードインタプリタだな、欲しいのは。

145 ：

>>143
速度調整「している」という主張では無くて、速度調整「が必要になる局面など存在しないというのは誤り」という主張なんだけど。
過去ログを良く読み返してね。

146 ：

>>145
> 127ナイコンさんsage2013/01/03(木) 18:07:34.08 返信 (3)
> >>125
> バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
> 昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
> それらのソフトを今(今後)動かす需要は発生しえないとでも？
実際ないってことだよね。

147 ：

> 昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
> それらのソフトを今(今後)動かす需要は発生しえないとでも？
仮に問題出たとしても、ソース修正かclassファイルにパッチ当てるかだろう。

148 ：

スレチな話題をいつまで引きずっている気だよ

149 ：

>>148
お前が新しいVAの話題振るまでだよ

150 ：

>>138
そもそもOS動かすのが目的だったんだから、とりあえずVMの主記憶用とか、
リソース相当確保しないといけないんじゃないか？

151 ：

VA用のJAVAVMでも作ってみるかい？

152 ：

>>150
> そもそもOS動かすのが目的だったんだから、
KVM関係ないじゃん

153 ：

K Virtual MachineでKernel-based Virtual Machine用のKernel Virtual Memoryを

154 ：

WABAって16bitな8086環境での動作実績あったっけ？
DPMIとかでないリアルモードDOSで動いた実績があるんなら88VAでも何とかなりそうな。

155 ：

>>154
WABAって何?

156 ：

＞Waba
Java VMのサブセット。Javaから例外をトラップする機能を省いたようなもの。

157 ：

>>147
ソースを変更できる場合ばかりとは限らない。
ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。

158 ：

オープンソースな実装には8bit向けのVMも結構あるな
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines#Free_and_open_source_implementations
何ができるかは知らんが。

159 ：

>>157
>ソースを変更できる場合ばかりとは限らない。
>ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
>ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。
古いPC引っ張ってくりゃいい話だよね。

160 ：

> ソースを変更できる場合ばかりとは限らない。
> ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
> ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。
フツー修正不可なんて馬鹿な契約しないしもっと柔軟に対応するけどね。

161 ：

>>159
それが出来ない場面っていくらでも考えられるんだが…
・マシン持ち込みの許可が下りない。予算がつかない。
・老朽化したり入手困難になるなど。
・復刻ゲームサービスなど、現在の環境で実行できないと意味が無い場合。
etc...

162 ：

>>160
作った会社がすでに潰れてて、権利ひきついだ会社からなんとかバイナリだけ貰えた場合とかは？
そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。

163 ：

>>127
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
Javaって世に出てから20年近く経ってて、その間にPCの速度も何十倍だか何百倍だかに
なってる筈だけど、古いJavaのアプリってVMでウェイト設定して運用されてんの?

164 ：

ちなみに>>161や>>162で挙げたような問題は、Java以外のソフトの世界では既に現実に問題になってるものばかりなので。

165 ：

>>162
>そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。
そしてVMに手ぇ加える工数は割ける場合？本気で言ってんのかな？

166 ：

>>163
元のアプリプログラム側をいじれないのにウェイトを追加せざるを得ない場合、
実行環境の側で何とかするしか無い
そういう事態が「起こりうる」って話。

167 ：

>>165
そういう需要が一定数あるならば、実行速度調節つきVMを一つ作っておくことだって出来るでしょう。
少なくとも各アプリごとに一々全部解析して、修正して、テストする手間よりはずっと少ない。

168 ：

>>162
>作った会社がすでに潰れてて、権利ひきついだ会社からなんとかバイナリだけ貰えた場合とかは？
パッチ当てりゃいいじゃん。
>そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。
商売的に割に合わない不要な仕事ってだけの話だね。

169 ：

>>167
>そういう需要が一定数あるならば、実行速度調節つきVMを一つ作っておくことだって出来るでしょう。
で、そういうVMは存在すんの? それが「そういう需要」のあるなしとイコールだと思うけど。

170 ：

>>161
>・マシン持ち込みの許可が下りない。予算がつかない。
商売として無価値ってことでしょ。やる必要ないよね。
>・老朽化したり入手困難になるなど。
Javaで? 意味分からん。
>・復刻ゲームサービスなど、現在の環境で実行できないと意味が無い場合。
ソース修正やパッチで対応可能じゃん。

171 ：

>>168
>パッチ当てれば
数値をいじるとか当たり判定潰すとかじゃなく、コードの「追加」だから、難易度は低くは無いと思うが…
パッチそのものの作業はともかくテストを全部一からやりなおしなんて騒ぎにもなりかねない。
>>167でも挙げたが、需要が一定数以上あるなら速度調節機能つきVMは作れる。
そして作ればアプリ毎の改修は行わなくて済むので商業的に割に合いやすくなる。
つまり個々に改修する方式では出せないソフトも出せるようになる。

172 ：

>>171
>数値をいじるとか当たり判定潰すとかじゃなく、コードの「追加」だから、難易度は低くは無いと思うが…
Javaなら超簡単。
>パッチそのものの作業はともかくテストを全部一からやりなおしなんて騒ぎにもなりかねない。
サービス開始前にテスト全部するのは当たり前。
ちなみに、VMに手加えたらテストはアプリどころの話じゃないぞ。

173 ：

>>170
>許可が下りない
この場合は、商売として客に供給するのでは無い場合。
何らかのアプリを社内・学内で使う場合など。
>老朽化したり入手困難
「アプリが開発された当時の古い環境を導入する」のだから当然。
今のマシンではVMのソフトだけ古くても実行速度は当時のものにならない。
あくまで実行速度の話をしていて、その為に当時の環境を用意するというのだから、当然老朽化した古いハードを使う事になる。

174 ：

>>172
>テスト全部
総合テストの話じゃなく、ルーチン単位の単体テストからやりなおしになりかねないって話。
VMに手を加えた分については、VMとしてのテストを行っておいて
その上でVM+目的アプリのテストを行うだけ。
既存の(既に枯れた)VMを使うのとは、VMそのもののテストが追加になるところのみが異なる。
速度調整つきVMをどこかのメーカーが作りアプリサービス会社に供給するのならば、
アプリサービス会社側のテストの量は増えることは無い。

175 ：

>>171
>>>167でも挙げたが、需要が一定数以上あるなら速度調節機能つきVMは作れる。
>そして作ればアプリ毎の改修は行わなくて済むので商業的に割に合いやすくなる。
>つまり個々に改修する方式では出せないソフトも出せるようになる。
動作速度なんてアプリ側でタイマーかなんか参照して取るもんでしょ。
「速度調節機能つきVM」とやらで調整したとして、ある環境ではある条件で速くなる、
ある環境ではある処理で遅くなる、なんて現象出たらどうすんの？

176 ：

>>174
>VMに手を加えた分については、VMとしてのテストを行っておいて
それが莫大な手間だろ。

177 ：

>動作速度なんてアプリ側でタイマーかなんか参照して取るもんでしょ。
それが理想なのは言うまでも無いことだが、そうなってないソフトが現実にあるなかで
それをどうしようかってのが話の前提なので、そこを覆されても。
>「速度調節機能つきVM」とやらで調整したとして、ある環境ではある条件で速くなる、
>ある環境ではある処理で遅くなる、なんて現象出たらどうすんの？
それこそエミュレータでも全く同じ問題がついてまわるはずのものなんだが。
それを解決しなければならないのはエミュレータでも同じだし、解決するための技術もエミュレータと共通。

178 ：

>>161
「マシン持ち込み」って何？

179 ：

>>176
少なくは無い手間だが、それでも個々のアプリでやるよりは遥に少なくて済む。

180 ：

>>177
>それこそエミュレータでも全く同じ問題がついてまわるはずのものなんだが。
>それを解決しなければならないのはエミュレータでも同じだし、解決するための技術もエミュレータと共通。
実機のエミュレーションだと実行される命令単位でクロック数計ってタイマーに合わせたり
当たり前にやってますよ。

181 ：

あきらめる

182 ：

>>178
文字通り、備品として既にそこに置いてあるマシンとは別のマシンを調達してくること。
決められたマシン以外導入禁止なんていうオフィスや学校は珍しくないと思われるが。

183 ：

>>180
Java VMの場合でも、厳密にやるならば、同じように各処理内容(共通ライブラリのメソッドや、バイトコードの命令)ごとに
実機で測った時間などを元にウェイトを設定する事になると思われる
だから技術はかなりの部分エミュレータと共通する事になる
そこまで厳密にやらなければ、メソッド呼出しやバイトコード実行ごとに適当にウェイトを入れるようになるだろうが
そういう実装のエミュレータも数多く存在してるのも同じ。

184 ：

>>169
今そのような動きはあまり見られないからといって、将来もそうであるとは限らない。
例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
将来そのようなサービスが現れる可能性は充分にある。

185 ：

>>182
>文字通り、備品として既にそこに置いてあるマシンとは別のマシンを調達してくること。
>決められたマシン以外導入禁止なんていうオフィスや学校は珍しくないと思われるが。
？？？
仕事に必要なものなら申請書出すなりして購入ってのは普通の話では？
上から与えられた機材のみで仕事？そういう職場って珍しいと思うよ。

186 ：

>>184
> 例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
携帯電話って機種ごとの差異が大きいんで、ちゃんと組まれてればタイミングはアプリ側で取ってるよ。
「ちゃんと組まれてない場合は〜」とか言うかもしれないけど、そういう出来の悪いアプリは
リバイバルの対象外で問題ないね。

187 ：

>>184
>例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
携帯だかPCだか向けのサービスとして、コンテンツ提供側がJavaのVMまで提供？
>将来そのようなサービスが現れる可能性は充分にある。
本気で言ってるのかな？

188 ：

>>183
>Java VMの場合でも、厳密にやるならば、同じように各処理内容(共通ライブラリのメソッドや、バイトコードの命令)ごとに
>実機で測った時間などを元にウェイトを設定する事になると思われる
>だから技術はかなりの部分エミュレータと共通する事になる
『詭弁の特徴のガイドライン』でいうところの
1. 事実に対して仮定を持ち出す
3. 自分に有利な将来像を予想する
ですね?

189 ：

ごちゃごちゃ言った所で、JPC等が動ようなjaVAは存在しないし、
88に移植する能力もないだろう。

190 ：

88VAのスレなのにスレ違いの話を延々続けてる馬鹿共は何なんだ？

191 ：

JPC?
https://www.google.co.jp/search?q=JPC

192 ：

ああ、これのことか。
http://sourceforge.jp/projects/sfnet_jpc/releases/

193 ：

>>189
>ごちゃごちゃ言った所で、JPC等が動ようなjaVAは存在しないし、
Javaの話はVAでJava動かしてその上で何らかのエミュレータを動かそう、とか
そういう流れではないんで的外れ。

194 ：

いやいや、そういう流れの話に無関係なタイミング問題でごちゃごちゃ言うのが居ただけでしょ。
そもそも16bitで32bitのタイミングをエミュれる訳がないんだから。

195 ：

>>158
バンクとかEMSに対応した奴あるかな？

196 ：

>>154
よくわからないけど、DPMI対応の方がむしろハードEMSに移植しやすかったりしない？

197 ：

>よくわからないけど、DPMI対応の方がむしろハードEMSに移植しやすかったりしない？
プッ

198 ：

DPMI対応だと、VCPIとかにも対応してたりしないか？

199 ：

>>185
必要と思えば申請するが、それが必ず通るとは限らない。
そんな事もわからないニートさんが居ますね。

200 ：

>>186
どんな機種でもうごくように組むより、機種毎に別個に調整された別プログラムとしてサービスされてる事の方が多そうだが…
残念な事だが、世に名作と言われるゲームだからといってプログラムのつくりまでしっかりした物ばかりでは無いよ。
だからプログラムのつくりの悪さをもって安易にリバイバル対象外とする事はできない現実がある。
>>196
DPMIってのはDos Protect Mode Interfaceの略。
つまりDOSでプロテクトモードのプログラムを実行する環境のことだから
それ使われると88VAからは手出しできない。
仮想EMSとDPMIは別ものだよ。
仮想EMSをやるとCPUの特権モードを占有してしまうから
仮想EMSとプロテクトモードアプリとの共存をするために
仮想EMSドライバ側にプロテクトモードへのインターフェースを用意している
その仕組みがDPMIとかVCPIとか。

201 ：

>>187
>コンテンツ提供側がVMまで提供？
Wiiのバーチャルコンソールなんかは文字通りVM(エミュレータ)とのセットで提供されてるのだが。
>本気で言ってるのかな？
今は数々のレトロゲームがリバイバルされてるが、かつてはレトロゲームのリバイバルがあまり注目されてない時代もあった。
過去のものが後の世になって再注目されるというのは珍しい事では無いのだが。
>>188
可能性の存在の話であって仮定の話では無い。
話をすり替えないように。
「可能性があればそれに備える事も考えなければいけない」という議論をしてるときに(例: 事故や災害の対策など)
「仮定の話をするのは詭弁だ」と言うのはおかしいのと同じ。

202 ：

バーチャルコンソロール

203 ：

>>201
>可能性の存在の話であって仮定の話では無い。
>話をすり替えないように。
↓は可能性や仮定の話ではなく、現実のバイトコードインタプリタとエミュレータについての話じゃないの?
>バイトコードインタプリタとエミュレータってそんなに言うほど厳密に区別できるもんじゃないだろ。
>エミュレータって原義的には何かの真似してりゃエミュレータなんだから
>たとえ実在しない物でも、それを真似するならエミュレータで無いとまでは断言できないはずだ
>
>技術的には全く同じものと言えるしね」

204 ：

最後、要らん」付いた

205 ：

>>201
>>コンテンツ提供側がVMまで提供？
>Wiiのバーチャルコンソールなんかは文字通りVM(エミュレータ)とのセットで提供されてるのだが。
JavaのVMの話でしょ。

206 ：

>>201
>今は数々のレトロゲームがリバイバルされてるが、かつてはレトロゲームのリバイバルがあまり注目されてない時代もあった。
>過去のものが後の世になって再注目されるというのは珍しい事では無いのだが。
ハードウェアやネットワークの進歩で少ない労力でサービスが提供できるようになったから
商売として可能になったというだけであって、今になってレトロゲームが注目されているわけではない。

207 ：

そうなん

208 ：

そうだね

209 ：

>>200
手出しできないって別にバイナリ動かすんじゃなくて、ソース移植の話だよね？
特権モードより仮想EMS前提のプロテクトモードの方がまだマシなんじゃないかと。
それでないリアルモードと言うと、メモリ周り何も考えてないベタ移植で詰みそう。

210 ：

>>200
>残念な事だが、世に名作と言われるゲームだからといってプログラムのつくりまでしっかりした物ばかりでは無いよ。
>だからプログラムのつくりの悪さをもって安易にリバイバル対象外とする事はできない現実がある。
低いコストで提供する前提の商売では、提供するに当たってコストが発生するタイトルは敬遠されるし、
ある程度の数が見込めるであろうタイトルでは、それなりのコストを払ってでも手を加えていたりする。
バーチャルコンソールは前者。

211 ：

絶対に折れない馬鹿正直陣 vs 絶対に貫かれない理想主義陣

212 ：

一撃で流れ止めた凄え、感謝。
代わる話は無いけど。

213 ：

で、EMS使える処理系ってなんかないの？

214 ：

C言語ならEMSサポートするライブラリが無くても
インラインアセンブラか何かでEMSのファンクションコールを呼ぶところだけ自前で書けば
あとは根性で何とかなるでしょ
その根性が多大に要求されるのが困るんだけど…

215 ：

>>214
>インラインアセンブラか何かでEMSのファンクションコールを呼ぶところだけ自前で書けば
EMS呼ぶのにそんなもん要ったっけ?
もう随分昔のことで記憶もオボロゲだけど、Cの標準のライブラリだけで行けたような気がするけど。

216 ：

TurboCやMS-Cは知らないが
LSI-C86だとそんなライブラリはついてなかったと思う

217 ：

>>216
>LSI-C86だとそんなライブラリはついてなかったと思う
お前、製品版買って言ってるの？

218 ：

試食版って書き忘れただけなんだろ、どうせ
試食版使ってる人だって多いんだからいちいち目くじら立てんなよ

219 ：

試食版使わせてもらってる立場なら文句とか言うなや

220 ：

まったくだな
製品版が買えない貧乏人は黙って試食版を使っておけっての

221 ：

>>219=220
なんでお前そんなに偉そうなんだよ

222 ：

デパ地下の試食で腹いっぱいにした後文句言う乞食

223 ：

>>216
>LSI-C86だとそんなライブラリはついてなかったと思う
製品買ってるならまだしもフルセットでもない試食版でねぇ、こういうこと言うかな？

224 ：

EMSアクセスに特別なライブラリとか要らないから。

225 ：

で、どうやるの
説明してミソ

226 ：

>>225
「EMSアクセス」でぐぐったら↓が親切に説明してたよ。
http://www2.muroran-it.ac.jp/circle/mpc/front/old1/program/pc98dos/ems.html

227 ：

「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
コンパイラに付属するその他のライブラリは含まれない
インラインアセンブラ無しでも_bdos関数か何かCの標準ではないライブラリで可能ではある

228 ：

>>227
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
>コンパイラに付属するその他のライブラリは含まれない
お前ルール乙
>インラインアセンブラ無しでも_bdos関数か何かCの標準ではないライブラリで可能ではある
「LSI-C86だとそんなライブラリはついてなかったと思う」とか言ってる奴のことも考慮しろよｗ

229 ：

Cの標準ライブラリはローカルルールではなく公式

230 ：

>>229
>Cの標準ライブラリはローカルルールではなく公式
「Cの標準のライブラリ」だから違う話。

231 ：

LSI-Cの標準のライブラリとかならともかく
「Cの標準のライブラリ」も「Cの標準ライブラリ」も変わるわけが無かろう

232 ：

>>227
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
CがANSIとかで仕様化される以前は「標準のライブラリ」は存在しなかったってご意見？

233 ：

>>229
>Cの標準ライブラリはローカルルールではなく公式
「ANSI Cの標準〜」「C99の〜」とかって話ならそうかもね

234 ：

>>227
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
Standard LibrarｙってK&Rの頃から使われてたし、その頃にはCに仕様なんかなかったよ。

235 ：

K&Rに仕様が無いわけがないだろ

236 ：

仕様とデジュレスタンダードは別物だぞ
デジュレスタンダードが無ければ仕様が無いというわけでは無いな

237 ：

ANSIで規格化されるまではpccとstandard libraryの実装が実質的に標準というような状態で
>>227の言うような「C言語の仕様で規定された〜」なーんて言えるような状態じゃなかったよ。
UNIXって仕様よかコードを書く文化だから仕様がないのは珍しいことではなかったしな。

238 ：

だから規格と仕様は違うんだってば。

239 ：

>>227の言う
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
「仕様」って「規格」のことだろ。

240 ：

20年ほど起動してないVA動くかなぁ・・

241 ：

>>240
俺のVA2は、先週の彼岸に実家帰ったときに電源入れたら起動した
とりあえずオルテウスを10分くらい遊んだが特に問題ない感じだったよ

242 ：

VA2って電池周りが結構ヤバイらしいじゃないか

243 ：

俺も昔もってたわーPC88VA
音源ボードいれてた。ソーサリアンのBGMは88VAが最高だったよね。

244 ：

>>243
> ソーサリアンのBGMは88VAが最高だったよね。
曲によるかな。
「呪われたクイーンマリー号」のベースの音色が変わった上に
スタッカート気味になってたりとか、エンディングIIのFMブラスが
奏でていたメロディーがPSGになっちゃってたりとか、ところどころ
不満もある。エンディングIのドラムスも蛇足だと思うし。

245 ：

うちのVA、初代なんでサウンドボードII欲しいな…

246 ：

倉庫掃除したらVA版ソーサリアン（+追加、戦国、ピラミッド）のソフト出てきたわ…
5"-2DDの5枚組だけど中見たらまだ綺麗で懐かしさで涙出てきた：：
VA2捨てないで取って置きゃ良かったorz

247 ：2013/09/20

どうせ劣化して動かなくなってるよ
最近はオクでレトロPCをフルレストアして売るのが流行っているから
そういうの出てくるの待ってみれば？