It is currently Wed Aug 23, 2017 5:01 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Mar 24, 2017 8:44 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1860
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Sun Mar 26, 2017 11:23 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
tepples wrote:
I checked your count of 12 outputs against the pinout. Several MMC1 configurations would fit in 10 outputs:
  • SGROM: 6 (PRG A17-14 and /CE, VRAM A10)
  • SLROM: 11 (SGROM + CHR A16-12); would fit with 128K PRG ROM
  • SKROM: 12 (SLROM + WRAM +CE)
  • SNROM/SUROM: 8 (SGROM + WRAM +CE, WRAM /CE or PRG A18)
  • SOROM/SXROM: 10 (SUROM + WRAM A13-12)

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.

Top
 Profile  
 
PostPosted: Sun Mar 26, 2017 11:30 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
Bregalad wrote:
Only games using all address lines (256k/128k) (currently there is non known game using that)
NesCartDB search for mapper 1 games with 384 KiB of total ROM


Top
 Profile  
 
PostPosted: Mon Mar 27, 2017 3:22 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
Oops, I was mis-remembering. Actually, what is never used is 384 kB of toal ROM and SRAM simultaneously (aka use 100% of the MMC1 chip). So no games currently uses more than 11 output pins.


Top
 Profile  
 
PostPosted: Fri Mar 31, 2017 3:45 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
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.


Attachments:
mmc1_dual_v750c_or_single_v2500.zip [17.25 KiB]
Downloaded 30 times
Top
 Profile  
 
PostPosted: Fri Mar 31, 2017 4:54 am 
Offline
User avatar

Joined: Wed Apr 07, 2010 1:14 am
Posts: 466
Location: Iran
How about using ATF1504AS which seems to be active CPLD :
44 PIN : TQFP (10x10) / PLCC (16x16)
64 Macrocells
32 IO


Top
 Profile  
 
PostPosted: Fri Mar 31, 2017 10:23 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
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 !!


Top
 Profile  
 
PostPosted: Mon Apr 10, 2017 12:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
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 function is shared by 4 chips with the following roles:
  • 1st chip : Handles mirroring control, part of shift register, enable signals
  • 2nd chip : Handles part of shift register and lowest CHR and PRG banking bits
  • 3rd chip : Handles middle 2 CHR and PRG banking bits
  • 4th chip (optional) : Handles upper 2 CHR and upper PRG banking bits as well as WRAM disable bit
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.


Attachments:
MMC1_4x22v10.zip [12.98 KiB]
Downloaded 27 times
Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 5:34 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 175
Location: Poland
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?


Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 5:44 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
It's basically the same as burning an EPROM. If you can burn an EPROM, you can probably burn a PAL. Programmers costs something, sure, but I don't think it can be called "a fortune".


Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 6:12 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 175
Location: Poland
Even the most popular TL866 programmer support only GALs.


Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 6:14 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7157
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 10:04 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
All the PALs use (subtly) different programming interfaces; this was largely before JTAG or JEDEC standardization of same.

You basically have to dig up the specific programming documentation for the specific PAL you're using.


Top
 Profile  
 
PostPosted: Wed Apr 19, 2017 10:06 am 
Offline
User avatar

Joined: Wed Apr 07, 2010 1:14 am
Posts: 466
Location: Iran
It seems GALBlast is free to use.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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