ラベル Emulation の投稿を表示しています。 すべての投稿を表示
ラベル Emulation の投稿を表示しています。 すべての投稿を表示

2017年3月5日日曜日

SoundCortexについて

GitHubで公開している音源チッププロジェクトSoundCortexについて、Qiita等で公開されている情報のリンクを集めてみました。2017/03/05時点で投稿した内容とぐぐった結果のまとめになります。

公式

I2Cで制御できる80円のPSG互換チップで遊ぼう

PSG音源部について利用方法の説明とArduino、Rasberry Pi、PCからの具体的な利用例。

I2Cで制御できるSCC+互換チップ

SCC音源部について利用方法の説明、SCC+レジスタについての概要説明など。

80円PSGをWindowsから鳴らしてみる

Windowsから利用する具体的な方法を紹介。実際にlibkssにパッチを当ててKSSファイルをチップから再生する例を紹介しています。

ユーザによる記事

FreeBSD+mrubyでサウンドプログラミング

yamori813さんによる記事。FreeBSDと言っていますが、謎のボード上から鳴らしているようです。

LPC810とArduino UNOでSCC互換音源を鳴らす(1)

LPC810とArduino UNOでSCC互換音源を鳴らす(2)

ImpactDrillさんによるArduino UNOで利用する際の具体的な記事。Arduino用のライブラリも作成されているようですので、Arduinoから利用してみたいという方には助けになるかと思います。I2Cはプロトコルの性質上、エラーが起きたときにバスハングしやすいのが難点です。通信が不安定だという方は(2)で書かれているように電圧やコンデンサなど、回路的な面をチェックすると改善されるかもしれません。

PCNベトナムキックオフ、80円コンピューターで拡張するIchigoJam、レキシライブに市長登場

IchigoJamの福野 泰介さん、IchigoJamに繋げる実験をしたようです。オリジナルのSoundCortexはI2Cのデバッグで詰まった時にデバッガを使いたくてSWD経由で開発できるようポート配置を変更したのですが、福野さんはシリアルで開発しやすいようにポート配置を再変更したforkを公開されています。書き込み環境としてはシリアルを利用している人の方が多いと思いますので参考になるかと思います。本家でも配置をビルド時に指定できるようにした方が良いかも。
IchigoJamみたいな開発環境から使うのはターゲットとして一番面白いと思います。Arduinoではやや実用的な用途に届かないし、Rasberry Piだと自分でサウンド出力を持ってるので実はあまり嬉しくない。自作の電子工作に直接組み込めればそれが一番美味しいんですが、それはそれで敷居が高いですから。

チップの入手について

ImpactDrillさんが(1)の記事でも報告していますが、一部店舗でLPC810が大幅に値上げされています。卸しの段階でキャンペーン価格が終了した等の可能性があり、今後ほかの店舗でも在庫がなくなり次第値上げされる事も考えられます。現時点(2017/03/05)ではマルツパーツが75円を維持していてお勧めです。仮に安く入手できるお店がなくなってしまったら、別のチップでの対応を考えたいと思います。コアをアセンブリで書いているのでCortex M系で適当なのがあれば良いのですが。まぁ、大した規模でもないのでMIPSやAVRに移動するのも辞さない覚悟で。

2015年9月8日火曜日

Boot to CP/M

今更なんですけどね、UEFIを触ってみましたよ。
昔AVR用に作ったCP/MエミュレータをUEFI for x86_64向けに改造して、OS無しで直接CP/Mがbootできるようにしてみました。

Ubuntuだったら以下の手順でbuildできます。

% git clone https://github.com/toyoshim/cp-mega88.git
% cd cp-mega88
% sudo apt-get install gnu-efi
% make -f Makefile.uefi

