8T-ROM - new NES board prototyped

The Membler Industries, Strangulation Games, and Strangulation Records forum.

Moderator: Moderators

User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

8T-ROM - new NES board prototyped

Post by Memblers »

You can call it "eight tee" or "infinite turkeys", something like that. :)

Not for sale yet.. this is just the prototype and I'm about to put it through a lot of tests.

I got the boards this week and have soldered this one, built the JTAG cable for writing the CPLD (verified), currently I'm writing a full test program so I can verify if it works. Once that is settled, if I don't need to redo the board, next step will be releasing a PowerPak mapper file. Once there are enough demos/test ROMs, then emulator support should be possible.

Image
For larger images, see here:
http://membler-industries.com/memblers/ ... G_2089.jpg
http://membler-industries.com/memblers/ ... G_2091.jpg
http://membler-industries.com/memblers/ ... G_2092.jpg

There is a CPLD, but this is not a universal type of board. It's not a clone of any mapper, but I'd say it is most similar to MMC2 and MMC4 because there are PPU 'interrupt' tiles that can be used to automate CHR banking at nametable grid (BG) or scanline (sprite) precision.

Basic mapper specs:
  • 512kB PRG-ROM - 16kB PRG page size (either can fixed, or both paged, 32kB mode also possible). Flash memory - 4kB sectors.
  • 32kB CHR-RAM - 1kB CHR page (smaller CPLD can use 2 * 2kB paged, 2 * 2kb fixed)
  • 32kB WRAM - 8kB page size
  • 8 control registers at $5000 - $5038 - 4 bits wide
  • NES Expansion port enable - creates 4 8-bit ports, NES can read or write to an expansion port device at $5038,$5039,$503A,$503B - for use with future synthesizer, network adapter, ?? (this requires front-loader NES though). Unfortunately, enabling this feature requires changing jumpers on the board and different firmware.
  • Automated CHR bankswitching, also a CPU IRQ function (that comes with some side-effects, though)
  • H/V/single0/single1 mirroring control register
Stuff that remains to be implemented, but should be do-able (not all at once though):
  • 8 * 1kB CHR banking
  • CPU cycle timer
  • 4-screen mirroring, nametable bankswitching (either one requires changing jumper on the board)
To accompany this cartridge, I'm working on some communications software that will provide various functions, most importantly loading ROMs. I talked with blargg about his bootloader and I think we both came up with some pretty cool ideas.

Because of that, the USB adapter I'll build may have any (hopefully all) these features (I'll make another thread for this later):
  • NES controller port to USB
  • hardware flow control mode
  • software flow control mode
  • external reset - it needs NMI and/or IRQ/BRK activity, will fail if NES CPU is locked up - reduces need to manually reset NES during testing
  • plus various software-based features (supported in Windows, should be portable to OSX and Linux) - so far only the serial communication is platform dependent.
So yeah, the PLCC socket is just for testing, pretty soon I'll try to make a kazzo script so I can solder a blank chip on, then write a bootloader onto it.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

What can I say, very very cool stuff! Can't wait to get my hands on this. Hopefully this thread will not go unnoticed under this rarely used sub-forum.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

Interesting to see a new dev board. I guess it won't get a famicom treatment since the crowd is too small for it.

Time to get back someday a toaster nes! I miss my square controllers.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8T-ROM - new NES board prototyped

Post by tokumaru »

