Cross Platform development?

[Psycho Punch]

I kinda want my next NES project to be developed alongside a PCE version since I'm sure I'm going to be too damn lazy to port everything when the game is done. I was thinking about this a lot lately and I want to hear any ideas to make this viable.

As you already know the PCE is basically backwards compatible with NES binaries (of course the NES doesn't have all that PCE fancyness that is the internal bankswitch facilities, T mode, Set Decimal, etc.) so you would think it would be trivial to develop for both machines at once. But...

1. The video hardware is totally different from one another, it's not going to be trivial to port video related subroutines to the PCE, and good lord if you're trying to do fancy special effects.

2. Anything past 64 kb might complicate how you handle bankswitching for both consoles.

3. Music engine: I really have no idea what I'm doing with sound hardware and the only reason why my previous game had sound and music was because there was a Public Domain engine that I could use. This means that I'll have to make the same music twice, not to mention the hardware differences...

4. CD access vs. Nanosecond ROM access. If there's something in the NES game that requires a lot of bankswitching in a short amount of time that means that a CD port might not be viable.

5. There's high level C compilers for both machines but I'm sure that it would probably be much more incompatible with each other than anything in ASM


Do you guys think this is feasible, and any tips you can throw at me so I don't kill myself trying to do this?

(Koei had a shit ton of cross platform games involving all 8 and 16 bit consoles but I really have no idea how they did, I'm willing to bet that it's all interpreted code though.)

[OldMan]

so you would think it would be trivial to develop for both machines at once

Too bad bonknauts isn't still around. He did the megaman port, and had information about how
to convert things from the NES to the PCE. That would at least give you a place to start from.

I also wouldn't worry much about loading from CD vs ROM, at least to start with. You might be able
to load everything all at once, if you stay below 256K (or maybe 512K, I forget) with the system 3
card.

Other than that, I can only suggest trying to keep the hardware-specific stuff behind a well-defined
set of library functions. Things that can then be swapped for the different system builds

[Arkhan Asylum]

If you are going to do multiplatform music, consider MML, and try writing it for NES first, and then bringing to PCE where you get extra channels and can expand upon it.

MML is a portable(ish) music language.  You won't have to do TONS of work when going from platform to platform.

There exists PPMCK, and HuSIC, in addition to Squirrel for MML.   I am sure someone has to have written an MML player for NES that can be used in a game project.


I don't do NES dev but I would imagine they have libraries available.  What you might want to try doing is gathering both PCE and NES C libraries, and creating a layer above them that is toggled at compile time to pick which library call to make.    Or, the messier and probably required approach (because of video hardware differences and such), would be #def'd blocks to pick which code is used at compile time.

Microcabin released games on multiple machines, and it seems they wrote an intermediate language and had interpreters for various platforms, similar to what you're suggesting Koei did.   

[touko]

2. Anything past 64 kb might complicate how you handle bankswitching for both consoles.

bankswitching on the PCE is really easy and to have all in 8k banks help a lot .

[gilbert]

Hudson itself used an scripting language called IV in their PCE games, which was used extensively in especially games that speed is not the most concerned, like adventure games or RPGs (first or third party ones, doesn't matter, as it's in their official development kit AFAIK). With this they could easily design game events and data structures without using much assembly, just by using a parser/interpreter engine while executed. Without this, HUGE games such as Far East of Eden II simply couldn't be made.

I don't know whether they used IV in their Famicom (or even Super Famicom) games but it is a possibility, as they only need to have written parser engines on different systems so as to (re)use data formated similarly, especially most of the official development tools on the PCE were cross-platform supporting both Famicom and PCE (internal ones used by Hudson at least, the tools they provided 3rd party developers had the Famicom support removed so as not to confuse them).

[Gredler]

Have I glossed over how art is made and handled? I imagine you would need a lot of separate art assets

[TurboXray]

How are you going to approach this? Are you going to have core code that's executable on both machines? I.e. shared source files. How are going to approach this compiler wise? Using CC65?

Honestly, depending on the size of this project, I would write a simple pre-processor that builds assets defines for the corresponding package (header for NES rom, tile format in bin, etc). Maybe even forces optimizations for PCE size (like force ZP addressing for certain labels if it's PCE option to compile). Write the pre-processor in whatever language you're comfortable with -> spits out a modified source code file(s) to be compiled.

[touko]

Hi tom, glad to see you again 

[TurboXray]

Hudson itself used an scripting language called IV in their PCE games, which was used extensively in especially games that speed is not the most concerned, like adventure games or RPGs (first or third party ones, doesn't matter, as it's in their official development kit AFAIK). With this they could easily design game events and data structures without using much assembly, just by using a parser/interpreter engine while executed. Without this, HUGE games such as Far East of Eden II simply couldn't be made.

I don't know whether they used IV in their Famicom (or even Super Famicom) games but it is a possibility, as they only need to have written parser engines on different systems so as to (re)use data formated similarly, especially most of the official development tools on the PCE were cross-platform supporting both Famicom and PCE (internal ones used by Hudson at least, the tools they provided 3rd party developers had the Famicom support removed so as not to confuse them).

That's pretty cool! I didn't know this. I messed around a few years ago where I made a simple scripting engine on the PCE side that allowed you to build a horizontal shmup. The script was interpreted in realtime. It was pretty fun. I could do low level stuff too, like load(tileset_label, length, vram_Address). I had slow versions, fast versions, etc. I could control speed across the level, linear, exponential, log, etc. Stop the scrolling, initialize events, etc. Set when an enemy would appear on the map either by time marker or by location marker (what point in the autoscrolled level you reached). It made tweaking and designing the levels much faster and easier. The script allowed for "parallel" commands via a queue, as well as priority level setting. I was going to introduce subscripts as well, say for when a dramatic scene was to happen in the background or foreground, but called simply by its label name -> basically run another instance of the interpreter to handle that sub-script for that scenario.

[Psycho Punch]

Thanks for the suggestions, I'll try to port my finished breakout-like game to the PCE first to see how much portable code can I keep between consoles. My game has a pretty rustic "scripting" system that kind of separates NES specific routines already:

https://github.com/AleffCorrea/BrickBreaker/blob/master/state.asm

(keep in mind that most of the code was rushed so there's going to be a lot of stupid stuff in it, don't judge me )

so you would think it would be trivial to develop for both machines at once

Too bad bonknauts isn't still around. He did the megaman port, and had information about how
to convert things from the NES to the PCE. That would at least give you a place to start from.

I also wouldn't worry much about loading from CD vs ROM, at least to start with. You might be able
to load everything all at once, if you stay below 256K (or maybe 512K, I forget) with the system 3
card.

Other than that, I can only suggest trying to keep the hardware-specific stuff behind a well-defined
set of library functions. Things that can then be swapped for the different system builds

I special summoned the banished Bonknuts into the board again, don't worry. And you're right about the CD, but since I want to maybe make some enhancements like extra graphical assets, cutscenes, audio samples, etc. we'll see if 256k will be enough. As for hardware specific stuff my previous game kind of does that somewhat.

If you are going to do multiplatform music, consider MML, and try writing it for NES first, and then bringing to PCE where you get extra channels and can expand upon it.

MML is very nice for this, I don't know if there's a NES MML library with a decent license but if there isn't it would be a nice excuse to finally start learning about the console's music hardware instead of just letting third party code take care of it.

I don't like the C stuff in the PC Engine Magickit and I think that the NES equivalent has even more limitations, but maybe I should give it a serious look later.

Have I glossed over how art is made and handled? I imagine you would need a lot of separate art assets

You can always go full lazy and just use the 4 color art of the NES version as is

How are you going to approach this? Are you going to have core code that's executable on both machines? I.e. shared source files. How are going to approach this compiler wise? Using CC65?

Honestly, depending on the size of this project, I would write a simple pre-processor that builds assets defines for the corresponding package (header for NES rom, tile format in bin, etc). Maybe even forces optimizations for PCE size (like force ZP addressing for certain labels if it's PCE option to compile). Write the pre-processor in whatever language you're comfortable with -> spits out a modified source code file(s) to be compiled.

I'm using good old PCEAS.exe and NESASM, I see no reason to switch to "real" compilers at the moment. The pre processor idea sounds interesting, especially for setting up an automated pipeline for the project.

[gilbert]

That's pretty cool!

Actually Iwasaki's blog is a treasure of PCE development history, as he was a programming director in Hudson, involved with many CD projects, if you can read Japanese that is (I can read 60-70% of Japanese myself, the more Kanji the better), but web translation can help I think.

I don't know where he first started mentioning and explaining about IV, as I haven't read his enormous pile of articles yet, but it's mentioned many times in various places, that IV was extensively used (especially in CD games) and assembly codings were minimal. For example, he mentioned here about the assignment of programmers in a project, that starting from Far East of Eden II, they had one IV programmer writing IV scripts on a single state of the game (anyone played the game knew that it;s separated into various states/countries that you could travel around) so they probably had much more IV script writers than assembly coders.

[Psycho Punch]

Actually Iwasaki's blog

That's gold, thanks for sharing gilbert

[Psycho Punch]

ATTENTION DUELISTS:

1. I'm still trying to figure out what's my window for manipulating VRAM data. I heard that you can write/read data anytime, is that true? If so, what happens if I change a tile while it's being rendered in the current scanline?

I'll probably stick to writing during vblank for now (I don't even know how much cycles it lasts lol). Write outside of vblank in the NES and everything starts jumping up and down and your tiles get written randomly everywhere since the PPU reuses the registers you use to write to VRAM when rendering, it would be nice if that didn't happen here.

2. How can you rip tilemaps easily with MAME? Asking for a friend.

[OldMan]

I heard that you can write/read data anytime, is that true? If so, what happens if I change a tile while it's being rendered in the current scanline?

Yes, you can read/write 'anytime'. Dunno about during the active scanline, though. Never tried it.
I have, however, updated the vdc registers during the active scanline; sometimes if causes glitches
(like displaying the initial pixel, stretched over 2-3 pixels).
From what I remember, there are 'slots' for reading/writing, but I never really understood how it works.

I'll probably stick to writing during vblank for now

If you are going cross-platform, probably a good idea.

Afaik, the vdc registers are latches, with a seperate internal set for actual display.
You can check the tv signal specs if it really worries you. I *believe* the vblank period is at least 7 scanlines; I could be wrong there, though. (Raster irq value is 63 for first active display line, normally.
But I've never really been able to tell how much of that is the top blank area and how much is the
bottom)

I suggest you peruse the vdc register docs in the HuC stuff. There's a set of registers near the end that control the actual screen geomety; how many cycles each hsync/vsync pulse is, how many cycles
before the left edge of the screen, etc. I only vaguely understand that stuff - maybe you can explain it?

[Psycho Punch]

/tXaA15h.png

Another question: does anyone know what emulator actually supports debugging? I have bizhawk but the debugger doesn't work properly and it's just for show. Well at least I can see that the game managed to get to my character VRAM upload routine

I regret starting this but I can't give up until it's done. Wasn't revising my code to translate specific hardware code enough work already? Sigh

I only vaguely understand that stuff - maybe you can explain it?

If you don't understand, chances are I won't either
But I'll take a look.

[Psycho Punch]

:derpcat: :derpcat: :derpcat: :derpcat:

I got reminded of Mednafen and it's actually pretty decent for debugging purposes. Suddenly this became fun to do (!!!). So many bugs left to find, lmao. But as you can see the underlying logic is working semi correctly and building for the NES still works properly as it should.

/soZQ3sQ.png



EDIT: LOL I think I've figured out why there's a black stripe across the full screen fill and why the first column is also black: I'm probably writing the most significant byte of the tile first. Another bug slain, 9999999 more to go.

[OldMan]

I got reminded of Mednafen and it's actually pretty decent for debugging purposes....

Yes, it is. Make sure you go to the mednafen site and print out the debugger docs, so you
have it handy. There's a lot of nice things you can do with it.
And, as far as I'm aware, it's actually almost perfect emulation; if you see glitches when testing
in mednafen, you will almost certainly see the same glitches on real hardware.

If you don't understand, chances are I won't either
But I'll take a look.

At one time, I had a link to how the signal timing for NTSC video worked; how many pulses there were for various things, how long they needed to last, etc. I just didn't feel like working out exact timings in terms of how the pce did it.
I do remember being puzzled by how the values got set (in the bios routines), until I walked through the actual code. IIRC, they are set based on the center of the screen. So, in theory, it should be possible to come up with a higher Y resolution; I'm really interested in something other than nnnX240, but haven't found out how. Yet.

Maybe I'll look back into that soon.

And, for the record, I'm not an electrical guy. I'm a programmer. But sometimes you have to know these things. Or at least, sort of understand them when you google them.

[Psycho Punch]

/SdcF09I.png

Bugs fixed! Just need to un-dummy the PCE version of the sprite handling routines and RLE compressed backgrounds. (and get rid of that ugly ass palette for once)

I hope the game gets to this stage soon:

/qxBaV2d.png

I got reminded of Mednafen and it's actually pretty decent for debugging purposes....

Yes, it is. Make sure you go to the mednafen site and print out the debugger docs, so you
have it handy. There's a lot of nice things you can do with it.
And, as far as I'm aware, it's actually almost perfect emulation; if you see glitches when testing
in mednafen, you will almost certainly see the same glitches on real hardware.

I'm wondering if there are ways to load labels from the .sym file PCEAS generates into Mednafen. That would be useful (instead of having a second monitor with the file open searching for addresses lol.) I already have a nice cheat sheet printed out.

If you don't understand, chances are I won't either
But I'll take a look.

At one time, I had a link to how the signal timing for NTSC video worked; how many pulses there were for various things, how long they needed to last, etc. I just didn't feel like working out exact timings in terms of how the pce did it.
I do remember being puzzled by how the values got set (in the bios routines), until I walked through the actual code. IIRC, they are set based on the center of the screen. So, in theory, it should be possible to come up with a higher Y resolution; I'm really interested in something other than nnnX240, but haven't found out how. Yet.

Maybe I'll look back into that soon.

And, for the record, I'm not an electrical guy. I'm a programmer. But sometimes you have to know these things. Or at least, sort of understand them when you google them.

That's true, to this day I have no idea how to calculate exact Vblank time on the NES. I always use some conservative approximation (and you probably know how bad this is since it's so limited in that regard). Maybe it's time to actually try to understand that kind of stuff.

[OldMan]

I'm wondering if there are ways to load labels from the .sym file PCEAS generates into Mednafen.

Unfortunately not. I generally keep the .sym file open in an editor (well, actually the .lst file) and
flip to it when I need to. That way I can 'follow along' while debugging, and see the addresses for
any variables I might want to check.

Maybe it's time to actually try to understand that kind of stuff.

Yeah, but right now i'm finishing something else up.
The first thing I need to do is find the exact clock frequencies for the pce. From that I can start
working out the times for the various NTSC signal parts. (In terms of the pce clock(s) )

[esteban]

ASIDE: I fully support this awesome project (the brick game), because I know it will be a stepping stone towards BLODIA SPECIAL CD (forget about cross-platform, you want to target—as in limit—your potential audience to 3-4 humans and one really bored parrot).



/aside

[Psycho Punch]

ASIDE: I fully support this awesome project (the brick game), because I know it will be a stepping stone towards BLODIA SPECIAL CD

Edit: also, project stalled due to:

A: trying to find a good scheme to make data overlays since PCEAS complains whenever I add something larger than 32k instead of just spilling over the data to other 8kb banks
B: my keyboard's space bar is busted (again!)