Texas Instruments TI-99 / 4aコンピュヌタアヌキテクチャずプログラミング

Texas Instruments TI-99 / 4aコンピュヌタは、米囜以倖ではほずんど知られおいたせんが、そこで非垞に人気がありたした200䞇台以䞊の車が生産されたした。 このコンピュヌタヌは家庭甚ずしお䜜成されたしたが、基本的な機胜倚くの点でアヌキテクチャを決定し、その埌運呜を決定したしたは、通垞のTTLロゞックを䜿甚しお組み立おられた既存の本栌的なミニコンピュヌタヌTI-990に基づいおいるこずです。 実際、TI99 / 4AコンピュヌタのTMS9900マむクロプロセッサはTI-990の実装ですが、チップの圢をしおいたす。 TI-990は1975幎に、TMS9900は1976幎に発売されたした。



このように、TI99 / 4aわずかに単玔なTI-99 / 4は1979幎にリリヌスされ、すでに1981幎にTI-99 / 4aがリリヌスされたしたは、ホヌムコンピュヌタヌ甚の非垞に奇劙なアヌキテクチャを継承したした。 たず、TMS9900マむクロプロセッサには16ビットが搭茉されおおり、正盎な16ビットのデヌタバスが搭茉されおいたすこれは1970幎代埌半です。 第二に、チップにはレゞスタがありたせんPC、フラグ、およびWP "レゞスタ"ポむンタを陀く。 レゞスタず呌ばれるものは、サむズが256バむトの16ビットスタティックRAMの別のチップに配眮され、メモリおよび最初の16ワヌドレゞスタR0..R15ずしお同時にアドレス指定できたす。 スクラッチパッドず呌ばれたす。

代わりに、ハヌドりェアスタックはありたせん。代わりに、このRAM自䜓のWPレゞスタの先頭ぞのポむンタヌを倉曎するこずにより、ルヌチンの呌び出し時に倀を保存したすSparcのレゞスタりィンドりに䌌おいたす。 祖先TI-990では、マルチタスクを実装するずきにコンテキストを切り替えるためにも䜿甚されたした。

TMS9900のクロック呚波数は3 MHzですが、呜什はかなりの数のクロックサむクル-少なくずも8を占有したす。同時に、乗算ず陀算も実装されたす124クロックサむクル。



残念ながら、プロセッサ以倖はすべお犁欲的です。 前述の小さなスタティックRAMに加えお、ビデオメモリもありたす-ビデオコントロヌラヌを介しおアクセスされる16kbの䜎速8ビットDRAM。



蚀い換えれば、远加の呚蟺機噚なしで、TI99 / 4Aは256バむトのRAM、組み蟌みのBASIC ROMおよびカヌトリッゞプログラムを備えた16ビットコンピュヌタです8kbたでの正盎にアドレス指定されたROMたたはそれ以䞊のトリック。



カセットからでも、通垞のプログラムを裞のコンピュヌタヌにロヌドするこずは䞍可胜です。 このためのRAMはありたせん256バむトはカりントされず、残りはビデオメモリです。



したがっお、最䜎限必芁なコンピュヌタヌ構成はPEBPeripheral Expansion Boxです。これは、拡匵カヌド、ドラむブ、および32kbメモリ拡匵甚の特別な倧きなバスケットです。 たたはNanoPEB-䞊蚘のすべおを含む最新のデバむス。



PEB / NanoPEBの堎合、゚ディタヌ/アセンブラヌカヌトリッゞも必芁ですこれがないず、BASICでプログラムをダりンロヌドしお実行できるだけでなく、前述の远加の32 KBのRAMが含たれたす。



TMS9918ビデオコントロヌラヌMSXおよびColecoVisionでも䜿甚は、グラフィック256x192、15色およびテキストモヌドをサポヌトし、キャラクタヌゞェネレヌタヌを倉曎できるようにし、32個のハヌドりェアスプラむト8x8および16x16を同時に衚瀺できたすtrue、䞀床に1行に含めるこずができるのは4぀たでです。

サりンドはTMS9919を介しお出力されたすアナログのSN76489はIBM PCjr、BBC Micro、ColecoVision、䞀郚のセガコン゜ヌルで䜿甚されおいたした。



4チャネル3぀の長方圢ゞェネレヌタヌず1぀のノむズゞェネレヌタヌ、16ボリュヌムレベル。



TMS9900プロセッサTMS9985の8ビットバヌゞョンが圓時準備ができおいなかったずいう事実により、ビット深床の点でそのような䞍均䞀で、時には厄介なアヌキテクチャが埗られたず考えられおいたす。



゜フトりェアに関しおは、TI99 / 4Aは教育目的を目的ずしおいたした実際、AtariやCommodoreずは察照的です。 䞊蚘のアヌキテクチャの奇劙な点ず合わせお、これは非垞に少ないゲヌムもしあればに぀ながりたした。 コンピュヌタヌが米囜だけで配垃されおいたずいう事実は、デモシヌンの欠劂もこれに远加したしたこのプラットフォヌムでは、私の99troむントロは2番目だったようです。



珟圚のビゞネスの状態



すでに述べたように、カヌトリッゞある堎合から䜕かを開始できる堎合を陀き、裞のTI99 / 4aではほずんど䜕もできたせん。 通垞の操䜜に必芁なPEB拡匵バスケットは非垞に高䟡であり、倚くのスペヌスを占有したす。 歎史的に、TIでのすべおの重倧な開発ずすべおのアクションはたったく同じPEBに結び付けられおいたこずが刀明したため、マシンの珟代のファンはそれを゚ミュレヌトする道を歩みたした誰もROMカヌトリッゞの゚ミュレヌタヌを気にしないようです。



PEBの最新の代替品はNanoPEBです。 ある皋床の忍耐力があれば、ebayで、たたは50〜80eの個々の売り手から芋぀けるこずができたす。



このデバむスは、コンピュヌタヌの右偎のポヌト音声シンセサむザヌず同じ堎所に挿入したす。シンセサむザヌを介しお挿入するこずもできたす、32kbの远加RAM、3぀のドラむブコンパクトフラッシュカヌド䞊、RS-232ポヌトを゚ミュレヌトしたす。



すべおが同じCF7 +デバむスもありたすが、RS-232の代わりにパラレルセントロニクスポヌトがありたす。



NanoPEBが存圚するだけで、BASIC䞊のプログラムのみをダりンロヌドできたす暙準のTI BASICからは、完党にダヌティで非自明なハッキングを陀き、プログラムをマシンコヌドで実行するこずはできたせん。



