It's actually quite error-tolerant, since crystal speeds varied between computers, modems, and probably temperatures. A hardware UART checks the input I think at least 8 times per bit, and the value set for the longest time 'wins'. In software for receiving you just delay the time for 1.5 bits after start, so it's right near the 'center'. And if the timing is off a little (or even a lot, at lower baudrates), it only has to stay roughly in sync for 8 bits - so there's little time for any error to accumulate before it re-syncs for the next byte. It's much more forgiving than doing timed PPU tricks. blargg even got this to work while the DPCM channel was playing (and Bananmos got PPU tricks to work while DPCM channel was playing in "Years Behind", but that's a whole other impressive bit of hacking, heheh).Bregalad wrote:Sounds cool, but it should have been hard to get the timing for exact asynchronous communication.It's actually really easy to save/load data over the controller port to an RS232 port. Besides ground, it only needs 1 input (controller data) and 1 output (controller strobe). I think some older computers often used 5V serial ports, so in that case it could be wired up directly with no voltage translator. Building one of those MAX202 circuits and getting XMODEM protocol working with NES was my 2nd hardware project (and the first one that I did mostly on my own).
Timing formula if you're curious for NTSC is roughly 1789000 / baudrate. 93 NES cycles per bit at 19200 baud (what I used), and a whopping 745 NES cycles per bit at 2400 baud.
It really tempts me to pick up that idea again for general production, since more people are hacking with the hardware these days I think it'd make a fairly compelling little accessory if done with USB and sold cheaply enough to where it's hardly profitable (d'oh!).
I remember watching kevtris working on his FPGA NES just a few years ago, when he made a change and compiled it, it really would take hours to complete..! Computers are a little faster now (dual and quad-core sure helps), but that still seems like an amazingly intensive modern-day compilation process.Yeah usually I just try stuff and see what happens in FCEUX. If it would take hours to compile, never I could do this. And when doing raster effect, I add and remove a few cycles and try different things. If It'd take hours to compile, again I don't know what I'd do.I don't know about you guys, but there are times when I'm feeling so lazy that I guess a few combinations of signs/values/whatever and compile to see what works in a particular logic block. Sometimes it's faster than actually doing the math or tracing the code in my head, if the options are limited.
May be cheaper to start up, but I'd imagine for a game like SMB3 or something where they knew they would sell tons of copies, MaskROM may have ended up being the same cost or cheaper in the long run. And RAM being a commodity, perhaps may have been subject to price fluctuations. Just my guesses.I'd imagine that the CHR RAM boards might have been cheaper because there wasn't a mask setup cost for the CHR ROM; 6264 SRAM was a common off-the-shelf part that could be used across all such titles. Was this the case?
Also regarding the cost to publishers, the impression I got from reading some interviews was that Nintendo actually made their publishers pay up-front to produce a pretty large minimum number of carts. So publishers were taking a risk, while Nintendo was set to make money even if the carts were scrapped. No wonder Nintendo was so successful, and Atari/Tengen was so eager to set out on their own making unlicensed carts.