PC-6001エミュレータ開発日記

PC-6001 エミュレータ開発日記

■ [08/08/09] - WAIT信号

PC-6001初代のWAIT信号について記録。

	ORG 0DF00H 
	DI 
	LD A,02H 
	OUT (93H),A 
	LP: OUT (0A0H),A 
	JP LP

EXEC &HDF00して、OUT命令とJP命令が交互に実行されている様子をロジアナで確認しました。

青い線のマーカーラインA-Bの区間がOUT命令の実行状態です。最初の命令フェッチでM1信号がActiveになりますが、そのタイミングでWAITが1Clock分だけ入ります。これは以前からわかっていたのですが、IORQのタイミングでも WAIT信号がActiveになります。つまり、OUT命令では+2Clockとなります。一応、接続されているI/OデバイスによってWAITの入り方が変わるのかと思い、出力先ポートをA0Hだけではなく、OUT (00H),Aとしてみたのですが、この場合も同様の結果でした。

続いてOUT命令の変わりにIN命令を連続実行してみます。

IN命令の場合も同様に、+2Clockとなりました。

次はOUT(C),r命令です。

OUT (C),r命令は、第二OPコードを持ちますからM1が2回続きます。それに加えてIOREQのタイミングでWAITが入るので全部で15Clockになっています。

最後に、メモリライト命令です。

LD (nn),A命令をループ実行させましたが、WR信号発生時にWAIは入りませんでした。RDと同じようです。

今のところ、WAITが入るのは

命令のM1サイクル
IOリード/ライト

のタイミングということになります。

これらはRAM領域でのプログラム実行の結果なので、ROM領域では違う結果になる可能性があります。

PC-6001MkII解析マニュアルには、IOポートのF3HでM1やROM領域、RAM領域のアクセス時にWAITを入れるかどうかを設定変更できるような記述があります。初期状態は、M1とROMアクセスでWAITが入るようになっています。

実際に実機上でM1でのWAITをOFFにするよう設定し、ロジアナで調べたのですが、 WAITはなくなりませんでした。

ROM領域アクセス時のWAITをOFFにし、BASICで単純なループプログラムを実行したところ、処理速度が向上しました。 BASICのインタプリタが内蔵ROMにあり、この領域へのアクセス速度が向上したのだと思われます。外部ROM、つまりROMカートリッジに対しても有効なのかは調べきれませんでした。

M1とROM領域両方のWAITをOFFにすると、見た目、暴走します。内部でどのような暴走状態にあるのかわかりませんが、 CRTCをOFFにした後にM1/RAMのWAITをOFFにするとZ80自体はまだ動いているような信号の動きをしていました。

IOポートF3Hは、MODE1でも有効なようで、MODE1で起動後、ROM領域でのWAITをOFFにすると、BASICの実行速度が向上しました。

■ [04/12/06] - SR信号線

SR Signal line

PC-6001MkIISRの信号線をロジアナで取ってみた。この時のプログラムは、

	C000: DI
	C001: JP C001H

として、単純にRAM領域のJP命令をひたすら実行するというものなのに、内部で何をしているのか、まったくわからない。WAIT信号には租と密な箇所があるので、これが水平描画か何かのタイミングなのか。 WAIT信号を制御することで、Z80とCRTCがVRAM=MAIN RAMへアクセスするタイミングをずらしているようだ。2番目の画像が租な箇所で、3番目の画像が密な箇所。WAIT信号が非常に複雑。もしかすると垂直同期期間ではWAIT信号の変化が違うのかもしれない。そのあたりも測定しておけばよかった。

結果的には「よくわからない」ということになってしまったが、理由は別として、どれだけのWAITがかかっているのかは読み取れると思う。

上記測定の密の箇所だけでなく、初代機でも、 WAIT信号が入ってくるのはM1サイクル時のみ。通常のメモリアクセスにおいてはWAITはかかっていない事に注意。

今回は8049にもプローブをあてたのだが、 8049に接続されているのはCMTやキーボードと低速な周辺I/Oなので、うまく測定することができなかった。

測定したデータを見たい方は、 MyLAを利用してください。MODE1での結果も入っています。このデータを利用すれば、WAITの幅をμ秒単位で読み取ることができます。

