Experimenteller Code:
Hier habe ich den CPC-Typ float verwendet und nach Operationen die Mantisse des Ergebnisses um +-1 (Variable SIGADD, kann modifiziert werden) verändert. Unter der Annahme, dass der CPC dem IEEE-Standard folgt, und ich diesen richtig interpretiere (Fehler +- 0.5 ulp bei Grundoperationen), müsste dann das korrekte Ergebnis innerhalb dieser Mantisse-veränderten Werte liegen.
Je nachdem, wofür ich die Float-Operation durchführe, nehme ich dann den kleineren oder größeren der beiden veränderten Werte.
Mein Ziel hier war es, zu sehen, ob man so einen substanziellen Zeitgewinn erreicht. Der Code ist nicht verifiziert, subnormale Float-Zahlen werden nicht berücksichtigt, mir hat es genügt, ein Ergebnisbild zu bekommen, das in etwa der Mandelbrotmenge entspricht, wenn in der Formel z^2+c der c-Wert ein komplexes Intervall ist (und einem Pixel entspricht; siehe Bild, ganz rechts).
Für ein 64x64-Bild (2. von links) brauchte der Emulator in Echtzeit nun knapp 5h anstelle von 3 Tagen mit meinem STRING$-basierten Typ für 50x50 (ganz links). Das 256x256-Bild (3. von links) wurde nicht in Echtzeit berechnet (8h in cpcemu, fast)
Die Linien auf dem 2. und 3. Bild kommen wsch. daher, dass ich einige float-Ergebnisse als Fehler betrachte und den entsprechenden Pixel als UNCLEAR (grau) belasse. Bspw. verändere ich nur Mantissen, wenn das Ergebnis immer noch eine normalisierte Float-Zahl ist, ich also aus Gründen der Einfachheit des Codes den Exponenten nicht manipulieren muss (Zeilen 21500-21999). Fehler ist auch, wenn die Multiplikation 0 liefert, obwohl keiner der Faktoren 0 ist (underflow).
Man kann viel mit dem CPC machen, was Optimierungen angeht. Ich finde die STRING$-Variante (Fixpunkt) aber deutlich einfacher vom Verständnis (Schulrechnen) und Programmieren als float/IEEE/ulp.