Fluid simulation for new 2600 game concept

[JetSetIlly]

1 hour ago, Thomas Jentzsch said:

What kind of bankswitching is that? I would like to get it added to Stella.

It's the brand new ELF format. It's the same as the ELF binary format used on UNIX like systems.

 

The StrongARM functions will also need to be emulated but they're not difficult to implement.

 

It looks like this particularly binary limits itself to the Thumb instruction set but you should probably be prepared for "Thumb2" binaries too.

[JetSetIlly]

9 hours ago, 8bitPoet said:

BINARY (currently compatible with the Gopher2600 emulator, UnoCart, and PlusCart)
MattressMonkeys20240530rc4.bin

 

If anyone is trying this with Gopher2600 then I recommend that you enable the  "ARM Immediate mode".

 

Press F10 to open the preferences window and click on the ARM tab. The "Immediate ARM Execution" checkbox should be ticked.

 

 

For the technically minded, this just means that the emulation is not performing any cycle counting in the ARM emulation and can thus run a little quicker.

 

[Thomas Jentzsch]

1 hour ago, JetSetIlly said:

It's the brand new ELF format. It's the same as the ELF binary format used on UNIX like systems.

 

The StrongARM functions will also need to be emulated but they're not difficult to implement.

 

It looks like this particularly binary limits itself to the Thumb instruction set but you should probably be prepared for "Thumb2" binaries too.

We have UNIX expertise in the Stella team, but for the ARM stuff we would definitely need help. Else Stella will not be able to support these games.

[JetSetIlly]

24 minutes ago, Thomas Jentzsch said:

We have UNIX expertise in the Stella team, but for the ARM stuff we would definitely need help. Else Stella will not be able to support these games.

TBH, you probably won't need to support Thumb2, it's just that it's a theoretical possibility opened up by the UnoCart. The only ROMs that requires Thumb2 (including FPU emulation) are @MarcoJ's ACE games and demos.

 

With regards to ELF itself, there are probably C libraries with compatible licenses that you can make use of.

 

You probably have all the expertise you need already but if you do need any help I'm happy to offer it.

[Thomas Jentzsch]

1 hour ago, JetSetIlly said:

TBH, you probably won't need to support Thumb2, it's just that it's a theoretical possibility opened up by the UnoCart. The only ROMs that requires Thumb2 (including FPU emulation) are @MarcoJ's ACE games and demos.

 

With regards to ELF itself, there are probably C libraries with compatible licenses that you can make use of.

 

You probably have all the expertise you need already but if you do need any help I'm happy to offer it.

I will be asking most likely stupid questions:

• why do you use a special file format here?
• is there a tool to convert it to a binary?
• would that be Stella compatible?
• which bankswitching format is used for this game?
• ...?

Actually I am quite lost on this.

[JetSetIlly]

1 hour ago, Thomas Jentzsch said:

• why do you use a special file format here?

The problem with CDFJ and DPC+ as they exist today, is that binary files are specific to a particular architecture. In other words a DPC+ file that can run on the Harmony will not run on the PlusCart without first recompiling or patching.

 

The ideal solution would allow the ARM program to be agnostic about the specific memory architecture. Rather than invent a new "bank switching" scheme it was decided to use the ELF standard, which is an industry standard way of defining the rules governing what happens to a program during the process of loading into RAM.

 

1 hour ago, Thomas Jentzsch said:

• is there a tool to convert it to a binary?

The ELF file is the binary that executed on the cartridge. There's nothing else to convert to.

 

1 hour ago, Thomas Jentzsch said:

• would that be Stella compatible?

Yes. Provided that the ARM code has been compiled with only "Thumb" instructions. ARM programs that have been compiled to use the FPU for example, would require support to be added to the Stella ARM emulation. I don't expect many people would be using the FPU however.

 

1 hour ago, Thomas Jentzsch said:

• which bankswitching format is used for this game?

In my opinion, "bankswitching" is a misleading term in this case. There are no static areas of memory containing 6507 instructions and nothing to switch between.

 

The StrongARM method developed by @ZackAttack means that the ARM program runs in parallel with the 6507. There is no NOP state like there is with DPC+ and CDFJ. Put another way, we can say that the 6507 is never idle while the ARM program is running and that both CPUs are doing useful work at the same time.

 

Rather than NOPs, the ARM program feeds a constant stream of instructions to the 6507 by stuffing data onto the data bus. This is literally the bus stuffing that people have experimented with in the past.

 

To summarise, we can think of this new format as:

 

(a) a way of loading a binary into cartridge memory (ELF)

(b) a method of feeding instructions to the 6507 (StrongARM)

 

