6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue May 21, 2024 7:51 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Thu Sep 07, 2023 6:30 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 691
Location: Potsdam, DE
A comparison of 6502 vs 6809 vs Z80 based on Grant's designs (with minor modifications). All running MS basic, with the 6502 and 6809 running at 1.8MHz and the Z80 at 7.2MHz

https://www.youtube.com/watch?v=p5mwMwwM-R0

Unsurprisingly the Z80 is quicker but at the same clock speed I think the 6502 would have finished three times faster than it... I hadn't the heart to comment on the thread, but I did wonder whether the Z80 basic was in fact MS's original 8080 basic.

Neil


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 7:39 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10802
Location: England
Kind of interesting - those are nice little self-contained boards - but in my opinion that's not a great benchmark.
10 FOR I =1 TO 10000
20 PRINT I
30 NEXT I
because it's doing a great deal of I/O over that 115200 baud serial connection. It's going to be spending a lot of time converting to decimal ASCII and sending strings.

That said, I think it's perfectly reasonable to run the Z80 at 4x the clock frequency, because that gives all three boards the same access rate for RAM and ROM. That's the right way to have a level playing field, and it more or less matches the early available clock speeds of 1MHz for sixes and 4MHz for eights.

The three Basics, although all Microsoft, might have important differences - in particular, whether they have 4 byte or 5 byte floats is going to make a difference. It could be that the 6809 COCO EXTENDED BASIC is the only one doing 5 byte floats, in which case it's less surprising that it comes out a bit slower.

Results:
6502 38 seconds
6809 52 seconds
Z80 27 seconds

Thanks for sharing the video, though!


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 8:45 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1930
Location: Sacramento, CA, USA
I agree that the benchmark could be much better.

Although it may be "reasonable" for Z-80s to clock in at 4x the clock frequency, 4 MHz Z-80 systems were quite rare and/or expensive in the late 1970s, while 1 MHz 6502s were cheap and plentiful. For me, moving from the 1.77 MHz TRS-80 Model 1, Level 2 to the 1 MHz Apple ][+ was quite a noticeable improvement in both speed and accuracy. Cassette storage was similarly improved. Losing ELSE and USING stung a bit, though.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 9:37 am 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 298
Having a very quick look at the source code for the ROMs in the three boards, it looks like 6502 and Z80 are both 4-byte floats, while 6809 is 5-byte. That's still a large difference in time though.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 10:58 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10802
Location: England
Good point Mike, the 4MHz Z80 would be a luxury product, certainly early on. At the time of the VIC-20 and C64, those were just under 1MHz 6502, and a Sinclair Z80 based ZX81 or Spectrum would run at 3.25MHz or 3.5MHz. Looks like Amstrad's Z80 machines were 4MHz, but by that time Acorn were offering 2MHz 6502 machines.

Thanks for checking John. I've been thinking about a good simple test for Basic accuracy. I came up with
PRINT 7E7+1234-7E7
which will print 1234 with a Basic with 5 byte floats, or 1232 (probably) with only 4 byte floats.

There are of course very many benchmarks: Gordon's textual Mandelbrot is nicely visual, and also rather computational. The PCW set was widely used back in the day - see here for a table of results. The Dragon32 is a 6809 machine running MS Extended Basic, at 0.89MHz, so one might scale the values accordingly.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 11:13 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
barrym95838 wrote:
Although it may be "reasonable" for Z-80s to clock in at 4x the clock frequency, 4 MHz Z-80 systems were quite rare and/or expensive in the late 1970s, while 1 MHz 6502s were cheap and plentiful.

Any idea why that was, if it wasn't due to memory speed requirements? As Chromatix noted here in the 2K BASIC thread, I always thought memory cost was the limiting factor in most of these cases - were the faster Z80 CPUs also harder to come by? Or was it something to do with the complexity of the faster glue logic making these systems harder to build?


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 11:16 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10802
Location: England
I wonder if the Tandy's low clock frequency was a result of video architecture? Sharing RAM between video and CPU means making some tradeoffs - whether to compromise CPU speed to accommodate reasonable cost RAM, whether to put up with video noise, whether to stall the CPU while video is active.

Edit: maybe a sub-2MHz Z80 was a cheaper chip? That would be a motivation.

Edit: also bearing in mind that the CPU clock was commonly a submultiple of the colour burst frequency, or pixel clock frequency, which limits the choices of CPU clock.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 07, 2023 4:47 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Looking at the TRS-80 Model 1 tech manual, it seems they made the CPU input clock identical to the video character clock. However, the main RAM and video RAM are on separate buses, and only interact when the CPU accesses video RAM. The TRS-80 is spectacularly crude about this, simply blanking the video output for the duration of the CPU access (which is 4 character periods due to the Z80's bus protocol), so intensive drawing operations would leave noticeable black flickering streaks on the display. It's a little bit similar to some CGA cards' habit of "snowing", though this was because they didn't do this blanking.

I don't see any obvious timing justification for not using a faster CPU clock; the RAM chips are all fast enough to respond to a Z80 running four times as fast. However, there is a minor clue in that the 10.6445MHz master crystal is divided by 6 to obtain the 1.77MHz CPU and video character clocks, and is used more-or-less directly for the video dot clock (ie. the character cell is 6 pixels wide). It would be awkward to obtain a clean multiple of the video character clock that aligned to the Z80 bus cycle reliably, because 6 is not a multiple of 4. The logic to deconflict the CPU access to the video RAM would thus be more complicated; I think the CPU would need to have wait states inserted conditionally. The decision was thus probably taken that design simplicity took precedence over performance, which in 1977 probably made sense.

The 6800 and 6502 would not have run into this problem, since they both complete a memory transaction in one clock cycle rather than four. They would run efficiently at 1.77MHz. It would be interesting to see how a 6x clock maps to the DRAM access cycle and the 6800's quadrature clock, though. One way to obtain a clean, symmetrical four-phase clock from a 6x oscillator is to make use of both the positive and negative edges of the master clock. With the E/Phi2 (and CAS) clock taken from the positive edges, the Q (and RAS) clock would be taken from the negative edges midway between those used for the CAS clock.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: