Dreamcast-Talk.com

thank you for the explain
wondering if reaching to implement this in Metal Slug 6 or Dolphin Blue could help with the general running performance, expecially the in game loadings?

Those 2 games are already running very well and fast on gdemu+ original gdi

It turns out that the problem of slowing down the game is caused by explosions or too many other special effects at certain times, unless you change to a more powerful cpu

You can refer to the arcade version of Metal Slug, which will also slow down at certain times

Those two games run excactly the same with the atomis hardware soooo what’s the point .overall we have to decode all games to see more ram

yzb wrote:Those 2 games are already running very well and fast on gdemu+ original gdi

It turns out that the problem of slowing down the game is caused by explosions or too many other special effects at certain times, unless you change to a more powerful cpu

You can refer to the arcade version of Metal Slug, which will also slow down at certain times

Even with more powerful cpu it smooth it out but run slower since the fast running parts would be spammed with over frame.. I know this from metal slug 2 and 1 on dreamneo cd ..


The way they render those games even overclocking does not help that much it makes the slowdown gone but makes it all slower over all

Hey YZB, any luck looking at the Windows CE games? I think they still would benefit the most from the added memory.

Anthony817 wrote:Hey YZB, any luck looking at the Windows CE games? I think they still would benefit the most from the added memory.

I haven't watched wince games, they are too difficult to debug

Update kofxi link

Hey all,

32MB support patches I worked on were officially merged into KallistiOS earlier this evening. This same support enables easy 32MB support for homebrew on both NAOMI and modded Dreamcast consoles. This also means that if DreamShell is updated against the latest KOS, DreamShell will also automatically get 32MB support.

For developers, a DBL_MEM macro is provided to get a true or false value, so it's extremely easy to make decisions in your games/applications about whether or not to allocate more or less memory. You can easily do simple things on day 1 like choose to keep certain areas of your map cached in memory for 32MB users for better loading times just based off of that.

Additionally, I adapted tsowell's memory tester utility and included it in the KOS examples folder as well. It'd be worthwhile to look at the source if you're interested in using this in your code.

On top of that, cepawiel wrote a patch which kazade merged yesterday enabling 32MB support in the lxdream-nitro emulator. You can now build it with support by using the -DMOD_32MB_RAM=true option when building lxdream-nitro. Details for this are on the bottom of the lxdream-nitro page:
https://gitlab.com/simulant/community/lxdream-nitro

I was also able to get NetBSD/Dreamcast built with 32MB support extremely easily as well. Details for this and the current state of 32MB Dreamcast support is listed on dreamcast.wiki here.

When I get some free time I'll also try to look into the Sofdec playback/crash issue on 32MB systems, perhaps this can be patched somehow.

So I've been following along with the work on getting this patched merged into KOS and was also fortunate enough to have my DC modded for 32MB by darc and have loved every second of it. First of all, I wanted to thank tsowell personally for doing this. We really believe in what you've done and think it could be a valuable tool for development as well as even for released indie games and emulators. We wanted to see it in mainstream KOS badly!

For any developer who may be reading this thinking, "I don't care about special code for extra RAM for a small percentage of the population when the stock DC only has 16MB." First of all, just for you, as a developer, you can get a lot of use out of it adding extra code, metadata, allocation tracking/profiling, debug symbols, etc using it just for debug builds during development locally. Secondly, I would argue that there are definitely trivial scenarios for an indie game or for an emulator to easily leverage the extra RAM without having to go do a bunch of extra work for it... Like in our engine, we actually cache the previous 3 visited areas on PC so if you just backtrack quickly there's no reloading assets from disk.

On DC, we couldn't cache anything. Now I can trivially at least cache another area. Also there are things like particle buffers or dead body remnants on the map that are coming from a pool which have to be recycled but could be using a deeper buffer on 32MB.

A friendly reminder, darc made it this freaking easy to leverage on purpose: Furthermore what was added to KOS was just a single global variable, populated at startup, holding the start location of the stack, which is referenced now by the code rather than having a fixed value. It's as lightweight and nonintrusive as it could get, imo.

The only thing is in order to leverage 32MB, the toolchain has to be updated with KOS. You don't have to, you'll just get a message if you don't, but maaaaybe you'll like it if you do. lol.

It's great, it would be perfect if it solves the problem of playing sfd crashing

So I have a Dreamcast with two flashable tsop's and a switch.
First one has Japanse cake's bios and the second one has the DreamShell loader.

This should make it easy, as you could boot from the DreamShell bios up front and flash the 32MB bios in the other chip.

Then replace the ram chips and flip the switch to boot from from the 32MB bios.
Finally while booted into DreamShell, flip the switch once more to flash the 32MB DreamShell bios in the first chip.

Is there anybody willing to do the upgrade for me?
As I dont have a hot air soldering station