It's not a bankswitching scheme in the normal sense.

 

 

It's sounds complex but aside from parsing the ELF file itself (which is best done by a third-party library) the loading process is reasonably straight forward and a good, cycle accurate emulation would allow the bus stuffing to take place. From a development point of view it equates to a significant amount of work but probably worth the effort.

 

 

Edited June 22 by JetSetIlly

[Thomas Jentzsch]

2 hours ago, JetSetIlly said:

You probably have all the expertise you need already but if you do need any help I'm happy to offer it.

Offer accepted!  

 

I can provide help with the infrastructure, but the core functionality would require your input.

37 minutes ago, JetSetIlly said:

The problem with CDFJ and DPC+ as they exist today, is that binary files are specific to a particular architecture. In other words a DPC+ file that can run on the Harmony will not run on the PlusCart without first recompiling or patching.

This part I understand.

37 minutes ago, JetSetIlly said:

The ideal solution would allow the ARM program to be agnostic about the specific memory architecture. Rather than invent a new "bank switching" scheme it was decided to use the ELF standard, which is an industry standard way of defining the rules governing what happens to a program during the process of loading into RAM.

So the program is patched to the current memory architecture when it is loaded, right? If so, how does it determine the architecture? And are only the two existing architectures supported? Or does the ARM itself provide the required information?

37 minutes ago, JetSetIlly said:

The ELF file is the binary that executed on the cartridge. There's nothing else to convert to.

And here I am lost. If the program "somehow" gets adapted to the memory architecture, then in my mind, it gets converted. And the result is either Harmony or Unocart compatible. But you tell me it isn't so.  

37 minutes ago, JetSetIlly said:

Yes. Provided that the ARM code has been compiled with only "Thumb" instructions. ARM programs that have been compiled to use the FPU for example, would require support to be added to the Stella ARM emulation. I don't expect many people would be using the FPU however.

I see. Else we would have to extend ARM support. The current one is only minimal, it just covers what is needed without requiring too much CPU power. CDFJ games are no the edge already. I figure an ELF (or whatever we call it) program, utilizing the CPU significantly (e.g. by bus stuffing), cannot be emulated full speed on the Rockchip of the 2600+, right?

37 minutes ago, JetSetIlly said:

In my opinion, "bankswitching" is a misleading term in this case. There are no static areas of memory containing 6507 instructions and nothing to switch between.

So where does the code and data reside? "Somewhere" in memory?

37 minutes ago, JetSetIlly said:

The StrongARM method developed by @ZackAttack means that the ARM program runs in parallel with the 6507. There is no NOP state like there is with DPC+ and CDFJ. Put another way, we can say that the 6507 is never idle while the ARM program is running and that both CPUs are doing useful work at the same time.

Hm, that sounds like that you can now utilize almost 100% of the ARM CPU power, unlike the current bankswitching methods which only utilize ~20% (during OverScan and VBlank only). Combined with the faster CPU (168MHz vs 60/70Mhz), that's more than 10x the CPU power than available by CDFJ. Which already offers about 50x the power of the 6507. Is that correct? 

37 minutes ago, JetSetIlly said:

Rather than NOPs, the ARM program feeds a constant stream of instructions to the 6507 by stuffing data onto the data bus. This is literally the bus stuffing that people have experimented with in the past.

Didn't that have problems with certain consoles?

37 minutes ago, JetSetIlly said:

To summarise, we can think of this new format as:

 

(a) a way of loading a binary into cartridge memory (ELF)

(b) a method of feeding instructions to the 6507 (StrongARM)

 

It's not a bankswitching scheme in the normal sense.

I see. We need a more general term here.

37 minutes ago, JetSetIlly said:

It's sounds complex but aside from parsing the ELF file itself (which is best done by a third-party library) the loading process is reasonably straight forward and a good, cycle accurate emulation would allow the bus stuffing to take place. From a development point of view it equates to a significant amount of work but probably worth the effort.

Cycle accuracy seems like a major task. It seemed impossible for the Harmony, especially due to the MAM and lack of documentation. Kudos if you managed to do so.

[glurk]

I think this thread is probably going to have to have a seperate technical disscussion thread.  Just an idea......

 

Relatedly, I guess there is never going to be a Harmony cart version?

 

[DirtyHairy]

A bunch of questions:

