12th Vintage Computer Festival Europa (VCFe) in Munich 2011-04-30 to 2011-05-01

[OCT]

This year's event http://vcfe.org/E/index.html is to feature the (i.e. yet another ) ultimate showdown between the 6502 and the Z80 http://vcfe.org/E/Benchmark.html - while the 2010 meeting http://cpcwiki.eu/forum/index.php/topic,705.msg8082.html was much less relevant to the CPC and discussed on shorter notice as well, it still had quite a number of patrons from both this and the http://cpc-forum.de/viewtopic.php?f=7&t=903 in attendance.

BTW http://www.heise.de/newsticker/meldung/Der-ultimative-Benchmark-Z80-oder-6502-1232202.html reports that for a potential successor to the VCFe's retiring organizer, this is the time to volunteer (for the chance of starting on a lucky number )...

[TFM]

I know the organizer well in person. His favorite is the 6502, so I seriously doubt if this showdown with the Z80 will be fair.

However, just look at Starglider at CPC and at C64. Then you see the power of the cpu's.

[Gryzor]

I don't get it - won't the benchmark rely on the quality of the programming?

[arnoldemu]

I know the organizer well in person. His favorite is the 6502, so I seriously doubt if this showdown with the Z80 will be fair.

However, just look at Starglider at CPC and at C64. Then you see the power of the cpu's.

Hmmm.. isn't the problem here the organisation of screen memory and not the cpu?

[MaV]

Hmmm.. isn't the problem here the organisation of screen memory and not the cpu?

I'm not sure.

Clearing the screen is a lot faster on the CPC than on the C64, especially since the routine uses PUSHes (2 bytes) to clear it and unrolls the pushes for one line (had a look at the code). The C64 has to do it byte by byte, unless there's some trick involved. I haven't checked the 6502 code.

In an interview by Realtime software back in the days, they stated that a C64 version would be too slow. Given that, the c64 version looks quite impressive despite its lower resolution.

Still, the CPC version shines.

MaV

[MaV]

I don't get it - won't the benchmark rely on the quality of the programming?

Yep, so there's guaranteed subjectivity involved. Don't expect an objective result at all.
Especially since it's not assembly but a "high-level" language, they are testing the systems on, which in itself is implementation dependent.

Think of it as a tongue-in-cheek benchmark.

MaV

[Executioner]

The CPC should beat the C64 in just about any benchmark that doesn't use hardware sprites or scrolling on the C64 since a 4MHz Z80 is faster than a 1MHz 6510 at almost all equivalent instructions. The same could not be said for the BBC-B which runs over twice as fast as the C64.

[andycadley]

Hmmm.. isn't the problem here the organisation of screen memory and not the cpu?

Almost certainly, as is often the case when trying to compare CPUs with tests like this. Also there's the fact that the CPC had a 'top of the range' 4MHz Z80 wheras the 1MHz 6502 in the C64 was quite slow by contemporary standards, the Beebs was running at 2Mhz.

Clearing the screen is a lot faster on the CPC than on the C64

I seriously doubt that, the C64's screen normally occupies about 1K of ram. Even a slower CPU can clear that in way less time than the CPC's 16K display, no matter what tricks you use.

[arnoldemu]

Almost certainly, as is often the case when trying to compare CPUs with tests like this. Also there's the fact that the CPC had a 'top of the range' 4MHz Z80 wheras the 1MHz 6502 in the C64 was quite slow by contemporary standards, the Beebs was running at 2Mhz.
 

I seriously doubt that, the C64's screen normally occupies about 1K of ram. Even a slower CPU can clear that in way less time than the CPC's 16K display, no matter what tricks you use.

This is where we need our c64 machine comparison information wiki page, so things like this can be understood by all.

It depends on the mode of course, if it's char mapped or bitmapped. But even the c64's bitmapped mode takes less ram than a cpc's.

[MaV]

Almost certainly, as is often the case when trying to compare CPUs with tests like this. Also there's the fact that the CPC had a 'top of the range' 4MHz Z80 wheras the 1MHz 6502 in the C64 was quite slow by contemporary standards, the Beebs was running at 2Mhz.
 

I seriously doubt that, the C64's screen normally occupies about 1K of ram. Even a slower CPU can clear that in way less time than the CPC's 16K display, no matter what tricks you use.

We're mixing two topics in this thread now. One is Starglider, CPC, C64; the other topic is about the Festival + 6502 + Z80.

I was talking about Starglider and the comments of Realtime Software regarding the CPC and C64, since the previous poster (TFM/FS) mentioned Starglider.