■ [02/11/09] - 仮想キーボード

オホーツクとか、某SFアドベンチャーゲームをデバッグしようにも、普段は 101キーボードなので、カナの位置がわからない。最初は実機と見比べながらやっていたのだけれど非常に苦痛なのでキー配置図をPC-6001MkIIのマニュアルから取り込んでマウス座標を取得して...という処理を加えてみた様子がこれ。

仮想キーボード

“ろ”のキーを押しても出ないのはX版のキー処理がそうなっていたからかな。

SHIFTやGRAPHキーの処理を組み込んでいないし、GRAPHキーを押したら、やっぱり仮想キーボードの配置図も変わるとうれしいし、JISキーボードは慣れていないので50音配置ボタンとかも欲しいな、とか考え始めると非常に手間のかかることになりそうなので放置中。そういえばX88000はIME経由で入力できるのでしたっけ。

■ [02/11/04] - オホーツクに消ゆ

「オホーツクに消ゆ」でシーン4からシーン5へのロードが出来ないというメールが届いていたので調べたのですが、原因は“テープ走行速度 > メッセージ表時速度” という、いつものやつでした。イメージを書き換えるという対処ができない形式なのでお手上げです。エミュレータでのテープの読み込み速度を落とせばいいのですが、読み込み時間が実機並になります・・・。

オホーツクはアドベンチャーゲームだけあってプログラムに暗号化っぽいことがされていて解析も面白かったですよ、はい。

■ [02/09/8] - バグ取り

久々にエミュレータのコーディングミスに遭遇しました。

void SetTimerIntClock(long pow)
{
	TimerInt_Clock = BaseTimerClock * ((pow + 1) / 4);
}

という箇所があり、わざわざ括弧をつけてまで演算精度を下げてますね、昔のワタクシ。これまで解析してきたソフトでタイマ割り込みのタイミングを変えているものはドアドアMkIIぐらいで、これはpowの値をとても大きくしていたので問題が表面化しなかったのですが、先日、「ダメ人間養成所mk2」さんのところの「PSG音源ドライバ ver1.1」に対応した曲で問題が起きる、とKさんに指摘されまして調べたところ、powに1という値が入ってきた時に演算結果が0になるというバグに気が付いたわけです。

ついでにテラ4001がデモ画面から先に進まないというバグを調べました。 I/Oポートの94Hを使っているようでして、このポートは90Hの影ですから、CASE文を一行追加したら先に進むようになりましたとさ。

■ [02/09/4 .. part2] - Talk

音声合成用ICへ出力されるデータを眺めようとファイルに書き出ししてみたのだけれど、あれ？終端文字列って0x00が7個じゃなかったっけ？6個しか出力されていないのですけど、どこかで勘違いしてるかファイル出力にバグがある？

■ [02/09/4] - BUSREQ Memo

H LINEのBUSREQはONが31.340μsでOFFが22.350μs、V LINEのBUSREQはONが4495.917μs。

■ [02/09/3] - ROMカートリッジ

BEST MONITOR

BASIC Compiler

結局、Saverを使ってコンバートしました。

実機を引っ張り出していろいろ。ホルマントかぁ。音のドコまでをエミュレートしたらいいのかっていったら、 AY3-8910の出力端子がコンデンサに接続されていてフィルタが・・・というところまでかな。実機の方が音がまろやか(?)なのは、そういうわけでして。

■ [02/08/31] - ROMカートリッジ

手元にBASICコンパイラとBESTモニタのROMがあるのでAKI80で吸い出そうと真夜中の3時にバタバタとセッティング。でも、ROMライタ付属のFDDが9801フォーマットでAT互換機用ソフトが取り出せなかったり、シリアルケーブルが25PINだったり、挙句の果てにROMライタが2732に対応していなくて仕切りなおし。

BASICコンパイラで検索したら、その作者さんのWebページがヒット。

本業がゲームショウ関係でバタバタしていて大変な感じ.

■ [02/08/27] - 波形をみた

初代機を分解して波形をみてみました。まずはM1から。メモリアクセスに関しては1ClockのWAITが入っています。あ、ROMとRAMで違うのかどうか調べ忘れました。Mk2以降では違うかもしれません。