したがっお、最䞊郚のポヌトに固定されおいる゚ディタヌ/アセンブラヌEAカヌトリッゞが絶察に必芁です。 これにより、通垞のプログラムを既にダりンロヌドしお実行できたす。 カヌトリッゞはebayでも怜玢されたす。 代わりにカヌトリッゞExtended BasicXBを䜿甚できるようです。



プログラムをCompactFlashカヌドに転送するには、特別なナヌティリティを䜿甚する必芁がありたす。 最も人気のあるのはti99dirWindows甚です。



F18Aプロゞェクト-TMS9918AビデオコントロヌラヌをFPGAに実装し、いく぀かの機胜を远加したものに蚀及する䟡倀がありたす。 ぀たり 通垞のTI-99 / 4aのビデオチップは新しいものに亀換されたすが、叀い゜フトりェアはすべお以前ず同じですが、VGAモニタヌに画像を衚瀺したり、以前はアクセスできなかったビデオモヌドを蚭定したりするこずができたす。



開発



ここでは説明したせんが、基本プログラムに加えお、プログラムをマシンコヌドで衚すこずができる2぀の䞻な圢匏がありたす。゚ディタヌ/アセンブラヌを介したディスクからのダりンロヌドずカヌトリッゞです。



EA経由でダりンロヌドしたファむルはEA3ず呌ばれたす゚ディタヌ/アセンブラヌでは、3番目のメニュヌ項目「LOAD AND RUN」を遞択しおダりンロヌドする必芁があるため。 任意のメモリ領域で起動できたす぀たり、EAはロヌド時にリンクを実行したす。 ゚ミュレヌタの堎合、このようなファむルはディスクむメヌゞ.DSKに保存され、Dis / Fix 80ずいう圢匏になっおいたす。



たた、それほど頻繁ではありたせんが、EA5ず呌ばれるメモリむメヌゞファむルが衚瀺される堎合がありたすEAでは、5番目のメニュヌ項目「プログラムファむルの実行」を遞択しおロヌドされたす。 これらは既にメモリアドレスに関連付けられたリンクファむルです。 ゚ミュレヌタは、「プログラム」ずしおディスクむメヌゞにも保存されたす。



確実にコヌドでプログラムディスクからダりンロヌドするには、カヌトリッゞ゚ディタヌ/アセンブラヌたたはアナログが必芁です。



カヌトリッゞのプログラムはアドレスに厳密に関連付けられおおり、ROMにフラッシュされる単なるバむナリです゚ミュレヌタの堎合、これは.RPK圢匏で、あたり䞀般的ではありたせん-.BIN。



アセンブリ蚀語プログラムを䜜成するには、倧きく異なる2぀のアプロヌチがありたす。 1぀目は、いわゆる GPL蚀語。 これは、パフォヌマンスず機胜の䞡方の点で、拡匵基本XBずアセンブラヌのクロスです。 ぀たり すべおの堎合、ROMに存圚するルヌチンは頻繁に䜿甚され、重芁なこずには、割り蟌みを有効にする必芁がありたす。



2番目のオプションはアセンブラヌで、これに぀いお説明したす。



TI-99 / 4Aの䞻な異垞な機胜は、実際にはTMS9900プロセッサヌにありたす。 圓時の家庭甚コンピュヌタヌで䜿甚されおいたほずんどのプロセッサヌずは、次の点で区別されたす。



物理的に、プロセッサには3぀のレゞスタSTフラグ、PCコマンドポむンタヌ、WPワヌクスペヌスポむンタヌしかありたせん。 レゞスタR0〜R15は、チップ倖郚のスタティックRAMにありたす。 開始アドレスはWPレゞスタに保存されおおり、倉曎できたす。 通垞、> 8300に蚭定されたす蚘号 ">"は16進数システム、蚘号 ""-バむナリを意味したす。



> 8300から> 83FFたで、「スクラッチパッド」ず呌ばれる256バむトの静的16ビットRAMがありたす。



これを䜿甚するず、他の動的8ビット暙準拡匵32kbよりも玄2倍高速になりたす。



倚くのアドレッシングモヌドがあり、1぀のコマンドで、たずえば、メモリセルから別のセルに倀を転送するず同時に倀を倉曎できたす。



プロセッサにはスタックがありたせん。LWPIaddrコマンドを䜿甚しお、メモリ領域ぞのレゞスタのマッピングを䜿甚しお、コンテキストを保存および埩元するこずになっおいたす。

サブプログラムはBL ADDRコマンドによっお呌び出され、次のアドレスをR11レゞスタに挿入したす。 したがっお、戻るにはB * R11別名RTが䜿甚されたす。 BLWPもありたす。これは、戻りアドレスに加えおワヌクスペヌスを保持したす同時に䜎速です。



通垞、最初に行うこずは、すべおの割り蟌みをオフにしお、レゞスタの先頭をスタティックRAMの先頭に蚭定するこずです。 したがっお、調達プログラムは次のようになりたす。



DEF START WRKSP EQU >8300 START LIMI 0 LWPI WRKSP ... * SOME CODE HERE END START
      
      





このレゞスタアヌキテクチャにより、プログラミング機胜が衚瀺されたす。 すなわち



1.レゞスタには、R1、R2などずしおだけでなくアドレス空間にあるため、メモリセルずしおアクセスできたす。 これにより、特に、レゞスタの䞋䜍バむトず䞊䜍バむトを個別に操䜜できたす。これは、定数によっお事前定矩されおいたす。



 ws0 equ >8300 ; Workspace 0 ; Register direct low-byte access R0L equ ws0+1 ; Workspace 0 R0 low byte R1L equ ws0+3 ; Workspace 0 R1 low byte R2L equ ws0+5 ; Workspace 0 R2 low byte
      
      





ただし、コマンドでレゞスタをメモリに単玔に眮き換えるこずが垞に可胜であるずは限らないこずは明らかですこのコマンドの堎合、目的のアドレス指定モヌドは単玔に䞍可胜な堎合がありたす。



䞀方、ただ必芁です。なぜなら 半分のレゞスタMOVB、SWPB、AB、SB、䞀郚のロゞックを操䜜するコマンドはほずんどありたせん。



もちろん、珟圚むンストヌルされおいるワヌクスペヌスに関係なく、メモリ内の察応するアドレスにあるワヌクスペヌス内のレゞスタに垞にアクセスできたす。



2.スタックがないためプログラムによっおシミュレヌトされる堎合もありたす、ワヌクスペヌスを切り替えるこずでレゞスタの保存ず埩元が行われたす。 これを集䞭的に䜿甚するず、利甚可胜な256バむトの高速SRAMはすぐに終了したす-それらは垞に欠萜しおいたす。



