I've recently been motivated to increase the size of the cartridges I use for my game console project. So far I've been using simple 8KB EEPROM chips that work well enough, but I'd like to try using this parallel flash part I found that stores 16 megabits (or 2MB). The datasheet indicates that these can be used in much the same way as a parallel EEPROM and have a 55ns fetch time, so it seems like they should work well in my system that runs at 3.5MHz.

One thing that comes to mind is that of course some bank switching will be necessary. Controlling the higher address bits with a register of some kind should be pretty straightforward, except that typically I'm running code off the cartridge ROM. So switching the entire ROM-assigned address space would produce complications, right?

A15 on my system is already used to select the cartridge port, so I had the idea to use A14 as a sort of "banking enable" where it drives the banked address pins high if A14 is high, and enable output on the bank register when A14 is low. Is this a reasonable approach?

This is the flash part in question. Or rather, I'm gonna try to use the $3 part with the Micron part number. But the linked page has the datasheet.

I also attached the schematic I have drafted for the cartridge. I don't necessarily intend for the game console itself to write to the memory. The programming device will use the same edge connector though, which is why I have write-protect and ready/busy on solder jumpers. It also seems unlikely that a crashed program will accidentally send the correct set of commands to modify the flash data; so it should be safe to leave these jumpers connected in "writable mode" during development.

That sounds as if you have logic in the main system to somehow enable or disable the cartridge port. Is that really the case? Wouldn't it be easier and more flexible just to have the cartridge port be a straight extension of the system bus and let the cartridge decide to what addresses it will respond? (Consider that you may want to have more than just ROM in $8000-$FFFF on a cart.)

At any rate, fixed ROM in $C000-$FFFF and banked ROM in $8000-$BFFF is the approach used by UxROM, one of the simplest NES "mappers" (the term used in the community for decoding logic on board an NES cartridge). You may find it enlightening to read through the details of some of the other mappers to see the variety of hardware they put on cartridges and the various ways they have of accessing it.


Keep in mind that it's not unusual for developers to want persistent RAM (back in the day, usually battery-backed) in a cartridge for game saves and suchlike. But in this particular case, yes, disabling writes to what is intended to be ROM for the "production" carts is probably a good idea.

A thought that comes to mind is to have a dedicated "dev mode" line on the cartridge port that is grounded on consoles, but brought high on programmers and switchable on development systems; that could be used to let carts enable/disable certain hardware (such as EEPROM write protect), albeit sometimes at the cost of a little bit of extra circuitry on the cart.

It looks to me as if you don't need a jumper for ready/busy, though, do you? If the ROM is never written, ought ready/busy never go low? And unless there's a reason to do otherwise, you might also consider always holding /WP high and instead jumpering /WE between system /WE and Vcc, so that you're using the same design as you'd use on other EEPROM chips that don't have a separate /WP line. (Having a DEV line on the cartridge port would be a reason to do otherwise, of course. :-))

By the way, wiring the EEPROM ready output to the CPU's READY line is a brilliant little trick!


That may be true of this EEPROM, but others, such as the common AT28Cxxx parts, do not have any special write setup IIRC (though some do have special sequences for full-device erase and the like)

_________________
Curt J. Sampson - github.com/0cjs

Ah, I hadn't meant it quite as drastic as that. The cartridge port does essentially expose the system bus. The only thing "special" about it is that it gets an inverted A15 line passed as a chip select. My previous cartridge design was essentially a breakout board for an 8K EEPROM so this helped to keep the part count low on the cartridge. The cartridge hardware is free to respond to pretty much any address it wants, but the upper half of memory is guaranteed to not be contested by the built-in hardware.


Yup! I've been looking into a battery-backed SRAM design as well. I'd prefer it over a flash-based save not just because of the simpler write process but also not having to worry about the memory getting worn out from repeated writes.


As it happens, this is meant more for use by the programmer than the system. Truth be told I wasn't sure how it would interact with the system which is why I put it on a jumper. But if it does turn out to make it easier when I experiment with writing to flash from the game system then that'll be a nice bonus! (About half the jumpers I put on circuit boards are to defer thinking hard.)


