This page (revision-7) was last changed on 03-Feb-2023 15:21 by Eli Simpson 

This page was created on 07-Feb-2011 14:47 by Gromit

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
7 03-Feb-2023 15:21 28 KB Eli Simpson to previous removed extraneous "."
6 25-Nov-2021 11:39 28 KB Eli Simpson to previous | to last Changed 1 to I in keyword FI (probably a OCR error)
5 07-Feb-2011 15:31 28 KB Gromit to previous | to last
4 07-Feb-2011 15:21 21 KB Gromit to previous | to last
3 07-Feb-2011 14:59 14 KB Gromit to previous | to last
2 07-Feb-2011 14:48 14 KB Gromit to previous | to last
1 07-Feb-2011 14:47 14 KB Gromit to last

Page References

Incoming links Outgoing links
Review Action
Review Action

Version management

Difference between version and

At line 124 changed 2 lines
[#1]
%*Jim Gilbreath, "A High-Level Language Benchmark." ''Byte'', VI, 9 (September 1981), pp. 180-198.
Although I love standards, I don't like the __Sieve__. It's not easy for beginners to understand, it takes too long (in BASIC, anyway), and it doesn't test the Atari under real-world conditions, with lots of 6502 processor time being "stolen" by Antic for video DMA. I wanted a benchmark that anybody could appreciate, operating under the kind of DMA conditions an Atari program is likely to find itself up against.
Back in Issue 11, I devised a little program that fills a GRAPHICS 24 screen with color, one byte (eight pixels) at a time. It was used to compare a couple of BASIC compilers at the time, but it's equally valid in any run-time environment. My definitive BASIC implementation of this test appears in __Listing 5__. __Screen Fill__, as the program shall henceforth be known, executes in 4.025 jiffies or about 67 seconds on a 48K 800. (Again, improvements are possible, but for the sake of clarity let's stick to __Listing 5__.) I'll be using __Screen-Fill__ in conjunction with the __Sieve__ to judge the performance of every new language I review from now on. So let it be written; so let it be done.
{{{Listing 5.
10 REM * SCREEN-FILL BENCHMARK
11 GRAPHICS 24
12 POKE 19,0:POKE 20,0
13 SCREEN=PEEK(88)+256*PEEK(89)
14 FOR I=0 TO 31
15 FOR J=0 TO 239
16 POKE SCREEN+J,255
17 NEXT J
18 SCREEN=SCREEN+240
19 NEXT I
20 TIME=PEEK(20)+256*PEEK(19)
21 GRAPHICS 0
22 PRINT TIME;" JIFFIES"
}}}
OSS includes a implementation of the __Sieve__ benchmark in their Action! documentation. I rewrote the code slightly to make it match my BASIC implementation more closely; the modified program is shown in __Listing 6__. It executes in 89 jiffies or just under a second and a half. I'll save you a calculation by pointing out that the __Sieve__ runs about 219 times faster in __Action!__ than it does in Atari BASIC.
{{{Listing 6.
BYTE RTCLOK=20, ; addr of sys timer
SDMCTL=559 ; DMA control
BYTE ARRAY FLAGS(8190)
CARD COUNT,I,K,PRIME,TIME
PROC SIEVE()
SDMCTL=0 ; shut off Antic
RTCLOK=0 ; only one timer needed
COUNT=0 ; init count
FOR I=0 TO 8190 ; and flags
DO
FLAGS(I)='T
OD
FOR I=0 TO 8190
DO
IF FLAGS(I)='T THEN
PRIME=I+I+3
K=I+PRIME
WHILE K<=8190
DO
FLAGS(K)='F
K==+PRIME
OD
COUNT==+1
FI
OD
TIME=RTCLOK ; get timer reading
SDMCTL=34 ; restore screen
PRINTF("%E %U PRIMES IN",COUNT)
PRINTF("%E %U JIFFIES",TIME)
RETURN
}}}
Unconvinced? __Listing 7__ is an __Action!__ implementation of __Screen-Fill__. This demanding little gem executes in 32 jiffies (slightly more than half a second), or 126 times faster than its BASIC counterpart under maximum DMA handicap. And if you cheat by replacing the nested FOR-TO loops with an _Action!_, SETBLOCK procedure in the form:
{{{SETBLOCK(SCREEN,7680,255)}}}
you'll obtain an execution time of just five jiffies. This is essentially the same amount of time it takes the equivalent machine-language code to do the same job. No other high-level Atari language that I am aware of can match this kind of speed performance.
{{{Listing 7.
BYTE RTCLOK=20, ; addr of sys timer
SAVMSCL=88, ; lsb of screen addr
SAVMSCH=89, ; msb
I,J,TIME ; declare variables
CARD SCREEN
PROC BENCH()
GRAPHICS(24)
RTCLOCK=0
SCREEN=SAVMSCL+256*SAVMSCH
FOR I=0 TO 31
DO
FOR J=0 TO 239
DO
POKE(SCREEN+J,255)
OD
SCREEN==+240
OD
TIME=RTCLOK
GRAPHICS(0)
PRINTF("%E %U JIFFIES",TIME)
RETURN
}}}
!!Pulling the wings off a butterfly.
Once I got a taste of __Action!__'s dizzying speed, I had to find out what was going on inside that demonic little cartridge. So I used the W (write object code) option of the __Action!__ monitor to send a copy of the compiled __Screen-Fill__ benchmark to a disk file. Then I read it back into Ralph Jones' __Ultra Disassembler__ (published by Adventure International), massaged the labels and commented the code to make it correspond to the __Action!__ source text, line by line. The result appears in __Listing 8__.
Assembly programmers will appreciate the extraordinary efficiency of the __Action!__ compiler. The code in __Listing 8__ is totally non-recursive. It uses no special stacks or indirect pointers to control the flow of execution, just pure in-line machine code with an occasional JSR into a cartridge library routine. This is "native mode" compilation at its best: simple, clean, and very, very swift. The output of a typical C or Pascal compiler looks like spaghetti by comparison.
Because compiled __Action!__ programs refer to subroutines that reside inside the __Action!__ cartridge, you can't run a program without the cartridge in place. This may come as a disappointment to users who want to give copies of their latest __Action!__ game to friends who don't have __Action!__ OSS plans to remedy this situation by offering a Personal Run-Time Package to licensed __Action!__ users for around $30. It's a utility that will let you turn any __Action!__ program into a self-standing entity that will run with no help at all from the __Action!__ cartridge, thank you. A commercial run-time package will also be offered for a one-time licensing fee of approximately $300. Both may be available by the time you read this; contact OSS directly for more information.
Another $30 will get you OSS's Programmer's Aid Disk (PAD), a collection of demonstration programs and library routines that wouldn't fit into the already crowded __Action!__ cartridge. The libraries include badly-needed support for player/missile graphics, memory management and floating point math, precisely the weaknesses I noted above. The demo programs are very instructive and help to clarify some of the obscure features of the language. You even get a full-blown game program, written in __Action!__ by our very own Joel Gluck.
The PAD squarely addresses many of the shortcomings of the __Action!__ cartridge and documentation, and is an absolute must for all serious owners of the Action! system. In fact, this material ought to be included with every new system sold, even if it means bumping up the price a bit.
!!You can bank on it.
The 16K __Action!__ "SuperCartridge" is a technically interesting device in and of itself. It employs a hardware technique called bank-selecting to make itself "look" like an 8K cartridge. This gives you access to the 8K of RAM between $8000-$9FFF that is de-selected and thus rendered useless by a conventional 16K cartridge, such as __AtariWriter__.
The bottom half of the SuperCartridge ($A000- $AFFF) is divided into three independently addressable 4K banks of ROM, which are automatically switched in and out depending on what part of the system is in use. If your Atari has 48K or more memory, it's even possible to address the 4K bank of RAM that resides "under" this half of the cartridge. OSS's new __DOS XL__ operating system takes advantage of this capacity in a most ingenious manner. Look for a report in a future issue.
The bank-select cartridge is a nearly ideal home for Atari software. It gives the cartridge designer a full 16K to work with, enough room for plenty of bells and whistles. It gives the user an instant-loading, highly reliable environment with up to 40K of workspace. And because three of the memory banks occupy the same 4K address range, a bank-select cartridge is very difficult to pirate. Let's hope that more manufacturers start taking advantage of bank-selecting to enhance the value and security of their products.
[#1]*Jim Gilbreath, "A High-Level Language Benchmark." ''Byte'', VI, 9 (September 1981), pp. 180-198.
This page (revision-7) was last changed on 03-Feb-2023 15:21 by Eli Simpson  Top