Here's something that I wanted to do since I first dealt with the NES in 2004. A single-chip cartridge. It can address max 32Kbytes PRG-ROM, and uses the internal 2Kbyte Name-Table RAM as CHR-RAM. The idea is also mentioned on the nesdev wiki, but as far as I know nobody has ever implemented it for real. So this should be the first ever working & totally handmade prototype cartridge:
Attachment:
NocashSingleChipComponentSide.jpg [ 30.58 KiB | Viewed 18838 times ]
Attachment:
NocashSingleChipSolderSide.jpg [ 35.87 KiB | Viewed 18838 times ]
The handcut edge connector with copper contacts isn't perfectly plan, and gold contacts might also help making it more reliable. As it's now, it is working only when pushing the cartridge around until all pins are having good contact. The other two things I've learned are that the pins must have 2.50mm pitch (2.54mm won't work), and that the PCB should be only 1.2mm thick (the proto is 1.5mm, inserting it - and especially removing it - works only with extreme force; like needing to use a pair of pliers to get it pulled back out of the NES).
The game being made for testing the cartridge is here:
http://nocash.emubase.de/magicflr.htm - the NES version of the Magic Floor game that I've also ported to a bunch of other systems. It's a simple search game, somewhere between addictive and annoying. The binary is only 4Kbytes, and the CHR graphics are nicely fitting into 1Kbyte (the unused half of the 2K name table memory). The current version works both on the above cartridge, as well as normal NROM game (with 8K CHR-RAM instead of the name table RAM), so you can also test it with existing hardware or emulators.
The jumper is allowing to strap the VA10 name table address signal to PPU address lines A10, A11, A12, or A13. Which may all have some benefits. A10 and A11 would be the normal Vertical/Horizontal mirroring - that may be useful when using both Name Tables (where one would need to squeeze CHR data into unused NT locations), and may be also useful for using the whole 2K as OBJ memory (without using the BG layer). A12 would be One-screen BLK0 (with both BLK0 and BLK1 mapped as CHR-RAM). And A13 would be the most common case: One-screen BLK1 (with only BLK0 mapped as CHR-RAM).
Ah, and the name table chip select is simply this: /VCS wired to GND (so the 2K RAM is always selected).
EDIT (27 sep 2012): The corresponding mapper is now defined here:
http://wiki.nesdev.com/w/index.php/INES_Mapper_218
I'm glad to see someone finally building this.
The next question is how to emulate this. The obvious signal for this would be an NES 2.0 header with zero CHR ROM and zero CHR RAM, but that leaves what sort of mirroring to choose. Can't A12 already do everything A13 does, plus the ability to enable rendering late or disable it early to add a few more tiles?
Getting an own mapper number for it would be coolest
For the VA10 mapping, UNIF can define all four modes (Two-Screen H/V and Single-Screen BLK0/BLK1). The normal NES format can define only Two-Screen H/V... I was thinking of using the "Four Screen" flag here. Like so:
Code:
VA10 Effect on iNES Byte 6 UNIF "MIRR"
to Name Tables Bit3.Bit0 Bit7-0
PPU.A10 Two-Screen, Vertical Mirroring 0.1 01h
PPU.A11 Two-Screen, Horizontal Mirroring 0.0 00h
PPU.A12 One-Screen, BLK0 1.0 02h
PPU.A13 One-Screen, BLK1 1.1 03h
That would be of course only working if it's having it's own mapper number. When assigning it as "Mapper 0" then Bit3 would mean "NROM with Four-Screen". Otherwise, with the own mapper number, it's pretty clear that the board cannot have memory for Four-Screen, so one could misuse the bit as "One-Screen" flag in that case.
A bit messy, but it's the best solution I could think of.
Hmmm, now that you say it, A12 could in fact do anything that A13 can do.
Having the ability to define both A12 and A13 would be nice because A13 is a bit "straighter" than A12 (having the memory more clearly divided into NT and CHR-RAM). Oh, and with A13 the CHR-RAM is mapped to 0000h - with address LSB and MSB both 00h - that can save two "valuable" bytes of program code. That's maybe not too much saved memory, but the mapper might be a nice platform for people trying to squeeze as much of code into as less memory as possible. So other people might prefer A13, too.
Mapper 7... like AOROM?
No, that one allows to select BLK0 or BLK1 via the mapper (by software).
In this case, it's a "hardwired" selection, needs to be stored somewhere in the ROM image header.
It's cool someone eventually build a board that does this. I was actually going to make a board that does exactly this as well but with something slightly different - I was going to allow vertical and horizontal mirroring as usual exept the second nametable would be hardwired as blank - the internal chip disabled, and pull-down resistors to ensure the lines are at GND. This would allow to use one namtable normally + one blank nametable, and to have 64 tiles plus a blank tile.
I was actually going to make a game for this configuration, and to make it as "normal" as possible, that is it shouldn't have crappy graphics that would make the player immediately think "oh this game is ugly because it has only a single chip".
I won't tell more because it's trade secret
PS : Oh and I emulated it using mapper 0 simply, I just made sure to restrict myself to a single nametable and 64 tiles, which is pretty simple to do. Of course if I would rely on mirroring of tiles, it would break the emulation, but obviously I would not want to do this !
I was suggesting that you use Mapper 7 for testing on many emulators, because you get CHR-RAM and single screen mirroring. Specifying Mapper 7 is the most direct way to request single screen mirroring for simple roms on any emulator. As long as you don't actually try to use the extra hardware features (like the remaining 6k of CHR RAM, and second nametable), it would run just the same as a mapper that restricts them.
Looks like NES 2.0 doesn't let you explicitly specify single screen mirroring in the header. Did anyone ever decide on a mapper number for this?
If nobody else decides, I'd say make it NES 2.0 submapper of mapper #7, so old emulators can still play it.
So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this. I guess that with heavy CHR updating it wouldn't look so dull, just "minimalist". Flipping would surely help make the most out of the sprites, and the background patterns could gradually change as the player progresses through the level. Palette swaps could also add some more diversity to the graphics. Suddenly I feel like making a mock-up according to these limitations!
An unmodified mapper 7 ROM should work on this board as long as the limitations are respected, since the write to $8000-$FFFF necessary for selecting mirroring would be ignored. 32KB of ROM would be tough for a platformer though, because of all the level maps and such. I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM (and mapper 7 could still be used).
Cool stuff. I think it would be great configuration for a coding compo.
Very cool!
I like your "brute force" method of making your own 72 pin connector
Quote:
So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.
Games doesn't have to be platformers, you know ?
And don't worry I'll release an awesome game that requires a single chip someday, just leave me some time. It will look almost as good as any other NES game, as you say thank to heavy CHR updates.
Bregalad wrote:
Games doesn't have to be platformers, you know ?
But this is the kind of game I want to use to put this scheme to the test... problem?
Quote:
It will look almost as good as any other NES game, as you say thank to heavy CHR updates.
I believe games can easily look just like early NES games, and even somewhat better, but making them look like, say, Kirby's Adventure is surely not possible.
Shiru wrote:
Cool stuff. I think it would be great configuration for a coding compo.
Seconded! I'd surely do my best to participate.
Historically, a lot of old NROM games which don't use many tiles at the same time could easily have used a configuration like this if the idea would have ocurred to people. I imagine one 32kB ROM would be cheaper than 16kB+8kB back in the days, so that might have saved manufacturing costs slightly? Then again, it might not have mattered much compared to all other costs involved in making cartridge based games... especially in the NES market where the CIC was the biggest PITA...
tokumaru wrote:
So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.
This...(Stripped down, of course...My logo "Red moon games" is taking a lot of space...Text too, is not really needed.)
Quote:
32KB of ROM would be tough for a platformer though, because of all the level maps and such. I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM (and mapper 7 could still be used).
32kb is NROM size, right...? Well, Inversion have over 30 levels. The 64 tiles limit is a small problem. I might convert Inversion if there's any compo for this chip programming.
(And then release normal version as "extended" version...neat!)
Quote:
Seconded! I'd surely do my best to participate.
Yea, me too. If there will be any compo, of course.
The project itself is nice thing. Forces us to have even more limitations than NROM.
Call me crazy, but for some weird reason, I like it.
Denine wrote:
My logo "Red moon games" is taking a lot of space
It doesn't matter, because you can just overwrite these kinds of graphics between screens.
Quote:
Text too, is not really needed
Text will use what? Half of the 64 tiles we have? I think it's OK to have text as long as it's not during the actual game.
Quote:
Well, Inversion have over 30 levels.
Inversion is not a scrolling game, and each screen IS a level. In a scrolling game, a single level would be 30 screens. Also, 32KB is indeed the same amount of PRG-ROM as NROM, but since you don't have CHR-ROM anymore you have effectively less memory than NROM.
Quote:
I might convert Inversion if there's any compo for this chip programming.
If there was a compo, I would of course obey the 32KB limit.
tokumaru wrote:
It doesn't matter, because you can just overwrite these kinds of graphics between screens.
It does matter, because we have 64 tiles. Logo uses 87.
Also have no CHR ROM. So it'll take some space of PRG.
Currently, I wanted to insert one more song but, have no more empty space. So I'm trying too come up with better compression scheme.
Quote:
Text will use what? Half of the 64 tiles we have? I think it's OK to have text as long as it's not during the actual game.
Point taken. That's true.
Quote:
Inversion is not a scrolling game, and each screen IS a level. In a scrolling game, a single level would be 30 screens. Also, 32KB is indeed the same amount of PRG-ROM as NROM, but since you don't have CHR-ROM anymore you have effectively less memory than NROM.
That's true.
But I belive you just said "platformer" not "scrolling platformer", right?
On side note: I think a 30 screen level( only one way, not 4 way) is really long. Of course, it depends on how fast character moves etc. but still.
Quote:
If there was a compo, I would of course obey the 32KB limit.
Hmh, So I'll better use Famitone instead of Famitracker.(Famitracker uses considerably more space)
Denine wrote:
It does matter, because we have 64 tiles. Logo uses 87.
I see. You can just reduce the tile count instead of completely removing these screens. This kind of presentation will help the game look "normal". =)
Quote:
But I belive you just said "platformer" not "scrolling platformer", right?
You are right. But yeah, I'd like to see what kind of scrolling platformer could exist under these limitations.
Quote:
On side note: I think a 30 screen level( only one way, not 4 way) is really long. Of course, it depends on how fast character moves etc. but still.
Yes. It also depends on the kind of obstacles you have... some games have obstacles/puzzles that slow the player down quite a bit, so if you have a lot of those you can have smaller levels.
Could anything really be a single chip cartridge, since you also need the CIC?
Dwedit wrote:
Could anything really be a single chip cartridge, since you also need the CIC?
It is one reason why I think they should all be made 60-pins (there are other reasons too, including audio), and include the CIC in the 60-to-72 adapter, instead of on the cartridge.
It could have its own mapper number, it could have a UNIF name, or both or neither; but regardless, this is simple (same as an idea I had once too actually) and intend once I write a few things of DotFami then I intend to describe the mapper using that as well (just since it is a simple test of some software and documentation I am writing). Which pin will you connect CIRAM A10 to? Is it PA13?
OK here is a DotFami mapper code:
Code:
06 06 00 00 00
12 38 ; CIRAM A10 to PA13
10 1F ; enable CIRAM
01 00 00 00 ; PRG ROM
32 05 00 00 00
7E 2C ; chip select
00 2B 01 2A 02 29 03 28 04 27 05 26 06 25 07 24 ; data
08 0D 09 0C 0A 0B 0B 0A 0C 09 0D 08 0E 07 0F 06 ; address
10 05 11 04 12 03 11 02 12 21 13 22 14 23 ; address
Just writing a possible code for DotFami:
ines218.hs:
Code:
module Main (main) where {
import Language.FamicomHDL;
mapper :: Mapper ();
mapper = do {
r <- romchip 0;
rs <- parameter 0;
connectPRGaddress r (rs + 14);
connectPRGdata r;
connect prgce (chipEnable r);
pa <- parameter 1;
connect (cartridgePin pa) cirama10;
tieLow ciramce;
};
main :: IO ();
main = compile "ines218.cart" mapper;
}
ines218.map:
Code:
export ();
parameter 0 = (romsize 0) >> 15;
switch(flags & 0x9) {
0x0 { parameter 1 = 54; };
0x1 { parameter 1 = 53; };
0x8 { parameter 1 = 55; };
0x9 { parameter 1 = 56; };
};
use "ines218.cart";
Once more of DotFami specification is written and FamicomHDL is made, then we could include these on the iNES mapper articles and create a category for it (perhaps [[Category:DotFami mappers]]).
Whew, looks as if the thing is kinda inviting for a competition.
Bregalad wrote:
I was going to allow vertical and horizontal mirroring as usual exept the second nametable would be hardwired as blank - the internal chip disabled, and pull-down resistors to ensure the lines are at GND. This would allow to use one namtable normally + one blank nametable, and to have 64 tiles plus a blank tile.
Oh yes, neat idea. A little bit less low-level... but using resistors as "extra memory" is still pretty much in the low level category.
Hmmm, with some restrictions you might also get the same effect by software:
Blank the name table entries when they get scrolled offscreen (eventually with Port 2001h.Bit3=1, downside would be that you don't have a fullscreen picture).
Or, assign one BG palette as all-black (or whatever backdrop color you want), and set the color attributes in the 2nd name table to that palette number (downside would be that you could use only 3 BG palettes and only 60 tiles).
tokumaru wrote:
I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM
I was hoping to get the CPU/APU to toggle the "/IRQ" pin as extra address line (for two 32K banks), but after testing, it seems that the pin is input-only; it doesn't go low even when the APU is generating an IRQ.
Another idea would be trying to use an unused PPU address line as extra CPU address line, A12 for example. I haven't tested that, but it might be possible to control the PPU address lines when video is disabled, so one could maybe relocate PRG-ROM to WRAM during that time.
Well, and otherwise one could stay with the 32K limit, which is a lot of memory for an 8bit system. Or add some mapping, it'd blow the simple "single-chip" design, but it'd be still "single-memory-chip" - and might allow to get some really impressive graphics & sounds.
Is it okay if I assign a mapper number to the board? And (re-)define the "Four Screen" bit in the iNES header as "One Screen" bit for that mapper (as described above)?
(For now without recursing possible extensions like pull-down resistors or exceeding the 32K limit. If they get ever implemented they could share the same mapper number, as far as they don't conflict with the old 32K definition, or use another new mapper number - or stay with NROM or AOROM when exact emulation of the hardware limits isn't important).
Some potentionally free mapper numbers can be found here
http://kevtris.org/Projects/console/mappers/index.html but after googling for
nes "mapper xxx" (xxx=number), it turned out that most of them are used for this or that stuff. One number (maybe the last in the 8bit space) that seems to be still free is "218" so I guess I could use that one, right?
Btw. for the NES 2.0 mapper numbers 256..4095, I think the
http://wiki.nesdev.com/w/index.php/NES_2.0 page should contain some guidelines on how to use/invent new numbers. Like something saying that "any newly invented numbers MUST be defined in the
http://wiki.nesdev.com/w/index.php/Cate ... ES_Mappers category".
Quote:
Which pin will you connect CIRAM A10 to? Is it PA13?
The PCB could be jumpered to either PA10, PA11, PA12, or PA13 (see above for details).
And the MagicNES game, yes, it's using PPU A13.
Quote:
Could anything really be a single chip cartridge, since you also need the CIC?
Well, yes, I know, then it'd be two chips. On the other hand, the CIC isn't "directly" part of the mapper. On a Famicom it'd work without CIC, same on a modded NES (which every NES user
should have). And finally one could use that CIC-stunning circuits - don't know if newer consoles are protected against that trick, but at least that trick did exist & work with the older NES consoles - that could be implemented via transistors & capacitors without needing a second chip.
I was under the impression that CIC stun circuits such as those of Camerica and Color Dreams carts required a spare latch bit to generate the pulses.
I'd say don't redefine the "four screen" bit. It is already clearly defined, and any existing emulator that sees the "four screen" bit will provide 4 Screen VRAM.
tepples wrote:
I was under the impression that CIC stun circuits such as those of Camerica and Color Dreams carts required a spare latch bit to generate the pulses.
That would be the cost-down trick if you do have a spare latch (and enough CPU time to pulse it; which might need only a few CPU clocks per frame, I don't know how fast they are pulsing it). Otherwise it should be super-simple to make a transistor circuit that generates the pulses.
Dwedit wrote:
I'd say don't redefine the "four screen" bit. It is already clearly defined, and any existing emulator that sees the "four screen" bit will provide 4 Screen VRAM.
Would be no problem. If the emulator does support the mapper then it can interprete the header bit accordingly. And if it does't support the mapper then it won't work anyways, no matter if it sees the bit has one-screen or four-screen flag.
The other options would be assigning separate mapper number for each configuration, but I think that'd be some overkill.
Or, to allocate a new one-screen flag in the NES 2.0 header, like in bitX of byte 0Yh or so. But then the name table mapping would be controlled by 3 separate bits scattered all across the header (byte 6.bit0, byte 6.bit3, byte 0Yh.bitX). That'd be kinda messy, too. I think doing that would make sense only if more mappers need one-screen BLK0 and BLK1 mappings - which might be actually be the case (as UNIF is explicitly supporting that configuration). Are there any cartridges that are using that feature?
nocash wrote:
The other options would be assigning separate mapper number for each configuration, but I think that'd be some overkill.
Use submapper numbers if it help? (For mapper numbers 256 and more, it is not need submapper 0 for the compatibility mode, so you can use submapper 0 for your own use.) Or use the DotFami mapper codes (I have posted it above and believe it to be correct) (it is one reason why I make up DotFami). Or, even do both.
Use 60-pins cartridge that way you don't need CIC on the cartridge, you can use CIC only on 60-to-72 adapter, so you only need one CIC instead of more than one. At least, it is my suggestion (maybe you don't like it).
What Super Mario Bros 3 might look like if it had a 64 tile limit:
Also, you can animate CHR tiles easily. You can also mask off the first 8/16 lines of the screen by uploading more tiles into VRAM.
Shiru wrote:
I think it would be great configuration for a coding compo.
My first thought when I saw this. Also lots of lols at the connector.
Using extra logic for more PRG-ROM is possible, but then it's not single chip any longer, and if you go that far why not add a CHR-ROM that will be able to store some non-CHR extra data, too.
I like the idea of using a free CHR pin as an extra address line but it would probably be a little crazy to control. During rendering it could be controlled easily with the $2000 register, but during VBlank...
@Tokumaru : I have nothing against platformers, it's just the way you said it sounded like "game = (scrolling) platformer" for you. A platformer is quite needing in tiles as you need at least several tiles for the main character and several enemies and power ups. Other game genres can be done with less tiles.
Also of course it's not possible to look as good as Kirby's adventure, but I meant it's possible to look good enough so that it's not too obvious the game uses a single chip.
If people's reaction will be "hey this looks good thinking this game is the only sinlge NES/FC game that uses a single chip", then I'll have failed. However if their rections is "it looks fairly standard" then I'll be delighted.
And another trick to bypass the 64 tiles limitation would be re-writing tiles midframe. Of course it becomes a tradeoff between the extra blanking scanlines in the middle of the screen and the # of tiles being rewritten. Something like 4 more tiles could be a life saver in several situations. However I didn't plan to use that in my game.
Bregalad wrote:
Using extra logic for more PRG-ROM is possible, but then it's not single chip any longer, and if you go that far why not add a CHR-ROM that will be able to store some non-CHR extra data, too.
I like the idea of using a free CHR pin as an extra address line but it would probably be a little crazy to control. During rendering it could be controlled easily with the $2000 register, but during VBlank...
Now that I have given some more thought to this, expanding this mapper in any way that requires more components would make little sense, because the whole novelty here is the simplicity. If you're gonna add more chips you might just as well use a more conventional mapper. It would be interesting if something could be worked out using the CHR pins though.
Quote:
it's just the way you said it sounded like "game = (scrolling) platformer" for you.
It's my favorite game style, so it's only natural that it's the first one I think about. =) I do enjoy other kinds of games though, I just can't play RPGs.
Quote:
A platformer is quite needing in tiles as you need at least several tiles for the main character and several enemies and power ups. Other game genres can be done with less tiles.
Yeah, you'd have to keep power up and enemy kinds to a minimum, and make them symmetric whenever possible to take advantage of sprite flipping. Scrolling platformers might not be the most fitting for this mapper, but I believe that a decent one is perfectly possible.
Quote:
"hey this looks good thinking this game is the only sinlge NES/FC game that uses a single chip"
Most people don't know what having a single chip in the cart means... XD
Quote:
And another trick to bypass the 64 tiles limitation would be re-writing tiles midframe.
Another option, that doesn't require messing with the rendering process, is blanking one entire background palette (so you only get 3 for the game) and using that palette for a few scanlines at the top and bottom of the screen. Every 8 scanlines buys you 2 tiles, so if you reduce the vertical resolution to 192 (like in many other platforms) you get 12 extra tiles. Vertical scrolling becomes pretty much impossible though.
zzo38 wrote:
Use submapper numbers if it help? (For mapper numbers 256 and more, it is not need submapper 0 for the compatibility mode, so you can use submapper 0 for your own use.)
That would be working, too. Had the same idea last night. It wouldn't be much better/worse than using the 4-screen bit as 1-screen bit - emulators will need to interprete special header bits either way. I was thinking of the submapper bits as a last resort to be used only if something did went wrong. In so far, I would prefer to keep them reserved for such purposes.
Oh, and submapper 0 - that will be still needed to be reserved as "default" value. I am pretty sure that things will go wrong in future. The NES 2.0 format doesn't prevent people from assigning the same mapper number to different boards.
zzo38 wrote:
Or use the DotFami mapper codes (I have posted it above and believe it to be correct) (it is one reason why I make up DotFami). Or, even do both.
DotFami, like here
http://wiki.nesdev.com/w/index.php/User:Zzo38/DotFami ?
Looks powerful.
And also pretty complicated, at first glance at least.
zzo38 wrote:
Use 60-pins cartridge that way you don't need CIC on the cartridge, you can use CIC only on 60-to-72 adapter, so you only need one CIC instead of more than one. At least, it is my suggestion (maybe you don't like it).
Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.
nocash wrote:
zzo38 wrote:
Use submapper numbers if it help? (For mapper numbers 256 and more, it is not need submapper 0 for the compatibility mode, so you can use submapper 0 for your own use.)
That would be working, too. Had the same idea last night. It wouldn't be much better/worse than using the 4-screen bit as 1-screen bit - emulators will need to interprete special header bits either way. I was thinking of the submapper bits as a last resort to be used only if something did went wrong. In so far, I would prefer to keep them reserved for such purposes.
Oh, and submapper 0 - that will be still needed to be reserved as "default" value. I am pretty sure that things will go wrong in future. The NES 2.0 format doesn't prevent people from assigning the same mapper number to different boards.
You are correct it still does not prevent that (UNIF and DotFami do not have these problems). But I was thinking make a universal standard "ines.map" file (the format of this file is described in DotFami) to decode iNES headers (including NES 2.0) to select DotFami .cart files and values of external parameters. It is meant for DotFami-compliant emulators, but even emulators which do not use DotFami could use this ines.map for decoding the headers so that any new mapper numbers will be assigned here, including the decoding logic for the header, so it work. It was suggested that you must put it on the wiki under the iNES mappers category with a title "iNES Mapper ___"; so the corresponding part of the "ines.map" file (as well as the DotFami mapper codes, perhaps a Haskell program to compile the .cart (after a while I intend to make a Haskell library for doing this) (literate Haskell can be easily embedded into MediaWiki and most other formats)) can be included within the same article.
nocash wrote:
zzo38 wrote:
Or use the DotFami mapper codes (I have posted it above and believe it to be correct) (it is one reason why I make up DotFami). Or, even do both.
DotFami, like here
http://wiki.nesdev.com/w/index.php/User:Zzo38/DotFami ?
Looks powerful.
And also pretty complicated, at first glance at least.
Also incomplete. It is more complicated than other formats but also more precise, and I do try to make it simplified instead of being even more complicated than it is. There are some reasons I make it; one reason is for custom mappers, although it has other purposes too.
nocash wrote:
zzo38 wrote:
Use 60-pins cartridge that way you don't need CIC on the cartridge, you can use CIC only on 60-to-72 adapter, so you only need one CIC instead of more than one. At least, it is my suggestion (maybe you don't like it).
Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.
But then you still need adapter to play on 60-pins Famicom, so you need adapter either way. At least to me (and what I will do if I ever make the cartridges) is to make 60-pins cartridges (which might also use audio), and a 60-to-72 adapter with a CIC key (in NTSC-only mode by default but switchable to all-region), and a 72-to-60 adapter with CIC lock in NTSC-only mode (but can be turned off entirely by a switch). Also any hardware meant to play NES/Famicom games would be 60-pins (if I manufactured these, I would also manufacture the adapters so you can buy them together if you want to). (Of course, you need not follow my advice; you can do what you want, but I make this advice since I think is good idea.)
@Tokumaru : Don't worry the game I was planning to make for a single chip cartridge is not an RPG (but not a platformer either).
And I hope someday I'd do a RPG that even you like, although apparently I do less and less nesdev so unfortunatly I begin to start doubting this will ever happen.
The idea to sacrifice part of a nametable for more tiles is interesting. You say it would prevent vertical scrolling, but it is also possible to sacrify vertical borders for more tiles and sactify horizonal scrolling, or to sacrifice all 4 borders and sacrifice any scrolling. But with the additional cost of a palette (wich is 25% of your BG palettes) this is probably a very high price to pay for more tiles.
Also it'd be harder to emulate correctly, because it would mean the same RAM is mapped to both nametable and pattern tables. With the 1k / 1k approach (CIRAMA10 being wired to PPUA13) it's really an easier approach and is closer to what we're used to.
Also I don't think using any CHR line for extra PRG bankswitching is possible in a meaningful way.
A0-A9 and A13 changes all the time during rendering.
A12 has somewhat unpredictable behaviour during sprites fetching, and is always low during name table fetches.
A10 and A11 are selectable if you don't use scrolling at all and if all tiles are from the same area of pattern tables, but their behaviour is probably not predictable during VBlank, especially if you're updating VRAM (which of course you want to do).
I think with today's technology it's very possible to put a mask ROM + a custom clone of a CIC on the same chip, in fact it's even probably possible to put an entiere NROM cartridge, PRG-ROM, CHR-ROM and CIC on the same chip, but at least several thousands carts should be produced for it being made for a reasonable price per unit.
Quote:
Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.
But then you still need adapter to play on 60-pins Famicom, so you need adapter either way. At least to me (and what I will do if I ever make the cartridges) is to make 60-pins cartridges (which might also use audio), and a 60-to-72 adapter with a CIC key (in NTSC-only mode by default but switchable to all-region), and a 72-to-60 adapter with CIC lock in NTSC-only mode (but can be turned off entirely by a switch). Also any hardware meant to play NES/Famicom games would be 60-pins (if I manufactured these, I would also manufacture the adapters so you can buy them together if you want to). (Of course, you need not follow my advice; you can do what you want, but I make this advice since I think is good idea.)
You can always make your own 60 pin version if you'd like. The discussion here is irrelevant to 72 vs 60 pin.
You might argue my point and say hey 60 pin has sound! Well 72 pin has ~10 pins you could use for sound if you pleased. And I'm really interested in hearing what super awesome sound capabilities you can add without any chips... That's like saying you could add better graphics to this board if you used CHR ROM.
Quote:
I think with today's technology it's very possible to put a mask ROM + a custom clone of a CIC on the same chip, in fact it's even probably possible to put an entiere NROM cartridge, PRG-ROM, CHR-ROM and CIC on the same chip, but at least several thousands carts should be produced for it being made for a reasonable price per unit.
What would be the point to fabricate a CIC and mask rom in one? So you could spend thousands of dollars to be able to merely say there is only one chip? You can pay me thousands of dollars to bypass your CIC, and then you can say the same thing... In reality though if you ignore the need for level shifting which Hardwareman claims is unnecessary, you could just use a CPLD/fpga that has non volatile memory. Then you could have CIC, ROM, Dual ported ram, a full 8910 synth, MMC5, a spare 6502 coprocessor, and the kitchen sink in one chip for less than $20 a part. And still not have to pay fabrication start up costs...
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.
Bregalad wrote:
And I hope someday I'd do a RPG that even you like
Yours was an action RPG though, right? I kind like those. What I can't stand about RPGs is the battle system (I find fighting through menus incredibly boring), and all the useless fighting you have to do in order to level up.
Quote:
but it is also possible to sacrify vertical borders for more tiles and sactify horizonal scrolling
That wouldn't work, because you wouldn't get 16 contiguous bytes. You only get contiguous bytes if you hide horizontal areas (each row of tiles gives you 32 contiguous bytes, enough for 2 tiles), so it's only possible to sacrifice vertical scrolling.
Quote:
this is probably a very high price to pay for more tiles.
You could still gain some tiles if you mask the top and bottom of the screen by disabling rendering, the idea of sacrificing a palette was just to avoid messing with the rendering.
Quote:
Also it'd be harder to emulate correctly, because it would mean the same RAM is mapped to both nametable and pattern tables. With the 1k / 1k approach (CIRAMA10 being wired to PPUA13) it's really an easier approach and is closer to what we're used to.
Yeah, if you use mapper 7 the memory won't actually be shared between the name and pattern tables, you'll have to be careful so that things don't overlap when running on the actual 1-chip cart.
Quote:
A10 and A11 are selectable if you don't use scrolling at all
Quote:
If you chose only one type of scroll to sacrifice (either vertical or horizontal) you could still use 1 bit for bank selection, right?
Quote:
but their behaviour is probably not predictable during VBlank, especially if you're updating VRAM (which of course you want to do).
Since you only have 2KB or VRAM, that's all you be using, so you could access $0000-$07FF (A11 = 0) or $0800-$0FFF (A11 = 1) to select one of two 32KB PRG banks. For this you'd have to sacrifice vertical mirroring, right?
Quote:
Yours was an action RPG though, right? I kind like those.
Yes, but the RPG elements are pretty much limited to what is in
Mega Man X : You get new weapons from bosses and your lifebar can increase.
Yet nobody consider Mega Man X an RPG...
Quote:
What I can't stand about RPGs is the battle system [...] and all the useless fighting you have to do in order to level up.
There is infinite possibilities for various battle systems, though menus and without menus.
Tales of Phantasia and Star Ocean for instance doesn't use menus, yet their battle systems are probably worse than any RPGs that uses menu in my opinion.
As for levelling up I 100% agree with you : I hate RPGs which requires level grinding. Unfortunately lots of NES ones does, but then I just recommand people to use a cheat code to save your time.
Well designed RPGs shouldn't require the player to waste time in the sole purpose of rising his level, (unless he fled from too many random battles of course), requiring hours of level up is a flaw in design.
Quote:
Since you only have 2KB or VRAM, that's all you be using, so you could access $0000-$07FF (A11 = 0) or $0800-$0FFF (A11 = 1) to select one of two 32KB PRG banks. For this you'd have to sacrifice vertical mirroring, right?
In fact both A10 and A11 could be used, for a total of four 32KB PRG banks :
- Use tiles $00 to $3f (patterns $0000-$03ff) and nametable 0 ($2000-$23ff) : Bank 0
- Use tiles $40 to $4f (patterns $0400-$07ff) and nametable 1 ($2400-$27ff) : Bank 1
and so on.
(nb : the tiles and nametable are the same, mirrored, memory. You'd just need to address the correct mirrored version of the tiles for the sake of bankswitching)
The problems are :
- Scrolling is impossible unless you want your banks to switch "randomly"
- Bankswitching requires you not only to change the $2000 register, but also to update the entiere name table, therefore forced blanking is the only option.
- The address lines might not be stable outside of rendering, for example if the VBlank code rewrites the palette, there is no way to predict what will happen on the address lines. Even if it does nothing, I'm not sure they'll remain in the state they were in the frame.
This could be solved if all the VBlank code and all the code that uses forced blanking is duplicated in all banks.
However, that's a small price to pay for a single chip 64kb or 128kb cartridge !
Bregalad wrote:
As for levelling up I 100% agree with you : I hate RPGs which requires level grinding. Unfortunately lots of NES ones does
If I recall correctly, it was an anti-rental measure.
Bregalad wrote:
Scrolling is impossible unless you want your banks to switch "randomly"
That's what I was debating... If you want to select PRG bank 0, you can use the name tables at $2000-$27FF (A11 is always 0), and if you want to select PRG bank 1 you use $2800-$2FFF (A11 is always 1). Of course that you'd have to use matching tile indexes, 0-127 for bank 0 and 128-255 for bank 1. Changing the bank during rendering would indeed be impossible (like you said, you'd have to rewrite the name tables), but maybe you could use one bank during rendering (containing game code and data) and another one during VBlank (containing graphics and other things that can be accessed while rendering is off). Because of pattern table mirroring, you can write the tiles to one address and have the PPU read them from another, so that would be OK.
I'm not sure the address lines would be stable enough for that though... Maybe it's better we forget about this and accept this mapper for the simplicity it has. Bankswitching is sounding too complicated.
I'm confused about the goal to squeeze more memory into this setup with the CHR address line discussion. This setup is nice because it's simple and has a small amount of ROM, so why would you try to overly complicate things for more ROM.
Shiru wrote:
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.
A MCU isn't going to be fast enough for random access demanded from a ROM. You'd only have a few cycles to decode 16 inputs, retreive the data, and output to the pins. Definetly not enough time... For fun i once emulated a '161 on a UNROM board with an avr and it did work. I timed it out and i think there was less than a cycle's worth of slack for an overly simple operation and I wasn't retrieving data for the NES. I did NOT have enough time to implement the logic for the '32 in addition to the '161. You could use an AVR to feed a commanded stream of data and store it in onboard SRAM and perform all your code from there though. Not sure how well you'd be able to handle reset/interupts very well either. 2KB is pretty badly limited, you'd probably start sacrificing CIRAM for CPU use which would be a mess. The single chip 32KB starts looking pretty good at that point.
infiniteneslives wrote:
I'm confused about the goal to squeeze more memory into this setup with the CHR address line discussion. This setup is nice because it's simple and has a small amount of ROM, so why would you try to overly complicate things for more ROM.
You are probably right. The goal here is to simplify things, so if you need more than 32Kb of PRG you should probably not be using this mapper.
infiniteneslives wrote:
A MCU isn't going to be fast enough for random access demanded from a ROM.
I thought this way: AVR runs at 16-20 MHz, NES at 1.79 MHz. So we have 8-11 AVR cycles per 6502 cycle. Here is a primitive program that gets state of address lines connected to two ports, reads a byte from program memory, and puts it into third port.
Code:
loop:
in ZL,PORTA ;1
in ZH,PORTB ;1
lpm r0,Z ;3
out PORTC,r0 ;1
rjmp loop ;2=8t
Takes 8 cycles. Not sure if 6502 or NES hardware needs access to ROM every cycle, if it is, then it probably won't work.
PICS can run at like, what...40MHZ? And then they have single cycle execution for everything but branches AFAIK. Probably the better chip to go with, whatever you're discussing.
ETA: Nevermind, seems like you are talking about a equivalent instruct set chip. Carry on like I never posted this.
Shiru wrote:
infiniteneslives wrote:
A MCU isn't going to be fast enough for random access demanded from a ROM.
I thought this way: AVR runs at 16-20 MHz, NES at 1.79 MHz. So we have 8-11 AVR cycles per 6502 cycle. Here is a primitive program that gets state of address lines connected to two ports, reads a byte from program memory, and puts it into third port.
Code:
loop:
in ZL,PORTA ;1
in ZH,PORTB ;1
lpm r0,Z ;3
out PORTC,r0 ;1
rjmp loop ;2=8t
Takes 8 cycles. Not sure if 6502 or NES hardware needs access to ROM every cycle, if it is, then it probably won't work.
Few issues here first you have to know when to do this by polling ( CP, BNE 1 + 2 = 3 cycles) or or trigger off interupt (upto 4cycles) so you lose 3-4 cycles there. Let's make it easier and say you're running off the NTSC 21Mhz clk (slight over clock non-issue) this should help for worst case alignment timing. So for argument's sake we'll say 12 AVR cycles per 6502 cycle. The only way you know when the NES is accessing PRG ROM is /CE which is inverted M2 when A15 is high. M2 is only high (active) for 2/3 of the cycle. So that cuts your alloted time from 12 to 8 cycles. So from the time PRG /CE goes low you have 8 cycles to get data on the bus, assuming no setup time requirement and you're perfectly aligned with the NES. So you need 3-4 cycles to start and 6 cycles to retrieve data and put it on the bus. That's 9-10 cycles, time's up...
EDIT: oh and you forgot one very important time consuming item. You need to change the direction of your data bus register as well so you can go from tristate to output to prevent bus conflicts... 40 mhz is starting to sound even less feasible now too.
Most instructions executed from ROM read from ROM 2-3 CPU cycles in a row, (opcode, low order byte, high order byte) So you've got to do this sequence back to back. Additionally you've got even more problems if you try to sense R/W operations as you'll spend even more time looping or responding to two interupts.
Perhaps something is possible with the pic. I always thought their 40Mhz mcu's didn't have one cycle execution, according to 3gen that's not the case though. As a matter of preference I'll never touch anything besides AVR if I have a choice in the matter. Don't forget Xmega's run at 32Mhz as well.
In any event even if you somehow managed to pull it all off with overclocking or something you're still consuming ALL your time acting as a ROM, and only 32-64KB at that! Sorry but nocash still beats you... Forget about also acting as a CIC which also requires time sensitive operations and most likely cycle counting to achieve that. Toss in a few interupts for ROM and you'll miss CIC requirements... Save some time for sound, IRQs, etc? doubtful you can do it well if at all with ANY mcu.
Programmable logic is the only way to go if you want to do anything substantial with minimum (single) parts being your driving goal. The <$20 Mach XO2 cpld/fpga I suggested is the big dog, the powerful more modest one is $6-7 and could beat the pants off the MMC5 if you wanted to. But really trying to do things with ONLY one part is a silly goal aside from what nocash has built which is simple, capable, and dirt cheap.
See the Atari 2600 Harmony cartridge, it's just a 70 MHz ARM7TMDI (<70 MIPs). The NES is 50% faster than the 2600, but still it shows that it's very feasible; the 2600 doesn't even give you a clock or *any* control signal to synchronize with. Selecting a MCU with a slave parallel port will help.
Also worth noting is that the typical PIC at 40 MHz is actually 10 MIPs, some of the newer 16/32-bits are 1:1 and achieve 80+ MIPs.
STM32F205RC - $6.67 for a quantity of 100 at Digikey, this could do it. A large benefit of a MCU over a ROM here is that you can reprogram it in-system with a cheap TTL serial adapter. Kinda handy if this is intended for compos...
Somewhat comically I think a true NES flash cart emulating real mappers could possibly be developed with two fast MCU. If not today, in a few years.
I have assigned the single-chip cartridge as NES Mapper 218,
http://wiki.nesdev.com/w/index.php/INES_Mapper_218, using my initial idea for the name-table bits (iNES "four-screen" flag being interpreted as "one-screen" flag for this mapper - which should as good/bad as other solutions for the "how-to define one-screen in iNES problem".
Using an ARM CPU or the like as ROM+mapper would be cool. Not exactly the kind of low-end thing that I had in mind with the single chip idea, and probably more expensive, too (a 32Kbyte PROM should cost around 90 cents or so). But for more advanced designs it'd be nice!
From my experiences, ARM CPUs do need some waitstates for non-sequential accesses to external memory & external I/O ports, so they aren't as FAST as one might think. Maybe that applies only to the memory systems that I've dealt with (like the ARM CPU in the GBA/NDS), and raw ARM CPUs without such memory systems could faster.
Yes, the PPU address line to PRG-ROM address bus idea is pretty crazy, and would put some nasty limitations on the game. Not really recommended in most cases... On the other hand, if it does work, and if a game can deal with that limitations, then it would be extremly cool and very low-end.
I don't know if the PPU is constantly outputting the most recently used address during vblank (or when video is disabled). If it does output the address only for a few clock cycles (like during port 2007h reads), then the idea won't work at all. So that part needs to be definetly tested/verified before further dealing with the idea.
Quote:
I have assigned the single-chip cartridge as NES Mapper 218,
http://wiki.nesdev.com/w/index.php/INES_Mapper_218, using my initial idea for the name-table bits (iNES "four-screen" flag being interpreted as "one-screen" flag for this mapper - which should as good/bad as other solutions for the "how-to define one-screen in iNES problem".
OBJECTIONI mean, if anything this should be a submapper for 0 or 7, not a brand new mapper.
And the four screen flag is a four screen flag and should never be used for anything else, the iNES format is already messy enough without adding some more mess to it.
For what it's worth, I too am against repurposing bits that already have well defined meanings. I do believe it's different enough from mappers 0 and 7 to deserve its own number though, but something has to be done about the mirroring selection, since there are 4 possible settings.
Or another way:
The PA10/PA11 variant is #0 with zero CHR ROM and zero CHR RAM (which requires NES 2.0), and the mirroring bit controls which line is connected to CIRAM A10 as in standard hardwired mirroring mappers.
The PA12/PA13 variant may be given its own mapper number.
I wonder what kevtris would do.
I'd say make it mapper #7, submapper #1, so every emulator that currently exists will be able run the rom without the user manually needing to change the mapper number to 7. There are a LOT of NES emulators out there. Emulators may appear on unexpected platforms, like the TI Nspire, Playstation 1, Dreamcast, in-car DVD player, and the list goes on. Emulators are often abandoned, and modifying emulators to support a new mapper is not always a possibility.
Is it really compatible with either mapper 7 or 0 as is? Doesn't the CHR address rewiring make that impossible?
The only rewiring of the PA10/PA11 variant compared to NROM is that the PRG ROM is always disabled and the CIRAM is always enabled. Pulling the CHR ROM, cutting the CIRAM /CE trace from /PA13, and wiring it to ground is all that's needed. That's less rewiring than a typical mask-to-flash conversion.
Read above my edited message how I implemented this mapper 218 in FamicomHDL. I think this mapper would have its own number, although I don't know whether it should use mirroring bits or submapper numbers (the codes I wrote can be modified to work with submapper numbers if you want to).
I do not think it is compatible with mapper 0 or mapper 7 (although a game could be made which is compatible with multiple mappers). However there probably would be ways to make simpler mappers which use the same iNES number as some complicated one if the game is compatible with the simpler one not using all the functions.
If you do use a microprocessor on the cartridge, it might be better to still have a PRG ROM chip, and use the microprocessor for audio and video (possibly also PRG ROM bankswitching). So this would be two chips but with many functions.
Bregalad wrote:
OBJECTION
I mean, if anything this should be a submapper for 0 or 7, not a brand new mapper.
And the four screen flag is a four screen flag and should never be used for anything else, the iNES format is already messy enough without adding some more mess to it.
Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?
For the mirroring there are the 3 options that have been discussed above,
1. use the four-screen bit, which is at least roughly related for mirroring purposes, and can't conflict is case, since the cartridge cannot have extra ram
2. use the submappers, which are somewhat reserved for cases where the same mapper number has been used for different boards
3. invent a 3rd mirroring bit in the iNES header, that might make sense if other boards require single-screen mapping, too.
I think they are all equally messy. And all equally simple to implement: Read this or that bit from the header and treat it as one-screen flag. Doesn't matter that much which bit it is. But if there are plenty people clearly voting for one of the above 3 options: I could still change it.
Using different mapper numbers for the same PCB depending on the jumper settings... In this configuration it is NROM, but in that config it's AOROM... I really don't like that.
It's maybe roughly related to NROM with 0-byte CHR-ROM and 0-byte CHR-RAM, though that config might be also used for raw audio software, or web servers, or such things.
The game could be made compatible with mapper 7 (AOROM), but then the game would be required to initialize the AOROM mapper accordingly, although it's running on a PCB without AOROM mapper. Asides, then one could also declare the single chip cartridge as being a MMC1 mapper, which can be configured to one-screen mapping, too.
And anyways: after my poor soldering efforts, I want "my" own mapper number for the board
Since when have we ever assigned new mapper numbers for mirroring and ROM sizes? Heck we even used mapper 0 for NROM-368 (can never remember the number..) and it required an actual mapper chip and separate logic to work. Based on Kevtris' verdict on that I bet I can tell you what he'd say. If you get his opinion I say just go with it and end the debate.
This is really a subset of NROM as I see it which validates choice 2.
We don't have many mapper numbers left, no offense, but it's hardly worth it's own number IMO.
I agree with dwedit is saying to a point. However nothing is stopping one from denoting mapper 7, initializing the logic that isn't there properly and then not using all of the resources available if you want your game to be more compatible. A new mapper number certainly isn't going to solve the issue dwedit brings up either.
Don'cha think this discussion is getting a little heated for what it is?
zzo38 wrote:
Read above my edited message how I implemented this mapper 218 in FamicomHDL
Y U NO STOP PLUGGING EVERY POST? NOBODY REPLYING
kyuusaku wrote:
Don'cha think this discussion is getting a little heated for what it is?
Probably true, but that's what we do best around these parts! Argue about mapper technicalities that usually never see the light of day in a released game
infiniteneslives wrote:
Since when have we ever assigned new mapper numbers for mirroring and ROM sizes? Heck we even used mapper 0 for NROM-368 (can never remember the number..) and it required an actual mapper chip and separate logic to work. Based on Kevtris' verdict on that I bet I can tell you what he'd say. If you get his opinion I say just go with it and end the debate.
This is really a subset of NROM as I see it which validates choice 2.
Well, NES 2.0 allows you to specify no CHR RAM, so if it is NES 2.0 then it would be a case of mapper 0 although you would still need something new in order to specify connecting CIRAMA10 to PA12 and PA13.
(Also, the wiki specifies the mirroring for UNIF, but does not specify a mapper name for UNIF.)
I'm beginning to understand why MMC6 never got its own mapper...
Quote:
Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?
I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).
After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious to be wasted on something that can easily be implemented using existing mappers, and that iNES flags shouldn't be reassigned to new uses like this.
If someone will do something crazy like I and tokumaru were talking about (using more than 32kb on a single chip cart) then definitely a new mapper will be neccesarly. But for a 16k or 32k mapper, mappers 0 or 7 will do the trick very fine, as long as authors are careful not to rely on mirroring (that is, restrict to the usage of tiles 0-63, and don't display the unused nametable if mapper 0 is chosen).
Bregalad wrote:
Quote:
Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?
I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).
After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious to be wasted on something that can easily be implemented using existing mappers, and that iNES flags shouldn't be reassigned to new uses like this.
If someone will do something crazy like I and tokumaru were talking about (using more than 32kb on a single chip cart) then definitely a new mapper will be neccesarly. But for a 16k or 32k mapper, mappers 0 or 7 will do the trick very fine, as long as authors are careful not to rely on mirroring (that is, restrict to the usage of tiles 0-63, and don't display the unused nametable if mapper 0 is chosen).
Quote:
I'm beginning to understand why MMC6 never got its own mapper...
In fact the MMC6 is just the MMC3 and some extra features in a single chip, right ?
MMC6 is just MMC3 with a particular method of PRG RAM enabling. It can be distinguished from MMC3 in NES 2.0 based on PRG RAM size. Likewise, the only difference between NROM and the PA10/PA11 variant of this poor man's OneBus is 1. the CHR holes are unpopulated and 2. CIRAM /CE is grounded. That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.
tepples wrote:
NROM and the PA10/PA11 variant of this poor man's OneBus is 1. the CHR holes are unpopulated and 2. CIRAM /CE is grounded. That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.
3. VRAM A10 is connected to PA13. (Unless you *want* two screens and don't mind continuously relocating your tiles to offscreen parts of the nametable, that would be hardcore.)
How about using BNROM for the horizontal/vertical mirroring variants and AxROM for the single screen variants? iNES 2.0 submapper codes would indicate that the ROM actually belongs in this single chip cart, but emulators not aware of this cart or even iNES 2.0 would still run the games (as long as the programmer didn't abuse the mirroring, in which case an emulator aware of the single chip cart would have to be used). This is the cleanest solution I can think of.
EDIT: Well, there's still the problem that the iNES header doesn't allow the selection of which name table to use with single screen mirroring on AxROM, since this is controlled by the mapper. Would repurposing the H/V bit (which would only work on emulators aware of the single chip cart, to be compatible with AxROM the game would have to perform a mapper write to select a name table) be as frowned upon as repurposing the 4-screen bit like nocash suggested?
Quote:
I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).
After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious...
Glad that you don't see it too critical! I somehow thought I was asking for opinions... maybe I haven't made my questions and suggestions clear enough.
I think mapper 218 was in fact that LAST completley unused number in the 8bit space. But there are still 3840 free numbers in the NES 2.0 format, which is predicted to be enough until "next ice age". Nothing to be worried about for now.
Quote:
How about using BNROM for the horizontal/vertical mirroring variants...
EDIT: Well, there's still the problem that the iNES header doesn't allow the selection
What? BNROM, like mapper 34, as also shared for NINA-001?
Why not assigning it as 110-in-1 multicart apper, and indicating the special hardware variant by using .pdf as filename extension? ;-)
Yes (on the EDIT) that's the problem with AOROM.
Quote:
Would repurposing the H/V bit ... be as frowned upon as repurposing the 4-screen bit like nocash suggested?
I would guess, yes. :-)
nocash wrote:
What? BNROM, like mapper 34, as also shared for NINA-001?
I have no idea how NINA-001 got assigned the same mapper number. The NINA can be detected by the presence of CHR-ROM, which the single chip cart doesn't have, so this is not a problem.
Quote:
Why not assigning it as 110-in-1 multicart apper, and indicating the special hardware variant by using .pdf as filename extension?
... My suggestion was an attempt to use the simplest mappers (both BxROM and AxROM use a single discrete logic chip for a mapper) that are supersets of the different configurations that are possible on the single chip cart in order to make it as compatible as possible. It wasn't just a crazy random suggestion to avoid taking the last unused iNES mapper number.
Quote:
Quote:
Would repurposing the H/V bit ... be as frowned upon as repurposing the 4-screen bit like nocash suggested?
I would guess, yes.
Though so.
Now that I realize you were proposing that people don't "abuse" the CHR mirroring, Bregalad, I understand more clearly why you are suggesting mappers 0/7.
I was thinking that the CHR mirroring was actually an important part of this (not "abuse"), especially for people who would want to do some limited scrolling, or something like that, and that kind of thing would require a new mapper that properly supports it.
Another suggestion: if using mapper 7 to get single screen mirroring, you should write $8000-FFFF once to set the screen, in case someone wants to run it on an actual AxROM.
Why ?
On actual AxROM, the screen will be selected randomly and be kept while the system is powered on - a non-issue really.
In fact mapper 7 is probably the best, but 0 makes more sense for the circuits I was going to make where the chip would be disabled when A10 or A11 is high, pull-down resistors taking over the CHR data lines, effectively having a nametable automatically filled with tile #0, and having some automatic blank tiles.
All emus I've ever tried default nametables blanked with tile #0 and default unused tiles of CHR-RAM with blank tiles (which is never the case on real hardware), but any ways this would make my game compatible with the vast majority of emulators wile using mapper 0.
If I encounter issues I could just remove the resistors and deal with one-screen mirroring and only 64 tiles, with mapper 7, still 100% compatible with current emus.
rainwarrior wrote:
Now that I realize you were proposing that people don't "abuse" the CHR mirroring
By "not abusing the mirroring" I meant people should still use $0xxx/$1xxx for patterns and $2xxx for name tables, even though the single chip cart makes the tables accessible through mirrors (i.e. the name tables are also visible at $0000-$1FFF, and patterns also at $2000-$2FFF). In fact, patterns and name tables are mixed together, and only the NT mirroring and tile indexes used make a difference over what the VRAM is used for.
Quote:
I was thinking that the CHR mirroring was actually an important part of this
It's important in the sense that it introduces a number of limitations that don't exist in traditional configurations, but I don't really see any advantage in abusing the mirroring.
Quote:
if using mapper 7 to get single screen mirroring, you should write $8000-FFFF once to set the screen, in case someone wants to run it on an actual AxROM.
Yeah, I said that a couple of times. The ROM write would be harmless on the single chip cart, but would make sure that the correct name table was selected in AxROM.
Quote:
By "not abusing the mirroring" I meant people should still use $0xxx/$1xxx for patterns and $2xxx for name tables, even though the single chip cart makes the tables accessible through mirrors (i.e. the name tables are also visible at $0000-$1FFF, and patterns also at $2000-$2FFF). In fact, patterns and name tables are mixed together, and only the NT mirroring and tile indexes used make a difference over what the VRAM is used for.
Well this would be weird. Unless we want to do something like what you described (blanking portions of the screen for extra tiles), I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged. At least that's how I've always imagined the single chip cartridge.
Bregalad wrote:
I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged.
They will always be merged. Accessing $0000 will be the same as accessing $2000 no matter what you do. In practice, you could do all your VRAM updating (except for palettes) using $0000-$07FF, half of it being for patterns and the other half for a name table. If you do that, however, games won't work with mappers 0 or 7, or any other mapper really (except the newly created 218).
Quote:
I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged. At least that's how I've always imagined the single chip cartridge.
Yes, would be most likely case. I tried to make it flexible enough to work with different games, hence to options for using A10, A11, A12, or A13, with their advantages as described at the begin of this thread.
Quote:
you could do all your VRAM updating (except for palettes) using $0000-$07FF
Yup, for A10. Or elsewhere when using A11-A13. Of course it would be a bit weird to make a program that does actually
rely on that mapping - more commonly one would access the name table at 2000h, as usually.
Still, for testing/developing games, it'd be nice if the emulator reproduce the exact mirroring. Not sooo much for intentionally using uncommon mirrors, but for seeing problems when accidently smashing something by writes to mirrors.
When making single-chip games, my focus on the mapper number would be to indicate that - hey - this thing works without memory mapping hardware and without CHR ROM/RAM! Declaring it as AOROM with CHR-RAM and mapping hardware would be somehow masquerading the programming efforts needing for squeezing into NT memory.
Allowing the game to run on older emulators would be nice, too. You could just release a second version of the game that works as normal NROM or AOROM or some other widely supported mapper type.
tepples wrote:
That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.
This much I agree too; it does make a lot of sense! The problem is making it with PA12 and PA13 (I think iNES is the only format having this problem!!). Some possible solutions are:
- Use submapper 1 for PA12/PA13.
- Add an extra mirroring bit to iNES format to specify PA12/PA13 instead of PA10/PA11.
- Ignore it and just make the game work with other mappers as well as the single-chip.
- Make a multiple versions of the game, some working on any emulator and other require to use this special cartridge (or an emulator which emulates it).
- Use UNIF and/or DotFami format instead of iNES. With UNIF, you should be able to add additional values to the mirroring chunk to specify these kind of things.
- A combination of these.
Each one has its own advantages and disadvantages.
I was thinking some more about the 4 mirroring modes, and came to the conclusion that connecting A13 to CIRAM A10 isn't so versatile, because it doesn't allow parts of the name table to be used for patterns. When accessing $0000-$1FFF (A13 low) the lower 1KB is always selected, meaning that only this part of the memory can be used for patterns. Accessing $2000-$2FFF (A13 high) is the only way to access the upper 1KB, which is always used as a name table.
By connecting A12 to CIRAM A10 however, you can actually use $0000-$0FFF for patterns in the lower 1KB (which is also where the name table will be), and $1000-$1FFF for patterns in the upper 1KB. So if you set the background to fetch tiles from $1xxx and use 8x16 sprites, you can use a few extra tiles from $0xxx for sprites.
A11 and A10 are more restrictive in terms of scrolling (you'd scroll into the patterns if you scrolled both vertically and horizontally), but they're more versatile in terms of tile usage. Even if you use 8x8 sprites, you can still easily access patterns anywhere in the 2KB of RAM available, and these tiles can be used for sprites and backgrounds.
After considering all this, I'd probably use horizontal mirroring (A11) or single screen A (A12) in a project that used this mapper, in order to have the possibility of trading name table bytes for extra patterns, while still being able to scroll horizontally.
Anyway, my point is that although A13 provides the cleanest configuration (with complete separation of patterns and name tables), this configuration happens to be the one that doesn't offer the possibility of reallocating resources, so I'm not sure it would be the "most common case", as it says in the OP.
Quote:
They will always be merged. Accessing $0000 will be the same as accessing $2000 no matter what you do.
Not at all. Just think again. I map PPU A10 to CIRAM A13, which means there is 1k of RAM visible (and mirrored multiple times) at $0000-$1fff, and another 1k of RAM visible (and mirrored multiple times) at $2000-$3fff
Quote:
Anyway, my point is that although A13 provides the cleanest configuration (with complete separation of patterns and name tables), this configuration happens to be the one that doesn't offer the possibility of reallocating resources, so I'm not sure it would be the "most common case", as it says in the OP.
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.
Bregalad wrote:
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.
Quote:
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.
Quote:
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).
nocash wrote:
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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.
nocash wrote:
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.
Quote:
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?
Quote:
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).
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.
Shiru wrote:
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.
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.
Dwedit wrote:
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
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.
tepples wrote:
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?
exdeath wrote:
tepples wrote:
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.
tepples wrote:
exdeath wrote:
tepples wrote:
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.
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")
Also, this was discussed
a while back
What about making a 0 chip cartridge (or half chip) - the game would have just one prg-rom chip, but quickly after running, it would copy itself into internal nes ram and start executing itself from here. The cart could be then removed and the game wouldn't break. Ook, removing the cart would break the graphics as the vrom !cs line wouldnt be any longer connected to gnd, but then you could insert specially prepared pcb that contains only two jumpers - one that connects vrom !cs to gnd and the second that connects vram a10 to pa13.
Chris Covell's TapeDump utility does something like this, but you have to disable the CIC to get it working on a frontloader.
krzysiobal wrote:
What about making a 0 chip cartridge (or half chip) - the game would have just one prg-rom chip, but quickly after running, it would copy itself into internal nes ram and start executing itself from here. The cart could be then removed and the game wouldn't break.
This has been done on the Atari 2600 a while ago (
link), which is pretty impressive considering it has only 128 bytes of RAM.
Now, looking at this thread again... We never had a compo of games for the single-chip cartridge, did we? That would've been a fun one...
I'm curious, how would a single chip cartridge behave on a SOAC clones? I know that those clones have problems with 4-screen because the system fails to select cart RAM for nametables, but will they fail the other way and fail to select the internal ram for CHR?
Yeah. Those particular Famiclones short
CIRAM /CE to
PPU /A13, so the 2KiB of RAM is always enabled for nametable fetches and always disabled for pattern fetches, meaning that this CHR-less design won't work on them.
On Famiclones that retain the NES's multiplexing of the PPU data bus, all the tiles will be the open bus pattern:
Code:
abcd2000
abcd2003
abcd2030
abcd2033
abcd2300
abcd2303
abcd2330
abcd2333
where abcd = the low four bits of the tile that's being fetched (in colors 0 and 3)
On famiclones that don't, all the tiles would be a repeat of the fetched attribute table byte, so each 32x32 pixel zone would be the same 8 wide x1 high pattern, and it would be a function of the colors chosen for each 16x16 zone.
On the other hand, I don't actually know just how widespread this particular famiclone bug is. Clearly enough that it's well documented, like the reversed duty cycles bug.
I've update Magic Floor, and released another single-chip game: Starfight.
Magic Floor is now using DMA for OAM access, that should fix the NTSC drawing issues. The random generator does now start with smaller floors which is making the game a bit easier. The boulder is now a bit larger (the old 8x8 pixel boulder looked a bit lost on the 32x32pixel floor cells). And, with that minor changes, the ROM image grew to about 1020h bytes : / not so much a problem, but I was troubled by the idea of releasing something that's missing the 4K boundary by only 20h bytes, so I've added the decompression function from Starfight in there, too.
http://problemkaputt.de/magicflr.htmI've also added two gif's and a link to tepples' Magic Floor gameboy version on the above webpage (hope that's okay). That version comes up with several nice additions (which, no, I don't have them adopted in the NES update - maybe I'll do so someday).
Starfight is an old Amstrad CPC 4Kbyte type-in shoot-em-up game made by Herve Couppe. I've released Gameboy and ZX81 ports of the game some many years ago. So, now there's also a NES port. It's using only 64 tiles, so it's working fine as mapper 218 (in fact it's barely using half the tiles at once, so there would be still room for more graphics). Sprites, colors, and sounds are more or less same as in the original CPC version. The game takes up about 1100h bytes, after adding a decompression function it grew to almost 1200h bytes - but after applying actual compression I got it down to less than 1000h bytes (no requirement for mapper 218, but I like 4Kbyte games). The problem about compression was that the NES has only 2K main RAM, so I had to split the game to three compressed 'overlay' snippets (tile data, title screen, and game engine).
http://problemkaputt.de/starfigh.htmApropos, does somebody know how to contact the original author in france? I've never found a contact address anywhere. Except, there's a video for the ZX81 Starfight version on youtube with a comment from somebody called Herve Couppe, so maybe that's him, but I don't have a youtube account, and don't even know if youtube has some sort of PM function(?)
TestingStarfight and the Magic Floor update are both untested on real hardware (I've recently lost my home and my own PAL NES is now buried under tons of cardboard boxes, and I don't have a NTSC NES anyways). Would be nice if somebody could jump in and test the games on PAL and NTSC consoles. If you don't have mapper 218 hardware, anything with CHR-RAM should also work (eg. NROM mapper 0 with CHR-RAM, or AOROM mapper 7). The game source code allows to change "mapper_no" to that values (and can be then reassembled via Utility/Assemble File in no$nes.
Ah, yes, and I've released a new no$nes update today, see here:
viewtopic.php?f=3&t=17959
I still think that Mapper 218 should have been a NES 2.0 submapper of 7, so that every emulator in existence would already support it. Otherwise, I need to grab a hex editor and change the mapper to 7 myself.
edit: Trying to figure out what is breaking it on certain older emulators... Some emulators refuse to emulate mapper 7 without expanding the rom size to 32k. Some emulators are showing no nametables at all. Oddly enough, it works perfectly on Nesticle.
nocash wrote:
Magic Floor is now using DMA for OAM access, that should fix the NTSC drawing issues.
It does. I replaced the mapper number with 0 (NROM) + vertical mirroring, and it worked on my PowerPak the first time. I realized after completing a few floors that I had "got gud" since the first time I tried it. It must've been all the practice on the Game Boy port.
nocash wrote:
And, with that minor changes, the ROM image grew to about 1020h bytes : / not so much a problem, but I was troubled by the idea of releasing something that's missing the 4K boundary by only 20h bytes, so I've added the decompression function from Starfight in there, too.
http://problemkaputt.de/magicflr.htmI've also added two gif's and a link to tepples' Magic Floor gameboy version on the above webpage (hope that's okay).
Certainly.