Z80 Model 4 vs 6809 Coco Retro Speed Challenge

[@JamesJones-zt2yx]

The Z-80 takes more clock cycles for a given operation than the 6809 does; a 2 MHz 6809 will outrun the 4.77 MHz 8088 of the original IBM PC. The 6809's addressing modes give it an edge as well. As others have pointed out, the CoCo is doing a lot more work scrolling than the Model 4. Also as others have said, it would be interesting to try the tests under NitrOS-9 (a rewrite of OS-9/6809 initially done to take maximum advantage of the Hitachi 6309, a drop-in replacement for the 6809 that turns out to have a mode that provides additional registers and instructions, and, aside from interrupts which have to save the additional registers, takes fewer clock cycles to execute 6809 instructions than the 6809). It would also be interesting to see how much difference BASIC09 would make. BASIC09 converts the source code you enter into a form that both allows for prettyprinting, so you can still list and edit your code, and allows for far faster execution than the minimally changed form that typical microcomputer BASICs of the time kept, which at execution time forces endlessly reparsing expressions, converting constants from human readable form, and looking up variable names and statement labels. Any chance you could post your sieve listing?

[@VK2FVAX]

Definitely love to see a Sieve listing. Would dearly love to see this vs a MOS8502 in a c128 and a c64's mos6510 and a bog 6502 in either a KIM-1 or any of the PET/CBM/Porsche Pets, and just how slow BASIC is on my Atari 65XL. :P

[@JamesJones-zt2yx]

Pause (and fullscreeen) is your friend; you can see the sieve listing on the Model 4 display about 11 minutes in. Converted to BASIC09 to run under NitrOS-9/6309 EOU (ease of use) Beta 5, emulated on MAME, which does a good job of running at the speed of the original hardware. Running at an emulated double speed, the BASIC09 code takes between four and six seconds (I could get closer by running it maybe ten or a hundred times--I'm just printing out date and time of start and end, which is only shown to the second). In the BASIC09 version, the sieve is an array of Booleans, the loop control variables are integers, and unfortunately, in BASIC09 I had to wire in the value of lim since an array was involved. NitrOS-9 also scrolls considerably faster than Color BASIC or even the original OS-9.

[@driven01]

I want to go back in time. I was a god on that architecture. I was also far younger and better looking. The trifecta is that politics and people weren't as divided. Yeah, please bring me back to my 6809 coco days.

[@wcarlin]

@@VK2FVAX 5 INPUT "LIM"; L 10 DIM FL(L) 20 FOR N=2 TO SQR(L) 30 IF FL(N) 0 GOTO 80 50 FOR K=N*N TO L STEP N 60 FL(K) = 1 70 NEXT K 80 NEXT N 100 FOR N=2 TO L 110 IF FL(N) = 0 THEN PRINT N;", "; 120 NEXT N

[@wcarlin]

@@JamesJones-zt2yx As I was watching the video, I thought to myself that BASIC09 would be about 8 times faster. Looks like I wasn't far off in my estimate.

[@jamesigou9033]

I used to manage a Radio Shack franchise (Delmar Company) that ran it's multiuser POS system on a Coco under OS-9. Written with a Sculptor based database. It could support three or four users. Try that with a Model 4 (or any Z80 based machine).

[@horusfalcon]

Please: it's a Zee-Eighty. It's an American design. Good vid. Brings back memories of my old CoCo 3

[@gregoryroscow5846]

Zed 80 for Canada, UK, Australia, New Zealand etc. Doesn't matter where it was designed.

[@jasejj]

I think this tells you more about the efficiency of the ROM routines than anything else. I remember running similar tests back in the day on a Commodore VIC20 (1Mhz 6502) vs a Sinclair Spectrum (3.5Mhz Z80). The CBM blew the ZX away, mainly because the Sinclair machine used a lot of routines borrowed from earlier machines that were optimised for size not performance, and in the case of the graphics display the Sinclair did not have a text mode so had to poke 9 bytes (8+colour) for every character output to the screen.

[@paulstubbs7678]

Maybe the spectrum pauses the CPU during quite a lot of the video generation, like Sinclairs earlier efforts - useful code was only run in the video retrace period.

[@jasejj]

@@paulstubbs7678 The Spectrum doesn't do that, the video memory is contended so there is some slight slowdown when the CPU needs to access it but for BASIC programs the ROM routines are just slow. If you look at some titles for the machine such as I of the Mask, and Operation Wolf, you'll see that the system is quite capable from a graphics speed perspective despite lacking hardware sprites or scrolling. See here for an explanation of the memory contention principle, it's really quite clever spectrumforeveryone.com/technical/memory-contention-floating-bus/

[@TheTurnipKing]

​@@jasejj Broadly speaking on the Spectrum, if your code is above 8000h, it should run without contention.

[@jasejj]

@@TheTurnipKing Yes, this is true.

[@notyoung]

Interesting, as I had contact with both but my CoCo was a II, not a III. Basic09 running under OS9 (the original, not the nitro) was a very impressive tool. The OS9 terminal program had no problems running the (graphic) 51 character screen width at 2400 baud. I had a C compiler for the CoCo and it was OK after I corrected some errors in the (assembler) library - things like toupper() and tolower() were not handled as specified by Kernighan and Ritchie. Things I wrote in C were obviously faster than the interpreted BASIC on any micro of the day. I didn't finish the video. I often use headphones and I find unneeded music annoying; unneeded music louder than the narration is justification for termination.

[@CurtisBoyle]

As James Diffendaffer and William Astle have pointed out... the Coco's Microsoft BASIC was almost a straight port of earlier versions of BASIC, and didn't really use the full power of the 6809. Would be interesting to match NitrOS-9/6809 (particularly the new EOU Beta 2) with BASIC-09. :)

