Barone

@yuzokoshiro I realized that if you hold the equivalent to DOWN + A + B + C during the YKGGG sequence, it will load the Mega Drive era Ancient logo.

I agree. Great question. I think a lot of what is special about the hit react / 'stun' timing and rhythmic cadence of the gun play in GE007 evolved from Virtua Cop (SEGA) (which was Martin Hollis' initial direction for the game)

"Shrink patterns that live in VRAM" is the right architectural answer IMO. The shrink logic sits at the sprite assembly stage. Each scalable sprite needs horizontal and vertical shrink factors, 4 bits each, giving 16 levels. As the VDP writes a sprite into the line buffer, a subpixel accumulator decides which source rows and pixels to skip. Bresenham-style decimation. Shrink-only, not enlarge: enlargement does not fit a fixed VRAM access schedule and consumes too much of the 320-pixel line buffer per sprite. VRAM read bandwidth does not change. The VDP has exactly 40 sprite pattern fetch slots per line in H40 mode, giving the 320-pixel limit. Shrink does not save fetch slots, because tile data is read in 8-pixel rows regardless. You fetch the same rows and drop some pixels at the write stage. The per-line sprite count budget is unchanged. What you do get is the right size for each sprite without storing pre-scaled copies. Now the real costs: - The vertical shrink factor has to live in the VDP's internal sprite attribute cache, because it interacts with the per-line visibility scan during HBLANK. The cache currently holds the first 4 bytes (Y, size, link) of each sprite. Adding shrink data expands that cache by a few hundred bits of internal RAM, not just combinational logic. - HBLANK is already tight. The VDP processes the sprite list during HBLANK at roughly 2 SC cycles per entry, and the schedule is nearly full. Adding shrink factor evaluation costs a few cycles per entry, which over 80 sprites can push past the end of HBLANK. The visibility-scan phase may need a pipeline restructure, not just extra gates. - Horizontal shrink modifies the line buffer write-address generation, not just the write enable. Each sprite needs its own write-position accumulator during line assembly. This is a real address-generation change, more than a gate to suppress writes. - The attribute table layout has a constraint: entries are aligned on $200 or $400 boundaries and the address generator is tied to the 8-byte stride. A 16-byte scaling-mode entry means changing that address generator. The cleaner approach is a separate parallel scale-factor table at a configurable VRAM address, with its own VDP register, which costs another register and another address path. - There is also a VRAM-budget issue. The shrink feature solves the multi-scale storage problem (one master copy in VRAM, displayed at any scale). It does not solve the absolute-size problem. Super Scaler games like Space Harrier need many large source sprites resident at full size, because anything that might come close to the camera has to be available. The standard Mega Drive workaround, DPLC streaming, works for animation frames but not for "many large enemies must be ready simultaneously." A real Space Harrier port on this hypothetical hardware probably needs either more VRAM than 64KB or higher cartridge DMA throughput. Both are real BOM costs. So the honest total: an expanded sprite attribute cache, modified HBLANK sprite processing, line buffer write-address generation logic, an extra VDP register and table, and likely a VRAM or cartridge bandwidth upgrade. Call it 5-10% of the VDP's complexity plus a small BOM hit. The 320-pixel line buffer limit and the 40-fetch-slot ceiling stay where they are, because changing those means a faster VDP clock or a wider memory bus, both of which blow the consumer price point. The feature was reachable in 1988, but not trivial. It would have been a real engineering project measured in months, not gates on a margin. That is probably why it did not ship: the VDP was already on a tight schedule, scaling was an arcade feature with no console-market driver in 1988 (the SFC did not exist yet), and the cost was meaningful enough that skipping it was a defensible call. M2's "Sega Mark V" in the Mega Drive Mini 2 is exactly this proposal taken to completion IMO. They added sprite scaling to the VDP within the existing access slot schedule, ran Space Harrier and Space Harrier II on the result, and the games behave precisely as the analysis predicts. Speed matches the arcade in normal play, because the framerate cost of fake scaling is gone. But the reviews are unanimous on one specific issue: noticeable sprite flicker in scenes with many large enemies, particularly in Space Harrier II stage 12 and the Space Harrier boss fights. The Game Watch reviewer notes it as an "honest" limitation consistent with the spirit of the original hardware. That flicker is the 40 sprite pattern fetch slots per line maxing out. M2 added scaling and apparently left everything else alone, exactly as descrived here. When a scene wants more sprite pixels than the 320-pixel line buffer can hold, the VDP drops sprites on alternating frames, and you see flicker.

メガドラにリアルに拡縮機能を入れるとしたらどうするんだろう？　拡縮したパターンをVRAMに配置しないと描画できない場合、64KByteじゃ無用の長物になってしまいそう。(NEOGEO風に)VRAM上のパターンを縮小して表示する機能ならリアリティあるのかな？

Darius II is now fully playable on MiSTer FPGA 🚀 Major bugs are gone, triple-screen is blazing, YM2610 fully working and the core is approaching public release. youtube.com/watch?v=CNqW2f… #MiSTer #FPGA #Arcade #DariusII #Taito

Doom resurrection on the GF1 Neptune. Working in progress

Heyでは毎日ゲームのLIVE配信をYouTube、ニコニコ生放送で #レトロゲーム や最新ゲームの配信行っています。 ご視聴はこちら🔽 taito.co.jp/store/service/… Heyでは250以上のビデオゲーム設置しております。 是非秋葉原来た際には寄ってみてください。 ＃秋葉原Hey

Algunos habéis pedido video para poder verbel juego hasta que podáis probarlo, así que vuestros deseos son órdenes. Disculpad la torpeza pero estoy jugando con una mano 😂 #MegaPang

This freaking sequence.... This engine is a progression on mega r-type but, this sequence required support for reverse scrolling/event system, animation of the lift etc... Now it's done and.. I'm BAAAAD

youtube.com/watch?v=ybOPjG… public release of my FPGA core for China Gate (Technos, 1988) on @MiSTer_devel — both US and Japanese 西遊降魔録 ROM sets supported. #MiSTerFPGA #FPGA #Arcade #Retrogaming

@pastel_orbit @MADOKA_Park @GabrielPyron

自己書き換えプログラムによる最適化の話 BLAZING STARとPULSTARをリードエンジニアとして担当致しました PULSTARはそもそもVIEW POINTからの系譜であり、そちらへもテクニカルアドバイザーとして参戦しておりましたが 晴れて自分の作品としてPULSTARを実装し、BLAZING STARへ昇華していきました BLAZING STARもとても好評を頂き大変有り難かった が、NEO GEOという全く同じハードウェアでPULSTARを超える為に、何百もの工夫をしました 当時のゲームプログラム業界は血で血を洗う最適化と表現の群雄跋扈時代 一サイクルでも多く稼ぐ、芸術的な、それこそ思考競技と言える様な切磋琢磨時代でした そんな中一つ、現代では馴染みのないテクニックを プログラムコードは通常RAMへ展開されますが、という事は、自分自身を書き換えるプログラムもあり得ます これはその一つである弾幕を扱うループ処理 言語は勿論MC68000アセンブラ 数十～数百を彩る弾幕を、現代で言えばそれこそECSの様にキャッシュを意識したコーディングが出来れば良いのですが、なにせ当時です 最適化の肝はCPUクロックの削減徹底 for 弾 in 弾幕群 update 弾 こんな言語はありませんが、全員判ってくれますね これが無駄なんです あの頃のアセンブラ界隈では、ループ処理すら無駄。無駄無駄無駄 CPUクロックが足り無くて仕方がありません そこで僕はこんな事を : 前提 弾 update 弾 update 弾 update 弾 update ↓ 以下管理RAMが許すまで同じ処理を書いておく : フレームの頭 このフレームでは「弾」が100個ある。じゃあ、100個目に「rts(ループを抜ける)」命令を上書きする : この、手作りの料理みたいなRAMの上で実際にCPUを走らせる : rtsに書き換えた部分を「弾 update」へ書き戻す :毎フレームこれを行う 馬鹿馬鹿しいほどのストイックさです これにより、ループにまつわる「変数iはn以上か？そうでなければループ」という処理すらを省いています 実効値で2倍以上の効率化です いつの時代も、コーディングにおける最適化は芸術だと思います なにより、楽しい

High octane speed in Konami Snatcher wannabe Chords. Why not join the Chords revolution and support us at: patreon.com/Retrosegadev?u… #gamedev #indiedev #segagenesis #segamegadrive #sgdk

@badcomputer0 Very well deserved. You both do amazing work on the SMS. I hope to see more of this partnership. It really reminds us how great 8-bit gaming can be.

Road Fighter won the SMS Power coding competition! Thanks again to Chirinea for teaming up. There were a lot of great entries this year. Now we have to think of something for next year. #mastersystem #homebrew

@Karu_gamo F1 Triple Battle (PCE) / Fastest 1 (MD) applies some ideas that may be useful to you, I don't know. youtu.be/8Ls7zLEaB-c?si…

こうしてみるとMDのレースゲーはキレイだね。毎ライン計算してるのかな？　自分はそこまでこのラインをキレイにしたいとは思わないが、強い拘りを感じる美しさだ。

水平割り込みは２ラインごとに発生させていたけど、前計算は１ラインごとに行っていた。それだと計算量が多くて重かったので、計算の方も半分にした。おかげで軽くなったが、縁石がジョギジョギになった…。ファミコンのF1レースを彷彿させるね

Darius 2 and The Ninja Warrior MiSTer FPGA Core little update 😘youtube.com/watch?v=WR91F6…

So, this is a thing. 32X Games play on the SegaCD32X SRAM cart now. Hopefully, MARS Scientist can move foward with it. Shout out to Chilly Willy for the help and inspiration. Thank you! MD-32X-RAM-Cart Mod consolemods.org/wiki/index.php… @RetroRGB #Sega #Sega32X #SegaCD #SegaNeptune

Just another emulator? #NEOGEO

SNK絶頂期はいつか？ 餓狼、龍虎、サムスピ、KOFが出た年を並べると一目瞭然

The return of a legend The NEOGEO AES+ launches November 12, 2026 🎮✨ Now featuring HDMI output, high score saving, and more— all while preserving the essence of the original. Launching alongside 10 classic NEOGEO AES cartridges 📦 🔽 Pre-order here 🔽 plaionreplai.com/neogeo #NEOGEO #SNK

@matteusbeus It's still in time to delete that comment.

Darius II on MiSTer — first glimpse of triple screen coming to life! 🚀 Still polishing, but the game runs and all three panels are showing. Big thanks to wickerwaka (Donlon) for the Taito F2 reference. More soon! 🙌