Consequences of trying to disable CIRAM in clones that don't allow it?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Sun Jul 19, 2020 11:09 am

What happens when cartridges try to disable the internal CIRAM in clones where it's permanently enabled? I hear people saying that "games don't work", but what exactly is the visual result of trying to use these cartridges?

What happens when two RAM chips are enabled on the same bus? Is it possible to get something usable if the program detects that it can't control the name tables as intended and restricts itself to using only two name tables with the same layout as the CIRAM name tables?

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

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by lidnariq » Sun Jul 19, 2020 12:01 pm

tokumaru wrote:
Sun Jul 19, 2020 11:09 am
What happens when two RAM chips are enabled on the same bus?
Writes: Nothing, both writes to both RAMs work fine.
Reads cause bus conflicts.

Both RAMs are CMOS devices here, so it's not clear whether you'll get the same wired-AND behavior that we see with discrete logic mappers. For all I know, the new RAM could have sufficiently more powerful drivers that you won't be able to detect the CIRAM still being enabled simultaneously.
Is it possible to get something usable if the program detects that it can't control the name tables as intended and restricts itself to using only two name tables with the same layout as the CIRAM name tables?
Technically, but it's so restrictive that I think it's hardly worth doing anything more than displaying an error message.

If you can't disable your own additional RAM, you'll effectively be constrained to only being able to use horizontal arrangment, and the vertical scrolling register will have to stay in the range of -16 to 0. (Because you can't let the PPU switch between the source nametable at $2000 and the one at $2800)
You can't even safely use vertical arrangement, because the PPU always fetches from both the left and right nametable on each scanline.

Something like MMC5 or the 163 you could safely back off, but then why bother to write the same game twice? You're not going to be able to share that much between the more-nametables and the 2-nametables versions.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Sun Jul 19, 2020 12:48 pm

This would be for my raycaster. I need two name tables in order to draw a single screen (through the use of raster effects), and the 4-screen layout allows me to double buffer the 3D viewport, avoiding all tearing.

Since there's no scrolling, the only drawback of using two name tables would be the loss of the double buffering, but the game should remain playable.

User avatar
Fisher
Posts: 1091
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Fisher » Sun Jul 19, 2020 3:42 pm

I have a clone with this exact problem.
In fact, it didn't even had a correct PPU /A13 signal, wich I fixed with a inverter.
I tested some games, and had post some pictures of the problematic ones, after the "fix", here.
Maybe these pictures can give you an idea of what happens.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Sun Jul 19, 2020 6:21 pm

Fisher wrote:
Sun Jul 19, 2020 3:42 pm
I tested some games, and had post some pictures of the problematic ones, after the "fix", here.
Maybe these pictures can give you an idea of what happens.
Cool! It does look like 4-screen games manage to write data to the name tables and get it displayed properly.

I wonder how the CIRAM A10 pin is wired in MMC3 carts with 4-screen VRAM... Maybe it's connected to the MMC3 normally and you can still control the mirroring via $A000? If so, then I would be able to arrange the name tables horizontally and only use the top 2 of the 4 name tables on the cartridge.
lidnariq wrote:
Sun Jul 19, 2020 12:01 pm
For all I know, the new RAM could have sufficiently more powerful drivers that you won't be able to detect the CIRAM still being enabled simultaneously.
Wouldn't the 4-screen layout just work normally if this was the case?

What do you think would be the best way to detect a clone with this problem when trying to use 4 name tables? Write different sets of data to each pair of name tables and then try to read them back? Does the actual data used matter?

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

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by lidnariq » Sun Jul 19, 2020 7:06 pm

tokumaru wrote:
Sun Jul 19, 2020 6:21 pm
I wonder how the CIRAM A10 pin is wired in MMC3 carts with 4-screen VRAM... Maybe it's connected to the MMC3 normally and you can still control the mirroring via $A000? If so, then I would be able to arrange the name tables horizontally and only use the top 2 of the 4 name tables on the cartridge.
... Weirdly enough, it does look like TVROM does connect pin 10 on the MMC3 to the right pin on the card edge.

NesCartDB doesn't have good enough pictures of TR1ROM to check it.
Wouldn't the 4-screen layout just work normally if [extra nametables overpowered the internal ones]?
Yes, but bus conflicts are still bad for the hardware and you don't really want to elicit them if you can avoid it.
What do you think would be the best way to detect a clone with this problem when trying to use 4 name tables? Write different sets of data to each pair of name tables and then try to read them back? Does the actual data used matter?
Something like that. You want some combinations of bytes that'll clearly generate a bus conflict; probably checking for both potential RAMs driving the pins high and low would be better. Perhaps something like

$00 -> [$2000]
$FF -> [$2001]
$FF -> [$2800]
$00 -> [$2801]
Then make sure that you read back $00 then $FF.

User avatar
Fisher
Posts: 1091
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Fisher » Sun Jul 19, 2020 8:32 pm

If it matters, the Gauntlet cartridge I used was made by Gradiente, wich AFAIK uses the same mapper as the ones made by Tengen, the 206.
Maybe I should add this information to that thread.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Sun Jul 19, 2020 11:08 pm

lidnariq wrote:
Sun Jul 19, 2020 7:06 pm
You want some combinations of bytes that'll clearly generate a bus conflict; probably checking for both potential RAMs driving the pins high and low would be better. Perhaps something like

$00 -> [$2000]
$FF -> [$2001]
$FF -> [$2800]
$00 -> [$2801]
Then make sure that you read back $00 then $FF.
I see... Thanks.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Tue Jul 21, 2020 12:26 am

It now occurred to me that I could maybe ditch the 4-screen layout altogether, and use PRG-RAM instead, which is much more common and doesn't cause any compatibility issues. I could buffer an entire picture in PRG-RAM, and then copy it to the two name tables when it's ready. The only drawback is that, in NTSC, there's not enough time in a hardware frame, even with lots of forced blanking, to update both name tables in one go. I'd have to draw the screen in two parts over consecutive frames, either horizontally or vertically, introducing a bit of tearing.

There are some raycasters out there with tearing, such as MOOD on the Commodore 64 or Duke Nukem 3D on the Genesis, but I'm not sure how I feel about it. On one hand, the more frequent screen updates help cover up the low frame rates, but I can't help thinking it looks less polished than full screen updates.

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

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by lidnariq » Tue Jul 21, 2020 12:51 am

Honestly, I don't think it's worth worrying about compatibility with these famiclones. Unless you specifically want Fisher to be able to run your game on his.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Tue Jul 21, 2020 1:26 am

This is not just about Famiclone compatibility... In addition to the advantages of going with the more compatible/widespread hardware configuration, having access to the entire frame buffer opens up some possibilities, such as rendering objects with background tiles on top of the finished scene, eliminating the problem of sprite flickering. But even if I decide to stick with sprites for drawing objects, the extra PRG-RAM can be used to store extra sets of OAM buffers for quick flickering of 128 or more sprites, reducing permanent sprite dropout. Also, having more RAM available is beneficial in general... it helps with keeping object states, buffering decompressed data, and so on.

I did some tests and found that vertical tearing looks pretty bad when turning, but horizontal tearing is barely noticeable at full frame rate (which the following GIFs might not be, depending on where you're playing them).

No tearing (whole screen updates at once):
no-tearing.gif
no-tearing.gif (205.15 KiB) Viewed 645 times

Vertical tearing (top half updates first):
vertical-tearing.gif
vertical-tearing.gif (217.73 KiB) Viewed 645 times

Horizontal tearing (left half updates first):
horizontal-tearing.gif
horizontal-tearing.gif (206.04 KiB) Viewed 645 times

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Bananmos » Tue Jul 21, 2020 6:55 am

tokumaru wrote:
Tue Jul 21, 2020 1:26 am
This is not just about Famiclone compatibility... In addition to the advantages of going with the more compatible/widespread hardware configuration, having access to the entire frame buffer opens up some possibilities, such as rendering objects with background tiles on top of the finished scene, eliminating the problem of sprite flickering. But even if I decide to stick with sprites for drawing objects, the extra PRG-RAM can be used to store extra sets of OAM buffers for quick flickering of 128 or more sprites, reducing permanent sprite dropout. Also, having more RAM available is beneficial in general... it helps with keeping object states, buffering decompressed data, and so on.

I did some tests and found that vertical tearing looks pretty bad when turning, but horizontal tearing is barely noticeable at full frame rate (which the following GIFs might not be, depending on where you're playing them).

No tearing (whole screen updates at once):
no-tearing.gif


Vertical tearing (top half updates first):
vertical-tearing.gif


Horizontal tearing (left half updates first):
horizontal-tearing.gif
Nice results!

It does make perfect sense that horizontal updates would be a lot less noticeable when the viewpoint moves horizontally, as you avoid the very obvious seam that partially shifted walls give you.

It'd be interesting to see if doing that update in odd / even columns could improve it even further? As the columns rendered are already a heavily rounded/quantized version of the real world, the artifacts might be just about indistinguishable from the error you are already getting with using such a low resolution. Though I think it'd have to be tried to see if it works out that way in practice. :)

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Tue Jul 21, 2020 8:01 am

Bananmos wrote:
Tue Jul 21, 2020 6:55 am
Nice results!
This is still the 10+ year-old demo, I was just using it to test the tearing options. :mrgreen:
It does make perfect sense that horizontal updates would be a lot less noticeable when the viewpoint moves horizontally, as you avoid the very obvious seam that partially shifted walls give you.
True. The only artifact I can actually see is when a single column of the edge of a block gets left behind (it happens a couple of times in the test animation), but even then it's not that bad.
It'd be interesting to see if doing that update in odd / even columns could improve it even further?
I can give this a try later. I can easily try any pattern I want, I'm doing this in Photoshop! I'm guessing it'll look worse, though - instead of a single seam there'll be up to 27 of them! :lol:

I wonder if changing the update order depending on the direction of the movement would make a difference... When turning right I could update the right side first.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Tue Jul 21, 2020 11:16 am

Here's what updating alternate columns looks like:
alternating-columns.gif
alternating-columns.gif (394.47 KiB) Viewed 548 times
It's pretty bad. Way more "orphan" columns, and the walls are all jagged.

And here's what alternating rows looks like:
alternating-rows.gif
alternating-rows.gif (392.48 KiB) Viewed 548 times
Also pretty bad. Looks kinda blurry, actually.

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

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by calima » Wed Jul 22, 2020 1:25 am

That alternating rows wouldn't even be possible on a NES, I think.

Post Reply