FIGnition's Firmware 0.9.9 interpreter improves by up to 20% upon previous versions running at up to 400KIPs, comparable to real, early 80s 8-bit CPUs!
The Benchmarks are simple adaptations of the original BYTE / Personal Computer World Benchmarks (with the exception of the floating point tests). The benchmark tests are now attached.
An indication of the graphics performance is given below:
I make claims of up to 400 KIPS when none of the benchmarks report that figure. That's because loop itself is relatively slow at only 86.2KIPS (see bm1). Consider bm3L, it executes 9 simple instructions per loop + loop and does this 1000 times. So, the 9000 simple instructions take 0.034-0.0116 = 0.0224s, which is 401.8KIPs. Similarly, bm5-bm4 tells us that we can do 1000 call/returns in 0.024s, which means each call+return takes 24µs (equivalent to a 1.04MHz Z80). Pixel plotting takes 0.096s to do 2400 pixels, and since the loop involves 2 additional simple instructions+loop: the remaining code takes: 2.4*(2*0.025+0.0116) = 0.040s, leaving 0.0562s for plotting 2400 pixels, that's 43KPixels/s (lower than the effective KIPS).
The upshot though is that FIGnition can achieve performances in the same ball-park as real 8-bit micros from the late 70s/early 80s. The challenge is SRAM access, which is terribly slow at 0.9µs/2.7µs (sequential/non-sequential). Against this FIGnition prefetches the next byte while processing the previous one; makes use of internal RAM; performs 16-bit arithmetic as standard and of course, implements much of the functionality (such as displaying text, graphics and memory moves) via its fast internal Flash. As a result a simple instruction execution cycle takes as little as 25 AVR cycles (e.g. for and) which means 10.7MHz is used for the display, leaving 9.3MHz for user-code.
Since firmware 0.9.8 has been available, FIGnition supports a simple xor-based blitter which can move bitmaps at a rate of roughly 12622 tiles per second (or 252.44 tiles per 50Hz frame). Each move consists of two blit operations (one to erase an old bitmap and the other to blit a new bitmap). Let's compare this with, say a similar xor blitter for a VIC-20 operating with a bitmapped screen, ignoring colour RAM. In the assembly code provided on this page; a VIC-20 requires 50µs/scan + 41µs per extra column. So, a 16x16 pixel (4 tile) sprite requires: 1.641ms giving a simple blit rate of 2437 tiles per second, meaning that 1218tiles can be moved which is about 24.4 tiles per frame; about 10x slower than a FIGnition.
**(The KIPS calculations for bm2 to bm7 were incorrectly calculated here).