Benchmarking the Atari 800XL

[zbyti]

19 minutes ago, vol said:

Do not forget to turn the plus4 screen off by POKE65286,11.  It can be turned on later by POKE65286,27.
It is also possible to get the additional 25% speed boost for the PAL Plus4.

OK, I'll check it, in benchmark (PAL) above was:

 

{$ifdef c4p}
  poke($FF06,0);
{$endif}
{$ifdef atari}
  poke($22F,0);
{$endif}
// code...
{$ifdef c4p}
  poke($FF06,$1B);
{$endif}
{$ifdef atari}
  poke($22F,$22);
{$endif}

///EDIT

 

poke($FF06,11); give me the same result as poke($FF06,0); on PAL machine.

Edited February 10, 2021 by zbyti
11

[vol]

On 2/8/2021 at 4:38 PM, drac030 said:

In my view it is like comparing a car with a steam engine vs a car with internal combustion engine. A state-of-the-art steam car may at places, in special circumstances, outperform a sligtlhy older internal combustion one (65C816 is 6 years later than m68k), but it is the latter one that is superior technology. This is, among other things, why Amiga, Atari, Apple went for m68k in middle '80s, and it was not accident.

Your ideas about the 68000 advantages over the 65816 sound quite plausible but they are too abstract and theoretical.  We have one example (Sieve of Eratosthenes) where the 65816 shows that it requires 2 times less cycles than the 68000.  Let me show you one more.  I have another project which might be used for benchmarking - you can find out there that the NMOS 6502 requires even more than 2 times cycles less than the 68000.  Indeed you can think that my code for the 68k is less optimized but Xlife-8 shows performance matches the best Amiga cellular automaton programs and this shows that code of Xlife-8 is quite optimized for the Amiga.
I am sure that for some data processing the 68000 can be faster than 65816 but I can assume that such processings are rather untypical.
The byte transfer is a very common and important operation because it is one of the base operation for text strings.  The 65816 is about two times faster for this op than the 68000.
However there is something weird about the 6502.  Computer companies wanted to be rid of it in the 80s.  IMHO it was caused by still unknown reasons.  I can only propose a hypothesis that the 6502 was too fast and cheap and could crash several respectable companies.  The 68000 was a good choice and the lack of development of the 6502 for 7 years had also a strong effect.

Edited February 11, 2021 by vol

[vol]

16 hours ago, Faicuai said:

FYI, just got results for Atari 800 / Z80 (IndusGT+64KB RamCharger, CP/M v2.2):

 

  100 digits:      1.65s

1000 digits:   145.83s

3000 digits: 1301.59s

MAX digits:  8292

 

Results are verifiable on ALTIRRA, as it very nicely supports and emulates Indus/GT roms and CP/M operation.

 

You may want to update your database with these (interesting) results.

What are interesting results!  They match a 4 MHz system.  How is it possible?!  The Commodore 64 people had to use a 1 MHz Z80 cartridge, the Commodore 128 people were allowed to use the Z80 at effective 1.7 MHz.  What is your system exactly?  Would you like to send me a link to its description?  Thank you.

Edited February 11, 2021 by vol

[vol]

16 hours ago, Faicuai said:

Getting 508 ticks on Atari/NTSC.

 

The "canonical" version of SIEVE's Byte can run in 444 ticks, NTSC, as I attached on this thread, before.

 

Nevertheless, pretty good time, and interesting difference between +4 and Atari, though...

 

The difference between timings shows that the compiler wrongly counts timings for one system.  We have 1.2 times excess that means that 60 and 50 Hz are mixed up somewhere.  Do you know that the Plus4 (as the C64) system software timers are 60 Hz for both PAL and NTSC models?

Edited February 11, 2021 by vol

[vol]

On 2/8/2021 at 4:38 PM, drac030 said:

Well.

I can also ask you to read this material which has a cite from a very good hardware engineer 

Quote

