Beiträge von Mike

Probier' mal kinzi's Dead-Test-KERNAL. Das KERNAL-ROM ist bei deinem VC gesockelt, insofern - wenn Du das zugehörige EPROM brennen kannst und auf einen Adaptersockel bekommst - kann man das vlt. weiter analysieren.

VIC-20 DEAD TEST

Im funktionstüchtigen Garden Wars wird am Anfang neben dem Bildschirmgewackel auch eine schwarze bzw. weiße Schlange auf dem Bildschirm gezeichnet. Das klappt bei deinem VC mal überhaupt nicht. Das 'riecht' jetzt schon nach einem RAM-Fehler aber da solltest Du vorher herausbringen, welche RAM-Bausteine das genau sind - die Keramik-2114er haben nämlich schon was für sich ... ... wäre extrem schade die für nix auszulöten.

Zitat von maddoc177

Die blaue Leitung verbindet PIN Y am Port mit C9 in der Nähe des Video-ICs.

Die ist in der ersten CR-Revision der Hauptplatine ab Werk (mit einem eingeschweißten Widerstand) drin, später wurde sie dann in die Platine selbst integriert.

Zitat von maddoc177

Die kurze schwarze [Leitung] am Joy-Port verbindet Pin 7 mit L2.

Ich hab gerade mal das TRM gecheckt, die ist wohl auch ab Werk (verbindet Pin 7 mit +5 V), war mir aber noch nie aufgefallen ...

Es macht aber schon Sinn, wenn Du auch ein Foto der Oberseite mit rein hängst - bloß weil die "gleich" aussieht, heißt das noch lange nichts. Capstan (und ich) möchten wissen vom welchem Hersteller die TTL-Logik-Chips sind, die von MOS gefertigten Teile sind nämlich berühmt für ihre Ausfälle.

Wenn die Cartridge "läuft" und sogar Ton produziert, muß die "CPU-Seite" der Busse schon weitgehend i.O. sein ...

Zitat von maddoc177

Ohne Cartridge erscheint auch mir der türkise Rahmen und ein weißer Hintergrund mit flimmernden Punkten. CPU und VIC scheinen in Ordnung zu sein.

... normalerweise hängt der VC-20 in so einem Bild, wenn der RAM-Test nicht durchläuft oder das BASIC-ROM defekt ist.

Ich würde wie #3 auch auf einen (Teil-)Defekt der '245er tippen.

Zitat von maddoc177

RAMs [...]

Mach bitte ein Foto der Hauptplatine, damit die Schreiber hier wissen was sie dir antun, wenn sie das Tauschen der RAMs empfehlen.

Zitat von maddoc177

[...] oder PLA?

Da Du "völlig unerfahren" bist ... ..., sei dir hier verziehen: der VC-20 hat keine PLA, deren Aufgaben (also, Auswahl der Chips je nach angelegter Adresse von CPU oder Videochip) werden beim VC-20 von einer Handvoll TTLs übernommen.

Zitat von Kornel

Echt super geworden Mike!

Zitat von 8R0TK4$T3N

Nice

Ich geb' das gerne an Rob weiter ... mein Beitrag war ja im wesentlichen nur eine Fingerübung bzw. Fleißarbeit um eine pixelgetreue Kopie aus dem Screenshot zu produzieren. Da dort schon ein CRT-Filter drübergelaufen war, ging das nicht einfach mit einem Konverter.

Das Ergebnis soll aber mal zeigen, was grafisch so mit dem VC-20 und speziell mit MINIPAINT geht. Gerade die Mischung von Hires und Multicolour ist ja nicht ganz so üblich.

Zitat von 8R0TK4$T3N

Als Gast ist [Denial] leider nicht mehr einsehbar. Kennst du den Grund vielleicht?

Seit Jahresanfang hatten Scavenger-Bots die Bandbreite vom Forum beständig aufgebraucht, Anfang Juni hat der Admin dann vor lauter Not das Forum verrammelt damit es für die Bots (hoffentlich) uninteressant wird.