でcpmega88.efiってファイルが出来るので、EFIのパーティションにEFI/Boot/bootx64.efiって名前でコピーするか、EFI Shellから起動するかでCP/Mが起動します。CP/M用のディスクイメージはEFI/cpmega88/sdcard.imgって名前で用意してください。githubのページで詳しく書いてますが、z80pack用のイメージがそのまま使えます。

QEMUが入ってれば以下の手順でも動作確認できます。

% make -f Makefile.uefi install
% qemu-system-x86_64 -bios OVMF.fd -hda fat:.


OVMF.fdはこの辺から入手できます。

USBメモリとかに入れておけば、UEFI対応のPCに挿して起動するだけでCP/Mが動作します。わー、嬉しい!

2015年1月16日金曜日

Apple IIのハイレゾグラフィック

Woz様の回路、電車でぼけーっと考えてたら理解できたので忘れないうちにメモ。

よくある説明がこれ。柴田さんのApple II本(ブログエントリの末尾参照)より引用。VRAMから1バイトデータを取り出した時、最上位ビットが色セット切り替え、残りの7ビットで7ピクセル分の色を表現。ビットが0なら黒だけど、1だった時にはピクセルの位置によって決まった2色のうちの1色が表示される。連続して表示すると混ざって白く見えます、的な。
実はこの説明は厳密じゃなくて色は0/1のデータで表現しているわけじゃなくて、隣り合うピクセルの0→1、1→0というビットの立ち上がりと立ち下がりに反応して発色される。0か1かというのは本質的ではない。連続するビットに関しても、紫緑の場合と緑紫の場合だと色の滲み方が変わるはず。

で、原理の説明。まず色副搬送波の周波数が3.58MHz、それに対してドット・クロックが2倍の7.16MHzになっているのがミソ。適当な場所で1ピクセルだけビットが立ってる場合を考えるとドット・クロック2倍という事で色副搬送波と半周期だけ同期するパタン①と、同じく半周期だけど位相が180度ずれて同期する(値が反転している)パタン②の2種類が起きうる。ドット・クロックは2倍だけど、フリップした時に出てくる周波数成分はきっかり3.58MHz。これがそのまま色副搬送波の位相のずれとしてデコーダに検出される。
2ピクセル連続でビットが立った場合はどうかというと③と④で微妙に違う現象が起きる。③の場合は最初のビットの立ち上がりで色副搬送波と位相が一致、立ち下がりで反転。という事で連続するピクセルの左端が0度に相当する色に滲み、右端は180度に相当する色で滲む。で中間部分については色が打ち消し合ってるわけではなく、単に3.58MHzの周波数成分がほぼ0になってるため、彩度が0と判定されて白が発色される(位相差が色相、振幅が彩度に相当)。④の場合は逆で左端に180度、右端に0度の滲みがでるはず。

で、さらにApple IIでは最上位ビットを使って2つの色パレットを切り替えられる。これは14.32MHzの入ったFFを通して90度遅らせた信号を作り、遅延なしの2つの信号と合わせてセレクタに入力、最上位ビットでどちらか一方を選ぶことで実現できる。遅延付きが選ばれた場合は90度と270度、遅延無しが選ばれた場合は0度と180度の色相が取り出せるという仕組み。実際にはここで説明した位相差に加えて45度程度のずれがあり、それによって橙(45度)、紫(135度)、青(225度)、緑(315度)の4色が発色されるようです。周辺回路の遅延差がそのまま見えちゃってる感じなのかな?

という事で、本来は4割くらいの出力でカラーバースト出した上で、なだらかな輝度変化に3.58MHzに変調した色情報を載せるというのが正しいわけですが、手抜き回路では全力でカラーバースト出してやって、白黒デジタルなパタパタ出力のタイミングをちょっと前後に振ってあげるだけで独特のデジタルカラーが再現できるっぽい。これって実はマイコンでApple IIのビデオ回路を再現するのも夢じゃないって事ですね。14.32MHz-14bitのSPIが使えれば簡単に実現できる。VRAM1画面4KBって事を考えるとLPC1114あたりが適任。ビデオ専任のサブブロセッサとして任せてVRAM読み書きはメインプロセッサからI2C経由で。もしかしたらMegaZ-80Kで文字表示してたのよりタイミング的に楽かも。