First of all:
My statement in particular was based on the premise that the C64's screen is bitmapped, and I doubt it uses 1k only in Starglider. But I cannot say for sure now, we'd have to check the code in an emulator (preferably by one more proficient in 6502). We're still talking about vector graphics not a character based screen.
Starglider on the Amstrad uses a reduced screen, to shrink the vector graphics screen to 256 pixels in x. Screen height is also reduced, I don't know by how many lines, but the lower half shows the starglider's cockpit. This part stays untouched when clearing the vector graphics part of the screen. And that's way lower than 16k!

Secondly:
An equally clocked 6502 beats a Z80 for sure, and as Executioner has stated even a 2MHz BBC-B (Beebs?) can easily compete with the Z80 in an Amstrad or Speccy, no doubt.
The clock cycles of a 6502 instruction ranges from 2 to 7 (or 6 I can't have a look now), while the Z80's starts at 4 cycles and goes beyond 20 for the very complex ones. There's a reason why Z80 computers are almost always higher clocked machines.

Still, a comparison of those two processors is difficult. Complex instructions on Z80's side vs. simpler faster one's in a 6502. The 6502 misses 16 bit registers, memory needs to be indexed via zero page when the Z80 can use HL, BC, or DE, even IX and IY. The stack in a 6502 is 256 bytes, which can pose a problem.
The Z80 is harder to handle, eats clock cycles by the bunch, registers have specific functions, which may punch you in the face when you try to optimize.

For a more objective comparison of both processors, we may need emulators that   count the average number of clock cycles that each machine uses. Even then it depends on the software (games most probably) that is being used to base the comparison on.

The Festival's benchmark in Forth can only be called tongue-in-cheek. There's too many factors  obscuring a processor based comparison (shortcoming of the machines that inhibit the processor, implementation of forth, etc.).
MaV

BTW, I remember having read somewhere that the C64 almost would have had a Starglider 2 version. Too bad it wasn't finished.

[TFM]

I don't get it - won't the benchmark rely on the quality of the programming?

Well, a good benchmark does more rely on the hardware. Similar algorithms should be used, but can't always be used due to cpu differences. So it's hard to be fair.

[TFM]

Hmmm.. isn't the problem here the organisation of screen memory and not the cpu?

No, calculating the vectors in a 3D room take a lot of cpu power. Drawing that on the screen them doesn't need much. Especially since it's just lines and not filled surfaces.

[TFM]

The CPC should beat the C64 in just about any benchmark that doesn't use hardware sprites or scrolling on the C64 since a 4MHz Z80 is faster than a 1MHz 6510 at almost all equivalent instructions. The same could not be said for the BBC-B which runs over twice as fast as the C64.

In principle I agree, but scrolling is not a problem for the CPC. If you just use 16 KB screen memory without overscan, the CPC will beat the c64 in scrolling too. But I exclude pixel-wise horizontal scrolling here, as long as not sophisticated routines are used.

[andycadley]

Again, not sure I'm convinced on that one. Sure the CPC can hardware scroll in that case, but it's still a fair bit of effort to redraw the scrolled section. Having a bitmapped display is extremely punishing in comparison to the C64's tile based display. It's largely down to the variations in hardware more than anything else.

I think the best comparison of Z80 vs 6502 I ever saw was in the somewhat legendary "The C64 was crap!" thread in c.s.s/c.s.c many years back. I think the consensus was that a Z80 would be about 3 times slower at the same clock speed, in the general case. Of course it's very hard to be unbiased, as certain algorithms lend themselves better to one CPU architecture over the other. As well as the hardware differences, there is also the issue of coder's skill and experience, for example Speccy/CPC coders are often better at writing optimal bitmap manipulation routines simply because C64 coders rarely deal with the display in bitmapped mode.

[MacDeath]

It is often implied that Z80/CPC performs betterly in 3D than C64/65xx...

The 4mhz vs 1 mhz ...I don't know.
Many pro-C64 argue that most instruction take far less NOP/cycles on 65xx so it is roughly equivalent...(may depend a lot with said instructions)

But also... When Sounds and Sprites and scrolls are not really used as comparison... C64 is not that relevant.

Have you seen the Batman spinning LOGO ?

3D means that Character Attribute based Video is not good at all...
Because of the lines that cross each other.

Character attribute on the other hand can be quite interesting in bitmap graphics (2D) appart isometric (false) 3D...

square attributes are not good with Diagonal.

C64, when dealing with 3D, must rely on low resolution to get "more" colours... or only 2 colours per character in "High Res" (320x200...)

Hardwired 2D sprites are too little help here.

CPC, while having only 4 colours per screen (Mode1) have no problem with any visual artefacts from attributes.


Anyway I hope we'll see a lot of pictures of the event...