It is currently Fri Jan 19, 2018 6:12 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Thu Jul 22, 2010 7:57 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
tepples wrote:
The method of splitting a 29F040 between game and save would appear to need a custom mapper that places its registers below $6000 so as to distinguish flash writes from mapper writes.


It can be done with a 74HC139, which can be bought for maybe 10 cents, that chip could supply a chip enable for both a mapper register and WRAM. A generic 62256 SRAM cost should be around $1. You also want to consider assembly cost at around $.02 per IC pin (nevermind setup cost).

Next step up from the 10-cent mapper is the $1 mapper, a small CPLD. I've been wanting to make a small one in Verilog before I make the larger one later (heheh), I just haven't needed to yet.

For any kinds of parts cost I estimate that (in the worse case) something will add 3 times it's value to the selling price. Then try to figure out if it's worth it, if it adds that much value to it.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 22, 2010 8:38 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2986
Location: Tampere, Finland
Funny idea for a password (or pass sentence rather) system would be where it uses words instead of characters for the password. So let's say the dictionary contains 256 different words so each word represents a byte. The password would be something like "retrain museum hoe domed".

Easy to write down, easier to comprehend than bunch of random characters, but the dictionary takes space in ROM and entering the password is kind of PITA. The input screen could use some kind of word prediction though similar to ones used in mobile phones.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 23, 2010 6:07 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19487
Location: NE Indiana, USA (NTSC)
lidnariq wrote:
What are you really hoping for? Something that's compatible with the current NES save conventions (i.e. some kind of NVRAM memory-mapped in $6000-$7fff) or a cart with a cheaper way of holding the save data? Because you seem to be getting stuck on wanting both.

It'd be nice to have something I can use in an emulator or on a PowerPak so that I can test the saving code. But I guess I ought to complete the SNROM+battery version of one of these projects first so that we have something to port.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 05, 2010 10:42 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19487
Location: NE Indiana, USA (NTSC)
I want the extra work RAM even if it isn't battery-backed, but I also want the save. That's why I suggested that something had to be mapped into $5000-$5FFF, whether it is the control register for an I2C port (for serial FRAM) or a control for write-enabling the PRG ROM (for using a 29F040 as the PRG ROM and saving back to half of that). BootGod's DB lists six Japan-only games by Bandai on mapper 16 that use an I2C-like serial EEPROM.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 05, 2010 7:37 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
I looked up digikey pricing on Microchip EEPROMs on digikey on some sizes and it seems to roughly like this (obviously not a complete list):

$0.20 256 bytes
$0.40 8kB
$3.14 128kB (largest available)