Das ist natürlich nur eine Notlösung und hoffentlich wird das über ein Update der Forensoftware in der nächsten Zeit mal glattgezogen.

That kind of processing for rounded results anyhow should always use ...=INT(...*10+0.5) - or 100, 1000, etc. for more digits to the right of the decimal point.

It is almost always a futile attempt to calculate an integer result from non-integer input. Rounding errors in the representation of the non-integer input often enough thwart the expectations. What looks fine as formula in a standard math textbook can produce grossly wrong results with floating point arithmetic. The entire field of Numerical Maths revolves around getting robust results in the presence of a finite representation of real numbers and round-off errors.

In Ordnung, der eine geht noch:

Zitat von Volker

Ja, meine Variante wird besser sein als dein Ringspeicher, weil dadruch unnötige Kopien vermeiden werden.

Von "deiner Variante" habe ich bislang exakt 0 Zeilen Programmcode gesehen. Ich hatte ja bereits auf meinen Snake-Klon verlinkt ...

Noch ein SNAKE-Klon für den VC-20 ... - VC20 - Forum64

... und da ist die Variante, die den Bildschirmspeicher zur Verfolgung des Kopfes vom Schwanzende her nutzt auch schon implementiert.

Wenn Du das dann mal nachvollzogen hast, kannst Du dich im Nebensatz gerne noch um die einigermaßen überflüssigen Hin- und Herrechnungen zwischen (X,Y)-Koordinaten und Bildschirmadressen in der Referenzimplementierung von berni kümmern, mit den da verwendeten Divisionen bzw. Restwertbildungen geht auch einiges drauf. Das lohnt sich natürlich erst dann, wenn vorher der große Bremsklotz rausgezogen worden ist.

Und abschließend noch dazu:

Zitat von Volker

Es [kommt] nicht darauf an, wie viel der Programmierer einspart, sondern die "Kunden" des Programms.

Wenn das Ergebnis schlecht ist, werden das nicht viele Kunden sein, und damit die Gesamtlaufzeit des Programms ebenfalls gering - insofern behält mein Argument seine Gültigkeit.

Es geht hier nicht darum, irgendwelche zusätzliche Zuweisungen einzufügen, sondern die lineare Laufzeitordnung des ursprünglich "durchkopierten" Arrays durch die konstante Laufzeitordnung der Zugriffe auf einen Ringpuffer zu ersetzen.

Diese lineare Laufzeitordnung des durchkopierten Arrays hat die Geschwindigkeit der Referenzimplementierung eindeutig dominiert, nochmals: mit der Änderung auf einen Ringpuffer ist die Aufgabe gelöst. Alle anderen Details im Programm sind in dem Zusammenhang völlig nebensächlich, auch wenn Du das anders siehst.

Ich bin damit raus.

Zitat von Volker

Ringpuffer ist, wie ich schon mehrfach gesagt habe, in diesem Fall nur unnötiges kopieren von Information.

Bitte was?

Lies dir bitte die Beschreibung wie ein Ringpuffer realisiert wird in der Literatur durch. Du scheinst hier die Auffassung zu haben, daß ein Ringpuffer eine lineare Laufzeitordnung mit der Anzahl der gespeicherten Elemente hat, was aber nicht der Fall ist. Einspeicherung und Entnahme von Elementen erfolgen in konstanter Laufzeit.

Wenn wir uns da nicht einig werden, macht es wenig Sinn, den Rest auch noch auszudiskutieren.

Zitat von Volker

man [müsste] bei so einem Programm erstmal genau so sagen [...], [was] es machen solll; ist bis jetzt ja nicht geschehen.

Nun ja, es gibt eine "Referenzimplementierung" im *.pdf-Dokument, eine wie auch immer geartete optimierte Version sollte einfach das gleiche "äußerliche" Verhalten aufweisen und - gegeben durch den Thementitel - schneller sein.

Zitat von Volker

"Darf ich am Rand raus und soll ich dann auf der anderen Seite wieder ankommen? Ist es ok, wenn man bei links/rechts jeweils eine Zeile höher bzw. niedriger rauskommt?"

