How to link two games in a single ROM?

[+DZ-Jay]

I have a hypothetical question.  This is a completely fictional scenario.  Really.  I'm just asking for a friend.

 

Suppose my friend made a game some time ago.  Let's call it, "Winter Wendy meets The Spirit Of Giving."  Then also suppose that in the intervening years he made a lot of changes and enhancements to his game.  Now suppose further that he wanted to release this new enhanced version of his latest "Winter Wendy" game.

 

In this utterly imaginary scenario, this friend of mine decides that he wants to release his new "Winter Wendy Special Edition" game and include in it the original "Winter Wendy" game -- as is -- unaltered, just as it was originally released, hypothetically, a few years back.

 

What would be the simplest, easiest strategy to do this sort of thing without having to re-engineer the entire thing from scratch?

 

My first thought -- er, I mean, my friend was thinking that "bank-switching" would obviously play a role in this solution.  However, there are a few other issues that concern him.  For instance, the new (fictional) "Special Edition" is based on the original (and hypothetical) "Winter Wendy" source code, so they share quite a bit of the symbol namespace.  The implementation of procedures may have changed, but most of their names collide.  Obviously I won't -- er -- he won't be able to assemble both sources together in one go, unaltered.

 

Ideally there would be a linker that would take both ROMs and layered them, but as far as my friend knows, that does not exist.

 

Any suggestions from the experts on how best to tackle this, would be greatly appreciated.  My friend is very serious about his hypothetical programming fantasies, and would like to start imagining a proper solution to this completely fictional problem soon.  Preferably -- and for no special reason at all -- before the next Winter Season.  My friend is weird that way.

 

Thanks in advance!

 

     -dZ.

Edited August 15, 2021 by DZ-Jay

[+DZ-Jay]

Hmm ... nobody has suggestions? ?

 

Anyway ... in this totally fantastic, make-believe situation, er, my friend managed to implement bank-switching, so now his new (hypothetical) special edition of "Winter Wendy," with its new (fictional) levels and bonus stages, fits comfortably within the memory space, and still have some space left over for new animated cut-scenes.

 

Or at least that would be the case, if this was for real.  ?

 

Still need to find a way to incorporate the original "Winter Wendy" game with minimal effort.  The plan is to release both games in one cartridge.

 

Anybody has ideas?

 

   dZ.

Edited August 22, 2021 by DZ-Jay

[artrag]

Maybe you could rename all symbols in the first source by adding a _ or another prefix by search and replace.

A batch having in input the original symbol list and the source maybe could be feasible 

[+DZ-Jay]

So, having gotten bank-switching down, I have decid … my friend has decided to do something similar to what the Go For The Gold cartridge intended to do:  stitch together the original ROM of … er … Winter Wendy (*ahem*), to the new Special Edition binary, and modify the CFG file to map the original game memory address space to higher banks.

 

Then, implement an option to select the new or the original game during start-up, and switch banks accordingly.

 

I suppose this sounds easier and simpler than how it actually is, so can anybody provide any guidance on what needs to be done to have that work?  Any caveats or preparations would be helpful.

 

   dZ.

[Mik's Arcade]

haha, this topic is hilarious, best of luck.

 

I bet Oscar is working on this for you. If anyone can solve your.....errr.....ummmm....friend's problem, it is Oscar

[+DZ-Jay]

1 hour ago, Mik's Arcade said:

haha, this topic is hilarious, best of luck.

 

I bet Oscar is working on this for you. If anyone can solve your.....errr.....ummmm....friend's problem, it is Oscar

Well, it's not really an IntyBASIC program.

 

That said, any help from @nanochess or any of the other veterans will be welcomed! :)

 

    -dZ.

[Zendocon]

On 8/22/2021 at 11:28 AM, DZ-Jay said:

Hmm ... nobody has suggestions? ?

Sorry.  I just know I did everything by hand when I integrated Robots into SameGame, way back in 2004.

[+nanochess]

28 minutes ago, DZ-Jay said:

Well, it's not really an IntyBASIC program.

 

That said, any help from @nanochess or any of the other veterans will be welcomed!

 

    -dZ.

Hahaha finally I graduated to a veteran, although I think DZ-Jay was in the forums way a lot of time before me.

 

For an assembly program I would make a list of all the segments used. I would free the $5000-$6fff segment, make a menu, and then add the new program in the free space remaining in segments.

 

Probably I would rename all the labels in the original program with OLD_* labels.

 

I would do this way because I would hope that the original program wouldn't change.

 

[+DZ-Jay]

Just now, Zendocon said:

Sorry.  I just know I did everything by hand when I integrated Robots into SameGame, way back in 2004.

I understand, but I do not know what it entails to do it manually either.  So, any suggestions on how to do it would help.

 

For example, do I need to pad the ROM segments on both binaries to align before concatenating them together?  Or can I use them as they are.

 

(Note that both ROMs utilize the so-called “42K” memory map suggested by Joe Z., so they are scattered across 5 non-contiguous segments of varying size.)

 

   dZ.

