Search the Community
Showing results for tags 'benchmark'.
Found 4 results
I always knew that TI BASIC used the VDP RAM for most things. I also believed that the VDP RAM was a big contributor to the slow performance of TI BASIC. So I decided to create some code for CAMEL99 Forth that would let me create variables and strings in VDP RAM using the same kind of code that is used by Forth for this purpose. Here is the code that creates the memory allocation commands. The actual words are the like the Forth equivalent but they have 'V' prefix. HEX 1000 CONSTANT VBASE 37D7 CONSTANT VENDS ( this allows 10k of VDP RAM for data) VARIABLE VP ( VDP memory pointer) : VHERE ( -- addr) VBASE VP @ + ; ( returns next available VDP addr) : VALLOT ( n --) DUP VHERE + VENDS > ABORT" VDP MEM FULL" VP +! ; I needed a way to create a variable and a buffer to hold a string. I also made a buffer creator for CPU RAM while I was at it. : VDPVAR: ( -- Vaddr) VHERE CONSTANT 2 VALLOT ; : VBUFFER: ( n -- Vaddr) VHERE CONSTANT VALLOT ; : BUFFER: ( n -- addr) CREATE ALLOT ; ( CPU ram buffer creator) CAMEL99 already has ASM code that is equivalent of fetch and store for integers that operate in the VDP RAM. ( [email protected] and V!) but I needed routines to move a string from Forth into VDP ram with the count byte included. I also needed a way to GET it back into Forth. While I was at it I made a PRINT for both kinds of strings. ( PLACE a string from CPU ram into VDP ram as a counted string) : VPLACE ( adr len vdp-addr -- ) 2DUP VC! 1+ SWAP VWRITE ; ( GET a counted string from VDP ram and return address and count on stack) : VGET ( V$ -- addr cnt ) DUP [email protected] PAD SWAP 1+ VREAD PAD COUNT ; ( syntax candy) : VPRINT ( VDP$ -- ) VGET TYPE ; ( print a VDP string ) : PRINT ( cpu$ -- ) COUNT TYPE ; ( print a CPU string) Then I created variables and buffers in each memory space. DECIMAL VARIABLE X VARIABLE Y 50 BUFFER: B$ VDPVAR: Q VDPVAR: W 50 VBUFFER: A$ Below is the test code which completely blew away my assumptions about the speed of VDP RAM. For integers there is a pretty big hit as you can see. 50 to 75% slower in VDP ram. BUT there is only about a 9% slowdown when using VDP RAM for string storage! I am really surprised. This ran on CLASSIC99. Maybe somebody can tell me if real hardware would show the same kind of results. BF NOTE: Both Forth routines PLACE and VPLACE use ASM code to do the actual byte-by-byte movement of data. Forth only massages the parameters on the stack for the Assembly code to pick them up. DECIMAL ( integer store and fetch test) : CPU_R/W ( n -- ) 10000 0 DO I X ! X @ DROP LOOP ; ( 4 SECS) : VDP_R/W ( n -- ) 10000 0 DO I Q V! Q [email protected] DROP LOOP ; ( 6 SECS) ( test integer to integer transfer speed) : CPU_A->B ( n -- ) 10000 0 DO I X ! X @ Y ! LOOP ; ( 4.5 SECS) : VDP_A->B ( n -- ) 10000 0 DO I Q V! Q [email protected] W V! LOOP ; ( 7.9 SECS) ( test write a string to VDP RAM) : VDP$ ( -- ) CR S" Initial A$ string." A$ VPLACE CR A$ VPRINT 5000 0 DO S" This string was placed into VDP RAM 5000 times." A$ VPLACE LOOP CR A$ VPRINT ; ( 11.4 SECS) : CPU$ ( -- ) CR S" Initial B$ string." B$ PLACE CR B$ PRINT 5000 0 DO S" This string was placed into CPU RAM 5000 times." B$ PLACE LOOP CR B$ PRINT ; ( 10.6 SECS)
https://en.wikipedia.org/wiki/Dhrystone source:https://homepages.cwi.nl/~steven/dry.c Is it possible to run this on Atari? Not in assembler but maybe in other languages like: action, mad pascal, fast basic,basic, gcc6502, vbcc,turbo basic,quick and effectus ?
Hi all, I've been recently working on updating the Atari 2600 emulation of Z64K and I'm now looking for a comprehensive test suite of programs to test all aspects of the emulation, especially the TIA. Any suggestions on games that are good test cases would be welcome as well. note: Z64K checking of cartridge type is still a WIP so some non-standard cartridges types won't be detected properly. Ideally it would be nice to have a cartridge format similar to what VICE uses for the c64 but that can be another topic. To date I've been using the following programs for testing beyond the officially documented TIA behaviour. Tricks and demos from minidig. Rsync Test by Omegamatrix Hmove Tes by Bradford W.Mott Extra Terrestrials (to test RSYNC) Bang demo and Cosmic ark (to test star field) Thanks in advance for any help in updating the above list.
I decided to use a math-heavy BASIC program from Antic magazine called Fractal Zoom to test the built-in floating-point routines. I ran it in Atari BASIC, then BASIC-XE using it's own FP routines. I even made an Action! port that called the built-in routines. All tests were done with the default values for A-corner, B-corner and Side, and in GTIA 9-colour mode. To draw the first screen, Atari BASIC took 9.55 hours, and BASIC-XE using it's own FP took 3.02. The Action! port took about 9.5 hours, almost as long as the Atari BASIC version. That in itself says a lot! So, if you ever need to use floating-point in a speed-critical program, you might want to try something other than the built-in routines!