2015年1月9日金曜日

Getting ARM OABI environment after such a long time :-/

Background

Unfortunately, I need to use very very old ARM OABI Linux environment to salvage data from XFS used by broken NAS. XFS is designed to be compatible between platforms, but for some reasons, it was incompatible only with ARM OABI environment. As you may know, OABI used a curious middle endian and struct layout. It's a very old story around Linux kernel 2.6.1x, or so. But, it affects my HDL-GT1.0 actually. Linux box can not show any file entries even if the disk can be mounted, and xfs_repair has no power to solve the problem.
FYI, the first KURO BOX that was sold in Japan also used ARM OABI, but later versions used ARM EABI, AFAIK.

Basic Strategy

Install debian 4.0 (etch) onto QEMU. Etch was already out of maintenance, but this is the best choice since HDL-GT1.0 looks using the Linux that was based on it. Also there is enough information to install it onto QEMU, e.g. this site (*1). Debian 5.0 (lenny) provided two versions, OABI and EABI for ARM, but the next 6.0 (squeeze) had only EABI. Anyway these all were out of maintenance. There were no benefit to choose others.

How to Install

I used Ubuntu 14.04.1 with QEMU that is installed by "apt-get install qemu". Basically, I just followed the way described at (*1). But some tricks were needed since the information was already out of date, and meanwhile, etch was removed from the official place.

Boot files

Two mandatory files distributed at (*1) were also removed. I found them from web.archive.org. I can download them, but it seems that the server sometimes return 404 against them. Anyway, if you were lucky enough, you will be able to get them.
 Also, etch's initrd.gz was fetched from archive.debian.org/. The first initrd.img-2.6.18-6-versatile was used after installation, and the second initrd.gz was used on installation.

Use a manually chosen mirror site

Since etch was removed from the original place, I should specify an archive site manually. Mirror site name was archive.debian.org, and the path was default, /debian/. Here are some screen shots.
If you chosen one of default mirror sites, the installer will ask you to pick up a version of debian distributions from recent two or three choices that must use EABI.

Other Notices

In the page (*1),  that picture for the question "Continue without installing a kernel?" looks like the answer should be "<No>". But "<Yes>" is the right answer here.
Also, there is a critical issue to me. The provided kernel did not enable xfs support. So, even I install xfsprogs package and so on, xfs can not be mounted. According to the article, I can build kernel by myself. So, I'll try it next.
FYI, xfs_repair seems not working fine, but anyway it does not crash. Here, QEMU is launched with additional flags "-hdb HDL-GT-md13.img" here.
# apt-get install xfsdump  # it will install dependent xfs related packages including xfsprogs
# xfs_repair /dev/sdb  # it works somehow?

Kernel build

