Quote:

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.

Quote:

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

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

Quote:

@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

Quote:

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.

Quote:

[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

video game system development kit

http://www.xgamestation.com/media.php

Quote:

video game system development kit http://www.xgamestation.com/media.php

And this relates to MSX or the OCM... how?

As far as I can tell from that website it's just a home-computer-like development board with an ARM7 processor - incompatible to any 8-bit system known to man...

(Note to site admin: auto-url + quote closing tag = trouble)

The OCM asserts the Z80 wait pin when it's busy accessing memory - I have no idea if that's what the real MSX does or not, but if not it certainly won't be cycle accurate.

I've been playing with the NES design lately (I've managed to get Tennis running) and have discovered that the CPU clock is actually derived from the 21MHz PPU clock - so the CHR & PRG bus accesses should be synchronous - or there-abouts. I suspect the reason it didn't look like that on the CRO was that the PRG access timing differed depending on the actual instruction being executed... I'll have to go back and look at it again...

Anyway the upshot is that it should be possible to schedule PRG (CPU) and CHR (PPU) accesses on a regular basis from an FPGA design. Not sure if the memory bandwidth is there on the OCM SDRAM (when you add refresh cycles) - haven't done the calculations. Was also interested to learn that the CPU is halted when doing sprite DMA!

For those interested, my NES implementation is complete only to the point where it can run Tennis, and perhaps a few other simple carts, with no scrolling and no mappers. It uses >28KB of internal FPGA memory (EP2C35) so IIRC it can't be ported to the OCM (EP1C12) as-is - not that I have one anyway. It _might_ just fit with external CPU RAM (2KB)???

Regards,
Mark

Quote:

Was also interested to learn that the CPU is halted when doing sprite DMA!

Yes it is actually the CPU that is transferring the data, the video chip just accepts it as usual. So it is not really "DMA" but just a block memory move feature that Nintendo put in their CPU.

Interesting. I assumed it was an external function, likely the PPU itself. But looking at the register address, the sprite DMA function is in the same block as the APU functions, so I guess that's right. Not that it matters, but I implemented the sprite DMA in an external process, which de-asserts the 6502 RDY pin whilst in progress. And it too mimics CPU writes to normal sprite registers. Most importantly I suppose is the fact that the DMA on a real NES takes 513 cpu cycles, as does mine.

Of course, whilst Tennis looks like it's running on a NES, internally it resembles nothing of the sort. In fact, I based the design off my Centipede implementation of all things! Actually turned out to be a good choice - I chose it originally because it had a 6502 but - unlike most other video games - Centipede sprites are only 8 pixels high, just like NES Tennis.