Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Teo Tormo

19
Posts
110
Followers
A member registered 12 days ago · View creator page →

Creator of

Recent community posts

(1 edit)

My main test unit is a Japanese top loader with Furrtek's SD Loader using firmware 0,11 , and setting the region to Europe, Japan or USA the game loads and you can fight any combat using the downloadable version which is available here. For CD-R media I use a Japanese CDZ, with same results.  Have double checked 5 minutes ago.

To track this down, could you check a few things on your SD Loader?

  1. Firmware version (shown in the loader menu). I test with v0.11; versions before v0.9 had bugs with games that load during play.
  2. In the loader settings: Developer mode OFF and Debug DIP 1 and 2 all at 0 (they may have been changed for another game and stay active).
  3. Try removing any .dip files from the SD card root, and copy the game folder again exactly as downloaded (BIN files + CUE, not converted).
  4. Does it freeze on the very first fight, or after a few?
    Your answers will tell me if it’s a setting or something I must fix in the game. Thanks!

The available version here works fine for me at that point. Previous versions may fail there, but latest works for me. 

It is not meant for emulators, but it works with Retroarch using Geolith core.

Thanks for your nice words. 

thanks for the info!!

Thanks! I haven’t tried your version, so I can’t give you a fair comparison. I developed mine with substantial help from Codex, alongside many hours of testing on real hardware and troubleshooting. 

I understand that these projects involve costs. Personally, I wanted mine to be freely available so anyone interested could try it.

If you  want to use an emulator, use Retroarch with the Geolith core.

New beta 17 i s uploaded and works with SD Loader and has been succesfully tested with CD-R recorded with Daemon Tools and Neo Geo CDZ

Backbit specific version will be available with the next version next week, 

The bug is now solved, next update will have the fix, it will be online next week.

Thanks a lot!!!

Hey did you solved the puzzle with the moving floor on SF2?

Claude read it now. Same findings on the handshake (the fixed 18-value sequence ending in 2) and on the wasted cycles (in the port the ~1200-byte copies to and from shared RAM are patched out). The approach differs: you patch the jump table into direct calls, while the port leaves the 68000 code untouched and answers as the HuC would, including a 68000 rewrite of the 6280 collision routine, reading its data tables from the uploaded program image in ROM. It didn't consult your post while making the port, but it can't rule out having seen it during training.

Thanks! To be clear, the technical work on this port was done by Claude (Anthropic's AI); I directed it and tested on real hardware. Here's its explanation:

It's the original Data East set (MAME "robocop", World rev 4), not the bootleg, so the protection is the real HuC6280 coprocessor rather than anything bootleg-specific.

It isn't a hand disassembly either. It's closer to a static recompilation. A rewriter traces the 68000 code, both statically and with coverage from emulated playthroughs. It relocates the code and patches every hardware access to shadow RAM, and a vblank layer converts the video to the Neo Geo every frame.

The HuC6280 is handled at a high level instead of emulating the chip:

- At boot the 68000 uploads the HuC's program through the shared RAM (the HuC's own ROM is just a small loader). That uploaded 6280 code was disassembled to see what it does.

- The handshakes are faked: the loader-ready/started bytes and the 18-value sequence the 68000 checks on $4001-$4003.

- The IRQ commands (write to $47FF) are handled in 68000 code: $80 echo, $81 self-test (shared RAM filled with $AA), and 0-$7F, which runs the real job, the object collision pass.

- The collision pass is a port of the 6280 routine to 68000. It reads the HuC's data tables directly from the program image in the 68000 ROM.

- The game copies about 1,200 bytes of object records to and from the 8-bit shared RAM every frame. Those copies are patched out, and the collision routine works on the records in place in work RAM, which saves a lot of CPU.

qué raro , en neogeo cd no pasa, lo miro

gracias, lo tenía anotado

I think it is fixed now

I have uploaded a new version, there was a problem with the difficult level, the credits are not fully fixed, but at least are lees weird

I have uploaded a new version which solves that bug. Thanks for testing and commenting!!!