Why does this basic program crash FCEUX?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

Re: Why does this basic program crash FCEUX?

Post by rox_midge » Fri May 01, 2020 8:28 pm

Controllerhead wrote:
Fri May 01, 2020 7:32 pm
tokumaru wrote:
Fri May 01, 2020 4:58 pm
If you use a large CHR-RAM chip (32 or 64KB) you can pre-calculate all rotations and get the best of both worlds: no wasted ROM plus instantaneous switching.
So say you were to start your game with a 2-3 second splash screen, with maybe a CAPCOM size little logo in the middle, you could probably pre-populate that entire space with some clever ON-OFFing of the PPU. You get all the quick bank switching advantages of a CHR-ROM style setup with the flexibility of CHR-RAM. Plus, if it ever comes to cart, only one CHR chip instead of two.

I'm sold man. That's gotta be the way to go.
I get the impression that tokumaru sells RAM chips for a living, but I tend to agree. I also need PRG-RAM (preferably battery-backed), and I don't think there are boards with PRG-RAM + CHR-RAM + CHR-ROM - and if there are, they couldn't be cheap.

It also has the advantage that the tiles can be RLE compressed (or whatever), so that they don't have to take up as much space in the PRG-ROM. The more I think about it, the more it really does seem to be the best of both worlds.

User avatar
Controllerhead
Posts: 150
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Why does this basic program crash FCEUX?

Post by Controllerhead » Fri May 01, 2020 8:32 pm

tepples wrote:
Fri May 01, 2020 8:02 pm
PowerPak with PowerMappers supports the oversize TGROM configuration used by HH86.
It's a brilliant memory setup dude, and i have to congratulate you on years of Actually Shipping. Certainly something to aspire to.

Now, I know your target was Cart and Real Hardware. Your setup seems awesome for that. My question is, how does this oversized CHR-RAM work on most emulators? Do they tend to support it, or at least just chug along? Does it work on Everdrive? Classic/newer clone systems?

The only reason i can think of Not to do this would be compatibility issues. I mean, i'm not expecting it to work on Nesticle or anything, but how about like Nestopia? FCEUX? Mesen? Browser emulators? Android and iPhone emulators?

Personally, my eventual plan is to just release games as roms hawking Patreon or Paypal or something similar; so mass compatibility is a relevant issue for me.
Image

User avatar
Controllerhead
Posts: 150
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Why does this basic program crash FCEUX?

Post by Controllerhead » Fri May 01, 2020 8:51 pm

rox_midge wrote:
Fri May 01, 2020 8:28 pm
I also need PRG-RAM (preferably battery-backed)
Well, i'm sure you could get a bunch of CR-2032's cheap heheh.

Anyway, here in 2020, where EEPROM and mass storage flash memory are mature and all but free, it really makes me wonder if there is a better way... but i come from the software side so... i don't know... at this point, its practically Lateral Thinking with Withered Technology amirite?
Image

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Why does this basic program crash FCEUX?

Post by tepples » Fri May 01, 2020 9:35 pm

Controllerhead wrote:
Fri May 01, 2020 8:32 pm
how does this oversized CHR-RAM [with MMC3] work on most emulators?
FCEUX nightly and Mesen 0.9.9 have no problem with HH86. Test your own favorite emulator with the MMC3 big CHR RAM test ROM or a suitable build of Holy Mapperel. I don't own an EverDrive or any famiclones that take a cartridge.
Controllerhead wrote:
Fri May 01, 2020 8:32 pm
The only reason i can think of Not to do this would be compatibility issues. I mean, i'm not expecting it to work on Nesticle or anything, but how about like Nestopia? FCEUX? Mesen? Browser emulators? Android and iPhone emulators?
I haven't had a chance to test it on every published emulator. What I can do and have done is post test ROMs. But as for Android and iPhone, how many people actually carry around an external gamepad to use with a phone? And additionally as for iPhone, I thought 1. most popular emulators were GPL, 2. the App Store terms were incompatible with the GPL, and 3. the "self-contained" requirement in the App Store Review Guidelines required emulators to be distributed as a bundle with a ROM by the ROM's publisher anyway.

lidnariq
Posts: 9689
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Why does this basic program crash FCEUX?

Post by lidnariq » Fri May 01, 2020 9:36 pm

Controllerhead wrote:
Fri May 01, 2020 8:51 pm
Anyway, here in 2020, where EEPROM and mass storage flash memory are mature and all but free, it really makes me wonder if there is a better way...
Modern homebrew mappers do seem to be gravitating towards that. Both GTROM and UNROM512 are explicitly designed with that in mind, instead of providing extra RAM.

User avatar
rainwarrior
Posts: 7841
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Why does this basic program crash FCEUX?

Post by rainwarrior » Fri May 01, 2020 10:13 pm

rox_midge wrote:
Fri May 01, 2020 8:28 pm
I get the impression that tokumaru sells RAM chips for a living, but I tend to agree. I also need PRG-RAM (preferably battery-backed), and I don't think there are boards with PRG-RAM + CHR-RAM + CHR-ROM - and if there are, they couldn't be cheap.
Building a board that supports a simultanous CHR-RAM and CHR-ROM is guaranteed going to be more expensive than just using a larger CHR-RAM (and larger PRG-ROM to hold the stuff you want to copy to it).

