PC-88VA3
キーワード [
PC-88VA3
]
もしかして前スレ？または最新の関連スレッドβ
@logsoku_news をフォローする @logsoku_vip をフォローする
おすすめスレッド
| 大学生活 | PC総合 |
| ニュー速VIP | 自作PC |
| 大学生活 | PC総合 |
| 大学生活 | PC総合 |
| ニュー速VIP | pc |
| ニュー速VIP | PC |
| 大学生活 | PC総合 |
| なんでも実況J | PC |
| ノートPC | Slate PC |
| 大学生活 | PC総合 |
| 大学生活 | PC総合 |
| ニュー速VIP | PC自作 |
| 大学生活 | PC総合 |
| 大学生活 | PC総合 |
| 自作PC | pc acce |
最近見られたスレッド
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/
>>4
VA3 +1 とか…？
結局ポシャったとはいえコードネームだか仮の名前だかくらいは発表になってたと思うけど
どの辺を機能アップする予定だったのかな
98との互換性は更にアップしたんだろうか
○VA3の後継機種計画に興味ある
とりあえず欲しい機能を挙げてくと
(現在の技術フル稼働というより、さしあたっては当時の技術の順当な延長っぽいスペックで考えて)
テキスト&スプライトVRAMの更なる増量
スプライト&SGP;の描画能力の更なる向上(できればテキストがスプライトオーバーで消えなくなると尚ありがたい)
グラフィックの面数やVRAM容量も強化(256色以下モードで4枚、65536色でも640x408フルで2枚とか。あるいはそれ以上)
CPUの高速化&PC-98;との互換性強化
で、CPUをどうするかやっぱり困ってしまう
互換性をとるなら、Z80互換モードつきV30上位互換CPUが欲しいところだけど
PC-98互換のためのVRAM移動も兼ねて386系(386かそれ以上)が欲しくもある
(互換性向上をハードでやってくれるのが好ましいけど、無くても386ページング機能でVRAM再配置ならある程度対処できる的な意味で)
とりあえずの理想としてはPC-9801RAのごとく両搭載なんだが…(妄想マシンでコストを考えてもしょうがない？)
16bitPCとしての機能パワーと軽快さをFDDベースの環境で両立させようとした方向性は正しいと思う。
スペックはVA2と同等で軽量コンパクト化、価格帯をかつての8bitホビーPC上位機と同等の15万円台に下げて
VA本来のホビーPCとしての魅力をより広く体験してもらえる普及機が欲しかったかな。
気付くの遅れて入札できなかった
どんなVA用のライブラリーがあるのか気になる
スプライトとか音関係のライブラリもあっったのだろうか
どうにも使い辛かったのが…。6万色は更に色々な制限があったし。
32色モードを256色モードに拡張して、パレットを256色使えるように拡張して欲しかったり。
パレット付き256色ならかなりの絵が描けるはず
パレット256色といえば、業務用(アーケード)ゲーム機における8bit後期～32bit初期くらいの標準的スペックだから
やっぱりそのくらい使えればかなり使いでがあったのではないかと。
そんなに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だったりする。
スプライト
・ラスタバッファ式(本物のスプライト)： PC-88VA、X68000
・フレームバッファ式(擬似スプライトと呼ばれる)： FM-TOWNS
テキストVRAM
・文字コードからフォントを表示する機構が備わる本物のテキストVRAM： PC-88VA
・テキストVRAMというものの実態はビットマップVRAM： X68000
・無し。エミュレーションのみ。： FM-TOWNS
PCエンジンのCD-ROM2を外付けで繋げられるようにはなったんじゃないかな（棒
したがって読まない
8ビットCPUではこれらを扱いきれなくなり16ビット化したのであってX68対抗とかでは無いと思う。
ホビーユーザーがうまく移行してくれれば88MCなんての出さずにVAにCDROMが付いたはず。
88VAが存続してればCD-ROM内蔵モデルくらいは出たと思うけど。
でもFM-TOWNSみたいなCD-ROMまみれの世界にはならなかっただろうなーと…。
なんかHDD前提時代になってからのPC-98みたいに、CD-ROMも使われるけどそればっかりじゃない状態になってた気がする
N-BASIC削らずにそれがやれていたら、本格的にPC-88VAに移行できてたかもね。
PC-88VAの普及の見通しに自信が持てない→ソフトが出ない→なかなか普及しない→最初に戻る、の悪循環だったから…
これからはホビーパソコンはこれでいくんだ！という覚悟が足りなかったのが成功出来なかった原因かなあ。
成功したあかつきには性能向上のみならず更なる互換性向上を実現した新モデルを出してほしかったなあ。
シルフィードとかソーサリアンとか。
いやいや、VAやTOWNSは既存のPCを機能てんこ盛りに拡張したような感じだけど
X68は全く土台が新しいパソコンという感じ
触れた感覚からしても全然違う
68はゲーム機みたいなもんで一世代でお終い
スーパーX68000にはならなかったね
XVIはともかくX68030はさすがにマイナーチェンジとは言えないはずだ
公称16bitCPUから公称32bitCPUになったってのに。
最後にちょろっと変なのを出すこともある
でも実際にその機能は生かされずに終わる
CPUパワーが渇望されてなきゃ060turboなんて生まれるはずもないのに
060turboがバカ売れしたならその通りかもね
具体的な数字教えて
電倶楽で盛んに紹介されてた、ネットで声の大きい人が頻繁になんか言ってたってレベルじゃないの？
030ユーザーの060turbo所有率とか知ってるなら教えれ
互いの機能を載せた拡張ボード差すと互換機化するとか。
>>25が言うようにAT互換機自体がそうだしさ。
他社のPCでの動作を保証したその手のボードってあったっけ?
機能に互換があるなら対応するかはソフトハウスの判断なわけで。
XAとかXLは超高解像度があった気がするけど
>そもそも同一シリーズでも機種が違う時点で動作保証なんかないだろ。
FX-GAやTOWNSのボードは、PCによっては動作保証してたり、PCとセットで売ってたりしてたと思った
動かないソフトがあったら確実に修正してくれるってこと?
ボード売ってる会社が他社のソフトの動作を保証できるわけないべ。常識で考えれ。
・ノーマル・ハイレゾ両モード対応(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コネクタに電源コントロール線も来ているので、専用ディスプレイを使えばディスプレイ側で本体電源を操作できる
・テキスト画面も実はちょっと拡張されている。アトリビュートの拡張と、外字領域の拡大。
・まるで互換性が低いかのような誤解があるが、まず互換性が問題になることは無い
>>41
話の流れ理解すれ
そんなのねえよって話。
でも大したことじゃないだろ、脇毛がないのに比べたら
俺、いつ大人になれるの？
PC-88VAの後継機が中止になったのはPC-98GSの開発が決まったからだとか。
その証拠にPC-9801DAの後なのにV30を搭載している。
>その証拠にPC-9801DAの後なのにV30を搭載している。
意味わからん
PC-9801DAより後に出たのにPC-98GSには搭載されている
要するにPC-9801DAよりも前から開発されてたってこと
「PC-98GSって何だか開発期間がえらく長かったらしい」には関係するが、
「PC-88VAの後継機が中止になったのはPC-98GSの開発が決まったからだとか。」とは関係ない話だな。
「その証拠に」がイカンのだろう。
87年 VA
88年 VA2/3
89年 98DO
90年 98DO+
91年 98GS
という流れだってことか＠＠
NECの王道シリーズではなく、その変なシリーズが大好きなんだよな。
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年掛かったということになり、そらちょっと「えらく長かったらしい」と
言っても長すぎるんじゃないのという気がする。
「その証拠に」は一行目にかかってる
二行目にかかってると誤解してるのがいかんのでは
88でも98でもない別機種になるくらいのプロジェクトだろう
その結果がGSだったら超悲しい物語だ
http://www.enpitu.ne.jp/usr4/bin/day?id=41506&pg=20050519
「ブルマに関するあるマニアックな一考察」とかいうのが出てきたんだが……。
つまんねー荒らししてんじゃねえよ
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の後継っぽい位置付けに結果的になった、
という印象を持ってます。
（もっとも、これは根拠の無い個人的な意見です）
>PC-9801ES（1989年4月発売）をベースに、
開発期間2年半としても異常な長さだな。何でそんな掛かったんだろ?
持て余していた感じがあるな。PCでの使い方を模索していたのでは？
8801MCなんてのもやってみたり
発売直後から開発を始めたわけでもないでしょう。
あとは、ソフトウェア側の準備（Windows 3.0＋MME）とか。
とすると本当に長くかかっちゃったのだろう…
なんでこんなにてこずったんかね。
VASG？に積む予定だった機構を使いまわしてる部分とかもありそうなのに。
VA SuperGRAFXの内部構造はかなり後のPC-98GSに似ている物だったっぽい
65536色フル解像度表示可能な画面が従来グラフィックとは別の面として追加されてるところとか
あとPC-98互換モードもつくとか
6月には386SX搭載になるという噂まで出たらしい…
ますますPC-98GSとダブる
思うんだけど、擬似的に多少の空き容量が存在するようにみえて
カスタマイズ可能なCD版RAMドライブとかあっても良かったと思うんだよな。
そうすれば使い勝手は固定ディスクと大差なかった気がするんだけれど。
でもさあ、rom^2では使ってきたメディアだし、富士通にできた事ができなかった
理由ってなんなんだろう？
>できなかった
>理由ってなんなんだろう？
88終了
TOWNSのベースマシンもハイレゾ機だったって話だし。
SRのようにブレイクはしてくれなかった
そういえばそんな一部書換え可能CD-ROMは
セガサターンが採用するってアナウンスしてたなあ…
結局実現しなかったけど。
(セガの予告は大抵実現しないのだ…)
SuperGRAFXの頭文字取ってひっくりかえしたものっぽいね
本当にそれが由来だったりするかもしれん…
案外PC-98GSには使われてない(VASGで使う予定だった)スプライト機能とかが隠されてたりして…
(VAの従来スプライトと別にVASG専用のスプライト機構が追加される予定だったとか)
Sound
Visual
Audio
だとしても、似たような命名方式だな
PC-9801から見ると確かにサウンドもパワーアップしてるんだな…。
そう考えるとGraphic+SoundでGSって線も考えられるのか。
音源的に、GSはVA2/3から見て
・OPNAのADPCM用RAM削除
・OPNAとは別にPCM/ADPCM搭載
・DSPでちょこっと音が加工できる
っていうのが違いかな。
細かいことを言えば
・PC-98規格なのでFBEEP音源は無し
っていう違いもあるのか。
あれ？PC-88VAってBEEP音源の音程変えられたっけ？(普通のPC-8801は変えられなかったはず)
FH/MHから削られたって話聞いたような気がする。
あの機能使えるのはmk2の名前が付いた機種(mk2～FR、MRあたりまで該当？)だとか。
VAもたぶんないんじゃないかな？
それでは無い
TCUのカウンタ#1がBEEPの音程とあった
つまりPC-8801(V1/V2)では音程変更できないが、PC-88VA(V3)ではPC-9801と同様に可能という事になる
PC-9801もタイマー用の8253のカウンタの一つがBEEPの音程設定に使われている
…いやそこにLS-120かMOのドライブ突っ込めば少しはVA3気分になれるかな？と思っただけなんだけど。
いちいち別に作るとか、当時は贅沢だったんだな。
筐体そのものがサイズから全く別なんだっけか…。
今じゃ考えられんな。
6502、6809、Z80、8085なんてなったら目も当てられん
PC-8801には6809カードみたいな物って無いよね。
8086増設ならあったけど。
PC-9801には68000ボードとかV80ボードとか出てたみたいだ
PC-88VAには無いけど、V50系CPUってCPUコアだけCPUKILLする事は出来ないつくりなんだろうか？
88も98も、その手のボードって本体のCPU殺さないで動いてるでしょ。
やっぱCP/Mの要望が多かったんでないの、Z80ボード出てたのって
OS-9の要望はナインス、なんちってね
あったのか…
8086系を嫌ってる人の多いイメージのあるX68Kで意外だ…
>>97
そうなの？あまりにレアなんで実物を見たことが無いので知らなかった。
PC-98の場合、特にCバスにさすタイプのCPUアクセラレータ(当然本体CPUになりかわって動く)が出ているので…。
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
これは、あの天使たちの午後のジャストが発売ｗ
Xサーバーなんかは動かなかったんじゃないかなー
多分PC-88VAに移植された実績なんかも無いと思う
もしかしたらPC-98になら移植されてた「かも」ってレベルだし。
当時はそれなりに有力視されてたんじゃなかったっけ＜V60系CPU
普通に新CPUを試したいとか演算能力が欲しいとか、もしかしたらPC-UNIXが実現できたらいいな的アイテムだったかも。
確かV70には8086エミュレーション機能もついてなかったっけか
だから頑張ればDOSのソフトを動かす事も理論上は可能だったのでは。
そんなソフトを実際に書いた人が居るかどうかは知らないけど。
とにかく言える事は、実用性はともかく、当時ならそれなりに夢を見る事は出来たハードだったとは思うということ。
>もしかしたらPC-98になら移植されてた「かも」ってレベルだし。
98にはフツーに移植されてアスキーからパッケージ販売もされてた。
>>8086リアルモード時代のMINIXなんて本当にオモチャだったんでは。
今も過去もMINIXはOS学習用の教材だよ。
>多分PC-88VAに移植された実績なんかも無いと思う
>もしかしたらPC-98になら移植されてた「かも」ってレベルだし。
98には移植されてたから、VAで動かすのは大した手間じゃないだろ。つか知らないなら引っ込んでろ。
大したもんだ。
じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
凄いね。
>凄いね。
PC-98とPC-88VAとの違いと、PC/ATとPC-98との違いを同一視ってすげえ馬鹿丸出しｗ
>大したもんだ。
>
>じゃあPC/AT用の色々なOSもサクッとPC-98に移植できるんだね君は。
>凄いね。
技術的程度が見切れないとこれぐらいバカなこと言えるのかな？それにしても酷いな。
無知って怖いね。
無知って怖いね。
無知って怖いね。
無知って怖いね。
>凄いね。
android方式で、エミュを組み込めばおｋ。
問題は16bitで32bit環境以上のエミュレータって、68kのmacbochs位しか
知ってる例がないんだよな。
誰かアプリの足しにと作ってたりしない？
内部処理が16bitだから16bit CPUだけど
プログラムだけ見りゃ32bitで32bitエミュってるだけなんだろうね
16bit CPUのエミュレーターが入ってるんだっけ
実在のCPUをエミュレートするものでは無いけど
数式演算ルーチンのサイズ削減のために
わざわざ仮想16bitCPUのコードで書いてそれをエミュって動かしてるとか。
>しかも68000は命令セット的には32bitっぽいCPUだからなあ…
レジスタ長が32bitというだけ。
SWEET16はバイトコードインタプリタ。エミュレータではない
エミュレータって原義的には何かの真似してりゃエミュレータなんだから
たとえ実在しない物でも、それを真似するならエミュレータで無いとまでは断言できないはずだ
技術的には全く同じものと言えるしね
>技術的には全く同じものと言えるしね
エミュレータだと、エミュレーションする対象の論理的な部分以外にも、実行速度のような
物理的な部分までカバーしたりするから「全く同じ」は間違い。
>バイトコードインタプリタとエミュレータってそんなに言うほど厳密に区別できるもんじゃないだろ。
バイトコードインタプリタは方式。エミュレータはこの場合はソフトウェア製品。
エミュレータがバイトコードインタプリタで実装されてるとは限らない。
バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
それらのソフトを今(今後)動かす需要は発生しえないとでも？
さらに、仮想CPUとして規定したはずのものが、後になってからネイティブ実行できるCPUが実際に出てくる事もある。
Java VMのバイトコードなんてまさにその例。
>バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
いまどきのJava仮想マシンはJIT当たり前じゃん。何言ってんの？
激重だった頃の「アプリを」、「新しい環境で」実行する時の話だよ？
お前、JITとバイトコードインタプリタの区別もつかんの??
>仮想CPUとして規定したはずのものが、後になってからネイティブ実行できるCPUが実際に出てくる事もある。
そういうの(例: ARM Jazzelle)が出たところで、今あるJava VMがJazzelleのエミュレータになるわけないが?
Jazzelle
↓
Jazelle
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
Javaで実機固有の実行速度に依存するソフトってちょっと想像つかないんだけど、
どういうののこと言ってんの？
いや、だからJITとウェイトに何の関係もないのになんでJITって単語が出てくるんだって言ってるんだけど。
読解力無さ過ぎ…。
「昔はJavaなんか激重だった～」「それらのソフトを今(今後)動かす需要は～」なんて言ってるから
> いまどきのJava仮想マシンはJIT当たり前じゃん。
て言われてんだろ。頭悪いの？
いいから>>133に答えてやれよｗ
擬似コード的なもので書くなんて話は昔からありそうだよ。
javaは詳しくないからわからないけど、ところでVAで動かした事例はあるんだろうか？
JITだろうがワイヤーロジックだろうが大差ないんじゃないか？
この場合のウェイトはビジーループを指しているんだろうし。
激重環境を前提に作られたソフトならウェイトが入ってない事もある
たとえば何かを表示するのひとつ取っても、当時の環境であればどれの上でも
充分読める時間表示できてしまう物であれば、それ以上のウェイトは入れられない場合もあるだろう
そういったソフトなら、速い環境で実行すると読めないなんて事になる
機種ごとに動作速度が違ったPC-98用のソフトなんかでも
PC-9821Raなんかで実行するとウェイト不足でとんでもない速度になりまともに操作できないソフトなんか珍しく無かった
8bit時代みたいに全く同じ動作速度が想定できる環境で無くても
ウェイト不足に陥るソフトなんてゴマンとあるんだよ。
>>135
昔の激重VM環境上で動いていたアプリを、今時の速いVM環境(JITだろうがインタプリタだろうが過去よりはずっと速い)で
動かすって話なんだから、JITであるかJITで無いかは問題の本質に何の関係も無いのだが。
エミュレータにしても、内部がJITかJITで無いかで、ウェイト調整機構の要不要が変わってくる訳では無いのだが。
>たとえば何かを表示するのひとつ取っても、当時の環境であればどれの上でも
>充分読める時間表示できてしまう物であれば、それ以上のウェイトは入れられない場合もあるだろう
>そういったソフトなら、速い環境で実行すると読めないなんて事になる
>
>機種ごとに動作速度が違ったPC-98用のソフトなんかでも
>PC-9821Raなんかで実行するとウェイト不足でとんでもない速度になりまともに操作できないソフトなんか珍しく無かった
>>8bit時代みたいに全く同じ動作速度が想定できる環境で無くても
>ウェイト不足に陥るソフトなんてゴマンとあるんだよ。
98の頃の、タイマーとかでタイミングとってない頃のゲームかなんかで頭の中止まってる人みたいねｗ
>>125が指摘しているのはそこだし。
> 昔の激重VM環境上で動いていたアプリを、今時の速いVM環境(JITだろうがインタプリタだろうが過去よりはずっと速い)で
> 動かすって話なんだから、JITであるかJITで無いかは問題の本質に何の関係も無いのだが。
> エミュレータにしても、内部がJITかJITで無いかで、ウェイト調整機構の要不要が変わってくる訳では無いのだが。
で、実際どうやって速度調整してるって主張ですか?
この場合むしろロングコードインタプリタだな、欲しいのは。
速度調整「している」という主張では無くて、速度調整「が必要になる局面など存在しないというのは誤り」という主張なんだけど。
過去ログを良く読み返してね。
> 127ナイコンさんsage2013/01/03(木) 18:07:34.08 返信 (3)
> >>125
> バイトコードインタプリタにはそういう技術が全く不要であると断言できる？
> 昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
> それらのソフトを今(今後)動かす需要は発生しえないとでも？
実際ないってことだよね。
> それらのソフトを今(今後)動かす需要は発生しえないとでも？
仮に問題出たとしても、ソース修正かclassファイルにパッチ当てるかだろう。
お前が新しいVAの話題振るまでだよ
そもそもOS動かすのが目的だったんだから、とりあえずVMの主記憶用とか、
リソース相当確保しないといけないんじゃないか？
> そもそもOS動かすのが目的だったんだから、
KVM関係ないじゃん
DPMIとかでないリアルモードDOSで動いた実績があるんなら88VAでも何とかなりそうな。
WABAって何?
Java VMのサブセット。Javaから例外をトラップする機能を省いたようなもの。
ソースを変更できる場合ばかりとは限らない。
ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines#Free_and_open_source_implementations
何ができるかは知らんが。
>ソースを変更できる場合ばかりとは限らない。
>ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
>ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。
古いPC引っ張ってくりゃいい話だよね。
> ソースは既にこの世から失われてるかもしれないし、ライセンス上の理由などでソース修正が許されない場合もある。
> ライセンス上の理由で修正が出来ない場合は、逆コンパイラも使えない。
フツー修正不可なんて馬鹿な契約しないしもっと柔軟に対応するけどね。
それが出来ない場面っていくらでも考えられるんだが…
・マシン持ち込みの許可が下りない。予算がつかない。
・老朽化したり入手困難になるなど。
・復刻ゲームサービスなど、現在の環境で実行できないと意味が無い場合。
etc...
作った会社がすでに潰れてて、権利ひきついだ会社からなんとかバイナリだけ貰えた場合とかは？
そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。
>昔はJavaなんか激重だったからまともにウェイトなんか入れてないソフトも結構あったと思うが
>それらのソフトを今(今後)動かす需要は発生しえないとでも？
Javaって世に出てから20年近く経ってて、その間にPCの速度も何十倍だか何百倍だかに
なってる筈だけど、古いJavaのアプリってVMでウェイト設定して運用されてんの?
>そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。
そしてVMに手ぇ加える工数は割ける場合？本気で言ってんのかな？
元のアプリプログラム側をいじれないのにウェイトを追加せざるを得ない場合、
実行環境の側で何とかするしか無い
そういう事態が「起こりうる」って話。
そういう需要が一定数あるならば、実行速度調節つきVMを一つ作っておくことだって出来るでしょう。
少なくとも各アプリごとに一々全部解析して、修正して、テストする手間よりはずっと少ない。
>作った会社がすでに潰れてて、権利ひきついだ会社からなんとかバイナリだけ貰えた場合とかは？
パッチ当てりゃいいじゃん。
>そしてコメントの無い逆コンパイルされたコードを解析するだけの工数が割けない場合。
商売的に割に合わない不要な仕事ってだけの話だね。
>そういう需要が一定数あるならば、実行速度調節つきVMを一つ作っておくことだって出来るでしょう。
で、そういうVMは存在すんの? それが「そういう需要」のあるなしとイコールだと思うけど。
>・マシン持ち込みの許可が下りない。予算がつかない。
商売として無価値ってことでしょ。やる必要ないよね。
>・老朽化したり入手困難になるなど。
Javaで? 意味分からん。
>・復刻ゲームサービスなど、現在の環境で実行できないと意味が無い場合。
ソース修正やパッチで対応可能じゃん。
>パッチ当てれば
数値をいじるとか当たり判定潰すとかじゃなく、コードの「追加」だから、難易度は低くは無いと思うが…
パッチそのものの作業はともかくテストを全部一からやりなおしなんて騒ぎにもなりかねない。
>>167でも挙げたが、需要が一定数以上あるなら速度調節機能つきVMは作れる。
そして作ればアプリ毎の改修は行わなくて済むので商業的に割に合いやすくなる。
つまり個々に改修する方式では出せないソフトも出せるようになる。
>数値をいじるとか当たり判定潰すとかじゃなく、コードの「追加」だから、難易度は低くは無いと思うが…
Javaなら超簡単。
>パッチそのものの作業はともかくテストを全部一からやりなおしなんて騒ぎにもなりかねない。
サービス開始前にテスト全部するのは当たり前。
ちなみに、VMに手加えたらテストはアプリどころの話じゃないぞ。
>許可が下りない
この場合は、商売として客に供給するのでは無い場合。
何らかのアプリを社内・学内で使う場合など。
>老朽化したり入手困難
「アプリが開発された当時の古い環境を導入する」のだから当然。
今のマシンではVMのソフトだけ古くても実行速度は当時のものにならない。
あくまで実行速度の話をしていて、その為に当時の環境を用意するというのだから、当然老朽化した古いハードを使う事になる。
>テスト全部
総合テストの話じゃなく、ルーチン単位の単体テストからやりなおしになりかねないって話。
VMに手を加えた分については、VMとしてのテストを行っておいて
その上でVM+目的アプリのテストを行うだけ。
既存の(既に枯れた)VMを使うのとは、VMそのもののテストが追加になるところのみが異なる。
速度調整つきVMをどこかのメーカーが作りアプリサービス会社に供給するのならば、
アプリサービス会社側のテストの量は増えることは無い。
>>>167でも挙げたが、需要が一定数以上あるなら速度調節機能つきVMは作れる。
>そして作ればアプリ毎の改修は行わなくて済むので商業的に割に合いやすくなる。
>つまり個々に改修する方式では出せないソフトも出せるようになる。
動作速度なんてアプリ側でタイマーかなんか参照して取るもんでしょ。
「速度調節機能つきVM」とやらで調整したとして、ある環境ではある条件で速くなる、
ある環境ではある処理で遅くなる、なんて現象出たらどうすんの？
>VMに手を加えた分については、VMとしてのテストを行っておいて
それが莫大な手間だろ。
それが理想なのは言うまでも無いことだが、そうなってないソフトが現実にあるなかで
それをどうしようかってのが話の前提なので、そこを覆されても。
>「速度調節機能つきVM」とやらで調整したとして、ある環境ではある条件で速くなる、
>ある環境ではある処理で遅くなる、なんて現象出たらどうすんの？
それこそエミュレータでも全く同じ問題がついてまわるはずのものなんだが。
それを解決しなければならないのはエミュレータでも同じだし、解決するための技術もエミュレータと共通。
「マシン持ち込み」って何？
少なくは無い手間だが、それでも個々のアプリでやるよりは遥に少なくて済む。
>それこそエミュレータでも全く同じ問題がついてまわるはずのものなんだが。
>それを解決しなければならないのはエミュレータでも同じだし、解決するための技術もエミュレータと共通。
実機のエミュレーションだと実行される命令単位でクロック数計ってタイマーに合わせたり
当たり前にやってますよ。
文字通り、備品として既にそこに置いてあるマシンとは別のマシンを調達してくること。
決められたマシン以外導入禁止なんていうオフィスや学校は珍しくないと思われるが。
Java VMの場合でも、厳密にやるならば、同じように各処理内容(共通ライブラリのメソッドや、バイトコードの命令)ごとに
実機で測った時間などを元にウェイトを設定する事になると思われる
だから技術はかなりの部分エミュレータと共通する事になる
そこまで厳密にやらなければ、メソッド呼出しやバイトコード実行ごとに適当にウェイトを入れるようになるだろうが
そういう実装のエミュレータも数多く存在してるのも同じ。
今そのような動きはあまり見られないからといって、将来もそうであるとは限らない。
例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
将来そのようなサービスが現れる可能性は充分にある。
>文字通り、備品として既にそこに置いてあるマシンとは別のマシンを調達してくること。
>決められたマシン以外導入禁止なんていうオフィスや学校は珍しくないと思われるが。
？？？
仕事に必要なものなら申請書出すなりして購入ってのは普通の話では？
上から与えられた機材のみで仕事？そういう職場って珍しいと思うよ。
> 例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
携帯電話って機種ごとの差異が大きいんで、ちゃんと組まれてればタイミングはアプリ側で取ってるよ。
「ちゃんと組まれてない場合は～」とか言うかもしれないけど、そういう出来の悪いアプリは
リバイバルの対象外で問題ないね。
>例えば、Javaで書かれたような携帯電話用ゲームをリバイバルするという動きは今のところあまり見られていないが
携帯だかPCだか向けのサービスとして、コンテンツ提供側がJavaのVMまで提供？
>将来そのようなサービスが現れる可能性は充分にある。
本気で言ってるのかな？
>Java VMの場合でも、厳密にやるならば、同じように各処理内容(共通ライブラリのメソッドや、バイトコードの命令)ごとに
>実機で測った時間などを元にウェイトを設定する事になると思われる
>だから技術はかなりの部分エミュレータと共通する事になる
『詭弁の特徴のガイドライン』でいうところの
1. 事実に対して仮定を持ち出す
3. 自分に有利な将来像を予想する
ですね?
88に移植する能力もないだろう。
https://www.google.co.jp/search?q=JPC
http://sourceforge.jp/projects/sfnet_jpc/releases/
>ごちゃごちゃ言った所で、JPC等が動ようなjaVAは存在しないし、
Javaの話はVAでJava動かしてその上で何らかのエミュレータを動かそう、とか
そういう流れではないんで的外れ。
そもそも16bitで32bitのタイミングをエミュれる訳がないんだから。
バンクとかEMSに対応した奴あるかな？
よくわからないけど、DPMI対応の方がむしろハードEMSに移植しやすかったりしない？
プッ
必要と思えば申請するが、それが必ず通るとは限らない。
そんな事もわからないニートさんが居ますね。
どんな機種でもうごくように組むより、機種毎に別個に調整された別プログラムとしてサービスされてる事の方が多そうだが…
残念な事だが、世に名作と言われるゲームだからといってプログラムのつくりまでしっかりした物ばかりでは無いよ。
だからプログラムのつくりの悪さをもって安易にリバイバル対象外とする事はできない現実がある。
>>196
DPMIってのはDos Protect Mode Interfaceの略。
つまりDOSでプロテクトモードのプログラムを実行する環境のことだから
それ使われると88VAからは手出しできない。
仮想EMSとDPMIは別ものだよ。
仮想EMSをやるとCPUの特権モードを占有してしまうから
仮想EMSとプロテクトモードアプリとの共存をするために
仮想EMSドライバ側にプロテクトモードへのインターフェースを用意している
その仕組みがDPMIとかVCPIとか。
>コンテンツ提供側がVMまで提供？
Wiiのバーチャルコンソールなんかは文字通りVM(エミュレータ)とのセットで提供されてるのだが。
>本気で言ってるのかな？
今は数々のレトロゲームがリバイバルされてるが、かつてはレトロゲームのリバイバルがあまり注目されてない時代もあった。
過去のものが後の世になって再注目されるというのは珍しい事では無いのだが。
>>188
可能性の存在の話であって仮定の話では無い。
話をすり替えないように。
「可能性があればそれに備える事も考えなければいけない」という議論をしてるときに(例: 事故や災害の対策など)
「仮定の話をするのは詭弁だ」と言うのはおかしいのと同じ。
>可能性の存在の話であって仮定の話では無い。
>話をすり替えないように。
↓は可能性や仮定の話ではなく、現実のバイトコードインタプリタとエミュレータについての話じゃないの?
>バイトコードインタプリタとエミュレータってそんなに言うほど厳密に区別できるもんじゃないだろ。
>エミュレータって原義的には何かの真似してりゃエミュレータなんだから
>たとえ実在しない物でも、それを真似するならエミュレータで無いとまでは断言できないはずだ
>
>技術的には全く同じものと言えるしね」
>>コンテンツ提供側がVMまで提供？
>Wiiのバーチャルコンソールなんかは文字通りVM(エミュレータ)とのセットで提供されてるのだが。
JavaのVMの話でしょ。
>今は数々のレトロゲームがリバイバルされてるが、かつてはレトロゲームのリバイバルがあまり注目されてない時代もあった。
>過去のものが後の世になって再注目されるというのは珍しい事では無いのだが。
ハードウェアやネットワークの進歩で少ない労力でサービスが提供できるようになったから
商売として可能になったというだけであって、今になってレトロゲームが注目されているわけではない。
手出しできないって別にバイナリ動かすんじゃなくて、ソース移植の話だよね？
特権モードより仮想EMS前提のプロテクトモードの方がまだマシなんじゃないかと。
それでないリアルモードと言うと、メモリ周り何も考えてないベタ移植で詰みそう。
>残念な事だが、世に名作と言われるゲームだからといってプログラムのつくりまでしっかりした物ばかりでは無いよ。
>だからプログラムのつくりの悪さをもって安易にリバイバル対象外とする事はできない現実がある。
低いコストで提供する前提の商売では、提供するに当たってコストが発生するタイトルは敬遠されるし、
ある程度の数が見込めるであろうタイトルでは、それなりのコストを払ってでも手を加えていたりする。
バーチャルコンソールは前者。
代わる話は無いけど。
インラインアセンブラか何かでEMSのファンクションコールを呼ぶところだけ自前で書けば
あとは根性で何とかなるでしょ
その根性が多大に要求されるのが困るんだけど…
>インラインアセンブラか何かでEMSのファンクションコールを呼ぶところだけ自前で書けば
EMS呼ぶのにそんなもん要ったっけ?
もう随分昔のことで記憶もオボロゲだけど、Cの標準のライブラリだけで行けたような気がするけど。
LSI-C86だとそんなライブラリはついてなかったと思う
>LSI-C86だとそんなライブラリはついてなかったと思う
お前、製品版買って言ってるの？
試食版使ってる人だって多いんだからいちいち目くじら立てんなよ
製品版が買えない貧乏人は黙って試食版を使っておけっての
なんでお前そんなに偉そうなんだよ
>LSI-C86だとそんなライブラリはついてなかったと思う
製品買ってるならまだしもフルセットでもない試食版でねぇ、こういうこと言うかな？
説明してミソ
「EMSアクセス」でぐぐったら↓が親切に説明してたよ。
http://www2.muroran-it.ac.jp/circle/mpc/front/old1/program/pc98dos/ems.html
コンパイラに付属するその他のライブラリは含まれない
インラインアセンブラ無しでも_bdos関数か何かCの標準ではないライブラリで可能ではある
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
>コンパイラに付属するその他のライブラリは含まれない
お前ルール乙
>インラインアセンブラ無しでも_bdos関数か何かCの標準ではないライブラリで可能ではある
「LSI-C86だとそんなライブラリはついてなかったと思う」とか言ってる奴のことも考慮しろよｗ
>Cの標準ライブラリはローカルルールではなく公式
「Cの標準のライブラリ」だから違う話。
「Cの標準のライブラリ」も「Cの標準ライブラリ」も変わるわけが無かろう
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
CがANSIとかで仕様化される以前は「標準のライブラリ」は存在しなかったってご意見？
>Cの標準ライブラリはローカルルールではなく公式
「ANSI Cの標準～」「C99の～」とかって話ならそうかもね
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
Standard LibrarｙってK&Rの頃から使われてたし、その頃にはCに仕様なんかなかったよ。
デジュレスタンダードが無ければ仕様が無いというわけでは無いな
>>227の言うような「C言語の仕様で規定された～」なーんて言えるような状態じゃなかったよ。
UNIXって仕様よかコードを書く文化だから仕様がないのは珍しいことではなかったしな。
>「Cの標準のライブラリ」という場合はC言語の仕様で規定されたライブラリだけを指す
「仕様」って「規格」のことだろ。