Hi all! Me and Masyanya have something for you. Let me introduce you Invitenes - a game SRAM cartridge for the Famicom and Dendy! It uses a 60 pin connector, but via an adapter can be used on a conventional NES. Yes, you heard right - you can play any NES/Famicom games on real hardware! Moreover, this does not need a computer, except that once for save some games to SD/MMC card. So, here is the device:
The board is designed for conventional cartridge case:
We have already launched several mappers: UNROM, AROM, MMC1, MMC3. You can watch
this video, showing the launch a Bucky O'Hare game (currently a bug with the mountains has already been fixed). Features:
1. 2 megabytes of RAM for the PRG.
2. 2 megabytes of RAM for the CHR.
3. Cyclone II FPGA as mapper and logic.
4. STM32 Cortex-M3 controller as a co-processor for memory card, SRAM, and FPGA (can be used from 6502 side).
5. 32 kilobytes of battery-backed WSRAM (as 4 pages of 8 KBytes).
6. USB connector, which can be used to communicate with the computer.
7. Support SD/MMC memory cards up to 32GB.
8.
You can create your own mapper, and game for it!
And much more.
Yes, it's ROMless. All you need is stored on the memory card. There are special directory in which files are written which generate FPGA configuration for mapper function. Mapper number taken from the iNES header. To support the new mapper just add new file in that folder. The boot menu handled by coprocessor, so it is sorted and quite fast. Downloading a MMC3 game is about 3 seconds (2x 256K + 150K for FPGA config).
The device is still in development for the programming part, but shows its performance.
PS This is NOT 1st April joke! This device are real!
Quite a few advantages over the PowerPak! I like it! Let's see:
1. Works on clones;
2. Uses SD rather than the obsolete CF;
3. 4 times the space for PRG and CHR;
4. Direct connection to the computer;
5. Sorted files, thanks to coprocessor;
6. Faster transfers, also thanks to coprocessor;
Do you plan on selling these? I'm sure there would be a lot of interest!
EDIT: Too bad that the video doesn't show anything interesting. No menu, it just jumps straight to the game. We don't get to see anything about the cart itself, other than it is able to run Bucky O'Hare.
What about hacking? Will Firmware/mappers be open-sourced and documented? If so, you have an immediate buyer here...
/someone who already owns two awesome powerpaks for gaming but keeps wishing for a better development platform :)
Quote:
What about hacking? Will Firmware/mappers be open-sourced and documented? If so, you have an immediate buyer here...
Same here ! Good to know it wasn't an april fool.
How well would an OpenStreetMap viewer run on the ARM? Is that ARM7 as in Game Boy Advance or ARMv7 as in modern smartphones?
Very nice, good work guys.
I am very pleased with the fact that its designed for famicom. Using the powerpak with an adaptor works..but its not really elegant. Would be nice to just have a small cart plug in directly.
ps: if it wont cost too much a small dac for better "Extra" sound channel support representation would be nice...but I suppose you could go the powerpak route and just use 1 pin with pwm.
HardWareMan wrote:
8. You can create your own mapper, and game for it!
And much more.
Yes, it's ROMless. All you need is stored on the memory card. There are special directory in which files are written which generate FPGA configuration for mapper function. Mapper number taken from the iNES header. To support the new mapper just add new file in that folder.
I know this is a per-user specification, but I'd REALLY like $A2 (Mapper #162) to be associated with MMC7/RxROM.
...like, in the hearts & minds of everyone. That sort of thing.
Dr. Floppy wrote:
I'd REALLY like $A2 (Mapper #162) to be associated with MMC7/RxROM.
You want to reserve a number for a mapper that doesn't even exist? Why don't you make the mapper first? Or better yet, a game using that mapper, so that there's any reason for it to be officially included anywhere.
tokumaru wrote:
Dr. Floppy wrote:
I'd REALLY like $A2 (Mapper #162) to be associated with MMC7/RxROM.
You want to reserve a number for a mapper that doesn't even exist? Why don't you make the mapper first? Or better yet, a game using that mapper, so that there's any reason for it to be officially included anywhere.
I'm actually in the planning stages of such a thing, although it does tend to be a Catch-22: how does one create/test/debug an original game for a mapper with no emulation or hardware support?
This delightful device would appear to be a way out of that nasty cycle. I just hope, when it's all said & done, that I'm not too late.
Looks good. And wow, that's a lot of RAM.
@Dr. Floppy:
I understand where you're coming from, but there are a lot of ideas on the internet that end up never becoming anything. I think it's a terrible idea to waste something as scarce (not so scarce with iNES 2.0, but still) as mapper numbers with things that don't even exist. If we did that for everyone that had an idea, well, we'd have a lot of unfinished crap just taking up space.
At this point, documenting the "MMC7" would do little more than confuse emulator authors, who wouldn't even have a test ROM to work with.
Both the PowerPak and this cart allow you to test new mappers, provided you know how to make them, without the need for an "official" mapper number. You can just give your mapper file any number you want and it will work on your PowerPak. If you don't know how to make mappers, maybe the first thing to do is to learn that. Or get someone else to make it for you, so that you can code your game.
I believe that only a working game would give you the right to claim an official mapper number.
tokumaru wrote:
@Dr. Floppy:
I believe that only a working game would give you the right to claim an official mapper number.
This is an incredibly well-timed coincidence, as it illustrates my concept rather nicely:
http://maps.google.com/maps?q=0.0000,+0 ... 4&t=8&z=17
I can't think of a better showcase for [MMC5 + 4-screen mirroring] than an interactive 8-bit rendition of Google Earth.
Will it be possible for people who don't live in Russia to actually purchase this cart?
I saw the "RAM Factory" logo on the cart and I tried to buy their InviteSNES cartridge a while back, but I couldn't pay for it, because I would have needed to have a webmoney account which can only be made in Russia (or at least I think that was the case...I will not create an account there anyways). The website says payment with MasterCard is possible, but it is not available when you actually try to buy something there.
I'll try to answer most of your questions.
tokumaru wrote:
Do you plan on selling these? I'm sure there would be a lot of interest!
Yes. After the basic user interface will be done.
tokumaru wrote:
EDIT: Too bad that the video doesn't show anything interesting. No menu, it just jumps straight to the game. We don't get to see anything about the cart itself, other than it is able to run Bucky O'Hare.
Agree. That video was taken at early start for proof of concept. Later, I will make full demonstration video.
Bananmos wrote:
What about hacking? Will Firmware/mappers be open-sourced and documented? If so, you have an immediate buyer here...
As I already said: you can make your own mapper. So, this mean you will get some info for development. Since I'm not only developer, I can't say about full open source right now. But I guarantee that you will get maximum info as it possible.
Bregalad wrote:
Same here ! Good to know it wasn't an april fool.
No, it wasn't. It just happened.
tepples wrote:
How well would an OpenStreetMap viewer run on the ARM? Is that ARM7 as in Game Boy Advance or ARMv7 as in modern smartphones?
Sorry for misunderstanding. We use STM32F107, it has
Cortex-M3 core.
Jeroen wrote:
I am very pleased with the fact that its designed for famicom. Using the powerpak with an adaptor works..but its not really elegant. Would be nice to just have a small cart plug in directly.
Yes, since we are "Oh, those russians!", we are used to play Dendy. Dendy is FC clone and it has 60 pin connector. NES has bigger cartrige, which can hold our cartrige and adaptor. So, everything justified.
Jeroen wrote:
ps: if it wont cost too much a small dac for better "Extra" sound channel support representation would be nice...but I suppose you could go the powerpak route and just use 1 pin with pwm.
Yeah, we discussed that at early stage of development (at least
VRC7 support). But temporary exclude this for simplified prototype. And yeas, we can do PWM DAC for it (FPGA pins its weight in gold).
Memblers wrote:
Looks good. And wow, that's a lot of RAM.
We select RAM (actually SRAM, not DRAM, nor SDRAM and etc) for a write speed.
Grumskiz wrote:
Will it be possible for people who don't live in Russia to actually purchase this cart?
I saw the "RAM Factory" logo on the cart and I tried to buy their InviteSNES cartridge a while back, but I couldn't pay for it, because I would have needed to have a webmoney account which can only be made in Russia (or at least I think that was the case...I will not create an account there anyways). The website says payment with MasterCard is possible, but it is not available when you actually try to buy something there.
That's are good question. We will try to resolve it as soon as it possible. For now you can cooperate with somebody, who can deal with it right now.
Looking good!
I've got some curiosity questions more to do with some of the technical details. For one I'm curious as to the interfacing done by the FPGA seems like 140 some I/O should be more than enough but you commented on I/O at a premium suggesting you're using most of them. I suppose once the technical details come out that would allow one to make their own mapper most of my queries will be answered...
Also how are you level shifting? The FPGA isn't 5V tolerant but it looks like you just have some resistors between the cart edge and FPGA pins? Am I missing something or does the dendy not operate at 5V? Just curious what your trick was here.
So is there not separate WRAM? I guess with the large amount of PRG RAM you can use the mapper to place the WRAM as a page or two of the same PRG RAM where the ROM image would exist?
Any plans or goals on a release date? If it's well documented I'd be interested in playing around with one.
infiniteneslives wrote:
I've got some curiosity questions more to do with some of the technical details. For one I'm curious as to the interfacing done by the FPGA seems like 140 some I/O should be more than enough but you commented on I/O at a premium suggesting you're using most of them. I suppose once the technical details come out that would allow one to make their own mapper most of my queries will be answered...
All cart pins are routed to FPGA. I mean all, except power and sound. So, you can switch off internal 2KB CHR RAM, for example. Onboard SRAM are behind FPGA and did not accessable while FPGA are not configured. It give you maximum freedom for mapper routing.
infiniteneslives wrote:
Also how are you level shifting? The FPGA isn't 5V tolerant but it looks like you just have some resistors between the cart edge and FPGA pins? Am I missing something or does the dendy not operate at 5V? Just curious what your trick was here.
Indeed, the Cyclone 2 has LVTTL/LVCMOS 3.3V. And Dendy, Famicom and NES - TTL/CMOS 5v. But, in practice, restrictions on the current through the resistance is sufficient.
infiniteneslives wrote:
So is there not separate WRAM? I guess with the large amount of PRG RAM you can use the mapper to place the WRAM as a page or two of the same PRG RAM where the ROM image would exist?
You can do that, but only separate 32KBytes chip are battery backuped.
infiniteneslives wrote:
Any plans or goals on a release date? If it's well documented I'd be interested in playing around with one.
There are tons of plans. :3 But most important are support at least over 90% NES ROMset. And we will aim to 100%.
HardWareMan wrote:
You can do that, but only separate 32KBytes chip are battery backuped.
On the PowerPak, if the console is powered off by accident (e.g. the power goes out, someone trips on the power cord, etc.) you lose your progress, because you don't get a chance to write the SRAM contents back to the CF card. Did you add a battery to avoid this? How will the loading and saving of SRAM data work in your cart?
infiniteneslives wrote:
But most important are support at least over 90% NES ROMset. And we will aim to 100%.
If your mappers are faithful to the originals I'm sure this will happen naturally. I just ask of you to not use "hacks" just to get games working, because that reduces the reliability of the cart as a development tool.
Most of us already own PowerPaks, and it's great to play games and all, but it's kinda lacking as a development unit. Your cart has the potential to be a great development tool, so please keep that in mind.
HardWareMan wrote:
infiniteneslives wrote:
I've got some curiosity questions more to do with some of the technical details. For one I'm curious as to the interfacing done by the FPGA seems like 140 some I/O should be more than enough but you commented on I/O at a premium suggesting you're using most of them. I suppose once the technical details come out that would allow one to make their own mapper most of my queries will be answered...
All cart pins are routed to FPGA. I mean all, except power and sound. So, you can switch off internal 2KB CHR RAM, for example. Onboard SRAM are behind FPGA and did not accessable while FPGA are not configured. It give you maximum freedom for mapper routing.
infiniteneslives wrote:
Also how are you level shifting? The FPGA isn't 5V tolerant but it looks like you just have some resistors between the cart edge and FPGA pins? Am I missing something or does the dendy not operate at 5V? Just curious what your trick was here.
Indeed, the Cyclone 2 has LVTTL/LVCMOS 3.3V. And Dendy, Famicom and NES - TTL/CMOS 5v. But, in practice, restrictions on the current through the resistance is sufficient.
Maybe it's just me, but I don't follow how a mere current limiting resistor saves the FPGA inputs from damage/accelerated wear. So if I'm not mistaken these are the DC limits of your device:
http://www.altera.com/literature/hb/cyc2/cyc2_cii51005.pdf
According to that the absolute maximum input voltage is 4.0v @ 100% duty cycle and 4.2v at 50% duty cycle. Even with the current limiting resistors you've still got 5.0v present at the pins with the assumption that the input impedance of the pins is relatively high. Have you probed the pins to see what you actually have? The data sheet's warning would leave me a little concerned that this method of level shifting would limit life of the device:
"Conditions beyond those listed in this table cause permanent damage to a device. These are stress ratings only.
Functional operation at these levels or any other conditions beyond those specified in this chapter is not implied.
Additionally, device operation at the absolute maximum ratings for extended periods of time may have adverse
effect on the device reliability."
Is there something out there that shows how level shifting in this manner affects lifetime of the device? I'm not doubting that it doesn't work as is, but If you have more than 4.0V present on the pins I would expect that it won't survive over time...
I don't mean to be a naysayer, but it sounds like there is still time to toss in some level shifters if you decided to.
tokumaru wrote:
Did you add a battery to avoid this? How will the loading and saving of SRAM data work in your cart?
This was done in order not to think about compulsory saving and loading WSRAM if you play just one saving game at time. Saving and loading WSRAM are going through the system menu.
tokumaru wrote:
If your mappers are faithful to the originals I'm sure this will happen naturally. I just ask of you to not use "hacks" just to get games working, because that reduces the reliability of the cart as a development tool.
Our goal - the repetition of mappers in the original form, without any hacks and other such things. For example, documentation of MMC3 is very lame, even from Kevtris. I had to sit with an oscilloscope and logic analyzer to understand how it works. Now it works as it should and has been tested on several different games - everything works fine. Also, we will try to repeat the entire spectrum of Chinese mapers, but that is caring CaH4e3.
tokumaru wrote:
Most of us already own PowerPaks, and it's great to play games and all, but it's kinda lacking as a development unit. Your cart has the potential to be a great development tool, so please keep that in mind.
I know. On the other hand, I want an autonomous cartridge All-In-One. With blackjack and hookers. 3
infiniteneslives wrote:
Is there something out there that shows how level shifting in this manner affects lifetime of the device? I'm not doubting that it doesn't work as is, but If you have more than 4.0V present on the pins I would expect that it won't survive over time...
I don't mean to be a naysayer, but it sounds like there is still time to toss in some level shifters if you decided to.
I understand your concern. Many of you use
Krikzz products and has no negative feedback. I mean non exUSSR users. I think that was enough time to testing in real conditions.
2
HardWareMan could you please PM me to negotiate price, how to pay and shipping details
Blimey, keep at it! This has the potential to surpass even the PowerPAK, especially if it runs on many clones!
I am certainly interested in this ^^
All your questions can refer to the
support forum in the English section.
Couldn't register on the forum. Said my gmail email address was banned for some reason.
I've got a question. What's the smallest amount of bankswitching enabled? PowerPak can do 4K at the least; which is why the PowerPak NSF player has to double its ROM space to compensate.
B00daW wrote:
Couldn't register on the forum. Said my gmail email address was banned for some reason.
A lot of niche forums appear to prefer e-mail accounts from domains owned by wired ISPs over free webmail provider domains because it's easier for a spammer to get away with using a disposable webmail account over one at an ISP domain that someone is presumably paying for.
Workaround: Register your own domain and put Google Apps on it.
B00daW wrote:
I've got a question. What's the smallest amount of bankswitching enabled? PowerPak can do 4K at the least; which is why the PowerPak NSF player has to double its ROM space to compensate.
Since all slot pins are goes thru FPGA, you can bankswitch every single byte of SRAM. But it will be expencive for FPGA.
B00daW wrote:
Couldn't register on the forum. Said my gmail email address was banned for some reason.
B00daW, I reported the problem to the site administrator. Thx!
---
Try to register again.
B00daW wrote:
Couldn't register on the forum. Said my gmail email address was banned for some reason.
...when the core of the forum was poorly protected, gmail users register only to post spam, I closed it at all... but now... gmail.com removed from ban list!
Any hint on price?
Quote:
Any hint on price?
The forum says $120.
Tried for the second time to order from ramfactory (since PayPal was apparently added as payment method) but still can't order, it says No shipping available to the selected country and I live in Canada.
Can I haz compatibility list?
MMC5, VRC6, VRC7 - most important ones
Drafts of the menu engine. Everything happens in real time: reading memory card, a menu drawing directly to the PPU VRAM with LFN. Sorting are not implemented for now. It is also noticeable a button bounce of my old joypad, which is still alive since the early 90s.
And yes, this cartrige will supplied with IDE, something like
this.
Name the bios after me?
infiniteneslives wrote:
Name the bios after me?
No, it's just a file for test purpose. :3
Some update: adding file sorting (by LFN) and file filtering. You can hide any unsupported file, include NES file with mapper, that not present in MAPPER folder.
A less-plain menu and you're golden. Nice work so far! Holy crap PAL Contra is as slow as molasses.
I would like very much to order one of these. I haven't had a chance yet to read through all there is to read; is it publically available yet and payable via PayPal?
Also, how is compatibility with VRC6 and Sunsoft 5B external audio? May we possibly have a demonstration of the functionality?
I am particularly enthused by this as it is designed for Famicom / Dendy cartridge form factor and not the huge NES ones, which is appealing as I have a Famicom and would rather not have to pick up another NES or use a gigantic (backwards) converter.
3gengames wrote:
A less-plain menu and you're golden. Nice work so far!
This is a drafts. Later we will put things beauty.
BTW, AxROM almost fixed and Digger seems to be run correctly.
mikejmoffitt wrote:
Also, how is compatibility with VRC6 and Sunsoft 5B external audio? May we possibly have a demonstration of the functionality?
Because it is not so important, audio extensions are currently not supported. That means those games are will be run, but has no extra sound. Later we add extra sound engine.
Do you plan on supporting FDS games similar to the PowerPak? That would be pretty much a 100% buy for me if you did, at least in the future.
narunetto wrote:
Do you plan on supporting FDS games similar to the PowerPak? That would be pretty much a 100% buy for me if you did, at least in the future.
Yes, we do.
@HardWareMan
how many time before the release ?
sdekaar wrote:
@HardWareMan
how many time before the release ?
As soon as we finish testing a basic set of mappers and make friendly GUI.
Will this also support the sunsoft mappers?
I ask because The Portopia Serial Murder Case translated uses mapper 63.
I'm also really looking forward to this, I already have $150 set aside to buy it day 1.
DNSDies wrote:
Will this also support the sunsoft mappers?
I ask because The Portopia Serial Murder Case translated uses mapper 63.
Can I see this ROM? Because, I found that
Portopia Renzoku Satsujin Jiken (Japan) [En by DvD Rev A] (~Portopia - Serial Murder Case, The) uses mapper #0. Url:
[No links to unauthorized copies of non-free commercial ROMs please -- MOD]***
Ouch.
According this info this game does not have any mapper.
CaH4e3 wrote:
63го маппера не сущесвует лол
а игра эта вообще безмапперная
тем более эта игра вовсе не сансофтовая лол
That means 63 mapper does not exist, that game has no mapper and that game are not from Sunsoft.
Portopia Renzoku Satsujin Jiken (Japan) does NOT have a mapper normally, but the english translated romhack requires the sunsoft mapper #68 (did I say 63 before? sorry)
If your cart can play After Burner, it works:
http://bootgod.dyndns.org:7777/profile.php?id=326
another game that uses that mapper, Maharaja:
http://bootgod.dyndns.org:7777/profile.php?id=3852
also, Nantettatte!! Baseball:
http://bootgod.dyndns.org:7777/profile.php?id=2265
Some another WIP. New mappers added.
HardWareMan wrote:
Some another WIP. New mappers added.
any estimated on the price?
Will there be support for Shenzhen Nanjing's mapper? Final Fantasy VII and other games of theirs uses mapper 163.
Lugia2009 wrote:
Will there be support for Shenzhen Nanjing's mapper? Final Fantasy VII and other games of theirs uses mapper 163.
Can't mapper 163/164 games be trivially hacked to extended-BNROM? Is there even a definitive document on 163/164?
All documentation of Final Fantasy 7's mapper includes a magic black box that bankswitches the screen at scanline 128, with absolutely no information on how it knows what scanline it's on.
Dwedit wrote:
All documentation of Final Fantasy 7's mapper includes a magic black box that bankswitches the screen at scanline 128, with absolutely no information on how it knows what scanline it's on.
software reset counter on IRQ?
HardWareMan wrote:
Hi all! Me and Masyanya have something for you. Let me introduce you Invitenes - a game SRAM cartridge for the Famicom and Dendy! It uses a 60 pin connector, but via an adapter can be used on a conventional NES. Yes, you heard right - you can play any NES/Famicom games on real hardware! Moreover, this does not need a computer, except that once for save some games to SD/MMC card. So, here is the device:
The board is designed for conventional cartridge case:
We have already launched several mappers: UNROM, AROM, MMC1, MMC3. You can watch
this video, showing the launch a Bucky O'Hare game (currently a bug with the mountains has already been fixed). Features:
1. 2 megabytes of RAM for the PRG.
2. 2 megabytes of RAM for the CHR.
3. Cyclone II FPGA as mapper and logic.
4. STM32 Cortex-M3 controller as a co-processor for memory card, SRAM, and FPGA (can be used from 6502 side).
5. 32 kilobytes of battery-backed WSRAM (as 4 pages of 8 KBytes).
6. USB connector, which can be used to communicate with the computer.
7. Support SD/MMC memory cards up to 32GB.
8.
You can create your own mapper, and game for it!And much more.
Yes, it's ROMless. All you need is stored on the memory card. There are special directory in which files are written which generate FPGA configuration for mapper function. Mapper number taken from the iNES header. To support the new mapper just add new file in that folder. The boot menu handled by coprocessor, so it is sorted and quite fast. Downloading a MMC3 game is about 3 seconds (2x 256K + 150K for FPGA config).
The device is still in development for the programming part, but shows its performance.
PS This is NOT 1st April joke! This device are real!
Great
Can you made a mapper sdk?
and I can write new mapper to support.
Hello.
Is possible to make a GUI with pictures?
Like these:
See 0:42 sec.
http://www.youtube.com/watch?v=QxkjBOQHTaU
http://www.youtube.com/watch?v=WjV92Xg2pDo
or
Regards
It's possible to make a GUI with pictures on any flash cart that supports mapper 34 (BNROM, Deadly Towers), but currently
that feature works only for NROM games that use vertical mirroring.
How many and which mappers do exist until now?
And which mappers can we expect working from the beginning?
im-pulze wrote:
How many and which mappers do exist until now?
And which mappers can we expect working from the beginning?
For now we have this: 0, 1, 2, 3, 4, 7, 9, 10, 11, 13, 18, 22, 23, 68. Theoretical, any of mapper can be added (including by self user, if he has the appropriate skills).
Is there any update on an ETA? As far as I know it was last estimated for April. Don't want to sound like I'm rushing, just really excited for the cart.
There are a few updates, but about them later. Now we are discussing the implementation of sound extended mappers to implement a series of VRС.
HardWareMan wrote:
There are a few updates, but about them later. Now we are discussing the implementation of sound extended mappers to implement a series of VRС.
How can I buy one？
First, you have to wait release.
I'm really excited to buy this flashcart and see if it's a NES Powerpak killer. Thanks for your efforts thus far HardWareMan!
This is really exciting. I've been longing for a flashcart in a famicom cart formfactor. My AV Famicom looks ugly with a powerpak sticking way out of it. Hardwareman, do you know what the power draw of this would be like compared to Powerpak, more or less or about the same? My powerpak makes ugly jailbars compared to the same games on real cartridges on my RGB famicom.
Hope u can finish it soon!
Cant wait til its done. I have a Mebeteck clone and was looking for a flash cartridge for it and it seems as this is the only one that will work! Hope it will also be buyable from outside of Russia cuz im in Sweden!
I wonder what the plan is? I mean, are they going to implement a certain number of mappers, and then start selling the board....offering more mappers as they're made? I've really been checking out RAM Factory, and their website/YouTube videos seem more like... look what we did offerings, rather than advertisements for products. Does anyone own a RAM factory flash card that isn't directly associated with the RAM Factory? I wonder if it will even matter in the end, if they can't even accept PayPal....
HarwareMan just posted up a new WIP video
http://www.youtube.com/watch?v=eq4jgnrb ... ture=g-u-u"Adapted OS kernel. Clarified incompatibility MegaBoy, unfortunately, will not be supported temporarily. A current list of mappers: 0, 1, 2, 3, 4, 7, 9, 10, 11, 13, 18, 21, 22, 23, 25, 37, 47, 68 and 71. Completed, the update from the memory card that does not require special programming for the service, and therefore, a little more testing and will be released. Interface slightly modified, but still not yet the underlying list. You can now scroll the names manually, list management easier, as in the good old mnogoigrovkah. I think this is the last lab tests, which will be released after a small test batch of field test users. List of testers will not be made public."
80sFREAK wrote:
Waiting for updates...
With current WIP they will be very soon.
bootyhuntah wrote:
I wonder what the plan is? I mean, are they going to implement a certain number of mappers, and then start selling the board....offering more mappers as they're made? I've really been checking out RAM Factory, and their website/YouTube videos seem more like... look what we did offerings, rather than advertisements for products. Does anyone own a RAM factory flash card that isn't directly associated with the RAM Factory? I wonder if it will even matter in the end, if they can't even accept PayPal....
We accept paypal already. We want to bring this device to the usable form and won't to receive negative feedback at the start. Minimum usable interface and updates from the card by user is our goal before the release. Then we can sell the finished hardware and concentrate on the development of the software part (mappers are software part for this device). I remind you that this is not a major project in our lives, so it is not intended as wages and do in our free time. I hope you understand that. We do it because we can. And do not mind sharing with others.
New WIP. Revised OS kernel. A current list of mappers: 0, 1, 2, 3, 4, 7, 9, 10, 11, 13, 18, 21, 22, 23, 25, 37, 47, 68 and 71. Completed the update from the memory card that does not require special equipment for service, and therefore, a little more testing and this card will be released. User interface slightly modified, but still yet the plain list. You can now scroll the long names manually, list management now easier, as in the good old multigame cartriges. I think this is the last lab tests, which will end small field test batch by users. List of testers will not be made public.
PS Tricky should not use google translate. :3
Do you plan on doing #34 any time soon? This mapper actually encompasses two distinct boards, one with CHR ROM and one with CHR RAM. I'm looking for the version with CHR RAM (BNROM and compatible) which is mostly the same as #7, just with fixed horizontal or vertical mirroring instead of D4-controlled 1-screen mirroring.
HardWareMan wrote:
We accept paypal already. We want to bring this device to the usable form and won't to receive negative feedback at the start. Minimum usable interface and updates from the card by user is our goal before the release. Then we can sell the finished hardware and concentrate on the development of the software part (mappers are software part for this device). I remind you that this is not a major project in our lives, so it is not intended as wages and do in our free time. I hope you understand that. We do it because we can. And do not mind sharing with others.
I'm glad to know you accept PayPal
tepples wrote:
Do you plan on doing #34 any time soon? This mapper actually encompasses two distinct boards, one with CHR ROM and one with CHR RAM. I'm looking for the version with CHR RAM (BNROM and compatible) which is mostly the same as #7, just with fixed horizontal or vertical mirroring instead of D4-controlled 1-screen mirroring.
Yesterday we made this
weird mapper. What's the point in it?
I'm really excited about this cart. But the thing I really want to know is, if the cart has the technical capability for an implementation of all the special chips.
I had been using oversize-BNROM for
my multicart project.
im-pulze wrote:
I'm really excited about this cart. But the thing I really want to know is, if the cart has the technical capability for an implementation of all the special chips.
What kind of special chips are there? If the conversation about VRСx, they will be supported with sound. But it audio part has to be tested carefully like any other emulator.
RP2C33 (FDS), NAMCOT 106/163 (N106), MMC5, SUNSOFT 5B (FME-7)
If the cart is theoretical capable you have me as a new customer and I'll throw many monies on you!
HardWareMan wrote:
Yesterday we made this
weird mapper. What's the point in it?
The only thing weird about it is that the same iNES number is used for 2 completely different mappers. I don't have any interest in the NINA-001, but BNROM (well, 16-bank version of it at least) is very useful for homebrewing, because it's dead simple to implement on hardware and allows for a fairly decent amount of PRG-ROM. I've been using it in my programs.
I see that you now have an FDS selection! It would be nice if in the next WIP video you would showcase it!
We've got NSF! Next stop - FDS. Some timings: folder with 715 NSF's load about 1 second without sorting and 4-5 seconds with enabled sorting. So, it's possible place all ROM set in one folder but it more wiser store ROM set into folders sorting by first letter for example.
HardWareMan wrote:
We've got NSF! Next stop - FDS.
OH YEA!
HardWareMan: The original Portopia in Japanese did use mapper 0. It was changed to 78 for RevA so it could be expanded for the English translation. It was pointed out that mapper 78 was rather obscure so the mapper for RevB was changed to 68 which is a SunSoft mapper.
I was the beta tester for both English versions of this game.
OK, last week we get some result. FDS games are seems to be run correct. It support games with any discs and size count. User can change it when game request it in in-game menu. Or even leave FDS mode and go back to the OS. No video for now, sorry. And no extra sound chips for now, but some of them are already at test phase. Stay tuned.
I think after FDS will be done test period for cartridge will be finished too. And then... :3
awesome! waiting for the final product!
HardWareMan wrote:
OK, last week we get some result. Stay tuned.
I think after FDS will be done test period for cartridge will be finished too. And then... :3
Good news! Your competitor says 3 months till his version is ready for sale. I can't wait to see who puts better features/more features.
We do not participate in the competition, we do not need this. I saw a photo of the Krikz's prototype, we have totally different approaches and are likely targets. NiOS against ARM.
By the way, we will do rev.B, for example the coprocessor will be replaced by the more powerful for the same price.
HardWareMan wrote:
I saw a photo of the Krikz's prototype, we have totally different approaches and are likely targets. NiOS against ARM.
What do you mean when you say "we have totally different approaches and are likely targets"? How is your approach different, besides using an ARM M3-Cortex instead of an Altera chip, for configuring the FPGA, SD card and SRAM?
bootyhuntah wrote:
HardWareMan wrote:
I saw a photo of the Krikz's prototype, we have totally different approaches and are likely targets. NiOS against ARM.
Both of you are using a Cyclone II FPGA right? Who is using NiOS?
The FPGA does not save own configuration when no power (SRAM based). I'm talkin about co-processor, wich used to configure FPGA every power up or when it need to change. Krikz use another CPLD by Altera which save own configuration when no power (FLASH based). Obviously there stored SoC by Altera or simply NiOS.
I assume you are saying krikzz decided to use a CPLD by Altera, and you guys decided to use an ARM M3-Cortex, for configuring the FPGA and SD Card interface. Okay...
Another WIP. At this time, testing of implementation of the FDS and NSF. FDS has a built-in menu, where you can select the drive and side of the disc, or go to the main menu. NSF does not yet have additional sound chips, all of the music played by the pAPU. But the extra sound chips on the way! First one tested in a unique mapper №69 from SunSoft, which was used only in the one game: Gimmick!
PS Do not pay attention to the garbage on the screen FDS and NSF - it debug stuff, in a release, they will be removed.
I like Gimmick! and NSF
Very impressive FDS support! I like how you can bring up a menu and switch between games. I can't wait until you impliment the extra sound in FDS and the VRC mappers!
This is it! We will try to spin up as fast as possible.
The Sunsoft 5B channels heard in Gimmick! are clocked twice as fast, making the sound an octave too high. Otherwise, it looks great.
my russian isn't the best, so whats the text about?
im-pulze wrote:
my russian isn't the best, so whats the text about?
A quick look at the page via Google Translate reveals that it's a pre-order thread.
HardwareMan, do you have a rough timetable as to when the cart will be up for general order in your shop? Also, how about another progress video when you get more of the extra sound mappers working?
That's pretty awesome. Certainly going to give krikzz / bunnyboy some competition.
Still very excited for this!
Does the battery holder intentionally look like a cat's face? =)
Pre order can be done
here.
HardWareMan wrote:
Pre order can be done
here.
How much costs the shipping to germany?
The estimated price in euros are ~ 116 €
How can we preorder? When do we have to pay and what payment methods do you support?
You can ask
here. For more info PM to Admin there. Later I give to you more details.
Will there be a NES-Version of the cartridge, or do you sell a kit? (cart & adaptor)
Do they fit in a normal famicom cart case, or do they need some work to hold your invitnes?
im-pulze wrote:
Will there be a NES-Version of the cartridge, or do you sell a kit? (cart & adaptor)
Do they fit in a normal famicom cart case, or do they need some work to hold your invitnes?
Further work is required only in terms of adding holes for SD/MMC card and USB. You can see it
here. Using with
this adator it fits in standard NES cartrige shell.
Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.
Drakon wrote:
Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.
yea - something like that. But I'm cool with the solution HardWareMan suggested also. (It would be a selling point, I guess, if you sell an adapter with the cart as a kit)
im-pulze wrote:
Drakon wrote:
Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.
yea - something like that. But I'm cool with the solution HardWareMan suggested also. (It would be a selling point, I guess, if you sell an adapter with the cart as a kit)
I build custom console stuff for people. I know how important it is to a lot of people to be able to buy something that they can just "plug it in and play". People are more than willing to pay the extra money to get something like that.
OK, I found some sad error in MMC3 and eliminated it. Now it works perfectly.
We start to tie the debugger to this cartridge. The first sketches.
Soon I'll make new WIP video, sorry for delay.
HardWareMan wrote:
We start to tie the debugger to this cartridge. The first sketches.
Soon I'll make new WIP video, sorry for delay.
What disassembly (decompiler) did you use?
byemu wrote:
What disassembly (decompiler) did you use?
We don't use any 3'rd party software, only self made.
That looks like a pretty legit debugger. Is it just PC software bundled with the flash cart? Or is it actively getting input from the cartridge? If so I'd be curious how it works exactly and what features it has since you can't really single step the NES/FC.
infiniteneslives wrote:
...since you can't really single step the NES/FC.
Certainly not in the traditional sense. But look at CopyNes. Wait! OH SHI-- :3
HardWareMan wrote:
infiniteneslives wrote:
...since you can't really single step the NES/FC.
Certainly not in the traditional sense. But look at CopyNes. Wait! OH SHI-- :3
Not sure what you may be trying to say here... I was speaking from the perspective of the cartridge you can't control the CPU's clock (which is the traditional sense). The copyNES doesn't have the restriction of only connecting via the cart slot. Are you getting around this restriction somehow?
infiniteneslives wrote:
you can't control the CPU's clock (which is the traditional sense). The copyNES doesn't have the restriction of only connecting via the cart slot.
but you can feed arbitary instructions to the cpu such as jump-0-bytes-forward to halt the CPU, or if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.only the sky is the limit when you plug an fpga on the cart slot
hyarion wrote:
if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.
Except most PPU registers aren't readable at all, and even if the CPU is "halted" the PPU will keep running.
tokumaru wrote:
hyarion wrote:
if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.
Except most PPU registers aren't readable at all, and even if the CPU is "halted" the PPU will keep running.
That's true. But we can spy any CPU writes to PPU and we've got CHR side, so we have almost full info about PPU state (making listening PPU register part inside FPGA can hadle even DMA transfers, because for PPU it is still regular write cycle). Also we have full mapper state. And at last, depend on mapper, we must track which PPU render position is now by watching CHR RAM access (you know about it: 4 cycles to every background tile). So you just need to lock stop position and release CPU near this position. Only VBLANK hardware signal is missing and unavailable (available only indirectly by tracking fetching NMI vector).
Yes, it can produce some unexpected behavior, such game crash, but still quite powerfull, doesn't it? Full control possible only on emulator (dosen't matter hardware or software). I hope this is a comprehensive answer.
So you're actually able to 'single step' through something like the MMC3 scanline counter properly? Freezing the counter is one thing but syncing it back up properly including proper filtering and such would be quite a feat. Not only that but you've got to actually fire irqs at the pre-freeze rate to keep things stable while freezing. Wowzers, are you actually doing all that?
Well, we make 2 types of mappers: one simple and stable just for playing and other one with savestate abilities and other that kind stuff for debug. Debug mappers will be evolved simultaneously with debugger to achieve maximum possible adequate behavior in single step mode without any extra requirement from NES/FC side. That's our goal.
OK, using some techniques of interpretation of PPU signals we got extended capabilities, that pushes limits. Now we have private attribute for every single tile (8x8) instead of block 2x2 of tiles.
Some demonstration. Now I can say: we will do GUI menu, that can contain game thumbnails. Stay tuned.
This is very very awesome !
Any reason you didn't go all the way and have an attribute for every 8x1slice?
HardWareMan wrote:
OK, using some techniques of interpretation of PPU signals we got extended capabilities, that pushes limits. Now we have private attribute for every single tile (8x8) instead of block 2x2 of tiles.
Some demonstration. Now I can say: we will do GUI menu, that can contain game thumbnails. Stay tuned.
Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)
lidnariq wrote:
Any reason you didn't go all the way and have an attribute for every 8x1slice?
You're right. I must go this way. Besides, that can be done easier than 8x8.
thefox wrote:
Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)
This video shows a render of solid 512x480 picture windowed by 256x240 (PAL). I ain't gonna upload to youtube this one.
Someone should youtube it as I can't access the site.
It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
I'll work further on this.
Here test with color. Attributes are random for test purpose. And it compatible with worst clones with internal 2KB VRAM that can't be switched off (with less color resolution).
HardWareMan wrote:
It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
A very simple heuristic would be to latch the bottom 3 bits of the PPU address during pattern fetch, and use that as the fine Y scroll. The leftmost 8 pixels will be wrong (and depend on what sprites are on the following scanline), but the other 248 should work correctly.
Alternatively, timed code in the CPU would allow 16x1 attribute zones:
Attachment:
File comment: Uses N163 ROM nametables and timed code. Uses ≈50% CPU time during rendering (but busywaits)
display.nes.zip [13.63 KiB]
Downloaded 229 times
Attachment:
display.nes.png [ 46.02 KiB | Viewed 36315 times ]
I think more careful timing should allow switching attribute tables every 16 pixels, which could be offset from the PPU's native 16 pixel wide segments to achieve a new attribute every 8 pixels.
lidnariq wrote:
HardWareMan wrote:
It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
A very simple heuristic would be to latch the bottom 3 bits of the PPU address during pattern fetch, and use that as the fine Y scroll. The leftmost 8 pixels will be wrong (and depend on what sprites are on the following scanline), but the other 248 should work correctly.
Thinking the same thing. I can detect render end (no PRD cycle in couple M2 cycles) and reset fine tune counter. Need more testing and analyzing.
I've just think about: we can use sprite prefetch mechanism to recover scanline number, right? With IRQ, fired at every 8 scanlines for set new sprite coordinates and VBlank for reset sprite position.
You could try an MMC5-like fetch follower:
3 /RD falls in a row with PA13 high: Set X counter (6 bits) to 2
PA13 rise: Add 1 to X counter
Counter in (34...41): Fetch sprite patterns instead of BG patterns
PA13 rise while counter >= 41: Set X counter to 0
/RD fall with PA13 low and X counter = 0: Set Y counter (3 bits) to PA2-0
I know about MMC5. But doing some researches with logic analyzer I figured out that NTSC and PAL PPUs have some difference in render cycle. NTSC one has strange double-ALE cycles without PWR/PRD asserting.
***
Almost got it:
***
Logic analyzer says:
Code:
Previous scanline
201E - 23C7 - xxx0 - xxx8
201F - 23C7 - xxx0 - xxx8
HBlank
2400 - 27C0 - 0000 - 0008
2401 - 27C0 - 0010 - 0018
2402/2002 - 2000 - 1000 - 1008 < Address glitch
2000 - 2000 - 1FF1 - 1FF9
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
Next scanline
2000 - 23C0 - xxx1 - xxx9
2001 - 23C0 - xxx1 - xxx9
....
201E - 23C7 - xxx7 - xxxF
201F - 23C7 - xxx7 - xxxF
HBlank
2400 - 27C0 - 0000 - 0008
2401 - 27C0 - 0010 - 0018
2402/2002 - 2000 - 1000 - 1008 < Address glitch
2020 - 2020 - 1FF1 - 1FF9
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
Next scanline
2020 - 23C0 - xxx0 - xxx8
2021 - 23C0 - xxx0 - xxx8
Every column of table is normal PPU nRD based access to VRAM. In HBlank we have double access with start address of nametable. Maybe, this can be used somehow...
I was rereading some old threads and wanted to point out that Visual2C02 showed this:
viewtopic.php?p=102081#p102081
Hi, is this thread dead? How is the development of the cartridge and software going? Any progress please?
mathusummut wrote:
Hi, is this thread dead? How is the development of the cartridge and software going? Any progress please?
We have some progress. We have most of gaming mappers. Some of them need to be revised but we work on it. But this version of SRAM cartridge has exhausted itself and we work on new one with some improvements. When it will be ready I will post here the specs.
What advantages does your device have (over Krikzz's one)?