Trying to host yet another chip on the board is not just more expensive, but also a logistical problem in many ways. Far easier just to fill it up from PRG at boot or whenever is convenient.

Also, cost-wise you're not going to get cheaper than 32k CHR-RAM these days anyway, so it's not even worth considering whether you should do 8k vs 32k. Even if you only want 8k, you'd probably end up using a 32k chip and just not using most of it.

Basically, this only made sense in the past when RAM was a lot more expensive than it is now, to the point where making it smaller could make the board cheaper, despite the added complexity of hosting another CHR chip.

(Pretty sure this exact subject has been discussed before, but can't think of a good term to search for it at the moment.) Edit: found it
Last edited by rainwarrior on Fri May 01, 2020 10:28 pm, edited 3 times in total.

User avatar
Controllerhead
Posts: 150
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Why does this basic program crash FCEUX?

Post by Controllerhead » Fri May 01, 2020 10:18 pm

tepples wrote:
Fri May 01, 2020 9:35 pm
Test your own favorite emulator with the MMC3 big CHR RAM test ROM
Super helpful! I will be sure to do that. I'm quite curious...

...Look, I kind of got caught up in the zeitgeist of this thread, so before i start ripping plans and projects apart and converting code to use large CHR-RAM, i just wanted to ask and get a general feel on how it would run on "most things". Since i don't feel the need to customize Mario's Moustache, for now, i'm going to stick to CHR-ROM. I know it runs everywhere, switches fast, and suits my needs just fine. It really is an awesome scheme though, and a brilliant innovation with some clear advantages, and i will definitely be testing that ROM around.
tepples wrote:
Fri May 01, 2020 9:35 pm
But as for Android and iPhone, how many people actually carry around an external gamepad to use with a phone?
I have fond memories of carrying around a Wii-Mote with my shiny new Droid X rocking games at a smooth 60FPS on NESoid circa 2010 =) Of all the nerds i know, i was the only one carrying around an external gamepad...
Image

User avatar
rainwarrior
Posts: 7841
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Why does this basic program crash FCEUX?

Post by rainwarrior » Fri May 01, 2020 10:24 pm

rainwarrior wrote:
Fri May 01, 2020 10:13 pm
(Pretty sure this exact subject has been discussed before, but can't think of a good term to search for it at the moment.)
Found it. A brief discussion of the (lacking) merits of simultanous CHR-ROM + CHR-RAM:
viewtopic.php?f=3&t=19466&start=15#p244177

calima
Posts: 1190
Joined: Tue Oct 06, 2015 10:16 am

Re: Why does this basic program crash FCEUX?

Post by calima » Sat May 02, 2020 12:26 am

rox_midge wrote:
Fri May 01, 2020 3:51 pm
Are there any dev carts available that have CHR-RAM at all? Even just 16KB would suffice, as it would allow me to load banks prior to needing them for rendering.
Grab an Everdrive, the older N8 had 512kb for CHR and the newer pro has 8mb.

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

Re: Why does this basic program crash FCEUX?

Post by rox_midge » Thu May 07, 2020 7:45 pm

Based on the information provided by everyone in this thread, I was able to make a bunch of progress over the last few days. I switched to Mesen for the superior emulation and debugging features. I'm loading tiles from PRG-ROM into my 64KB of PPU-RAM at boot, and I've got basic camera control working, keeping a 6-row status bar at the bottom of the screen in place while the rest of the playfield can be scrolled around.

Despite the fact that the iNES header specifies that I've got 8KB of WRAM, though, Mesen indicates that there's nothing mapped into the $6000-$7FFF range, and indeed, attempting to read from $6000 results in $60 (the upper byte of the address line, I imagine), and attempting to write into it does nothing.

Does mapper 4 not support simultaneous PRG-RAM and CHR-RAM? I really do need to have that 8KB of WRAM to store object information.

lidnariq
Posts: 9689
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Why does this basic program crash FCEUX?

Post by lidnariq » Thu May 07, 2020 7:48 pm

Are you using Mesen's header editor? What does it say your file is?

User avatar
aa-dav
Posts: 102
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Why does this basic program crash FCEUX?

Post by aa-dav » Thu May 07, 2020 8:01 pm

rox_midge wrote:
Thu May 07, 2020 7:45 pm
Does mapper 4 not support simultaneous PRG-RAM and CHR-RAM?
Yes. Show your header description again, we will check it.

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

Re: Why does this basic program crash FCEUX?

Post by rox_midge » Thu May 07, 2020 8:12 pm

Here's what Mesen's header editor says, which matches what I meant it to say (image attached).

The bytes are:

Code: Select all

4E 45 53 1A 08 00 40 08 00 00 07 0A 00 00 00 00
Attachments
ines-header.png

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Why does this basic program crash FCEUX?

Post by Sour » Thu May 07, 2020 8:15 pm

Did you enable the WRAM for the mapper? e.g by writing $80 to $A001?
Otherwise Mesen won't give you access to the work ram, even if you define it in the header.

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

Re: Why does this basic program crash FCEUX?

Post by rox_midge » Thu May 07, 2020 8:22 pm

OMG, it's that *@#$ rake again!

Code: Select all

	; Enable WRAM
	lda $80
	sta $A001
That was exactly it! I'm going to have a bruise there before all is said and done.

Post Reply