[+DZ-Jay]

12 minutes ago, nanochess said:

Hahaha finally I graduated to a veteran, although I think DZ-Jay was in the forums way a lot of time before me.

 

Ah, yeah, I guess I am also a veteran, but a dummy one.

 

Quote

For an assembly program I would make a list of all the segments used. I would free the $5000-$6fff segment, make a menu, and then add the new program in the free space remaining in segments.

 

Hmmm.  I see.  So you would incorporate the new program into the old one.

 

I was thinking doing it in reverse:  Incorporating the old program into the new one.

 

Right now, they both exist as separate branches in the source tree.

 

Quote

Probably I would rename all the labels in the original program with OLD_* labels.

 

I would do this way because I would hope that the original program wouldn't change.

 

I was kind of expecting not to touch the old one at all.

 

In fact, I was hoping to just take the already released production ROM binary — as is — and just somehow stitch it into the new program.

Part of the reason is that the tools (assembler, etc.) have changed over the years, and there may be some things that break with such an old source.  I remember a couple of changes to the assembler that broke P-Machinery back a few years ago, and, hmm, my friend says that the original Winter Wendy is almost 10 years old.

 

Unless you think that building them together like you suggested would be easier.  There are a ton of symbols, though.  Christma Winter Wendy is a  very plump lady.

 

   dZ.

Edited September 14, 2021 by DZ-Jay

[+nanochess]

17 minutes ago, DZ-Jay said:

In fact, I was hoping to just take the already released production ROM binary — as is — and just somehow stitch it into the new program.

This cannot happen in our multiverse absolute addressing relocation done manually is a P**n in the *ss.

 

17 minutes ago, DZ-Jay said:

Part of the reason is that the tools (assembler, etc.) have changed over the years, and there may be some things that break with such an old source.  I remember a couple of changes to the assembler that broke P-Machinery back a few years ago, and, hmm, my friend says that the original Winter Wendy is almost 10 years old.

 

Unless you think that building them together like you suggested would be easier.  There are a ton of symbols, though.  Christma Winter Wendy is a  very plump lady.

 

   dZ.

It is cumbersome, but reassembling the original source with new tools is the way.

[+DZ-Jay]

4 minutes ago, nanochess said:

This cannot happen in our multiverse absolute addressing relocation done manually is a P**n in the *ss.

 

Hmm … Imagine — just for a moment — that I know very little about linkers and address mapping (hehehe) … How then does the Go For The Gold trick that Joe Z. mentioned in another thread, work?  (Where he just concatenates the binaries and modifies the CFG file?)

 

Obviously I’m missing something (which is why I’m asking here).

 

Keep in mind that I have not only the original binary in ROM and BIN+CFG file, but the source, assembly listing, symbol table, CPU map file, etc.; and I’m pretty handy at writing parsers and such tools.

 

If I wanted to do something like the Go For The Gold trick, what would I need to do?  I just want to understand the full complexity of it, in case it turns out to be a fun side project. (I’m always on the lookout for new things with which to procrastinate. )

 

Most likely, it’ll be an absolutely scary ordeal, and I’ll just take your suggestion anyway.  So, win-win either way.

 

4 minutes ago, nanochess said:

It is cumbersome, but reassembling the original source with new tools is the way.

Gotcha.

 

Thanks for all the suggestions.  I’m collecting all this information for the future.  Right now, I’m focusing on finishing the special edition and cramming all the new content and stuff into it.  Once that is done, then I’ll come back to this, and hopefully the best strategy would be clear to me then. 

 

Or … er … I mean … my friend is grateful for all the help, and says that it helps him fantasize about a hypothetically release of his imaginary game. 

 

   dZ.

[+DZ-Jay]

This is what I am referring to.  What is needed for it to work on non-Mattel titles?

 

I thought I needed to know the offset of where the second ROM started and map its segments.

 

I guess if the segments were padded to their boundaries it would be easier to find their offsets for the CFG address map, but on a pinch, I could write a script to compute that for me by scanning the listing file or something like that.

 

But of course, I’m out of my depth here, so if I’m way off the mark, please tell me.

 

  dZ.

Edited September 14, 2021 by DZ-Jay

[+DZ-Jay]

I've been thinking about this, and putting together in my mind all the notes on bank-switching and memory allocations scattered around, and I have a theory.  Here's how I think this could work.  Please let me know if this is wrong.

 

• Working on the new game code, I will add a menu selector in the $5000 address segment to switch to the appropriate ROM pages.  The ROM segments in use by this program will be at page $0.
• I build the program into a BIN+CFG, which will include the mapping to the ROM segments in page $0.
• I then take the old ROM from the original game, and using the CFG file, adjust the address mappings starting from the end of the new ROM.  These will map the segments to higher ROM pages.
• I then concatenate both ROMs together, the new one first, the old one second.
• I then add the adjusted CFG file mappings to the new game's CFG file.

Does that sound about right?

 

    -dZ.

[+Lathe26]

