Ok I'm slowly learning C++, and teaching myself how to make a NES emulator at the same time.
But I also have an idea for a little side/project.
What I want to try is to make a program that can convert NES games to SNES games.
Why do you ask?
Especially when there are already plenty of both NES and SNES emalutors around?
Just for the challenge...
I had thought about just trying to write a program that converts the ROMS to exe files instead.
But, well, thats kind of boring tbh.
And obviously wouldn't work so well unless the end user had the same or a very similar system to my own.
So anyway, has anyone ever done something similar?
Where the program takes the input of a NES ROM and outputs a functional and compliant SNES ROM?
I looked, but I couldn't find anything that does this. But maybe I was just using the wrong search terms.
If I am not mistaken, people have already done this a few years back. I'm pretty sure I've seen NES games that runs in SNES format, atleast some mapper 0 games like "Mario Bros" and similar..
I am not sure how it was done. Perhaps using the 8-bit mode on the SNES.
Well so far I've seen that people have done this by hand, but I've yet to come across any apps written that automate the process.
Not saying that they don't exist though...
wasn't the snes built to be compatible with nes games ? so that's probably a possible thing
tho i don't see how you'd trivially convert nes roms into a native windows executable unless you just append a rom to an emulator
since translating the rom into something x86 can would be anything but trivial
Coldberg wrote:
wasn't the snes built to be compatible with nes games ? so that's probably a possible thing
The SNES
was originally supposed to be compatible with NES ROMS, but apparently Nintendo had a lot of prob at the time getting it working, and so it never happened.
Both the NES and SNES CPU are the similar architecture + endian-wise, so that is in my favour too.
Coldberg wrote:
tho i don't see how you'd trivially convert nes roms into a native windows executable unless you just append a rom to an emulator
since translating the rom into something x86 can would be anything but trivial
That's not entirely what I had in mind.
Perhaps a better example would be to think of it as a "ROM mapper" of sorts.
I imagine the breakdown would go something like this:
* map sprites
* map backgrounds
* map animation/char movement
* map sound
* pad rom as appropriate
So there would be no actual executing req'd as the new emulator/console would simply play the new rom as if it was created for it.
Converting the sprites/backgrounds would be fairly straight fwd. Re-assembling the levels AND maps would be a bit more tricky, I'd imagine. But the actual character movement/reponses... That's where I imagine it would start to get problematic.
I'm not even considering the sound at this stage. That would be something that I would prob leave off for a very long time...
emu_enthusiast wrote:
Well so far I've seen that people have done this by hand, but I've yet to come across any apps written that automate the process.
Not saying that they don't exist though...
You haven't seen one because they don't exist.
They don't exist because it's not possible to fully automate the process.
NES and SNES share a similar processor architecture, but from a standpoint of a conversion program, that is the end of their similarities.
The register map is totally different, the timing is different, the PPU is different, and APU uses an entirely different processor with its own instruction set and memory map, etc, etc.
At best you'll be able to hack together a program to automatically convert 1 NES game to a functional SNES game. But in all likelyhood that program will only work for that one game.
It's possible to be semi-automated for a certain subclass of NES games - for example, CNROM games only. One could make build the necessary SNES-side code and build a tool that would convert everything necessary - it would probably either require ROM detection (to know where data and code are in the ROM) or include a built-in emulator that logged every address that was code. This would require the user to play the game under such emulation and thorooughly exhaust every branch of game code that they could possibly do. Still wouldn't be 100%, so the user would have to manually ensure that all code was marked as code, graphic tiles marked as graphics, and sound driver marked as sound. Then an automated tool could take that external information and build an SNES ROM.
Not easy, but not impossible either. Wouldn't work for later games that used mappers, one would have to basically "unroll" the mapper and generate a flat memory map that the tool could use to convert the game.
Much easier to just port the game yourself, as has been done with the few NES-to-SNES ROMs that are floating around.
LocalH wrote:
t would probably either require ROM detection (to know where data and code are in the ROM) or include a built-in emulator that logged every address that was code. This would require the user to play the game under such emulation and thorooughly exhaust every branch of game code that they could possibly do.
Some of the FCE Ultra derivatives can save such an access log.
That's good, as such a log could be used. It would still require the user to manually attempt to access every possible valid code path in the original ROM. This was how the first Sonic disassemblies were worked on.
As a side effect, such a project could also make working towards a disassembly easier for a given ROM.
I'd be happy to contribute my NES sound emulator to such a project. I released the source under a license that is pretty close to public domain (if it isn't that exactly). But I'd be interested in updating a few things in it, if there was any point to doing so.
I wanted to write an emulator/auto-converter like you're talking about. But the sound was the most different part, and the most interesting to me, so that's as far as I ever took it.
I agree with Disch that it won't be possible to fully automate the process. I think there would be a pretty good success-rate though for auto-patching the NES register writes. The odds that it would get a false-positive and patch a 3-byte string of data instead of code are low, but significant (I can think of some stupid tricks that would reduce it, but it's surely easier to just manually hack the odd ones).
A while back I was considering the timing differences. On the SNES you could increment a counter every scanline, and use that to time-stamp the NES PPU writes (i.e., create an HDMA table, which also means the video will be one frame behind). The confusing thing is that the SNES CPU doesn't run at a constant speed, so I don't know if that can be worked out. Also, all this extra processing could would mean you could very, very easily run out of CPU time to finish the frame.
Overall, I believe that it's a lot easier than it looks.
Hehe. I didn't expect this sort of a response.
It was more of a "would this be possible," rather than anything concrete.
tbh I am nowhere near skilled enough coding-wise to be able to pull something like this off yet, or even any time soon.
You're better off doing it by hand. For PC-Engine someone has actually made a NES emulation wrapper that allows NES games to run with relatively minor changes. I know Mega Man, Contra, and Castlevania were working on it. All UNROM.
There's also Super Sleuth, which is really novel.
It's an SNES emulator, but it redirects NES registers to their SNES "roughly" equivalents, and uses the SNES CPU. With only a little bit of code, it runs Super Mario Bros.
byuu wrote:
There's also Super Sleuth, which is really novel.
It's an SNES emulator, but it redirects NES registers to their SNES "roughly" equivalents, and uses the SNES CPU. With only a little bit of code, it runs Super Mario Bros.
That's pretty cool. Thanks for the link.
byuu wrote:
There's also Super Sleuth, which is really novel.
It's an SNES emulator, but it redirects NES registers to their SNES "roughly" equivalents, and uses the SNES CPU. With only a little bit of code, it runs Super Mario Bros.
What do you mean by ''A little bit of code''?
Do you mean Graphics, Palette, **IRQ and ***Mapper Registers?
If so, Prove that SuperSleuth will run a modded SMB1 rom via SMBDIS with these modifications. Screenshots will tell the results
** It uses Sprite 0, You may need to replace it with an IRQ for it to work properly
*** Mappers do not apply to an unmodified NROM version of SMB1
Download the emulator yourself. byuu doesn't have to "prove" anything to you. He said Super Sleuth plays SMB and it took me a whole 10 seconds to try running it myself.
He's right. Every NES game that I tried works sucessfully.
So the interesting thing to me is now, can the same thing be done in the ROM itself rather than in the emulator?
This might be interesting...
I don't think it'd be feasible except by hacking the ROM itself. Disassemble it, replace NES register writes with equivalent SNES ones, and then rebuild the ROM.
emu_enthusiast wrote:
So the interesting thing to me is now, can the same thing be done in the ROM itself rather than in the emulator?
No. Getting a NROM game to work with an automatic patcher may work. But ultimately you can't automate a process to get the vast majority of NES games to run on SNES. The reason being mappers. That's why all the AS NES hacks are of NROM games.
You could probably adapter any NES game to SNES if you do it by hand though. If you have both the skills and alot of time.
Well getting an NROM game to patch would be my first objective.
But surely with a bit of work it could also be done for games with different mappers?
NROM games are not as easy as you think.
Identifying register reads/writes is easy for an emulator like Super Sleuth to do because it can do it while it emulates the game. For a program like a disassembler or NES->SNES converter, identifying which bytes in the ROM are actually register accesses is somewhat of a challenge. The only real way to do it is to step through the code, and even then it's hard to get it all (things like indirect jumps really complicate it).
And that's only the start of it.
I was going to get into the reasons why this is so complicated and throw out some possible ideas -- but before I do all that, let me ask you this:
How much about the NES / SNES do you really know?
EDIT:
Here's some stuff I as thinking about. This is assuming you can identify all register reads/writes in the original ROM.
Register changes
Since NES regs don't translate directly to SNES regs, it seems to me the way to approach the situation would be to replace register writes with JSRs That way you could emualte the NES registers inside the ROM.
The problem with this is space. LDA absolute is only 3 bytes, but JSL long is 4 bytes. This can be gotten around by "hijacking" the following instruction and placing it in the new subroutine (a trick I employed in my ROM hacking days).
For example:
Code:
STA $2001 ; original game code
LDA #$00
STA $6000
could be translated to:
Code:
JSL write_2001_lda0
NOP
STA $6000
;--------------- in another bank
write_2001_lda0:
JSR write_2001_common ; a routine to emulate a 2001 write on the SNES
LDA #$00
RTL
ROM space in other banks isn't really an issues because SNES allows for games to be much, much larger than most NES roms.
Sprite 0 hit
Sprite 0 hit doesn't really have any equivilent on the SNES... so this presents it own challenge.
The SNES
does let you fire an IRQ at a specific X,Y point on the screen though. So it makes sense that you could try the following:
- identify sprite 0 hit loops (not that hard if you can identify reg reads)
- replace sprite 0 hit loops with code that sets up an IRQ, CLI's, then WAI's
This complicates other things though:
- What do you do about other IRQs? SMB does use any other IRQs, but other games use DMC IRQs along with sprite 0. I suppose your SNES code could just figure out which IRQ is next -- like an emulator.
- How do you find out where sprite 0 would hit? I guess you'd have to keep track of sprite 0 information when you catch $2004 and $4014 writes so that you can know what sprite 0 is at all time. You could also read from VRAM to find out where the first opaque pixel is (without doing that, sprite 0 hit would trip several scanline too high in a lot of cases). Ensuring the BG pixel is opaque as well is pretty much out of the question, though.
@Disch
Not a lot yet, but:
1. There are plenty of technical docs available explain what things are and how they work.
2. There are also plenty tools to help decpiher whats going on.
3. There are even rom maps available for a number of games to aid the process.
The fact that there is already hardware available to plug a NES game into a SNES gives me hope that this is actually achievable. Although perhaps somewhat difficult.
The biggest problems that I can see I would have are:
1. The mapper situation.
2. The special chips that certain games contain
I'd love to hear any thought/ideas you have about how I could go about tackling this.
emu_enthusiast wrote:
The fact that there is already hardware available to plug a NES game into a SNES gives me hope that this is actually achievable.
The thing is... the hardware can just catch and readdress register accesses.
For the whole ROM to be converted you have lots of concerns apart from that, such as addressing and spacing issues.
Quote:
The biggest problems that I can see I would have are:
1. The mapper situation.
2. The special chips that certain games contain
Those are the same thing =P. The special chips you're referring to are typically the mapper.
Quote:
I'd love to hear any thought/ideas you have about how I could go about tackling this. :)
I don't mean to be a big pessamist. I'm all for a challenge. Admittedly, this is an interesting topic, and it would be neat if it ever came about. I'd be happy to contribute in any way I can.
But I don't have my hopes up.
Yeah, I can't promise that anything will ever come of this idea either.
The whole concept of it is interesting though. Being able to play a previous generation's game on a console in a non-emulated form.
I'll be back with more questions, if it gets off of the ground.
emu_enthusiast wrote:
The whole concept of it is interesting though. Being able to play a previous generation's game on a console in a non-emulated form.
It's not that new: Sega had Power Base Converter, Sony has PS1 discs in PS2 and PS3, and Nintendo has GameCube compatibility in non-Korean Wii consoles. The "hardware trickery" of this emulator is ample evidence that Nintendo at least tried for back-compat in the Super NES, but because games for earlier consoles used stuff not well documented in the official manual (like $2005/$2006 behavior), it was more difficult to revise those behaviors in the new platform.
AOROM, BNROM? Try identifying mapper writes and changing to another bank. It might not work so easily for CNROM because games are more likely to expect to read back.
emu_enthusiast wrote:
The fact that there is already hardware available to plug a NES game into a SNES gives me hope that this is actually achievable. Although perhaps somewhat difficult.
I do not see how this helps you. The Super-8 aka Tristar contains a NOAC like all NES clones. It does not utilize the SNES CPU or PPU.
What you want to do works in theory so much as you could certainly port any NES game to SNES given you have the skills and the time to do it, by hand. There is no magic bullet to automate the process. Before you can even begin to attempt this process you should probably first understand your source system, the NES. If you don't understand it your chances of success or any noticable progress are none. Once you know enough about the NES you'll have to learn about the SNES and then you'll begin to understand the challenges involved in running a NES game on the SNES.
However once you understand these things it is certainly possible to target a game and hack it up to run it on SNES. Obviously the AS NES hacks do this.
I agree with Disch that it's an interesting concept to talk about. But I don't think you have a chance at doing anything automated. Manually you can do but you need to do alot of research. It's not as simple as clicking the right things on your computer.
@tepples
The systems that are already directly backwards compatible don't interest me so much. Eg. PS1 on PS2, or GC games on a Wii. These systems don't really need to be re-emulated or converted anyway.
I wonder though more about things like turning a .nes into a .wad, for example. Not to play through emulation of the console, but turning it into a native playable game. Epecially for the old cartridge based systems that don't use the DVD/mini-DVD/Blueray formats.
Of course that is very far-fetched. And I am starting with a simple console, because this is easier to do and learn.
@MottZilla
I did not realise that the tristar did not utilise the SNES CPU/PPU. I just assumed it allowed a different cartridge shape to be used with the SNES console. That combined with the SNES CPU's "compatability mode."
Anyway I understand that the whole undertaking would be a HUGE, non-trivial task, and possibly even impossible.
- It's an awesome programming exercise, challenger... but I don't see a solid point of making such thing. It's much interesting, no doubt... but is worth the effort?
Fx3 wrote:
- It's an awesome programming exercise, challenger... but I don't see a solid point of making such thing. It's much interesting, no doubt... but is worth the effort?
I agree, interesting but not worth the effort, especially since I don't think anybody can say at this point how good a result can be expected. Of course I'm going to follow the progress eagerly though if somebody decides to undertake a project like this.
@Zepper
Why does anybody attempt to make an emulator?
And why do people continue to make emulators of consoles that are often already perfect or near perfectly emulated?
Is it because it is necessary? No.
It's the personal challenge, the learning experience, the inquistive nature of wanting to know how something ticks, the tinkerer, the hobbyist having fun.
Face it there's not really any bragging rights left in reproducing an old dead console. And gawd knows there's no money in it either.
So yes, its completely unnecessary. It's also completely self-indulgient. But also totally worth it.
emu_enthusiast wrote:
Why does anybody attempt to make an emulator?
And why do people continue to make emulators of consoles that are often already perfect or near perfectly emulated?
Is it because it is necessary?
Yes, this allows you to play old games without suffereing the problems of non-working connector, lost saves (due to died out batteries), unconfortable controller and play games translated from japanese, and to homebrew.
A NES -> SNES "converter" would probably be doable for simple mapper that uses no of few raster effects, but would have completely no point, as Fx3 pointed out.
I don't agree that it would be useless.
It would be very educational for one. He would become much more familiar with both the NES and SNES, and no doubt give him a boost in whatever programming language he chooses.
And let's not forget the fun factor. Isn't that the only reason any of us indie developers code anything?
Disch wrote:
And let's not forget the fun factor. Isn't that the only reason any of us indie developers code anything?
That and donations. I got enough donations from TOD, my GBA test cases, and my forum.gbadev.org posts to buy a DS and a DS homebrew kit back when homebrew was expensive (early PassMe days). Lockjaw for PC and GBA brought in a couple more donations from the old tetrisconcept.com crowd (which since split into harddrop.com and tetrisconcept.net), which I used toward buying my cousin's PSP-2000 so I could make final verifications on Luminesweeper.
Hamtaro126 wrote:
What do you mean by ''A little bit of code''?
Ask Overload, he hasn't released the source code yet. It could in fact be a full-fledged NES emulator for all I really know. I seem to recall hearing that it shared portions of the SNES code is all.
Disch wrote:
The problem with this is space. LDA absolute is only 3 bytes, but JSL long is 4 bytes. This can be gotten around by "hijacking" the following instruction and placing it in the new subroutine (a trick I employed in my ROM hacking days).
Until you run into one of those bastard games that have an RTS after your desired instruction. Or even better, where the entire function is just your opcode + rts (or there's a branch line in each direction), so you can't patch in the opposite direction either. You're pretty much forced to find free space in that bank as a springboard, or somehow hijack a JML (your location) into WRAM, an unused HDMA block, etc.
I've actually ran into this many times. It's very frustrating. I suspect you'd run into the problem a lot with an automated tool.
byuu:
Good point. That could also screw up jumps too. What if a game jumps to the instruction immediately after the STA? I'd imagine that would be quite common as well.
tepples wrote:
Disch wrote:
And let's not forget the fun factor. Isn't that the only reason any of us indie developers code anything?
That and donations. I got enough donations from TOD, my GBA test cases, and my forum.gbadev.org posts to buy a DS and a DS homebrew kit back when homebrew was expensive (early PassMe days). Lockjaw for PC and GBA brought in a couple more donations from the old tetrisconcept.com crowd (which since split into harddrop.com and tetrisconcept.net), which I used toward buying my cousin's PSP-2000 so I could make final verifications on Luminesweeper.
@tepples
That's pretty cool that you managed to make some money from doing it. I still think that your case would be the exception, rather than the norm though.
Regarding the JSL long, I didn't think it was an issue since you could put a table of long JMPs in RAM, starting at $0800 and JSR to there with the normal 3 bytes. If you support 29 registers (should be all of them except for $4016/$4017) with 4 addressing modes for each register, 4 bytes for each JMP long, that's 464 bytes.
Though you might have to dork with the stack or something to get it to RTL properly back from a JSR, I haven't used the '816 enough to know if that's much of an issue.
It might not be fast, but you've just gotta hope they don't write the registers too much. Regs like $2007 will need to be optimized (I think it would be very appropriate to use static recompilation in that case, to really be safe).
Memblers wrote:
Though you might have to dork with the stack or something to get it to RTL properly back from a JSR
That's called long jumping to a PHK-PLB-RTS in the appropriate bank.
Oh ok, I remember using PHK / PLB in my NSF player now that you mention it. Had been a while.
I'm
very surprised this hasn't been mentioned yet! And you were all so close bringing up the idea of code/data separation with FCEU*'s code/data logger; Kent Hansen (Snowbro) wrote NESrev circa 2003 to tackle this problem exactly; a code/data analyzing disassembler for NROM games.
I, myself, have experimented with a similar approach for SNES
[1].
I'm not sure if NESrev will be useful to you, emu_enthusiast. But if you want to go the recompiler route, that's the ticket. (At least until something better comes along?)
It will be difficult writing a generalized tool for conversion, as many have already pointed out. But don't let that distract you! Remember that similar things have been done before. Even if not entirely relevant, one example I can think of off the top of my head is the GBC-Colorizer; it was able to "convert" old monochrome GB games into GBC-color mode by inserting a generic subroutine that could setup the palette as configured by the user. It took advantage of the higher clockrate that GBC games ran, because the palette handler did add some overhead.
Similarly, SNES also runs "slightly" faster than NES, and this additional horsepower can be used to detect (and "correct") trouble areas like register accesses at runtime. Of course, this requires some serious hacking; this method is a lot like "software watchpoints" which I've explained in some detail on
my forums. There are possibly better ways to redirect register accesses and the like (pre-patching the ones that can be easily found and analyzed, for example). But runtime-checking is foolproof when implemented properly, even if it does add a ton of overhead. But hey, it's just an educational proof-of-concept project, right?
Hi
In 2010 I wanted to work on an sd cartridge but they are working well enough on it, and discovered at that time this CPU compatibility between the snes and the nes.
So I made a program called "uper nes" doing the work described in this post.
The goal is to increase the number of games on the super nes.
It is complex but the disassembling and assembling a snes rom works.
It lacks good register emulation. Actually it converts successfully test roms but not SMB.
It works by recompiling all the code contained in the prg rom and only the code because the prg rom is kept as a data source.
The snes rom runs the code bank on the recompiled code and the data bank on the original prg rom.
The CHR roms are converted when they are inserted into the video ram.
The tricky part is the indirect jump, I used a printf from Neviksti to display each unknow indirect jump address at runtime. Because the indirect jump addresses are not know until runtime. Therefore disassembling does not work on these addresses at first pass. The addresses must be entered by hand in a config file and the the re-assembler started again.
Actually the re-assembler is like finished but it lacks proper asm routines in order to recompile games that work. Like the DMA does not work, sprite 0 is not implemented...
Memblers has built the apu emulation already so I will use it if he wants but does anyone wants to help for the register emulation routines? I feel bored to always test and retest.
Maybe someone with more experience on the nes could help?
I will work on it in order to allow mapper 0 conversions. But not soon, it is difficult and I must take a full week to do something on it and then I'am exhausted.
I stopped for some month because I have a black screen on SMB and because maybe I can be helped. It will go faster than do it all myself. However even if helped, I keep doing the disassembler side of it.
It works on linux, uses flex and yak and wla-65816 assembler. I debug using supersleuth on wine.
Some more details:
The register access emulation calls routines from an assembler file.
All the remaining work should be to finish these routines. Some are linked more or less to others but it is possible to finish it by building test roms for the nes that only show one function on one register and then make the conversion work on the snes.
Actually I have the background, the palete, the controller, but problems with sprites and DMA.
And sometimes adding something new breaks old functions so test roms are mandatory.
Patrick: PM me if you got a chance, We can collaborate and use our skills to do this.
Also You need to convert to BASS (Byuu's ASSembler) to make things simpler. WLA may not be suitible enough for everyone because of the bad things the linker does, etc.
Still... I think this is great what you are doing.
You may try to ask the user named ''_mic'' for assistance of recreating the APU registers in SPC700 for WLA. and if needed, a BASS conversion may be also appropriate, or use MSU-1, but may be more difficult!
About the DMA of the Sprites: There are 128 sprites instead of the 64 sprites, You cannot adjust it to the size of 64.
So in order to do this: You must make a mirror of the SPR-RAM in FreeRAM, Just like in the Arkanoid conversion by P0P:
To do this, Copy the RAM from the defined position ($200-$2FF, 64 bytes) and copy it to FreeRAM at any place remaining (Arkanoid conversion uses SPR-DMA at $800-$9FF). and make the other 64 sprites turn 8x8 into 8x16 using a if the emulated register's 8x16 bit is activated (optional)
EDIT: Difference in Sprites are like this:
Code:
Key:
s = size
x,X = x position
y = y position
p = palette
c = character
m = same as c, but adds to the character set (mode)
v = vertical flip
h = horizontal flip
o = object priority (Depends on mode in SNES)
- = should be unused
(8 = the emulator's switch bit for CHR, shouldn't be used in real NES games)
From NES(8x8):
yyyyyyyy,vho---pp,cccccccc,xxxxxxxx
From NES(8x16):
yyyyyyyy,vho---pp,cccccccm,xxxxxxxx
From SNES:
xxxxxxxx,yyyyyyyy,cccccccc,vhoopppm+XsXsXsXs
For the SNES NES emulator, I propose a format conversion to this before DMA:
xxxxxxxx,yyyyyyyy,cccccccm,vho--pp8
in 8x16 mode, the M must set the 8 bit, in any modes, the ''pp (palettes)'' must be converted to comply with the SNES via bit shifting to the left...
Hi
I must take a look at BASS. Sure that WLA is not user friendly sometimes, but it works on linux and has interesting features when it's time to build the rom file.
The APU should just be glued in from Memblers work.
For the sprites I do not have it in mind but converting the format is something tricky. I use a loop to do the conversions before copy in video ram or CGRAM and I may use 64KB of cache wram for it because the DMA must be able to copy it at any time. I have used many strategies, but first it must work then be optimised.
What is the Pop's Arkanoid version?
Patrick FR wrote:
Hi
I must take a look at BASS. Sure that WLA is not user friendly sometimes, but it works on linux and has interesting features when it's time to build the rom file.
The APU should just be glued in from Memblers work.
For the sprites I do not have it in mind but converting the format is something tricky. I use a loop to do the conversions before copy in video ram or CGRAM and I may use 64KB of cache wram for it because the DMA must be able to copy it at any time. I have used many strategies, but first it must work then be optimised.
What is the Pop's Arkanoid version?
It is a NES to SNES conversion hack made by P0P, A old 1994-1995 SNES Hacker...
I may give it to you via PM under study purposes upon request, It is part-ROMhack Part-homebrew, so it is not to be distributed any other place!
Or search via GOOGLE.COM something or other...
EDIT: I contacted one of the people that had a similar project, Overload had the same thoughts and maybe we can combine code if approved by him (Contacted via PM)
Byuu said I need to check him out, so I did so...
If you give me the source of the Arkanoid port I will surely reuse the good ideas. And it's not mandatory to use it if the author wants it to be kept closed.
I looked at the html documentation of bass and it seems compatible except it does not use the bank system of WLA.
Adapting to bass is possible it should be like replacing BANK directives or even create BANK macros. And rewrite two or three things. I hope it's standard 65816 instruction names and operands.
What are the improvements in comparison to WLA?
With WLA I must very often specify rep sep for 16/8 bit instructions. And it is not clear to me how we can specify that a chunk of code is 16 or 8 bit without using a rep/sep. I had many bugs because I expected 16bit instructions and got 8.
So did someone started another project of this kind?
I though it was so difficult and uncertain that no one would do it.
Patrick FR wrote:
If you give me the source of the Arkanoid port I will surely reuse the good ideas. And it's not mandatory to use it if the author wants it to be kept closed.
I looked at the html documentation of bass and it seems compatible except it does not use the bank system of WLA.
Adapting to bass is possible it should be like replacing BANK directives or even create BANK macros. And rewrite two or three things. I hope it's standard 65816 instruction names and operands.
What are the improvements in comparison to WLA?
With WLA I must very often specify rep sep for 16/8 bit instructions. And it is not clear to me how we can specify that a chunk of code is 16 or 8 bit without using a rep/sep. I had many bugs because I expected 16bit instructions and got 8.
So did someone started another project of this kind?
I though it was so difficult and uncertain that no one would do it.
P0P is no longer in the scene since around 1998, so he does not care about it...
It is ROM only, but it still can be disassembled a bit to extract the main emulator parts...
I belive Banks are simply like this in BASS for example:
Code:
org $818000
db "Code and Data Here"
instead of WLA's extra functions:
Code:
;Is this right?
.BANK 1 SLOT 0
.org $8000
.db "Code and Data Here"
BTW Overload actually had not created a NES emulator for SNES, But he created Super Sleuth... I think after the PM he said something about ''I still continue to work on this project, Byuu made a Misinterpretation''.
I read about the idea of using the 65816 emulation to run the nes 6502 code without rewriting a 6502 emulator. But it does not mean that register emulation is written in 65816.
It is also possible to run the Arkanoid version on the nes and the snes and see what is different.
But assembler without comments is awfull, especially the loops. I am interested in the interrupt vectors and they should be easy to read.
I wait for other comments on this and if it is positive I will change the assembler to bass and release what I have on sourceforge.
Patrick FR wrote:
I read about the idea of using the 65816 emulation to run the nes 6502 code without rewriting a 6502 emulator. But it does not mean that register emulation is written in 65816.
Fact:
It is compatible for some, but few games such as Puzznic aren't compatible opcode-wise without extended hacks (uses the unofficial Double NOP instruction on NES)
There is also a PPU emulator for PCEngine/TG16 comes with NES2PCE Conversion patches, It may help, but needs rewriting for it to work:
http://pcedev.wordpress.com/downloads-and-links/Make sure the author is credited for his work, He needs support.
Patrick FR wrote:
I wait for other comments on this and if it is positive I will change the assembler to bass and release what I have on sourceforge.
Okay!
Hamtaro126 wrote:
few games such as Puzznic aren't compatible opcode-wise without extended hacks (uses the unofficial Double NOP instruction on NES)
I haven't traced into Puzznic myself, but I seem to remember that one being opcode $89 when
they talked about it on tasvideos. On the 65816, that has become BIT #$ii, which is very much like a 2-byte NOP except it modifies the N, V, and Z flags. So unless it does the 2-byte right before a branch, it should still work.
Patrick FR wrote:
With WLA I must very often specify rep sep for 16/8 bit instructions. And it is not clear to me how we can specify that a chunk of code is 16 or 8 bit without using a rep/sep. I had many bugs because I expected 16bit instructions and got 8.
Assemblers such as x816 (yes that's the name) have a pseudo-op called ".DETECT ON" which will automatically adjust the size of the assembled results based on current SEP/REP bits. Per x816's documentation:
Code:
.DETECT
Toggle bitlength detection. (default is off)
X816 is capable of automatically detecting the changes in
bitlengths. When enabled any use of forced bitlength
extensions or used of the REP/SEP instructions will change
the bit lengths for the accumulator and indexes within
the assembler.
Examples:
.detect ; report detect on or off
.detect on ; enable autodetection
.detect off ; disable autodetection
You can also use .MEM and .INDEX to force the size if you want, but .DETECT tends to do the Right Thing(tm). Remember: it's an assembler, not an emulator, so it only traces SEP/REP sizing linearly.
I've used x816 for quite some time to write both 65816 and 6502 (NES) code. Since it's a 65816 assembler, when writing 6502 code I just have to remember (mentally) which opcodes aren't valid on the 6502. One which often snags me is INC (implied), which was introduced on the 65c02.
Anyway, maybe x816 can help make your life easier. Of course, source for x816 isn't available, it's DOS-only (not even Win32), and Normal Yen (author) has been long gone from the "scene". Version 1.12f is the latest.
koitsu wrote:
Assemblers such as x816 (yes that's the name) have a pseudo-op called ".DETECT ON" which will automatically adjust the size of the assembled results based on current SEP/REP bits.
Likewise ca65 has
.smart.
Bass is open source, therefore we can add things if needed.
If a rom uses undocumented opcodes, it will trigger an error message. I do not think that many programs will use undocumented instructions. I think programs are much cleaner on Nintendo hardware than on C64.
In SMB we have a branch on weird code but it is unused.
I'd Use macros in place of the .A and .I directives, since BASS never had it: replace all REP and SEP (8/16bit flags) to make new better macro commands setting!
Examples:
Code:
define A_mode $10
define I_mode $20
define IA_mode $30
//Comments use the same format as C/CPP format
//
//This macro sets a selected reg to 8 bits.
macro set8bit
sep #n
endmacro
//This macro sets a selected reg to 16 bits.
macro set16bit
rep #n
endmacro
//Usage Example:
//set A to 8 bits
//{set8bitmode A_mode}
//set Index (X and Y) to 16 bits
//{set16bitmode I_mode}
Another Question: Can One Simulate Some mappers (while hacking the ROM a bit) when copying via the MVN opcode from any ROM address to 7E8000-$7EFFFF in RAM depending on a value?
If so, It is easy to use MMC1, UxROM, CxROM, AxROM as well as NROM from there
Example:
Code:
define Amount $4000
SwitchBank0:
rep #$30 ; A and I = 16-bit
ldy #$8000 ; Y = Source Bank
ldx #$8000 ; X = Destination Bank
lda #Amount ; A = transfer amount (<$8000)
; This is Right? Correct if not:
mvn $82, $7E ; transfer the amount, ($82:8000-BFFF -> $7E:8000-BFFF)
rtl
;add more switching, etc
The slowest bankswitch among common mappers is probably MMC1 at 64 or so cycles. MVN takes a lot longer than that.
tepples wrote:
The slowest bankswitch among common mappers is probably MMC1 at 64 or so cycles. MVN takes a lot longer than that.
I guess not...
I will leave the user on thier own for mapper options then.
To Byuu: Maybe I can ask if you can make banks possible via XML (the SNES 20-in-1 pirate is one, info availible @ d4s's site).