Hallo beieinander.
Vor einiger Zeit hatte Lance Ewing im Denial-Forum schon mal den 6561 Die zwischengehabt:
6561 Die Shot Reversing Explorations
Tobias, ich hab' jetzt mal mathop's Analyse des Luma-Schaltkreises in den Denial-Thread gesteckt um Lance anzuspitzen. Besser die Kräfte bündeln als nebeneinander her braggeln.
Viele Grüße,
Michael
Hi, Ruudi,
so DRAM-Karten am VC-20 sind jetzt nicht so völlig unbekannt, im Denial-Forum sind die öfter schon aufgetaucht:
http://sleepingelephant.com/ip…pic.php?t=9710&hilit=DRAM
http://sleepingelephant.com/ip…pic.php?t=8770&hilit=DRAM
http://seepingelephant.com/ipw…t=868&start=20&hilit=DRAM
http://sleepingelephant.com/ip…pic.php?t=8371&hilit=DRAM
http://sleepingelephant.com/ip…=6358&start=15&hilit=DRAM
Hab auch noch nicht die Beschaltung analysiert, ob die den Refresh autark hinbekommt, oder
dazu Hilfe von einem in den System-IRQ einzubettenden Programm braucht (was das System ja letztlich langsamer machen würde...)
Ein kleiner Teil der Beschaltung kümmert sich um eine Adreßumkodierung (BLK1..3 und BLK5 in ein neues "A13" und "A14"), der Rest macht den Refresh. Dazu ist zwischen den CPU-Zugriffen genug Zeit, der VC-20 wird also nicht ausgebremst. Da der Videochip generell keinen Zugriff auf den Expansionport hat, ist auch von der Seite kein Problem vorhanden (heißt, es gibt keine Kollisionen zwischen Video-Zugriff und DRAM-Refresh, weil von vornherein überhaupt keine Videodaten von einer Cartridge geholt werden können).
Viele Grüße,
Michael
Nachtrag: hier ist zum Vergleich ein PNG mit der so ermittelten Palette. Die kann man neben die Farbstreifen aus dem Foto "halten" und sich so einen Eindruck von der relativen Helligkeit der Farben und dem Farbeindruck machen. Bei der originalen VICE-Palette waren z.B. die Orangetöne und Hellrot ziemlich daneben, auch das Cyan vom Rahmen sah anders aus (zu dunkel!):
VICE Original:
Mike PAL:
Zum Schluß zum Vergleich noch die "Mike NTSC"-Palette, die ich auch mit o.g. Methode ermittelt hatte. Ja, die ist wirklich so schräg. Hellorange, Hellrot und Hellviolett kann man kaum voneinander unterscheiden und insgesamt wirkt sie auch 'kälter':
Mike NTSC:
vermutlich weiß es Mike
http://sleepingelephant.com/ip…topic.php?t=3101&start=23
Grob übersetzt: "Mit einer völlig beliebig zusammengestellten Kombination aus Torstens VC-20 (frisch von mir und einem Arbeitskollegen umgebaut mit S-Video mod), einem 1084 mit 'brauchbaren' Einstellungen von Helligkeit, Kontrast und Farbsättigung und meiner Fuji S5800 habe ich die Ausgabe von 'ColourTest' fotografiert, da werden alle 16 Farben angezeigt. Schnipsel der Farbbalken habe ich zuerst gemittelt, was zunächst recht maue Farben ergab (wg. Lochmaske und Elekronenstrahl-Gaußprofil => Scanlines). Diese 16 'vorläufigen' Farben habe ich dann gegen 'Weiß' und 'Schwarz' kalibriert, d.h. in jedem Farbkanal (linear) auf gleiche Weise so gestreckt, daß Weiß bei (255,255,255) und Schwarz bei (0,0,0) herauskamen. In einigen Fällen (Blau und Purpur) gingen dabei Farbkomponenten leicht aus den Bereich 0..255 heraus, die wurden dann geclippt."
Das Ergebnis war dann für mich subjektiv wesentlich näher an der Bildschirmausgabe dran als die damals mit VICE original verwendete Palette (das war noch bevor die CRT-Emulation eingebaut wurde!) und die Palette verwende ich auch nach wie vor in meinen VFLI-Konvertern.
Leider habe ich das Projektverzeichnis zu dieser Berechnung nicht aufbewahrt, ich würde aber auch die Rechnung heute etwas anders durchführen: zuerst das Foto von sRGB nach linear-RGB wandeln, damit dann die Mittelung der Farbschnipsel und Streckung ausführen und erst zum Schluß die Palette wieder nach sRGB wandeln. Es kämen vermutlich geringfügig andere RGB-Werte raus, aber da o.g. Kombination ohnehin schon ziemlich beliebig war, macht das wohl nicht viel aus und lohnt m.M.n. nicht unbedingt.
Viele Grüße,
Michael
P.S. Hier ist das Foto. Die "Farbschnipsel" wurden zwischen den Schachbrettern und den Farbnamen entnommen:
Könnte vielleicht auch am €40,-- LCD Display liegen....war zu faul den 1084 herzuräumen
Die zerrissenen Pixel hast Du auch mit dem 1084, ich kann das aus eigener Erfahrung bestätigen.
Das Composite-Signal des VC-20, speziell der CR-Platine, ist einfach Schrott. Nur Weiß, Schwarz, (Hell-)Blau oder (Hell-)Gelb sind unproblematisch, aber der Rest ...?
Gerade wenn man wie in den Beispielbildern oben auf einmal ein paar mehr Farben in nächster Nähe beisammen hat, kann man das nicht mehr ignorieren. Dann sollte das Bild schon so Richtung Monitor geschickt werden, wie es sein soll - und nicht wie die originale Video-Verstärker-Schaltung es meint. 
VG,
Michael
Hier gibt's noch ein anderes Bild zum begucken:
... 
Danke, HoP!
Also geht das Bild grundsätzlich mit der Penultimate(+). Das läßt mich jetzt vermuten, daß bei dem VC mit dem Bugreport tatsächlich RAM im unteren 1K defekt ist, irgendwo im Bereich des Tapebuffers. Sowas ist tückisch, weil es eben nicht sofort auffällt; der RAM-Test im KERNAL checkt das auch nicht.
Sonst sehe ich, daß sich bei dir ein S-Video mod durchaus lohnen würde: gerade die roten Pixel in der oberen Hälfte des Berges sind arg zerrissen und das Dither-Pattern am oberen Rand des Bilds fährt Schlangenlinien.
Viele Grüße,
Michael
So sieht das Bild übrigens in echt auf meinem VC-20 mit S-Video mod aus ...
... 
Tag beisammen.
Hat einer der Leser eine Penultimate Cartridge am Start und könnte das angehängte Bild mal auf seinem VC-20 ausprobieren? Es müssen mindestens +24K RAM als Speichererweiterung vorhanden/eingestellt sein:
Auf dem Bildschirm erscheinen links und rechts von der eigentlichen Anzeige noch farbige Streifen im Rahmen, das ist ganz normal. Das Bild hat 104x256 Pixel. Auf meinem eigenen VC und in Emulation paßt alles. Mir ist aber eine Rückmeldung untergekommen, wo unten im "Nebel" deutlich ein weißer Fleck sichtbar ist. Jetzt geht es darum herauszufinden, ob das jetzt evtl. an defektem RAM (auf der Cartridge?) oder an irgendwelchen Wedges, Schnellladern oder File-Browsern liegt. Ideal wäre daher ein Test, wo außer der Speichererweiterung der Penultimate sonst nichts aktiv ist.
Schon mal Danke im Voraus. 
Michael
P.S. für welches Spiel wäre das ein dankbares Titelbild (auch wenn die in-Game Grafik nichts taugt ...)?
Kann man sich nicht zusätzlich noch ein paar Kopieraktionen sparen, wenn Strings mit den Längen 1 und 2 (und 0 natürlich ohnehin) erst gar nicht im String-Heap abgelegt werden sondern nur im Deskriptor-Pointer 'leben'?
Ab String-Länge 3 geht dann der Tausch "Descriptor-Pointer gegen zwei End-Bytes im String" problemlos, wird ein String gelöscht geht immer die Markierung mit $FFxx an dessen Ende, und die Sonderfallbehandlung für Strings der Länge 1 fällt weg.
Oder hab' ich da was übersehen?
Da gab's vor drei Jahren hier im Forum64 mal 'ne richtig erhitzte Diskussion drum: 
Ich probier's mal:
Auf dem Desktop liegt ein frisches Verzeichnis mit dem Namen "Patch", da hab ich gerade "patch.prg" aus meinem Post-Attachment im Ursprungsthread und die Datei "basic" aus dem C64-Verzeichnis von VICE hineinkopiert:
In x64 nimmst Du jetzt folgende Einstellungen vor: TDE (True Drive Emulation) aus und Virtual Device Traps ein. Das ermöglicht VICE den Zugriff auf das Host-Dateisystem derart, daß ein PC-Verzeichnis als "Diskette" gemountet werden kann:
Die Autostart-Settings änderst Du nun derart, daß eine in das Hauptfenster von VICE gezogene Datei automatisch das drumherum liegende Verzeichnis als Diskette mountet: "PRG autostart mode: Virtual FS".
Als letzte Vorbereitung nimmst Du noch das Häkchen aus "Write P00 files" heraus. Das macht nur Ärger.
Jetzt ziehst Du einfach "patch.prg" in das Hauptfenster von x64. Das Verzeichnis "Patch" mit "patch.prg" und "basic" drin wird automatisch gemountet und nach kurzer Zeit (die Du gerne mit Settings > Maximum Speed > No Limit verkürzen kannst) steht dann auch die Datei "basic-p" drin:
Nun kopierst Du "basic-p" in das C64 Verzeichnis von VICE:
In "Settings > ROM settings ..." gibst Du den Namen des gepatchten BASIC-ROMs an:
... und nun zum Test. Eine der Multiplikationen zeigt mit dem originalen BASIC-ROM ein falsches Ergebnis an:
"basic-p" eignet sich direkt dazu, auf dem PC in ein passendes EPROM gebrannt zu werden.
Viel Erfolg!
Michael
In den VICE-Directories steht m.W. erst mal nur das originale BASIC-ROM drin, sollte sich das mit einer neueren Version geändert haben? Diese Datei wäre dann aber die, auf die Du den Patch anwenden würdest.
Auf jeden Fall kann man in den Einstellungen auch ein alternatives BASIC-ROM angeben, das "läuft" in meinem emulierten VC-20 und C64 auch immer mit. In meinem echten VC-20 ist es auch in echt drin.
... cool, dass Du den "Römer" erkannt hast ...
Ich war mir schon ziemlich sicher, hab aber TinEye um eine zweite Meinung gebeten.
Salve, Cäsar!
Gefunden hier im Forum habe ich einen Fix als PRG-Datei [...]
Nur rein interessehalber - es handelt sich bei dem Fix nicht zufällig um meinen Patch für die ver-bug-te Fließkomma-Multiplizierroutine?
Das Programm um ein bereits abgespeichertes *.bin-File (also, pure Daten ohne den 2-Byte-Header mit der Ladeadresse) des BASIC-ROMs zu patchen hatte ich ja hier gepostet, nicht aber das bereits gepatchte BASIC-ROM, aus gutem Grund: es gibt nämlich einen aktiven Rechte-Inhaber, der den Daumen auf dem originalen ROM drauf hat.
Du findest das *.bin-File aber in einer aktuellen Fassung von VICE. Mein Patch checkt auch, daß er gerade die richtige Datei bearbeitet.
Viele Grüße,
Michael
Ohne zumindest ein bischen Fachchinesisch auszuhalten wirst Du wohl kaum auf einen grünen Zweig kommen.
Auch wenn Du nicht verraten willst um welches Motiv es sich handelt wäre z.B. interessant wie groß das Bild ist (nicht in KB, sondern Breite und Höhe in Pixeln), damit eingehend das Bildformat (nicht gemeint, welcher Dateityp, sondern Breite-Höhen-Verhältnis). Beim C64 ist die Ausgabe mit 320x200 (oder 160x200 in Multicolor) festgelegt - kennst Du dich mit IrfanView *) genügend gut aus, daß Du einen geeigneten Ausschnitt deines Bildes auf 320x200 bekommst? So, daß das Motiv noch erkennbar ist? Dann: der C64 hat nunmal nur 16 Farben. Ist dein Bild farbig, oder in Graustufen oder gar nur eine Liniengrafik? Von solchen Bedingungen hängt dann ab, wie Du weiter vorgehen mußt. Ein Patentrezept gibt es hier nicht. Die C64-Grafik ist so viel schlechter als alles was ein PC heute kann, daß Du beim 'Runterrechnen' immer Kompromisse eingehen mußt.
Wenn das alles dann mal geklärt ist, gibt es dann schon brauchbare Tools. Die eigentliche Anzeige auf dem C64 ist, sobald die gewandelte Datei vorliegt, ein rein programmiertechnisches Problem - das lösen wir zwischen dem ersten und zweiten Frühstück.
VG,
Michael
*) oder irgendein anderes, auf den PC oder Mac laufendes Bildbearbetungsprogramm
Ich würde das so angehen: [...]
Es gibt bei diesem flexiblen BASIC-Stub nur noch ein kleineres Problem in Bezug auf VICE: standardmäßig ist die Load-Option beim Autostart auf LOAD"*",8,1 gesetzt. Heißt, mit dem 'falschen' gesteckten Speicherausbau landet der SYS nur an der Ladeadresse aus dem PRG-File-Header und nicht an dem BASIC-Start, der durch den Speicherausbau vorgegeben ist. Damit findet der RUN-Befehl nichts was er gescheit ausführen kann. Da nutzt also jegliche Programmiertechnik, die relokatiblen Code erzeugt (oder erzeugen kann) einfach mal gar nix.
In der Praxis wird es wohl nur darum gehen, daß man Programme für den nicht erweiterten VC auf robuste Weise ans laufen bringt, obwohl eine Speichererweiterung 'gesteckt' ist und VICE einem zusätzlich Knüppel zwischen die Beine wirft. Der umgekehrte Fall ('großes' PRG auf kleiner Maschine) wird aufgrund des zu erwarteten Speichermangels wohl kaum praxisrelevant sein.
Das folgende Programm schreibt einen Bootloader auf Disk. Wenn dieser Bootloader mit ",8,1" geladen wird, schaltet er vorhandene Speichererweiterungen ab, lädt ein frei wählbares Programm nach und startet es automatisch.
Lädt man ihn (doch) mit ",8", dann sieht man nach LIST so einen BASIC-Stub, wie tokra ihn beschrieben hat. Das dadurch gestartete Maschinenprogramm *ist* relokatibel und startet wiederum den gewünschten Payload mit abgeschalteter Speichererweiterung:
Für den Fall, daß das Nutzprogramm doch eine bestimmte Speichererweiterung braucht, kann ein zuerst nachgeladenes Programm erst einmal testen, ob der Erweiterungspeicher auch existiert, dann den Speicher wieder expandieren und dann das eigentliche Zielprogramm laden und starten.
Viele Grüße,
Michael
Faszinierend. Hätt ich so echt nicht erwartet. Aber da sehen wir wie teuer solche Array-Zugriffe sind.
In einem anderen Thread war M. J. einem ähnlichen Phänomen auf den Grund gegangen. Da war eine mit HYPRA-COMP kompilierte Linienziehroutine nicht so schnell, wie sie hätte sein können, obwohl die Adreßberechnung durch einen Table-Lookup sowohl in BASIC als (grundsätzlich) auch für das Kompilat schon ziemlich eingedampft/optimiert worden war:
Daß Deine kompilierte Version im Vergleich zur VM so langsam ist, kam mir ein wenig komisch vor und ließ mir keine Ruhe, so daß ich der Ursache anhand des laufenden Code in Vice auf den Grund gehen mußte. Dabei stieß ich dann (leider wie erwartet) auf eine starke Bremse: Die Indexberechnung für das Array verwendet die Routine im Basicrom ab $b34c, die eine 16 Bit-Multiplikation beinhaltet. Mit anderen Worten: Für jeden einzelnen Punkt, der gesetzt wird, wird auch eine Multiplikation durchgeführt anstelle eines einfachen Verschiebens der Indexbits. Welch Wunder also, daß die Routine so langsam ist. Hätte der Compiler diese Indexberechnung optimiert, wäre deine Version wesentlich schneller.
Auch aus diesem Grunde wäre es sinnvoll, einen Vergleich mit dem gcc durchzuführen, denn dort sollten derartige Optimierungen eigentlich vorgenommen werden.
Heißt, diese generische 16-Bit-Multiplikation wirkt auch hier als Bremse. Eine spezielle Multiplikation für ein 1D-Array mit 5 (Fließkomma) oder 2 (Integer) Bytes pro Element wäre es gewesen.
Ich hätte noch DIM X%(400),Y%(400) nehmen können, um den Speicherbedarf der Arrays zu verkleinern, aber dann kommen noch mindestens zwei weitere Integer<->Float-Umwandlungen pro Schleifendurchlauf dazu ... und das ist dann noch langsamer:
4) Einlesen mit READX%(T),Y%(T): 254 Jiffies. Zeichnen mit X=X%(T):Y=Y%(T): 3093 Jiffies.
Der erste Teil ist also klar noch mal langsamer (Float->Integer-Wandlung), beim zweiten Teil 'kürzt' sich vermutlich die zusätzliche Integer->Float-Wandlung genau dagegen weg, daß die Multiplikation mit 2 statt mit 5 eine 16-Bit-Teil-Addition weniger braucht.
Liest er dann während des Zeichnens oder erst alle aus und dann erst? Wär interessant, wieviel Overhead das READ verursacht.
Ich hatte das gar nicht in Betracht gezogen, aber gerade ausprobiert. Dazu muß man natürlich alle Koordinaten in zwei großen Feldern mit DIMX(400),Y(400) speichern.
1) Die rekursive Version braucht 5756 Jiffies.
2) Auslesen mit READX,Y während des Zeichnens braucht 3048 Jiffies.
3) Bei deinem Vorschlag schlägt das Einlesen mit READX(T),Y(T) schon mal mit 246 Jiffies zu Buche. Das anschließende Zeichnen, in dem die Koordinaten dann mit X=X(T):Y=Y(T) aus den Arrays übernommen werden, ist dann - unerwarteterweise - mit 3092 Jiffies langsamer! In der Summe, 3338 Jiffies.
Während schon zu erwarten war, daß die Gesamtzeit von 3) mit 3338 über 2) mit 3048 liegt, sind schon die zwei Arrayzugriffe X=X(T):Y=Y(T) teurer als READX,Y mit dem notwendigem Parsen der DATAs in das Fließkommaformat. Das hat mich jetzt schon etwas überrascht.
Zusammen damit, daß bei 3) auch noch die zwei großen Arrays fast 4 KB extra brauchen ohne irgendeinen Vorteil zu bringen, ist 3) damit wohl aus dem Spiel.
Ja klar, aber wär der Teil mit der Parameter-Übergabe in Maschinensprache gelöst (Soft Stack), wär es noch schneller.
Ich habe zum Vergleich auch eine Version geschrieben, welche die Koordinaten aller 400 Voxel einfach aus DATA-Zeilen ausliest. Damit ist der rekursive Overhead zwar komplett eliminiert, aber natürlich zeigt das dann die rekursive Natur des Menger-Schwamms auch nicht mehr. Das bringt etwa den Faktor 2 an Geschwindigkeit.
Ähnliches gilt für parametrisierte Unterprogramme (Prozeduren oder Funktionen, wie man sie halt nennen will). Da könnte man allerdings zu einem Trick greifen, und einfach einen zusätzlichen Software-Stack definieren, auf dem man Parameter übergeben kann. Das wäre dann natürlich ein Zusatz-Aufwand, und langsamer, aber langsamer als was? Langsamer als die üblichen BASIC-Variablen natürlich, aber will man in einem BASIC-Programm heute einen Stack einbauen, muss man sowieso ein Array dafür definieren, und dann hat das noch dazu nur einen festgelegten Typ, und das wäre noch viel langsamer und braucht mehr Programm-Code.
Man siehe mir bitte nach, daß dieses Beispiel für den VC-20 (mit mindestens +8K Speichererweiterung) ist, aber so ein Software-Stack funktioniert verblüffend gut. Es wird ein Menger-Schwamm mit der Iterationstiefe 2 gezeichnet. Mehr gibt die Grafik-Auflösung ohnehin nicht her:
Hier ist das zugehörige BASIC-Programm. Die Grafik läuft über eine eigene BASIC-Erweiterung, MINIGRAFIK:
Die Unterroutine ab Zeile 15 wird mehrfach rekursiv aufgerufen, und die Zeilen 21 und 23 'beackern' den Software-Stack.
Der eigentliche Clou m.M.n. ist allerdings, daß das GOSUB in Zeile 22 tatsächlich als Barriere auf dem CPU-Stack wirkt und die FOR-Schleifen trotz gleicher Variablen-Namen auch erneut angelegt werden! Die ursprüngliche Version hatte die FOR-Schleifen noch händisch mit IF...GOTO nachgebaut, die Version hier ist kürzer, nutzt den CPU-Stack jetzt aber fast zur Gänze aus.
Viele Grüße,
Michael
P.S. hier ist das Original: Heute so gecodet... ...
