Benchmarking the Atari 800XL

[vol]

1 hour ago, Faicuai said:

It does not run.

 

Well, not in SDX. It kills it immediately.

Please tell me about a value at $e-f (BASTOP) on your system and I build the code for it.

[drac030]

19 minutes ago, vol said:

Your code uses $347-$348.

Correct:

 

+ICBLL   = $0348

 

into

 

+ICPTL   = $0346

 

and it will be fine.

 

Please tell me about a value at $e-f (BASTOP) on your system and I build the code for it.

 

I hope you realize that this value and also the amount of memory available over it will be different depending on the particular Atari setup and even the BASIC interpreter used...

 

Edited January 30, 2021 by drac030

[vol]

9 minutes ago, drac030 said:

Correct:

+ICBLL   = $0348

into

+ICPTL   = $0346

and it will be fine.

I hope you realize that this value and also the amount of memory available over it will be different depending on the particular Atari setup and even the BASIC interpreter used...

 

Thank you it works now.

I have asked for a particular system BASTOP-value.  The program changes MEMTOP and uses its old value to calculate the total amount of memory which the program can use.  So I only need the value of BASTOP.

[vol]

BTW should I use LDX #0 before RTS in the new OUTCHAR routine?

[dmsc]

Hi!

1 minute ago, vol said:

BTW should I use LDX #0 before RTS in the new OUTCHAR routine?

Because the IOCB#0 could be redirected (for example, to a file). The value of the X register then is the IOCB you are calling - #0 in this case.

 

About BASTOP, the whole reason of the existence of BASTOP is that it is not constant - it depends on the specific DOS used (many to choose from), the BASIC interpreter and the current program. You should not depend on that location having a fixed value.

 

Have Fun!

[vol]

4 minutes ago, dmsc said:

Hi!

Because the IOCB#0 could be redirected (for example, to a file). The value of the X register then is the IOCB you are calling - #0 in this case.

 

About BASTOP, the whole reason of the existence of BASTOP is that it is not constant - it depends on the specific DOS used (many to choose from), the BASIC interpreter and the current program. You should not depend on that location having a fixed value.

 

Have Fun!

Thank you!  So is it the safe lowest address from which it is possible to load ML-code?  The program assumes BASTOP at $8xx now.  Of course, it is about a value after NEW or reset.

[drac030]

It is difficult to come with a safe value for BASIC, all this depends how much stuff you have loaded at the MEMLO.

 

For example, on my system PEEK(14)+256*PEEK(15) after NEW gives 5320. But it is pretty low value and on other systems may be much higher. It can also be lower.

[Faicuai]

4470 (d) here, right after landing on READY prompt (no basic source loaded).

 

That's on SDX, w/ DOSKEY and ENV drivers. E: acceleration is dedicated / embedded on system ROM, and SIO via ROM / PBI.

 

Atari DOS, on the other hand, is a freaking LOMEM hog !!!

[vol]

I've just uploaded version 3 of the program.  It uses a portable OUTCHAR now and sets MEMTOP at $1907.  So BASTOP after its loading will be $1902 for drac030's system and that leaves only 5 bytes free.  So it may cause problems. However Faicuai's system should work nice now.

Moving MEMTOP up leaves less memory for π-digits, now the program can print only 3916 digits when its previous version can print 4356.

[Rybags]

Refresh on C64 AFAIK never steals cycles.  Many accesses on the C64 are transparent since the CPU runs at half the relative speed of the video generation compared to the Atari.

 

You can alter the refresh cycle generation on the Atari but at the cost of losing most of the cycles to the character and map fetches.  With programing tricks you can make 240 badlines which disables the bulk of the refresh cycles in a frame.

[vol]

30 minutes ago, Rybags said:

Refresh on C64 AFAIK never steals cycles.  Many accesses on the C64 are transparent since the CPU runs at half the relative speed of the video generation compared to the Atari.

 

You can alter the refresh cycle generation on the Atari but at the cost of losing most of the cycles to the character and map fetches.  With programing tricks you can make 240 badlines which disables the bulk of the refresh cycles in a frame.

This explains why the C64:Atari800 performance ratio is about 1:1.65 and not 1:1.75

[drac030]

5 hours ago, vol said:

So BASTOP after its loading will be $1902 for drac030's system and that leaves only 5 bytes free.  So it may cause problems.

It works.

 

5 hours ago, vol said:

Moving MEMTOP up leaves less memory for π-digits, now the program can print only 3916 digits when its previous version can print 4356.

This actually depends on the BASIC interpreter used. On my system I can still print up to 5228 digits.

 

Okay, my results number 1:

 

100 digits - 0.16

1000 digits - 15.26

3000 digits - 137.14

5228 digits - 416.80

 