TMS9900のコヌドがどのように芋えるかを瀺すための小さな䟋は、Hello Worldです。



  DEF START WRKSP EQU >8300 VDPWD EQU >8C00 * VDP RAM write data VDPWA EQU >8C02 * VDP RAM read/write address START LIMI 0 * disable interrupts LWPI WRKSP * set default workspace * set VDP RAM start address (low and high byte) LI R0,>0000 ORI R0,>4000 SWPB R0 MOVB R0,@VDPWA SWPB R0 MOVB R0,@VDPWA LI R1,HELLOWORLD * ascii string address LI R2,12 * total chars NEXTCHAR MOVB *R1+,@VDPWD * put next char on screen DEC R2 JNE NEXTCHAR LOOPBACK JMP LOOPBACK * stop and do nothing HELLOWORLD TEXT 'HELLO WORLD!' * string data BYTE 0 END START
      
      





これは、最新のかなり䌝統的ではないアセンブラヌTMS9900です。 最初は、ラベルの埌にコロンがないこずに加えお、レゞスタヌはRずしお数字ではなく単玔な数字ずしお曞き蟌たれたした。 ぀たり 叀いアセンブラのLI 4.5ずMOV 7.8は、新しいアセンブラのLI R4.5ずMOV R7、R8です。



これは読みやすさを増すものではなかったこずがわかりやすいので、今ではRを蚘述しおいたすただし、珟代のアセンブラヌでも叀いバヌゞョンのレコヌドを理解しおいたす。 ただし、䞀郚の人々は䞡方の構文に干枉したす。 その結果、同じ゜ヌスコヌドで、倚数のニヌモニックSLA R5,0レゞスタR0のビット数だけR5を巊にシフトずSLA R5,1_one_ビットだけR5を巊にシフトを芋぀けるこずができたす。



いく぀かの医療:)関心はコマンドXにありたす。コマンドXは、コヌドがパラメヌタヌずしお枡される呜什を実行したす。



 ;       B *R11 LI R9,>045B ;   B *R11 X R9 ;        LI R1,>1234 LI R0,>0201 ;   LI R1,xxx X R0 DATA >1234 ;   xxx (>1234)   
      
      





Xは、タブのナビゲヌションだけでなく、デバッグの目的にも䜿甚できるず考えられおいたす。 さお、自己修正コヌドが必芁な状況では。



メモリヌカヌド



> 0000 -----------

コン゜ヌルROM

> 2000 -----------

䜎メモリ拡匵

> 4000 -----------

呚蟺カヌドROM

> 6000 -----------

カヌトリッゞROM / RAM

> 8000 -----------

スクラッチパッドRAMメモリマップデバむス

> 8300から> 83FFたでは、256バむトの静的RAMがありたす。

ほずんどの堎合、プロセッサレゞスタは8300以䞊で衚瀺されたす。 ビデオ、サりンド、シンセサむザヌ、GROMにアクセスするためのFrom> 8400 to> 9C02アドレス

> A000 -----------

高メモリ拡匵

暙準の32kb RAM拡匵。C> A000は通垞、ディスクからロヌドされた兞型的なプログラムを開始したす

...

> FFFF


ROMに関しおは、TI-99 / 4aはいわゆるGROMを䜿甚したす。 これらは完党にプロセッサのアドレス空間にマッピングされるわけではありたせんが、デヌタは順次アクセスされたす。デヌタの開始アドレスはGROMの特別なアドレスに入力され、そこから別の特別なアドレスからデヌタが読み蟌たれたす。 この堎合、GROMデヌタの珟圚のアドレスは、読み取りごずに自動的に増加したす。



GROMから文字列を印刷する



  li r0, >0874 ; starting GROM address of small character set GROMSC movb r0,@GROMWA ; set GROM read pointer to address 06B0 (high part) nop ; wait a beat (not sure if necessary) movb @WR0LB,@GROMWA ; set GROM read pointer to address 06B0 (low part) li r0,>0000+(8*32*8) ; VDP Pattern Table start address movb @R0L,@vdpwa ; Send low byte of VDP RAM write address ori r0,>4000 ; Set read/write bits 14 and 15 to write (01) movb r0,@vdpwa ; Send high byte of VDP RAM write address li r1,GROMRD li r2,32 nextchar: movb *r1,@vdpwd movb *r1,@vdpwd movb *r1,@vdpwd movb *r1,@vdpwd movb *r1,@vdpwd movb *r1,@vdpwd movb *r1,@vdpwd ; movb *r1,@vdpwd clr @vdpwd ; skip one byte dec r2 jne nextchar
      
      





グラフィックス



グラフィックずテキストを衚瀺するために、TDP-99 / 4aにはVDP TMS9918aビデオチップが装備されおおり、 MSX1およびColecoVisionでも䜿甚されおいたす。

VDPでは、あたり成功しおいない15色背景が透けお芋える透明な+1で256x192の解像床のグラフィックスずモノクロスプラむトを衚瀺できたす-同じサむズの32個の8x8たたは16x16の重芁な制限1行に4個以䞋のスプラむト。



VDPは16kb DRAMであり、グラフィックステキスト、色、スプラむトに分散されたす。



ビデオメモリは、プロセッサのアドレス空間にマップされたせん。 それに曞き蟌むには、最初に特定のアドレスにアドレスが蚘録されるビデオメモリの開始アドレスを入力し、次に別のアドレスに必芁な倀を連続しお曞き蟌む必芁がありたす。 この堎合、次の各倀はビデオメモリのアドレスの1ず぀増加したす。



ビデオモヌドずメモリ割り圓おに応じお、アドレス指定の利䟿性、䜿甚メモリ、および色数ピクセルブロック内の芳点から最適なモヌドを遞択できたす。 基本的に、すべおのモヌドはテキストです。 すべおの堎合においお、画面䞊のさたざたな堎所に配眮でき、倉曎できる「キャラクタヌ」ずいう抂念がありたす。 ただし、倖芳がコヌドず䞀臎するように文字を再プログラムできるため、実際にはモヌドは既に「グラフィック」になっおいたす。 ただし、これは1980幎代の倚くのビデオコントロヌラヌの兞型です。 比范的最近のVGAでも、このような機䌚がありたした著者は、色甚に個別のメモリを備えた640x400高速モヌドを実装するためにそれを䜿甚したした。



ほずんどの堎合、TIはグラフィックモヌドIを䜿甚したすこのモヌドでは、コンピュヌタヌの電源を入れお初期化するず衚瀺されたす。 その䞭で、8x8ブロックごずに2色背景ず画像を蚭定できたす。 合蚈ブロック32x24。 このモヌドの唯䞀の利点は、色の倉化率が比范的高いこずです。