On 9/14/2021 at 12:26 PM, nanochess said:

This cannot happen in our multiverse absolute addressing relocation done manually is a P**n in the *ss.

Ok, the extra censoring of "p**n" made me substitute a much worse word than intended.  ??

[+nanochess]

22 hours ago, DZ-Jay said:

I've been thinking about this, and putting together in my mind all the notes on bank-switching and memory allocations scattered around, and I have a theory.  Here's how I think this could work.  Please let me know if this is wrong.

 

• Working on the new game code, I will add a menu selector in the $5000 address segment to switch to the appropriate ROM pages.  The ROM segments in use by this program will be at page $0.
• I build the program into a BIN+CFG, which will include the mapping to the ROM segments in page $0.
• I then take the old ROM from the original game, and using the CFG file, adjust the address mappings starting from the end of the new ROM.  These will map the segments to higher ROM pages.
• I then concatenate both ROMs together, the new one first, the old one second.
• I then add the adjusted CFG file mappings to the new game's CFG file.

Does that sound about right?

 

    -dZ.

I don't see this including a relocation of addresses of the original game. So it would break.

 

I mean, the CFG file only changes the target address when loading the binary pages of ROM, but the code still will refer to the old addresses.

 

 

[carlsson]

47 minutes ago, Lathe26 said:

Ok, the extra censoring of "p**n" made me substitute a much worse word than intended.  ??

I'm sure the sentence you formed in your head could be sung to the tune of Candle in the Wind by Elton John. And we leave it there.

[+DZ-Jay]

41 minutes ago, nanochess said:

I don't see this including a relocation of addresses of the original game. So it would break.

 

I mean, the CFG file only changes the target address when loading the binary pages of ROM, but the code still will refer to the old addresses.

Aren't the old addresses in the original game still valid, though?  I mean, the CFG tells which parts of the binary to load to which segments, and the segments remain the same ... they are just in different pages.

 

What I mean is, say the old game has an instruction that points to $2100.  The CFG would have something like:

[mapping]
; The new game maps ROMSEG 3 ($2000-$2FFF) to Page A
$2000 - $2FFF = $2000 PAGE A

; The new game maps its own ROMSEG 3 ($2000-$2FFF) to Page F
; Only that its actual position in the binary is offset by
; the size of the new game.
; $XXXX = $2000 + word_size_of_new_game_rom
$XXXX - $YYYY = $2000 PAGE F

 

As long as the block within $XXXX - $YYYY is loaded into $2000 by bank-switching, all addresses in the game will still work, no?

 

My understanding of the CFG mapping is that it takes the word position in the binary and maps it to a logical address space.  The game code itself references this address space (not the physical position in the binary file).  Is this not correct?

 

    -dZ.

[+nanochess]

Just now, DZ-Jay said:

Aren't the old addresses in the original game still valid, though?  I mean, the CFG tells which parts of the binary to load to which segments, and the segments remain the same ... they are just in different pages.

 

What I mean is, say the old game has an instruction that points to $2100.  The CFG would have something like:

[mapping]
; The new game maps ROMSEG 3 ($2000-$2FFF) to Page A
$2000 - $2FFF = $2000 PAGE A

; The new game maps its own ROMSEG 3 ($2000-$2FFF) to Page F
; Only that its actual position in the binary is offset by
; the size of the new game.
; $XXXX = $2000 + word_size_of_new_game_rom
$XXXX - $YYYY = $2000 PAGE F

 

As long as the block within $XXXX - $YYYY is loaded into $2000 by bank-switching, all addresses in the game will still work, no?

 

My understanding of the CFG mapping is that it takes the word position in the binary and maps it to a logical address space.  The game code itself references this address space (not the physical position in the binary file).  Is this not correct?

 

    -dZ.

That would be correct if you are using bank switching in exactly the same addresses.

 

Still you would have the problem at the boot up segment on $5000-$6fff. You would have to patch it to jump to your menu, or also make it bank switchable.

 

I don't remember if LTO-Flash supports bank switching in all pages.

 

[+DZ-Jay]

1 minute ago, nanochess said:

That would be correct if you are using bank switching in exactly the same addresses.

Yes, that's the point, I am.  Sorry, I guess I was not very clear on that.  I am using CART.MAC, which sets up a 42K memory map, and both versions of the game use it the same way.

 

I have modified it slightly to support one dynamic ROM segment in the new game, that is only for bank-switching.  However, I was expecting to bank-switch the others to page 0 for the new game, and some higher page for the new one.

1 minute ago, nanochess said:

Still you would have the problem at the boot up segment on $5000-$6fff. You would have to patch it to jump to your menu, or also make it bank switchable.

Yes.

1 minute ago, nanochess said:

I don't remember if LTO-Flash supports bank switching in all pages.

Oh, yeah, good point!  Hmm ... I'll have to look into that.  I agree, that is the question:  if bank-switching is not allowed in any of the segments, I'll have to look into your other suggestion.

 

Thanks for all the help! :)

 

    -dZ.