My results number 2:

 

100 digits - 0.10

1000 digits - 10.46

3000 digits - 94.12

5228 digits - 285.98

 

 

[vol]

1 hour ago, drac030 said:

Okay, my results number 1:

 

100 digits - 0.16

1000 digits - 15.26

3000 digits - 137.14

5228 digits - 416.80

 

My results number 2:

 

100 digits - 0.10

1000 digits - 10.46

3000 digits - 94.12

5228 digits - 285.98

 

 

It seems you have a kind of SuperCPU for your Atari, the timings are almost identical.  So if you use special version of code for the 65816 your systems results will even become approx. 50% better.

Thank you very much for your help, the Atari is a very interesting system.

Edited January 31, 2021 by vol

[drac030]

56 minutes ago, vol said:

It seems you have a kind of SuperCPU for your Atari, the timings are almost identical.

Okay, so some technical information now:

 

1) the BASIC interpreter I used is U-BASIC. It is not very much more than the ordinary Atari BASIC recompiled so that it runs in the memory under the OS instead of hogging the cartridge area. You can run it on vanilla 800XL or 65XE (not on 800 - it requires a 64k machine).

 

The maximum memory (out of the first 64k as the benchmark rules stipulate) I can get here in this BASIC without falling back to the cassette recorder (which I do not have) as the only storage is:

 

? PEEK(14)+256*PEEK(15) = 4375

? FRE(0) = 43803

 

It would however be better if the benchmark could avoid involving a BASIC interpreter and be run directly from the CP.

 

2) the hardware: PAL Atari 65XE with 320k RAM and Rapidus Accelerator. The results number 1 is the regular board, 65C816/20 MHz. The results number 2 is a prototype where the CPU is clocked at 40 MHz. So yes, this is "a kind of SuperCPU for Atari" as you correctly guessed.

 

This however raises questions about the SuperCPU results listed in your table. Namely, what is the difference between the entries 31/34 on one side, and 44/45 on the other side? Both list 65C816/20 MHz, but as you see, 31/34 are actually faster (by about 10%) than a 65C816/40 MHz. So how this result has been achieved on the SuperCPU board or maybe it is a mistake and 31/34 are really faster than the 20 MHz listed?

 

56 minutes ago, vol said:

So if you use special version of code for the 65816 your systems results will even become approx. 50% better.

If you can compile the main module for the 65C816 target, we could see.

Edited January 31, 2021 by drac030

[Faicuai]

18 hours ago, vol said:

I've just uploaded version 3 of the program.  It uses a portable OUTCHAR now and sets MEMTOP at $1907.  So BASTOP after its loading will be $1902 for drac030's system and that leaves only 5 bytes free.  So it may cause problems. However Faicuai's system should work nice now.

Moving MEMTOP up leaves less memory for π-digits, now the program can print only 3916 digits when its previous version can print 4356.

It works!

 

Now getting 1.85s for first 100 digits, and 184.9465s for 1000 digits... This is in "console mode", output via XEP80 Ultra-drivers (80-cols) and NO blank-screen (XEP80 drivers service (and keep) E: driver at full 6502 tilt, all the time).

 

All the above with Atari 800/Incognito (RAM/ROM/HD board) and SDX dos.

[Mazzspeed]

The PAL Plus/4 can be set to NTSC mode by disabling the screen which sets the CPU frequency to 2.22Mhz - It's actually one of the fastest 6502 based systems for raw calculations in this mode.

 

I don't know whether something related to this fact could be affecting your results, but it may be something to consider?

Edited February 1, 2021 by Mazzspeed

[Mazzspeed]

21 hours ago, vol said:

This explains why the C64:Atari800 performance ratio is about 1:1.65 and not 1:1.75

In relation to the C64, the 6510 and the VIC-II access memory in an interleaved fashion, the CPU on one clock phase, the VIC-II on the other. In comparison, ANTIC accesses memory via DMA and needs to halt the processor to access memory, which I assume drops overall processor efficiency. In comparison the VIC-II only steals clock cycles from the 6510 when necessary via the AEC signal on the 6510, making this comment perfectly plausible. In fact the 6502 in the A8 could be running at a comparative ~1.3Mhz in certain scenario's.

Edited February 1, 2021 by Mazzspeed

[Rybags]

56 minutes ago, Mazzspeed said:

The PAL Plus/4 can be set to NTSC mode by disabling the screen which sets the CPU frequency to 2.22Mhz - It's actually one of the fastest 6502 based systems for raw calculations in this mode.

 

I don't know whether something related to this fact could be affecting your results, but it may be something to consider?

 