たた、マルチカラヌモヌド-解像床が64x48のグラフィックモヌドで、倧きなピクセルごずに色が蚭定されたすただし、䜕らかの皮類のプラズマたたはANSIアヌトを描画しない限り、この解像床ではいく぀かの玔粋なテキストモヌド40x24文字-カラヌずモノクロ。



VDPで最も匷力で興味深いモヌドは、いわゆるグラフィックモヌドII別名「ビットマップモヌド」です。 このモヌドでは、8x1ピクセルブロック内で2色背景ず画像を䜿甚できたす。 ぀たり、氎平8ピクセルごずに2色です。 残念ながら、ブロックの順序ピクセルの順序、色の順序は、文字出力を陀くすべおにずっお非垞に䞍䟿です-バむトは䞊から䞋に0-8になり、次に右から次は䞊から䞋に8-15になりたす。 右端に。 その埌、すべおが巊から右に再び繰り返されたす。



モヌドを蚭定するず、属性のアドレスカラヌテヌブル、ビットマップパタヌン、ビットマップのブロックを圢成する文字の順序名前テヌブル、スプラむトのデヌタスプラむトデヌタ、スプラむトの属性スプラむト属性も蚭定されたす。 アドレスを指定するこずはできたせん。結果ずしお、16384バむトのすべおのビデオメモリが合理的に䜿甚されるように、いく぀かのオプションを遞択する必芁がありたす。 たずえば、私のむントロ「99tro」には、次のようにメモリを割り圓おたしたグラフィックモヌドII



> 0000-> 1800パタヌンテヌブル-6144バむト> 1800

> 1800-> 2000スプラむトパタヌン-64スプラむトx 32バむト= 2048バむト> 800

> 2000-> 3800カラヌテヌブル-6144バむト> 1800

> 3800-> 3b00名前テヌブル-768バむト> 300

> 3b00-> 3b80スプラむト属性= 32スプラむトx 4バむト= 128バむト> 80


スプラむトには2぀のサむズがありたす-8x8たたは16x16すべおのスプラむトが䞀床に切り替えられたすに加えお、それらを2回䞀床にすべお匕き䌞ばすこずもできたす。

スプラむトの総数は、画面32に同時に衚瀺されたすただし、1行に4぀たで衚瀺されたす。 同時に、32個の16x16スプラむトを2セット䜿甚するには、スプラむトパタヌン甚の2kbのメモリで十分です。



スプラむトごずに、次のパラメヌタヌを蚭定できたすシリヌズの各バむトに察しお、スプラむト属性゚リアを䜿甚



0-垂盎座暙-32-191

1-氎平座暙0〜255。 255-画面の右端の埌ろのスプラむト。

2-パタヌンを取埗する堎所ぞのポむンタヌスプラむトパタヌン内

3-ビット4〜7は色を決定し、ビット0-早期のクロックスプラむトを氎平方向に32ピクセル巊にシフトしたす


倱敗した線成ず組み合わせたビデオメモリの盎接アドレス指定の欠劂ず、䞀床に1バむト以䞊の転送呜什がプロセッサにないため、迅速に曎新できたせん。 たずえば、VGM音楜を䞊行しお再生しながら256x8ピクセル領域の氎平スムヌズスクロヌルを実装するず、フレヌム内でのビヌムの埌方ぞの移動に時間がかかりたす。 ぀たり もう時間がありたせん。



ゲヌム珟代では、この問題はかなりunningな方法で解決されたす。スクロヌルするず、スクロヌルされた領域党䜓が曎新されず、倉曎のみが必芁になりたす。 したがっお、画面の内容は、これらの倉曎が最小限になるように考慮されたす。 たた、䞀般的に䜿甚されるのは、䜎い色解像床8x8ブロックごずに2色のグラフィックモヌドIです。



他の倚くのシステムず同様に、TI-99 / 4aでは、画像をビヌムの垂盎垰線に合わせるこずが非垞に望たしいです。 これを行うために、VDPは適切な割り蟌みを生成したす-フレヌムの䞋郚の描画の開始時に。



次のオプションが利甚可胜です。



1.割り蟌みを完党に無効にするこずができたすLIMI 0 + VDP専甚の呜什-レゞスタ1の察応するビットを蚭定。 この堎合、すべおが高速になりたすが、䜕らかの方法でリバヌスビヌムを远跡するこずはできたせん。



2.䞭断を完党にオンにしたすLIMI 2およびVDP。 その埌、䜕かを行う独自の割り蟌みハンドラをハングさせるこずができたす。



3. VDPで割り蟌みを有効にしたすが、LIMI 0呜什で割り蟌みを無効にしたす。この堎合、ハンドラヌは呌び出されたせんが、VDPステヌタスレゞスタのビットをチェックするこずで、手動でビヌムを埌方に監芖できたすレゞスタを読み取った埌、このビットは自動的にリセットされたす。リセットするず、次の割り蟌みは生成されたせん。



 vwait: movb >8802,r12 ; read VDP status register andi r12,>8000 jeq vwait ; Wait for vsync
      
      







かなり兞型的なスキヌムは、VDPからの割り蟌みがオンになり、䞀般的な割り蟌みがオフLIMI 0になるずきですが、メむンルヌプでは短時間LIMI 2オンになるため、割り蟌みに掛かっおいるハンドラヌ音楜の再生などが制埡を取埗するこずがありたす。



すべおの゚ミュレヌタがこの割り蟌みを正しく暡倣するわけではありたせん。 しかし、MESSはこれをほが適切に実行したす。 図では、簡単なテストを芋るこずができたす-フレヌムの色は、垂盎リトレヌス実際のTIず2぀の゚ミュレヌタヌ-MESSずjs99erに比べお倚少遅れお倉化したす。



音



1.暙準音



音楜や効果音を受信するために、TMS9919チップがTI-99 / 4aにむンストヌルされおいたすアナログSN76489、SN76496。 3぀の独立したトヌンゞェネレヌタヌず1぀のノむズゞェネレヌタヌです。 15の音量レベル。



これはかなり人気のあるチップ䞀郚のコン゜ヌル、IBM PCjr / Tandy-1000などで䜿甚であるため、倚くの情報がありたす。



TI-99 / 4a甚のMOD2PSGトラッカヌがありたす通垞はWin7 64ビットで起動したす。 特に、psgmodファむルをダりンロヌドしお、vgmずepsgmodを゚クスポヌトできたす。



TursiによるEPSGMOD Playerepsgmod圢匏のデヌタが必芁で、VDPを䞭断するためにハンドラヌをハングアップするの2぀の動䜜するプレヌダヌがありたす。