• From what you say @JetSetIlly I assume that the ARM program is compiled PIC and linked to a relocatable ELF? So you load the ELF according to the SOC memory layout, relocate it and start executing the entry point?
• The program runs 100% of the time and emits a stream of 6502 instructions?
• Current targets are arm7tdmi (the harmony, which is  ARMv4 + Thumb) and Cortex M4 (which ist Thumb + Thumb2)?
• Is there more to the runtime environment of the ELF, like a library, or is it running on bare metal?
• If there is no runtime library then I presume the ARM code accesses the hardware directly? If so you still need different builds for the different supported SOCs?
• What time base is the ARM code using to drive the bus? I suppose it is syncing to address bus transitions, right? From the early code samples I have seen from @ZackAttack I assume that the kernel section calls a function for every instruction which then blocks until all bytes of the instruction have been processed by the 6507.
• Is there any written documentation for this execution scheme?

I don't think strict cycle accuracy for the ARM code is required, though. If we assign each instruction a time slice that corresponds to the average MIPS we should be fine.

Edited June 22 by DirtyHairy

[JetSetIlly]

5 minutes ago, Thomas Jentzsch said:

So the program is patched to the current memory architecture when it is loaded, right? If so, how does it determine the architecture? And are only the two existing architectures supported? Or does the ARM itself provide the required information?

And here I am lost. If the program "somehow" gets adapted to the memory architecture, then in my mind, it gets converted. And the result is either Harmony or Unocart compatible. But you tell me it isn't so.  

Well, the binary will look and be arranged slightly differently in memory than it is in the file, if that's what you meant. The ELF format is a way of instructing the loader what to do with the data in the ELF sections - ie. is it read only data? is it executable data? does this value need translating to a different memory origin? etc. So in that sense, yes, the data is converted.

5 minutes ago, Thomas Jentzsch said:

I see. Else we would have to extend ARM support. The current one is only minimal, it just covers what is needed without requiring too much CPU power. CDFJ games are no the edge already. I figure an ELF (or whatever we call it) program, utilizing the CPU significantly (e.g. by bus stuffing), cannot be emulated full speed on the Rockchip of the 2600+, right?

I'm not familiar with the Rockchip but probably not.

10 minutes ago, Thomas Jentzsch said:

So where does the code and data reside? "Somewhere" in memory?

Heh. Yes it's in memory but it's not a block of memory that you would see in a normal bankswitching scheme.

26 minutes ago, Thomas Jentzsch said:

Didn't that have problems with certain consoles?

I think so, but I believe @ZackAttack has found a working solution. He'll have to fill in the details on that.

 

28 minutes ago, Thomas Jentzsch said:

I see. We need a more general term here.

I've always referred to them as "mappers". Bank switching is just one of the side-effects that can happen when addressing the cartridge.

 

30 minutes ago, Thomas Jentzsch said:

Cycle accuracy seems like a major task. It seemed impossible for the Harmony, especially due to the MAM and lack of documentation. Kudos if you managed to do so.

I meant cycle accuracy on the 2600 side which I believe Stella has. In other words, it's important that the correct data is on the data bus at the correct moment.

 

31 minutes ago, Thomas Jentzsch said:

Offer accepted! 

I'll read up on C libraries for ELF parsing and take it from there.

[Thomas Jentzsch]

24 minutes ago, glurk said:

I think this thread is probably going to have to have a seperate technical disscussion thread.  Just an idea......

Agreed. I have created an issue here. Lets continue there.

24 minutes ago, glurk said:

Relatedly, I guess there is never going to be a Harmony cart version?

Depends on the author. The games doesn't look like it needs that much CPU power.

Edited June 22 by Thomas Jentzsch

[Almaric]

As a Stella Emulation-only guy, I just want to say thanks for the ROM! And of course, thanks to all the talented people that put in the work to keep Stella updated and current.

 

Also - Is there any chance of getting a straight-on pic of that awesome box art? I like to throw together my own silver box versions to display in Stella.

 

 

[+sramirez2008]

18 hours ago, 8bitPoet said:

After a year and a half, the question of whether this game concept is feasible or not has been answered! And the answer is YES!

After a lot of collaboration and effort, @ZackAttack and I were able to fully realize Mattress Monkeys beyond its original scope.

Kudos to @MarcoJ for the amazing music, and a big thanks to out playtesters! We also send our gratitude to @ZeroPage Homebrew for hosting the exclusive world premiere!

BINARY (currently compatible with the Gopher2600 emulator, UnoCart, and PlusCart)
MattressMonkeys20240530rc4.bin

 