[@sprybug]

Yeah Curtis, I was going to write a comment about how you need to take in the efficiency of the coding of the BASIC interpreter into account as well.

[@RetroLogicLaboratory]

Thanks for checking out my video! Ya that was a bit of a struggle I had while filming this - but it can be argued that even if we measured with pure assembly code a really skilled Z80 or 6809 assembly programmer might be able to hack a solution 30% faster than an average programmer. I figured it was best to assume that both BASIC interpreters were developed by people of similar skill levels, and that I wasn't using any functions that were "known bad" on either platform. BASIC being the common language of the time and all, as well as the fact I could use the exact same source code in both machines. I realized today that the M4 was probably only running at 2MHz so I will probably make a follow on video for this but after that, I'm thinking I'll run a test of BASIC09 vs RSDOS BASIC (which BASIC09 will obviously run circles around) just out of curiousity.

[@Agnemons]

Umm. Your not comparing a Model 4 to a coco. Your comparing a model III with a coco. The model 4 in native mode runs at 4 Mhz while in model III mode it is running at 2 Mhz.

[@fedoralexandersteeman6672]

Pretty cool! How about comparing speeds of machine language programs? Then the interpreter and the way it's written won't skew the results.

[@richardkelsch3640]

All these measurements show are the differences in how the BASIC ROM is optimized in each machine. Different BASICs handle variables, math, and other things differently. Then there's the hardware. You can set an MSX, ZX Spectrum, and TRS-80 Model 4 (all Z80 machines) side to side, have them adjusted for the same clock speed, and they all would perform differently. The results would be just as dramatic. It's the BASIC itself, as well as the surrounding hardware. These same things can be done with a Commodore 64, Atari 130XE, and Apple II (all 6502 machines), and depending on which BASIC is used, the results would be vastly different. FOR/NEXT loops? Seriously?

[@what9418]

Yeah agreed, given the outcome, the coco's basic interpreter clearly doesn't use the MUL instruction.

[@microhobbyist]

Interesting results. I'd love to see the same tests in assembly. Actually, testing the 3 most popular 8-bit CPUs, Z80-6809-6502 toe to toe at the same clock speed would be interesting indeed.

[@mdshaw89]

This was AWESOME! Would love to see some more just like this using ALL of the old vintage computers. Using BASIC is perfect because if you were anyone back in the day using anything at home you more than likely used BASIC. Its funny to think that my primary programming language from 7th grade(where I was introduced to the the Apple II), through high school(using TRS-80 model III's and IBM PC Jr's) through my "freshman" year in college(using BASIC on a 'mainframe' system) was all BASIC.

[@RetroLogicLaboratory]

Hey thanks for the nice comment! One thing about benchmarks is that they are pretty much bogus (think BogoMips) because there are so many potential variables. What I like about this speed test is that there is one constant, that is the source code is exactly the same between the two machines- down to the spaces and punctuation. So even though it doesn't test the absolute fastest way either machine can perform the given calculations it does compare how they would run with precisely the same inputs. And since BASIC is what the machines came with it is also like you said more than likely what you'd be using at home.

[@driven01]

Who starts coding at line 500? (gasp)

[@rflberg]

Like to see the coco go against other computers. Also width 80 screen has to do a memory swap because it is outside the 64k area.

[@johncochran8497]