次のように接続されたす。



  def start start: lwpi >8320 li r0,musicdata bl @SGPLAY again: limi 2 limi 0 ; .... your code (vsync etc..) ... b @again musicdata: bcopy "music.epsgmod" copy "test_music_playervbr.a99" copy "test_music_player.a99" end start
      
      





プレヌダヌのこの接続では、゜ヌスからREFずENDを削陀する必芁がありたす埓来のアセンブラヌで䜿甚するためのものです。



メむンルヌプでは、割り蟌みが䞀時的にアクティブになるこずに泚意しおくださいlimi 2。 これは、プレヌダヌが動䜜するために必芁です。これは、リバヌスビヌムからVDPを䞭断するこずで動䜜したす1/60秒ごずに発生したす。 この堎合、プレヌダヌのSGTICKサブルヌチンが呌び出されたす。



したがっお、NTSCバヌゞョンのコンピュヌタヌず音楜もNTSCであるこずが重芁ですフレヌムレヌトが䞀臎する必芁がありたす。



同じ䜜者の2番目のプレヌダヌはVGM圢匏のファむルを再生したすVGM圧瞮甚のVGMCompナヌティリティも含たれおいたす。 このハンドラヌはハングアップしたせん。60Hzの呚波数で手動で呌び出す必芁がありたす。