Das sind Detailprobleme, die grundsätzlich nichts ändern. Genauer gesagt: in der Referenzimplementierung haben diese Abfragen nur einen konstanten Teil an der Laufzeit, optimiere ich also auf einen Ringpuffer, dann sind schon >99% der Aufgabe erledigt. Wie das konkret zu erfolgen hat, nochmals, siehe gängige Literatur:

Zitat von Volker

[Man erwartet] in einem Buch eigentlich, dass das folgende Programm mit den beigebrachten Techniken oder zumindest sehr ähnlich dazu optimiert wird [...] Wie lautet denn jetzt die Lösung der Optimierung mit Binärbaum bzw Hash?

Das folgt hier (leider) nicht aus dem Dokument. Der Ringpuffer ist hier im wesentlichen die kanonische Lösung - weder muß man irgendwie mit einer Binärbaumsuche Anfang und Ende der Schlange im Array "suchen", zwei gespeicherte Indizes reichen da völlig aus, und hashen muß man da auch nichts: der Zugriff auf jedes Einzelelement im Array ist garantiert in konstanter Laufzeitordnung, Hashing ist nur dann in konstanter Laufzeitordnung, wenn es keine Kollisionen gibt. Hier also Hashing in Betracht zu ziehen würde also nur Dinge verkomplizieren für die es keinen Grund gibt.

Zitat von Volker

Oder wolltest du als Lösung der Aufgabe [hören]: "Nee, dass ist schon der beste Code und kann nicht mehr optimiert werden"?

Ich habe die Aufgabe nicht gestellt, das geht nur Richtung berni - davon abgesehen gibt es aber neben z.B. der Laufzeit des Programms und dem benötigten Speicher mindestens noch eine weitere Dimension die optimiert werden kann: nämlich die Zeit, die der Programmierer mit der Implementierung des Programms selbst verbringt. Wenn diese Zeit die erwartete Gesamtlaufzeit des Programms um Größenordnungen übersteigt, hat man vielleicht etwas verkehrt gemacht.

Zitat von Volker

(Einzig, wenn da je nach Zugriffsmuster ein Cache den kompakteren RIngpuffer schneller lesen kann als den größeren Bildschirmspeicher, dann würde es evtl. Sinn machen. Aber das wird beim c64 ja wohl nicht der Fall sein, oder? (Ich habe aber zugegebenermaßen schon lange nicht mehr am C64 programmiert)).

Caches im Sinne von CPU-Caches sind eine neuzeitliche Erfindung ... ... sowas gab es beim C64 noch nicht: zu den Zeiten war der Speicher schneller als der Prozessor, weswegen man es sich sogar leisten konnte, 50% der möglichen Buszeit an den Videochip abzugeben. Die Voraussetzung für diese Aussage ist also schon mal falsch, Speicherzugriffe sind beim C64 immer gleich schnell.

Beim Ringpuffer sind das dann - unabhängig von dessen Größe und von der Größe der Schlange - immer nur zwei Zugriffe, einer für die freiwerdende Position des Schwanzes und einer für die neu zu belegende Position des Kopfes.

Zitat von Volker

Ja, die letzte Variante ist "korrekt". Aber warum "zusätzliche Speicher". In dem Fall ist ja nichts zusätzlich, der Speicher wurde ja vorher auch schon belegt. Es ist mit der Variante weniger Speicher als vorher.

Das gilt nur, wenn man das Array im Bildschirmspeicher ablegt und das ganze so kodiert, daß es nicht auffällt. Zumindest im gegebenen Fall müßte man für die 4 Richtungen entweder 4 verschiedenen Zeichen das gleiche Ballsymbol zuteilen, alternativ könnte man natürlich auch mehr Zeichen für den Körper hernehmen, welche gleichzeitig noch den "Verlauf" zeichnerisch nachbilden.