There was a bug I discovered in the Model 1 TRS-80 Level II basic in the floating point math. When I discovered that bug, I tested it with newer computers and it persisted on every computer I ever checked that used Microsoft Basic until floating point co-processors became ubiquitous. If you want, there's a simple program to detect it. 10 A = 1E38 20 B = SQR(A) 30 C = B * B 40 PRINT A,B,C What is going to happen is that you're going to get a floating point overflow in line 30. That is obviously wrong since you A is equal to 1x10^38 power which is representable. And the square root is 1x10^19. So C should be the same as A with a value of 1x10^38. Why does this happen? Floating point numbers have 2 parts. A significand which has a value greater than or equal to 0.5 and less than 1.0 (in binary of course). It also have an exponent ranging from -127 to 127. I'm not getting into lower level details such as excess-128 representation and such. The floating point math in Microsoft basic will add the exponents and if the result is an overflow, immediately report an overflow. It will the multiply the significand, and finally if needed normalize the result. Unfortunately, that algorithm is incorrect. Consider the possible range of values from multiplying the significands which range of [0.5, 1.0). The result will be in the range [0.25, 1.0). If the result is in the range [0.25, 0.5), then in order to normalize the final result, the significand has to be multiplied by 2 and the exponent has be decremented by 1. So if you have a multiply where you add the exponents and the result is exactly 128 (an overflow condition), it's possible that the final result won't be an overflow IF the result of multiplying the significands is less than 0.5. Basically, the Microsoft multiply routine terminated too early with an error if the exponent just barely overflowed.

[@RetroLogicLaboratory]

Hey that's really cool. Didn't Bill Gates write the floating point math himself? I thought I read that somewhere.

[@johncochran8497]

@@RetroLogicLaboratory I don't know if he did or not. I do know that the version of BASIC on the TRS-80, both level 1 and 2 were written for the 8080 and did not take advantage of the capabilities of the Z80. In fact, that's how I discovered the bug in Microsoft's floating point. I implemented my own floating point package in Z80 assembly and tested it with a program that generated random numbers and performed the multiplication using my package and Microsoft's, then comparing the results. When there was a difference, the program halted and displayed everything so I could manually verify things. Was rather surprised when I discovered a bug in Microsoft's code instead of mine.

[@paulstubbs7678]

@@johncochran8497 It sounds like the basic was based of the original code Bill Gates and his mates wrote for the original Altair 8800, with a lot of the core code never getting updated. It must have been a shock to them when it came to getting their code running on the 68XX and 6502 processors, they'd have to actually revisit all their code.

[@TheSulross]

Tandy against Tandy - keep it in the family. Well, what CoCo users really want to know is how their 6809 fairs against 6502 rivals from Commodore, Atari, Texas Instruments, or Apple

[@josesantos2603]

There was an amazing 3D Atari game made with Motorola 6809 processor, called "I Robot", with fast and colorful 3D graphics. It was beyond its time, we just had graphics like that by the end of the 90's.

[@JamesJones-zt2yx]

Is that a graphics mode screen on the CoCo? I'm pretty sure that the Z-80 TRS-80s only did text mode, with the only graphics being the block characters.

[@rdoetjes]

I never coded in basic anymore after I’d learned assembler on the C64. And even today I just code assembler for the C64 :) I recently also got back into Z80 and I don’t like it compared to 6502 or 68000 there’s too much limitations of reading from memory. You have to use specific registers, and you can’t inc or dec a memory location. You need to load the value from memory do your operation on it and store it back. It’s far more tedious. And I see a lot of the 8086 in there, which is logical as the 8086 is based on the 8080 which in turn was cloned as a Z80. I did very little with 6809, I only made a sumo bot with it but it felt very friendly. Like the 68000 does too. Awesome instruction set.

[@RetroLogicLaboratory]

Hi, thanks, its great to hear some of other people's experiences in different assembly languages! I did a lot of 8086 code a long time ago but forgot most (all) of it.. Except the scars obtained from memory segments are something I still have. :) 6809 was rumoured to be inspired by the PDP-11 instruction set which was pretty elegant.

[@AndrewTubbiolo]

Zeee eighty, the Z-80 is 'merican.

[@Jenny_Digital]

I'm just about to watch this battle and my money is on the 6809 as it's architecture _should_ give it the edge more often than not. That is unless we're dealing with lots of block copies and 16 bit indexes. EDIT: Didn't realise you were using BASIC (Makes sense though I used to use FORTH and assembly myself). My bet is somewhat worried now.

[@Foxxy11256]