I'm fairly sure that doesn't happen - the screen blanking just prevents the cycles lost for screen generation in the same fashion as setting DMACTL to 00 on the Atari - the PAL/NTSC setting would just toggle between 312/262 scanlines at ~ 50 & ~ 60 FPS.  There's no valid reason for the CPU to overclock to that speed (though it does seem somewhat close to half the PAL colour clocking rate)

[Mazzspeed]

Just now, Rybags said:

 

I'm fairly sure that doesn't happen - the screen blanking just prevents the cycles lost for screen generation in the same fashion as setting DMACTL to 00 on the Atari - the PAL/NTSC setting would just toggle between 312/262 scanlines at ~ 50 & ~ 60 FPS.  There's no valid reason for the CPU to overclock to that speed (though it does seem somewhat close to half the PAL colour clocking rate)

https://en.wikipedia.org/wiki/Commodore_Plus/4

 

Quote

The Plus/4's PAL model may also be switched to NTSC mode by disabling the screen which sets the CPU frequency to 2.22 MHz^[10] (this is 115% faster than C64's maximum speed). So a Plus/4 (PAL) is one of the fastest 6502 based computers for raw calculations.

 

[Mazzspeed]

It's even highlighted in the results list:

 

[Rybags]

I've got a real machine, so will have to get it out and see for myself.

[Mazzspeed]

18 minutes ago, Rybags said:

I've got a real machine, so will have to get it out and see for myself.

I can tell you right now, it definitely runs at 2.2Mhz. This has been known for quite some time now.

 

All it needs is the 2Mhz ram of the BBC and it would be a rip snorter as long as the screen is off. All our 8bit machines run 1Mhz ram as Atari and Commodore wanted to make things as affordable as they could without the backing of the British Broadcasting Corporation.

 

In fact the BBC is a really good 8bit machine. It lacks somewhat in graphics capabilities, but as a development machine it's a great device - Especially with that Tube port and an ARM second processor.

[Rybags]

The "2 MHz Ram of the BBC" - somewhat irrelevant.

RAM doesn't really have a speed, it's got access time which in the case of most 8-bit computers will have plenty of headroom below what's needed, e.g. 250 ns was the original spec but most XEs will have DRams that are under 150 and as low as 90.

 

The BBC has an advantage in that it's actually running at full speed all the time (from what I could deduce using one) - so in fact it's likely the Ram is probably clocked even higher.

[Mazzspeed]

1 hour ago, Rybags said:

The "2 MHz Ram of the BBC" - somewhat irrelevant.

RAM doesn't really have a speed, it's got access time which in the case of most 8-bit computers will have plenty of headroom below what's needed, e.g. 250 ns was the original spec but most XEs will have DRams that are under 150 and as low as 90.

 

The BBC has an advantage in that it's actually running at full speed all the time (from what I could deduce using one) - so in fact it's likely the Ram is probably clocked even higher.

The BBC was running a 2Mhz clock via it's 6502 most of the time with the exception of certain operations, therefore ram speed was more important than other 8bit machines of the era. Basically, the BBC needed DRAM with a 250ns cycle time or better with ~90-100ns access time in 1982 and could make use of it. Most other 8bit machines of the era had DRAM in the 300ns cycle time range on release in 1982, dropping to ~250ns and even 150ns years later as manufacturing improved and prices dropped, but they couldn't really make use of it. As far as I'm aware most A8's in 1982 ran 4116 DRAM chips with up to 350ns cycle time, later on I believe better variants were used like the 4164 that allowed for far faster cycle and access times, but as you stated the A8 couldn't really make use of such DRAM's, unlike the BBC.

 

The Plus/4 is a bit of an unknown, I don't really know what DRAM was fitted to the device on release, but knowing Commodore it could have been anything and most likely could have been slower than ideal considering it's ability to run at 2.2Mhz in certain situations - Essentially that's my point. However, I guess a the end of the day the machine ran, so the memory used must have been good enough.

Edited February 1, 2021 by Mazzspeed

[Rybags]

I'm fairly sure Atari never used Ram over 250 ns.  It just wouldn't work.  250 ns equates to half of a 2 MHz cycle, so gives a little leeway for our 1.79 MHz systems.

 

"Make use of" isn't really relevant.  Whether a given cycle is granting memory access to the CPU or for DMA, the timing requirements are still the same.  We don't have wait states like PCs where we're waiting for long latency memory operations, any given memory access is always done in a single cycle.

 

Plus/4 is a mid 80s machine so chances are it was using 150 ns chips or better.  Though just like our 90 ns chips in the XE, it makes no difference, so long as it works it doesn't make the machine any faster or slower.

 

The 2.2 Mhz thing - seems strange to me though it is about a 4:5 ratio over the 1.78 Mhz base clock - and our Atari and the Plus/4 has a 4:5 ratio of the CPU vs half the colourburst cycle.