Single Chip Cartridge

[tokumaru]

Not at all. Just think again.

Yeah, I was wrong before, and my post above (EDIT: heh, it's actually on the previous page!) is exactly what you said: me thinking again.

If you want to use the entiere screen, which is of course what I want to do in the game I was developing, that's pretty much the good way to go.

Yes, that's the basic set up, where abusing the mirroring is just not possible. If you're not scrolling though, or scrolling in only one direction, you could just as easily use H/V mirroring and still have the possibility of borrowing name table bytes for extra patterns.

[nocash]

I'm not sure it would be the "most common case"

At the moment, using A13 is - literally - the most common case (as it's used by the magic floor game).
And other than that, it's the simpliest/straightest mapping, the thing that first comes to mind to most people when they don't need special tricks. I'd assume A13 will stay quite common for future games. And mind the memory/opcode saving: With A12 you couldn't use address 0000h for CHR-RAM, so A13 does at least have a small advantage.

Btw. for non-A13 mappings, there might be in fact one case where programmers may want to rely on special mirrors: If you share one 1K block for BOTH name table and char data, then it would make sense to access both in the 2xxxh area, or both in 0xxxh area (instead of separating CHR at 0xxxh, and NT at 2xxxh).

[tokumaru]

I'm not sure it would be the "most common case"

At the moment, using A13 is - literally - the most common case (as it's used by the magic floor game).
And other than that, it's the simpliest/straightest mapping, the thing that first comes to mind to most people when they don't need special tricks. I'd assume A13 will stay quite common for future games.

I guess you guys are correct. Most people would rather have a clear separation between CHR and name tables, than having to worry about complicated mirroring layouts just to get a few measly extra tiles.

And mind the memory/opcode saving: With A12 you couldn't use address 0000h for CHR-RAM, so A13 does at least have a small advantage.

I don't see that as much of an advantage though.

Btw. for non-A13 mappings, there might be in fact one case where programmers may want to rely on special mirrors: If you share one 1K block for BOTH name table and char data, then it would make sense to access both in the 2xxxh area, or both in 0xxxh area (instead of separating CHR at 0xxxh, and NT at 2xxxh).

Exactly. You get the freedom to distribute the available memory less evenly, in case you want to.

[nocash]

I don't see that as much of an advantage though.

It's only a tiny advantage: For addr=0000h, you can write 00h to both LSB and MSB of Port 2006h. Makes your program code a little bit smaller.

Exactly. You get the freedom to distribute the available memory less evenly, in case you want to.

Not sure if I did meant that. What I meant is if you use NT data at 2000h-20FFh with attributes at 23C0h-23FFh, and CHR data (in a mirror of the same 1K memory block) at 0100h-03BFh, then you might prefer to address that stuff in a continous addresss space at 0000h-03FFh.
That would give you a cleaner memory map in source code. At that point, compatibilty with regular NROM or AOROM carts would end, as they can't do that mirroring.

[tokumaru]

It's only a tiny advantage: For addr=0000h, you can write 00h to both LSB and MSB of Port 2006h. Makes your program code a little bit smaller.

With only 64 tiles, I imagine most games that are not simple puzzles will be updating CHR data A LOT (and to many locations besides $0000), in which case they should have a more robust CHR management system, where tile destinations are specified with a single byte from which the target address is calculated.

That would give you a cleaner memory map in source code. At that point, compatibilty with regular NROM or AOROM carts would end, as they can't do that mirroring.

Yes, to retain compatibility with these mappers you can't access CHR data and name table data in a contiguous address space. That's basically what I meant by "abusing the mirroring".

BTW, do you have a version of your emulator up for download that supports the single chip cart?

[nocash]

do you have a version of your emulator up for download that supports the single chip cart?

Works in the new no$nes v1.1 update (released around six minutes before you've asked). To get it emulated, the game needs to be declared as "mapper 218", with the mirroring selected via the iNES H/V bit and the 4-screen bit misused as 1-screen bit (sorry, I know that not everybody liked that definition, but then there haven't been too many people favoring other options (*), so I've did stick with that definition).
(*) aside from the NROM/AOROM solution... that was actually favored by many people... but I really-really wanted an own mapper number for it, sorry there.

Oh, and I've updated the http://nocash.emubase.de/magicflr.htm demo game, the ROM-image is now marked as mapper 218, so no$nes v1.1 will handle it as such (which, for that game, basically means that you can see the special NT/CHR mirrorings in the VRAM viewer).

[Memblers]

I'm a little late to the party, but..

I don't think it was said already, but in case everyone didn't know, a cheap trick to fit more tiles with the same memory is to store two 1bpp tiles combined into 1 NES tile. You display them individually by using different palettes. The trick is using the 'extra' color when a pixel appears in both tiles, so your NES tile usage is such: transparent, tile1color, tile2color, tile1&2color. While the actual palette you send to the PPU would look like:
set 1 - BG, color1, BG, color1
set 2 - BG, BG, color2, color2.

Just a random thought. Isn't an ATMega MCU fast enough and has enough pins to emulate a ROM for NES, i.e. put requested data from internal ROM on data bus pins as fast as needed? It probably can also act as CIC.

ATMega64 could be enough for this application (32K for PRG, 32K for AVR code), and its price is under $10, which is a bit less than thousands.

I actually previously thought of doing that with the Propeller MCU (with 8 32-bit cores, it's an odd one).. I coded a small part of it it (never built the hardware) and it would have been fast enough for PRG, but unfortunately was a little too slow for CHR. CIC was not possible because that MCU must always bootload (it's RAM based), so you have to wait 500msec on powerup. I mostly wanted it for CHR, PRG wasn't interesting enough, so I ditched it. But if the Prop2 is ever produced (and is faster), it could become a potentially very powerful CHR-RAM. Those CPUs can have zero latency for this because instead of needing to poll or have an interrupt, you just have a dedicated CPU core run a "wait until input equals" instruction. But imagine your CHR RAM having multiple 6502 cores (emulated) inside it.. why not move metatile rendering into it, or have entire level data in it and have the NES write scroll values to it, or perhaps another core could handle hit detection if you sent it object coordinates. Instead of dual-port, it's like octo-port memory. I better leave something for the NES to do, hehe.

I'm not familiar with ATMega at all, but with the PIC32 I believe if you're willing to write branch-less code (just a string of LDA #xx / STA $2007 can be useful), it should be possible for PIC32 to feed code/data directly to the NES via DMA transfers to it's parallel port, which would free up the PIC32 CPU for other tasks. Perhaps that could work on chykyn's ENIO CPU board.

[Dwedit]

This thread got me thinking...
What if the Game Genie had been designed to use the internal CHR RAM instead of some huge pixel logic gates? It could have had much nicer graphics for the code entry screen.

[tepples]

What if the Game Genie had been designed to use the internal CHR RAM instead of some huge pixel logic gates? It could have had much nicer graphics for the code entry screen.

But then we wouldn't have something to compare the graphics of the Bad Apple demo to

How do you think you could do better with 64 tiles than Codemasters did with 16? Mockup plz

[exdeath]

32 bit MCUs as CHR-RAM lol. Could do 3D and BlueRay decoding if you wanted. MCU just renders to RAM that the PPU displays. Only problem is the worst limitation that cannot be circumvented, the 13 color limit and attributes

Would be interesting on a SNES though in mode 7. Use a cart based MCU to do whatever you want and just write the result to the mode 7 linear frame buffer straight to VRAM via B bus. Console itself just acting as a display DAC and input processor really.

[exdeath]

But then we wouldn't have something to compare the graphics of the Bad Apple demo to

Is there anything special going on here other than just streaming nametable deltas?

[tepples]

But then we wouldn't have something to compare the graphics of the Bad Apple demo to

Is there anything special going on here other than just streaming nametable deltas?

Nope. I RE'd the entire data format a couple days ago. It's just that Game Genie and Bad Apple help people understand what I mean when I talk about a 64x60 pixel frame buffer in the nametable.

[exdeath]

But then we wouldn't have something to compare the graphics of the Bad Apple demo to

Is there anything special going on here other than just streaming nametable deltas?

Nope. I RE'd the entire data format a couple days ago. It's just that Game Genie and Bad Apple help people understand what I mean when I talk about a 64x60 pixel frame buffer in the nametable.

I see, so the application here is only using internal name table VRAM and creating/loading 16 tiles in software without need CHR-ROM at all. Thats not possible without at least a jumper card or something in the CHR-ROM slot to toggle CIRAM on CHR-ROM reads is it.

[lidnariq]

I go on vacation for two weeks and this entire thread happens...

After completely disassembling Galaxian, I went and started work on a version of it ported and stripped down to what's here called the PA13 variant/what I called "micro7" because of its ability to be emulated as AxROM.

I got distracted before I finished it (although it mostly works)­, and I had to throw away lots of things to make it work (some animation, non-noise sound). I obviously won't post it here; it's a sufficiently invasive change that an IPS would necessarily contain the entire ROM. (I could post a par2 but see also "buggy")

[lidnariq]

Also, this was discussed a while back