Problems with tiles rom on real hardware

[totologic]

Hi.

I try to run some demos on the real Neo Geo hardware.

I use the NeoSD : The NeoSD

Whereas the fixed layer works well, the display for sprites has a problem. For example, the logo in the Sprite demo doesn't show: Video of Sprite Demo

Trying with with some demos I built (with map of 10000+ tiles), I started to see sprites on screen, but all is messy. I could guess from the results on screen that the tiles in the C-ROM don't start at the expected index.

You can compare: Video of my demo on MAME

Video of my demo on Neo Geo

In your demo code you add this: `/// First tile for the sprite in the ROM

define START_TILE 60`

Is it related to our problem ? Why the 60 value ? On real hardware this value should be higher, but why ?

[totologic]

I have noticed the 3840 bytes size for tmp.c1 and tmp.c2 files, matching the 60 offset value for our start tile. Is there any reason for such a value or is it arbitrary ?

[dciabrin]

First of all thanks a lot for your report, this is the first time I see a ROM which uses ngdevkit running on real hardware :)

As for the sprite problem, this is puzzling and probably hard to debug for me alone as I don't own a NeoSD..

Let's address the simple thing first: START_TILE 60 is kind of arbitrary. In fact it's the first game tile that can be used, because by default all the previous tiles are used to hold the ngdevkit logo that you see on the eyecatcher.

By default, a ngdevkit-based ROM configures the eyecatcher function to use sprite info from tile 0 [1] in the C-ROM. The eyecatcher expects 60 tiles for the original neogeo logo, so the first tile that the game ROM can use is tile 60. I should come up with an example of a custom linkscript and crt0 to explain how to override that, but I don't think it's the root cause of your problem.

What puzzles me is that the first 60 tiles are apparently correctly displayed by the neogeo bios, so it could very well be that the the sprite examples in the devkit lack some writes to specific registers or something to properly set up the sprite.

Maybe the problem comes from some mapping done by NeoSD, although it looks unlikely: all the example rom in ngdevkit hijack some existing rom name to make them run on emulators (ngm code 202). So if for some reason the size of the rom created by ngdevkit doesn't match that of the original game, maybe NeoSD does something weird? Although as I said, it's highly unlikely, because the eyecatcher seems to work fine.

It looks like the sprite set up example is lacking something :/

[1] https://github.com/dciabrin/ngdevkit/blob/master/runtime/crt0.S#L60

[dciabrin]

Hmm actually I just realized that the eye catcher was run from the emulator. Can you tell me whether it works on real hardware? maybe I got the analysis totally wrong in the first place :)

[totologic]

The eye catcher doesn't show on the hardware, it shows only on MAME.

I export the ROM for the NeoSD using a generic process (no checksum, no relation with an existing game). I used it to export the Neothunder homebrew (also based on PuzzleDePon rom) and it works fine.

I am going to investigate in my demo why some tiles show and some other don't. Maybe I will identify something.

Don't hesitate if you have any idea.

[totologic]

I did some experiments.

I did a swap of the c-rom files with the Neothunder homebrew. Results show the files exported by the titletool as safe (they display well in Neothunder). But the tiles from Neothunder don't show in the sprite demo, confirming something wrong with the code.

Then I wrote a simple rom tiles explorer. It is based on the sprite demo. It allows to show 64 successive tiles from the c-rom, starting from any point. The result is astonishing: the tiles show only from the 4036th place (maybe +/- 1). We can see it clealy at 00:49

Demo tiles

Does-it mean something to you ? We could hardcode the 4036 value but that would not be really satisfying :)

[totologic]

After playing a bit more, I found the exact offset in c-rom tile access is exactly 4096 (4036 as shown above which we add the 60 START_TILE value). I could play some demo adding this value in my code.

[city41]

I get the same results with this example on the NeoSD.

But I would argue the starting index of 60 for the tiles is correct, you can see that here:

Seems there is something wrong with the example's code.

FWIW, in general I have had a lot of success running stuff built with ngdevkit on NeoSD. This is the first time I have seen an issue like this.

[city41]

Also from what I can tell, the eyecatcher should not run at all for default ngdevkit games. Why MAME runs the eyecatcher I don't understand.

In ngdevkit's runtime, $122 jmp's to GAME_BOOT. $122 is where the game's USER subroutine handler needs to be

https://wiki.neogeodev.org/index.php?title=USER_subroutine

The first time it is called is for eyecatcher. But rather than respond to that, a ngdevkit game invokes main(). I hacked at crt0.S to work around this:

https://github.com/city41/ngdevkit/commit/2f3395ee5208c5bc5746f95434628bba75b53293

My hack causes ngdevkit to respond to eyecatcher and tell the bios to handle eyecatcher. Then the second time USER is called, main() is invoked.

[city41]

I was able to fix this

The way I did it was with truncate --size 131072 202-s1.s1, then load it onto NeoSD.

It seems the very large S ROM (it is normally 1048576 bytes) is tripping up the NeoSD somehow.

@totologic how do you make your .neo files? I suspect your tool for making them and my tool for making them both handle large S ROMs incorrectly.

My NeoSD tool is here: https://github.com/city41/neosdconv

EDIT: I also changed the first color in the first palette to 0x8000, which is required for real hardware to operate correctly.

https://wiki.neogeodev.org/index.php?title=Palettes

See the "Special colors" section

[city41]

S ROMs have a max size of 128kb. ngdevkit generates S ROMs that are 1024kb. If an S ROM is larger than 128kb, bank switching is required:

https://wiki.neogeodev.org/index.php?title=S_ROM

[totologic]

I use the NeoBuilder.exe program provided by Terraonion.

[totologic]

Guys, that would be great to have a place to share our experiments and tricks on Neo Geo, Ngdevkit, NeoSD, maybe more.... I already have plenty of demos running on the real hardware. Any idea ?

[sreuter]

@totologic Same here, happy to host this for us on my Discord. https://discord.gg/FXwhA8P

[sreuter]

Btw, I spent some time last night to get my homebrew game working on my cabinet using Darksoft's MultiMVS. Thanks to some of the instructions in this thread + some MultiMVS specific instructions on how to compose the ROM!

Here's the quick and dirty gist:

mvsmulti:
    mkdir -p mvsmulti/
    ./join_crom0.py # get this from https://www.arcade-projects.com/forums/index.php?thread/5055-darksoft-neo-multi-help-thread/
    cp rom/202-m1.m1 mvsmulti/m1rom
    cp rom/202-p1.p1 mvsmulti/prom
    dd if=rom/202-s1.s1 of=mvsmulti/srom bs=128k count=1
    cp rom/202-v1.v1 mvsmulti/vroma0
    echo -n "13" > mvsmulti/fpga

[dciabrin]

Hey @city41,

Thanks very much for troubleshooting that one. Sorry for the awfully late answer, but I just fixed all the examples in ngdevkit-examples by following your advice. So if you happen to re-run the devkit's examples on your real hardware and it doesn't work now, please shout and I'll revisit it (hopefully more diligently this time :P)