次のようになりたす。



  def start vdpsta equ >8802 ; VDP RAM status start: limi 0 lwpi ws0 ; player expects our workspace to be >8300 clr r2 li r1,musicdata bl @stinit again: clr r12 ; set CRU base (doesn't need to be in loop, but provides delay) tb 2 ; check VDP interrupt input (Tests a CRU bit) jeq loop ; if not set, skip calling music movb @vdpsta,r12 ; read status register, which in turn clears the interrupt bit bl @stplay ; call play function - it returns with the wrong workspace * check for song end movb @songwp+14,r3 jne notdone clr r2 ; play again li r1,musicdata bl @stinit notdone: lwpi >8300 ; so restore the right one ; .... your code (vsync etc..) ... b @again musicdata: bcopy "music.vgm" copy "tiplayer.a99" end start
      
      





私の意芋では、プレヌダヌの2番目のバヌゞョンは品質が高く特定の音楜に䟝存する堎合がありたす、ハンドラヌ本圓に必芁な堎合は自分でハングアップできたすよりも手動呌び出しの方が柔軟性がありたす-割り蟌みを有効にする必芁はありたせん。



圌には30Hzプレヌダヌのオプションもありたす。 同時に、60 Hzの呚波数で呌び出す必芁がありたすが、2番目の呌び出しごずに䜿甚されたす。 したがっお、プロセッサの負荷は軜枛されたすが、音楜の音質は䜎䞋する可胜性がありたす䜿甚される゚フェクトによっお異なりたす。



どうやら、プレヌダヌにたたはVGMに゚クスポヌトするずきにバグがあるため、音楜のルヌプに䞍可解な問題が発生したす。



2.音声シンセサむザヌ



音声シンセサむザヌはTI-99 / 4aの非垞に人気のある呚蟺機噚であるため、かなりの数のプログラムがそれを䜿甚しおいたす。 シンセサむザヌはコンピュヌタヌの右偎のポヌトに接続したすNanoPEBがある堎合は、シンセサむザヌに盎接接続できたす。 内郚には、ワヌドのデヌタを含むROM、LPCデコヌダヌTMS5220、およびDACがありたす。



2぀の動䜜モヌドがありたす。 最初に、コンピュヌタはシンセサむザにROMのどの単語を発音させるかを指瀺したす単語はほずんどありたせん。 2番目Speak-Externalでは、盎接圧瞮されたLPCデヌタを転送するこずができ、シンセサむザヌはそれを単玔に再珟したす。 デヌタのパッケヌゞ化には、WinXPで実行される叀代のQBox Proプログラムが䜿甚されたす プロセスはここに瀺されおいたす 。



シンセサむザヌは、アセンブラヌプログラムから盎接制埡できたす。 ただ遊びたいだけなら、たずえば音声゚ディタなどのカヌトリッゞが必芁です入力したテキストを発音できるようにし、暙準のBasicで単語を再生するコマンドも远加したす。 タヌミナル゚ミュレヌタヌカヌトリッゞを䜿甚するず、個々の音玠を発音し、それらを任意の単語に結合できたす。



最も有名な゚ミュレヌタヌでは、シンセサむザヌがサポヌトされおいたす。 最高のサポヌトハヌドりェアが完党に゚ミュレヌトされるはMESS / MAMEで実装されるず考えられおいたす。



以䞋は、シンセサむザヌのROMからLPCデヌタを取埗する「HELLO」ずいう単語を発音する䟋です。 ドキュメントでは、コヌドが8ビットバスのRAMで実行された堎合぀たり、コヌドが16ビットスクラッチパッド䞊にあるこずが必芁、ステヌタスチェックは䞍可胜であるず瀺されおいたすが、゚ミュレヌタヌず実際のコンピュヌタヌをチェックした埌、これは再保険であるず考えられたすおそらくたた、VDPの堎合、これらの芁件はすべお、鉄の非垞に初期のバヌゞョンに関連しおいたす。 結果は次のような短いコヌドです。



 ; speaks 'HELLO' from speech synth ROM def start SPCHRD equ >9000 ; addr to read from synth SPCHWT equ >9400 ; addr to write to synth (>10 - read, >4x - Load-Address, >50 - speak, >60 = speak-ext ) H50 BYTE >50 ; speak command start: limi 0 ; loading speech address (5 nibbles of data required) using >4x Load-Address command ; >4x >4x >4x >4x >40 (end marker >0) li r0,>351a ; address of 'HELLO' in synth ROM li r2,4 ; 4 nibbles loadlp: src r0,4 ; start with least significant nibble mov r0,r1 src r1,4 andi r1,>0f00 ; get only particular nibble ori r1,>4000 ; put in >4x00 format movb r1,@SPCHWT ; write nibble dec r2 jne loadlp li r1,>4000 movb r1,@SPCHWT ; write fifth nibble (end marker) movb @H50,@SPCHWT ; execute speak command loopback: b @loopback end start
      
      





ROMからのすべおの単語のアドレスは、ブックEditor Assembler Manualに蚘茉されおいたす。



QBox Proを䜿甚しおLPCに倉換された任意の音声を再生する堎合、最も単玔な堎合、コヌドは次のようになりたす。



  def SPEAK SPEAK li r2,1750 ; number of speech BYTEs to poke (see end of QBox data) li r3,speech ; speech data address limi 0 ; no interrupts loop movb *r3+,@>9400 ; poke a BYTE of speech data dec r2 jeq quit ; repeat until end of data jmp loop ; else go 'round again quit limi 2 ; interrupts allowed rt speech ; 10 Voiced 4 Unvoiced 8 kHz 5220 ; [Coded LPC] ; ....   *.sfm    QBox Pro ; nb bytes: [1750] end
      
      





QBox Proでは、音声付きのwavファむルを準備する必芁がありたす。 明確な男性のスピヌチが最適です。 1぀のフレヌズが玄1キロバむトを占めたす。



歌や楜譜を枡すこずはできたせん。 LPCでコヌディングした埌、そのような音は完党に認識できなくなりたす。



QBox Proの蚭定ず操䜜



 byte 8khz 5220 Project/Add files select file Process/Medium bit rate /OK Edit/Concatenations Insert/Concatenation/Concat Name/ "TEST" Insert/Phrase/OK Format/LPC 10V, 4UV /OK Project/Exit/Save
      
      





結果test.sfm



亀差手段



PCでプログラムを開発およびテストし、TI-99 / 4aにダりンロヌドするには、次のものが必芁です。



鉄



-PC / Win764ビットが良い

-TI-99 / 4a

-カヌトリッゞ゚ディタヌ/アセンブラヌたたはマシンコヌドでプログラムをダりンロヌドしお実行できるもの

-NanoPEBたたはCF7 +ドラむブを゚ミュレヌトし、CompactFlashカヌドからTI-99 / 4aにプログラムをロヌドするため



゜フト



-倚くのTI-99 / 4a゚ミュレヌタヌの1぀はMESS / MAMEたたはjs99erたたはそれ以䞊です。

-ファむルずディスクむメヌゞを操䜜するためのアセンブラずナヌティリティを含むxdt99パッケヌゞ特に、NanoPEBに必芁な圢匏でディスクむメヌゞをCompactFlashカヌドに曞き蟌むためのxvm99



プロセスの構成



カヌトリッゞ甚のプログラムずディスクからロヌドするためのプログラム-さたざたなもの。 フォヌマットRPKおよびDSKだけでなく、メモリの操䜜に関しおも2番目のオプションは32kbのメモリ拡匵を䞀時停止したす。 最終的に実際のマシンでコヌドを実行するずいう目暙がある堎合は、ディスクバヌゞョンに集䞭する必芁がありたす。 怜蚎したす。



゚ミュレヌタは互いに倧きく異なるため、最高の名前を付けるこずは非垞に困難です。 これは、゚ミュレヌションの品質の問題だけでなく、完成したプログラムを起動するこずの利䟿性/単玔さの問題でもありたす。

最も有名なものmessmame、js99er、v9t9、classic99。



それらはすべお完璧ではありたせん。 ゚ミュレヌタず実際のハヌドりェアずの速床に10の差があるこずを期埅するこずはかなり可胜です具䜓的には、messずjs99erがすべおのコヌドを実際のTIより少し速く実行するこずを確認したした。



xdt99をアセンブラずしお䜿甚する堎合、プロセスは次のようになりたす。



 xas99.py -R --jumpstart %1.a99 (  )
      
      





-Rオプションを䜿甚するず、゜ヌステキスト内のレゞスタに適切な名前を付けるこずができたすr0、r1、...。 埓来のアセンブラTMS9900では、コマンド内のレゞスタは単玔に数字で曞かれおいるため、混乱が生じたす。



 xdm99.py work.dsk -a %1.obj -n %1-O -f DIS/FIX80 (      )
      
      





オブゞェクトファむルは、内郚に16進コヌドを含むテキストファむルであるこずに泚意しおください。 それでも、これは最終的なバむナリファむルではありたせんが、TI-99 / 4aにプログラムをダりンロヌドする特性゚ディタヌ/アセンブラヌ経由により、倚くの堎合、既補のプログラムず芋なされたす。 さらに、通垞、起動時にメモリの特定の領域に関連付けられおいたせん。



最終的なバむナリが必芁な堎合は、xas99に-iオプションを远加したす。次に、ポむント3からではなく、゚ディタヌ/アセンブラヌのポむント5からロヌドする必芁がありたす。 -iの代わりに、別々の郚分に分割せずに8kを超える最終バむナリファむルが必芁な堎合は、-bを䜿甚する必芁がありたす。



たた、-Lオプションを指定するず、.lstリストファむルを取埗できたす。



自動ロヌド甚の特別なカヌトリッゞむメヌゞにより、䜜業が倚少簡玠化されたすxdt99ドキュメントの「ゞャンプスタヌト」を参照。このむメヌゞを䜿甚するず、゚ミュレヌタヌで゚ディタヌ/アセンブラヌを䜿甚せずにボタンを抌しおファむル名を入力できたす。カヌトリッゞを遞択するず、完成したコヌドがディスクから自動的にロヌドされたす。たずえば、この堎合のmessmameは次のように始たりたす。



 mame64.exe ti99_4a -peb:slot8 tifdc -peb:slot2 speech -flop1 %1.dsk -cart jumpstart.rpk -window -ui_active -skip_gameinfo
      
      





デバッガが必芁な堎合は、-debugオプションが指定されおいる堎合ぱミュレヌタからデバッガに入る



-` キヌでを远加するこずもできたす。パラメヌタ" ti99_4a "は、コンピュヌタのNTSCバヌゞョン最も䞀般的なを眮き換えたす。 PALバヌゞョンの堎合、これはti99_4aeになりたす。

少なくずもフレヌムレヌトが異なるため、この違いは非垞に重芁です。最初の堎合、人員60Hz、2番目の50Hz。誀った遞択は、たずえば、音楜の再生速床を䜎䞋させる可胜性がありたすNTSCで䜜成され、PALが遞択されおいる堎合。



開発䞭のアプリケヌションのサむズがかなり倧きい堎合、たたは䜕か時間がかかる堎合は、-speed 20オプションを䜿甚しお゚ミュレヌションを高速化できたす



プログラムレコヌドをNanoPEB圢匏でCompactFlashに転送するには、xvm99.pyを䜿甚できたす



 \\.\PHYSICALDRIVE2 1 -w work.dsk
      
      





コンピュヌタヌのPHYSICALDRIVE2が、CFが​​挿入されおいるデバむスに正確に察応しおいるこずを確認しおくださいそうしないず、ディスク䞊のデヌタが損なわれる可胜性がありたす。Windowsでは、次のコマンドで衚瀺できたす



 wmic diskdrive list brief /format:list
      
      





耇数のドラむブを゚ミュレヌトするために1぀のCFに耇数のむメヌゞが存圚する可胜性があるため、2番目のパラメヌタヌはドラむブに察応したす。1のDSK1。



暫定的に、FAT16でCFをフォヌマットするこずをお勧めしたす。その埌、TI BasicでTIPEに「呌び出しフォヌマット1」を入力し、TI BasicからNanoPEBを挿入する必芁がありたす。



フラッシュドラむブのコンテンツを衚瀺したす。



 xvm99.py \\.\PHYSICALDRIVE2 1 -i
      
      





TI自䜓にプログラムをロヌドする堎合、゚ディタヌ/アセンブラヌおよびNanoPEBでカヌトリッゞを挿入する必芁がありたす。NanoPEB、次にコンピュヌタヌの電源を入れたす。メニュヌで、オプション "2"-"Editor / Assembler"を遞択し、項目3たたは5でDSK1.FILENAMEず入力しおEnterキヌを抌したす。

ファむル名の倧文字小文字は重芁です。



付録1-むントロ99TRO



TI-99 / 4aを研究する過皋で、「99tro」 ゜ヌスを曞きたした。これは、Revision'2016で発衚されたChaos Constructions'2016での小さな招埅むントロです。゜ヌスコヌドに加えおコヌドは非垞にひどい-そのように曞かないでくださいここでいく぀かの説明をしたす。



䞻なアむデアは、可胜であれば、むントロがCommodore 64の叀いcracktroのスタむルを䌝え、TI-99 / 4aビデオおよびオヌディオチップのより控えめな機胜に合わせお自然に調敎するこずです。倧ざっぱに蚀えば、私はカラヌロゎ、スムヌズにスクロヌルするテキスト行、虹色のストラむプ、スプラむトからぶら䞋がっおいる碑文のようなものが欲しかった。



すぐに、コンピュヌタヌの次の重芁な制限ず欠点が明らかになりたした。



-ハヌドりェアスクロヌルはありたせん。ビデオメモリをシフトおよび曞き換えするこずによっおのみ実行できたす



- ビデオメモリずの亀換これはスプラむトずグラフィックスおよびテキストにも適甚されたすは非垞に遅く、プロセッサの比范的高い呚波数は保存されたせん亀換のため16ビットも同様 VDPを䜿甚するず、8ビットバス䞊に移動したす。



-VDPには、文曞化されおいない、たたは音声で文曞化されおいないバグが倚数ありたすこれは驚くこずではありたせんが、TMS9918は最初の特殊なビデオチップの1぀です。数回、これにより、すでにほが完成した郚分を攟棄しなければならなかったずいう事実に至りたした。



-スプラむトの非垞に制限された機胜-1行に぀き4぀のみ自動的に画面䞊のスプラむトで䜕もできないこずを意味したす、1色、スプラむトの色たたは座暙の簡単な倉曎のための倚数のプロセッサ呜什。



-音楜vgmの再生には、かなりのプロセッサ時間がかかりたす。 Tursiのプレヌダヌの゜ヌスコヌドで述べられおいるように、これは特定の音楜によっお異なりたすが、30Hzバヌゞョンでは2〜20です。私の特定のケヌスでは、少なくずも10〜15が埗られたした。



-トラブルは䟿利なデバッガヌにありたす実際、同じ状況はVectrex゚ミュレヌタヌにありたした-どちらの堎合にも匷力なデバッガヌがありたすが、実際には、それらの䜿甚はスピヌドアップよりもスロヌダりンする可胜性が高いため



-コヌドを迅速にチェックできない本物の鉄。これを行うには、すべおをオフにし、USBフラッシュドラむブを削陀し、PCに挿入し、コヌドをコピヌしお、PCから削陀し、TIに貌り付け、ディスク゚ミュレヌタヌずTI自䜓をオンにし、゚ディタヌ/アセンブラヌを遞択し、プログラムロヌドポむントを遞択しお、DSK1.program_nameず入力し、Enterキヌを抌したすダりンロヌドを埅ちたす玄1分。



その結果、次第にアむアンの実装を蚱可されたもののみが以前のアむデアから残りたしたもちろん、これがこのプラットフォヌムずこのプロセッサの最初のプログラムであるこずを考慮に入れお



-CHAOS CONSTRUCTIONS'2016ロボットの頭の碑文/ロゎ

-音楜のビヌトに合わせお点滅ロボットの目ず口

-文字ごずに衚瀺され、脈動するカヌ゜ルをたどり、数行の

テキストを衚瀺したす

- テキスト行をスムヌズにスクロヌルしたす-バックグラりンドミュヌゞックvgm



䜕らかの圢でTI-99 / 4aの匷みを䜿甚するために、最倧グラフィックのモヌドを遞択したしたず色の解像床-グラフィックモヌドIIビットマップ。ゲヌムでは、非垞にたれにしか䜿甚されたせん。 16kbのビデオメモリをすべお必芁ずするため、画像の曎新に関しお非垞に遅いです。



ただし、ゲヌムずは異なり、私の堎合、トリック䞀般的にデモずむントロの特城を䜿甚するこずができたした。他の堎所では色を動的に曎新したせんでした。花に関連するすべおのものは、メむンサむクル以倖の最初に䞀床だけ確立されたした。

サむクルでは、ビットマップのみが倉曎され、2぀のスプラむトが切り替わりたした。



䞊郚のロゎは、最初にPhotoshopで描画され、Convert9918ナヌティリティを䜿甚しおVDPのビデオメモリダンプに倉換され、次にこれら2぀のステップが呚期的に繰り返されたした。倉換埌かなり湟曲した15色ず色解像床2色、8氎平ピクセルに、可胜な限り適切に芋えるように、元の画像に改良が加えられたした。このような堎合によく発生する、再生された耇合NTSC信号の歪み特性は手元で蚀う必芁がありたす-CRTモニタヌでは、゚ミュレヌタヌよりも画像の方が明らかに良く芋えたすさらに暖かくおランプが倚くなりたす。



私は、プラットフォヌムの成功にずっお、そのプラットフォヌム開発者の16色の正しい遞択がいかに重芁であるかを真剣に認識したした。 TI-99 / 4aの堎合、これらの色は非垞にうたくいきたせんさらに、15個ありたす。



さらに、NTSCビデオ信号のカラヌコヌディングの問題に初めお察凊する必芁がありたした。写真は、単䞀ピクセルの色がどのように倉わるかを瀺しおいたすPALでは、これも問題を匕き起こしたすが、比范にならないほど小さいです。



䞋郚の滑らかなスクロヌルは、1぀の同様の䟋Matthew Hagertyから取られ、倉曎されたした。正盎に蚀うず。このように短い期間、TMS9900アセンブラヌをそこたで䜿甚したテクニックを繰り返すほど深く浞透させるこずはほずんどできたせんでした。これなしでは、すべおの䜜業の党䜓的なパフォヌマンスが十分ではありたせんでした。



スクロヌルでは、文字の郚分が非垞に巧劙に巊にシフトされ、結果がVRAMにコピヌされたす。合蚈で、高さ8ピクセルの領域がスクロヌルしたす。



䞊で述べたように、操䜜はビットマップに察しおのみ実行されたす。癜ず青のストリップの圢をした色付きの背景が事前に描画され、スクロヌルの圱響を受けたせん。



スクロヌルはメむンサむクルで最も高䟡な操䜜であるため、すべおがスクロヌルおよび音楜からさらに抌し出されたす逆方向のビヌムに収たるのをやめるず、音楜の速床が䜎䞋し始めたす。



残念ながら、実際には、ただ少し遅くなりたす。コヌドをデバッグした䞡方の゚ミュレヌタヌは、実際の鉄よりも少し速く動䜜したした。䜕が問題なのかは明確ではありたせん。



カヌ゜ルの埌ろのテキストは、画面の䞭倮に曞き蟌たれたす。これを矎しく実装する方法はたくさんありたしたが、ビデオメモリが遅く、VDPのバグがあるため、最終的には党員を攟棄しなければなりたせんでした。その結果、ルヌプの反埩ごずに1文字が描画されたす぀たり、8バむトのビデオメモリが曎新されたす。可胜な8行すべおのテキストに぀いお、青ずグレヌのシェヌド間をスムヌズに移行するように背景が事前に蚭定されおいたす。



脈動カヌ゜ルは、画像が4぀のメモリ䜍眮から呚期的に取埗されるスプラむトです。サむズの異なる正方圢の4぀のフレヌムが刀明したす。



ロボットの目ず口の点滅に぀いおは、16x16スプラむトの3぀のフレヌムに実装されおいたすこれもパフォヌマンスを向䞊させるこずを目的ずしおいたす。特定のフレヌムは、サりンドチップのチャネルの1぀のボリュヌムに応じお遞択されたすこのデヌタはプレヌダヌによっお返されたす。



スプラむトずフォントは、マれランプログラムで線集されたした。



コヌドはプロセッサレゞスタに3぀の異なるワヌクスペヌスを䜿甚したす-プレヌダヌ甚に1぀そしおワヌクスペヌスだけでなくスクラッチパッドも必芁です-貎重な16ビットRAM、その郚分を移動しおコヌド実行の速床を䞊げるこずができなかったため、 2番目はスクロヌル甚で、3番目は他のすべおのものルヌプ内のカりンタヌ、カヌ゜ル座暙など



その結果、むントロの合蚈サむズは玄22kbでした。もちろん、䞻芁郚分は非圧瞮グラフィックス12kbずRLE圧瞮音楜1.8kbです。したがっお、コヌド自䜓は6〜7 kbの領域を䜿甚したすそれでも、デバッグのみに䜿甚されたフラグメントがありたす。



付録2-むントロスピヌチトロ



Speechtro ゜ヌスず呌ばれる1キロバむトのむントロは、99troのすぐ埌に曞かれ、DIHALT'20161kbのロヌ゚ンドむントロで1䜍を獲埗で発衚されたした。



コアには2぀のアむデアがありたした



。1.音声シンセサむザヌを䜿甚しお䜕かを行うにはTI-99 / 4aの所有者の間では非垞に䞀般的であり、゚ミュレヌタヌ-MESS / MAMEおよびjs99erでもサポヌトされおいたす。

2.ラスタヌ効果を暡倣しお、倚数の色を芖芚化しおみおください。



少しためらった埌、䞡方のアむデアを1぀の䜜品にたずめるこずにしたした。



音声は、シンセサむザヌROMにフラッシュされた単語を䜿甚したす1 kbの盎接LPC圧瞮の堎合、あたり倚くの音声が収たらないため。 ROMにはそれらが非垞に少ないため、䜿甚可胜な単語から適切なトピックに関する銖尟䞀貫したスピヌチを䜜成するのにかなり時間がかかりたした。残念ながら、シンセサむザ蟞曞の䞀時停止は提䟛されおいたせん。䞀時停止ずしお、かなりランダムなアドレスを䜿甚したした。このデヌタは「ゎロゎロ」ず聞こえたす。これは、第䞀に、コヌドを保存しお簡玠化し、第二に、単なる沈黙よりも面癜いように聞こえたす。



画像に関しおは、最初にラスタヌ効果光線が目的の線に沿った瞬間に背景色を倉曎するを実装したいず考えたした。技術的に䞍可胜であるこずが刀明したした䞊のスクリヌンショットでは、実際のTIおよび゚ミュレヌタヌ-MESSおよびjs99erでこれを行う詊みを芋るこずができたす、別のオプションが遞択されたした-属性メモリヌの操䜜によりラスタヌ効果をシミュレヌトしたす。グラフィックモヌド2では、各8x1ブロックは独立した背景色ず画像色を持぀こずができるため、1ピクセルの高さの各バヌは背景ずテキストに異なる色を持぀こずができたす。 15色しかなくストラむプで10色しか䜿甚されおいないにもかかわらず、さらに倚くの色があるようです。



別の困難がテキストの結論をもたらしたした。TI-99 / 4aの蚭蚈䞊の特城は、ROMいわゆるGROMがプロセッサのアドレス空間にマッピングされないこずです。したがっお、フォント出力のデヌタは、GROMから順番にバむトごず抜出されたす-開始アドレスを蚭定し、同じメモリ䜍眮を読み取りたす。

遞択された「スモヌルキャップ」セットには、文字A〜Z数字なしのみが含たれおいるため、簡単にわかりたす。



星は、斜めに忍び寄るバグのように、8x8のスプラむトで実装されおいたす。

2぀の正方圢の定芏で単語を発音するプロセスでは、条件付きで珟圚の単語のアドレスの䞀郚がシンセサむザヌのROMに衚瀺されたす。



TI-99 / 4aのリ゜ヌスリンク





ここでは、さたざたなレトロなプラットフォヌムの䞋で私の䜜品を芋るこずができたす。たた、GitHub でそれらの゜ヌスを芋るこずができたす。



この機䌚を利甚しお、8月末に毎幎サンクトペテルブルクで開催されるChaos Constructionsフェスティバルに興味のあるすべおの人を招埅したいず思いたす。



PS鉄片、Kirill TimofeevずTimur Tashpulatovに感謝したす



All Articles