nesdev.org

So I'm planning on adding discrete mapper support to this board for appeal to homebrews which are content with a discrete mapper. I had plans to make discrete mapper boards flashable via the kazzo using an added resistor to pull down the /OE pin which would also be connected to EXP0. That would allow for writing via the kazzo. But that wouldn't allow it to be flashed via the NES for saves and such.

You could of course add some extra logic to make it work, but if the goal is to be as minimalistic as possible, a one chip discrete mapper is desirable.

I had a thought which I believe will work with a number of limitations. Can anyone see any reason this won't work? Or another limitation I'm missing?

The idea would be to ground the /CE pin on the flash, tie /WE to R/W, and /OE to PRG /CE. The /CE pin can stay grounded at all times. The /OE pin must be high for writes, and low for reads. The mapper would be connected normally, and work for UNROM, ANROM, BNROM, etc or even some hybrid that banks CHR-RAM or something. So writes to $0000-7FFF would write to flash, and writes to $8000-FFFF would be to the mapper, and read from flash. That would only allow the last bank to be writable since you could only really use $4020-7FFF for non-conflicted writes. That'd be okay for game use generally though since you shouldn't have to access all banks for the sole purpose of saves. But that does suck up a fair amount of space in your fixed bank (EDIT: for standard UNROM style only though)

(EDIT: For UNROM): You'd probably want to write to the mapper selected bank in $0000-3FFF, BUT you'd have to be careful because of the conflicts with other hardware mappings. Writes to RAM and the PPU could be easily recovered from though if you were smart about it. One other limit would be that you couldn't write to the mapper (or anywhere really) while in the middle of a flash writing routine. You'd have to make your flash writing routine run from RAM because you can't execute from flash while in the middle of write routines...

The only other thing you'd have to watch out for is some how accidentally writing the unlock and write/erase command routine to the flash when you were trying to just use the hardware mapped to those locations. I think the chances of that are pretty slim though based on all the hoops you have to jump through to unlock the flash (expressed in limitations above.)

That's an awful lot of work to avoid needing a extra gate or two. But for people content with a discrete mapper it might be worthwhile to have nvm for saves on a discrete board without any extra hardware. Thoughts???

Doesn't the FLASH write negotiation process involve toggling all the FLASH address lines? How does that interact with the colliding functionality thing? Seems like it would also pose a problem for using a too-large FLASH for a game that didn't fill it. Would needing to change the bank to set the higher address lines interfere with the negotiation process?

lidnariq wrote:Doesn't the FLASH write negotiation process involve toggling all the FLASH address lines? How does that interact with the colliding functionality thing?

Well they don't have to toggle completely/exactly (poor wording, let me explain). This would be a /WE controlled write sequence, as such the address bits would only have to be valid while PRG R/W (/WE) was low. With the chips I'm using A0-14 need to be valid toggling between $2AAA and $5555 for unlock commands. This does bring up something I neglected though. My edit for UNROM only isn't completely true, because unlock commands would have to conflict with RAM $2AAA (mirrored to $02AA) even for 32KB banked mappers. So you'd loose operation of that byte in RAM while saving to flash for all discrete mappers. The $5555 unlock command doesn't conflict. There are other flash chips that only require as little as A0-A10 or A12 to be valid but I'm not using them on my v2 boards.

Would needing to change the bank to set the higher address lines interfere with the negotiation process?

The mapper would control A15 and up, and those don't need to toggle for writes. You wouldn't have to write to the mapper durring after starting the write sequence. So you can avoid conflicts there by just selecting the save bank prior to executing the save routine.

UNROM is more of a pain, but still manageable. To have a save bank outside of the fixed last bank would be annoying for standard UNROM as you have to write data to $0000-3FFF. And you're operating from RAM this whole time. As such you'd only have ~half of the sectors to choose from for saves, but that's okay. You'd have to select a save sector that ended up in $2000-3FFF. Additionally for the $2AAA command to be valid on UNROM you'd have to choose an even bank for saves. That way you don't have to write to the mapper between unlock commands and writes.

Seems like it would also pose a problem for using a too-large FLASH for a game that didn't fill it.

What do you mean? a game that used less than a sector's worth of data for saves? The sectors are 4KB in size for PLCC-32 chips generally. Not sure I understand the problem you're considering.

