Jump to content
IGNORED

A collection of Atari BASIC benchmarks


Recommended Posts

35 minutes ago, Mazzspeed said:

If you want to cheat, the PAL +4 would probably be the fastest machine there with the screen blanked in NTSC mode

There is no cheating, whatsoever. There never was.

 

I for one am happy that the +4 has the ability to muster all of its firepower and mop the floor with the C64, at once. GOOD for it!!

 

Action!, QMeg 4.04, PDM Player, a ton of file-decompressors, PBI HD-based I/O, they all rely or substantially improve when having access to full CPU-bandwidth (if or when it is needed the most).

 

And no, there is no script (.bat file) needed because an SDX-compliant driver is loaded from a .CFG driver-config. file (which resides on SPARTA.DOS folder), and it is a facility innate to SDX, providing full auto-boot functionality (that is a benefit of running a better-built DOS).

 

And no, the cute-girl pictures appear when it becomes much nicer looking at them, just because we somehow are driven to stop praising Atari-merits, and (instead) we get desperate subliminal advertising of foreign toy-computers that do not relate to this forum or our own platforms.

 

But it is business as usual, I guess.

 

Link to comment
Share on other sites

17 minutes ago, Faicuai said:

There is no cheating, whatsoever. There never was.

If there's no script than you're manually poking the necessary registers to blank the screen using your XEP80 as the display device, meaning the machine is not as it is on boot and it is specifically stated "Tricks like turning off interrupts to get better results should not be done." - Meaning, no screen blanking, as there's little doubt that falls under the definition of a trick no matter how you want to manipulate the results in your favor as a fanboi.

 

CONFIG.SYS and AUTOEXEC.BAT (including any .CFG type file) are scripts, they're effectively software running before the benchmark to achieve an advantage (disabling DMA) - Therefore they're a trick.

 

As stated, the benchmark machine used as a line in the sand is a C64 that isn't using screen blanking to achieve faster results - And it would achieve faster results using screen blanking as the VIC-II wouldn't be stealing CPU cycles every badline. So if the basis for the benchmark isn't using screen blanking, than screen blanking makes your results invalid.

 

You use half naked Women as a distraction when you're back against the wall out of comebacks. I wonder if there's any Female users on these forums, I wonder how they'd interpret such images? For the record, I'm not the only person in this thread stating your results are invalid.

Edited by Mazzspeed
  • Like 1
Link to comment
Share on other sites

9 minutes ago, Mazzspeed said:

If there's no script than you're manually poking the necessary registers to blank the screen using your XEP80

No, no, no, this not how this works.

 

The SDX driver (Ultra) for XEP80 takes care of DMACTL / SDMCTL registers. because it must secure full fire-power when driving traffic in and out through PIA, at 30+ Kbps line-rate. This is a driver-level operation (not user-level). If not, XEP driver´s timing table will go off the window and crash!

 

The REVERSE situation, however, is what nowadays I am firing manually: I "park" the driver while residing in MEMLO and still hooked to SDX warm-start mechanism, and open a E: session in 40-cols.  mode, by instructing the OS to perform such task via HATABS handler table. I can then resume 80-cols. session at full speed (1.79Mhz minus overhead) with the exact same machine-language routine.

Link to comment
Share on other sites

Just now, Faicuai said:

No, no, no, this not how this works.

 

The SDX driver (Ultra) for XEP80 takes care of DMACTL / SDMCTL registers. because it must secure full fire-power when driving traffic in and out through PIA, at 30+ Kbps line-rate. This driver-level operation (not user-level). If not, XEP driver´s timing table will go off the window and crash!

 

The REVERSE situation, however, is what nowadays I am firing manually: I "park" the driver while residing in MEMLO and still hook to SDX warm-start mechanism, and open a E: session in 40-cols.  mode, by instructing the OS to perform such task via HATABS handler table. I can then resume 80-cols. session at full speed (1.79Mhz minus overhead) with the exact same machine-language routine.

