Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Convert .NES into .SMS ROM File?

Reply to topic
Author Message
  • Joined: 18 Feb 2018
  • Posts: 4
Reply with quote
Convert .NES into .SMS ROM File?
Post Posted: Fri Dec 07, 2018 9:39 pm
Hello all!

I was wondering if there is a way to change an NES ROM into an SMS ROM? Odd request, but I thought I would ask the guys that would probably know.

Thanks for your time.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Fri Dec 07, 2018 9:52 pm
No, that would be impossible.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 278
Reply with quote
Post Posted: Sat Dec 08, 2018 8:14 am
No, there is absolutely no hardware similarity at all.
Any attempt at a port would have to be a complete from scratch job.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 515
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sat Dec 08, 2018 10:43 am
Well... you could, technically, write an emulator that would run on the SMS... it would run at one frame per *minute* and have lots of limitations. :P

The problem is not so much the CPU (though that does contribute), but the differences between the video hardware; the NES supports sprite flipping, while the SMS does not, the NES does not support BG tile flipping, while de SMS does... plus the way the palettes are handled is pretty different, too. It would be possible to rewrite the tiles on the fly to make up for the pallete and sprite flipping issues, but unless the game was absurdely simple, you would quickly run out of tiles, not to mention how slow it would be... maybe a more realiable way to emulate the PPU would be to arrange the SMS tiles as a all-pixels-adressable pseudo-framebuffer, then implement all the BG and sprite rendering from scratch; of course this would be even slower.

Essentially, it would be impractical.

I imagine it would theorethically be more realistic to create a NES emulator running on the Genesis; it has tile flipping both for the BG and the sprites, and the palette differences could be worked around by some smart use of tile duplication... keep in mind that its CPU would still not have enough "oomph" to emulate at full speed.

Also, someone made a NES emulator for GBC a long time ago; as expected, it's quite slow.
  View user's profile Send private message Visit poster's website
  • Joined: 16 May 2002
  • Posts: 1121
  • Location: italy
Reply with quote
Post Posted: Sat Dec 08, 2018 11:36 am
Well, Yuji Naka supposedly wrote a NES emulator for the Genesis.

Also, this.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 278
Reply with quote
Post Posted: Sat Dec 08, 2018 6:08 pm
haroldoop wrote

The problem is not so much the CPU (though that does contribute), but the differences between the video hardware; the NES supports sprite flipping, while the SMS does not, the NES does not support BG tile flipping, while de SMS does... plus the way the palettes are handled is pretty different, too. It would be possible to rewrite the tiles on the fly to make up for the pallete and sprite flipping issues, but unless the game was absurdely simple, you would quickly run out of tiles, not to mention how slow it would be... maybe a more realiable way to emulate the PPU would be to arrange the SMS tiles as a all-pixels-adressable pseudo-framebuffer, then implement all the BG and sprite rendering from scratch; of course this would be even slower.