Readers are always dazzled by the speed.  Motorola talks about 12 megahertz. The Apple [Macintosh] computer has about 7 megahertz with the 68000. The equivalent speed on the 65816 would be in the  neighborhood of 2 to 3 megahertz.
In other words, a 2- to 3-megahertz Apple  [II-series] has the same kind of performance as an 8-megahertz Macintosh.

 

[zbyti]

3 hours ago, vol said:

The difference between timings shows that the compiler wrongly counts timings for one system.  We have 1.2 times excess that means that 60 and 50 Hz are mixed up somewhere.  Do you know that the Plus4 (as the C64) system software timers are 60 Hz for both PAL and NTSC models?

Let's not blame the compiler, I didn't know that the timer on C+4 (PAL) is not changed 50 times per second :] I have to check it out.

[zbyti]

Yep... SIEVE NTSC blanked screen

 

 

EDIT: Atari800 NTSC ML blanked screen:

 

sieve.xex sieve_fast.asm

Edited February 11, 2021 by zbyti

[Cyprian]

sometimes ago I did a test on the Atari XL and the C64, where I measured LZ4 depacking time. Test was done with the same screen resolution on both platforms 320x200px 1bit per pixel.

The test generates a sound peak on the beginning and the end of the test. I measured in Audacity the distance between those peaks in 44 100 Hz samples.

C64 took: 299 791 samples;

XL: 228 912 samples.

It means in that video mode, the XL has 130,96% power of the C64, and  the C64 76,36% of the the XL.

 

Attached you can find binaries and source code for both platforms. Just press space to begin the test.

 

LZ4 Test_A8_C64_v2.zip

[+Stephen]

6 hours ago, vol said:

What are interesting results!  They match a 4 MHz system.  How is it possible?!  The Commodore 64 people had to use a 1 MHz Z80 cartridge, the Commodore 128 people were allowed to use the Z80 at effective 1.7 MHz.  What is your system exactly?  Would you like to send me a link to its description?  Thank you.

The Indus GT disk drive uses a Z80 CPU running at 4.0MHz and in order to run CP/M, it must have the 64kB RAM expansion card.  The original was DRAM, but there now exists a new SRAM based card.  I do not think that will change any of the speeds at all.

[Faicuai]

8 hours ago, vol said:

What are interesting results!  They match a 4 MHz system.  How is it possible?!  The Commodore 64 people had to use a 1 MHz Z80 cartridge, the Commodore 128 people were allowed to use the Z80 at effective 1.7 MHz.  What is your system exactly?  Would you like to send me a link to its description?  Thank you.

 

In a nutshell, it is possible because of the abstraction provided by SIO and its bus, which is how the Atari (and its floppy drive, The Indus/GT) communicate.

 

As far as I have seen, used and tested, The Indus/GT is gram-by-gram, byte-for-byte, out-of-the-box, the best drive ever made for the Atari. I got it with my 800XL in 1984 (when jumping late from my 400).

 

In the above simple (yet effective) arrangement, the Indus/GT leverages its built-in processing power with its embedded ability to communicate bi-directionally over Atari's SIO bus. With this setup in mind, combined with a 64KB drop-in, plug-and-play RAM board that connects on the right-side pin-header of the Indus/GT MoBo (takes 2mins to install), the drive's CPU has now a full 64KB address space to work, which it will use not only to implement a sophisticated sector-cache facility, but also execute CP/M 2.2, when instructed to do so.

 

The Indus/GT can be "bootstrapped" into CP/M by a special combination of two keys on its front-panel and a CP/M formatted floppy with its corresponding BIOS. On the Atari end, what is needed is a terminal-program that will leverage the Atari's graphical capabilities to emulate an 80-col device, with very fast scrolling, and full bi-directional support as well. It will not only provide terminal facilities to the Indus/GT comouter, but will also put at its disposal Atari's storage facilities (even from a PBI-mounted .ATR!!!) so you can exchange files in and out of CP/M at will (which is how I loaded your generic CP/M Pi-bench compile into the Indus).

 

And you can see, it runs at full 4Mhz, and it is no different than BBC's Z80 modules, just that those hang from the Tube, instead. FYI, Altirra (the BEST and most complete 8-bit emulation package I know in existence) emulates the Indus/GT down to its rom level, and you can do there everything I did on my pictured A800 setup.

 