次にBUSREQです。BUSREQが細切れに変化している箇所と、HIGHが連続的している部分がみてとれます。 VIDEOコントローラのHS/FS信号に合わせて変化していますね。ですので、Z80が動作できるのは、水平帰線期間と垂直帰線期間ということになります。

続いてINTの発生タイミング。TimerINTのラインがわからなかったので 4040の出力を調べていますが、4040の↑に合わせてINTが↓が変化しています。ただ、この時はBUSREQがACTIVEなのでINTはLOWのままとなり、BUSREQがHIGHになると同時にINTがクリアされてZ80が割り込みを受け入れています。なので、TimerINTが発生した時に BUSREQ状態であれば、割り込みは待たされることになります。キャプチャ画面ではキーボードや CMT割り込みの発生源である8049のライン変化が出ていませんが、タイマ割り込みと同じ動きをしていました。

ところでタイマ割り込みと8049系の割り込みが同時に発生した場合なのですが、残念ながら調べることができませんでした。条件がシビアですし、いいトリガタイミングがないのですよ。

■ [02/08/24] - 波形をみたい

各種割り込みが同時に発生した時って、優先度の低い割り込みは待たされるのでしょうか、それともキャンセルされてしまうのでしょうか。

水平描画時と垂直描画時にはBUSREQが発行されるのでZ80は止まることになっているのですが、水平描画時の帰線期間も止まっているのでしょうか。また、描画OFFモードではBUSREQが発行されませんが、描画ONにした時は、どのタイミングで描画が始まるのでしょうか？途中から？それとも垂直帰線終了後から？

とかまぁ、細かい疑問がいくつかありまして、回路図をみてもよくわからないのですね。そういう時にはまよわず波形をみればいいということで、注文しましたよ、オプティマイズさんのカメレオンUSB+ロジアナ。ロジアナソフトは、Psxpadさんのところのから。動作確認は終わったので、明日にでもPC-6001をバラして波形をみてみようと思います、楽しみ。

■ [02/08/22] - BUSREQ

最近ずっとヘッドフォンつけてPSGな音を聴いていたから耳が痛い。

実機でハイドライドを起動してみると、全然速度が違う～。ステップ数計算を間違えたかなぁと調べてみても問題ない。描画WAITを0にしたくらいでちょうどいいな・・・って、まさか、 CRT OFFを使っているのでは！？と思ったら大当たり。高速描画するならボクも同じ方法を使っただろうけど、 RFモジュレータでTVにつないでいる時には砂嵐が表示される可能性があるから禁じ手だと思っていました。ただ、短時間であれば問題なく、ハイドライドではLDIとEXとLD HL,SPの組み合わせを使ったりして、その辺は考えられているなぁと。ありゃ、DoorDoorMk2でもタイトル画面で全画面クリア時に使用してるな。

■ [02/08/19] - version0.64 rel6

エミュレータの終了時に落ちる（終了するではなく）という報告があるのですが、手元の環境で再現せず困り中。

エンベロープが短いというご指摘がありましたように音に対して無頓着すぎでした。少しだけ手を加えただけでChack'nPopの音が鳴り出しました、なるほど。それでもまだまだですけど。一日中、1KHzの矩形波を聴いていたので耳がおかしな感じ。

■ [02/08/17] - version0.64 rel6

不都合がたくさん出るかと思われます。ステータスバーは無くす方向で考えています。この手の動作情報は別ウィンドウにまとめて出そうと思いまして。

音にノイズがたっぷり・・・。

■ [02/06/29] - sound

サウンドドライバ周りを修正中。30分ほど1KHzのテストをしていたので耳がヘンになりそう。

■ [02/06/25] - Virtual66SR

PC-6601SRエミュレータのVirtual66SRというのがあるそうです、すばらしい。

■ [02/06/16] - SRのVRAM その4

