FYI Lattice is only one still recommending a 5v tolerant CPLD for new designs with their 4000v series. A Rep told me they expect them to stick around for upwards of 8-10 years because of the 5v tolerance. Still didn't get anything in writing though. They didn't have a good answer as to if they'll ever update the software to work on future OS's however.. :/ The requirement to use decrepit ispLEVER classic is the biggest drawback for the lattice 4000v series.

Xilinx started EOL on 9500XL series 2 years ago, and Altera just announced EOL on EPM3000 series.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Great point, I guess close to 95% of MMC1 games would fit, Only games using all address lines (256k/128k) (currently there is non known game using that), or all who use all address lines but one while also using SRAM (for example SKROM 128k/128k) wouldn't fit.

However I do not know if either of those configurations fit a single Atmel V750 chip. Even if they do, it's less nice to have to reconfigure the chip for each MMC1 sub-configuration than having a generic MMC1 using 2 chips but that can be used with aynthing without changing how the chips are programmed.

Quote:

FYI Lattice is only one still recommending a 5v tolerant CPLD for new designs with their 4000v series.

Atmel CPLDs are not only 5V tolerant but apparently function entirely in 5V logic. There's only 2 models available, but I think they are still recommended for new designs.

Last edited by Bregalad on Mon Mar 27, 2017 3:22 am, edited 1 time in total.

So I finally managed to have a MMC1 with a set of 2 Atmel v750c chips. Those chips actually have only 10 "hidden pins" for a total of 20 registers (I previously tought they had more - the datasheet are extremely unclear and documents very poorly the possibilities of the chip). Both chips are used to 100% of their capacity ; all 40 registers, all I/O pins of the 1st chip and all output pins of the 2nd chips are used ; and making a MMC1 that way was barely possible. This is not yet tested on hardware, so it's likely it's still imperfect.

It's also possible to use a single Atmel v2500 chip, but then the chip is barely used to half of its total capacity.

How it work internally :The shift register is made so that it is initialized to '11110' whenever a "reset" write or a "5th" write is made. When a 5th write is made, the upper bit becomes '0' and then the shift register know it can reinitialize itself to the value '11110'.

Internal registers are loaded with the 4 low bits of the shift register and the D0 line directly. They are inverted internally, because the Atmel chip guarantees that all registers are reset to '0' on power-on if some conditions are met (monotonic voltage increase and no clock oscillation before final voltage is reached). I hope those conditions are met with the NES, so that we can know all MMC1 registers are initialised with '11111', which means the last bank is always switched in at $c000-$ffff (and also at $8000-$bfff but that's less important). SRAM is also disabled on power-on. I believe this is how actual MMC1 chips behaves (at least the most common revisions). If it wouldn't behave like that, it would be difficult to have a reliable reset vector in ROM.

I did not design the shift register so that the first write after power on counts as an actual "first" write. Actually the shift register will reset to '00000' so the 1st write after poweron will be counted as a 5th write, using '0' for the 4 lower bits and D0 for the upper bit. Writing a value with D7=1 first is thus necessary in practice - I am unsure about how a real MMC1 behaves. If it is required than the first write after poweron is counted as the 1st write, it should be possible to do that by reversing the polarity of some bits in the shift registers in a smart way - but this would be yet another headache and an additional source of bugs.

Both the internal registers and the shift register are clocked with a partially decoded signal, called Write_to_MMC1. It's enabled when $8000-$ffff is written to and when this write is not blocked because it follows directly another write. Then the remaining decoding is done for the registers on the D pin. The reason the decoding is not done solely on the D pin is because there weren't enough product terms to do that for all pins - and that's also the reason the decoding is not done entirely on the clock pins. Normally adress lines should be stable when ROMSEL is active, so glitchy clocks on either the shift register or internal registers shouldn't be possible - but that could be a potential problem.

For the 750c version, the logic is cut in the following manner:

1st chip handles Reg0 and Reg3, the PRG-ROM switching, the PRG-RAM enable, the mirroring control and the Write_to_MMC1 clock decoding.

2nd chip handles Reg1 and Reg2, the CHR-ROM switching and the shift register.

Notice that the split boundaries are not very logical some signals goes back and forth between 2 chips - for example when writing to reg0 to set CHR-ROM switching mode the write logic is decoded in the 1st chip, the data passes through the shift register in the 2nd chip, is registered in reg0 on the 1st chip and then is output to be used by the 2nd chip. But that's the sole way it could be made to fit in 2 chips. Splitting it along more logical lines (PRG half and CHR half) would not fit in 2 chips. This also implies that both chips should be prevent, even if CHR-ROM switching is unused (typically for CHR-RAM boards).

Since the V750c chips are basically like 2 22V10pals tied together, this means it might be possible to do a MMC1 chips out of only 4 PAL22V10 chips and not 5 like I proposed in the original post, however doing so will be a major headache and might cut the functionality in even more illogical boundaries.

PS : To people who are going to say me : Why didn't you add feature X, Y or whathever - this was never my goal to create mappers, but instead to replicate the existing Nintendo MMC1 exactly as it is (including it's shortcomings) using a reasonable number ordinary orderable customer chips. Doing with 74xxx logic would require way too much chips - getting it done in one or 2 chips is nice - and that without requiring a surface mount component nor any regulator nor level shifters.