Allerdings ist diese Methode, wie ich am Schluß meines vorigen Beitrags geschrieben habe, hier nicht einsetzbar, da sie voraussetzt, daß die Schlange nicht überlappt. Das tut sie aber aufgrund der Konstruktion des Beispielprogramms.

Zitat von Volker

Also kurz: Statt immer die ganze Schlange zu zeichnen/kopieren besser nur den neuen Kopf setzen und den Schwanz löschen. Dürfte dein Programm also im besten Fall grob um Faktor 2*(Länge der Schlange - 2) beschleunigen.

"Beschleunigen um einen Faktor" ist hier etwas zu kurz gegriffen. Gemessen an der Größe der Schlange ändert sich die Laufzeitordnung von O(n) zu O(1). Das bedeutet, statt einer Laufzeit pro Schritt die sich linear mit der Länge der Schlange vergrößert, bleibt die Laufzeit jetzt konstant!

Um dahin zu kommen, reicht allerdings ein zusätzlicher Zeiger auf den Schwanz alleine nicht aus, jeder Teil der Schlange muß die Information mitführen wo der nächste, weiter vorne liegende Teil liegt.

Diese Information kann entweder, wie im Beispielprogramm, in einem Array gespeichert werden - dann sollte man allerdings nicht ständig das ganze Array "durchkopieren" (das ist das, was letztendes zur linearen Laufzeitordnung führt), sondern einen Ringpuffer verwenden (dazu bitte die gängige Literatur konsultieren).

Alternativ kann man diese Information, in welche nächste Richtung man gehen muß wenn man den Schwanz gelöscht hat, in den Bildschirmspeicher selbst einkodieren. *) Der zusätzliche Speicher nimmt dann automatisch das denkbar sinnvolle Maximum an (so viele Positionen, wie der Bildschirm Positionen hat). Ein Beispiel dazu - für den VC-20 - findet sich hier:

Noch ein SNAKE-Klon für den VC-20 ... - VC20 - Forum64

*) das setzt allerdings voraus, daß sich die Schlange nicht überlappt, was im Beispiel aber der Fall ist. Also doch der Ringpuffer ...

Es ist immer recht spannend, wenn Leutz Screenshots von einem Bild veröffentlichen, dann aber irgendwie vergessen die zugehörige Bilddatei mitzuliefern, so daß man sich das Bild evtl. auch mal auf echter Hardware anschauen kann. Nun gut, dann wird das Bild auch schon mal einfach 1:1 nachgepixelt ...

(Quelle: Yet Another Slide Show ... - Denial)

Das ging dann mal über 4 Abende in MINIPAINT und dann war die Sache im Kasten, 30 Workstages insgesamt.

Anbei das Diskimage für den VC-20 mit mindestens +8K-RAM-Speichererweiterung. Speziell für SD2IECs ist mit zippy auch ein Schnelllader an Bord.

Zitat von root42

Wäre gut für [...]

Ehrlich gesagt, "nur" Bank-Switching für sich alleine ist programmtechnisch eine Angelegenheit, die ich mir äußerst ungern ans Bein binde. Es ist nicht nur schwierig zu nutzen (gibt z.B. viel Spaß, wenn man sich versehentlich eine Interrupt-Routine "aus-bank-t"), sondern kettet das Programm auch noch an spezielle Hardware, was den Nutzerkreis erheblich einschränkt.

Was mir erheblich besser taugt ist eine zugehörige Firmware, die das Extra-RAM als RAM-Disk anbietet. Das erlaubt dann z.B. das Programm (welches dann natürlich als Mehrteiler vorliegt) wahlweise von Floppy zu gebrauchen oder eben zuvor in die RAM-Disk zu verschieben, und das gibt dann auch einen erheblichen Geschwindigkeitsvorteil.

Vorausgesetzt die RAM-Disk ist sauber in den KERNAL eingehängt, kann man nun das eigene Programm im Vorfeld ganz 'normal' entwerfen, die gängigen Methoden zur Overlay-Thematik ziehen auch hier (was muß als statischer Part im Speicher bleiben, was wird - z.B. als "Leveldaten" - nachgeladen). Und, im Gegensatz zu einer Bank-Switching-Lösung, die wohl immer nur größere Speicherblöcke ummappen wird, hat man dann eine Granularität herunter bis auf Einzelbytes.