OBJECTIVE
The object of the game is to collect as many flies and bonus bananas while avoiding the deadly ceiling fan. After the first stage, the player must also avoid falling off the bed. (You'll lose points for falling off)
 

CONTROLS
- While your monkey is on the mattress, use the joystick to move left and right.
- While your monkey is airborne, you can slightly influence your monkey’s direction with the joystick (Up, Down, Left, and Right).

- Press the button to pause your game.

- During the Challenge Stage, use the joystick to move the fly up, down, left, right, and diagonally
 

SCORING
Fly and Bananas values change based on the current stage.

Stage I - Flies are worth 1 point. Bananas are worth 5 points.
Stage II - Flies are worth 2 points. Bananas are worth 10 points.
Stage III - Flies are worth 5 points. Bananas are worth 25 points.

CHALLENGE STAGE

Roles are reversed and now you play as the fly, popping bubbles while avoiding the monkeys from below. You have 20 seconds to pop every bubble. Missed bubbles will rise again, if time remains. Each bubble popped is worth 5 points. Pop all 16 bubbles for a perfect score!
 

STRATEGY
Positioning your monkey various distances from the monkey landing on the mattress will influence the height and trajectory of your monkey. Finding that sweet spot will help you reach the flies and bonus banana without being thrown into the ceiling fan.

STAGES
Once you've reached all three stages, you've unlocked the option to choose your starting stage from the menu using Up and Down on the joystick.

FAQs
Did you hide any Easter eggs in the game?
Yes. Have fun on your hunt!
Will there be a physical release?
We're actively seeking a publisher. (Any interested publishers, get in touch!)

 

I just watched the premiere on yesterday’s ZPH and this looks excellent! Consider one CIB sold if you can find a publisher. 🙂

[+sramirez2008]

19 hours ago, 8bitPoet said:

After a year and a half, the question of whether this game concept is feasible or not has been answered! And the answer is YES!

After a lot of collaboration and effort, @ZackAttack and I were able to fully realize Mattress Monkeys beyond its original scope.

Kudos to @MarcoJ for the amazing music, and a big thanks to out playtesters! We also send our gratitude to @ZeroPage Homebrew for hosting the exclusive world premiere!

BINARY (currently compatible with the Gopher2600 emulator, UnoCart, and PlusCart)
MattressMonkeys20240530rc4.bin

Tried the BIN on my UnoCart and I get a Bad Rom File error. I'm on v18 of the UnoCart firmware. Anyone else have this issue?

[ZackAttack]

7 hours ago, sramirez2008 said:

Tried the BIN on my UnoCart and I get a Bad Rom File error. I'm on v18 of the UnoCart firmware. Anyone else have this issue?

You need to switch to the UCA firmware to play elf games.

[+sramirez2008]

13 minutes ago, ZackAttack said:

You need to switch to the UCA firmware to play elf games.

Thanks.

[+Philsan]

Could you please make a PAL60 version (Fly Hunter too)?

[ZackAttack]

2 hours ago, Philsan said:

Could you please make a PAL60 version (Fly Hunter too)?

Mattress Monkeys will automatically switch to PAL60 if that's what you have configured in your uno/plus cart settings. It's a single bin for both.

[m.o.terra kaesi]

20 hours ago, sramirez2008 said:

I just watched the premiere on yesterday’s ZPH and this looks excellent! Consider one CIB sold if you can find a publisher. 🙂

have I missed something or why isn't Atariage an obvious publisher? 

[+sramirez2008]

24 minutes ago, m.o.terra kaesi said:

have I missed something or why isn't Atariage an obvious publisher? 

Could be. Just going by their FAQ.

 

FAQs
Did you hide any Easter eggs in the game?
Yes. Have fun on your hunt!
Will there be a physical release?
We're actively seeking a publisher. (Any interested publishers, get in touch!)

[8bitPoet]

28 minutes ago, m.o.terra kaesi said:

have I missed something or why isn't Atariage an obvious publisher? 

@ZackAttack can explain this better than me, but it requires a custom PCB designed by Zack, so it's not as simple as supplying a rom file and some artwork to AtariAge. We're talking with @Albert about the logistics. Stay tuned!

[+sramirez2008]

I finally got around to upgrading my UnoCart and testing the game. I hope to play it with family over the upcoming (4th of July) holiday. Thanks for sharing the bin.

[8bitPoet]

7 hours ago, sramirez2008 said:

I finally got around to upgrading my UnoCart and testing the game. I hope to play it with family over the upcoming (4th of July) holiday. Thanks for sharing the bin.

That's great! I hope it's fun for the whole family.

[+sramirez2008]

Couldn’t sleep. New personal HS. This is a fun, addictive, try “one more time” type of game. 👍

[8bitPoet]

7 hours ago, sramirez2008 said:

Couldn’t sleep. New personal HS. This is a fun, addictive, try “one more time” type of game. 👍

GG! Thank you so much for that compliment. If this were a coin-op, you could kiss your quarters goodbye! LOL