The NES also supports 512 tiles (256 BG + 256 sprite) and also has separate RAM for tilemaps (normally the size of two screens, but a few games had extra RAM to allow four screens), sprites and palettes.
Whereas on SMS, the tilemap (I can't recall, is the SMS tilemap only the size of one screen or is it larger than the screen?), sprite data and palette I think all need some of the VRAM, which in practicality limits the SMS to 448 tiles.
Also, games which use CHR-ROM mid-frame bankswitching to effectively get around the tileset size limit would probably not be something feasible to emulate.
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 75
Reply with quote
Post Posted: Sat Dec 08, 2018 8:16 pm
KingMike wrote

The NES also supports 512 tiles (256 BG + 256 sprite) and also has separate RAM for tilemaps (normally the size of two screens, but a few games had extra RAM to allow four screens), sprites and palettes.
Whereas on SMS, the tilemap (I can't recall, is the SMS tilemap only the size of one screen or is it larger than the screen?), sprite data and palette I think all need some of the VRAM, which in practicality limits the SMS to 448 tiles.


Yeah the sms is nearly the size of the screen, depending on the VDP init, you get maybe 2 tile columns extended off screen on the left and right and I think 4 tile rows for an overscan on the bottom. The VRAM had 3 parts to it as well. palette 1 bank which uses 256 unique tiles, palette 2 bank has 192 unique tiles totaling to 448 tiles like kingmike said. The screen space which takes up technically 64 tiles.
The VDP is much different from the PPU and even of you could use some kind of code translator, you'd have to re program the video chip driver and bank code as well as fix any sprite tiles that use flipping.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2309
Reply with quote
Post Posted: Sun Dec 09, 2018 10:52 am
IllusionOfMana wrote
Yeah the sms is nearly the size of the screen, depending on the VDP init, you get maybe 2 tile columns extended off screen on the left and right and I think 4 tile rows for an overscan on the bottom. The VRAM had 3 parts to it as well. palette 1 bank which uses 256 unique tiles, palette 2 bank has 192 unique tiles totaling to 448 tiles like kingmike said.


The SMS tilemap is 32x28 tiles, so it's exactly the width of the screen (yes, you can hide the first column) and 4 rows more. As for the the 448 tiles total, that's the minimum, as there are surely more tiles available - two in the SAT 'gap' for instance, and up to 8 more if you don't need to scroll the background vertically, exploiting the unused tilemap space.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 75
Reply with quote
Post Posted: Mon Dec 10, 2018 4:26 am
sverx wrote

As for the the 448 tiles total, that's the minimum, as there are surely more tiles available - two in the SAT 'gap' for instance, and up to 8 more if you don't need to scroll the background vertically, exploiting the unused tilemap space.


Are there any games that go that far in using as much available tile space as possible? Also going back more onto topic a bit, is it possible to software flip sprites and if so is it possible without causing slowdown?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Mon Dec 10, 2018 8:11 am
Plenty of games max out the tile count, Phantasy Star for example goes above 448 by using the unused tilemap region and the sprite table "hole".

In our theoretical SMS ROM generator, we could simply store all the tiles flipped four ways. Flipping in software would probably be quite fast using a 256 byte lookup. However everything has some cost, nothing is going to be full speed anyway. In a generic SMS game, you might want to flip in software for some reason but again the impact on slowdown depends on what sort of flipping, whether you have the source data in ROM or RAM instead of VRAM, and how many you want to flip.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 45
Reply with quote
Post Posted: Tue Dec 11, 2018 2:07 pm
In addition to the many good points about graphics above: the joypad doesn't have enough buttons, and the audio would be really difficult to model: it offers a variety of duty cycles, which the SMS does not, plus a PCM channel. So prima face you'd need a busy loop just to play back the same audio.

... and just as the issue raised above about cartridges potentially extending graphical abilities via extra on-cartridge hardware, some also add extra sound generators into the mix.

The NES as a console is really quite distinct from most other platforms because of the proportion of things that games achieve only through extra hardware, and that hardware's diversity. Not just graphical, but in general.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 278
Reply with quote
Post Posted: Tue Dec 11, 2018 5:50 pm
Another problem is the palette could come into play.
While the SMS palette of 15+transparancy is larger than the NES' 3+transparancy, the thing is to have two palette-swapped sprites on the screen (I'm sure that's been done for some two player games), for SMS you would need to create two versions of the sprite with the different colors? As in, hope you have room for duplicate tiles?

Maybe you could get around it with split-screen games by doing a mid-frame palette change, but two palette-swapped characters similtaneously in the same frame would require dupe tiles.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Tue Dec 11, 2018 6:38 pm
Palette swapping enemies was very common, and indeed on SMS you can't do that without having more than one copy.

I think we can comprehensively say that NES <-> SMS is far from simple, let alone something that could be automated.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2309
Reply with quote
Post Posted: Wed Dec 12, 2018 10:15 am
KingMike wrote
Another problem is the palette could come into play.
While the SMS palette of 15+transparancy is larger than the NES' 3+transparancy, the thing is to have two palette-swapped sprites on the screen (I'm sure that's been done for some two player games), for SMS you would need to create two versions of the sprite with the different colors? As in, hope you have room for duplicate tiles?

Maybe you could get around it with split-screen games by doing a mid-frame palette change, but two palette-swapped characters similtaneously in the same frame would require dupe tiles.


A nice trick may be to have a differently colored sprite 'below' a sprite that has transparency on those pixels where you want the underlying color to appear. Think of a car's rooftop or similar - but yeah, this has its limits too, and increases both sprite count and sprite per line count.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Wed Dec 12, 2018 10:56 am
Or put the coloured sprite on top. Micro Machines does this to allow it to share the car sprites while overlaying a per player colour. The NES version indeed can use palette swaps to change the colour of whole cars.

The problem is that this increases pressure on the sprite limit, and again would be hard to automate as you need to pick out exactly which pixels to change and which to leave transparent.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2309
Reply with quote
Post Posted: Wed Dec 12, 2018 3:31 pm
Maxim wrote
[...]would be hard to automate as you need to pick out exactly which pixels to change and which to leave transparent.


That's why I thought about putting it behind, to use the sprite on top also as a mask... of course this doesn't work in any situation.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Aug 2012
  • Posts: 283
  • Location: Porto, Portugal
Reply with quote
Post Posted: Thu Dec 13, 2018 7:38 pm
seeing people disassembling nes games and converting these extracted assembly sources to sms wouldn’t surprise me, at all... - anyway, would be great seeing a lot of people trying it - who wouldn’t want to play a version of super mario on sms looking and feeling just like nes version? and seeing how surprising were these recent zx-spectrum versions of kung fu master and rally-x (okay, zx-spectrum and these original arcade machines are all z80), which obstacles would have converting nes games to sms in a similar way?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Thu Dec 13, 2018 8:59 pm
The CPUs are very different, a mechanical translation would have terrible performance. You'd still need to basically rewrite the graphics and audio engines. Many games just aren't technically possible to port as-is, you'd have to make some changes to make it fit the limitations.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Aug 2012
  • Posts: 283
  • Location: Porto, Portugal
Reply with quote
Post Posted: Fri Dec 14, 2018 12:12 am
Maxim wrote
The CPUs are very different, a mechanical translation would have terrible performance. You'd still need to basically rewrite the graphics and audio engines. Many games just aren't technically possible to port as-is, you'd have to make some changes to make it fit the limitations.


it depends a lot, for example just compare Antarctic Adventure versions, nes with msx1/colecovision , how they are so similar each other

of course the differences between both machines are huge, but i believe some huge effort can be made on these remakes almost from scratch (not merely "conversions")

Duck Hunt is a great example of a nes game remade for msx1

(i’m mentioning msx1 and colecovision for the similarity they have with sg1000)

I imagine that such remakes of nes game to sms would need to have similar development aproach
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Fri Dec 14, 2018 6:39 am
If the conversion is based on the exact gameplay logic because you have access to the design docs and artwork then it's easy to look very similar without it being an exact conversion. Even with access to the source, people tended to rewrite rather than try to convert assembly line for line.
  View user's profile Send private message Visit poster's website
  • Joined: 30 Mar 2009
  • Posts: 268
Reply with quote
Post Posted: Fri Dec 14, 2018 11:13 am
If any one wants some insight on how these conversions used to be done, i highly recommend reading: "it's behind you" by bob pape.

It's a book he wrote about porting R-Type for the ZX Spectrum.
He goes into detail about sprite handling, routines, sound, etc. Very interesting read.

And, it's free.

http://www.bizzley.com/
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 45
Reply with quote
Post Posted: Sun Dec 16, 2018 1:05 pm
tibone wrote
If any one wants some insight on how these conversions used to be done, i highly recommend reading: "it's behind you" by bob pape.

It's a book he wrote about porting R-Type for the ZX Spectrum.
He goes into detail about sprite handling, routines, sound, etc. Very interesting read.

And, it's free.

http://www.bizzley.com/


I followed this advice and read it last night; it's a two-hour read, some technical details — especially on software rendering, smooth scrolling and colour clash, and a little on sprite multiplexing on the C64 side — but mostly practicalities and the sheer amateurism of management, with a guest appearance by criminality, that he endured on that particular project. With lots of mentions of Fareham, Reading, etc, that you'll enjoy if like me you're from that sort of area. Just don't read it if you're the sort of person who gets into a rage about apostrophes.

I would also recommend it: it's easy enough to read the stories of those who managed to combine programming talent with business acumen, like Ultimate Play the Game or David Braben, because they managed to acquire the proper spoils; this is more about how thousands of more naive others experienced the home computer game industry.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 75
Reply with quote
Post Posted: Fri Dec 28, 2018 4:39 pm
So, NES (or c64) to SMS is a rather difficult if not impossible conversion without near total rewrite of the game. How about Gameboy Color to SMS and vice versa? Correct me if I'm wrong, I believe the Gameboy color uses a modified z80 architecture but retained most of the z80 instruction set. How difficult would it be to make the conversion?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2309
Reply with quote
Post Posted: Fri Dec 28, 2018 7:27 pm
I've read the GB processor's instruction set is halfway between the Zilog Z80 and the Intel 8080, a subset of the Z80 I mean.
So it would require at least to recompile using some macros to substitute the unsupported instructions - of course we're addressing only the CPU here, as the rest of the hardware isn't so similar.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12513
  • Location: London
Reply with quote
Post Posted: Fri Dec 28, 2018 7:36 pm
Many games were developed with a single codebase for GB, GG and SMS in the 90s. The GB-Z80 is almost compatible, but you would need to mechanically replace some of the instructions. This still doesn't help with the primary problem: the sound and video chips are different in important ways which are central to the game functionality much of the time, and need dedicated code to adapt the game to the hardware. For example, GB has memory-mapped VRAM and supports a "window" which is often used for status bars, there's no easy way to emulate that on the Sega VDPs. It can also do sprite flipping.

Having said that, I suspect an enterprising individual could port some of the heavily disassembled games (eg. Pokémon) to Sega consoles.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 515
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Fri Dec 28, 2018 10:02 pm
As others already mentioned, GB-Z80 is similar enough to standard Z80 that, as long as you have a proper assembly source, you could convert everything to Z80, either by using a conversion script or a set of ASM macros, as long as no absolute addresses nor self-modifying code is used.

The main problem is that the video/audio interfaces are completely different, meaning that, while you should be able to reuse the game logic with no problem, the graphics/sound routines will have to be rewritten.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Aug 2012
  • Posts: 283
  • Location: Porto, Portugal
Reply with quote
Post Posted: Sat Dec 29, 2018 9:03 pm
talking about converting GameBoy games to z80-based hardware, i guess someone converted (looks more as conversion than remaking) Ninja Gaiden to ZX-Spectrum - http://www.indieretronews.com/2018/01/ninja-gaiden-shadow-warriors-gameboy.html
  View user's profile Send private message Visit poster's website
  • Joined: 01 Aug 2012
  • Posts: 283
  • Location: Porto, Portugal
Reply with quote
Post Posted: Sat Dec 29, 2018 9:11 pm
(btw, a lot of people keep insisnting on saying that GameBoy is a z80-based hardware when never was - lr35902 is based on 8080 with some few z80 extended opcodes - it totally lacks ix and iy registers, ldir and etc. - we all never should say it’s a z80 when it totally lacks what makes z80 a z80)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2309
Reply with quote
Post Posted: Sun Dec 30, 2018 6:04 pm
Gameboy as said has no Z80 or i8080 - but you can call its processor a 'simplified' (opcode wise) Z80 or an 'expanded' Intel 8080, it's all about the point of view.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!