Für den VC-20 ist sowas schon gemacht worden: für die 512 KB RAM der FE3 gibt es eine RAM-Disk, die 480 KB des Extra-RAMs zur Verfügung stellt. Insofern ist für mich das Extra-RAM in der PU ein alter Hut, da gab es früher schon besseres/mehr, und das Extra-RAM in der PU ist wahrscheinlich auch nur ein Nebeneffekt davon, daß ein 'übergroßer' RAM-Chip benutzt wurde um die on-Board-Logik zur Dekodierung für +35K RAM einfacher zu machen.

Zitat von Goodwell

Gibts zu der Erweiterung irgendwo Infos?

Hier: Tool Basic 7.5

Zitat von AndyDTV

Hat irgendjemand ein paar C128 Basic Listings die irgend etwas nichttriviales mit Grafik machen?

Ein neueres Beispiel: Grafik von "drüben" (DDR)

Seinerzeit (1986-1991) hatte ich auch einiges in der Art mit BASIC V7 programmiert ... Balken- und Kuchendiagramme, Zeichnungen komplett gemalt aus Linien, Kreis(-bögen) und Flächenfüll-Befehlen, in Hires und Multicolour.

Dann gab's noch eine BASIC-Erweiterung von mir, Tool-BASIC, wo man mit einer Variante des DRAW-Befehls einfach die Farbe selbst angeben konnte. Der Algorithmus hat dann während des Zeichnens die nötige Farbnummer (im Bereich 1..3) charweise selbst ermittelt, so daß man sich nicht selbst darum kümmern mußte wie man möglichst Colour-Clashes vermeiden konnte.

Ein Malprogramm gab's dann auch noch von mir, Superplot V3, aber das griff bereits auf eine Menge Support-Routinen in Maschinensprache zurück um das ganze sinnvoll zu gestalten (Speicher-Kopierroutinen, Kompressor und Dekompressor für die Bitmap beim Laden und Speicher, Drucker-Hardcopy, Maustreiber, etc.).

Von einem Actiongame wie ELITE war das aber alles noch sehr weit entfernt, ja.

Zitat von Tobias

Eine Art Modul-internes "Bankswitching"?

Genau das. Irgendwo im 'tfw8b'-Blog auch erklärt - und bislang nicht in Gebrauch bzw. verwendbar, da die verantwortlichen Leutz selbst nicht wissen, was sie damit anfangen sollen.

Zitat von Ganymed77

hast Du nen Beispiel oder Link zu der Variante parat?

Von hier:

Writing a 3D geometry engine from scratch - Denial

(... leider momentan hinter einer Anmeldung, da unlängst eine Bot-Armee einen massiven Angriff auf das Denial-Forum gefahren hat ...)

Die beiden je 512 Bytes großen Tabellen 'abs_table_lo' und 'abs_table_hi' werden wie folgt initialisiert:

Das ist bereits für vorzeichenbehaftete Zahlen. Wenn man den Teil von "BIT zp_factor_1" bis ".Multiply_04" wegläßt, gilt die Routine für vorzeichenlose Zahlen.

Die Routine entnimmt die beiden (8-Bit-)Faktoren aus zwei Zeropage-Adressen und speichert das (16-Bit-)Ergebnis ebenfalls in zwei Zeropage-Adressen. Viele Beispiele im Netz erwarten die Eingabe in den CPU-Registern und geben das Ergebnis ebenfalls in CPU-Registern zurück. Der Kern der Multiplikationsroutine läßt sich durchaus auch auf diese Weise implementieren, wobei die Eingabewerte in den meisten praktischen Fällen nicht bereits zur Hand sind, sondern ohnehin erst noch aus dem Speicher abgerufen werden müssen. Es ist ebenso unwahrscheinlich, daß das Ergebnis direkt von einer anderen Multiplikation verarbeitet wird, sodaß es auch erstmal wieder im Speicher abgelegt werden muß. Die Ein-/Ausgabeverarbeitung dieser anderen Routinen erhöht deren Zyklenanzahl um weitere 12 Zyklen (2x LD% ZP, 2x ST% ZP, % ^= beliebiges CPU-Register)! Für die obige Routine benötigt der vorzeichenlose Teil 50 oder 53 Zyklen; je nach Vorzeichen benötigt die gesamte Routine ohne RTS zwischen 62 und 71 Zyklen, durchschnittlich 66,5 Zyklen.