$2AAA is not a mirror of RAM $02AA; it is a mirror of PPUSTATUS.

infiniteneslives wrote:

Seems like it would also pose a problem for using a too-large FLASH for a game that didn't fill it.

What do you mean? a game that used less than a sector's worth of data for saves? The sectors are 4KB in size for PLCC-32 chips generally. Not sure I understand the problem you're considering.

Earlier someone mentioned flash with 64K sectors, the kind that would need a log-structured file system to use effectively. Besides, most discrete mappers lack the 7420 needed to decode WRAM, and games without WRAM can't really use a save bigger than 1K.

infiniteneslives wrote:UNROM is more of a pain, but still manageable. To have a save bank outside of the fixed last bank would be annoying for standard UNROM as you have to write data to $0000-3FFF. And you're operating from RAM this whole time. As such you'd only have ~half of the sectors to choose from for saves, but that's okay. You'd have to select a save sector that ended up in $2000-3FFF. Additionally for the $2AAA command to be valid on UNROM you'd have to choose an even bank for saves. That way you don't have to write to the mapper between unlock commands and writes.

I guess the negotiation process varies so widely by specific flash that it's not clear there's a unifying set of problems. For one that only used the 12 LSB address lines, it clearly wouldn't matter regardless of banking style. On the other hand, for something like the SST39SF0x0 series which uses all 15 LSB address lines, the command sequence for sector erase ends (write $55 to $2AAA, then write $30 to the sector to be erased) with the opposite value of A14 than for byte program (write $A0 to $5555, then write the value to the address), so I'm not altogether clear you could safely use those specific ICs on a reprogrammable UNROM board.

Seems like it would also pose a problem for using a too-large flash for a game that didn't fill it.

What do you mean? a game that used less than a sector's worth of data for saves? The sectors are 4KB in size for PLCC-32 chips generally. Not sure I understand the problem you're considering.

I was assuming more than 16 bits of address were required to enter any programming mode. But, given that these parallel flash are most often used in microprocessors with a 16-bit address bus, maybe that's foolish.

One other possible complication is that the 6502's R/W goes to its final value (along with the rest of the address bus) at the beginning of Φ1, and the value of the data bus isn't guaranteed to have settled at least until the beginning of Φ2. And M2 is even later than Φ2...

tepples wrote:$2AAA is not a mirror of RAM $02AA; it is a mirror of PPUSTATUS.

. Man, I impress myself some times with my ability to convince myself of such ridculousness as $2AAA > $1FFF...

Having the conflict with PPUSTATUS is actually perfect. Although I'm assuming nothing actually happens when you write to a read only PPU register. There's no reason to even write to $2AAA when you're normally reading from $2002. With $5555 not conflicting with anything, it's safe to say you'll never accientally jump through all the required hoops to accidentally write/erase flash.

Earlier someone mentioned flash with 64K sectors, the kind that would need a log-structured file system to use effectively. Besides, most discrete mappers lack the 7420 needed to decode WRAM, and games without WRAM can't really use a save bigger than 1K.

Well that discussion was under the assumption that a more complex mapper (> discrete) was being used. Even still, those 64KB sectored flash chips usually have one sector broken into smaller ones (as small as 8KB) for the MX29F*00C. With a save size of 1K you could still make good use of 4KB-8KB save sector(s) with multiple save profiles and retaining outdated copies for redundancy. 'Wasting' 3KB of a 128KB chip doesn't seem like a sizable loss IMO. For something without banked PRG-ROM that might not be the case, but that's kinda besides the point.

I guess the negotiation process varies so widely by specific flash that it's not clear there's a unifying set of problems.

Of chips in production today there are really only two flavors x8 and x16 (in BYTE mode). Their command set is effectively the same though aside from the one bit shift in addresses.

For one that only used the 12 LSB address lines, it clearly wouldn't matter regardless of banking style.

I always saw the ones with fewer required valid address bits to be preferable. But in this case having the lack of mirroring actually makes it simpler $2AAA doesn't mirror down into SRAM address space.

