EA változtatások 583.5 másodpercről 498.6 másodperce javították a futásidőt 4 MHz-es gépen, de ezen még tovább kellene gyorsítani.

Egyébként arányaiban nem sokkal lassabb, mint az én változatom (310 sec), hiszen te nagyobb felbontást használsz (160x200 a 128x192 helyett), és több iterációt (88 a 64 helyett). Egyébként miért pont 88?

Egyébként miért pont 88?

A paletta mérete miatt, 11 szín 8 árnyalata (ditherelve). Pontosan 88 iterációnál a 12-edik szín jelenik meg, ami fekete.

Kisebb módosításokkal így változott a futásidő:
main: 479.6 s
Iterate: 410.2 s
fpMult: 114.2 s
fpSqr: 202.2 s
PutPixel: 6.4 s
AddQueue: 2.7 s
_divuint + _moduint: 4.4 s

Szerk.: az ri változó törlésével az Iterate még gyorsul 15.2 másodperccel. További minimális gyorsulást eredményez az előjeles 32 bites összehasonlítás előjel nélkülire alakítása.

443.9 másodperc, de továbbra is csak C nyelvű az Iterate:
 epmandel.com (2.97 kB - downloaded 226 times.)

 epmandel.c (8.93 kB - downloaded 231 times.)
 loader.s (9.39 kB - downloaded 223 times.)
 ihx2ep.c (3.96 kB - downloaded 218 times.)
 Makefile (0.91 kB - downloaded 223 times.)

 testmult.lua (1.53 kB - downloaded 220 times.)

Újdonság, hogy a 0-9 billentyűkkel más paraméterek választhatók (a 0 az alapértelmezett), de ezek a nagyobb nagyítás miatt lassabbak. Célszerű 250 MHz-es Z80-at beállítani. A Stop billentyűvel megszakítható a rajzolás, Space vagy Escape kilép.

Még lehetne próbálkozni 16 bites egész aritmetikával (pl. 1 bit előjel + 3 bit egész + 12 bit tört rész)

2 bit egész nem lenne elég? ha jól számolom, akkor úgy 3.9999... lenne a legnagyobb ábrázolható szám, de ha r2+i2 >= 4, akkor úgyis a végtelenbe tart, szóval ott elég lenne csak az overflow-t figyelni, nem?

hevenyészett 2.13 bites fixpontos számításom eredménye:

static unsigned char Iterate(int x, int y)
{
unsigned char iter;
long r=x;
long i=y;
for(iter=0; iter<MAXITER; ++iter)
{
long r2 = (r*r)/8192, i2 = (i*i)/8192;
if (r2+i2 >= 32768) break;
i = (r*i)/4096 + y;
r = r2-i2 + x;
}
return iter;
}

úgy vettem észre, hogy a jobbra shift az nem aritmetikai shift-et csinál, ezért az osztás
de nem is a hatékonyság volt a lényeg jelenleg, csak kipróbáltam, hogy működik-e egyáltalán

Valóban jó ötletnek tűnik ez a pontosság, egyelőre 299.8 másodperc lett, de valószínűleg lehetne jobb is:
 epmandel.com (2.93 kB - downloaded 221 times.)

Szerk.: nagyobb nagyításnál (4, 6 és 7) azonban hibásan működik, itt már kevés a felbontás.

ez egyébként mennyivel gyorsabb, mint azok, amik annak idején, az EP idejében készültek?

A _mullong is elfogyaszt 33.8 másodpercet, valószínűleg itt:
Ezt érdemes lenne átalakítani, hogy az assembly fixpontos szorzó rutint használja.

Szerk.: egyelőre a nagyobb pontosságú verziót módosítottam, ez gyorsult is 443.9-ről 423.9 másodpercre.