Let's build a kernel to support XFS. The system contains minimum set of packages. So, we need following packages to build the kernel at least. There are two choices, 2.6.18 and 2.6.24, but choose 2.6.18 that the original installation bases on.
# apt-get install make gcc linux-source-2.6.18 kernel-package build-essential libncurses5-dev initrd-tools
Then, prepare source files.
# cd /usr/src
# tar jxf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18
Kernel 2.6.18 has a config template file for versatile. Here, we use it as a baseline, then enable XFS support in addition.
# make versatile_defconfig
# make menuconfig
In the menu, enable a following items. I'm not sure if this is the exactly necessary and sufficient condition. But at least, it is sufficient:)
  • Bus support ---> PCI support [built-in]
  • Device drivers ---> SCSI device support ---> SCSI device support [module]
  • Device drivers ---> SCSI device support ---> SCSI disk support [module]
  • Device drivers ---> SCSI device support ---> SCSI tape support [module]
  • Device drivers ---> SCSI device support ---> SCSI generic support [module]
  • Device drivers ---> SCSI device support ---> SCSI low-level drivers ---> SYM53C8XX Version 2 SCSI support [module]
  • File systems ---> Ext3 journalling file system support [module]
  • File systems ---> XFS filesystem support [module]
  • File systems ---> XFS Quota support [built-in]
  • File systems ---> XFS Security Level support [built-in]
  • File systems ---> XFS POSIX ACL support [built-in]
  • File systems ---> XFS Realtime subvolume support [built-in]
  • File systems ---> Filesystems in Userspace support [module]
  • File systems ---> Pseudo filesystems ---> Virtual memory file system support (former shm fs) [built-in]
  • File systems ---> Pseudo filesystems ---> Tmpfs POSIX Access Control Lists [built-in]
  • File systems ---> Pseudo filesystems ---> Userspace-driven configuration filesystem (EXPERIMENTAL) [module]
  • File systems ---> Native language support --> Japanese charsets (Shift-JIS, EUC-JP) [module]
  • File systems ---> Native language support ---> NLS UTF-8 [module]
then save and exit the menuconfig. Let's build the kernel.
# make dep
# make modules && make zImage && make modules_install && make install
# mkinitrd -o /boot/initrd-2.6.18.img 2.6.18
Now dependent modules should be installed into the internal file system, and kernel and initrd images that can be specified on launching QEMU are created. The kernel image should be placed at arch/arm/boot/zImage, and initrd image is /boot/initrd-2.6.18.img as you specified at the last command. I copied them to the host machine via scp. After shutting down the emulated ARM system, launch the system again with these new images, as
# qemu-system-arm -M versatilepb -kernel zImage -initrd initrd-2.6.18.img -hda hda.img -hdb want-to-read-fs-in-xfs.img -append "root=/dev/sda1"
The resolution of the boot console is finer than the original, and linux logo is not used. But anyway, it boots. Once you login the system, it will support XFS correctly, and it is exactly the XFS that is not compatible with current XFS. In my case, I launched QEMU with "-hdb HDL-GT-md13.img", then it can mount the image correctly.
# mount /dev/sdb /mnt
# ls -l /mnt
drwxr-xr-x 6 root  root  88 May 16  2012 share
drwxr-xr-x 6 root  root  88 May 16  2012 spool
Yep!

Lennyは新しすぎた

Etchでkernelの設定を変えて色々試してる間にLennyのイメージを見つけたので試してみた。XFSがデフォルトでオンになってたので期待したんだけど、互換性問題が修正された後のバージョンのようだ=Etch/OABI XFSは読めなかった、という残念な日記。

https://web.archive.org/web/20130605075901/http://people.debian.org/~aurel32/qemu/arm/

web.archive.orgにLennyのARM OABIイメージが残ってた。README.txt通りに起動すればXFSが有効になったカーネルで起動できるので、-hdbでイメージを渡せば普通にマウント可能。ただ、xfs_repairとかインストールされてないので、ちょっと作業が必要。

ちなみに運が良ければ、
# mount /dev/sdb /mnt
# ls -l /mnt
でメタ情報含めて正しく見えれば勝利。駄目だったらツール使ってfile systemの修復。まずは、このままだとaptが使えないので、/etc/apt/sources.listを編集。
deb http://archive.debian.org/debian/ lenny main
を追加すればOK。
# apt-get update
# apt-get install xfsprogs
あとは程度次第だとは思うんだけど、
# xfs_repair /dev/sdb
これで駄目なら
# xfs_repair -L /dev/sdb
あたりをマウント解除した状態で実施。で、僕の場合は最初から最後まで治らず。例のページにあったように shareというディレクトリ名は出てくるけど、メタデータが壊れて見えてる状況。xfs_repairはエラーなしで綺麗に終わったんだけど。