On the other hand, for something like the SST39SF0x0 series which uses all 15 LSB address lines, the command sequence for sector erase ends (write $55 to $2AAA, then write $30 to the sector to be erased) with the opposite value of A14 than for byte program (write $A0 to $5555, then write the value to the address), so I'm not altogether clear you could safely use those specific ICs on a reprogrammable UNROM board.

Yeah that's why I was saying you'd have to choose a save sector that was in an even bank. You need A14 to toggle between $0000-3FFF and $4000-7FFF without writing to the mapper. Selecting an even bank to contain the save sector would satisfy that, you'd just have to deal with the fact you're writting to the PPU (or RAM) at the same time. If you choose the two sectors mapped to $2000-3FFF you can avoid most likely deadly conflicts with RAM. You'd just have to get clever with handling PPU conflicts. I'd say just turn rendering off after each write to a mirror of $2001. Or just let the PPU go crazy for fun. Then assume the entire PPU needs initialized and redraw everything after writing save data.

I was assuming more than 16 bits of address were required to enter any programming mode.

Yeah I'm unaware of any such chips. That and it doesn't have to be a universal solution for every flash chip that ever existed. Just needs to work with ones choosen to solder onto the board.

One other possible complication is that the 6502's R/W goes to its final value (along with the rest of the address bus) at the beginning of Φ1, and the value of the data bus isn't guaranteed to have settled at least until the beginning of Φ2. And M2 is even later than Φ2...

Yeah I was thinking about that too. I think this is the real threat to my idea here.

SST 39SF0*0 datasheet wrote:During the Byte-Program operation, the addresses are latched on the falling edge of either CE# or WE#, whichever occurs last. The data is latched on the rising edge of either CE# or WE#, whichever occurs first.

So the address needs to be valid when R/W goes low. That might be an issue... Now that I can pull out my scope and compare, it looks like PRG R/W rises and falls with the address lines. Tas (address setup) is zero on these chips, but it's hard for me to say that the address will indeed be valid by the time R/W goes low. I always have a hard time conceptualizing zero times, really Vil of the /WE pin is what decides the timing. It might just work, or perhaps could work well enough with verification and repetition. You might be able to cheat and put a small cap on R/W but that's not exactly kosher... EDIT: One thing that does help is that we'll satisfy the 30ns hold time without issue. But I still think the chances are slim.

As for data being valid when R/W goes high, that's a non-issue with the help of bus capacitance. Data is usually valid well into the next cycle.

If the setup time on the address bus doesn't work out, the smallest piece of logic I can think of that'd solve the issue is to put an inverter to drive /CE with M2 inverted. Hey if you did UNROM with NAND gates, and 128KB PRG or less, you could get an inverter for free.

infiniteneslives wrote:if you did UNROM with NAND gates, and 128KB PRG or less, you could get an inverter for free.

ITYM NOR gate.

lidnariq wrote:

infiniteneslives wrote:if you did UNROM with NAND gates, and 128KB PRG or less, you could get an inverter for free.

ITYM NOR gate.

Well that'd work too.

OR gates: last 16KB fixed to last bank (no free inverter) 'standard mapper 2'
AND gates: first 16KB fixed to first bank (no free inverter) 'non-standard mapper 180'
NAND gates: first 16KB fixed to last bank, mapped bank number inverted (free inverter if 128KB or less) EDIT: this one might be preferred to avoid conflicts with PPU for writes.
NOR gates: last 16KB fixed to first bank, mapped bank number inverted (free inverter if 128KB or less)

Right?

Even still, those 64KB sectored flash chips usually have one sector broken into smaller ones (as small as 8KB) for the MX29F*00C.

That depends on whether the small sector ends up in a fixed bank or in a switchable bank.

And if it turns out that we must use mapper 180 for whatever reason, that's not too much of a problem for homebrew unless DPCM in the fixed bank is needed. It's not hard to put the vectors at the end of each 16K PRG bank. The problem comes when testing the game in an emulator.

tepples wrote:That depends on whether the small sector ends up in a fixed bank or in a switchable bank.

you'd pick the part with the top or bottom boot sector to get the desired placement of the smaller sectors. Either way it ends up the last/first sector is 16KB, below/above that are two 4KB sectors, and then the remainder for 32KB bank. So the two 4KB banks end up in the second or second to last bank which should work regardless.