In Model III Mode, the Model 4 is running at 2Mhz instead of it's native 4Mhz.

[@ChristopherLionRoars]

The plethora of registers and fast register based instruction gives the math an advantage in the z80

[@Everything817]

Great video. If you aren't a member of the TRS-80 Model 1-4/4P group on Facebook, we'd love to have you!

[@RetroLogicLaboratory]

Hey thanks for the invitation! I'm on the group but a bit of a lurker. I really enjoy the quality of conversations on the group and honestly haha the real experts are there posting all the time. Better for me to be quiet and absorb the knowledge. :)

[@smalltownMainer]

from what i have seen that keyboard issue is the carbon contacts. you can get something to paint onto those surfaces which works well.

[@uni-byte]

RUN would do without the line number and you don't need spaces in BASIC. Just sayin'. Also, you have to remember that the COCO's video needs to sync with a regular TV/monitor so this slows down the screen updates. The Model 4 has a purpose built monitor that allows for faster sync and hence faster video updates. The COCO is a faster machine computationally. However, there is something very cool about the model 4.

[@hitechworld7264]

The model IV appears to be running in 64x16 mode while the CoCo is running 80x24. That would mean the CoCo has alot more work to do than the model IV each time it scrolls. Furthermore the 80 column mode in the CoCo 3 has both character and attribute bytes that need to be moved. Maybe you should have run both machines in their respective 32x16 modes for the purposes of comparison.

[@RetroLogicLaboratory]

Yes i think you are right. I somehow didn't notice the 64 character width.... Worse than that though is that in Model III the computer is only running at 2Mhz instead of 4.... I've decided to unlist this video for now because the conclusions I've drawn are flawed (not that this was intended to be science or anything). Might re-do the video or do a follow-on.. not sure yet. Thanks for pointing this out!

[@Jenny_Digital]

@@RetroLogicLaboratory it's still fun to race them.

[@paulstubbs7678]

@@RetroLogicLaboratory Minor problem.

[@kevincozens6837]

The video showed the second display test completing at the same time on both machines.

[@1697djh]

You should have tried the model 4 in model 4 basic? Would have been interesting ?

[@Jenny_Digital]

I have a question. Does the CoCo have to copy the screen RAM to scroll the screen but the TRS80 just update a pointer. That could be a reason for the CoCo's slower scrolling. Then again, it could be the Z80's block copy opcodes helping the other.

[@RetroLogicLaboratory]

I really like this question. I bet some of the viewers can probably answer this offhand. Any takers? If not, I might have to do the research myself and do another video!

[@CurtisBoyle]

@@RetroLogicLaboratory I can't speak for the TRS80, but on the Coco, yes, it is block copying screen RAM to do a scroll. And on the 40 or 80 column screen modes, that is two bytes per character (ASCII char byte and attributes byte).

[@paulstubbs7678]

The Z80 Trs's have the video ram as part of the main memory map, there are no pointers of other modern complex designs. The first video ram byte is always the first char on the screen etc. To scroll you have to block copy the video ram. However (on the M1 atleast) there is no delay in video ram access, to the detriment of the display. Whereas later designs (CoCo?) make the CPU wait so that video display glitches are not created.

[@paulstubbs7678]

Interesting, I would have thought the 6809 would be faster, as you say, it's a later design. I think the video output on the M4 would be faster, as it is a simpler design, with the CPU not paused in it's video writes to avoid glitches in the video as the CPU steals the video RAM away from the video generation circuits. (well, that's how my model 1 works - I'm assuming the M4 is the same) Pity you didn't post the basic code for the last example, as I'd like to run it on a few of my boxes. Also a pity about your M4 keyboard, My M1 with an Alps keyboard (later ver) is still fine, with no repairs needed.

[@jeffm2787]

Both are great processors IMO. Z80 had much more software and OS wise from what I recall.

[@youreperfectstudio4789]

The CoCo3 also has a value you can poke that way speeds up the processor. Edit oh I see you cover that haha

[@tchiwam]

That's why I always calculate 1 / x before my for loop :)

[@GORF_EMPIRE]

Interesting that the z80 beat out the 6809 in multiplication seeing that the 6809 has hardware mutliply. But the model 4 is running at 4 mhz where the 6809 is less than 1 mhz.

[@uni-byte]

The math libraries for the Z80 were more mature at the time. Also, those use din the COCO were probably just ported over from the Z80 rather than designed specifically for the 6809. They are both based on MS Basic and MS had much more experience with the 8080/Z80 lineage of CPUs.

[@GORF_EMPIRE]

