Jump to content
IGNORED

How to fairly compare the 8-bit Atari with their contemporary computers, speed-wise?


ldelsarte

Recommended Posts

Hello there!

 

I recently watched on YouTube a video from RetroManCave (Neil), titled "Inside the BBC Micro - Trash to Treasure (Part 2)" (https://www.youtube.com/watch?v=bQCgzIWZo0o)

At 0:03:35, Neil explains that the BBC Micro's 6502 runs at 2 MHz, which makes it pretty fast, compared to other computers from the same period, for instance the Apple II that ran at 1 MHz (1.9 MHz in turbo mode). Of course, I regret that Neil didn't mention Atari's 1.79 (1.77) MHz at that point.

Later at 0:08:00, Neil mentions the Rugg/Feldman benchmarks for BASIC, in which Atari BASIC (and the OS FPP) does not help to make the computer shine.

 

To me, it's not really fair to compare the computers with merely their CPU speed (*) and Rugg/Feldman benchmarks for BASIC figures:

- The Atari runs MUCH FASTER with other BASIC, such as Turbo BASIC XL, to name just one

- The Atari 8-bit architecture, with dedicated additional chips, allows the CPU to focus on the main tasks, whilst the other chips deal with video, sound, P/M, etc. In lots of other computers from the same period, the CPU deals with everything, so a higher clock rate is not enough to make it faster!

 

My question is: How to compare - with justice - the 800XL with the C64, the Apple IIe, the BBC Micro, etc in terms of performance?

Any suggestion of bench marking method?

 

(*) Same 6502 CPU for instance; We all know that a 6502 & a Z80 at 2 MHz are NOT equally powerful

  • Like 1
Link to comment
Share on other sites

Depends really.  Raw CPU speed is fairly easy to determine based on "wasted" cycles going to ANTIC.

 

However, let's take scrolling a full screen of data.  Without our custom chips, this would be a slow CPU bound task.  With ANTIC's display list, it can be as simple as one register write to move an 8K screen.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Using BASIC is not the way to test performance, as you say, depends on the BASIC used,

virtually all games and applications are written in machine code, so that would be a fairer way.

 

You would need a suite of tests:

 

Raw CPU performance doing some calculations, moving data etc.

 

Graphics manipulations: Drawing, moving screen data, scrolling etc.

 

Sound, pops , bangs, music.

 

Disk reads/writes.

 

Maybe I/O if you want to test everything.

 

Then you would get a better feel of what each machine was best at.

 

Simply using BASIC is not a real test.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

The BBC video hardware loses out.  It can do 80 columns and has double the bitdepth so 4 colours at 320x200 but no sprites, no HScrolling, not very good control of video base or mode changes midscreen.

So you can see it near it's peak in games such as Zalaga but you'll notice the lack of scrolling games and those that do generally do it slowly and/or chunkily.

  • Thanks 1
Link to comment
Share on other sites

AFAIK the BBC also uses dual port RAM so the CPU can run without video stealing cycles but as explained above the video chip is less (or differently) sophisticated than the Atari‘s. So it will beat the Atari hands down in pure execution speed but not graphically. Not something you can express in a single measure. 
 

  • Thanks 1
Link to comment
Share on other sites

17 minutes ago, slx said:

AFAIK the BBC also uses dual port RAM so the CPU can run without video stealing cycles but as explained above the video chip is less (or differently) sophisticated than the Atari‘s. So it will beat the Atari hands down in pure execution speed but not graphically. Not something you can express in a single measure.

 

Nope, it doesn't use dual-port RAM, it just uses the only manufacturer's RAM that could run at double the speed of the RAM in other machines of the early 1980s generation. That allowed it to display 320x200x4 color bitmaps, or 640x400x2 color bitmaps way earlier than other home computers. But the RAM was expensive ... so it only had 32KB when other machines at the time were starting to offer 48KB or 64KB of RAM.

 

Everything, absolutely everything, was the product of a cost-benefit analysis of the technology that was available at the time.

 

That's where the design choices in the Atari come from. It was designed to work with the 8KB and 16KB RAM chips that were avavilable in the late 1970s.

 

Three years later on, the C64 and Spectrum (and Atari 1200XL/800XL) could use the newer generation of 64KB RAM chips.

 

The Atari was absolutely amazing for its time, and it managed to do a good job of holding its own (and sometimes surpassing) the newer machines that came later ... but the genius of its design can only do so much against the march of technology.

  • Like 5
  • Thanks 2
Link to comment
Share on other sites

" The Atari was absolutely amazing for its time, and it managed to do a good job of holding its own (and sometimes surpassing) the newer machines that came later ... but the genius of its design can only do so much against the march of technology."  Well stated!

 

One could make some fairly simple assembler benchmark(s) to measure the processing power.  Much of the code should be interchangeable. You could add or subtract the display and other major individual features like disk access to get an idea of the overall processing from a particular machine.  OTOH, seems like a whole lot of trouble, plus then you have the issue of "original design" vs "improvements."  Many Atari folks would like to ignore the original Atari 8K BASIC, slow floating point, and even slow I/O. But that's what they came with.

 

-Larry

  • Thanks 1
Link to comment
Share on other sites

On 1/12/2020 at 12:38 PM, ldelsarte said:

Hello there!

 

I recently watched on YouTube a video from RetroManCave (Neil), titled "Inside the BBC Micro - Trash to Treasure (Part 2)" (https://www.youtube.com/watch?v=bQCgzIWZo0o)

At 0:03:35, Neil explains that the BBC Micro's 6502 runs at 2 MHz, which makes it pretty fast, compared to other computers from the same period, for instance the Apple II that ran at 1 MHz (1.9 MHz in turbo mode). Of course, I regret that Neil didn't mention Atari's 1.79 (1.77) MHz at that point.

 

What's this 1.9MHz turbo mode for the Apple II ?? Never heard of it.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

19 hours ago, Rybags said:

The BBC video hardware loses out.  It can do 80 columns and has double the bitdepth so 4 colours at 320x200 but no sprites, no HScrolling, not very good control of video base or mode changes midscreen.

So you can see it near it's peak in games such as Zalaga but you'll notice the lack of scrolling games and those that do generally do it slowly and/or chunkily.

image.png.ba59d6852eef67083bd65a0138c7c948.png

I know, I know. I never played with a BBC micro, but never felt tempted to. I grew up in France; the Atari 800XL was quite popular. I'm a big fan of Boulder Dash, perfectly designed and looking great on the Atari 8-bit computers. I mean, look at this BBC rendition.

 

  • Like 2
Link to comment
Share on other sites

2 hours ago, 777ismyname said:

FWIW, there is a recent discussion on AtariAge of Rugg Feldman benchmarks, in various flavors of Atari BASIC. I was thinking of porting it to Action! for shits and giggles.

Action! would provide the best compromise "listing is easy to understand, even for beginners" and "much, MUCH faster execution time, getting closer to assembly language speed".

If you write the Action! version, I'm truly interested.

Link to comment
Share on other sites

11 hours ago, elmer said:

The Atari was absolutely amazing for its time, and it managed to do a good job of holding its own (and sometimes surpassing) the newer machines that came later ... but the genius of its design can only do so much against the march of technology.

I didn't understand all this when I was 13yo with my 800XL.

To me the Atari 8-bit computers architecture is :

  • Elegant
  • Complex but not messy
  • Multipurpose and flexible
  • Highly optimized for video games
  • And also, to a certain extent, ready for the future

With the Atari 8-bit computers FAQ, the Altirra technical documentation, De Re Atari and a few other books, you can really understand that these people knew exactly what was needed to build a GREAT computer. That's why I really find it unfair to see all these YouTube videos, retrogaming books and Facebook groups glorifying "greatest selling micro computers" cheaply designed from the same period. You guess which one I'm referring to.

  • Like 7
Link to comment
Share on other sites

On 1/14/2020 at 12:51 PM, ldelsarte said:

Action! would provide the best compromise "listing is easy to understand, even for beginners" and "much, MUCH faster execution time, getting closer to assembly language speed".

If you write the Action! version, I'm truly interested.

I think I have what is supposed to be a faster floating point library for Action! somewhere or another. If I find it then I will write an Action! version.

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...
On 1/14/2020 at 7:07 PM, ldelsarte said:

With the Atari 8-bit computers FAQ, the Altirra technical documentation, De Re Atari and a few other books, you can really understand that these people knew exactly what was needed to build a GREAT computer. That's why I really find it unfair to see all these YouTube videos, retrogaming books and Facebook groups glorifying "greatest selling micro computers" cheaply designed from the same period. You guess which one I'm referring to.

My teenage self also found it unfair that the clearly (mostly) inferior C64 was so much more successful than the beloved Atari which had so many more elegant traits (better color palette, device-based OS, better DOS, etc.). Looking back I realize that was just one of many cases where a sufficient product at the right price wins out against a superior but more expensive product. I recall an interview (on Retrobits?) where (IIRC) Chuck Peddle explained that the C64 was basically designed to sell at manufacturing cost after a few rounds of rebates with profits to be made by selling peripherals (a bit like printers today) and that peripheral sales exceeded estimates by more than 100%. 

 

Maybe it is part of my fascination with the Acorn BBC Micro that like the Atari and despite (mostly) inferior graphics it has a lot of clever, elegant and forward-looking traits (modular OS, support for bank-switching ROMs under the hood, lots of expansion ports). Yet it was outsold by the vastly inferior but much cheaper Sinclair Spectrum and probably would not even have existed or at best remained a niche product without the big push it enjoyed through the BBCs education programme. While no one with a BCC would have swapped it for a Speccy, the latter was enough computer for many who could not afford a BBC.

 

Occasionally thinking about an Action! ROM for the BBC....

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I've always thought that the only real disadvantage that Atari built into their machines was the choice of attaching

peripheral devices i.e. SIO, on the face of it daisy chain devices have what you want, but this meant they had to

be intelligent (apart from cassette) which inevitably put the price up, so much so that people couldn't afford the much

needed disk drives and printers.

 

With a lot of people having access to printers, not being able to connect them to their Atari was a big negative.

For me I built a parallel port interface that pluged into ports 3 & 4 on my 800 and wrote a driver that resided in Page 6

which allowed me to use any Centronics Printer. Later I built a parallel and serial interface for my 130XE, again as

the price of an 850 interface was so much to buy.

 

I only managed to buy my first 1050 when they started reducing prices when sales were dropping.

 

In spite of all that, I chose the Atari 800 and later 130XE over the much inferior competition and don't reget it one bit,

I still use it every day and get so much pleasure. I have 2 ST's also, but hardly use those any more.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

In the end, there's no way to fairly compare them. They're all different animals. It's like comparing a Ferrari with a Jeep. Depending on what you want them to do, either could be faster, better or more fun.  Even a ZX Spectrum will be able do some things better than an Atari 800. Just love the one you're with and don't worry about the rest :-)

  • Like 2
Link to comment
Share on other sites

Now, figures. I wanted to get some figures about how the implementation of both Atari BASIC (rev. C) and the floating-point package (part of OS, used by Atari BASIC) lead to disappointing figures in the Rugg-Feldman benchmarks (see the Wikipedia page - https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks).

 

I made all my tests on Altirra v3.2, configured as a PAL 800XL.

I used all the listings (Benchmark 1 to 8, files D1:PALB1.BAS to D1:PALB8.BAS) of the Wikipedia page.

I added these two lines, to get a rough estimation of the duration of the execution.

10 POKE 18,0:POKE 19,0:POKE 20,0
800 PRINT INT((PEEK(18)*65536 + PEEK(19)*256 + PEEK(20)) / 50):END

Obviously, I realise that these two lines themselves biased the result by making the execution last even longer. But I wanted to compare the very same listings running with various configurations:

- Atari BASIC rev. C vs. Turbo BASIC XL

- Altirra's Fast Floating-point math OFF vs. ON

 

If you want to convert any of these listings to NTSC

ENTER "D:NTSC.LST"

If you want to remove the timing modification

ENTER "D:PURE.LST"

 

I created two separate graphics because the result of the benchmark #8 make the figures difficult to compare, due to the really long execution time of #8.

(FFPM means Fast Floating Point Math, an option of Altirra) 

 

See for yourself. The "result" is the output of line 800 (rough execution time in seconds, the lower the bar, the better)

 

We already knew all this but, to me, it is obvious that comparing an Atari 8-bit computer with the competitors from the same period in computer history, based solely on BASIC programs running on Atari BASIC is a very hazardous: the results can be impressively improved on the same hardware, running a different implementation of BASIC and/or the OS's FPP. I guess the same can be said about the other computers: there are surely better and faster BASIC implementations for them as well. But Atari BASIC - despite its versatility and user-friendliness - makes the Atari 8-bit computers look underpowered, which is absolutely not true.

 

BTW, do you know any other (non-compiled) BASIC that could perform faster than Turbo BASIC XL?

 

------ Attachements

 

performance.atr --> all listing, Atari BASIC & DOS

performance (turbo basic XL).atr --> all listings, Turbo BASIC XL & DOS

all the listings i've used.txt --> a UTF-8 text file with all listings

performance results - part 1.png

performance results - part 2.png

performance.atr performance (turbo basic XL).atr all the listings i've used.txt

Edited by ldelsarte
Link to comment
Share on other sites

1 hour ago, ldelsarte said:

10 POKE 18,0:POKE 19,0:POKE 20,0
800 PRINT INT((PEEK(18)*65536 + PEEK(19)*256 + PEEK(20)) / 50):END

Beware of the race conditions in the above code.  In line 10, where you are clearing the timer, you could potentially have a VBI occur in the middle of the line, resulting in the second or third timer byte incrementing to 1 right after you clear it, but before you clear the next lower byte.  It is probably better to clear them in the other order, low to high (weird that in this one case they decided to go big endian).

 

Likewise, in your reading of the values, you could end up missing a 'carry' where you read the higher byte and then the lower byte wraps back to 0 before you read it.  Maybe inhibit VBIs while reading these?

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

12 hours ago, StickJock said:

Beware of the race conditions in the above code.  In line 10, where you are clearing the timer, you could potentially have a VBI occur in the middle of the line, resulting in the second or third timer byte incrementing to 1 right after you clear it, but before you clear the next lower byte.  It is probably better to clear them in the other order, low to high (weird that in this one case they decided to go big endian).

 

Likewise, in your reading of the values, you could end up missing a 'carry' where you read the higher byte and then the lower byte wraps back to 0 before you read it.  Maybe inhibit VBIs while reading these?

 

Thank you for these tips!

I re-wrote line 10, in reserve order:

10 POKE 20,0:POKE 19,0:POKE 18,0

As for line 800, I dread that adding more changes (inhibit Vertical Blank Interrupts, etc) would again bias the results, even more. So, to mitigate, I ran the benchmark 3 times. If all 3 results are the same, I use them, otherwise, I run the benchmark 10 times and use the average value. I assume this will be enough to get a rough idea of the execution time. If not, I might ask the author of my very favourite emulator (Altirra) to add a new feature to track the execution time of BASIC programs.

Link to comment
Share on other sites

I took into account the suggestion of StickJock and ran the benchmarks again on Altirra configured as follows:

  • Base system    PAL 800XL (320K)
  • Additional Devices    Printer (P:), Host device (H:), VideoBoard XE
  • OS Firmware    Atari XL/XE OS ver.2 [1F9CD270]
     

I also added the more popular BASIC disks or cartridges:

  • Turbo BASIC XL 1.5
  • Microsoft BASIC I or II
  • OSS BASIC XE
  • OSS BASIC XL, FFPM option ON
  • OSS BASIC XL, FFPM option OFF
  • OSS BASIC A+, FFPM option ON
  • OSS BASIC A+, FFPM option OFF
  • Atari BASIC, rev. C, FFPM option ON
  • Atari BASIC, rev. C, FFPM option OFF

Strangely, OSS BASIC XE does not seem to benefit from Altirra's "Fast Floating Point Math" option, whilst the BASIC A+ and BASIC XL do.

On standard hardware, I'm tempted to conclude that Turbo BASIC XL 1.5 is the fastest.

On Altirra with the "Fast Floating Point Math" option ON, OSS BASIC XL is the fastest.

 

So, to come back to the Rugg-Feldman benchmarks, Atari's results would have been between approx. 5 times better with Turbo BASIC XL instead of Atari BASIC ...

Do you come to the same conclusion? Is there anything else I missed?

 

performance results II - figures.png

performance results II - all results.png

performance results II - cummulative results.png

performance.atr

Link to comment
Share on other sites

Things could be rather easy, if people allow to remove the pink glasses.

CPU speed really isn't all. It's also what the chipset is adding. Not just to take the load off the CPU. There are also possibilities where the Chipset is working in parallel to the CPU. It might have taken up to the year 1998 , when PC users , that had been proud of their "fast" CPUs, that things like a Soundcard with an own Processor and RAM, can play digital music , and VOODOO Graphics made the 3D Part, that CPU speed isn't all .

But as it seems, even today there exist Atari users who think in the same wrong direction of "CPU is all" .

The Atari has the ANTIC. The only real benefit of this chip is the internal small RAM Buffer that allows ANTIC to handle some things in parallel to the CPU. And there is the programmable re use of memory that allows to fill up the screen with a very low CPU load.

ANTIC can steal up to 70% of CPU speed, no, this is not a nice feature.

Then there is the GTIA chip. Well, it offers the Player Missile Graphics. Up to a limited degree it is a real benefit.

With just 5 CPU Cycles you can move a relative amount of 240 Bytes, horizontally.

In the vertical direction thing quickly turn bad. A simple vertical move of 10 Bytes need a least 11 Rows of 5 cycles.

So you have 55 cycles to handle.

In comparison to the C64, both directions need only 5 cycles for every Sprite.

Adding all possiblilites , the Atari's CPU would need 8Mhz to have C64 games running .

 

Vice Versa, the Atari HAS the PMg , so there is a real advance to other computers back then.

But particular the C64 was built to be better in that case than any other computer of that time. VIC2 and SID did a lot to add to the CPU, so in a lot cases, the 1MHz weren't a limit for games.

Only games that took use of the benefits by ANTIC and GTIA, did their job well, for up to computer development of 1986.

The modes in that ANTIC does the additional filling of the screen, had been unreachable for other computers.

Star Raiders, Rescue on Fractalus, or even Electraglide had their speed advance.

 

Games that took the optimized Displaylist to get the fastest visuals , also had been on top .

Dimension X , Ballblazer or Stealth brought breathtaking speed with good visuals.

 

But, as soon as real detailed and colorful graphics had to be used, everything was too much for the CPU and, games needed to be reduced heavily.

Just have a look at Donkey Kong Jr. The screen is reduced to 32 bytes, the enemy movement is at charset resolution. It's a fun game, but barely running smooth.

 

Games like Drop Zone still have been fast by the tricky use of enemies that move in a scrolling relevant speed.

Other games tricked the movement of a whole enemy invasion by just scrolling the screen (Space Invaders).  

 

Those tricks wouldn't have been possible, if the Atari didn't have the hardware features. It was a marvelous task in 1979 , but they missed to add features by the years.

 

 

A fair comparison with contemporary computers is only possible, if you put all chipset features to it.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

9 hours ago, ldelsarte said:

Thank you for these tips!

I re-wrote line 10, in reserve order:


10 POKE 20,0:POKE 19,0:POKE 18,0

As for line 800, I dread that adding more changes (inhibit Vertical Blank Interrupts, etc) would again bias the results, even more. So, to mitigate, I ran the benchmark 3 times. If all 3 results are the same, I use them, otherwise, I run the benchmark 10 times and use the average value. I assume this will be enough to get a rough idea of the execution time. If not, I might ask the author of my very favourite emulator (Altirra) to add a new feature to track the execution time of BASIC programs.

If the race condition hits in line 800, you will have artificially low values by either $010000 or $000100 jiffies.  Averaging this into 10 will still give you a pretty big error (6553.6 or 25.6 offset).  Maybe discard any result that is more than 250 less than other passes?

 

You can minimize (but not eliminate) the window by shortening the timer read code by doing something like T1=PEEK(18):T2=PEEK(19):T3=PEEK(20) and then processing the data.  Also, if you do it this way, you can see if you *might* have hit the window by seeing if T3 is 0. 

 

How about this idea:

99 STARTTIME=0

100 POKE 20,STARTTIME:POKE 19,0:POKE 18,0

 

800 T3=PEEK(20):T2=PEEK(19):T1=PEEK(18):T31=PEEK(20):IF T3<>T31 AND T31=0 THEN STARTTIME=128:GOTO 100

801 TIME=(T1*65536)+(T2*256)+T3-STARTTIME

 

In line 800, if T3 and T31 are not the same, then the VBI hit during the reads.  However, if it is just incrementing from, say 5 to 6, then it is no big deal as there is no carry involved.  If it is wrapping from 255 to 0, that is when we start getting big errors, so we will only trap that case.  To make sure that the next pass doesn't end up in the same place, we offset the starting timer value.

 

Of coarse, it is still a good idea to average several runs.

 

 

  • Thanks 1
Link to comment
Share on other sites

When you run benchmarks in BASIC, you aren't just benchmarking the CPU, you are benchmarking the BASIC.
But a lot of people bought machines to use BASIC, so it is one of many things benchmarks should consider.
Most BASICs aren't built for speed, some are just slower than others.
 

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...