HDL-GTはEtchらしいのでバージョン揃えて試す作業を継続してみる。こっちは配布されてたイメージでXFSがONになってないので、kernelとinitrd.imgを作り直して見てるんだけど、boot中にpanicが出て、少しずつ修正しながらもうちょいでinitが走り出しそうなとこまで来たとこ。QEMU内でのkernel buildに時間かかってTATが……。

追記:HDL-GTのkernelは2.6.12.6ベースで予想通りOABIを使用、XFSまわりのkernel configは以下の通り。
CONFIG_XFS_FS=y
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y

2014年12月13日土曜日

ARMの上で動くリンゴ印のOSで究極のLチカを楽しむ

ARMは仕事で初めてゲームを作ったコンシューマ機、ゲームボーイアドバンスのCPUという事で、とても思い入れのあるCPUです。ゆんゆんに「ちょっと手伝ってー」と言われて立ち寄ったのが今や泣く子も黙る神移植のM2さん。タイトルはデ・ジ・キャラット。楽曲は憧れの並木学さん。そしてサウンドプログラムを手がけていたのがX68k界でブイブイ言わせてた齊藤彰良さん。当時はお二方ともM2移籍前。僕もワクワクしながら仕事をしていました(最近は大きな仕事に慣れすぎてワクワク感が麻痺してしまってるかも……)。
そんな思い入れのあるARMですが、今やモバイルを中心とした組み込み世界の覇者。AndroidやiPhone向けの高性能プロセッサであると同時に、ホビー向けには個人でも100円程度で手に入るモデルが沢山あります。そこで、せっかくだから久々に何か遊べないかなー……という事で考えたのが……

120円ARMの上でリンゴ印のアイツを動かす!


そう、あれです、あれ。Apple II。
秋月で手に入るLPC1114の性能を見ていてピンと来ませんか?
  • ARM Cortex-M0
  • 50MHz(最大)
  • Flash: 32KB
  • RAM: 4KB
このギリギリ感!ちなみに以前からマイコンだけで古のマシンを再現する企画を続けており
  • CP/Mega88 ... CP/M Z-80 on ATMEGA88 (20MHz, Flash: 8KB, RAM: 1KB) + 外付けSRAM 64K
  • MegaZ-80K ... MZ-80K on ATMEGA644 (20MHz, Flash: 64KB, RAM: 4KB) + ATMEGA328 (20MHz, Flash: 32KB, RAM: 2KB) + TINY2313(20MHz, Flash: 2K, RAM: 128B)
に続く第三弾です。ソースはgithubに置いてありますが全てアセンブリで書かれています。毎回何かしら無駄な挑戦をしているわけですが、今回の見どころは
  1. I/O 4KB、ROM 12KB、RAM 48KBをFlash 32KB、RAM 4KBだけでごまかす
  2. ビデオ出力とキーボード入力をUARTのTX/RXに変換する
  3. 空いてるI/OにGPIOを割り当てて、Apple BASICからLチカ
の3点。

1は単純なローテクで実現。ROMはFlash側に埋め込み、VRAMについては一切記憶しない事でメモリ節約(次節でも説明)。ゼロページやスタック、Apple BASICが本気で使う空間にはRAMをまじめに割り当て、それ以外の領域に関しては全部同じ1-Byteを共有するようにしてあります。主記憶のないキャッシュみたいなもんで、書いて読んで比較……という単純なメモリチェックに対しては正しく動くけど、本当にワークとして触りだしたら動きません。まぁ、初期化コードを騙して、小さいプログラムを動かすには十分。

2は気合。UART入力をキーボードに変えるのは比較的簡単ですが、出力をUARTに変換するのはちょっと大変です。VRAMへの書き込みを見はりつつ、前に書いたアドレスからの差分でカーソル移動を行います。書き込み内容はTXに送るだけでVRAMの実体は実装しません。読まれたら固定値0xFFを返すだけ。スクロール時の画面書き換えは書き込みパタンから自動判別します。読んで1段上のラインに書き込んで……という処理を繰り返すのでアドレスパタンからも判別できるし、本来使われることのない"読み出し値0xFF由来の値"の書き込みを検知する事でも判断できます。スクロール処理中は再描画の書き込みを無視し、スクロール終了を検出したらしれっと改行を送って通常モードに戻ります。