And if it turns out that we must use mapper 180 for whatever reason, that's not too much of a problem for homebrew unless DPCM in the fixed bank is needed. It's not hard to put the vectors at the end of each 16K PRG bank.

Isn't it actually preferred to be able to bankswitch on the DPCM bank? So AND/NAND gates are preferred?

The problem comes when testing the game in an emulator.

Yeah there's always that hurdle. However my opinion is "If you build it, they will come."

infiniteneslives wrote:Isn't it actually preferred to be able to bankswitch on the DPCM bank? So AND/NAND gates are preferred?

Samples in the fixed bank allow decoding level data without interrupting drums or sound effects. If you have a lot of speech and only rarely access level data, the Crazy Climber layout becomes a good choice.

I gave a heads up about the INL-ROM cart to the chip music crowd @ ChipMusic.org
http://chipmusic.org/forums/topic/12922 ... rt-dumper/
The SXROM flash cart is a god send for running Pulsar and PR8. Thanks again!
Yogi

yogi wrote:I gave a heads up about the INL-ROM cart to the chip music crowd @ ChipMusic.org

Glad to see other communities interested in the project.

To answer your question from you other thread:

Been looking over the V2 board, so very excited seeing the ATMega footprint. Judging from the solder bridges, cart edge uC flashing?

You mean flashing the atmega via the cart edge? If so yes, I connected the SPI signals to the EXP port. But that's not only for programming the avr, primary purpose for routing those signals there would be to program a SPI flash.

In another thread you mentioned mapping the uC onto the data bus @ $5000 and $5001, is this the design? One last question, is the second CPLD need for the uC or can the single CPLD handle the uC address decoding as well as the mapper logic?

The idea is for the CPLD to decode $5000 for the avr and use one signal for a "avr select" for the CPLD to interupt the avr. Whether the avr or CPLD would decode A0 is TBD, and dependent if it would be necessary.

infiniteneslives wrote: You mean flashing the atmega via the cart edge? If so yes, I connected the SPI signals to the EXP port. But that's not only for programming the avr, primary purpose for routing those signals there would be to program a SPI flash.

I know you're in early stages ATM, but at some point do you think there could be a 'Arduino' development version? With an ATMega 328 @16MHz and access to the Rx/Tx pins you have the basic Uno. Coupled with your 'FDS' ram cart design this could be a great platform, for both the NES and Arduino community.
For myself, I fall more into the 'PIC fan' club, but the Arduino IDE and community offers allot. Seems like there is a Arduino project for just about every application one could dream up, so there is example code everywhere. This could make the transition for a NES developer very easy, but a little less for the Arduino user going from C/C++ to 6502 assembly (cc65 would help here).

The idea is for the CPLD to decode $5000 for the avr and use one signal for a "avr select" for the CPLD to interupt the avr. Whether the avr or CPLD would decode A0 is TBD, and dependent if it would be necessary.

OK. I could see where using A0 (and also A1) would be useful for passing some state data to the Mega. Example, the address that the 2A03 read from would signal the uC what to expect at the next access cycle; this could provide cycles for the Mega to fetch from flash or process data on demand and be ready to output at the next read.
Anyway, sorry for rambling. Looking forward to your progress.
Yogi

yogi wrote: I know you're in early stages ATM, but at some point do you think there could be a 'Arduino' development version? With an ATMega 328 @16MHz and access to the Rx/Tx pins you have the basic Uno. Coupled with your 'FDS' ram cart design this could be a great platform, for both the NES and Arduino community.

I've got it setup for re-flashing the AVR via a USB bootloader, it's the same way you're able to update the firmware on your kazzo. So it's the same chip as an arduino, but significantly simpler/cheaper to program. Personally I feel the arduino is an unnecessary level of abstraction.

OK. I could see where using A0 (and also A1) would be useful for passing some state data to the Mega. Example, the address that the 2A03 read from would signal the uC what to expect at the next access cycle; this could provide cycles for the Mega to fetch from flash or process data on demand and be ready to output at the next read.
Anyway, sorry for rambling. Looking forward to your progress.
Yogi

Pretty much yeah. It's all a juggling game between features, user friendliness, timing, speed, and i/o on the mcu and CPLD.