MD-NICCC - a 3D Mega Drive experience by TiTAN

[Chilly Willy]

Yeah, what I said was a bit ambiguous, so I don't blame you for the confusion. That web page on 65xx timing was awesome! Bookmarked.

As demonstrated on that page, read/write cycles take one cycle, but the 6502 isn't a single cycle processor, which is why I said that despite taking one cycle to read data from a rom, it can't read data EVERY cycle, making that speed moot. Then there's also the issue that the MD can use DMA to read data from the rom, and it doesn't actually access the rom the same way (or at the same speed) as the 68000. So there's more to it than just processor access times.

[Sik]

It's even messier with the 65816:
http://forum.6502.org/viewtopic.php?f=4&t=2438

On top of that… let's not forget about the operands. The fastest instructions on 68000 that access memory are 8 cycles (4 to read opcode, 4 to read/write a word). Not sure what it is on 65816, but from what I recall pretty much all its memory instructions take extra operands (save the stack ones, I think?), so they need to be read on top of the value being accessed… and then there's the part where all these comparisons go to hell even when accounting for clock speed, because the instruction set itself gets in the way (65816 is a lot more verbose generally requiring more instructions to achieve the same thing than 68000).

And yeah, when it comes to DMA none of that matters as that does its own thing (kind of the whole point of DMA). SNES DMA speed is roughly comparable to Mega Drive DMA in H32 mode. The main catch is that access to video memory outside blank is asking for trouble on the SNES, while it just slows down on Mega Drive (so the latter gets room to stream in some more tiles if doing a huge DMA, think about 100 more or so before the next vblank kicks in). Of course you still want to avoid the slow down because that eats lots of CPU time, but if you'll just spend that time waiting you may as well take it.

[Miquel]

TmEE co.(TM) and Stef, If that’s to be believed:
http://laughtonelectronics.com/Arcana/V ... iming.html
data bus is in use by two cycles.

By reading earlier you are only imposing more speed on RAM.

In other words, can you read a byte per cycle? Is NOP a single cycle instruction?

[Miquel]

Oh! There is no instruction prefech on the 65c816, now this makes sense. So this is really a read cycle of one cycle.

[Miquel]

No, the 7.67 Mhz 68000 is actually *slower* than the 2.68 Mhz 65C816 at accessing memory...

However, the 65xx cannot transfer memory on every clock, so that's moot.

Stef is correct, 65816 transfers 1 byte per 1 cycle, non-stop if needed, no problem.

You have to remember that the 68000 takes multiple clock cycles to access memory (generally 4 clocks), while 65xx variants take 1 cycle.

Actually is 3 cpu cycles per read/write cycle, and then at least an extra is needed cycle to store data somewhere in case of read, or anyway a micro-instruction is always 2 cycles, so at the end is always 4 cycles. Add 2n more cycles if the cpu operation is delayed. But the proper read/write cycle is 3 cpu cycles, could it be significative for DMA speed?

it's why the 65C816 can work at 2 speeds, fast memory (ROM) were too expensive in 1990 so they voluntary limited it to 2.68 Mhz to reduce cost on RAM (which is fixed to work at 2.68 Mhz) and to maintain acceptable cost on ROM too (while leaving possibility to increase ROM speed later when chips would become cheapers).

I'm not sure about that, the thing is that the increment of speed is only working on the second half of the memory mapping. That sounds to me like they use to many levels of glue logic at the addressing decoding to be compatible with nes (at first), which is situated on the first half, and that effected memory speed. Snes is a very neat design overall except the mapping, witch is simply nasty.

[Sik]

Actually is 3 cpu cycles per read/write cycle, and then at least an extra is needed cycle to store data somewhere in case of read, or anyway a micro-instruction is always 2 cycles, so at the end is always 4 cycles. Add 2n more cycles if the cpu operation is delayed. But the proper read/write cycle is 3 cpu cycles, could it be significative for DMA speed?

1) VDP has a complete disregard for paying attention to signals for memory accesses
2) That has actually caused trouble back then

I'm not sure about that, the thing is that the increment of speed is only working on the second half of the memory mapping. That sounds to me like they use to many levels of glue logic at the addressing decoding to be compatible with nes (at first), which is situated on the first half, and that effected memory speed. Snes is a very neat design overall except the mapping, witch is simply nasty.

The NES clock speed is used for the I/O ports (controller comes to mind) but not for the slow ROM area. There's definitely some weird mess which looks like the outcome of an early attempt at compatibility, but I don't think the way slow vs fast ROM works is one of those. Splitting clock speed by address range was probably just an easy way to determine what speed to use.

[Miquel]

1) VDP has a complete disregard for paying attention to signals for memory accesses

Are you saying DTACK signal (and his companion, I don't remember the name) is ignored ?

That's hard to believe.

[Sik]

It is :​D (which also means DMA will not hang on areas where the 68000 usually would) It seems they just assumed DMA would only be used with memory that would always respond in time.

[Miquel]

That’s like ignoring the father of all signals, what you say is truly reality breaking.

I just booked it in my “to do” list to study and resolve once for all this affair.

[TmEE co.(TM)]

VDP is what generates the !DTACK *for* 68K. During DMA the 68K is in bus requested state so that signal has no meaning of any sort.

[Chilly Willy]

VDP is what generates the !DTACK *for* 68K. During DMA the 68K is in bus requested state so that signal has no meaning of any sort.

Indeed. Think of it like the 68000's wait control rather than a vital bus control signal independent of the 68000.

[Miquel]

I haven't check how the VPD works but judging by how the 68k does: VDP has to signal !BR (bus request) and wait for !BG (bus grand); the same when Z80 access main memory.

Also !DTACK could be used to put the cpu in a wait state, the problem is the address bus is being used by the cpu while !DTACK is low.

[TmEE co.(TM)]

It can only be used in ranges where VDP doesn't generate it for you such as 800000...9FFFFF. This area is used by 32X and SVP for example. You cannot forcibly override !DTACK since VDP actively drives it on most accesses.

[HardWareMan]

It can only be used in ranges where VDP doesn't generate it for you such as 800000...9FFFFF. This area is used by 32X and SVP for example. You cannot forcibly override !DTACK since VDP actively drives it on most accesses.

There is also A14000...BFFFFF without !DTACK.

[Sik]

$A14xxx has the TMSS-related ports (on systems with TMSS, that is).