3は特に難しいことはなく。拡張スロット用のI/O空間が開いているので、そこへのアクセスをGPIOにつなげてみました。Apple BASICからはPEEK/POKEで気軽に全メモリ空間へアクセスできるので、これだけでBASICからGPIO制御が可能になります。

という事で簡単なデモ。YouTubeの編集機能使って音とか説明つけてみた。携帯片手に左手でぽちぽち入力した映像なんですが、フラフラしてた画面も手ぶれ補正であっさり安定。



という事で、次はこのプロジェクトを始めた真の目的、佐藤一憲さんにもらったWIZnetを繋げて遊ぶ、というステップに進もうかと。宿題間に合いそうで良かった、良かった。

2011年9月23日金曜日

Memo to build official android emulator

This is a memo to build official android emulator which Android SDK includes. This emulator forked from qemu.

Get source codes
$ cd $WORK
$ git clone git://codeaurora.org/platform/external/qemu.git
Build
$ cd $WORK/qemu
$ git checkout origin/aosp/tools_r13
$ ./android-configure.sh
$ make
Prepare OS images
$ cd $WORK
$ wget http://dl.google.com/android/android-sdk_r13-linux_x86.tgz
$ tar zxf android-sdk_r13-linux_x86.tgz
$ cd android-sdk-linux_x86/
$ ./tools/android
(Install SDK platform packages, then create virtual machine definition named X in GUI. Android 1.6, 2.3.3, and 3.2 will work fine.)
Launch the OS image
$ ANDROID_SDK_ROOT=$WORK/android-sdk-linux_x86 $WORK/qemu/objs/emulator-arm @X
(X is the name you named in preparing OS images.)
Memos

  • codeaurora.org is an unofficial mirror repository. If kernel.org come back, you must use the git://android.kernel.org repository.
  • If you'd like to build on OS X, you must build in a case-sensitive file system because block.h conflicts with system provided Block.h. Default file system is case-*in*sensitive, so you may prepare a disk image and work in it as follows;
    • $ hdiutil create $NAME -size 1024m -fs HFSX -volume $VOLUME; hdiutil attach $NAME; cd /Volumes/$VOLUME; do something...
  • If you'd like to build trunk sources, you may want to use prebuilt SDL library in /platform/prebuilt.git. It could be passed via --sdl-config arguments in android-configure.sh. But I guess it miss three functions including SDL_WM_GetPos, etc. Also it will be a pretty tough and boring work to find some stable combinations between versions of SDL, qemu, and OS images.

2011年9月19日月曜日

CPU Emulation using JIT on JavaScript

I'm struck with an idea to implement CPU emulation using JIT like technique on JavaScript. Basically, the emulator generates JavaScript function which emulate a target binary sequence by the basic block, then cache it in hash. The code could be like 'cache[pc] = eval(jit()); cache[pc]();'.

Since I'd like to know how this technique could be effective, I just make a tiny pseudo emulator and estimate its performance. The result show the JavaScript CPU interpretor will be x100 slower than a native code. Modern JavaScript engines become faster and faster. But it seems to be still slow. On the other hand, qemu-arm seems to be quite fast. It's just several times slower than the native one. So how about my emulation using JIT on JavaScript? It's slower than qemu. But not so bad. It might be pretty fast than native CPU interpreter.

As supplements, I must say that this benchmark treats just one simple case and the result will be changed by loop size, count, and JIT overheads in various situations.

2010年5月9日日曜日

オリゲー・フェスタ68

通称オリフェスに参加してきました。
自分のサークル名義じゃないけど、久々のイベント参加。


