Quote:

if a 3.5MHz R800 ~ 28 Mhz Z80 then 28Mhz R800 ~ 224 Mhz Z80.

R800 is 7MHz, so theoretically 4 times faster than a Z80 at the same clock. At double the clock it's 8 times, in theory. In practice, this is only 5 to 6 times.

So a 28MHz R800 = 28 * 5 to 6 = ~150 MHz Z80

Err... No it isn't... I put the R800 at roughly 8 times as fast a 3,5MHz Z80. I know this isn't really true, but since I'm a big R800 fan I tend to 'bend' the facts a little from time to time. But anyways...

If an R800 is 8 times as fast at twice the clock, it's four times as fast clock-for-clock. You were forgetting to divide the 5 to 6 (where I took 8) by two for twice the clock. So taking my example of 8 times at fast it would be 4 * 28 = 112MHz (hence the 110MHz) If we take your 6 times as fast (prolly closer to the truth) it would be 3 * 28 = 84MHz. I'm not willing to settle for 5 times as fast tho... No way!

By the way, I was checking out the R800 speed today, and the slowest instuction there is is the HALT instruction. This one is exactly 4 times as fast as on a 3,5MHz Z80. The fastest instruction I've catalogued sofar (I'm at the L of the instruction set ) was add hl,ss at exactly 22 times (!) as fast as the Z80. The average increase of speed was around 8 times as fast. That is ofcourse if every intruction is used once, which is not to close to reality. I think I'll maybe disassemble a piece of BIOS code to see how fast it would be on each processor. Should be interesting to see

Quote:

I think I'll maybe disassemble a piece of BIOS code to see how fast it would be on each processor. Should be interesting to see

indeed, especially when you spot pieces of code that could use some improvement to speed things up. since bios calls are used a lot they should be fully optimized.

Quote:

The average increase of speed was around 8 times as fast. That is ofcourse if every intruction is used once, which is not to close to reality.

What's also not close to reality is that you forget the following:
1. there's a wait state for reading from RAM. Every instruction that reads from RAM (this includes stack) will take a wait state, every instruction that reads OR writes from RAM will make the following instruction take a waitstate too.
2. whenever the program crosses a 256 byte (aka page) boundary, or takes a jump, there is a wait state.
3. there are regular refresh periods in which the R800 stalls for several microseconds(!). Even though the R800 runs at 7.16MHz, it already looses about half a MHz because of the refresh periods. In a 512K system this loss is greater than in a 256K or 1024K system.

So in an ideal world, yes, R800 would be 8 times faster. In the real world, however, R800 is only 5 to 6 times faster.

Quote:

Quote: The average increase of speed was around 8 times as fast. That is ofcourse if every intruction is used once, which is not to close to reality. What's also not close to reality is that you forget the following: 1. there's a wait state for reading from RAM. Every instruction that reads from RAM (this includes stack) will take a wait state, every instruction that reads OR writes from RAM will make the following instruction take a waitstate too. 2. whenever the program crosses a 256 byte (aka page) boundary, or takes a jump, there is a wait state. 3. there are regular refresh periods in which the R800 stalls for several microseconds(!). Even though the R800 runs at 7.16MHz, it already looses about half a MHz because of the refresh periods. In a 512K system this loss is greater than in a 256K or 1024K system. So in an ideal world, yes, R800 would be 8 times faster. In the real world, however, R800 is only 5 to 6 times faster.

In my ideal world the r800 would be at least 1000 times faster..

Quote:

In my ideal world the r800 would be at least 1000 times faster..

Why would you want that? You're not gonna use it anyway. Name an app which is sufficient to use it (Nah, don't say, 'to speed up my BASIC programs', because that could do nicely with less)...

Oh, and 3D engines are too much as well

Well, maybe there are on the moment not that many programs but it opens new doors to software development, but I agree...800 times faster would do just fine

What would be your desired speed then?

I think the current R800 speed is fine enough. Concerning GFX9K capabilities, I'd say double it. The Turbo R can push out all of the GFX9K then.

Quote:

I think the current R800 speed is fine enough. Concerning GFX9K capabilities, I'd say double it. The Turbo R can push out all of the GFX9K then.

Mwah, I'd rather have the wait states (including I/O waits) removed. With that, I think R800 is fast enough for the Gfx9000. Hell, I even doubt it 'can't handle' the Gfx9k right now. Ok, well, I guess with RAM to VRAM copies a faster CPU would be useful. But otherwise... The v9938, v9958 and v9990 are essentially co-processors. You can let them do work while the CPU is doing something else. Especially with the Gfx9000's command execution interrupt the Gfx9000 can be kept working in the background pretty much non-stop.

Though I realize copies aren't everything when it comes to dealing with a VDP ofcourse. You also need to update sprite locations, pattern indexes, screen splits, e.d. It actually pretty much depends on in which screen mode you are programming for. I doubt there'll be much copying in the pattern modes, and on the other hand in 'screen 5' for the Gfx9k it is 95% copying. But, ahwell .


~Grauw

Yeah, the waits suck... Since the Gfx9000 is on the cartridge bus, the S1990 inserts 3 R800 wait states when accessing it.
I think building it in somehow would solve it... I wonder what kind of results will be achieved then. I mean, it could well be that with the waits it's just fast enough to handle everything...

Well, I honestly think that 9958 with addram hack beats the crap out of GFX 9000

not really you wouldn't be able to do stuff like shown in Team Bomba Under Water demo, CPU isn't fast enough to do all these copies.

Quote:

not really you wouldn't be able to do stuff like shown in Team Bomba Under Water demo, CPU isn't fast enough to do all these copies.

Well, same is true between GFX9000 and any 2$ SVGA on PC. Speed is nothing, software is everything!

Long life 99x8!!!

Does fMSX for PSP access the kernel memory?