Isn't that cool? Now you know why SIO is the closest related precursor of what you know today as USB, both designed by the legendary Joe DeCuir... all in 1979 !!!

 

????

Edited February 11, 2021 by Faicuai

[Mazzspeed]

4 hours ago, Faicuai said:

And you can see, it runs at full 4Mhz, and it is no different than BBC's Z80 modules, just that those hang from the Tube, instead. FYI, Altirra (the BEST and most complete 8-bit emulation package I know in existence) emulates the Indus/GT down to its rom level, and you can do there everything I did on my pictured A800 setup

The Tube interface is vastly different to the SIO bus and technically superior, the Tube interface doesn't effectively use the machine as a terminal.

 

However, this is interesting. It would be really interesting to see what the Commodore SFD 1001 could pull with it's dual 6502's assuming you could find a ramboard that would suit it and the software was optimized for it. Nice result.

Edited February 11, 2021 by Mazzspeed

[Faicuai]

1 hour ago, Mazzspeed said:

The Tube interface is vastly different to the SIO bus and technically superior, the Tube interface doesn't effectively use the machine as a terminal.

 

However, this is interesting. It would be really interesting to see what the Commodore SFD 1001 could pull with it's dual 6502's assuming you could find a ramboard that would suit it and the software was optimized for it. Nice result.

Adding more color (and precision):

 