Sounds like a cool mapper, I'm very interested!
Memblers wrote:512kB PRG-ROM
Not great, because this has to be used for both PRG and CHR, since the board uses CHR-RAM. This means that some of the last commercial NES games are bigger than what this board can do, so theoretically we can't surpass a few titles made back in the 90's in some aspects, which is a bit of a let down.
32kB CHR-RAM - 1kB CHR page (smaller CPLD can use 2 * 2kB paged, 2 * 2kb fixed)
Wait, there's only 1 switchable 1KB slot? That doesn't make much sense, but based on the list of "stuff that remains to be implemented" (where you say "8 * 1kB CHR banking") it does sound like it. In this case I'd much rather have 2 2KB fixed + 2 2KB switchable.
Automated CHR bankswitching, also a CPU IRQ function (that comes with some side-effects, though)
Automated CHR switching is nice and all, but not very useful. I can't think of any other use for this other than drawing title screens, cutscenes or status bars. An IRQ function on the other hand, can be used to switch tiles as well as for many other useful effects (scroll splits, color emphasis changes, etc). So, if the automatic switch is just a way for lazy programmers to avoid manually doing the bankswitching, I'd rather give up that feature and improve some other aspect of the mapper (possibly the IRQ function).

Also, I'm interested in what the "side-effects" of the IRQ function are.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8T-ROM - new NES board prototyped

Post by tepples »

tokumaru wrote:
Memblers wrote:512kB PRG-ROM
Not great, because this has to be used for both PRG and CHR, since the board uses CHR-RAM. This means that some of the last commercial NES games are bigger than what this board can do, so theoretically we can't surpass a few titles made back in the 90's in some aspects, which is a bit of a let down.
Half a meg is as big as Mega Man 5 and 6 and Super Mario World. Kirby's Adventure is the only licensed NES game bigger than this. But perhaps you can extend it a bit with the Codemasters-derived codec that you RE'd.
32kB CHR-RAM - 1kB CHR page (smaller CPLD can use 2 * 2kB paged, 2 * 2kb fixed)
Wait, there's only 1 switchable 1KB slot?
I chatted with Memblers about this at MGC back in March. It's sort of a compromise between ability to rewrite a few CHR tiles every frame during downtime (Battletoads style) and ability to rotate CHR (SMB2/SMB3 style). Choose one method for sprites and the other for background. More switchable slots means more state bits on the CPLD, and state bits get expensive on 5.0 V CPLDs.
Automated CHR switching is nice and all, but not very useful. I can't think of any other use for this other than drawing title screens, cutscenes or status bars.
That or text in an RPG, if it's anything like MMC2/MMC4. Dedicate one bank to a 128x32 pixel pseudo frame buffer, as in Faxanadu or Super Bat Puncher, and you can use it draw dialogue with mid-scanline bank switching.
Last edited by tepples on Sat Oct 22, 2011 11:30 am, edited 1 time in total.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Sounds pretty good to me, almost everything I personally wanted. 2KB eatra nametable RAM and you'd totally please me if I were to pick a custom developer board for sure. Sweet stuff memblers, I hope this satisfies most people's needs. :)
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

I too like chr-rom, but I guess it would be easier for me to make my chr-rom game chr-ram than it would be for anyone else to do vice versa. I take it the WRAM can't be battery backed?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

3gengames wrote:2KB eatra nametable RAM and you'd totally please me if I were to pick a custom developer board for sure.
Four screen mirroring could, at least in theory, use some of the available 32K CHR-RAM for nametables.
Kasumi wrote:I take it the WRAM can't be battery backed?
If I remember correctly, the plan was to use the Flash PRG-ROM for game saves. Some of these chips make it possible to write protect certain sectors, which makes it practically impossible to accidentally overwrite actual PRG-ROM data.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Kasumi wrote:I too like chr-rom, but I guess it would be easier for me to make my chr-rom game chr-ram than it would be for anyone else to do vice versa. I take it the WRAM can't be battery backed?
Well I mean, it has 4x banks of 8KB of CHR-RAM, so you lose no benefits of CHR-ROM and still have the advantages of CHR-RAM just as long as you write what you need. It'd take a while to write 32KB, even 16KB, but if you really hate the waiting inbetween screens or whatever, you can always only used 16KB and during the game running and upload the next 16KB if you'll need it and can tell you're about to switch character sets.
User avatar
Hamtaro126
Posts: 818
Joined: Thu Jan 19, 2006 5:08 pm