イモプロ名義で以下の物を展示してました。

  • MegaZ-80K(最初の写真では画面左端より外側w)

AVRをふんだんに使って再現したMZ-80K互換機。MEGA644でZ80エミュレーション。UARTベースで共有バスを張って、その上でI/O通してました。今回は足がいっぱいあったので、SRAMとはアドレス15bit、データ8bitを外部ラッチ無しで直に繋いでます。配線は圧倒的に楽ができた(笑。








画像表示はMEGA328が専任。ひたすらUARTモジュールを駆使してNTSC信号を作りまくるお仕事。I/Oからのアクセスにすぐに応答する余裕がないため、間にFIFOとしてのTINY2313がいます。
I/OバスとしてはシリアルでTINY2313がデータを掴み、HSYNCを待ってパラレルでMEGA328に流し込む感じです。

写真はMac上のGtkで書いてたプロトタイプに、シリアルで画面表示モジュールにデータを流し込むコードを追加し、エミュレーションで書いた画面と実際のビデオ出力を比較しているところ。











あとはサウンドもTINY2313が担当。こっちは割り込みでレジスタをパタパタさせて鳴らしております。

で、最後はなぜかファミコンコントローラ。色々とツッコミもありましたが(笑。キーボードどうしようかな、PS/2にしようかな、USBにしようかな・・・と考えていたらPS/2の端子が部品箱にない事に気づきました。USBならいっぱいあるけど、ホストは作ったことはないし・・・。という事で、手っ取り早く済ませよう、とファミコンを投入。やっぱりTINY2313を使っていて、キーボードに対するI/Oアクセスが来たらコントローラのステータスを読み出し、適当にスキャンコードにマップして応答を返しています。


  • CP/Mega88(左端、iBook)

再びCP/Mega88。こっちもインベーダー動かしたりして展示してました。
ライセンスはどうなってるの?って人もいましたが、今は開放されてます。


  • USB-PSG/SID(中央、MacBook)

USB接続のPSG音源とCommodore64のSID音源。Linux用のドライバしか書いてないので、デモはUbuntu上で行いました。fMSXのPSGアクセス部に手を入れてドライバのI/Oを叩くようにしています。Ys-IIのサウンドモードを動かしていました。
同じような事をやってます、って話をしてくれた人が何人かいましたが、Windowsでやってる人はドライバ部分で苦労してるみたいです。Linuxはその辺がお手軽だったので、独自クラスで適当なbulk転送のプロトコル決めて、ちゃちゃっと処理しちゃってます。
/sys/bus/usb/drivers/usb_psg/ 以下にデバイスファイルが出来て、そこ経由でレジスタ読み書きしたり、レジスタダンプ表示させたり。
USB部分はPIC18F2550ですね。今回唯一のPIC成分。PICだとUSBフレームワークがついててファーム開発もらくらく・・・というわけではなく、実は自分、商用コンパイラ使うのが許せなかったので、sdcc向けにスクラッチでUSBのファームを書きました。当時は自前でUSB周りを叩いたファームって見かけなかったけど、今だとどうなんだろう。シリアルからデバッグメッセージ吐きながら開発してましたが、うかつにメッセージ吐くとUSBのプロトコル側でタイムアウトが発生してしまうので、結構大変だった記憶があります。

2010年4月27日火曜日

エレキジャック・フォーラム

というわけで、発表させていただきました。

発表資料のほうは、カーネル/VM探検隊で見たsexy hookの
プレゼンに触発されて、Preziで作ってみました。


オンラインでの参照はこちらから。

デモをしようと思ってたんだけど、ディスプレイ出力端子が
USB端子とぶつかってしまい断念。
この日にあわせて新マシンを調達したのが裏目に出たか(うひ

そのうち基板作ったら一式公開〜とか考えてたんですが、
興味もってくれた人がいたので、近いうちに一度公開しようと思います。