8T-ROM - new NES board prototyped

8T-ROM - new NES board prototyped
by Memblers on 2011-10-22 (#85439)

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.

For larger images, see here:
http://membler-industries.com/memblers/pics/IMG_2089.jpg
http://membler-industries.com/memblers/pics/IMG_2091.jpg
http://membler-industries.com/memblers/pics/IMG_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.

by thefox on 2011-10-22 (#85441)

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.

by Banshaku on 2011-10-22 (#85444)

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.

Re: 8T-ROM - new NES board prototyped
by tokumaru on 2011-10-22 (#85449)

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.

Quote:
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.

Quote:
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.

Re: 8T-ROM - new NES board prototyped
by tepples on 2011-10-22 (#85452)

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.

Quote:
Quote:
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.

Quote:
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.

by 3gengames on 2011-10-22 (#85453)

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.

by Kasumi on 2011-10-22 (#85454)

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?

by thefox on 2011-10-22 (#85456)

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.

by 3gengames on 2011-10-22 (#85459)

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.

Re: 8T-ROM - new NES board prototyped
by Hamtaro126 on 2011-10-22 (#85461)

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.)

Re: 8T-ROM - new NES board prototyped
by tokumaru on 2011-10-22 (#85463)

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.

Quote:
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?

Quote:
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.

Re: 8T-ROM - new NES board prototyped
by tepples on 2011-10-22 (#85465)

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?

Quote:
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.

by infiniteneslives on 2011-10-22 (#85471)

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

What have ya got on this for a CPLD? 72 macrocell?

by Memblers on 2011-10-22 (#85485)

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.

Quote:
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.

Quote:
Quote:
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.

Quote:
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.

by Banshaku on 2011-10-23 (#85509)

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.

by Memblers on 2011-10-24 (#85544)

The problem I had (with the initial failed test) was just an intermittent solder joint, the hardware works! I'll do a board revision though since I've made a couple mistakes (so far), some minor stuff, just a CHR bus conflict , but I have jumpers to select 4-screen mode, which circumvents that problem. So I'm going on to test the Verilog code now.

And I forgot to mention earlier about saving on this cart, it is intended that PRG-ROM is used for save data. Battery-backed SRAM may be faster to write, but the bad part is how easily the data gets corrupted, without using a real NVRAM controller. I've only found one cheap IC that is simply an NVRAM controller, but it's long out of production - most newer ICs that handle it cost too much because they include a lot of other features (like real time clock, CPU reset generator, watchdog timer). First time I made it to Chaos in Final Fantasy, my dog's tail hit the NES which erased my save (real life watchdog reset?), I think using FlashROM can put a stop to crap like that. Just don't bump it WHILE it's saving, but in practice you would probably want to keep 2 copies in memory, to revert to a backup if the first has failed.

Since the sector size for the Flash is 4kB, that means you can program individual bytes in whatever order you want (you could leave $FF "blank" bytes in your data and fill them in later, for example), but when you erase, it is done in 4kB-sized blocks. On the original Squeedo design it was 64kB sectors, that was a little inconvenient for NES, heheh. But, in theory a game saving to flash could be 128kB, and have 384kB of saved data! Who knows what for, but it may be a good way to write a live level editor on the NES or other stuff.

Since the flash endurance question usually comes up too, here is the calculation for that - 100k erase cycles - a player could save 10 times a day, every day, for 27 years straight. Use 2 sectors for saving and it's 54 years, and so on.

Quote:
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.

Yeah Famicom exp port is really close to be being a normal DA15 connector, but I don't think they can be bought without the metal flange. At least it's not something totally alien like the NES exp port.

by tepples on 2011-10-24 (#85546)

Memblers wrote:
But, in theory a game saving to flash could be 128kB, and have 384kB of saved data! Who knows what for, but it may be a good way to write a live level editor on the NES or other stuff.

That or a Mario Paint clone that can use the new adapter from SNES Mouse to NES that infiniteneslives recently figured out to make. Or an animation maker (who needs Flash?). Or RPG Maker.

Quote:
Yeah Famicom exp port is really close to be being a normal DA15 connector, but I don't think they can be bought without the metal flange.

I have an old Y-adapter for the Sound Blaster game port, which also uses a DA15 connector, and it has no flange.

by infiniteneslives on 2011-10-24 (#85547)

tepples wrote:
That or a Mario Paint clone that can use the new adapter from SNES Mouse to NES that infiniteneslives recently figured out to make. Or an animation maker (who needs Flash?). Or RPG Maker.

I'd like to see the NES mario paint! or at least I know my daughter would

by miau on 2011-10-25 (#85563)

Exciting news!
This has almost everything I could wish for. FlashROM save game functionality is particularly amazing, seems to be superior to the conventional method on many levels: price, size, data retention and being prone to save corruption, as you mentioned.

To me, the lack/unaffordability of save game functionality has always been one of the most inhibiting factors to creating more complex homebrew games. Having to restrict myself to a password system = headaches.

I'd happily use this board for the full version of Super Bat Puncher if it has any chance to see mass production and be affordable.

Consider me a supporter.

by Denine on 2011-10-27 (#85661)

Woooow! A new, custom made board\mapper?
You really are good at technology!
Some noobish things that I don't get.
Quote:
32kB CHR-RAM - 1kB CHR page (smaller CPLD can use 2 * 2kB paged, 2 * 2kb fixed)

Not sure what it means...Umm...I can write 32kb of grafics with $2007 like CH RAM, and later use them in same way as CHR ROM by switching 32kb around?If yes, then it would be AWESOME!
Quote:
Automated CHR bankswitching, also a CPU IRQ function (that comes with some side-effects, though)

Automated?
Quote:
4-screen mirroring, nametable bankswitching

Ability to switch name tables?! I mean, just like CHR ROM?!
I Like it
Quote:
Flash memory - 4kB sectors.

Not sure...you mean battery backup?(for game saves)
Quote:
2: I'd like a DMA Mode for CHR-RAM, much like Gameboy

I'v read about DMA mode for GB, but I don't understand anything.Can someone say it in human language? What effect it would give using it with NES?

About board:Do you have any plans on releasing it? Any price for it in mind?Any idea for mouse support?
This project is really interesting, hope you can finish it.

by tokumaru on 2011-10-27 (#85664)

Denine wrote:
Not sure what it means...Umm...I can write 32kb of grafics with $2007 like CH RAM, and later use them in same way as CHR ROM by switching 32kb around?If yes, then it would be AWESOME!

Yup, that's what it means. This is nice because you get the advantages of CHR-RAM (updating a small number of patterns and also create them in real time) and CHR-ROM (quickly changing a large number of patterns).

Quote:
Automated?

When a certain tile is rendered, it triggers a bankswitch.

Quote:
Ability to switch name tables?! I mean, just like CHR ROM?!

I believe that name table bankswitching is the ability to arrange the available name tables in any way you want, instead of being restricted to vertical or horizontal mirroring.

by Hamtaro126 on 2011-10-27 (#85677)

Quote:
Quote:
2: I'd like a DMA Mode for CHR-RAM, much like Gameboy

I'v read about DMA mode for GB, but I don't understand anything.Can someone say it in human language? What effect it would give using it with NES?

I was thinking of enhancing SMB1 or demaking SMW if I needed to, as DMA is used for Characters, Palettes and Nametabes, Sprites still have thier own DMA,

Somehow, I will plan to make a new mapper myself, just for the heck of it.

DMA can upload any type of data via RAM easy via external regs, without using too much of RAM, and does not take a hassle for both the user and CPU

by tepples on 2011-10-27 (#85679)

Denine wrote:
Quote:
Flash memory - 4kB sectors.

Not sure...you mean battery backup?(for game saves)

It's like battery backup, except it doesn't need a battery, and the whole chip isn't corrupted by an unclean power cut. You can erase a sector of flash and copy data from PRG RAM to that sector.

Quote:
Quote:
2: I'd like a DMA Mode for CHR-RAM, much like Gameboy

I'v read about DMA mode for GB, but I don't understand anything.Can someone say it in human language? What effect it would give using it with NES?

"DMA to CHR RAM" means hardware-assisted data copying from the CPU bus to the PPU bus. The Genesis has it (Sega used to call it "blast processing"), and so do the Super NES and Game Boy Advance. It'd be like OAM DMA (which copies a 256-byte page of data on the CPU side to $2004), except targeting $2007 instead. But on the NES, any way I know of to do this would require the CPLD to take control of the CHR RAM's entire address and data bus, and that's MMC5 territory.

by Hamtaro126 on 2011-10-27 (#85680)

That is why I'm doing my own mappings for a new WIP, DIY Famiclone computer, But that is another story, Memblers is doing ok so far.

(it may use an actual 6502)

EDIT: I'll stop and actually do stuff now...

by Memblers on 2011-10-28 (#85696)

Denine wrote:
About board:Do you have any plans on releasing it? Any price for it in mind?Any idea for mouse support?
This project is really interesting, hope you can finish it.

After I get the mapper design stabilized and tested, then I'll send some around to interested developers (with a USB cable). I've got 10 prototype boards, when I do the revision I'll order maybe another 10 or 20 and solder those by hand also. I'll be (once again) enhancing my Garage Cart #2 project to use this board, once that is ready (or any other project) then I can put it into mass production.

My price target for the board was to sell it for around $15 (that includes the board with all the parts soldered on, programmed and tested). Component cost by itself may be close to $10, then there's the cost of having it assembled, and me testing/repairing them and all that, so $15 might be more like a quantity discount type of price.. we'll see. The hand-soldered initial batches may cost a little extra.

Maybe a dev kit including a cart + case + USB adapter would cost something like $35 - $45. Not sure yet, I'm definitely wanting to keep things cheap though.

As for mouse support, that depends on the software. I guess the SNES mouse adapter being discussed would work, but since the NES only has 2 control ports you'd have to either disconnect a controller, or disconnect the USB. But for the PC software, one of the functions I've wanted to add later was the ability to poll the PC keyboard/mouse from the NES. Though that may be awkward to use depending on where your PC and NES/TV are located.

maiu: Thanks for the support, your game project will definitely further the cause. The more boards I can order, the cheaper it will be overall. Between just Super Bat Puncher and Garage Cart #2, I believe this could be successful with at least one decent production run.

by NESHomebrew on 2011-10-30 (#85761)

Memblers wrote:
Between just Super Bat Puncher and Garage Cart #2, I believe this could be successful with at least one decent production run.

Would these be used for the compo cart as well?

by tokumaru on 2011-10-30 (#85762)

WhatULive4 wrote:
Would these be used for the compo cart as well?

You mean "underused", right?

by tepples on 2011-10-30 (#85764)

The nesdevcompo cart uses the Deadly Towers mapper.

by NESHomebrew on 2011-11-01 (#85812)

tepples wrote:
The nesdevcompo cart uses the Deadly Towers mapper.

Yea, but there was some talk about including a couple of the other games as well. I believe memblers ordered the boards, but I haven't heard any updates.

by tepples on 2011-11-02 (#85827)

Memblers wrote:
Maybe a dev kit including a cart + case + USB adapter would cost something like $35 - $45. Not sure yet, I'm definitely wanting to keep things cheap though.

Now that I've got my kazzo working, sign me up.

Quote:
As for mouse support, that depends on the software. I guess the SNES mouse adapter being discussed would work, but since the NES only has 2 control ports you'd have to either disconnect a controller, or disconnect the USB.

That or put a switch on the adapter between controller 2 and the USB.

by infiniteneslives on 2011-11-02 (#85829)

How exactly is the USB planned to work? Sounds like through the controller port somehow? What kind of chip or mcu is between the two handling the comms?

by Memblers on 2011-11-05 (#85895)

Here is a picture of the board for the compo cart.
http://membler-industries.com/memblers/pics/IMG_2090.jpg
Just a 74HC161 for the mapper, it's such a simple setup that I'm surprised only one game ever used it.

tepples wrote:
Quote:
As for mouse support, that depends on the software. I guess the SNES mouse adapter being discussed would work, but since the NES only has 2 control ports you'd have to either disconnect a controller, or disconnect the USB.

That or put a switch on the adapter between controller 2 and the USB.

Actually, since I'll be using NES extension cables (that contain 7 wires), I really wanted to pass the controller through at the same time. But the real problem is that the adapter circuit is inside the USB connector hood - having the NES controller plug in near the PC's USB connector would be exceedingly weird. Cutting into the wire and splicing the controller in seems possible, but may be kinda ugly and more work to build. Adding a box where it can be spliced or switched inside wouldn't look too bad, but then that adds a need for 3 strain reliefs - maybe I'll take a look into doing that.

Unfortunately the camera we have here quit working, it can take videos but not pictures anymore. The pics I've posted so far I took at work. But the USB adapter as designed now looks great, just a cable with NES connector on one end and USB on the other - proper strain relief and everything, it looks professionally made. I'd hate to ruin the aesthetics of it, but for developers who want to use it make/debug a 2-player game, some kind of Y-adapter would surely be convenient.

infiniteneslives: Yep controller port, and the chip used is a PL-2303 (or clone, it's under an epoxy blob so who knows). I'm getting it from these: http://www.dealextreme.com/p/usb-cable-for-nokia-n1200-1208-1650-2630-2670-13638 Just been ordering 10 at a time for the discount, but sometime I may ask them if there is a better discount for ordering 100 or something. Blargg, other folks, and I in the past have previously made RS232 adapters (that would be mostly compatible with this) using the MAX202/MAX232.

To handle the communications, because writing a software UART on the NES is only half-duplex, I've came up with a protocol layer so that arbitrary data could be sent both ways without data loss. There is overhead involved of course, but I've also integrated run-length encoding in the hopes that it will make up for it in some cases (would make a huge difference on ROMs that include lots of padding, as most in-development stuff tends to be). My communication protocol is sorta inspired by XMODEM, ZMODEM, and SLIP - none of those were really suitable on their own for this use.

For the fun of it (and to make testing easier hopefully), I've chosen to write the protocol in C and build it with CC65 and GCC. I'm finally delving into CC65 (the KNES template by thefox was a huge help), but of course on the NES side the vital parts will still be written in asm (send/receieve and CRC calculations).

by Jeroen on 2011-11-06 (#85942)

Man this cart looks sweeeeet. Also the compo cart looks pretty
I like the punchout style irq...I mean it could be more ideal but its a decent tradeoff between costs and game capability.

by tepples on 2011-11-20 (#86572)

Anything new over the past two weeks?

by Memblers on 2011-11-22 (#86649)

I've had some trouble with CHR-RAM on my test cart, has been annoying me so I'm working on a new test program to narrow it down. Mostly I've been getting used to using a C compiler with NES, and sorting through my old Squeedo code for things to re-use, like the NSF loader. That's probably the first thing useful I'll try to get working. CC65 has been pretty cool to use.

One thing I have been able to verify, is that the program appears to be booting in my configured start-up bank. That is still a concern, because the CPLD would need to be awake before the NES CPU is. It starts at a lower voltage, but does need time to load it's configuration. Banking seems OK so far, haven't tried the CHR-hit IRQ because of the tile corruption.

BTW, for a cycle-counter IRQ, the setup I've done is to change a couple registers to be address and data ports. So, in this mode there are 16 registers indirectly available. Since they are only 4-bits wide, you need 4 of them of them just for setting the IRQ trigger time (16-bits). Though maybe I could do an auto-inc the register index to make the writing faster.

by Hamtaro126 on 2011-11-22 (#86659)

Memblers wrote:
I've had some trouble with CHR-RAM on my test cart, has been annoying me so I'm working on a new test program to narrow it down. Mostly I've been getting used to using a C compiler with NES, and sorting through my old Squeedo code for things to re-use, like the NSF loader. That's probably the first thing useful I'll try to get working. CC65 has been pretty cool to use.

One thing I have been able to verify, is that the program appears to be booting in my configured start-up bank. That is still a concern, because the CPLD would need to be awake before the NES CPU is. It starts at a lower voltage, but does need time to load it's configuration. Banking seems OK so far, haven't tried the CHR-hit IRQ because of the tile corruption.

BTW, for a cycle-counter IRQ, the setup I've done is to change a couple registers to be address and data ports. So, in this mode there are 16 registers indirectly available. Since they are only 4-bits wide, you need 4 of them of them just for setting the IRQ trigger time (16-bits). Though maybe I could do an auto-inc the register index to make the writing faster.

One question: Will there be Emulator support for the mapper?

by Memblers on 2011-11-22 (#86673)

Hamtaro126 wrote:
One question: Will there be Emulator support for the mapper?

Sure, if I do it myself it will probably be in FCEU, as that is what I tend to use for debugging. This would be an iNES 2.0 mapper, with sub-mappers used for 2 or more different configurations. It should be able to work on the PowerPak, also.

This will be after the board and mapper are both debugged and tested.

by Memblers on 2011-11-27 (#86843)

Found the CHR error before I went to bed, turns out it was a simple error in my verilog. Typical noob error.

So, finally my board is verified! Now just to figure out if there's anything in the design that needs to change. I fixed the CHR bus conflict with a wire (no need to even cut traces, thanks to the CHR jumpers).

BTW I've figured that I will go ahead and start producing the NES to USB adapters and starting supplying those first, in December if everything goes well.

by Jeroen on 2011-11-27 (#86848)

Was/is there a prize estimate?

by Memblers on 2011-11-29 (#86921)

For the NES-USB cable, I was thinking $15 or $16

by thefox on 2012-04-09 (#92329)

Updates?

by picccca on 2012-05-30 (#94834)

thefox wrote:
Updates?