I had this problem enough with the AT28Cxxx-based cartridge that I put a ZIF socket on one and did a little bodge work to keep !WE pulled high. Fortunately the system runs stably enough with a *correct* program that it doesn't often try to write to the cartridge by accident, but of course software (especially software in development) is seldom fully correct. This might even have resulted in some of my stock of cartridges getting prematurely cooked.

Hi, guys.

Not sure if this fits into your latest discussion, but here's what popped into my head in response to this quotation from the lead post:
Okay, so A14 says whether the RAM's high address lines get $7F or the value in the shift register.

Instead you could add another shift register. Then A14 would say which of the two shift registers applies. (And you can still get $7F if you want.)

There's little or no extra hardware cost, because the '244 is eliminated. As for benefit, you gain the ability to simultaneously have two "windows" open into the RAM. That'll result in a massive speedup if you're ever faced with doing a copy from one extended-RAM area to another -- likewise when comparing two areas. Is that something you'd value?

Edit: another benefit arises when creating or examining an object that straddles a window boundary. Using two windows you'd be able to easily access the entire object.

I guess at powerup we need the upper window to self-initialize to logical $7F, but nothing stops us from redefining all the RAM address inputs as active-low. Then for initialization we can use the HC595's ability to reset to physical $00.

Hmm, might be a downer if adding the extra shift-reg means you become obliged to output sixteen bits (and sixteen clock pulses) every time. But I can think of some solutions for that, and probably you can too.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That is an interesting idea! On my system the main use of the extended memory would be to store large assets like sprite sheets, tilemaps, and music. But the beauty of putting it on the cartridge instead of the mainboard is of course that the cartridge can be tailored to the application running on it.

One way I could deal with the difficulty of both windows being movable is to copy code to RAM on reset and run the rest of the program from there.

As for the extra shift register, I have one more VIA pin exposed on my cartridge port that could be used as a selector.

I could yet have a use for this on the next revision of the motherboard, where I'd like to expand the available RAM at the bottom end of the memory map without interfering with stack operations.

> But in this particular case, yes, disabling writes to what is intended to be ROM for the "production" carts is probably a good idea.

Something to watch out for: in some cases, if you send a write to an EEPROM, even if it is write-protected, it will go through the timing of a write, which means the next few reads will appear corrupted. So unintended writes are best avoided, unless you've ruled this out.

This explains some of the more dramatic crashes on my system!

As far as avoiding inadvertent writes, the "Software Data Protection" feature on these models is pretty handy.

One of the tricky things about working with flash on low-end embedded stuff is buffering data every time you write. It looks like the chip you linked has 64k blocks, so you would need to read the whole block into RAM if you wanted to modify the data in that block of flash. One thing you could do is implement your own wear leveling system if your saves take up much less than one block. For example, if you only need 4k for a save, save it to the first 4k the first time then to the second 4k the second time, etc. That way you get 16 saves per 64k block before you have to erase. You can keep track of which save is active by using the first few bytes of the block as a tally system. Erasing the whole block will set those bytes to all 1s. Every time you save, turn the next 1 in the tally bytes to a 0. Count the number of 0s in the bytes to know which save you're on.

If anybody happens to have particular experience with these Parallel NOR flash chips, I'm having the most peculiar issue when trying to build a cartridge programmer for it. It's supposed to be in read mode on power/reset, and it's supposed to be fully cleared to 0xFF from the factory.

For some reason instead it outputs 0x07 to the data pins no matter what. At first I doubted my soldering since this is a TSOP48 part with pins I can just barely see. However after assembling three copies of the board and all three copies behaving the same way, I'm thinking something must be wrong with my board design. (or I'm very consistent in my soldering mistake)

EDIT: Nevermind, at some point I got the pins reversed on my cartridge board in my EagleCAD part library and never realized until now. That's why the old card design was working fine but the new card wouldn't respond and just got ominously warm.