There are no IRQs on this one, this board is really simple; it's my replacement for NROM. I know it looks like it would cost more than NROM, but considering that you can't buy 32kB FlashROMs (and PPU doesn't have enough address lines to issue commands to SST39-series FlashROM), 74HC parts are cheap, getting them factory assembled in a large quantity is also cheap, hopefully the extra features makes it usable for a wider variety of situations, so my thought is that the additional costs are made up in volume.
I haven't forgotten about my mid-range 8T-ROM board, it's still possible that I will put that into production once there is need for it. There was a game in development that would have used it, but I haven't heard any news on it for a while, and I don't know if the developer is still interested in using my hardware for it. I thought I would use it for Garage Cart #2, but it is kinda overkill for that. It would have made for a nicer devcart certainly, with the WRAM and IRQ. I would totally go forward with that, if I was sure I could sell several hundred of them at least. In the meantime, there have been more uses for a low-end board, so I've made Cheapocabra.
Please be careful with the word "goat". In Christian circles, a "goat" is identified with those sentenced to death for not caring for the poor. And in tech circles, I shouldn't have to explain (see Wikipedia).
Interesting, I wasn't aware of the former association, and the latter, I guess I should be glad I didn't put any big circles on it, and I'll have to remember not to make a revision numbered "EO3" or something similar, lol.
I just like choosing interesting animals as mascots/totems for my boards, you might notice my past NES boards have had a squid, a turkey, and my board for Playchoice has a sea turtle.
So you have one version with BxROM (#34) style PRG, one version with UxROM (#2) style PRG, and one version with UxROM (#180) style PRG. How are these not "variants"?
The hardware is the same for all of them, what it does is interleave the fixed bank in software, by repeating it when the cartridge is programmed. My programming code does this automatically by checking the header in the iNES file when it is uploaded. That does waste half the ROM, but the price difference between 256kB and 512kB is smaller than ever, and I feel that the savings of not having to build and stock different hardware variants more than makes up for the cost (it's back to the solution of lowering costs by higher volume). One could consider 32kB paging to the preferred 'native' mode.
With erase pages how big? I ask because I noticed no work RAM in CPU space. Will games need to repeatedly bankswitch between the full flash page holding the save data and the just-erased flash page to which the the save data is being copied?
The sector size for erasing is 4kB, which is pretty reasonable. So, unless the save data is fairly large, it can be done without bankswitching. In any event, you must execute code from RAM when doing the write/erase commands because the ROM is unreadable at that time, so copying between banks wouldn't add much complexity to the code.
In addition, lack of work RAM breaks the model of running a large, complex simulation that has a good reason to use more than the 1500 bytes of game state you typically get on the NES. (This is 2048 bytes, minus 256 for VRAM transfer buffer and stack, minus 256 for OAM transfer buffer, minus about 36 for machine state things such as NMI count, controller state, NMI trampoline, local variables, and the like.) I guess games needing this much space can be redesigned to be turn-based without DPCM usage so that they can wait for vblank to access the second pattern page.
Yeah I know, my previous boards with Flash all had WRAM, so going without does make the Flash seem less useful. One thing the specs didn't mention, is that in the PPU space there is RAM available at $3000-$3FFF, 2 pages of it, so 8kB in total (bankswitched in tandem with the nametables), counting the part that overlaps palette memory. Obviously that's no replacement for CPU RAM, but it's something.
I think it may still be possible to create a large, persistent simulation with this small RAM + large Flash setup, if you're able to divide the world into smaller zones and allow for some load/save time when changing zones. I'm planning on writing a filesystem that includes wear-leveling, so while each sector allows for "only" 100K erases (minimum), this can be extended into the millions by spreading it out. And easily tens or hundreds of millions, if your data "file" is small.
Correct me if I'm wrong, but counting (NTSC) CPU cycles with this chip, sector erase time is 18 milliseconds, and byte programming is 14 microseconds. I'm coming up with 3,221 CPU cycles to erase, and 2.5 CPU cycles to program a byte. That seems pretty fast for programming, the actual command sequence to program is significantly longer than that. So you could probably do an erase or program operation without interrupting music playback (not DPCM though).
So really, with this board, if one has a game that's more suited to WRAM, it's probably worth considering using a board with WRAM (I could move 8T-ROM into production like I mentioned, it's just going to cost more). If you successfully redesign such a game for Cheapocabra, you could either sell it cheaper, or take some additional (well-deserved) profits.
Are these GPIOs, or are they useful only for LED output?
You could call them GPOs I suppose, heheh, since they are output-only. But yeah, that 4-pin debug connector outputs the same 2 bits that control the LEDs, plus 5V and GND.
Does that exclude me because I was planning to sell a clone of a famous Russian video game prior to a 2012 court decision?
Definitely not, I don't think that either of us could have reasonably predicted that something as simple as shapes in a game could be legitimately copyrighted. Plus, there were countless previous clones of the same game over the years.
If anyone was curious about the logic used, the prototype in the picture uses 2 74HC00s, but the next revision will use a 74HC02 and 74HC10. The functionality is the same, but I had some out-of-spec timing for the mapper latch (it works when I wire in an RC filter), so I had to change it.