They only come in surface mount format, unfortunately. For some people that might not be that much of an issue, but it's still a major inconvenient in my opinion. I didn't understand whether they were more or less powerful than the v2500 (which comes in traditional DIP format) - the number may it look like it's an intermediate between the v750 and the v2500 but I could be wrong.

I looked into it, a full MMC1 is definitely possible with four PAL22V10 chips (instead of 5 as proposed in the inital post) - however they'd have to be splitted up very differently, and this would probably make it impossible to remove a chip or two if not all the MMC1 is used. This is of course less convenient than two V750 chips or a single V2500, but the chip is more widely available from many manufacturers insted of being Atmel only - and it's still a lot more convenient than a dozen of 74HCxxx chips !!

So I finally got a full MMC1 on only 4 PAL22V10 chips (instead of 5). The only remaining problem is that I rely on registers being reset ('0') at power-on for a fully functional chip, which is the case with Atmel 22V10s but I'm unsure whether it's also the case with other manufacturers.

The 4th chip can be ommited if PRG-ROM is 128kb or lower, and CHR-ROM/RAM 64kb or lower. If this chip is removed, the WRAM disable bit is not implemented (i.e. behave like a MMC1A and not like a MMC1B/C), and the corresponding input on chip 1 should be tied to VCC.

The inner working is pretty much the same as the implementation using 2x v750C or 1x v2500 chips, exept how the clocking works. The first chip is clocked by M2 but because M2 has wrong polarity it inverts the signal itself. I hope this trick works. The only purpose of being clocked by M2 is for the double-write prevention, but the registers simulate being clocked by /ROMSEL as they only change state when /ROMSEL is low, but they are actually clocked by M2. For the other 3 chips, everything is clocked by /ROMSEL, simplifying logic and requiring less inputs.

Note that almost all I/Os is used therefore the implementation pretty much fully uses the logic present in all 4 chips (only a single output is unused on chip 4). I hope it'll be useful, though.

As usual this is largely untested, prone to errors and omissions on my part. Each chip's pinout was randomly decided and could be changed at will, e.g. if this makes routing easier.

How are you going to burn those PALs? PAL programmers cost fortune, there are no homebrew cheap ones, and PAL program waveforms aren't officially available. Or is it just for educational purposes which ends on simulation phase?

If I'm not mistaken GAL is just the name Lattice gave to their reprogrammable PALs, while other companies continued to call them "PAL" but with different suffixes (to make them differ from one-time programmable PALs, which today are probably obsolete). There's vritually no difference.

Who is online

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