VRAMをあれこれと書き換えてみたことをMEMOしておきます。PREタグ使ってるんで表示がグタグタかも。

		-SCREEN2-

		REM (256,0)がVRAMの0000Hに対応しているらしい
		PSET(256,0),16		0000: 0F 00 00 00 00 00 00 00
					0008: 00 00 00 00 00 00 00 00

		REM 1バイトで2Pixelらしい
		PSET(256,0),16		0000: FF 00 00 00 00 00 00 00
		PSET(257,0),16		0008: 0F 00 00 00 00 00 00 00

		REM 2バイトで4Pixelは隣り合っているけど...
		PSET(256,0),16		0000: 0F 0F 00 00 00 00 00 00
		PSET(258,0),16		0008: 00 00 00 00 00 00 00 00

		REM 2バイト単位で飛び飛びらしい
		FOR I=0 TO 15		0000: 10 32 00 00 54 76 00 00
		PSET(256+I,0),I+1		0008: 98 BA 00 00 DC FE 00 00
		NEXT

		REM 偶数ラインと奇数ラインが交互にならんでいるらしい
		FOR I=0 TO 15		0000: 00 00 12 32 00 00 54 76
		PSET(256+I,1),I+1		0008: 00 00 98 BA 00 00 DC FE
		NEXT

		REM Y=2は0100Hから始まるらしい
		FOR I=0 TO 15		0100: 10 32 00 00 54 76 00 00
		PSET(256+I,2),I+1		0108: 98 BA 00 00 DC FE 00 00
		NEXT

		REM Y=4は0040Hから始まるらしい...ちょっと変則的？
		FOR I=0 TO 15		0040: 10 32 00 00 54 76 00 00
		PSET(256+I,4),I+1		0048: 98 BA 00 00 DC FE 00 00
		NEXT

		REM 以下、同様に調べてみると...規則性はあるけどねぇ
		PSET(256+I,6),I+1	0140:
		PSET(256+I,8),I+1	0080:
		PSET(256+I,10),I+1	0180:
		PSET(256+I,12),I+1	00C0:
		PSET(256+I,14),I+1	01C0:
		PSET(256+I,16),I+1	0200:
		PSET(256+I,18),I+1	0300:
		PSET(256+I,20),I+1	0340:

		REM (0,0)は1A00Hから始まるらしい
		PSET(I,0),I+1		1A00: 10 32 00 00 54 76 00 00

		REM 以下、同様に調べてみると、こちらは素直な並び
		PSET(I,2),I+1		1B00: 10 32 00 00 54 76 00 00
		PSET(I,4),I+1		1C00: 10 32 00 00 54 76 00 00
		PSET(I,6),I+1		1D00: 10 32 00 00 54 76 00 00
		PSET(I,8),I+1		1E00: 10 32 00 00 54 76 00 00
		PSET(I,10),I+1		1F00: 10 32 00 00 54 76 00 00
		PSET(I,12),I+1		2000: 10 32 00 00 54 76 00 00
		PSET(I,14),I+1		2100: 10 32 00 00 54 76 00 00
		PSET(I,16),I+1		2200: 10 32 00 00 54 76 00 00

		-SCREEN3-

		REM (512,0)がVRAMの0000Hになるらしい
		PSET(512,0),4		0000: 80 80 00 00 00 00 00 00

		REM 偶数ラインと奇数ラインが交互に並んでいるらしい
		PSET(512,1),4		0000: 00 00 80 80 00 00 00 00

		REM 2バイトで8Pixelらしい
		LINE(512,0)-(519,0),4	0000: FF FF 00 00 00 00 00 00

		REM SCREEN2と違って素直に並んでいる？
		PSET(512,0),4		0000: 80 80 00 00 80 80 00 00
		PSET(520,0),4		0008: 80 80 00 00 80 80 00 00
		PSET(528,0),4
		PSET(536,0),4

		REM 素直でよい
		LINE(512,0)-(639,0),4	0000: FF FF 00 00 FF FF 00 00
					00xx: 略
					0038: FF FF 00 00 FF FF 00 00
					0040: 00 00 00 00 00 00 00 00

		REM (0,0)がVRAMの1A00Hになるらしい
		PSET(0,0),4		1A00: 80 80 00 00 00 00 00 00

なんとなく見えてきました。

Macintosh G4 Cubeを譲ってもらい、自宅に持って帰りました。 OS-Xであれこれやってみたいところですけど、Objective-Cだけならともかく、あのフレームワークまで理解しないといけないのは面倒だなぁと。 WindowsでもMFCなんかも使わずにWin32SDKだけでやってるワタクシとしては、 MacでもC言語とAPIだけの環境が欲しいのですが。

■ [02/06/12] - SRのVRAM その3

読み込みメモリのBank切り替え(I/Oの60h～67h)においても16Kの壁があるようです。

		CPU空間の8000hにRAMの0000hを割り当てる ... OK
		CPU空間の8000hにRAMの2000hを割り当てる ... RAMの0000hが出てくる
		CPU空間の8000hにRAMの4000hを割り当てる ... OK

		CPU空間のA000hにRAMの0000hを割り当てる ... RAMの2000hが出てくる
		CPU空間のA000hにRAMの2000hを割り当てる ... OK
		CPU空間のA000hにRAMの4000hを割り当てる ... RAMの6000hが出てくる

前半は前半、後半は後半にしか割り当てられないようですね。

もう1つ次の手順でメモリを切り替えて、

		(1)CPU空間の8000hにRAMの0000hを割り当てる ... OK
		(2)CPU空間のA000hにRAMの4000hを割り当てる ... RAMの6000hが出てくる

このようにしても(2)の影響で(1)の割り当てアドレスが0000hになってしまうようなことはありませんでした。

SCREEN1ではASCIIコードとアトリビュートが交互に並んでいる単純なVRAM構成です。

SCREEN3の場合...

		screen 3,2,2
		line(0,0)-(639,0),4
		では、
		0000: FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 
		0010: FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 
		0020: FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 
		0030: FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 
		0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
		0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
		こうなります。

		screen 3,2,2
		line(0,1)-(639,1),4
		では、
		0000: 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 
		0010: 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 
		0020: 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 
		0030: 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 
		0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
		0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
		こうなります。

マニュアル上では4バイトで8Pixel(4色なのでRGB各2bit)と書かれているのですが、 Z80を通してVRAMにアクセスすると4bitが2バイトにパックされた状態となります。

また、奇数ラインと偶数ラインが交互に出てきているのがわかります。

SCREEN2の場合...

		screen 2,2,2
		CLS
		line(0,0)-(319,0),4
		では、
		0000: 44 44 00 00 44 44 00 00 44 44 00 00 44 44 00 00
		0010: 44 44 00 00 44 44 00 00 44 44 00 00 44 44 00 00
		0020: 44 44 00 00 44 44 00 00 44 44 00 00 44 44 00 00
		0030: 44 44 00 00 44 44 00 00 44 44 00 00 44 44 00 00
		0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		こうなります。

		screen 3,2,2
		CLS
		line(0,1)-(319,1),5
		では、
		0000: 00 00 55 55 00 00 55 55 00 00 55 55 00 00 55 55
		0010: 00 00 55 55 00 00 55 55 00 00 55 55 00 00 55 55
		0020: 00 00 55 55 00 00 55 55 00 00 55 55 00 00 55 55
		0030: 00 00 55 55 00 00 55 55 00 00 55 55 00 00 55 55
		0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		こうなります。

マニュアル上では1Pixelで1バイトと書かれているのですが、 Z80を通してVRAMにアクセスすると4bitが2バイトにパックされた状態となります。 2バイトで2Pixelです。

また、奇数ラインと偶数ラインが交互に出てきているのがわかります。

ただ、I/OポートにY座標を指示する為のレジスタがあり、これによってメモリコントローラがデータの並びを入れ替えているでしょうから、これらの結果を鵜呑みにすることはできません。

さらに面倒なのはVRAM上でのデータの並びと配置でして、それは明日以降に続く、と。

■ [02/06/11] - SRのVRAM その2

VRAMからのリードはMAIN RAMの0000hをCPU空間の8000hに上げて、X座標をHLに入れて最上位BitをONにしてからLDする。ナニユエ0000番地？MAIN RAMは32K、VRAMが32Kあるような感じなんだけど、実際にどうかはともかく、エミュレータでそういう風に実装してもよさそう。

いまだにMAIN RAMの構成も理解が足りなかったりする。32KBytesしかないように見えるんだけど。

初心に戻ってPC-6001mkIISRの取扱説明書を開く。ブロックダイアグラムのバスを見ると...メモリコントローラがDRAMにつながってないし！なにそれ。っていうか、Z80とDRAMのデータバスがつながってないし！

DRAMを制御しているのはCRTコントローラ2のみで、D-RAMのバスは同じくCRTコントローラ2とVRAMデータバスが、CRTコントローラ1とVRAMアドレスバスが接続されているらしい。あ、VRAMとはDRAMであって、メインの RAMのことですね。メモリコントローラは各種ROMとZ80と接続されていると。さらにさらに、Z80データバスは CRTコントローラ2と接続されて、Z80アドレスバスはCRTコントローラ1と接続されている。メモリコントローラとCRTコントローラのつながりはない。Z80はCRTコントローラを経由しないとメモリにアクセスできないってことですか？

P6にはゼンゼン関係ないけど、午後の国GREACE SIDEが再開してた。

■ [02/06/10] - SRのVRAM

VRAMはフラットなメモリ構成だと思い込んでいたら全然違うし。W氏の資料を読んでから、 PSET/POINT命令の逆アセンブルリストを読んだり。640x200の時は4Bytesで8Pixelで 160Bytes/Lineという構成らしく割と単純。問題は320x200の時で、わけがわからん。 VRTCとRAMをどうやって接続しているんだか。メモリアクセスルーチンは Z80Coreで頻繁に呼び出されるから、ここに条件分岐を書き加えたくはないのだけれど。
[訂正]320x200だとフラットらしい。・・・まてまて、320x200では1Pixelで1Byteだから 64000Bytes必要だけど、SRの仕様は2画面取れると。VRAMは128Kbytes積んでる？わけなくて、 1Pixelで1Bytesの上位4Bitは使っていなことから、VRAMの構造（というかCRTCからのアクセス）はアドレスバス8本単位で分かれていると考えられると。でも、W氏の解析と違ってきちゃうし、 X版では実際に動作しているのだから、どこかしらボクが勘違いをしているっぽい。

I/Oポートに流れるデータをみていてもわかるように、とにかくVRAMへのアクセスが複雑で重すぎ。SRって使いにくい。ゲームソフトが出なかったのは時代の流れだけでなくてアーキテクチャにも問題があったのだなぁと思ったり。

■ [02/06/09] - SRのRAM

RAMへのアクセスは16Kbytes単位で8Kbytesしか選択できない？・・・よくわからんです、はい。つまり後ろ半分の8KBytesはつかえないってコト？

ROMの読み込み、メモリマップと関係するI/Oポート、垂直同期割り込みモドキをくっつけたら、VRAMを書き換え始めた。来週は描画処理ということで。・・・VRAM破壊してるだけだったら泣ける。

■ [02/06/04] - 画面サイズ

SRは縦方向に204Lineあるということをすっかり忘れてました。こうなるとウィンドウを 640x480にしてセーフティを含めた無描画部分も用意してやろうかという気にもなったりしますけど。

■ [02/06/01] - リンク

放置している間にも各方面の方々からメールを頂いていまして、PC-6001系のサイトを立ち上げられた方もいらっしゃいましたから、ここでつないでおきます。ココのTOPにあるリンク集を安易に書き換えとWWWC/WWWDが反応してしまい、『エミュレータ本体が更新された？！』と思わせてしまうのも申し訳ないので。

ぱぴーなSOFT図鑑

OLION ULTIMANIA

もれがあったら申し訳ありません。

MODE1のscreen3/4が出るようになってEGGYとかスペハリとかTINY XEVIOUSあたりが 640x400で表示できるようになった。AX-7あたりはまったくダメなんだけど、描画処理が理解できていないのと、動作確認用のプログラムがないので放置。

■ [02/05/31] - 2倍

1ヶ月に一時間ぐらいのペースでコード書き換えてますから、カタチになるものが出来上がるまでには、かなりの時間を要するわけでして。それでも SR対応の準備として640x200での描画から。BASICでの各SCREENモードは割とカンタンなんですが、MC6847が持っている他のモードでの描画処理がサッパリわかりません。

そのうち、isioさんに教えを乞うということで・・・。

2000年までの日記 / PC-6001のページに戻る