<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>パピコニアンの倉庫 - 整頓中 &#187; PC-6001</title>
	<atom:link href="http://www.retropc.net/mm/archives/category/pc-6001/feed" rel="self" type="application/rss+xml" />
	<link>http://www.retropc.net/mm</link>
	<description>コメントスパムがひどいのでコメント欄を閉じています。ご用の方はTWITTER(@morian)へ</description>
	<lastBuildDate>Mon, 30 Mar 2026 14:28:56 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>タイニーゼビウス 完全解析＆解説</title>
		<link>http://www.retropc.net/mm/archives/1718</link>
		<comments>http://www.retropc.net/mm/archives/1718#comments</comments>
		<pubDate>Tue, 15 Sep 2015 13:50:21 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1718</guid>
		<description><![CDATA[PC-6001同人誌「PC6000NOTE No.5」に寄稿した記事をWeb用に再編集してアップロードしました。 タイニーゼビウス 完全解析＆解説]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1718/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6001mkII版ハイドライドをSMC-777に移植</title>
		<link>http://www.retropc.net/mm/archives/1675</link>
		<comments>http://www.retropc.net/mm/archives/1675#comments</comments>
		<pubDate>Tue, 07 Jul 2015 12:27:18 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>
		<category><![CDATA[RETROPC]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1675</guid>
		<description><![CDATA[移植しようとしたきっかけとか、まるで無くて、なんとなーく移植してみたくなったので移植しました。オモチャ（SMC-777）が手元にあったから、という以外の理由が思い当たらず、趣味のプログラミングとして楽しんだというところです。かかる費用は自分の時間だけですし。 ■ まずはトーフの表示 SMC-777の基本スペックはWikipediaでもみてください（間違いもありますが）。 SMC-777は仕様がオープンなマイコンです。というのも、付属のマニュアルにはハードウェアの回路図から各種設定項目まで全てが記載されています。 VRAMに何かを書き込みたければ、マニュアルを読めば手順がわかりますし、それなりに丁寧に説明がされています。だからといって、簡単に絵が描けるかというと、それほど甘くはありません。 グラフィック画面のスペックは、320×200ドット16色、もしくは640×200ドット4色です。今回は320×200ドットの画面モードを使います。その場合のVRAMアドレスはこのようになっています。 1ドットは16色なので、1ドットあたり4ビット、1バイトには2ドット分の情報が詰まっていることになります。となりのバイトは2ドット隣になるので、1ドット単位で絵を動かすのが苦手（面倒）ということになります。もっとも、この時代のマイコンで1ドット単位で絵を動かす事は無理要求ではあります。 問題はVRAMのアドレスです。 2ドット隣は2バイト先のアドレスなので、1バイト当たりの座標は一致しているのですが、1バイト(2ドット)書き込む毎にアドレスを+2しなければならないので、横方向にドットを連続して打つコストが高めです。 縦方向は+$1000です。ただし、8ドット毎に+$A0されて、ついでに上位2バイトは$00にリセットされます。8×8ドットのものを描くのであればさほど苦労しませんが、8ドット目をまたぐ場合、ちょっと面倒なことになります。 面倒さはまだ続きます。 VRAMがどこにあるかというと、I/O空間にあります。SHARP X1と同じですね。VRAMサイズが32KByteで8ビット幅では足りないので、アドレスバス16ビットを使ってアクセスします。OUT (C),A命令を使うと、Cレジスタがアドレスバス下位に、Bレジスタがアドレスバスの上位に乗るというZ80の仕様を使ったハードウェア構成です。 ただし、SMC-777では、単純にZ80のアドレスバス16ビットがVRAMのアドレスバスに素直につながっているのではなく、上位8ビットと下位8ビットが入れ替わって接続されています。Cレジスタを固定してOUT (C),A → INC B → INC B → OUT (C),A&#8230;というように連続してVRAMに書き込みが出来るという、なんとなく効率よさそうな仕様なのですが、VRAMの並びが変則的なので、実際にはそんなに甘くありません。 まず、横方向については、Y座標が9の時とかでは、横方向のアドレスがBレジスタに収まらなくなり、桁あふれが起きます。つまり、INC BCのCが$FFを越える場合があるのです。INC BCはCレジスタの桁上がりが自動的にBレジスタに加算されますが、SMC-777では、BレジスタとCレジスタが逆並びでVRAMにつながっているので、INC CBという命令が欲しくなります。当然、そんな都合のいい命令はありません。 縦方向は先にも説明したとおり、Y+1ごとに+$1000だけども、8ドット毎に$A0され、尚且つ、+$1000されない(=$A0-$1000される)という条件になります。 このように線を1本描くだけでもレジスタのやり繰りが大変なのですね。Z80アセンブラ最適化ゲームとしてはなかなか面白いのかもしれませんが。 こういう仕様はカタログのスペック表からは読み取れませんから、よくあるマイコンスペック比較が無意味なのがよくわかります。 そんなSMC-777のハードウェア仕様を頭に入れて、VRAMに8×8ドットの白い四角が描けるようになれば、あとは応用でレンガ画像を敷き詰められるわけです。 この画像だけで既にハイドライドっぽい！始まりの予感！ 基本的にPC-6001mkII版のハイドライドは8×8ドットのパターンを並べて描画するようになっています。16×16ドットキャラや、縦線やボックスフィルのようなドット単位での描画処理もありますが、最初に8×8ドットが描ければ、そこから一気に移植が進むようになります。 美しい・・・。 PC-6001mkIIとSMC-777は共に16色(P6mkIIは黒と透明黒があるので見た目は15色)が表示できますが、パレットは並びだけでなく色自体が違います。 上がPC-6001mkIIのパレットで下がSMC-777です。SMC-777の方が渋い色がありますね。これを見比べて、なんとなく似た感じの色を割り当てました。 SMC-777Cのパレット機能か、SMC-777用のパレットボードを装着してパレット機能を使えば、PC-6001mkIIと同じ色に出来ると思うのですが、残念ながら所有していないのでした。 ■ メモリが足りない PC-6001mkIIの16色(見た目は15色)モードでは、スクリーンのメモリ上の解像度が160&#215;200ドットで、表示時に320&#215;200へと横方向に2倍化されます。 それに対して、SMC-777は16色で320ドットの表示が出来ますから、横方向解像度はSMC-777の方が高いということになりますが、それが良いかと、そうでもありません。単純に考えても、画像のデータ量が2倍になります。PC-6001mkII版のハイドライドは、オンメモリ動作で、グラフィックデータが30Kバイト弱ほどあり、それ以外のプログラムやマップデータでほぼRAM 64Kバイトを使い切っていますから、画像データが2倍になると64KバイトのRAMには収まらなくなります。 ハイドライドでは全ての敵が一度に出ることは無く、多くても一画面あたりの敵は4種類程度ですから、データの圧縮を使ってやりくりする事はできます。ただ、そうなると320ドット用にドットを打ち直すことになりますし、PC-6001mkII版がSMC-777を侵略、じゃなかった、PC-6001mkII版を素直に移植するのとは違う話になるので、PC-6001mkIIの解像度を再現する事に決めました。 つまり、1ドット単位で描くのではなく、2ドット同時に同じ色を書き込むということで横2倍化にしています。幸いにも、SMC-777のVRAMは16色4ビット構造なので、1バイト書き込むと2ドットとして画面に表示されますから都合が良いです。 ざっとまとめると、メモリ上の画像データは横半分状態になっているので、描画ルーチンで2倍化、つまり、4ビットデータを8ビットに広げています（敷衍化？）。例えば、$12を$11,$22に展開してVRAMに2バイト書き込むのですね。 余裕があったら、PC-8801版の8色グラフィック画像に差し替える案も考えていたのですが、そんな時間的な余裕はなく、あと、SMC-777のVRAMは垂直型16色4ビットなのに対してPC-8801は水平型8色で、動的な画像変換が重そうだったのでやめました。 ■ 移植話その1 PC-6001mkII版のプログラムコードは昔からちょっとずつ読み進めてて、7,8割くらいは解析してあります。一部の敵の動きのアルゴリズムを読んでなかったり、PC-6001mkII版ハイドライドのプログラムには自己書き換えがあったりもして、まだ知らないコードもあるのですが、PC-6001mkIIとSMC-777のCPUはどちらもZ80系ですし、RAMも64Kバイトなので、「I/O周りを整えれば同じように動作するでしょ」くらいの気楽さでPC-6001mkIIのコードをSMC-777にゴッソリ持ち込んでいます。 それに、元のハイドライドのプログラムが描画処理とそれ以外が比較的分離されていたので、移植しやすかったです。ハイドライドの神様に感謝です。 移植作業をもう少し具体的に説明すると、PC-6001エミュレータでハイドライドを起動して、テープロードが完了したゲーム開始前の状態のRAMをファイルに落として、必要な箇所だけを切り出して、それを逆アセンブルして、さらにそれをZ80のアセンブラ（今回はpasomoというアセンブラを使いました）でSMC-777のバイナリにして、D88形式のファイルに書き込んでいます。 D88形式のファイル生成には、bookwormさんのd88toolを使わせてもらっています。ただ、SMC-777エミュレータで扱えるD88形式はヘッダが異なるので、その辺は自作ツールで変更しています。 [...]]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1675/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6601SR 赤外線キーボードをWindowsパソコンで代用してみる</title>
		<link>http://www.retropc.net/mm/archives/1629</link>
		<comments>http://www.retropc.net/mm/archives/1629#comments</comments>
		<pubDate>Sun, 30 Nov 2014 11:20:01 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1629</guid>
		<description><![CDATA[PC-6601SRの赤外線キーボードを、Windowsパソコン+USB赤外線キットで代用してみました。 記事の詳細は別サイトで。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1629/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6001 SCREEN MODE4 の色滲みを調べる</title>
		<link>http://www.retropc.net/mm/archives/1615</link>
		<comments>http://www.retropc.net/mm/archives/1615#comments</comments>
		<pubDate>Fri, 31 Oct 2014 10:13:29 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>
		<category><![CDATA[RETROPC]]></category>
		<category><![CDATA[同期信号]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1615</guid>
		<description><![CDATA[別サイトへのリンクですが、PC-6001の色のにじみ現象とはなんなのか、とことん調べてみました。NTSCで色が出る仕組みや、AppleIIの発色方法などの参考にも。 PC-6001 SCREEN MODE4 の色滲みを調べる]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1615/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6001mkIIのバージョン違い</title>
		<link>http://www.retropc.net/mm/archives/1202</link>
		<comments>http://www.retropc.net/mm/archives/1202#comments</comments>
		<pubDate>Tue, 06 Aug 2013 12:34:30 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1202</guid>
		<description><![CDATA[PC-6001mkII本体にはバージョン違いがあるようです。 以前からPC-6001シリーズに搭載されているBASIC ROMにはCRC違いがあると言われていたのですが、mkIIの場合は目に見える形で違いがわかります。 PC-6001好き好きメンバーの推測では、これらの写真のmkIIが後期バージョンだと考えられています。 起動時のメニュー画面では、“PC-6001 Mk2 BASIC”が“PC-6001 Mk-2 MENU”になっています。 BASIC起動後の画面ではバージョン表記が“Ver.1.7”がVer. 1.7”になっています。 mon（機械語モニタモード）からBASICへの復帰時にAGAIN BASICと表示されません。従来のmkII(前期バージョン)だとこんな感じでした。 機械語モニタのB-R命令実行時も素っ気なくなっています。 前期バージョンでは REVIVAL AND AGAIN BASICと表示されていたのですね。 ちなみに、後期バージョンでBASIC起動直後にmon→B-Rとするとハングします。キーボードを押すとポチポチと音はするので割込みは生きてるっぽいのですが。 本体内部のBASICのROMにプリントされている文字にも違いがあり、PCR-02がPCR-02Bになっています。 BASICの内部処理自体にも変更点があるようで、えすびさんがまとめてくださっています。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1202/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>タイニーゼビウスをX68000に移植してみた</title>
		<link>http://www.retropc.net/mm/archives/1033</link>
		<comments>http://www.retropc.net/mm/archives/1033#comments</comments>
		<pubDate>Fri, 07 Jun 2013 15:17:23 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>
		<category><![CDATA[RETROPC]]></category>
		<category><![CDATA[X68000]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1033</guid>
		<description><![CDATA[一年前のメモから 2012年6月8日のことでした。6月8日はX68000の日らしく、twitterではX68000が好きな人達や、ライバル機種の人達が入り乱れて、各々が楽しく一日を過ごしていました。その様子は「2012年6月8日は「X68000」の日」にまとめられています。 うんうん、みんな楽しそうですネ・・・いやいや！P6er(※PC-6001ユーザのこと)としては、いくら格下の機種（PC-6001>越えられない壁>X68000という意味）とはいえ、ライバル機が活発に活動しているのを見過ごすわけにはいきませんから、ここは何か仕掛けねば！と一人勝手に思い立ちました。 とはいっても、当日に何かするには仕込み時間が無さ過ぎたので、1年後の2013年6月8日を目標日に定めました。変化の激しい時代になんと気の長い話。でもこの不安定なご時世（※2012年）に1年後のネタを考えるくらいの心のゆとりがあってもいいよね。 何をつくろか まず最初に思いついたネタが、X68000の代表的なソフトをPC-6001に移植することです。 え、何言ってんのコイツと思われそうな妄想ですが、PC-6001には「タイニー移植テクニック」があるのです。つまり、どんな大作であってもタイトル名に「タイニー」を付ければ誰もが納得してしまう、そんなテクニックです。 例えば「タイニーグラディウス」とか「タイニーファイナルファンタジー」とかなら、グラフィックが物足りなくても速度が遅くても、なんだか許せてしまう雰囲気になるのです。（※1） ※1 タイニーという言葉をどうとらえるかは人それぞれですが、私はPC-6001らしさを表すとても良い意味の単語だと思っています。ばかにする意図はないです。 X68000の名作がP6でも動いちゃってるモンネーというのは愉快そうです。X68000のゲームで有名なものとなると、ジェノサイドやファランクス、魔神宮でしょうか。「タイニー魔神宮」なんてキャッチーじゃん！BASICでいいし！と思うのですが、このネタのギリギリ感を理解出来る人がPC-6001陣営どころかX68000組にも少ない気がします、ザイン。 そんな感じで、何を移植しようかなーとネットでX68000のタイトルを調べながらツイッターのTL眺めていたところ、「侵略！」の文字が目に飛び込んできました。2012年頃まだアニメイカ娘ブームの余韻があったのですね。・・・そっか、X68000のソフトをPC-6001に持ってくるより、積極的に侵略的な攻めの姿勢として、PC-6001のタイトルをX68000に移植して侵略すればいいんじゃね？と発想をひっくり返したのです。 PC-6001の雰囲気をX68000に持ち込むというよくわかんない移植ですが、これなら作業的にも趣味プログラムの範疇で無理がなさそうです。 移植するタイトルは・・・うん、PC-6001の代表的なソフトといえばタイニーゼビウスです。元々はアーケードの移植作ですが、PC-6001らしくアレンジされてますし、ネームバリューもあります。 移植作のタイトルは68秒だけ悩んで「タイニーゼビウスPRO68K」に決めました。 移植をするにあたっては2つの大きな問題がありました。 まず、タイニーゼビウスの内部的な作りがよくわかっていないことです。雰囲気移植（目コピー）でも充分だとは思ったのですが、グラフィックデータを目コピーするのは面倒ですし、グラフィックデータの吸い出すついでにマップデータの解析もすることにしました。 次の問題が、X68000での開発です。X68000は20年ほど前に色々といじっていたので、漠然と『68000アセンブラをHASとHLKを使ってなんかするんだよ』程度の記憶はあるのですが、スプライトコントローラのレジスタなどの資料を集める必要が出てきました。今の時代に68000アセンブラを書くのもなんですが、普段、PC-6001のプログラムを書くために使っているZ80に比べたら、豊富なレジスタと命令の直交性に優れている68000アセンブラは天国なはずです。 とはいっても、データやプログラムのタスク管理はC言語を使った方が断然ラクですし、タイニーゼビウスを動かすくらいであれば実行速度はそれほど必要じゃないので、GCCの開発環境を整えました。速度やファイルサイズに不満があったらコンパイラで生成されたアセンブラソースを手動で最適化すればいいですし。 なんでも世の中には、クロス開発できるX68000をターゲットマシンにしたGCCがあるようです。すごく興味深いのですが、開発環境上の問題にあたるのは避けたかったので、今回は充分に枯れているHuman68K上で動くGCCを使いました。 ざっと開発環境を説明すると、X68000エミュレータ上で動いているHuman68KにGCC環境を構築して、WindowsのドライブをHuman68Kから見えるようにWINDRV.SYSを使ってマウントして、Windows上でソースを書いてエミュレータでコンパイルしています。 資料集めですが、X68000でC言語による開発といえば、C MagazineでX68000のGCC言語でゲームを作る連載記事があったことを思い出しました。たしか、その連載をまとめたような本が出ていたような気がしたので検索して「GCCによるX680x0ゲームプログラミング」という書籍にたどり着き、さっそくAmazonで注文しました。書籍代は1円で送料の方が高くなるというよくあるAmazonっぽい本の買い方です。 その他は、昔から持っていた「INSIDE X68000」と「プログラマーのためのX68000環境ハンドブック」、それと、「ぷにぐらまーずまにゅある」を参考にさせてもらいました。 開発環境を整えながら、タイニーゼビウスのグラフィックデータとマップデータの解析を進めたのですが、ここでいきなり誤算が発生しました。タイニーゼビウスのプログラム解析作業が楽しくなってしまったのです。マップデータの展開ルーチンを読むにはスクロール処理や画像データの転送処理なども理解しなければならなかったのですが、その延長で他の処理も読みたくなり、結果的に、逆アセンブルした全プログラムを読み終えてしまいました。 当初の目的から外れた副産物であるタイニーゼビウスの解析結果は、@Hashiさんが執筆されているPC-6001の同人誌、PC6000NOTE No.5に収録されています。タイニーゼビウスの処理内容や様々な疑問点への解答など、一通り網羅しています。 現時点では通販はされていませんが、定期的にコミケやゲームレジェンドなどのイベントでTinyProjectというサークルとして頒布されています。→2015年にWebで公開しました。タイニーゼビウス 完全解析＆解説 どう移植するか タイニーゼビウス解析した結果としては、X68000への完全移植は無茶な課題だなと思いました。一般論というか常識として、PC-6001とX68000の大雑把な意味でのスペック比較はPC-6001 >> 越えられない壁 >> X68000なのですが、まぁ、そのへんの事はひとまず脇に置いておくとして、完全移植が難しい理由の一つが、PC-6001のタイニーゼビウスは同期を取らずに全力で動作しているという点です。 同期というのはテレビの垂直同期とか音楽の再生時間などですが、そういったものに依存せずに背景のスクロールやキャラクタの移動処理を常に全力で行っています。ですので、表示するキャラクタの増減、つまり処理量によってゲームの進行速度や音の再生速度が微妙に変化しているのです。これを再現するにはZ80のクロック数やPC-6001の各種割り込みタイミングを考えないといけなくなるのですが、こうなるとX68000上で動作するPC-6001エミュレータを作った方が手っ取り早くなってきます。ただ、X68000にはそこまでのCPUパワーはありません。コードコンバートしてクロック数を数えながら調整して動かすという方法もありますが、その労力に見合わないネタ企画なので、雰囲気が似てれば細かいところはいいやと早々に割り切りました。 スプライトとBGを試す X68000の特徴の一つはスプライトです。家庭用向けのパソコンにスプライトを搭載しているというのは今からみても尖った仕様ですね。シャープやるね！ ゲーム機ではなく、16bitどころか32Bitといわれてもおかしくない高価なパソコンに搭載されているスプライト機能ですから、タイニーゼビウスのキャラクタならゴッソリとキャラ定義できる、と思っていたのですが・・・X68000のスプライトって定義できる数が足りない・・・なんてこと・・・。こんなんだっけ？ 特にBG面への割当数制限が厳しいです。タイニーゼビウスのキャラクタ数くらいなら余裕と思っていたのに。 これなら、スプライトを使わないでグラフィック面に全部描画してもいいんじゃないかなーと思いました。処理速度は間に合いそうですし。 でも、せっかくのX68000のゲームでスプライトを使わないのも残念すぎるので、キャラクタ管理をするということで。XSPとかのスプライトドライバを使うことも考えましたが、そこまでじゃないかなと思ったので、それなりに自前で管理します。 画面モードの話 タイニーゼビウスの画面モードは256&#215;192です。VRAM上のドット数は128&#215;96なのですが、表示する時に拡大されます。 X68000でスプライトが扱える画面モードは256&#215;256か512&#215;512で、PC-6001横方向の解像度を収めるには512&#215;512ということになるのですが、このモードだとドットが細かすぎるので、裏技的な384&#215;256モードに設定します。この辺のCRTC設定値とかはネット上の資料がほとんどなかったのですが、X68000programingというページに書かれていて助かりました。ありがたや。 CRTC周りの設定はアセンブラで記述して、ゲーム本体のC言語のプログラムとリンクしたかったのですが、えっと、C言語とアセンブラのコード呼び出しってどうやったっけ？というレベルから思い出しプログラミングです。最近では、アセンブラ混じりのC言語を使う機会はないのでしょうがないよね。 久々のC言語 マップなどのデータを外部ファイルに持ち、それらのファイルをメモリに読み込むのにfread()とかmalloc()といったCのライブラリを使う事には多少の抵抗がありました。というのも、昔、X68000のプログラムを書いていた頃はアセンブラを使っていて、DOS CALLかIOCS CALLが基本だったので、メモリや処理速度にオーバーヘッドのあるライブラリを使うのはやだなぁと。あと、当時はGCCのコンパイル速度が遅くて、X68000ではC言語自体が使いにくいなぁと。 今ではエミュレータのメモリを12M一杯まで載せて、MPU速度を無制限ぶんぶん回せばあっという間にコンパイルできちゃうのでラクラクです。 それにしても、平成が20年も過ぎるとさすがにC言語でmalloc()してメモリ確保なんていうプログラムを書く機会はほぼないので、懐かしさと自前でメモリ管理をする不安感とで不思議な感じがしました。 BG面を表示する X68000の仕様を確かめつつテストプログラムを書いて、背景の表示とスクロール処理ができました。 [...]]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1033/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>万引き少年ゲーム</title>
		<link>http://www.retropc.net/mm/archives/1012</link>
		<comments>http://www.retropc.net/mm/archives/1012#comments</comments>
		<pubDate>Mon, 27 May 2013 13:31:23 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>
		<category><![CDATA[RETROPC]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1012</guid>
		<description><![CDATA[万引き少年ゲームについて、わかっている範囲でとりまとめてみました。 万引き少年ゲームの歴史については、bmfanさんのページにある、マイコンBMFANマガジン Ver.1.0の記事中にまとまっています。また、ALL ABOUT マイコンBASIC Magazineさんのページにも掲載プログラムの一覧がありますので、これらから引用させていただくと&#8230; マイコンベーシックマガジン1983年10月号 「移植版万引少年ゲーム / HC-20」 はるみのゲーム・ライブラリー 「まんびき少年ゲーム / PC-6001」 マイコンベーシックマガジン1982年7月号 「移植版 万引き少年ゲーム / PC-6001」 ラジオの製作付録ベーシックマガジン82年1月掲載 「万引少年ゲーム / MZ-80K2/C/E」 雑誌RAM 1980年2月号掲載「万引少年 / PET2001」 という事になります。MZ版はRAM版を参考にして作成した事が記事中に書かれています。 雑誌掲載では、PET2001版の「万引少年」が最古なのですが、実は雑誌掲載よりも前に公の場で発表されています。 東大マイコンクラブ著, 集英社 / だからいまマイコンによると、1979年の東大駒場祭において、東大マイコンクラブが制作したゲームとして「万引少年」のタイトルで発表されたようです。「万引き少年」でも「万引き少年ゲーム」でもありません。翌年の駒場祭では「万引少女」というゲームが発表されたようです。こちらは音声合成でしゃべるゲームだったようですが、画面写真や動作機種などについての記述がないので、これ以上の事はわかりません。 だからいまマイコンに掲載されている写真では、PET2001ではなくCBM3032のようにも見えますが、写真が小さいのと、どのマイコンで万引少年が作られたのかは書かれていないので詳しいことは不明です。 1980年2月号のRAMにも同じような経緯が記事中に書かれていますので引用すると、 このゲームは、11月下旬に行われた東大駒場祭において、当ゲーム開発事業部企画「熱中時代・ゲーム編」に出品するために開発されたものです。 ～中略～ また、駒場祭が終り、このゲームを『RAM』編集部へ持っていくと、その題名のあまりな不埒さに編集部の人がかなりビビッタようです。でも、何とかOKが出たので、掲載の運びとなったのです ということですから、駒場祭が最初ということで間違いなさそうです。 記事中では、「あるメーカーから商品化される予定ですので、個人で楽しむ以外は一切の使用を禁止します」と書かれているのですが、実際に商品化されたかどうかはわかりません。 ちなみに記事のタイトルでは「万引少年」なのですが、RAM誌の表紙や目次では「PET2001 万引少年ゲーム」となっています。 開発元が東大マイコンクラブである事は、東大マイコンクラブのホームページ内のUTMC &#8211; 活動成果 &#8211; ソフトウェアにも書いてあります。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1012/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6001にYM2203を追加する記事</title>
		<link>http://www.retropc.net/mm/archives/946</link>
		<comments>http://www.retropc.net/mm/archives/946#comments</comments>
		<pubDate>Fri, 26 Apr 2013 12:40:01 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=946</guid>
		<description><![CDATA[I/Oの1985年9月号に、PC-6001用のFM音源カードの記事があります。 ROMカートリッジスロットに差し込むカード上にYM2203を2個も載せるというものです。 回路図を引用します。 アドレスデコードがシンプル！ 今となってはYM2203とYM3014を手配するのが難しいかな。矩形波音源でよければ秋月電子で取り扱っているYMZ294が安いので、2個といわずに4個ぐらいどーんと載せるのもありかもですね。発音タイミングがずれまくりそうですが。 ハードウェアはシンプルですが、この手のデバイスは音楽データがないと楽しめないので、曲データの作成の手間の方がかかりそうです。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/946/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PC-6001mkIIがテレビ地上波に登場</title>
		<link>http://www.retropc.net/mm/archives/868</link>
		<comments>http://www.retropc.net/mm/archives/868#comments</comments>
		<pubDate>Sat, 02 Mar 2013 07:35:36 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=868</guid>
		<description><![CDATA[NHKの番組 MAG・ネット 3月1日の放送では、ノベルゲーム特集の一環として、PC-6001mkIIとPC-8801mkIISRとX68000がテレビに登場しました。 番組の内容は、PC-8801mkIISRの実機＆本物のフロッピーディスクで「東京ナンパストリート」を遊ぶというもので楽しかったですヨ。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/868/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>映像信号を測る / PC-6001mkII RGB</title>
		<link>http://www.retropc.net/mm/archives/609</link>
		<comments>http://www.retropc.net/mm/archives/609#comments</comments>
		<pubDate>Sun, 01 Apr 2012 07:50:48 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[PC-6001]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=609</guid>
		<description><![CDATA[PC-6001mkII背面のデジタルRGB出力から水平・垂直同期信号を測定してみました。 PC-6001mkIIでは付属の取扱説明書にタイミングチャートが記載されているため、あえて測定する必要はないのですが、マニュアルと実測値が違うことはよくありますし、デジタルオシロで2チャンネル同時測定をしてみる題材として、あらかじめ数値がわかっている機材を使った方が都合がよいのです。 マニュアル掲載のタイミングチャートではこのようになっています。上図が水平方向の各種タイミングで、下図が垂直方向です。水平方向は64.696μs(15.457KHz)、垂直方向は16.688ms(59.922Hz)ということになっています。 タイミングチャートの水平方向の図では、水平同期信号がフロントポーチ・バックポーチで階段状に変化しているかのようにみえますが、実際には、TTLレベルで同期信号のパルスが負論理で発生するだけです。 垂直方向も同様で、TTLレベルで負論理でした。同期期間もマニュアル通りです。 水平同期信号と垂直同期信号を同時に測定したのがこちらです。2つの信号を重ね合わせると判りにくくなるので、垂直同期信号の電圧値を倍にして表示してあります。タイミングチャートによると、垂直同期信号の間に水平同期信号が262本あるはずです。 もうひとつ、垂直同期信号がActiveになった瞬間の拡大図です。垂直同期信号のパルス幅は水平映像信号3本分に該当していることがわかります。これもマニュアル通り。 これらの映像信号はmkIIのモードに関わらず一定です。PC-6001mkIIの垂直方向画素数はMODE1では192、MODE5では200ですが、垂直方向の走査線数は画素数に関係なく一定なので変化しません(Z80 BUSREQは別の話です）。RGB信号も併せて調べてモード別のディスプレイエリアを比較してみるとわかりやすかったかもしれませんね。 また、リセットボタンを押しっぱなしにしている時も同期信号は変化しませんでした。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/609/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