I just wonder if there is a good way to get a clock for it. The trouble I see is that most address decoding will involve PRG/CE, which is already gated with M2 (the clock). Not sure if that's a problem yet (obviously it's been done before). There's probably one with an enable, I didn't check.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 12:58 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
This has been really interesting to consider all the possible configurations. After talking to kevtris today about how to interface an I2C EEPROM to NES (not too bad, but the cart requires 2 latched bits in, and 1 latched bit out to the NES. There probably is a cheap 1-bit latch, I haven't looked it up. But that should be trivial with a CPLD, and would tie right in with the rest of the mapper.

But kevtris and I both agreed that it's pretty cheap to add a battery. I think parts cost for CR2032 + SMT battery holder could be about 60 cents. So if the WRAM is already there, it's a decent option.

EEPROM is attractive for being maintenance-free. The batteries should be good for years at a time without an NV-controller, but I think it's dependent on the leakage current of the particular SRAM. Zelda lasted a long time (almost 20 years for my copy I think), but I imagine Nintendo was as selective as possible about the particular parts used. If the save-data continuity matters that much to the user, they probably want a CopyNES or a transfer cable anyways.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 2:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6641
Location: Seattle
Memblers wrote:
$0.20 256 bytes
$0.40 8kB
$3.14 128kB (largest available)


What quantities are you talking about, here? Microchip themselves gives quotes of 17c/29c/$2.40 for the those parts in quantities of 1k.

Quote:
how to interface an I2C EEPROM to NES (not too bad, but the cart requires 2 latched bits in, and 1 latched bit out to the NES.


A SPI interface should only require one latch -- or could be attached to the joypad port. (Whether that's desirable is another question.)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 3:36 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
I think those prices were for 100 quantity, I could have mixed them up.

Quote:
A SPI interface should only require one latch -- or could be attached to the joypad port. (Whether that's desirable is another question.)


I haven't looked at the speeds yet, but the latched clock and data might be needed if the NES is faster than the chip is rated for.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 6:15 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19487
Location: NE Indiana, USA (NTSC)
A lot of these I2C parts are rated for 1.0 MHz. The NES is up to 1.8, but it'd probably actually operate it at 1/6 of that (ROL/STA loop). The CPLD could handle clocking the interface, but then someone who knows Verilog and soldering would need to handle that.

I understand CPLDs are sized by how many bits of state they store and how many I/O pins they have. How much effort would it take to write a CPLD mapper in Verilog that does this:
  • PRG switching equivalent to MMC1 SUROM (4 bits for PRG page number, 1 bit for 256 KiB super-bank number, 2 bits for PRG bank mode)
  • One switchable CHR bank at $1C00, out of 32, so that 1 KB of a 62256 CHR RAM page can be bankswitched (5 bits)
  • Mirroring like MMC1 (2 bits)
  • A latch used for I2C communication (3 bits)
  • Reset detection (? bits)
  • All registers in $5000-$500F space so as not to overlap if used in write-back-to-29F040 mode
And about 34 I/O pins:
  • NES side: PRG A14-A12, A3-A0, D3-D0, /CE, R/W, M2; CHR A13-A10; CIRAM A10 (21 pins)
  • Internal side: PRG ROM A18-A14, /CE; WRAM /CE; CHR RAM A14-A11 out (A10 shared with CIRAM); I2C SDA, SCL (13 pins)

For 7 more pins and 2 more bits, you could add an IRQ on tile $FF access, but let's not get ahead of ourselves because the goal of this topic is to explore a new mapper allowing easy ports from SNROM and SUROM (MMC1 + PRG RAM + CHR RAM) but supporting flash-writeback and I2C save types.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2010 6:24 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
The description helped me get started on it, thanks.

So far it has pretty much been simple to implement. This is my first practical verilog project, so most of the effort was learning the language (conclusion - extremely C-like in syntax, not bad at all).

So far it's using 30 macrocells (out of 36 in this smallest CPLD). It's not tested at all, but it does compile and synthesize.

What I've come up with so far is:
-PRG $8000 and $C000 are banked independently (so it supersedes any 16kb and 32kB modes). 256kB max though.
-CHR-RAM Is banked, 2 banks again, at $0800-$0FFF and $1800-$1FFF, the rest is fixed.
-registers at $5000-$5007
-WRAM is banked

Also PRG /CE (to the ROM) isn't needed, but PRG /RD is. Since the NES provides no active-low read signal, which is no problem for SRAM, but I don't know if I trust using /CE as /RD with any random type of flashrom. Might be OK on specific ones. I suppose that could be a minor problem for the MMC1 flash cart idea in the other thread. On Squeedo I just invert the PRG R/W line using a NAND gate, making it low on read to get this signal.

i2c remains to be added. Should be easy.

I'm also wondering if it's worth using the on-board RAM for nametables. Allowing nametable banking, and 4-screen mode. I'll look into that last (and hopefully have enough I/Os to make it optional, probably not though).

It definitely needs a bit more size with the PRG-ROM bankswitching, so the 'super-bank' idea sounds effective. I think I could also double the size with no more I/Os by doing a trick where $8000 could only use even banks, and $C000 can only use odd banks. It makes sense to me, it doubles the maximum size but also forces you to use both banks evenly (so it might take a bit of duplicate code).


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2010 6:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19487
Location: NE Indiana, USA (NTSC)
Thanks for starting on this, Memblers.

Memblers wrote:
I'm also wondering if it's worth using the on-board RAM for nametables.

MMC1 style mirroring needs 2 bits of state, which means about 2 macrocells. A 4-screen mode fixed to the last 4 KiB of CHR RAM would take one more bit. Independent switching might exceed 36 macrocells.

Quote:
It definitely needs a bit more size with the PRG-ROM bankswitching, so the 'super-bank' idea sounds effective.

But we'd still have to add some sort of reset detector to make it always start in one or the other super-bank, so that we don't power on or reset into a freshly erased sector of a 29F040 chip. Is this there, or are you relying on a 16-byte reset stub in all banks?

Further steps:
  1. Test it
  2. Make I2C
  3. Make a demo of saving on both I2C and flash save types
  4. Port it to PowerPak's FPGA
  5. Get it working in at least one PC-based emulator

If you get this working, I'm willing to give you some repro business by developing a game for it.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2010 6:59 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
Actually I'm still kinda concerned about the power-on state of the CPLD. It has to copy the config out of EEPROM into SRAM, but it gets an early start by doing this while the VCC voltage is still rising. But I also have to regulate 3V to give the CPLD, which will add some kind of delay (not sure what).

So I'm thinking either:
a) it will be fine and start up in a good state
b) I could tri-state the latch outputs and add pull-up resistors
c) something else?

I'm really not sure what will happen at startup, if the NES can possibly come alive first, or what.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 10, 2010 3:13 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
Double posting, but the story continues..

CPLD start-up should be safe, due to the NES CPU reset having a delay. But since reset is done by the lockout chip and by charging a capacitor, how different is a toploader and famicom? I don't know. But definitely they should have delays built in, as I realize now it would be stupid anyways if the CPU started as soon as possible (possibly before the memory is ready, etc).

I've got the reset detector figured out, it's as simple as using a capacitor charged by the M2 clock to release it from reset mode. Though I'm getting kind of stingy with the I/Os at this point (I think the reset could share an I/O with part of the i2c if it has to, as I don't think one wouldn't ever need both at the same time).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 14, 2010 9:08 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3500
Location: Indianapolis
Triple post c-c-combo!

It all fits in the CPLD, using 36 macrocells and 34 I/Os. I'll see about making a PowerPak version of it (I'm still waiting on the Xilinx ise 9.1 download which is 2.5GB).