Effectively speaking, both Z80s (in the BBC-Micro and Atari setups) are isolated from the host systems. Or, said in different terms, those Z80s have their own RAM, their own BIOS/OS, their own clock, etc., which pretty much explains the very-very close exec. times between Atari and BBC, as well as max. supported bench depth. (which is impossible, say, on BCC's on-board RAM resources).

 

It is more than clear that the tube is a high-speed bus, designed with its own glue / exchange supporting-logic but, at the end of the day, it keeps host system-bus and expansion bus essentially separate. That effective separation between the systems  (and final results) are the similarities I was referring to.

 

Notably, even with a completely abstracted bus-arrangement like SIO between Atari and Indus/GT, I can afford the luxury of getting directories, renaming, copying, and text-converting files existing on the Atari's .ATR images (attached via PBI), without ever leaving the CP/M environment, and while the Atari CP/M terminal is running. I had the fortune to meet / exchange messages directly with the developer of such tools. 

 

[Mazzspeed]

6 minutes ago, Faicuai said:

Adding more color (and precision):

 

Effectively speaking, both Z80s (in the BBC-Micro and Atari setups) are isolated from the host systems. Or, said in different terms, those Z80s have their own RAM, their own BIOS/OS, their own clock, etc., which pretty much explains the very-very close exec. times between Atari and BBC, as well as max. supported bench depth. (which is impossible, say, on BCC's on-board RAM resources).

 

It is more than clear that the tube is a high-speed bus, designed with its own glue / exchange supporting-logic but, at the end of the day, it keeps host system-bus and expansion bus essentially separate. That effective separation between the systems  (and final results) are the similarities I was referring to.

 

Notably, even with a completely abstracted bus-arrangement like SIO between Atari and Indus/GT, I can afford the luxury of getting directories, renaming, copying, and text-converting files existing on the Atari's .ATR images (attached via PBI), without ever leaving the CP/M environment, and while the Atari CP/M terminal is running. I had the fortune to meet / exchange messages directly with the developer of such tools. 

 

Using the Indus like that is an impressive way of thinking outside the box, with smart drives being a thing it's a shame more people didn't think of the possibilities.

 

Tube still uses system I/O including disk access controlled by the BBC itself, your implementation literally is the disk access - Which is impressive thinking in itself.

[vol]

On 2/11/2021 at 7:05 PM, Faicuai said:

 

In a nutshell, it is possible because of the abstraction provided by SIO and its bus, which is how the Atari (and its floppy drive, The Indus/GT) communicate.

 

As far as I have seen, used and tested, The Indus/GT is gram-by-gram, byte-for-byte, out-of-the-box, the best drive ever made for the Atari. I got it with my 800XL in 1984 (when jumping late from my 400).

Thank you very much for your information.  The Indus/GT was a really super-thing!  I thought that such intellectual disk drives were available only from Commodore.  The Indus/GT capability to run CP/M is astonishing!  I am going to make a special pi-spigot variant for it.  However I need help.  Is it possible to get timings in a program running under CP/M?  Maybe it is possible if a CP/M program asks the Atari host?  Anyway I need information about details how to get a timer value in Atari CP/M program code.  If I understood correctly I can use the Altirra emu to run CP/M, didn't I?  I have downloaded this emu and run it under my old Microsoft Windows XP under VirtualBox. It is really a very good emu.  However under my old Windows help system doesn't work. I have been able to find Indus/GT ROM and CP/M disk images but how to combine all these things and to start CP/M?  I booted the terminal disk, run E for 80 column mode and got an empty screen. The instruction says "After the terminal program has been booted, insert the CPM disk into the Indus and while holding down the "drive type" button, press the "error" button; this will boot up CPM, which will ask you to hit the return key to continue. At this point your are booted up and running CPM".  It is too cryptic for me, where can I find those two buttons?  Are they on Atari keyboard or they are special buttons on the drive?
I am also curios about 80-column mode.  Does it use 4x8 font matrix?

[Faicuai]

17 minutes ago, vol said:

Thank you very much for your information.  The Indus/GT was a really super-thing!  I thought that such intellectual disk drives were available only from Commodore.  The Indus/GT capability to run CP/M is astonishing!  I am going to make a special pi-spigot variant for it.  However I need help.  Is it possible to get timings in a program running under CP/M?  Maybe it is possible if a CP/M program asks the Atari host?  Anyway I need information about details how to get a timer value in Atari CP/M program code.  If I understood correctly I can use the Altirra emu to run CP/M, didn't I?  I have downloaded this emu and run it under my old Microsoft Windows XP under VirtualBox. It is really a very good emu.  However under my old Windows help system doesn't work. I have been able to find Indus/GT ROM and CP/M disk images but how to combine all these things and to start CP/M?  I booted the terminal disk, run E for 80 column mode and got an empty screen. The instruction says "After the terminal program has been booted, insert the CPM disk into the Indus and while holding down the "drive type" button, press the "error" button; this will boot up CPM, which will ask you to hit the return key to continue. At this point your are booted up and running CPM".  It is too cryptic for me, where can I find those two buttons?  Are they on Atari keyboard or they are special buttons on the drive?
I am also curios about 80-column mode.  Does it use 4x8 font matrix?

That is very nice!!! To see the Atari / IndusGT combo. getting its own test.

 

I am not sure you will get timing facilities when running CP/M bios for Indus/GT Z80. I have scanned the memory looking for mirror / timing cells, and never found them. However, a "START" and "END" bell or screen message will do it. There is no concern regarding active-screen, DMA on or off, etc. The Z80 is in FULL command of Indus/GT resources. It is a very simply setup, indeed.

 

I will prepare an .ATR for you, with what you need (give some time). We will guide you. Altirra will allow you to enter Indus-console buttons, to bootstrap CP/M, exactly as you do it with my real drives. After than, everything is relatively easy. As far as I have seen, there is nothing out-there like Altirra and you should stick to it, as much as you can. Very, very powerful and complete. 

Edited February 12, 2021 by Faicuai

[vol]

7 minutes ago, Faicuai said:

I will prepare an .ATR for you, with what you need (give some time). We will guide you. Altirra will allow you to enter Indus-console buttons, to bootstrap CP/M, exactly as you do it with my real drives. After than, everything is relatively easy. As far as I have seen, there is nothing out-there like Altirra and you should stick to it, as much as you can. Very, very powerful and complete. 

Thank you very much.  However without information how to get timings it will be no use.  Can we somehow reach the host memory?

[Faicuai]

Just now, vol said:

Thank you very much.  However without information how to get timings it will be no use.  Can we somehow reach the host memory?

There maybe a way, but I guess it will have to be at BIOS level, to exchange such info. with host-terminal?

 

It should not be a problem, though. Hand-timing is perfectly acceptable, as long as it can be verified by any user... unless the BENCHMARK algorithm uses system-timing as a computational input, just like an active variable of the algo. ? That would be strange...

[vol]

14 hours ago, Faicuai said:

There maybe a way, but I guess it will have to be at BIOS level, to exchange such info. with host-terminal?

 

It should not be a problem, though. Hand-timing is perfectly acceptable, as long as it can be verified by any user... unless the BENCHMARK algorithm uses system-timing as a computational input, just like an active variable of the algo. ? That would be strange...

Maybe I should start a new topic about how to get access to the host resources from the Indus GT...  The BBC Micro CP/M systems have detailed docs about how to access the host resources.  So maybe later we can discover how to do the same things with the Indus.

Anyway I am trying to run CP/M and I am not successful.  I have installed the Indus GT device, attached ROM for it.  It can boot from the Indus Master disc but it refuses to boot from the Terminal disk.  The system boots from this disk when I disable the Indus.  When the Indus is enabled it requires something extra to boot from the Terminal disk.  Once I accidentally could boot it and then start booting CP/M but after some progress all was stopped.

 

You know every program in my project must satisfy 4 requirements and one of them is capability to measure time.

Edited February 13, 2021 by vol

[vol]

19 hours ago, Faicuai said:

I will prepare an .ATR for you, with what you need (give some time). We will guide you. 

I have just found out information that CPM disks in ATR format are unreliable, one needs to use XFD-format disks.  Would you like to help with such a disk image?  And I am still stuck in problem of booting from the terminal disk.  

Edited February 13, 2021 by vol

[Faicuai]

1 hour ago, vol said:

I have just found out information that CPM disks in ATR format are unreliable, one needs to use XFD-format disks.  Would you like to help with such a disk image?  And I am still stuck in problem of booting from the terminal disk.  

Away from my retro-desk since yesterday afternoon. Just enjoying life a bit... ;-)

 

Will help you with those images (you need to fix sector 1-3 because they are written always as 128bytes even on  256bytes/sec DD images). That's why your boot is stalling.

 

Ince after that you should be on your way. On Altirra, use "console switches" to press Indus/GT buttons.

 

Cheers!

[vol]

1 hour ago, Faicuai said:

Away from my retro-desk since yesterday afternoon. Just enjoying life a bit...

 

Will help you with those images (you need to fix sector 1-3 because they are written always as 128bytes even on  256bytes/sec DD images). That's why your boot is stalling.

 

Ince after that you should be on your way. On Altirra, use "console switches" to press Indus/GT buttons.

 

Cheers!

Thank you!  I have been able to find a thread on this forum where I get the required image.  But it is something strange that I still can't normally boot from the terminal disk.  Maybe there is some little trick for this?

The Atari is quite an interesting system to explore.

Cheers!

[+Stephen]

29 minutes ago, vol said:

Thank you!  I have been able to find a thread on this forum where I get the required image.  But it is something strange that I still can't normally boot from the terminal disk.  Maybe there is some little trick for this?

The Atari is quite an interesting system to explore.

Cheers!

Everything you need you can find here:
http://trub.atari8.info/index.php?ref=indus_cpm_en

 

[vol]

29 minutes ago, Stephen said:

Everything you need you can find here:
http://trub.atari8.info/index.php?ref=indus_cpm_en

 

Thank you but it is rather outdated information, this thread is much better.

I have finally persuaded the terminal disk to boot.  I have to set the Indus drive as D2: and boot the terminal disk from D1: which is set as a generic Atari drive.

So CP/M started for me!  However any disk error hangs the system.  

Edited February 13, 2021 by vol

[Faicuai]

On 2/13/2021 at 10:47 AM, vol said:

Thank you!  I have been able to find a thread on this forum where I get the required image.  But it is something strange that I still can't normally boot from the terminal disk.  Maybe there is some little trick for this?

The Atari is quite an interesting system to explore.

Cheers!

Here: