Comments (11)
I am generating my C ROMs using a tool I wrote. I also made this, https://city41.github.io/neospriteviewer/, which is helpful to validate C ROMs, and I am pretty confident the C ROMs are built correctly.
I don't think it's a C ROM issue. As when .padding
is no longer present, my S ROM tiles are also messed up. But I totally agree removing padding leading to this issue is very strange.
I have no idea what the actual issue is. I'm very new to native dev like this, reading up on ld scripts right now.
This isn't urgent for me. I hope to learn enough to contribute rather than just post problems :)
from ngdevkit.
I removed .padding from ngdevkit.ld in my fork and returned to having objcopy swap the bytes. No problems so far, everything works great on gngeo and real hardware. I am padding out the p rom to 64kb with my neosd converter tool.
from ngdevkit.
I am having some luck with
prom: $(ELF) rom
$(OBJCOPY) -O binary -S -R .comment $< rom.stripped
(cd ../swaptool && ts-node index.ts -i ../src/rom.stripped -d ../src/rom/202-p1.p1)
Where swaptool is just a dumb program I wrote that swaps byte pairs. Basically telling objcopy to strip out all the unneeded stuff then swapping remaining bytes blindly afterwards.
I guess it's possible the padding section can be whatever (I still don't understand its purpose) and objcopy's --reverse-bytes
was used when it can only do the job when rom.elf just happens to have even padding? In other words, reversing the bytes with objcopy might not be the right way to go?
The approach outlined in this comment works on gngeo and NeoSD.
from ngdevkit.
Wow, bad error indeed... let me see if I can come up with something that doesn't require additional tool, I don't remember whether my neogeo linkscript is causing the generation of the .padding section or if it's a common section. But either way I'm almost sure we could strip that section and be done with it.
Can you check on your rom whether $(OBJCOPY) -O binary -S -R .comment -R .padding works better?
from ngdevkit.
Actually I think I am wrong that removing .padding broke the rom on NeoSD. I believe that was another issue. So it's possible just killing .padding altogether is the way to go. I will test tonight.
from ngdevkit.
Did some tests and I am finding when I remove .padding
from the p rom by adding -R .padding
to the objcopy command, it works just fine on gngeo, but does not work correctly on real hardware with the NeoSD. I get garbled graphics as if the tiles in my C ROMs and S ROM are messed up. But I suspect some pointers in the P ROM might be off? causing the game to load the wrong tiles?
If I build the exact same game, except leave in .padding
, then it works as expected in both gngeo and on real hardware. In this case I am using my cheesy little swaptool to swap the bytes as outlined above.
from ngdevkit.
looks like padding is added in the link script
https://github.com/dciabrin/ngdevkit/blob/master/runtime/ngdevkit.ld#L103
from ngdevkit.
For garbled gfx, you might want to have a look at #14 and check if the solution over here has any impact on your rom.
Right now I fail to see why removing the last section of the ROM would have an impact on sprites :/, would need to look into it and try to generate a p-ROM that exhibit your problem.
I'll report my findings as soon as I get some spare time, I still hope we can fix the issue with a tweak in the link script rather.
from ngdevkit.
One theory is the NeoSD can not handle such tiny P ROMs. They may be assuming a P ROM is always at least 512kb. I think that's the smallest P ROM size of commercial Neo Geo games.
I posted on the TerraOnion forums asking about this.
from ngdevkit.
The p rom needs to be a multiple of 64kb for the NeoSD. So that is very likely the issue.
So yeah, maybe just get rid of .padding?
from ngdevkit.
I removed .padding from ngdevkit.ld in my fork and returned to having objcopy swap the bytes. No problems so far, everything works great on gngeo and real hardware. I am padding out the p rom to 64kb with my neosd converter tool.
Ok by re-reading objcopy's manual, I saw that the semantics of reversing bytes is to work on each section individually, rather than on the output file. So indeed, since the linkscript doesn't enforce all section sizes to be even, this can cause problems as you mentioned...
I now use dd to swap bytes. It's generic enough that it will work on all OS, and it leaves the linkscript untouched, so I think that it's a good compromise.
Also, it should fit the NeoSD use case as I believe that the default linkscript aims at padding to 128KB, which should be good enough.
Don't hesitate to reopen if the problem persists, Thanks!
from ngdevkit.
Related Issues (20)
- How to convert Sprites via ngdevkit? HOT 1
- Linux compilation instructions: Ubuntu readline package name change HOT 1
- Deferred VBL routines, audio, and then some more HOT 4
- Address error HOT 1
- Packaging of ngdevkit-toolchain is broken for sdcc HOT 1
- deb packages are broken in launchpad for Jammy 22.04 HOT 1
- pip3 install pygame HOT 3
- SDCC no longer builds in MSYS2
- Tracker music support for ngdevkit? HOT 2
- GnGeo compatible with MAME? HOT 6
- Software DIP system doesn't work with optimized builds HOT 5
- MSYS2 pacman 404s when trying to download ngdevkit repo database HOT 7
- Move MSYS2 CI builds to one branch per sub-project HOT 1
- Clean nightly tags in msys2-ngdevkit repository after new commits/builds
- Update ngdevkit docs to use the new ucrt64 packages HOT 1
- rpm rebuild workflow in COPR HOT 1
- PyGame may load palette .png incorrectly, which breaks ngdevkit tools
- Games no longer work in MAME HOT 3
- SDCC compiled with program-prefix breaks .rel files generated with sdas
- ngdevkit cannot extract toolchain tarball with recent msys2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ngdevkit.