The maximum number of mappers that can be accommodated by epm240
Moderator: Moderators
The maximum number of mappers that can be accommodated by epm240
I tried to optimize the logic combination as much as possible, use fewer registers, write the latch module as a combinational expression as much as possible, reuse common wire nodes as much as possible, after that, epm240 supports mapper0,1,2,3,4,7 at most (mapper1 has limitations and does not support 32K WRAM and 32K PRG mode)
I wonder if I can support more on epm240, but Krzysio claims that he supports the following:
#0 NROM
#1 MMC1
#2 UNROM
#3 CNROM
#4 MMC3
#7 ANROM
#15 Contra Function (Contra 168-in-1 / Contra 100-in-1 multicart)
#30 UNROM-512 (nesmaker games)
#71 Camerica Codemasters' games
#232 Camerica Quattro
That is amazing.
I wonder if I can support more on epm240, but Krzysio claims that he supports the following:
#0 NROM
#1 MMC1
#2 UNROM
#3 CNROM
#4 MMC3
#7 ANROM
#15 Contra Function (Contra 168-in-1 / Contra 100-in-1 multicart)
#30 UNROM-512 (nesmaker games)
#71 Camerica Codemasters' games
#232 Camerica Quattro
That is amazing.
Re: The maximum number of mappers that can be accommodated by epm240
Mapper #30 and Mapper #71 are currently partially supported as the superset and subset of Mapper 2. However, Mapper #232 is not going to be supported. It is impossible for mapper #15 to be fully supported. Currently, I am not prepared to implement it, and there are no more LEs available.
My implementation will take up more LEs, the global clock is not m2, and the delay of sram_ce is also generated by epm240 instead of an external Diode+RC circuit(although I also reserved component pads on the PCB).
My implementation will take up more LEs, the global clock is not m2, and the delay of sram_ce is also generated by epm240 instead of an external Diode+RC circuit(although I also reserved component pads on the PCB).
Re: The maximum number of mappers that can be accommodated by epm240
Anyway, I supported mapper #198 through conversion patches
Without any modification on ROM data, by dynamically patching in the menu loader
Without any modification on ROM data, by dynamically patching in the menu loader
Re: The maximum number of mappers that can be accommodated by epm240
Since then, I have supported the TF card, and the SPI interface is also generated by hardware. Because my global clock is fast enough, I can achieve 8bit transmission within a read/write Instruction cycle without inserting the nop to wait. This simplifies the asm programming and treats the command operation of SD as a memory port accessing. I have ported the file system and added the fast seek function for DIR so that I can accelerate the display of menus. Now, I can support 16 layers of path folders (depending on the length of the folder name), with a limitation of 100 files or subfolders per folder.
I have written a mapper for loader, which roughly refers to the implementation of EDN8. The overall UI is similar to EDN8 Pro. But I greatly simplified the implementation form, and all of these, including support for mappers 0,1,2,3,4,7, are completed on epm240.
Reading ROM from the TF card and saving it in RAM, and executing it from RAM, which ensures the robustness of the hardware. The writing process will not damage the firmware even if the power is turned off or an abnormal power outage occurs.
At present, my SD loading speed is about 32K per second, and a 128KB ROM usually completes loading in 4 to 4.5 seconds. Mapper2 has the fastest loading speed, and there will be a screen display of progress during the loading period, which will result in a loss of one frame of time every 8KB. However, under the limitation of loading 32K per second, a loss of 4/60 performance is acceptable.
Finally, I updated my PCB, truly enter into the TF flashcart era.
ps:The wiring under the CPLD has been completely erased:)
I have written a mapper for loader, which roughly refers to the implementation of EDN8. The overall UI is similar to EDN8 Pro. But I greatly simplified the implementation form, and all of these, including support for mappers 0,1,2,3,4,7, are completed on epm240.
Reading ROM from the TF card and saving it in RAM, and executing it from RAM, which ensures the robustness of the hardware. The writing process will not damage the firmware even if the power is turned off or an abnormal power outage occurs.
At present, my SD loading speed is about 32K per second, and a 128KB ROM usually completes loading in 4 to 4.5 seconds. Mapper2 has the fastest loading speed, and there will be a screen display of progress during the loading period, which will result in a loss of one frame of time every 8KB. However, under the limitation of loading 32K per second, a loss of 4/60 performance is acceptable.
Finally, I updated my PCB, truly enter into the TF flashcart era.
ps:The wiring under the CPLD has been completely erased:)
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: The maximum number of mappers that can be accommodated by epm240
I see some signals connect directly to the CPLD, which is not a 5V tolerant device (exception being EPM1270 and 2210 with external current limit resistor and internal IO clamp diode specifically enabled as per documentation). What is done about this problem ? Or it is assumed it is to be used only with low voltage famiclones etc. ?
Re: The maximum number of mappers that can be accommodated by epm240
By the way, I have reserved some components to support mapper 413 and also used an MP3 decoder chip. This chip can also manage TF card. When using the storge card as read-only for playing MP3 or wave, I can release cpld to save more LEs. Using this chip to implement the SPI interface does not require running a file system. In theory, this chip should be able to read in nes files, transfer them to CPLD, and then write them to RAM. This part has not been implemented yet, and this chip is actually an MCU with very simple peripheral pins. However, I am not relying on it to access the TF card, this is another reserved solution
Re: The maximum number of mappers that can be accommodated by epm240
Yes, I won't reply to such level matching questions, but I will use them. If an explanation is necessary, the reason is costTmEE wrote: ↑Tue Jun 13, 2023 5:17 am I see some signals connect directly to the CPLD, which is not a 5V tolerant device (exception being EPM1270 and 2210 with external current limit resistor and internal IO clamp diode specifically enabled as per documentation). What is done about this problem ? Or it is assumed it is to be used only with low voltage famiclones etc. ?
Re: The maximum number of mappers that can be accommodated by epm240
The theoretical maximum storage space is 1024K PRG+512K CHR (except the FLASH ROM of BIOS), but there is a portion of PRG RAM used as the system NVRAM (save RAM, latest file path, and other settings), the actual supported ROM structure is up to 768K PRG + 512K CHR
When switching CPLD to EPM570 (I have already made it compatible with different 4 power pins), it will support over 15 or more mostly used mappers. Mapper 198 must be supported
As for the Flash ROM, it can support custom COB module up to 2G bits in size, so it can be either FLASH CART or MULTICART
When switching CPLD to EPM570 (I have already made it compatible with different 4 power pins), it will support over 15 or more mostly used mappers. Mapper 198 must be supported
As for the Flash ROM, it can support custom COB module up to 2G bits in size, so it can be either FLASH CART or MULTICART
Re: The maximum number of mappers that can be accommodated by epm240
A few days ago, I updated the design and added the implementation of Sunsoft-5B and VRC6 expansion audio. All I need to do is adding an 8-bit DAC. The verilog implementation does not take up much LEs, with three 16-bit counters and a 6-bit adder. The EPM570 can also include both expansion audio while implementing the aforementioned mappers.
However, FDS and N163 require dual port RAM support, which consumes approximately 1K LEs, while basically requiring an FPGA with over 1.5K LEs at least
However, FDS and N163 require dual port RAM support, which consumes approximately 1K LEs, while basically requiring an FPGA with over 1.5K LEs at least
Re: The maximum number of mappers that can be accommodated by epm240
FDS shouldn't require dual-ported RAM - the wavetable RAM can't be accessed by the CPU and the audio at the same time.
Re: The maximum number of mappers that can be accommodated by epm240
It is true that reading and writing wavetable are not the same in time, but also not the same(bus) in space. Emulating pseudo DPRAM using SRAM externally is also more complex, so it is better to directly call DPRAM IP using FPGA
Re: The maximum number of mappers that can be accommodated by epm240
Wiki says:"When writing is disabled ($4089.7), reading anywhere in 4040-407F returns the value at the current wave position."
I set the read breakpoint between $4040- $407F, but the program did not stop, indicating that the reading is not accessed through the CPU addresses. It should have an internal clock, and not yet known whether this clock is(m2???). At each cycle, the waveform value of the current pointer (address) is read.
It seems that something is not clear here. I would rather hope it is correct so that I can share the read and write data lines, and an external SRAM would finish this job
I set the read breakpoint between $4040- $407F, but the program did not stop, indicating that the reading is not accessed through the CPU addresses. It should have an internal clock, and not yet known whether this clock is(m2???). At each cycle, the waveform value of the current pointer (address) is read.
It seems that something is not clear here. I would rather hope it is correct so that I can share the read and write data lines, and an external SRAM would finish this job
Re: The maximum number of mappers that can be accommodated by epm240
It's either clocked by M2, or it's clocked by the FDS's own 21.5MHz crystal divided by 12, which is the same rate but not synchronized.
Re: The maximum number of mappers that can be accommodated by epm240
The difference between FPGA based on lookup table structure and traditional CPLD based on logic gate interconnection structure is that lookup table is actually an initialized SRAM, and the more unique the address constraint on SRAM, the less lookup table it occupies
Usually, the condition of "if (addr_in [15:0]==16'hFFFF)" occupies less LUTs than "if (addr_in [15:8]==8'hFF)", and in traditional logic interconnectional CPLDs, the former occupies more macro cells
So, for LUT based FPGAs, condition statements should be written as standardized as possible to occupy all input bits, and the bit width should be uniform (even if some bits are not connected to a mapper on hardware), so that the synthesizer can merge the same input
Usually, the condition of "if (addr_in [15:0]==16'hFFFF)" occupies less LUTs than "if (addr_in [15:8]==8'hFF)", and in traditional logic interconnectional CPLDs, the former occupies more macro cells
So, for LUT based FPGAs, condition statements should be written as standardized as possible to occupy all input bits, and the bit width should be uniform (even if some bits are not connected to a mapper on hardware), so that the synthesizer can merge the same input
Re: The maximum number of mappers that can be accommodated by epm240
I cannot help people benefit from what I'm saying, it does not depend on how much I said, but on how much others understood. I was blamed for talking nonsense just because what I said cannot be understood. Of course, when the reader can understand what I say over time or he is currently doing the same work, I believe he will understand, but I do not expect him to have a friendly attitude towards me because it is obvious: sometimes different people working in the same job may compete with each other in different teams.
As it seems that I have offended some people at the moment, I may have to change my posting style on the forum. I try to reply to other people's topic posts as little as possible to avoid my super short speaking style decreasing their evaluation on me. Instead, I think it is better to accumulate my own topic posts together. I think this is a better way to avoid being misunderstood
BTW, I like Rousseau's work "Confessions"
As it seems that I have offended some people at the moment, I may have to change my posting style on the forum. I try to reply to other people's topic posts as little as possible to avoid my super short speaking style decreasing their evaluation on me. Instead, I think it is better to accumulate my own topic posts together. I think this is a better way to avoid being misunderstood
BTW, I like Rousseau's work "Confessions"