Will Powerpak affect your coding-habits on the NES or are you going to use it for gaming only?
Myself I'm really looking forward to it, would be awesome to be able to run my own code on the real thing and I will for sure code alot more for the NES.
Hopefully this will make me start coding more for the nes again, as I feel it was sort of a let down to not be able to test my code on the real machine before. =/
Hopefully soon I'll be able to afford one (I'm so broke that it's ridiculous). I'll just use it for gaming mostly, or to take my games and demos on the road, and maybe play around with the FPGA a bit.
I'm too spoiled by my ROM emulator, so I'd continue to use that and my Squeedo prototype (and sometimes my ROM emulator with my Squeedo prototype, heheh) for development. Having to swap memory between a cart and programmer gets old really fast. I like to run every test cycle on the hardware, and only use emus for debugging when I'm stuck.
Fx3 wrote:
What is this?
Are you serious? A
giant thread about the PowerPak has been going on since april and you haven't noticed?
I can't afford a PowerPak right now and may have to wait for the second batch three months later. It may make NES development more difficult for me if other members refuse to test my programs on hardware on grounds that I should have bought a PowerPak when I had the chance. I hope people on this board will remain as understanding after the PowerPak as they were before it.
Congratulations, tepples, you wrote your fist non "ultra technical" post since you're on this board.
And don't worry, I'll have to wait the second run too, as I just cannot buy on the net right now. Additionally, getting one power pak right now could be bad for my exams coming in 2 weeks, if you see what I mean.
Other than that power pack just allows much easier handling for testing on real hardware, but I'd still test on a real cart before claiming anything accurate, exept maybe for NROM and simple discrete logic mappers (wich can hardly have fake hardware emulation, exept maybe when it comes to bus conflicts, that anyone should have coded in order to avoid them anyway).
I'll still test things on emulation, and test on the real hardware here and here when I'm motived to do thing (there is no need to test EVERY change on the real hardware, as I'm ususally changing a lot of little things once at a time when I'm coding). I think I'll use Power Pak a lot for gaming, especially with RPGs wich are succeptible to loose saves on a real cart, but not on power pak since the compact flash can hold saves. Also a great thing is the ability to transfer saves from the PC to the cart and vice-versa, wich is GREAT !
You can then play on your PC a game, then contine to play it with the power pack using your last save, and then if you're having a hard time, transfer the game back to the PC and use emulator savestates to beat a boss or something. This has never happened before.
tepples wrote:
It may make NES development more difficult for me if other members refuse to test my programs on hardware on grounds that I should have bought a PowerPak when I had the chance.
I really doubt that something like this will happen... You are more likely to get more people to test your programs now, since the PowerPak makes it all easier for everybody.
The only way I had to test NES programs on hardware was reprogramming my flash chips and using them with one of my devcarts (I only made NROM and UOROM so far), but getting and setting up the EPROM programmer was so much trouble that I almost never did it.
With the PowerPak, I expect to use my NES much more, for both developing and playing. In fact, I'll probably keep the PowerPak permanently attached to the NES, and only swap the CF card! =)
Bregalad wrote:
Also a great thing is the ability to transfer saves from the PC to the cart and vice-versa, wich is GREAT !
This would make it possible to use level editors and other game tools coded for the NES itself and then read and use the created data on the PC.
Quote:
This would make it possible to use level editors and other game tools coded for the NES itself and then read and use the created data on the PC.
Oh, I have never trought of this, but effectivly this will become possible, and will become cool.
I think Celius made some tools that worked like this, and AFAIK he was the one that came up with the idea. For people who are more comfortable with 6502 ASM than anything else, this is good.
I'm considering coding tools like that, with the use of the lightgun to simulate basic functions of a mouse. It will not be possible to drag things, but "clicking" over an object and then over the desired destination works just as well.
Before the PowerPak, this could only be done easily with emulators. Maybe with the CopyNES, but I'm not sure. I really think the NES development scene will be divided in before the PowerPak and after the PowerPak.
tokumaru wrote:
I think Celius made some tools that worked like this, and AFAIK he was the one that came up with the idea. For people who are more comfortable with 6502 ASM than anything else, this is good.
That, or I should write a set of macros that turn 6502 assembly into C
Quote:
I'm considering coding tools like that, with the use of the lightgun to simulate basic functions of a mouse.
And it would cost about $15 to solder a Super NES Mouse (bundled with Mario Paint) to an NES controller cord and have the
real basic functions of a mouse. Heck, if you wanted, you could solder it into the same plug because the mouse uses only D0 and the Zapper uses only D3 and D4.
Quote:
Before the PowerPak, this could only be done easily with emulators. Maybe with the CopyNES, but I'm not sure. I really think the NES development scene will be divided in before the PowerPak and after the PowerPak.
Just as the GBA/DS scene was divided into before and after the hacking of the GBA Movie Player, right?
tepples wrote:
That, or I should write a set of macros that turn 6502 assembly into C
Wow, that'd be crazy! O_o
Quote:
And it would cost about $15 to solder a Super NES Mouse (bundled with Mario Paint) to an NES controller cord and have the real basic functions of a mouse.
Oh, please, no more spending money! The PowerPak, CF card and card reader already left a big hole on my budget! Plus, I prefer to stick to the standard hardware... I always hated when people made cool things for customized items that no one else had but them. Standard stuff can be used by everyone.
We already had the lightgun/mouse conversation before... =)
Don't get me wrong, I'm not against innovation or anything, I just don't think it is the first answer for everything. I think new things should be invented only when the current possibilities are not enough... And I do believe that simple editors can be controlled just by clicking around.
Quote:
Just as the GBA/DS scene was divided into before and after the hacking of the GBA Movie Player, right?
If you say so... I'm not into the GBA dev... =)
I, like most people on the forum, will use the powerpak for both gaming and my own code. As Tokumaru said, it will be so much faster for development testing. Plus, no more worrying about some of those less than reliable prom burners
The thought of having hundreds of NES games on 1 carts is just explosive
Quote:
Other than that power pack just allows much easier handling for testing on real hardware, but I'd still test on a real cart before claiming anything accurate
The PowerPak
is a real cartridge!
I'll mostly use it for gaming. That's what it's made for, and it will be strinkingly good at it from what I can tell, its only drawback to an emulator being the load time and the lack of external sound.
For development, it leaves a lot to be desired. Copying stuff to a CF card is just marginally less work than programming chips. I suppose a serial joypad cable would improve things, but this will be even slower than loading stuff from the CF card. And as there is no support for it in the boot ROM, the NES program you write would need to do the actual loading.
And while testing stuff on the PowerPak is hundreds of times more reliable than testing it on an emulator, I still advise people to test it with an actual AOROM/MMC3/whatever board if the program is intended to run on that. Otherwise, we might get a lot of lookalike-mappers to add to the iNES 2.0 format just to support homebrews.
In short, this is a gamer's device, not a developer's. That doesn't mean it's not in a developer's interest, as most of us usually love to play pirated games as well. And for the stuff you do release, people who use it on the real deal will most likely do it with a PowerPak, so it's in your interest to see your stuff run on it. :)
Quote:
And while testing stuff on the PowerPak is hundreds of times more reliable than testing it on an emulator, I still advise people to test it with an actual AOROM/MMC3/whatever board if the program is intended to run on that.
For MMC3 (and any other non-discrete logic mapper) I couldn't agree more.
For AOROM (and any other discrete logic mapper) since the only thing there is to emulate in hardware is a simple latch, I doubt the PowerPak could be any innacurate as long as the mapper itself is implemented right, but I'd still test on a real cart for principe.
Quote:
I still advise people to test it with an actual AOROM/MMC3/whatever board [...]. Otherwise, we might get a lot of lookalike-mappers to add to the iNES 2.0 format just to support homebrews.
This is my biggest fear, but face it: this will happen unless PowerPak's mappers are spot-on or they are tweaked so often that developers won't make things that only work on one revision of a PowerPak mapper. Or maybe PowerPak in its full power should be the target hardware, and the programs that run on it include a copy of the mapper code it runs with.
Why are you guys so scared of synthesized mappers? It's not as if MMC1 or MMC3 have any incomprehensible logic to mimic. Besides someone can always make test ROMs!
True, but it's not a replicable cartridge.
Quote:
Why are you guys so scared of synthesized mappers?
It's synthesized
mismappers that I'm scared of. Such things already exist in (almost?) every NES emulator, which is why testing with only an emulator is frowned upon.
If all commercial MMC1/MMC3 games work, chances are the logic is sound enough for homebrew, no?
kyuusaku wrote:
If all commercial MMC1/MMC3 games work, chances are the logic is sound enough for homebrew, no?
Not necessarily, as there may be some special case that never appears in a commercial game but can appear in a homebrew project. It's much harder to prove that someething is 100% accurate than it is to prove that something is not 100% accurate.
Sure some undocumented and unused feature may be missing but at least we know that the known features work when a commercial game runs well. Homebrew authors are likely to use only features documented anyways unless the purpose of the homebrew is to reverse engineer hardware, but in that situation you would only want to use the original.
kyuusaku wrote:
Homebrew authors are likely to use only features documented
They may intend on only using well-known features, but end up using obscure features too. There's no substitute for testing on an MMC3 if your program claims to work with it. On the other hand, an emulator author could create an emulator specifically to assist writing NES programs (games) that don't rely on obscure features. It would have many options for each mapper and main chips to warn if certain features are used. The main benefit would be many bugs caught automatically. Smart emulator authors already have something like this for debugging the emulator itself, where warnings are printed when weird things are done by the emulated code.
Using documented features doesn't always work, because it's possible for the documents to be flat-out wrong. I know I was really annoyed when my (really simple) MMC1 program followed all the docs, worked on every emulator (and probably still does), but gave me random results every time the NES was turned on (I didn't have a burner then, so I was stuck with the ROM as it was).
I think most of these out-of-production ASIC mappers should just be left to do what they were made for.. running the old games.
Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.
That all depends... what features do you require, and how do you intend do distribute your creations? It all comes down to whether you want to make and sell your own carts, or are satisfied with your stuff running on people's PowerPaks.
tepples wrote:
Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.
UNROM is pretty decent (and Squeedo can simulate it, except it has 4-screen mirroring). It's also easy to reverse the banks with the same PCB, when having $C000-$FFFF switchable is desirable (I'm gonna use that setup for my upcoming 'Chipography' music release).
And I actually really enjoy doing new NES board designs. I'm pretty sure I could even come up with a fairly cheap way to do a scanline or CPU cycle timer interrupt. If it's really needed, I may be able to source some 74LS670s so both banks could be independently switched (but I might face a minimum order, so I'd have to be confident the game can use it with good success).
I'm still willing to offer my new board design service for free (well, at my cost.. $100). That should be easy to make back with a good game release.
tepples wrote:
Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.
Why not design a very powerful mapper that is inexpensive to produce, easy to emulate in both software and FPGA, and then use that? I mean, why write games for old mappers that aren't even manufactured any more?
Code:
Why not design a very powerful mapper that is inexpensive to produce, easy to emulate in both software and FPGA, and then use that? I mean, why write games for old mappers that aren't even manufactured any more?
Because "powerful" and "inexpensive" rarely meet in this case. That's the trade-off. CPLDs are quite expensive when you want MMC3 functionality or beyond. TTL logic is equally expensive when getting complex, and akward to route. Full-custom ASICs are inexpensive to produce in larger quantaties, but it will cost you a fortune to setup manufacturing of them. And unless you have prior experience in ASIC design, something is likely to make the ASIC screw up in the first run.
For a really powerful mapper at an "acceptable" price tag, I think something like the flash-based ProASIC FPGA would do. It has the traditional drawbacks of not being 5V tolerant though, and you won't get below $10 a piece even for larger quantities.
Quote:
Because "powerful" and "inexpensive" rarely meet in this case
Couldn't have said it better! Just for some examples, MMC1 size cpld is ~$4. MMC3 size cpld is ~$15. MMC3 size fpga is cheaper (~$10) but then you need to add boot rom, voltage translation, etc.
The old mappers (U*ROM, A*ROM, etc) are still used because emulators properly support them with no work, and the chip is incredibly cheap at $0.25. If you need wram then you can bump up to MMC1 for still relatively cheap. If you need more, buy a PowerPak
Personally I think MMC1 should be the maximum target for most starters. It can be put on brand new hardware and is simple so the game will hopefully stay simple (and be finished!).
I find Jagasian's point persuasive. A cheap and easy-to-emulate-accurately mapper would be ideal for modern NES development.
Someone on 6502.org posted that the SX series microcontrollers can be had for under $3 a piece and run at 75 MHz, allowing them to emulate a programmable logic device plenty fast for a NES. These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.
MMCs are standard setup for the NES, so it definitely make sense to continue to use standard setups, and avoid complications, such as making super-bizare mappers made up just to have the desired features while being cheaper.
Plain discrete logic can still do great stuff, the only real problem is that features will eventually grow up a enourmous number of chips, and that it's a bit hazardous to route. (but nothing beats quad SMD chips when it comes to be horrible to route).
blargg wrote:
I find Jagasian's point persuasive. A cheap and easy-to-emulate-accurately mapper would be ideal for modern NES development.
Someone on 6502.org posted that the SX series microcontrollers can be had for under $3 a piece and run at 75 MHz, allowing them to emulate a programmable logic device plenty fast for a NES. These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.
I think this is a very interesting area to pursue.
I remember reading that Hellraiser for NES was designed to have a Z80 onboard (and thats around 2.5 MHz).
Al
Hey, sorry, I just missed that quote.
I think a x32 PLL multiplier on the M2 line would allow the microcontroller to run at 57.8 kHz on NTSC and 52 kHz on PAL, wich would be somewhat great. It couldn't react imediately unfortunately, but if the software would slow down it's mapper writes especially for the cart, it could be compatible with both the micro cart and the real (MMC1, MMC3, etc...) cart, making interesting things.
Quote:
These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.
That's quite true : I don't know why most microcontroller on the market are equiped with that much I/O port integread functionality, serial bus interface, etc... when all this will not be simultaneously used 80% of the time and can be done by software. Just to keep lazy people rest lazy and just do some register writes instead of doing actual coding. Features like A/D converters and such cannot be replaced with soft, tough (but couldn't be interesting to use as mapper).
Anyway even if such a micro would be used, some features, like mirroring control and bus conflicts disabling couldn't be done without some discrete logic arround, because the mappers output really needs to directly react to the inputs.
The point is that you use a fast, cheap microcontroller in place of an FPGA to reduce cost, nothing more. It's just to provide simple functions like scanline IRQ or bank switching, not extra processing. And then we'd come up with an easy-to-use design so that every homebrew developer could use the same mapper, not make a bunch of custom mappers as Bregalad thought I meant.
It could be nice if a microcontroller could be synced with the NES CPU. I'm definitely not an oscillator expert, but I'm kinda skeptical that a PLL on the M2 clock at such high speeds would be practical.
Memblers wrote:
It could be nice if a microcontroller could be synced with the NES CPU.
Hmmm, I take it you're implying there would be
metastability issues if it ran on its own clock? Or that it wouldn't respond fast enough if no synchronized?
blargg wrote:
Memblers wrote:
It could be nice if a microcontroller could be synced with the NES CPU.
Hmmm, I take it you're implying there would be
metastability issues if it ran on its own clock? Or that it wouldn't respond fast enough if no synchronized?
I was mostly thinking of how the code would synchronize, which could either be lazy, or necessary, depending on how problematic any timing mis-step would be (haven't thought it through fully, heheh). Kind of like how people using an MCU for bit-banged RS232 would sometimes use a clock that gives a whole number of CPU cycles for each bit that comes in. That would practically eliminate framing errors, plus make the code a cinch to write.
I'm also thinking, with the way oscillators start up (varying with temperature and such, even more with a PLL) they won't start on the same cycle. I guess if it's fast enough it'd be able to get an input from the NES and go from there though. And also that 2 different oscillators will drift apart from eachother over some period of time. Maybe not a problem again, for the same reason (great speed difference and waiting for NES input).
I had thought about trying a similar experiment on Squeedo, for doing something like "fast block transfers" (forgoing IRQs on both CPUs) where the NES could just read/write as fast as possible while the PIC struggles to keep up and not drift into timing errors. I never got around to doing that though.
It does sound like a good idea. The designers at 6502.org have the luxury of clocking the CPU with their microcontroller, though. Sure is easy when you can just change everything around.
blargg wrote:
The point is that you use a fast, cheap microcontroller in place of an FPGA to reduce cost, nothing more. It's just to provide simple functions like scanline IRQ or bank switching, not extra processing. And then we'd come up with an easy-to-use design so that every homebrew developer could use the same mapper, not make a bunch of custom mappers as Bregalad thought I meant.
You mean agree on a final mapper that would have enough features for everyone and then stick on it ? The MMC5 has almost all features one can think of, while being able to simulate lower features of lower mapper at almost perfection, would it be the universal mapper you're talking about ?
A MCU based mapper running with a PLL clock should definitely check for another thing at start-up to snch with the CPU (such as a simple rising edge of M2 or something in that sense). Then the mapper would have something like 32 cycles for each CPU cycle, maybe it's just enough to check if the mapper is written to and then react more or less immediately to it (some delay cycles woudldn't mapper when it comes to bankswitching). The problem is that mirroring control and CHR bankswitching should by synched with the PPU, wich is much faster than the CPU.