So that fills up the chip. Reset is in there, it resets the PRG banking latches only, but I guess with the added diode/cap/resistor circuit it would reset the banking even if the reset button is hit. Some pirate multi-carts use the same circuit. I think it might not be needed for power-on, because in the design software you apparently can specify a start-up state for all of the registers. So hopefully this pin and extra circuit isn't even needed.

The "superbank" bit is in there, so it can address 512kB. That's perfect for 32-pin memories.

I2C support is in, both the address and data line are bidirectional, latched I/Os for the NES to control.

I looked around at flash memories available, and the SST39SF family seems to be nice and very cheap. It is byte-programmable and uses 4kB-sized erase sectors, so I think this makes the I2C / EPROM combination a lot less appealing. It claims 10k erase cycles minimum, but that could be extended further with some wear-leveling.

If I took I2C out of the design, that would free up a couple pins. Perhaps I could even make the PRG bankswitching 5-bits for both slots instead of 4 (so the superbank bit would no longer be needed).


edit - For the SST chip I noticed the flash write endurance is 100k in another datasheet. I think maybe the 512kB sized one is 10k. The price difference between the sizes is negligible.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 15, 2010 3:02 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7350
Location: Chexbres, VD, Switzerland
tepples wrote:
I just finished a demo of password generation, entry, and validation.
Your method looks similar to what I'd have done if I were to code a password system.

May I ask how you encrypt the bits ? It's not clear in the doccumentation. It says it's inspired by TEA, but where can I find info about that ?

If I were to do that I'll scrable the bits in a random order and EOR them with some constant to make it impossible to "guess" their order originally. Is it what you're doing ?

So I guess the minimal lenght of a password of a 32 caracter set is (8/5)*(#of bytes + 1)
Your case is for a # of bytes of 7 (since there is one validation byte).

Also I wonder if it's possible to make the validation byte so that the "best" possible password has a meaning in english (or whatever language), but without "hard-coding" it. I've heard DQ1 and/or 2 does something like that in japanese, but because they're in japanese it's hard to verify.

Finally, I think another system should be good, and that doesn't require the character set to be exactly 32 chars : You make a big number from your game variables (bit-scrambled of course) and "convert" this number into base 26 (for example, assuming you use the 26 latin letters).
To decode the password, convert it back to base 2 and de-scramble the bits, with of course some validation bits that should remain constant.
The base conversion itself acts like encription, so I guess it should be hard to "guess" passwords.
It's however more complicated to compute the # of symbols per bits.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group