@@uni-byte Even in a port back then would have been most likely in assembler so I doubt that's the reason. I think the clock rate could be more the likely culprit.

[@uni-byte]

@@GORF_EMPIRE Of course, but asking a bunch of 8080/Z80 programmers to port their code to 6809 ... yeah, it ain't gonna be pretty. I'm guilty of this my self. I have ported 6502 code to Z80 and to 8088 and while it runs, it ain't optimum. The 6809 should be able to run circles around the z80, and it does in the right hands. Just look as OS/9 compared to CP/M. BTW, the Z80 cuts it clock frequency in half internally to produce the phases it needs for processing. So a Z80/8080 running at 4MHz is (kinda) like a 6809, 6800 or 6502 running at 2MHz. Something to keep in mind.

[@GORF_EMPIRE]

@@uni-byte Oh I'm not saying the 6809 is not the better chip because I believe it is. I've coded 6502, Z80, 68k, Jaguar Risc and many others. They all have their charm. But clearly some are going to run code more efficiently ...Z80 are still one of may favorite processors though. I will get around to 6809 someday. Funny thing is... my first computer was a Coco but I stuck with basic. I did not do assembler until my 2nd machine...the 6502 VIC-20.My Astrocade is where I learned z80. Atari ST the 68k and then the Atari Jaguar for the RISC chips. I did a few months worth of SH4 when screwing around with the dreamcast.

[@mheermance]

Basic used floating point numbers which were expensive on eight bit machines. The 6809's multiplication instruction was an integer multiply and was likely swamped by all the bit shifting floating point requires.

[@alphahr]

I have yet to get me a Coco 3. I have a few Coco 2 and A stack of MC-10's

[@datalore6187]

I used to have a TRS-80 Coco3. I had so much fun with that machine. Tandy sabotaged the marketing for the machine because they didn't want to kill the sales of the Tandy 1000. The Tandy software for the Coco3 was just....meh. But other vendors made some pretty good software, and pushed that little computer to its limits.

[@IrishCarney]

I had a CoCo. Loved many things about it but was always annoyed by that hollow metallic echo of its keyboard. That Model 4's keyboard sounds so much better

[@RalphReagan]

Everyone i knew got rid of their 6809 and upgraded to the Motorola?

[@Captain_Char]

I could do this same test on my kaypro 2x, but I also have the option to compile the program into machine language

[@davidgari3240]

Feeble. For a = 1 to 1000 Print a, a*a, sqrt(a), 1/a Next a Ignore scroll speed by not PRINTing but by assigning count, square, square root, and reciprocal to variables. Let us know who wins.

[@wishusknight3009]

I thought the cocoiii had a clock of 1.78?

[@osgeld]

it does in fast mode

[@JamesJones-zt2yx]

It does, but when it comes up in BASIC, it remains at the original 0.89 MHz clock rate. OS-9 on the CoCo 3 switches to the faster speed when it starts up.

[@joelavcoco]

POKE &HFFD9,0 will put the CoCo 3 in 1.78MHz mode in BASIC.

[@deterdamel7380]

So.. you should get a Coco, if you need a more powerful computer.. 😄The issue with assembler wasn't the complexity, it was more the lack of an 'IDE' and the risk to lost the content of the memory (source-code) after every simple bug.

[@AndrewTubbiolo]

Subs are expensive. American Virginia class subs are running over 2 billion these days.

[@c704710]

Compare displaying 6 trapizoids on screen.

[@Simcore999]

👍

[@archieil]

model 4 had faster video if I am not wrong. The reason for slower full screen updates programms

[@AndrewTubbiolo]

10 for X= 0 to 0.999 step 0.001 20 print atan(x) 30 next x THAT's a test.

[@seka1986]

COCO 6809 FOR THE SLAM DUNK WIN!

[@elfenmagix8173]

Though the Z80 is based on the Intel 8080 made in the mid '70s, the Motorola 6809 is based on the Motorola 6800 made in the mid-late 70s. Both have multiplication / division op codes. The 2 machines are made for different markets, business vs. home. Thus one will beat the other depending on what tests you throw at it.

[@kraftwerk974]

If back then you had a C64 then the 6510 outclassed these two 🤣

[@driven01]

(Cough) ouch and that keyboard

[@isiisorisiaint]

you kinda say it yourself, but then you don't, this is a totally useless video for the purpose of its title, you're comparing two very different basic implementations, not two cpus, thumbs down for the misleading title

[@martindejong3974]

The coco is a toy (and designed by Motorola, not Tandy) compared to the model 4.