Zitat von LordRudi

Was passiert beim ROL oder ROR, ASL oder LSR und welche Flags werden u. U. gesetzt?

Findest Du alles hier:

mcs6500_family_hardware_manual.pdf

Zitat von LordRudi

Aber ich muss mir, beispielsweise für eine 16bit-Multiplikation, einiges wieder erarbeiten.

Wenn's schnell sein soll und beide Faktoren unbekannt sind, wird das üblicherweise mit Differenzen von Quadratzahlen, letztere aus Tabellen, ausgerechnet. Bitshiften und Zusammenaddieren ist langsamer.

Zitat von LordRudi

Ohhhgottt, was hab ich losgetreten. [...]

Von deiner Seite kommt halt relativ wenig rüber mit welcher konkreten Aufgabenstellung Du gerade wieder einsteigst. Da mußt Du dich nicht wundern, wenn dir da die ganze Bandbreite an Werkzeugen präsentiert wird. Die Leutz sind sich auch nicht zu schade, eigene Werkzeuge zu bauen, wenn Ihnen das, was "auf dem Markt" ist im Moment für den eigenen Anspruch nicht taugt.

Solche flapsigen Bemerkungen helfen dir dann aber auch nicht weiter und kommen bei dem einen oder anderen auch gerne schon mal in den falschen Hals.

Pro-Tip: such dir eins von den vorgestellten Tools aus, schau ob dir das was bringt, und dann kannst Du gerne in ein paar Wochen mit einem neuen, selbstgeschriebenen Programm daherkommen, das zeigt, daß Du was gelernt hast. Merci.

Zitat von LordRudi

Ich suche ein Tool, mit dem ich schrittweise Assembler-Code ausführen kann.

Es sollte ausgewählte Speicherstellen als Binär-, Hex- und Dezimalzahlen anzeigen, um zu zeigen "was sich da tut".

Es muss jetzt nicht unbedingt speziel für den C64 sein, wäre aber besser.

Ich möchte testen, ob bei Berechnungen die Bits richtig hin- und hergeschoben werden

Hier wäre die Auskunft von deiner Seite sinnvoll, ob Du in Maschinensprache gerade erst (wieder neu) einsteigst, oder ob Du von späteren Rechnern (Amiga, PC) das Arbeiten in aufwendigeren Debuggern wie in @oobdoo's Beitrag gewohnt bist.

Beim (Neu-)Einstieg tut's eigentlich erstmal jeder native Feld-Wald-und-Wiesen-Monitor (gerne auch ohne Anführungszeichen). Nicht jeder von denen kommt mit einem Einzelschrittmodus daher, es gibt aber immer die Möglichkeit, Einzelbefehle durch Breakpoints zu trennen und so durch das Programm zu steppen - sobald das Programm Tastatur und Bildschirm bedient, wird's allerdings komplizierter, da der Monitor ja eine Nebenwirkung erzeugt.

Damit kann Du dann ohne weiteres die Wirkung der Einzelbefehle nachvollziehen und zwischendrin auch schauen, was sich im Speicher so tut, eben per Kommandozeile.

Auf dem VC-20 hab ich auf solche Weise z.B. die Abarbeitung einer eigenen Quadratwurzel-Routine, eingehängt in die USR()-Funktion nachvollzogen - vorweg erstmal der Sourcecode:

Die Idee ist jetzt, nachzuvollziehen, was sich bei den Schleifendurchläufen in Y := Sqrt_05 tut.

Ich hab in der nachfolgenden Reihe von Screenshot die Routine erstmal 'batch-assembliert' - dazu wird die Eingabe des Monitor zeitweilig in eine SEQ-Datei umgelenkt:

Sobald der Batch abgelaufen ist, stellt eine kleine Hilfsroutine die Standard-Ein-/Ausgabe wieder her, schließt die Datei und kehrt zu BASIC zurück:

Jetzt ein etwas tieferer Blick in den assemblierten Code um das Äquivalent der Zeile "JSR $BBD4 ; FAC#1 nach Sqrt_05 (Y: Zwischenergebnis) speichern" zu finden ...

... und wir werden fündig bei $02CD - da der Aufruf hier ins VC-20-BASIC-ROM geht, ist es der Befehl JSR $DBD4:

Das Zwischenergebnis in Y geht nach $02F1. Der Code wird nun instrumentiert, damit wir uns das Zwischenergebnis in jedem Schleifendurchlauf ansehen können. Eine Kopie von JSR $DBD4 wird an anderer Stelle hingeschrieben und mit den Befehlen BRK/NOP/RTS abgeschlossen. Dieser "Rucksack" wird dann von einem JSR-Befehl angesprungen, der die Stelle des originalen JSR $DBD4 einnimmt:

Wieder in BASIC zurück, geben wir PRINTUSR(2) ein um die Quadratwurzel von 2 auszurechnen. Der PRINT-Befehl steht hinter einer Zeile von Doppelpunkten, weil der Monitor auch den BASIC-Eingabepuffer nutzt und wir am Ende keinen ?SYNTAX ERROR haben wollen.

Während der Ausführung reduziert die Routine das Argument in den Bereich größer gleich 0,5 und kleiner 2, intern rechnet es also die Wurzel von 0,5 aus und korrigiert anschließend den Exponent.

Der Breakpoint ist jetzt das erste mal aufgerufen worden und bei $02F1 ist "$80 $40 $00 $00 $00" gespeichert. Mit G und M zeigen wir die nächsten Zwischenergebnisse an bis die Routine fertig ist und die Kontrolle an den BASIC-Interpreter zurückgibt, ...

... mit der Ausgabe von PRINT sauber angehängt an das letzte G-Kommando.

Die drei Zwischenergebnisse im Fließkommaformat entsprechen diesen Zahlen:

>02F1 80 40 00 00 00 ^= 0.75

>02F1 80 35 55 55 55 ^= 0.708333333

>02F1 80 35 05 05 05 ^= 0.707107843

Nach diesen drei Durchläufen ist der nächste Wert im Fließkommaakkumulator schon innerhalb der Genauigkeit und nach Korrektur der Exponenten wird 1.41421356 als Ergebnis ausgegeben.

Zitat von kadi

Sieht aber von der Reihenfolge auch so aus als sei da ein Bit kaputt und immer aus 0, halt das Bit1 mit Wert 2.

Zitat von kadi

Der Poke ist auch dunkel.

Dann kann man einen Übertragungsfehler (z.B. eine defekte RAM-Zelle als Zwischenspeicherwert für die COLOR-Parameter, wie gesagt, von vornherein ziemlich unwahrscheinlich) zum TED-Register ausschließen.

Das Bit 1 der Luminanz wird im Bit 5 des Registerwerts übertragen. Da andere Funktionen augenscheinlich nicht beeinträchtigt sind, kann eine fehlerhafte Datenbusverbindung ebenfalls nicht die Ursache sein. Denn dann ließe sich z.B. der Cursor nicht mehr an allen Stellen positionieren.

An einem C64 hatte ich mal einen ähnlichen Fehler, hier konnten in eins der Farbregister auch nur noch 8 verschiedene Farben ge-POKE-d werden, da hing dann auch ein Bit ständig auf 0. Das ist dann in beiden Fällen ein teildefekter Videochip, und ich kann dir nur die Daumen drücken, daß es dabei bleibt.