I posted in 2011 about a program to disassemble NES games and make SNES roms nearly automaticly. It was not finished, the assembler code replacing the PPU calls and the code for the interrupt vectors is not working. Many test roms did not pass and I stoped here.
Today a friend told me to put something in GitHub before tonight, so I have chosen this project, nothing to lose.
I have released it with a GPL licence and uploaded it to Github at https://github.com/mandraga/upernes.
For now it is mostly a tech demo but the C code works fine, it is the asm files who do not work that much any more.
Edit: I worked on it for 6 month and I have encouraging results on the snes.
Edit: Super Mario Bros nearly completed, it needs a proper sprite 0 emulation and a fast background refresh.
Edit: Sprite 0 is ok, sound and bg update in progress.
Edit: Sound is working and Super Mario Bros, Excite Bike, Balloon fight are emulated.
I do not want to have to install flex-mingw or something similar because Sourceforge seems to hate using adblockers, and no other trusted mirrors exist right now for flex-mingw!
I have MSYS2 on my windows and it will not be difficult to "port" it. I will port it maybe in a week or two when I can work with my computer with windows and MSYS2. But you can try MSYS2 (has an installer) and then adding all the tools and all the libs like flex and bison using pacman in command line. Porting from linux to windows is much more easier recently.
Today I ported it to windows64 using MSYS2.
Recompilation works except if a PORT is accessed by other means than absolute. Indirect port accessed may be used by some rom's audio program SNDSQR1 SNDSQR2.
The binary is called upernes.exe in the source folder.
Usage is: ./upernes.exe romname.nes
The new source code and CHR files are in outsrc/. Copy them to asm/ and build the snes rom.
Add a outsrc/ fodler to binw64 and you should be able to call "upernes.exe romname.nes". What you see in the graphic window is the code already parsed. I do not remember the color meaning, it should be data/code areas, maybe I will add audio port and graphic port accesses in other colors.
I do not know if it is current usage to keep compiled binaries in a git repository? Is it better to put that on another web page? I was used to sourceforge where you have both source and binaries. Can someone clarify this?
Currently upernes.exe exits if it finds a non absolute address access to an hardware port. It means that if a rom writes in a port using the port adress it is transformed into a call to an emulation routine on the snes. But if a rom writes the port using an indexed something then the code to replace this indexed call needs to be added to the cpp asm rewriting functions.
However, currently, the basic test roms must pass the tests again. upernes.exe rewrites the code but the called routines from the assembler files are not working properly. So the plan is to fix the asm port routines and then add the non absolute port read/writes.
Btw, now that it works on windows, do you know an snes emulator with a good assembler trace and breakpoints? This is crucial to be able to work properly on port emulation. Being too often lost in asm routines was what made me stop working on it.
There are some serious permissions issues in your source folder, too. Everything was marked executable, and I was unable to touch any of the source subdirectories from permissions issues. I had to manually fix permissions before I could use this.
When I ran upernes on Donkey Kong (PRG1), a lot of text went by, a window with a strange red smear on it popped up for a second, then I got this output:
Code: Select all
upernes: recompileIO.cpp:133: void CRecompilateur::outReplaceIOport(FILE*, t_pinstr, Copcodes*): Assertion `addressing = Abs' failed. Aborted
I will check those permission issues right after this post.
The text is the rom source code plus the count to ports and memory accesses, this is normal, look to it. The image is the rom being disassembled as I said before.
And yes, it fails if it finds an indirect access to an hardware PORT.
Thanks for your comments.
Ballonfight passes the recompilation process (however, without adding the indirect jumps if any).
Now I must merge the assembler files containing the new routines, and this is far from working. But I have seen that snes9x debug version was ported to linux, this may be great for passing the tests roms.