Dude, as clear as I can be. The basis for the benchmark does not have it's onboard graphics chip disabled for faster results, and there is no doubt it would achieve faster results with the VIC-II disabled for the reasons mentioned above. Therefore, if you disable ANTIC, you are performing a trick and it is specifically stated no tricks are allowed. So while your little experiment is interesting (if not predictable, as it's what you always do while crapping on about running the 6502 hot), it's totally invalid as a direct comparison to the basis of the benchmark.

 

All you are doing is highlighting the fact that early forms of DMA aren't always ideal, there were better ways of doing things. Having said that, for it's age there is no doubt the A8 is an impressive design.

Link to comment
Share on other sites

13 minutes ago, Mazzspeed said:

And it would achieve faster results using screen blanking as the VIC-II wouldn't be stealing CPU cycles every badline

This is also not true, as there are solid basic-benchmark examples on C64 where screen-blanking makes zero effect.

 

But the best you can do is prove us wrong: go to Bench64, download C64 version, and run it yourself on your actual C64 with and without screen-blanking, at let us know the results!

  • Haha 1
Link to comment
Share on other sites

14 minutes ago, Faicuai said:

This is also not true, as there are solid basic-benchmark examples on C64 where screen-blanking makes zero effect.

Bullshit.

 

The VIC-II has a form of DMA that's technically an improvement on the A8's design. During normal operation the CPU and VIC-II share the bus in an interleaved fashion, where necessary the VIC-II uses the AEC line to halt the CPU to gain bus priority, this is done every badline - The CPU is the bus slave and the VIC-II is the bus master regarding the C64's architecture.

 

Certain C64 fastloaders used to blank the screen to improve disk drive loading times, the benefit was considerable. The performance benefit wouldn't be as great as the A8, but there'd no doubt be a benefit.

 

Your ignorance is showing I'm afraid, and your results are still invalid.

Edited by Mazzspeed
  • Like 1
Link to comment
Share on other sites

11 hours ago, Mazzspeed said:

The VIC-II has a form of DMA that's technically an improvement on the A8's design.

 

11 hours ago, Mazzspeed said:

Your ignorance is showing I'm afraid, and your results are still invalid.

 

No, it is not about "ignorance" (as you immediately claim right after being pressed or simply invited to show your OWN results or evidence) It's just that the relative difference is too small to alter reality in a meaningful way (and much less to invalidate my results):

 

https://www.lemon64.com/forum/viewtopic.php?t=69897&start=0

 

"Commodore 64 (PAL): 31.97, 30 with screen off (poke 53265,11), 34 if Return is held down."

 

While certainly NOT zero (as I disregarded as such), it will not change the material reality a single bit, and will not change the FACT that the A8 will run the tests (presented on this thread) substantially faster, any time of the day.

 

Since it is clearly evident that you have no real interest (whatsoever) in how well the Atari platform could really do (but, instead, how to enshrine anything C64-related, at every possible turn). you are more than welcome to run Bench64 on your C64 (with or without OS-driven interrupts, VIC-II or whatever you wish to enable or disable on its original config., with whatever Basic interpreter of your choice) and share with us YOUR own findings (at least, you will have the opportunity to participate in a meaningful way on this discussion, and who knows, we could even add those results to Maury´s table, too!)

 

Even better, I invite you to grab the .ATR I originally posted at the beginning of this thread (which you can perfectly open on your end), and hand-port any of the SIEVE assembly benchmarks I included there to your C64 assembler of choice, and show us all the way!

 

There's a great opportunity there for you to shine.

 

 

Link to comment
Share on other sites

19 hours ago, Faicuai said:

Basic++ is the only one that can't handle them.

Case closed. (UPDATE: ok, not so closed... Could you please try running FPTEST34.BAS from last image I posted and show a screen-shot of final index, so I can try to guess where your FP-pack is baselining? Is it 2KB in size or larger?)

That's what I did above, this is from your image. Actually, Basic++ is there tested with the Os++ math pack, which is *another* math pack. But, frankly, what's so complicated about that forbidding you to run the tests yourself? You can also cross-compare Atari-Basic/Os++, Basic++/Original math pack if you like, all these combinations work just fine.

