64 columns on a nes famiclone (just an idea)

Comment

Comment by BruceMcF on November 3, 2010 at 8:27am

It may be that there is far less complexity here if the target system uses the FAMiclone all in one chip that includes the single large address space mode. Then if there is not enough space to fit the required information for one half of the screen in one mapping of the video "ROM", the screen can be split into thirds instead of 10 lines each third, which is 5 rows of 16x16 blocks.

Setting up memory mapping in the unified address space is much easier, since its possible to roll your own with a single CPLD.

Comment by Ben Samples on November 3, 2010 at 5:29am

"(90^2/2 = 4050 bytes)"

Rereading my last post, I noticed that my math wasn't sound here. I got the right answer, but for the wrong reason. You still need to use 8K of CHR-ROM to do it, but this all still fits on one "half" of the palette.

I'm going to use the excuse that it's early and that I haven't been properly caffeinated yet because it sounds as good as any other. ;)

Comment by Ben Samples on November 3, 2010 at 5:18am

Your palette idea is pretty sharp. From a programming standpoint, however, this has a problem.

To store the digraphs for 7-bit ASCII would require 128 * 128 (divided by two because of the palette trick) = 8k of CHR-ROM, which fits just perfectly into what the NES can hold in its pattern tables. The problem, however, is that the NES alone can't store different background colors for each of the tiles in memory; the PPU, without any extension from a mapper, can only set individual background colors for 16x16 pixel regions in the attribute table (there's a great article about attribute tables on the NESdev wiki that you may want to go look at that explains this better than I can here).

You have two options for implementing this sort of text display on the NES:
1) Use a mapper like MMC5 that provides extended attribute tables and allows you to set backgrounds for individual 8x8 tiles, or;
2) Start pruning away at the number of displayable characters to try to cram them all into 4k of memory so you can use the same palette background for all of them, using the other "half" of the nametable data for sprites to fill in missing glyphs here and there.

Using MMC5 is by far the cleanest option, but it's also a more expensive one. I don't know what sort of access the PlayPower project has to this sort of hardware, but as a hobbyist developer one would have to purchase MMC5 cartridges of existing games, take them apart, and then gut them - which can get cost- and time-prohibitive very quickly on any sort of large scale at all.

The pruning option could quickly turn into a little nightmare to code, but it is in theory at least feasible. To fit the character digraphs into 4k, one would have to tear down the ASCII character set to 90 glyphs (90^2/2 = 4050 bytes). This is easier than it sounds, with 32 of the ASCII characters not being printable anyhow, but it would require choosing six glyphs out of the regular ASCII set to represent on screen as sprites - with all the limitations that entails. It wouldn't be possible to show more than eight of these (hopefully uncommon) glyphs on any one line at a time without resorting to flickering, and there would be a hard limit of 64 "sprite glyphs" per screen.

Aside from those limitations, though, this is a great idea. I hope this helps.

Comment by Sam Washburn on June 2, 2010 at 1:05am

This is a clever idea. I like how you thought to use specialized palettes to encode two mono tiles on one 2bit tile. The split screen is either accomplished by polling the Sprite-0 Hit bit, or by using a more advanced mapper chip to generate raster IRQ's. Also, you would need a CHR-RAM cartridge setup to be sure the tiles are editable and not stored in ROM. This seems feasible to me.

see: How does sprite 0 hit detection work?

Comment by Paulo Silva on April 13, 2010 at 5:59am

@BruceMcF yes, it's sharp enough, i remember running Taswide on a TK90X (ZX-Spectrum clone) when i lived in Brazil at 80's, and the TV i had were really crappy...

Comment by BruceMcF on April 12, 2010 at 8:47pm

I don't know any of the details of getting it to operate in the NES, but I used a very similar bitmap font on the C64 in the 1980's (its 320 rather than 256 pixels wide, so it was 80 columns).

However, that was for a monochrome monitor, not for the television display: the issue is how sharp the television display is. Its definitely worthwhile exploring, as an option, but if the television display is not sharp enough to support it, a fallback to 32col by 30row text probably should be available.