NES and Famicom support for the One-Chip-MSX!

Page 8/9
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9

By SLotman

Paragon (1237)

SLotman's picture

11-10-2007, 23:42

Hah, we from Brazil dont need such thing... we still have SMS, Genesis and NES available in stores!!! Brand new ones!

... I know, it's crazy, stores sell side-by-side brand new Wiis, PS2, X360, NES and SMS - but it's true Smile
(some things only happen in Brazil hehehe)

By dvik

Prophet (2200)

dvik's picture

11-10-2007, 23:49

@SLotman, what is the price of a brand new NES in stores (compared with for example a Wii)?

By tcdev

Expert (76)

tcdev's picture

12-10-2007, 01:55

Kevin has reverse engineered each cartridge type (see his table "MaprMatrix" of the 100+ cart types), and instead of recreating them all in VHDL, he has instead recreated them using the lower-level and more accurate circuit diagrams into which VHDL compiles.

What? That's simply not true, and doesn't even make sense.

Like I posted elsewhere in this thread, unless you know the gate-level circuit implemented _inside_ the custom chips in the NES (and carts) then _any_ emulation, whether FPGA in VHDL or software in Java, is still an approximation based on guess-work. In some respects, it's actually *easier* to get a more accurate software emulation than it is in an FPGA.

I'm not doubting Kevin's work _is_ more accurate, it's simply that he has put more effort into making it so.

Regards,
Mark

By Vampier

Prophet (2385)

Vampier's picture

12-10-2007, 02:03

There is clearly a market for hardware and emulation.... the Wii/PS3 and Xbox360 have picked up on that. But to be honest... it's too restrictive when you're used to emulators on the PC (or modded consoles)

By DamageX

Master (217)

DamageX's picture

12-10-2007, 08:03

I don't think it will be possible to emulate the NES on the OCM. Even if they have the same FPGA, it's the size, speed and configuration of the attached memory that is more important. Unlike any other cartridge-based console, the NES is unique in that it has two (2) distinct, asynchronous buses on the cartridge connector. One is clocked by the video (PPU) at around 21MHz (IIRC) and the other is synchronous to the CPU bus. Unless you have 2 separate memory buses attached to the FPGA, this makes it *very difficult* if not impossible, to emulate.
I disagree. The fact that there are two buses at the cartridge connector only matters when trying to interface to real NES cartridges. If the MSX (which has separate RAM and VRAM buses) can be implemented in the FPGA then the NES should be just as doable.

There may be a 21.5MHz clock going into the NES PPU (just like there is the V9958 IIRC...) but that is not the speed that the bus runs at. Think about it for a second... how fast were ROMs in the early '80s anyway? I'll give you a hint, even the SNES CPU supported switching from 3.58MHz down to 2.68MHz to accomodate cartridges with cheap, slow ROM. Based on what I know about the NES PPU I would say that it probably gets its job done with a 2.68MHz bus speed just like the TMS9918A does.

By tcdev

Expert (76)

tcdev's picture

12-10-2007, 15:38


I disagree. The fact that there are two buses at the cartridge connector only matters when trying to interface to real NES cartridges. If the MSX (which has separate RAM and VRAM buses) can be implemented in the FPGA then the NES should be just as doable.

Wrong. It has nothing to do with real NES cartridges, and everything to do with the fact that the emulation still has two processors vying for memory on separate buses. If your FPGA platform only has 1 memory bus, then the FPGA still has to share it between 2 asynchronous bus masters - the CPU and PPU.

The CHR bus is accessed in back-to-back pairs of reads every 150us. The 2 accesses are 376ns apart, and the RD pulse is 180ns wide, so 150ns ROMs would be sufficient there. The PRG bus is accessed every 600ns, with a 376ns pulse width. Again, not overly fast.

The problem comes about because these two buses are completely asynchronous. One scenario is that the accesses on the 2 buses occur at the same time. You still need the 1st CHR access within 180ns to render the pixel at the right time, but less than 376ns to read both CHR & PRG buses. Worse yet, you get a PRG access just before a CHR access, which gives you little more than 180ns to do *2* accesses. It gets tighter than that, because of metastability inside the FPGA you also need to unmeta the RD signals through a few flip-flops clocked at your FPGA system clock speed. And you need some sort of logic to ensure PPU accesses are timely enough to render the pixel but not exclude PRG accesses because if they're late the program will crash!

Yes, I have done my homework - we found these problems on our PUCE project. I had Tennis running on a PUCE board using a simple algorithm that caused PRG bus accesses to pre-empt CHR accesses. As a result Tennis did actually run properly - it was just a very snowy picture!

SDRAM becomes particularly nasty because not only do you have latencies setting up the actual access, but you also need to fit refresh cycles in there as well.

The way around all of this of course is to sychronise your CPU and PPU clocks internally and approximate relative speeds overall by skipping cycles. However then you run into timing problems with nasty software that uses tight timing loops and ballast code to change PPU registers mid-line - exactly what Kevin was having problems with.

This is one example why accurate software emulation is in fact easier.

Regards,
Mark

By tcdev

Expert (76)

tcdev's picture

12-10-2007, 15:43

Actually, thinking about it, it may not be such a problem with a NES implemented within an FPGA. Certainly these are real problems when trying to emulate a cartridge running on a real NES...

If you are emulating the NES itself, it should be possible to have the system logic insert wait-states on the PRG bus and hold up the CPU when the PPU needs to access memory. The PPU could pre-empt the CPU bus accesses, because they need to be timely, and the logic could ensure that any pre-emption held off the CPU until the PRG access could complete... hmm... interesting...

Regards,
Mark

By SLotman

Paragon (1237)

SLotman's picture

13-10-2007, 02:36

@SLotman, what is the price of a brand new NES in stores (compared with for example a Wii)?

Much cheaper... a Wii over here is around $500-$600 (in some cases over $1000), where the "several" NES clones costs around $50-$100

By DamageX

Master (217)

DamageX's picture

13-10-2007, 06:19

The PPU could pre-empt the CPU bus accesses, because they need to be timely
It seems to me that you could just buffer and delay the video output by one or two pixels. Then it doesn't matter if PPU timing matches the real thing exactly, and you can interleave memory accesses in a fixed pattern (2 for the CPU and 3 for the PPU, during every ~1.1us). Just a guess.

My point before was that I don't think you have mentioned any issue that doesn't also apply to the existing MSX implementation. In fact, I would say the MSX is more complex still because the VDP has multiple screen modes and uses a few different memory access schemes. Although the OCM is probably not cycle exact at this point. In practice, I'm not sure how much that matters.

By AuroraMSX

Paragon (1901)

AuroraMSX's picture

13-10-2007, 16:49


Quote:
Although the OCM is probably not cycle exact at this point. In practice, I'm not sure how much that matters.Well, then there is a fat chance that software emulators like openMSX and blueMSX are currently more accurate than the OCM Tongue

Running Naked in a Field of FlowersRunning Naked in a Field of Flowers

Page 8/9
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9