Link to comment
Share on other sites

8 minutes ago, thorfdbg said:

That's what I did above, this is from your image

No, you did not.

 

You ran Bench64.bas, not FPTEST34.bas (unless I missed the latter's screenshot, which I could not find...)

 

FPTEST34 *also* fails on my end with one of the FP packs I have here (I had already tested long before). Just wanted to see those specific results with YOUR FP-pack, and maybe build an OS image with your FP rom (if we can have access to it), so we all can run Basic++ to its intended / full potential (no Basic package on Atari will get anywhere with stock FP rom).

 

Link to comment
Share on other sites

9 hours ago, Faicuai said:

 

 

No, it is not about "ignorance" (as you immediately claim right after being pressed or simply invited to show your OWN results or evidence) It's just that the relative difference is too small to alter reality in a meaningful way (and much less to invalidate my results):

 

https://www.lemon64.com/forum/viewtopic.php?t=69897&start=0

 

"Commodore 64 (PAL): 31.97, 30 with screen off (poke 53265,11), 34 if Return is held down."

 

While certainly NOT zero (as I disregarded as such), it will not change the material reality a single bit, and will not change the FACT that the A8 will run the tests (presented on this thread) substantially faster, any time of the day.

 

Since it is clearly evident that you have no real interest (whatsoever) in how well the Atari platform could really do (but, instead, how to enshrine anything C64-related, at every possible turn). you are more than welcome to run Bench64 on your C64 (with or without OS-driven interrupts, VIC-II or whatever you wish to enable or disable on its original config., with whatever Basic interpreter of your choice) and share with us YOUR own findings (at least, you will have the opportunity to participate in a meaningful way on this discussion, and who knows, we could even add those results to Maury´s table, too!)

 

Even better, I invite you to grab the .ATR I originally posted at the beginning of this thread (which you can perfectly open on your end), and hand-port any of the SIEVE assembly benchmarks I included there to your C64 assembler of choice, and show us all the way!

 

There's a great opportunity there for you to shine.

 

 

It's totally about ignorance, to quote yourself as an Atari fanboi:

 

20 hours ago, Faicuai said:

I for one am happy that the +4 has the ability to muster all of its firepower and mop the floor with the C64, at once. GOOD for it!!

You simply don't like the C64, it's that simple. As a result, like most zealots such as yourself, you're totally clueless when it comes to the C64's architecture. There's a reason Atari didn't run the A8 at the same clock speed as the Apple II at the time, and that's because it's early form of DMA isn't terribly efficient. If they had have run the A8 at the same clock speed as the Apple II, the A8 would have been slow as molasses.

 

That's all your proving by turning off DMA time and time again in literally every benchmark you ever run on the A8, you're proving unequivocally that the A8's DMA implementation isn't ideal in certain circumstances and you know it. Furthermore, your results are still invalid with DMA disabled.

 

I'm not at all interested in some pointless C64 vs Atari debate, we already know the results of an NTSC C64 as they're the basis for the benchmark. I'm highlighting, like others in this thread, that your results are invalid in the context of this benchmark. Furthermore, you stated there would be zero difference in C64 benchmarks with the screen off vs the screen on, now you state that the difference won't be zero (most likely after an extensive and desperate Google search on how the C64 actually works) but it won't change the material reality a single bit...

 

...So which one is it? Will it make a difference, or won't it make a difference? We know the difference will be nowhere near as substantial as the difference regarding screen off vs screen on considering the A8 and it's at times inefficient DMA implementation, as I honestly can't think of a single 8 bit machine that see's the kind of results with DMA on vs DMA off that you see under the A8 platform (bearing mind, I'm an A8 user myself). However, I can tell you for a fact that there is a difference, and considering a difference of just one point on the base NTSC C64 benchmark would skew the overall results due to the fact the NTSC C64 is the line in the sand regarding this benchmark, the results I'm seeing are quite interesting and actually highlight how Commodore improved on the A8's design while still allowing for the VIC-II to DMA with bus priority only when needed - At every other time both CPU and VIC-II share the bus no different to the Apple II.

 

I have the Bench64 results, I ran them yesterday. I'm just a little confused on your comments regarding ZERO difference suddenly swaying to not changing the basis for the benchmark one bit even though one point's difference will skew the results overall.

 

I'm not interested in the other benchmarks, Bench64 is adequate for the likes of this discussion.

Edited by Mazzspeed
  • Like 1
Link to comment
Share on other sites

1 hour ago, Mazzspeed said:

You simply don't like the C64, it's that simple. As a result, like most zealots such as yourself, you're totally clueless when it comes to the C64's

See?  ?

 

It does not take that much Atari praising... or even [Commodore non-C64] praising to get you lashing out with your cyclical "ignorant", "zealot", "clueless", "C64 greatness", yada, yada... Four (non-constructive, personally-directed) words right there, following a long babbling drivel, without a single piece of substance to enrich the discussion.

 

Nevertheless, I will do the homework for you. Quoting myself:

 

10 hours ago, Faicuai said:

While certainly NOT zero (as I disregarded as such), it will not change the material reality a single bit

Here's the Bench64 run with C64 screen turned off (fyi, we don't even need poking such commands on the A8, as it is controlled by embedded OS Interrupt / Keyboard handler, inherited for decades from the 1200XL OS):

 

990B2138-899E-4BA4-9990-AF2E1C1C6556.thumb.jpeg.85d5487b2c3b185bac367c65a5667e9e.jpeg

 

Re-normalizing the C64 benchmark to this new level, and re-computing BBC and Atari results, we get:

 

BBC: 189

A8 Altirra Basic+FP (via Bit3, Xep80, VBXE or OS DMA=off): 196

A8 TurboBasic: (via Bit3, Xep80, VBXE or OS DMA=off): 225

 

So there you have it. The C64 went from pretty-slow... to pretty-slow... At least, it is consistent, no surprises. (just don't start with your "fanboi", "ignorance" and all that gibberish...)

 

Also, pretty much in line with what we already saw, at a much lower-level:

https://litwr2.github.io/pi-spigot-benchmark/pi-spigot-benchmark.html

 

For your comfort and peace-of-heart, I can suggest Maury to normalize all Atari DMA=OFF results to 100/107 factor, if that makes you truly happy. The reality won't change, no matter how extensive your "VIC-II DMA greatness" advertising persists and how "poorly" it was implemented on Atari (without really stopping for a nano-second to think about the expensive RAM required to cope with non-blocking bus back in 1979, at speeds ~2Mhz)

 

We could have a much more interesting discussion if you had the skills to port the ASM code I posted to your C64 assembler of choice. That would be really fun, though, but I guess it is not your cup of tea.

 

So... moving on, now...

 

 

Link to comment
Share on other sites

23 hours ago, Mazzspeed said:

The VIC-II has a form of DMA that's technically an improvement on the A8's design.

Hardly. No matter what, the 6510 is limited to 1 MHz or less. In the A8 architecture, the programmer can choose between CPU dominance (up to 1.65 MHz) and DMA demands.

Edited by ClausB
  • Like 2
Link to comment
Share on other sites

2 hours ago, Faicuai said:

So there you have it. The C64 went from pretty-slow... to pretty-slow... At least, it is consistent, no surprises. (just don't start with your "fanboi", "ignorance" and all that gibberish...)

We already knew the rough speed of the C64 as the C64 is the basis for this benchmark with the screen enabled - The CPU performance of the C64 isn't up for debate, neither is the absolutely massive gains experienced on the A8 platform with DMA on vs DMA off - Your stupid idea that disabling DMA makes for a valid result in the context of the benchmark in question is what's up for debate. Furthermore, you stated that the C64 would see ZERO difference with the screen off, then you went and frantically did a Google search in order to try and substantiate your claims, only to find you were wrong. On top of that, all you've successfully done is proven just how early forms of DMA without chip memory are fairly flawed from a performance perspective.

 

So basically, considering the form of DMA used by the C64 with the VIC-II only taking bus priority when needed, the C64 is the more efficient machine clock for clock and still has outstanding graphics capabilities with dedicated color ram direct to the VIC-II.

 

PAL screen on:

 

oPkS6CK.jpg

 

PAL screen off:

 

OVr6aqo.jpg

 

That difference, is more than enough to skew the results - Hence the reason why the author of the benchmark specifically states no tricks are to be used. Normalizing the results simply proves what we already know, they still don't make your results valid. Your results with DMA off, as predictable as they are, are invalid in the context of this benchmark. Furthermore, you have plenty of scripts utilizing pokes to disable ANTIC, you've got scripts for a wide variety of stupid tasks, I've got them all here. If you disable the screen using your modified ROM keyboard shortcuts after the machine has booted, than, once again, your results are invalid considering the context of this benchmark. The C64 has a number of useful shortcuts under JiffyDOS, naturally disabling the screen isn't high on the priority list due to the fact the C64 doesn't suffer the extensive overheads regarding DMA as seen on the A8.

 

All you have proven is that in terms of overall architectural design, clock for clock, the C64 is the better machine.

 

1 hour ago, ClausB said:

Steve Wozniak, 1977.

To quote myself:

 

4 hours ago, Mazzspeed said:

the results I'm seeing are quite interesting and actually highlight how Commodore improved on the A8's design while still allowing for the VIC-II to DMA with bus priority only when needed - At every other time both CPU and VIC-II share the bus no different to the Apple II.

As far as the comment below is concerned:

 

1 hour ago, ClausB said:

Hardly. No matter what, the 6510 is limited to 1 MHz or less. In the A8 architecture, the programmer can choose between CPU dominance (up to 1.65 MHz) and DMA demands.

Faicuai has undeniably proven in this very thread that clock for clock the C64 is the more efficient machine. Naturally a machine running a 6502 at a higher clock speed is going to be faster, run that 6502 at 1Mhz or less in line with the C64, and the A8's going to struggle to do anything.

 

Essentially, if people are going to act like fanboi's and rant crap, I'm going to pull them up on it. It's obvious that Faicuai knows nothing about the C64's architecture unless pushed to do research, as evidenced by his frantic backpeddling in this very thread. This whole Commodore vs Atari thing is a laughable joke. As stated, considering it's age, the A8 is undoubtedly an impressive machine - However, considering the age of the C64, in many way's it's an improvement. As one would expect considering it's a slightly newer design.

Edited by Mazzspeed
  • Like 1
Link to comment
Share on other sites

8 minutes ago, Mazzspeed said:

The performance of the C64 isn't up for debate, neither is the absolutely massive gains experienced on the A8 platform with DMA on vs DMA off - Your stupid idea

933ED546-DAC3-4B3A-9111-33484DD754CF.thumb.jpeg.5e3cd63baa55e53444240f255fe9b3b5.jpeg

 

All that tree-howling.... It's all I am hearing from you, since many posts above...

 

The only imbecilic rant I have read so far is implying that exploiting the available resources on the A8 platform to better suit a specific task is "cheating".

 

Just grow the fuck up, for once, and move on.I promise, you will survive.

 

Link to comment
Share on other sites

28 minutes ago, Faicuai said:

933ED546-DAC3-4B3A-9111-33484DD754CF.thumb.jpeg.5e3cd63baa55e53444240f255fe9b3b5.jpeg

 

All that tree-howling.... It's all I am hearing from you, since many posts above...

 

The only imbecilic rant I have read so far is implying that exploiting the available resources on the A8 platform to better suit a specific task is "cheating".

 

Just grow the fuck up, for once, and move on.I promise, you will survive.

 

I'm not the only person in this thread telling you that running your A8 with DMA off is cheating, there's two others both stating the exact same thing.

 

Therefore, the only one howling in this thread is yourself. The only one that's highlighted the inefficiencies of the A8 platform is...

 

...Yourself.

 

So how about you swallow that bitter pill, take your own advice, and grow the fuck up. Because these arguments ended around thirty years ago, talk about holding a grudge. I should be thankful that's not a picture of a half naked chick, because that's the definition of childish.

  • Haha 1
Link to comment
Share on other sites

2 hours ago, Mazzspeed said:

I'm not the only person in this thread telling you that running your A8 with DMA off is cheating, there's two others

There is no two others (unless you want to deliberately fill vacant spots on that picture).

 

How do we know? Because on this (very same) thread, it has been already acknowledged that BOTH [DMA=ON] and [DMA=OFF] results should be reported in Bench64 results. Just like other (comprehensive) benchmarking attempts have done, as well. There is nothing new, nothing revolutionary with this (AS LONG AS it is clearly disclosed, instead of implied, which has ALSO been brought to my attention, and with which I completely agree).

 

Furthermore, when voice of wisdom steps on your tail and and bring to your attention how disparate your assertions could be (NOT mine), you prefer confronting such voices with infantile depictions of your opposing voice, and at whatever cost it takes to enshrine your own (favorable) opinion regarding the C64, even in a completely unsolicited manner. This pattern is cyclical, systematic, repetitive, and it clearly shows what your real standing is regarding these matters.

 

And to top it off, and to clearly illustrate how non-sensical your proposition could be, it turns out that my current environment (ran and operated with Atari products, through-and-through) requires DMA disabled to fully access the A8's CPU power-band, and thus operate correctly. This environment is, in turn, the most adept and effective at handling the way I interact with this platform and its resources, which is no different to the way I interacted with my former PCs., and command-driven workstations, in the past. It is what I know and what I enjoy the most, and anyone here could enjoy it in the exact same way as I do. 

 

If you do have a problem with this basic reality, then such problem resides solely inside of you (yours to keep).

 

There will not be any changes, whatsoever, to the results presented here. This (and any other test relevant to this thread) will also be run with DMA=OFF regardless of who feels traumatized for it, and  regardless of who (imaginarily) depicts it as "cheating".

 

P.E.R.I.O.D.

 

 

Link to comment
Share on other sites

1 hour ago, Faicuai said:

There is no two others (unless you want to deliberately fill vacant spots on that picture).

 

How do we know? Because on this (very same) thread, it has been already acknowledged that BOTH [DMA=ON] and [DMA=OFF] results should be reported in Bench64 results. Just like other (comprehensive) benchmarking attempts have done, as well. There is nothing new, nothing revolutionary with this (AS LONG AS it is clearly disclosed, instead of implied, which has ALSO been brought to my attention, and with which I completely agree).

 

Furthermore, when voice of wisdom steps on your tail and and bring to your attention how disparate your assertions could be (NOT mine), you prefer confronting such voices with infantile depictions of your opposing voice, and at whatever cost it takes to enshrine your own (favorable) opinion regarding the C64, even in a completely unsolicited manner. This pattern is cyclical, systematic, repetitive, and it clearly shows what your real standing is regarding these matters.

 

And to top it off, and to clearly illustrate how non-sensical your proposition could be, it turns out that my current environment (ran and operated with Atari products, through-and-through) requires DMA disabled to fully access the A8's CPU power-band, and thus operate correctly. This environment is, in turn, the most adept and effective at handling the way I interact with this platform and its resources, which is no different to the way I interacted with my former PCs., and command-driven workstations, in the past. It is what I know and what I enjoy the most, and anyone here could enjoy it in the exact same way as I do. 

 

If you do have a problem with this basic reality, then such problem resides solely inside of you (yours to keep).

 

There will not be any changes, whatsoever, to the results presented here. This (and any other test relevant to this thread) will also be run with DMA=OFF regardless of who feels traumatized for it, and  regardless of who (imaginarily) depicts it as "cheating".

 

P.E.R.I.O.D.

 

 

Well, here's two quotes highlighting that your DMA disabled results are, in fact, invalid as highlighted by the previously posted screenshot from the Bench64 GitHub page:

 

McafFJH.png

 

Quote 1:

On 6/3/2021 at 7:23 AM, Stephen said:

Correct, but you have a habit of always showing your benchmarks with DMA off and often times not mentioning it, to make the Atari seem faster than it is in "normal operation" by most people.  Consider a road rally where you're going for top MPG in matched stock cars.  You take one car, take all the tension off the rear drum brakes, over-inflate the shit out of the tires, and remove the air cleaner so you manage to squeeze out an extra 2MPG.  You can't claim the stock car gets better mileage.

 

And Quote 2:

On 6/3/2021 at 4:51 AM, Maury Markowitz said:

 

Sure, but then it's no longer the same benchmark. The conditions of the test are just as important as the code.

 

 

 

Furthermore, your A8 is not a two stroke motorbike and doesn't have a powerband, it also doesn't have a power valve or a carburetor. My claim is not a proposition, my claim has been highlighted by yourself, proven so impeccably by yourself and that claim is that clock for clock the C64 is the more efficient design compared directly to the A8 with it's early DMA implementation. But congratulations, at least you can win a BASIC benchmark running BASIC other than stock Atari BASIC.

 

If my opinion favors the C64, it's because you so diligently pointed out to everyone that the A8 is, clock for clock, the less efficient design if you actually want to see what's on the screen without some form of 80 column add on - Outstanding job! What I will say, is that in my opinion, I think you need to get over an argument that ended 30 years ago and realize that we are all retro enthusiasts. Some of my favorite retro platforms don't even have graphical capability. However, as an A8 owner and user, I understand what Jay Miners team were doing with the technology and cost restraints present at the time and can definitely appreciate the machine - I love my A8 and C64 equally, I'm just intolerable of bullshit.

 

Your environment does not require ANTIC when using your XEP80, stop manipulating any context regarding DMA, your mysterious mincing of words is becoming tiring. If ANTIC is running, you are effectively running a clock speed of about 1.3Mhz due to ANTIC steeling precious clock cycles.

 

Dear Gawd. Technically speaking it's highlighted that Bench64 doesn't even run on the A8 under the BASIC environment the author intends you to run. Let...It...Go.

 

On the upside, at least you're learning new things about differing architectures of the time.

 

06kvgWj.png

Edited by Mazzspeed
Link to comment
Share on other sites

On 6/3/2021 at 12:17 AM, Mazzspeed said:

for the benchmark to be meaningful

LOL- are benchmarks ever really meaningful?

 

No-one ever bought a computer in order to run benchmarks on it, and they tell you next to nothing about what you can actually use or enjoy that computer for...  So much angst! So little point!

 

Bill Wilkinson called it right back in 1985: 'Well, what does all this long-winded discussion boil down to? Two simple points: (1) Always presume that a benchmark program is worth slightly less than the paper it is printed on. (2) If you want to do number crunching on your Atari computer (against my best advice), go out and buy the Newell Fastchip. (And it won't hurt to try some other languages.)'

 

If this was true in 1985, how much more so now when these archaic machines, even more than then, represent only hobbyist fun?

 

If you genuinely have need of performing abstract processor-intensive calculations, honestly why on earth would you use 50 year old hardware to do it?  ?

 

Bitcoin mining on the A8, anyone?

 

 

 

Edited by drpeter
  • Like 1
Link to comment
Share on other sites

13 minutes ago, drpeter said:

LOL- are benchmarks ever really meaningful?

 

No-one ever bought a computer in order to run benchmarks on it, and they tell you next to nothing about what you can actually use or enjoy that computer for...  So much angst! So little point!

 

Bill Wilkinson called it right back in 1985: 'Well, what does all this long-winded discussion boil down to? Two simple points: (1) Always presume that a benchmark program is worth slightly less than the paper it is printed on. (2) If you want to do number crunching on your Atari computer (against my best advice), go out and buy the Newell Fastchip. (And it won't hurt to try some other languages.)'

 

If this was true in 1985, how much more so now when these archaic machines, even more than then, represent only hobbyist fun?

 

If you genuinely have need of performing abstract processor-intensive calculations, honestly why on earth would you use 50 year old hardware to do it?  ?

 

 

 

 

I couldn't agree more.

 

Bit bashing an old 6502 (6510) based machine is a total waste of time when there are better ways to do things using modern upgrades. This is one area where the C64 excells due to it's architecture, most likely the reason outright CPU performance wasn't a priority when the C64 was designed.

 

I have never felt limited by the performance of my C64.

Edited by Mazzspeed
Link to comment
Share on other sites

1 minute ago, drpeter said:

 

Ha Ha, not sure I would be using any retro machine, upgraded or not, to mine for bitcoins ?

You wouldn't use the new Bitcoin miner for the C64?

 

Neither would I!

 

However, some of the modern upgrades for both machines are very impressive. If such upgrades were available in the day I would have grabbed them In a heartbeat.

Link to comment
Share on other sites

3 hours ago, Mazzspeed said:

Bitcoin miner for the C64

Holy cow- you mean there is such a thing!?

 

How long would it likely take the entire residual world population of C64's to find a single bitcoin, and how much electricity would it consume, I wonder?

  • Haha 1
Link to comment
Share on other sites

7 hours ago, Mazzspeed said:

Well, here's two quotes highlighting that your DMA disabled results are, in fact, invalid

That is FALSE. Citing from GitHub:

 

" Reporting results

  1. Please use the machine exactly as it would appear when turned on. Tricks like turning off interrupts to get better results should not be done."

  • What does TURNED ON mean? What state? What condition? 
  • When we "turn on" the Atari, there is no Turbo Basic anywhere to be seen!! On that (dumb-ass) basis, we should warn Maury to stop wasting his time testing ALL other interpreters (!!) ?
  • When the GitHub author turns on his "glorious MinZ v1.1 (36.864 Z180, CP/M 2.2, BBC BASIC [Z80] v3)" WHERE is BBC Basic for Z80 (which I also have for CP/M 2.2 on the IndusGT? When I turn on my CP/M computer, there is no CP/M or BBC/Basic to be seen anywhere (!!) Does "turned on" means "after being booted?" Because if not, how does the bizarre MinZ comes into the picture? ?
  • My system boots fully-automatically (entirely SDX-driven) into 80-cols. session, directly from a stack of SDX drivers loaded before getting control back at command prompt for the first time! So where exactly is that I must define "turned on" here? How is this different from booting the MinZ? ??
  • ANSWER: "turned on" stems from the author's resentment regarding how ClockSp benchmark is simply defined: " (...) ClockSp is calibrated so that a BBC model B with most interupts turned off gives 2.00MHz". He thinks that turning off most interrupts makes look BBC's Basic "deliberately" better: "(...) Assumes some system tweaking to make the BBC Micro appear slightly faster than its default setting..."  ??

 

 

7 hours ago, Mazzspeed said:

Your environment does not require ANTIC when using your XEP80, stop manipulating any context regarding DMA

This (third) time, there is no need to wait for wisdom to kindly kick you around, as it is already written, and BEFORE driving the XEP at ultra-speed...  And guess who were involved... ?

 

Quoting myself: " (...) my current environment (ran and operated with Atari products, through-and-through) requires DMA disabled to fully access the A8's CPU power-band, and thus operate correctly "

 

Here you go (in case you forgot your milk-and-pijamas before going to bed).

 

 

"Won't ever run correctly on Atari BASIC, because it doesn't have user- defined functions. Soz, Maury … ☹"

 

It turns out that it DOES RUN, and with a penalty factor (on Atari runs) of up to x(1/1.5) during execution of emulated DEF calls, as measured already in MS-Basic by running the core calls with DEF or via [gosub/return/assignment] emulation. It's just that the Author could not make it run, because he defeated his very own "portability" goal, the one he explicitly complained about BBC-Basic benchmarks !! ??

 

 

 

  • Haha 1
Link to comment
Share on other sites

10 hours ago, Mazzspeed said:

That difference, is more than enough to skew the results

 

Normalizing Atari results to the please the PAL-c64 princess (by factor of 100/103)

 

BBC Miicro:                   202 (original), now 196

Atari Altirra Basic + FP: 209 (original). now 203

Atari TurboBasic:           240 (original), now 233.

 

I'm sure she now feels relieved of not being left so behind. 

 

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...