Re: 8T-ROM - new NES board prototyped

Post by Hamtaro126 »

Opinions for your Mapper:

1: If needing an IRQ: Something that is seperate from CHR, and it has to be Easy and Simple

2: I'd like a DMA Mode for CHR-RAM, much like Gameboy, SNES and One-bus.

3: Custom Nametable Mapping (See Opinion #4 for why)

4: If possible, use another mode flag, so if it is enabled, add layer 2 for $2800 and $2C00 (with seperate scroll regs, normal NT operation.)
AKA SmilyMZX/AtariHacker.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8T-ROM - new NES board prototyped

Post by tokumaru »

tepples wrote:Half a meg is as big as Mega Man 5 and 6 and Super Mario World. Kirby's Adventure is the only licensed NES game bigger than this. But perhaps you can extend it a bit with the Codemasters-derived codec that you RE'd.
Yeah, I know. It's not bad, it's just not great. For most projects 512KB is enough, it's just that there isn't much room left for experimenting beyond what was already done on the NES... You know, silly stuff like FMVs and such. Anyway, I know 512KB is just fine for most uses.
I chatted with Memblers about this at MGC back in March. It's sort of a compromise between ability to rewrite a few CHR tiles every frame during downtime (Battletoads style) and ability to rotate CHR (SMB2/SMB3 style).
I see... so it really is just 1 switchable slot. Well, If that "costs" (I don't really know how you count CPLD resources) as much as 2 switchable 2KB slots, I'd much rather have that. If the cart is capable of both, I wouldn't mind having sub-mappers for the two kinds. In fact, I imagine that all the stuff that can be customized through jumpers would result in a lot of possible combinations, which would have to be identified by different mapper numbers or sub-mappers, right?
That or text in an RPG, if it's anything like MMC2/MMC4. Dedicate one bank to a 128x32 pixel pseudo frame buffer, as in Faxanadu or Super Bat Puncher, and you can use it draw dialogue with mid-scanline bank switching.
I don't know... I feel that there are very few uses for this, and if having this feature means crippling the IRQ function, I don't think it's worth it, because you can do so much more with decent IRQ functionality.
Kasumi wrote:I too like chr-rom
I grew fonder of CHR-RAM over the years, and if it can be bankswitched, like in this cart, it feels almost the same as CHR-ROM.

Memblers, please don't think that I'm complaining or anything, I'm just expressing my opinions about the few weak points of the mapper. My overall impression is very positive, and I really appreciate your initiative to create something this useful for the NES homebrew community. I'm very interested in this.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8T-ROM - new NES board prototyped

Post by tepples »

Hamtaro126 wrote:2: I'd like a DMA Mode for CHR-RAM, much like Gameboy, SNES and One-bus.
DMA from PRG RAM to CHR RAM would take an MMC5-scale ASIC or FPGA to implement, and we don't have that kind of money. Why do you want to update more than ten tiles per frame?
4: If possible, use another mode flag, so if it is enabled, add layer 2 for $2800 and $2C00 (with seperate scroll regs, normal NT operation.)
What kind of layer 2? Do you mean parallax scrolling? That would require pretty much an entire PPU on a cart, as was done with Wide Boy for Famicom and Super Game Boy for Super NES. That too would need an ASIC or FPGA comparable to the PPU. The attributes would be taken from only one of the layers, causing Spectrum-style clashes left and right.
tokumaru wrote:If that "costs" (I don't really know how you count CPLD resources)
CPLDs are sized in macrocells. Each macrocell can hold one bit of state, and occasionally very complex logic may require macrocells to be paired up. Most large CPLDs nowadays are for voltages lower than 5.0 V, and large 5.0 V CPLDs are very expensive.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Great work on this. Thanks for the pictures and update!

What have ya got on this for a CPLD? 72 macrocell?
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

Thanks for the feedback and everything. I wasn't able to get it running on the first try, so it's debugging time.. Despite that, it's still really exciting to work on.

But yeah this board will be a platform for more than one mapper, it would make sense to use iNES submappers when it's emulated later, I think. I'm willing to customize it to whatever features are needed (within it's limitations of course, heheh).

The mapper I've defined currently fits into 36 macrocells and 34 I/Os. Because of demand for more features, I might standardize on the 72 macrocell part - or have them both produced eventually. It's only like $1.10 cost difference, which is nothing on a devcart, but maybe worth saving when a game is produced. It is a 3.3V CPLD, but it has 5V-tolerant inputs. Part U7 on there is a 3.3V regulator.

The CPU cycle IRQ, and 1kB CHR paging is in the unimplemented category since it's stuff that should fit now that I'll have twice the resources, I just haven't written the verilog for those parts. As soon as I get it running, those will be one of the first things to try. But just getting the basics is first.

The CPU cycle IRQ what I had in mind, was to try and use a timer with a pattern like 113,114,114 and an equivalent table for PAL. Another useful possibility is a plain CPU cycle timer, but I believe 15 bits are needed to cover an entire frame. That + compare value is 30 bits already, but I believe that would still fit in the 36 extra macrocells.
2: I'd like a DMA Mode for CHR-RAM, much like Gameboy, SNES and One-bus.
That's a feature I want for my Squeedo rev3 design (in the future), which will use an FPGA and be an epic mapper, but will definitely be more expensive. Being able to scroll nametable or CHR data on cart might be kinda cool, I hadn't thought of that.
Half a meg is as big as Mega Man 5 and 6 and Super Mario World. Kirby's Adventure is the only licensed NES game bigger than this. But perhaps you can extend it a bit with the Codemasters-derived codec that you RE'd.
Yeah, I know. It's not bad, it's just not great. For most projects 512KB is enough, it's just that there isn't much room left for experimenting beyond what was already done on the NES... You know, silly stuff like FMVs and such. Anyway, I know 512KB is just fine for most uses.
Yeah, 512kB isn't nothing new, but having 32kB of WRAM I think makes a difference because it allows for more use of compression than previous games. And actually too, while it's maybe not useful for FMVs specifically, with the communication server I'm working on, the NES->USB adapter can become sorta like the Disk System but with gigabytes instead of kilobytes. :) Even with sound, I'm kinda thinking I can build the PC version of my Squeedo synth into it so it can still be used with the NES without having to own the actual synth in hardware (though it'd be very preliminary until the synth hardware is created and tested).

With the IRQ (when using CHR as IRQ source), the side-effect is that when you use the special tile, it regards the entire tile as a hit, and since the tile covers 8 scanlines, then the IRQ will trigger 8 times. The work-arounds are to either handle the repeated IRQs, or have your IRQ routine use up over 900+ cycles before acknowledging the IRQ and returning from it. It's really just a hacked-on kind of thing, since it can share the CHR banking logic easily (either mode is selectable during run-time, but can't be used simultaneously). Another thing is that I don't know how close to hblank the IRQ will be triggered - if you have to wait 100 cycles after IRQ trigger to get into hblank, that would kind of be a downer. You also have to use up a sprite for every position you'd want an IRQ, because using the background tiles for IRQ I expect could become very awkward if you scroll. So the timer type of IRQs will be more useful for sure.
Interesting to see a new dev board. I guess it won't get a famicom treatment since the crowd is too small for it.
Actually I have thought of doing a Famicom board, but one of the problems I'm running into is for the communication adapter, I haven't found a source for FC expansion port connectors. Closest thing I've seen, is from Tototek they have NeoGeo controller extension cables, but they seem to be out of stock. Famiclone controller cables might be easier to come by though, if they're still using the same 9-pin standard.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

Good to hear about the famicom thingy. I forgot about the attached controllers so you cannot use it for debugging (except with an AV famicom) and the expansion port is different.
Post Reply