Hi und frohes neues Jahr,
und passend dazu: alle ELV-Magazine sind seit ein paar Tagen in PDF-Form zum runterladen kostenlos bereitgestellt worden.
Beispiele:
- regelbare Netzteile (z.B. 0-30V, 0-2A), teils per PC steuerbar etc.
- Atari-ST und Amiga Genlock-Interface-Karte
- Video Wandler (FBAS-RGB, RGB-FBAS, SVideo-XYZ etc.)
- Video Digitizer
- AD/DA/LA-Karten
- Lötstationen
- Vollverstärker
- uvm
.. bis 1993, Rest muss ich noch ĂĽberfliegen.
Viel Spass
Kult oder Trash?: "Atztec Challange" (schon erwähnt), "Caverns of Kafka" und "Beyond Forbidden Forest".
"Atztec Challange" hat bei mir länger als 1h zum Durchspielen gedauert. Die Piranhaszene war auf SW-Fernsehern
nicht spielbar.
"Caverns of Kafka" wegen der hackeligen Steuerung. Longplay auf Youtube ist aber unter 10min.
"Beyond Forbidden Forest" hatte ich nur angespielt.
Gemeinsam ist allen Dreien eine nervige Musik, die aber irgwie schon wieder triggert.
- 50Hz Bildwiederholfrequenz (nicht zu verwechseln mit der Netzfrequenz! Einen 100Hz-Fernseher kann ich NICHT gebrauchen!)
Der Beitrag ist zwar schon alt, da du aber noch mitliest:
Warum keine 100Hz? Ich habe mir noch zwei 100Hz-Fernseher von Nachbarn gesichert, die
sich kurz nach dem Kauf einen TFT gekauft hatten. Beide hatte ich ausgibigst am C64/C128
getestet (inkl. eigener Scrolling-Testprogrammen, eben wegen der 100Hz) und war eiglich
total begeistert. Farben super und Scrolling total weich.
Das mit den 4:3: stören dich die schwarzen Balken bei 16:9?
Was ist mit Fort Apocalypse? Da gabs im zweiten Level zwei Möglichkeiten zum
Ziel. Der erste ist der ĂĽber einem Raum gefĂĽllt mit Pins, die man abschiessen
musste. Der zweite geht ĂĽber einen Raum mit Panzern am Boden und Laserschranken
an den Wänden. Den zweiten fand ich wesentlich schwieriger.
Ausgewählt wurde doch über Zufall => unfair!!
Fort Apocalypse definitiv, mmn auch Choplifter, wenn auch knapp.
Ja, genau das ist es, danke Dir.
Ich habe mir gerade mal die Youtubevideos zu CPC und C64 angeschaut.
CPC gefällt mir besser, ruckelig wirken aber beide. In der Doku Gestern
hatte ich eigentlich einen relativ guten Eindruck, aber nach den beiden
Youtubevideo bin ich eher ein wenig enttäuscht, schade.
Und: ich hatte nur Fotos geschossen. In der Doku (ĂĽber London/Architekktur des letzten Jahrhunderts)
sieht das Spiel sehr ruckelig aus. Hm, irgenwie nicht so ganz C64, aber man weiss ja nie.
Sieht aber fĂĽr mich eindeutig nach 8Bitter-Spiel aus.
Ich hatte Gestern noch zwei Fotos von einem Spiel gemacht, an das ich mich nicht erinnern kann,
es jemals gesehen zu haben. Es ist in etwa wie 1942 etc. Kennt das jemand hier?
Und: wie heiss ĂĽberhaupt diese Spielegattung?
Links zu BĂĽcherdownloads sind hier nicht gerne gesehen, deshalb noch ein Tipp:
Es gibt eine Seite, auf der zig Retro-Computer inkl. BĂĽcher, Magazine und Manuals
gelistet sind. Da ist auch eine Seite zu VC20 dabei. FĂĽr dich interesant sind
BĂĽcher zum Mapping, VIC, IO, etc. Ist allerdings alles auf Englisch.
P.S. hast du schon mal was von Bombjack gehört.
Die Grundlagen fĂĽr meinen C64-Assembler-Einstieg waren:
- das Buch Das Maschinensprache Buch zum Commodore 64
- ein einfaches Monitor/Assembler Programm (bei mir: TIM aus C64 portiert)
- und viele Artikel aus den C64-Magazinen
Erst viel später kamen dann Makro-Assembler, selbstgebaute Generatoren
etc. dazu.
Das Buch war zum grössten Teil eine 6502/6510-Einführung, zum
Schluss erst ein paar c64-spezifische Geschichten. Für dich wäre
da das VC-20 intern die bessere Wahl. Da steht der komplette Aufbau
inkl. ROM-Listing drin, d.h. alles, um auch praktisch zu arbeiten.
NVidias erster Chip (NV1) waren auch beide Quad-basiert
NVidia's NV1 hatte sogenannte quadratic Surfaces zur Darstellung/UnterstĂĽtzung von NURBS,
was nichts mit quad-basierten Tiles zu tun hat. Im Prinzip wurden Bezierflächen vom (glaube ich)
absoluten Grad 2 gezeichnet. War auch revolutionär, aber leider eine marktwirtschaftliche
Sackgasse.
Was mir eben noch eingefallen ist: Caverns of Kafka
Edit: hab mir gerade das Longplay-Video angeschaut. Nicht nur dir Graphik,
auch die Animationen sind echt schlecht. Ich finde/fand das SPiel aber gar
nicht mal so schlecht.
Edit2: weiter Untern findet sich noch ein Link auf die Atari800er Version.
Die sieht ja wirklich gewil aus!! Schade, schlecht umgesetzt.
Danke für die Links, werde mir die Videos in der nächsten Woche mal anschauen.
Im Artikel zu Al Charptentier stehen ein paar interessante Infos, so wurde z.B.
das Gehalt bei MOS wegen der nichteingehaltenen hohen Erwartungen von Tramiel
reduziert, statt kräftig in Bonus und in Arbeitsklima zu investieren. Man muss ja
dabei an den umglaublichen Erfolg des C64 (auch VC20 und PET) denken ...
so kann man eine Firma zugrunde richten.
Das mit dem Bonus hatte ich schon frĂĽher gelesen, die Gehaltsreduzierung war mir
aber neu. Hier muss auch erwähnt werden, dass eine von Tramiels Firmenphilosophie
die war, Geschäftspartner immer respektvoll zu behandeln, wozu auch die Bezahlung
der Leistungen gehörte. Dabei sollte immer so viel bezahlt werden, dass dem Gegenüber
mindestens die Existenssicherung garantiert wurde. Diesen Teil hatte er wohl in seiner
eigenen Firma nicht so umgesetzt, schade! Naja, eine seiner Philosophien war ja, das
Geschäft Krieg ist...
Wenn man generell mit irgendwas weiterkommt, sind es gerade die RMW-Opcodes, da die CPU beim DMA-Request des VIC noch eventuelle Schreibzyklen des aktuellen Befehls beenden darf, und die RMW-Opcodes enden auf zwei Schreibzyklen.
Da passen dann eventuell mehr Befehle in die freien Bereiche, aber eigentlich in diesem Fall auch nur, wenn man Sprite 0 benutzt. Da geht dann nur INC $D016 o.ä., um den Border aufzumachen.
Bei INC $D016 etc. kennt man ja beim ersten mal nicht den Inhalt der entsprechenden Register.
Nach ein paar mal ergibt sich aber doch eine bestimmte Sequenz an Werten, je aus READ und
fĂĽr WRITE. Kann man diese Sequenzen nicht in einfache Codeschnippsel giesen und so auf
RMW verzichten? Im Idealfall erhält man nur WRITE-Zugriffe?
In der Summe ist das jetzt also ein Monitor, der die meisten Funktionen von VICMON und HESMON statt in 4 KB in nur 2 KB unterbringt, aber im Gegensatz zu den beiden auch sauber mit BASIC und KERNAL zusammenarbeitet.
Hast du den Code arg quetschen mĂĽssen, um von 4KB auf 2KB zu kommen? Ist das leicht zu erreichen?
Und mal vielen Dank fĂĽr die ausfĂĽhrliche Beschreibung, ich hatte schon lange mal vor, selbst
einen einfachen Monitor zu schreiben. Ziel ist aber hauptsächlich die Verwendung in FPGA-Umbegungen,
da muss dann aber der I/O-Teil komplett ohne KERNAL-UnterstĂĽtzung auskommen. Werde mich also
mal ausfĂĽhrlich lesend an Deinem Code austoben.
Sehr schönes Projekt. Hast Du den Monitor/Assembler selbst geschrieben? Falls ja,
ist der Sourcecode verfĂĽgbar?
Ich gehe mal stark davon aus, dass Du die Software geschrieben hast, weil die
Umleitung von Input/Output in glaube ich keinem der kleinen Monitoren eingebaut
ist. Mit meinen Assemblerkenntnissen ist es eher kein Problem, den Assembler
und Disassembler (plus zugeh. Tools wie Move, Erase, Fill, etc.) zu schreiben.
Da ich mich aber nie fĂĽr das OS interessiert habe, sind Tools wie LOAD, SAVE und
VERIFY eher schwer fĂĽr mich zu implementieren. Ich gehe mal davon aus, dass
diese Tools auf das OS zugreifen. Damit mĂĽsste sich Dein ROM doch auch mit wenig
Aufwand auf den C64 ĂĽbertragen lassen?
Leider bin ich zZ sehr in Renovierungsarbeiten eingespannt, habe also nur Abends mal eine
Stunde oder am Wochenende Abends mehrere Stunden Zeit, Antworte also immer ein bischen
spät auf Fragen.
Warum interessiert die Amplitude des Color Burst nicht? In PAL ist diese ansich festgelegt. Ich bin kein Fensehtechniker, aber
Fernsehtechniker bin ich auch nicht (musste mir am Montag und Dienstag Abend die notwendigsten
Docs+Specs zu PAL durchlesen), aber fĂĽr den C64 brauchts ja nur einen Schwellwert, um zwischen
Farbe und S/W/Grau zu unterscheiden.
Am Donnerstag Abend hatte ich aus den Specs den Grundrahmen und den Ansatz zur Berechnung
der Amplitude und der Phase aus dem Burst zusammengestellt. Aus den Specs zu PAL und der
Auflösung des C64 ergibt sich folgendes
- 4,4MHz Burst-Frequenz, ein Vielfaches als Samplingfrequenz fĂĽr den ADC (z.B. 20*4.4=88MHz oder
22*4.4=96.8MHz). Ich wähle für die folgenden Überlegungen 96.8MHz als Samplingfrequenz.
- für 96.8MHz erhält man je Pixel 12 Samples, ein entsprechend kleiner gewählter Rahmen hat nur
6 Samples. Der Rahmen muss wesentlich kleiner gewählt werden, da zu Pixelbegin und -Ende noch
Farbübergänge des letzten/nächsten Pixels enthalten sind.
- die Aufgabe ist also, aus diesen 6 Samples je Pixel (und des Bursts am Zeilenanfang) die Phase
zu bestimmen:
- das mache ich per einfache Approximation, indem ich das Signal s in Form
a*cos(t)+b*sin(t) darstelle (lineare Approximation in L2, d.h. umgangssprachlich auch oft
Bestapproximation genannt).
- aus den beiden Parametern a und b wird, wiederum durch Approximation, die Phase und die
Aplitude bestimmt (Amplitude = a^2+b^2, Phase=atan2(b,c))
Die erste Approximation ist denkbar einfach, die Vektoren sin(t) und cos(t) fĂĽr die Samplingzeitpunkte
t0..t5 lassen sich ja einfach berechnen, so dass man die Darstellung A*[a,b]=s erhält. Durch Umstellung
erhält man so [a,b]=(A^T*A)^(-1)*A^T*s(t) (A^T ist die Transponierte, A^(-1) die Inverse zu A).
Da das ganze ja in einem FPGA werkeln muss, setzt man zuerst A1:=(A^T*A)^(-1)*A^T (wird oft als
Pseudoinverse von A genannt), dann A2=ganzzahl(A1*2^(bits-1)) (bits: Rechengenauigkeit fĂĽr
Integerarithmetik). Man erhält damit mittels einfacher Ganzzahlarithmetik [a_int,b_int]. Mit z.B. 8 Bits
Rechengenauigkeit erhalte ich so max 5 Prozent absolute Abweichung, mit ein wenig Rauschen
(z.B.2 Prozent) weniger als 10 Prozent. Bei 9 Bits weniger als 2.5 Prozent bzw. 5 Prozent. Damit lässt
es sich leben. (das Verfahren zur Bestapproximation wird in jedem Numerikbuch beschrieben, ist
denkbar einfach)
Im zweiten Schritt wird das [a_int,b_int] in Amplitude und Phase umgerechnet (d.h. a^2+b^2 bzw.
atan2(b,a); atan2(a,b) wäre genauso möglich, ist aber egal). Aus gewissen Symmetrieeigenschaften
kommt man schnell auf eine Aufteilung in Sektoren, ich habe mich, ähnlich zu Bressenham, zur
Achtelung entschieden und bin zum Ergebnis gekommen, dass eine Approximation mit 2D-Polynomen
vom absoluten Grad 1 ausreicht. Man erhält also atan(b,a)=p00+p10*a+p01*b. pij sind per
Approximation einfach berechenbar.
Bis jetzt habe ich nur eine erste "Fassung" eines Skripts, die noch ĂĽberarbeitet werden muss. Im Anhang
habe ich mal Bilder zusammengestellt, die die Atan2-Approximation veranschaulicht. Die ersten beiden
Bilder zeigen die Funktion als Flächen- und als Kontour-Plot, die beiden letzten die Plots der Abweichung
der Approximation zum Orginal. Die in den letzten Bildern eingezeichneten tĂĽrkisenen Punkte liegen
alle auf dem Einheitskreis, d.h. sollten NULL Abweichung aufweisen. Ausserdem sollten in der Umgebung
der Punkte die Abweichung möglichst wenig ansteigen. Bei mir ist die Steigung etwa 0.5, d.h. je Prozent
Abweichung in der Amplitude der Punkte erhalte ich 0.5 Prozent Anstieg des absoluten Fehlers. Auch damit
kann man leben.
Was jetzt noch vor einer Implementierung in HDL (VHDL oder Verilog) gemacht werden muss, ist es,
die zu approximierenden Punkte auf dem Einheitskreis an die "richtigen" Grössenordnungen anzupassen
und die Koeefizienten der Approximationen neu durchzurechnen. Inkl. Automaten, Polynomberechnungen
plus Testbenches ca. 1-2 Monate Aufwand. Dann noch die Platine mit ADC. Aber ob dazu einer hier
bereit ist..?
Aber der c0pperdragon schafft es ja auch irgendwie, die Signale zu erkennen.
https://github.com/c0pperdragon/C64-Video-Enhancement
Im Grunde ist das Ziel hier ja sehr ähnlich. Ein "externer" c0pperdragon ohne Modifiaktionen am C64, mit HDMI Ausgabe.
Wie schon gesagt, wird hier ja nicht das analoge Signal eingelesen, sondern das
Digitale am VIC-Eingang. Dann wird mittels VIC-II-Emulator (in HDL fĂĽr FPGAs)
ein Bild synchron nachgebaut und per Wandler fĂĽr HDMI aufbereitet und ausgegeben.
Wenn man die HDL-Files ĂĽberfliegt, dann hat man sehr schnell die Vermutung,
dass eine, gelinde gesagt, spärliche Version verwendet wird. D.h. es wird nicht
alles so angezeigt, wie es zu erwarten ist. (und auch hier: ob HDMI oder VGA
oder was auch immer als Ausgabe gewählt wird, ist eigentlich egal)
Was wir halt nicht vergessen dĂĽrfen ist, dass es sich um analoge Signale eines Chips handelt, der Ende der 70er entwickelt wurde.
Ja, genau: die Signale sind nicht nur werteanalog, sondern auch zeitanalog. D.h., je
Zeile hat man einen kontinuierlichen Signalverlauf, der auch zeitanalog gewandelt
und auf dem Bildschirm angezeigt wird. Damit sind z.B. auf horz. Ebene Sampling
und entsprechende Skalierungsoperationen, wie sie für höhere Auflösungen von
TFTs notwendig sind, ĂĽberflĂĽssig (naja, gilt fĂĽr SW-Monitore, fĂĽr Farbe hat man
ein Raster und damit eine Art Zeitdiskretisierung). Ausnahme ist aber der vertikale
Verlauf, hier muss die Anzahl der Zeilen gleich der des Bildschirms sein, oder z.B.
per Wiederholung mehrfach angezeigt werden.
Von Pixel zu Pixel springen die Signale nicht unendlich schnell an, sondern haben Ansprech- und Abschwellzeiten, Unter- und Ăśberschwinger. Das dĂĽfte mit ein Teil der Herausforderung sein, solche Signale dennoch richtig zu erkennen.
Wenn man z.B. regelmäßige Farbmuster hat, kommt es nicht selten vor, dass sich daraus ein Störmuster ergibt.
Genau deshalb ahme ich ja auch das nach, was in einem Videochip so vorsich geht:
Per hoher Samplingrate nicht nur das LUMA-Signal, sondern auch das CHROMA-Signal
zu samplen, den darin enthaltenen Burst abzufangen, auszuwerten um damit je
Pixelposition ebenfalls enthaltenen Burst in eine Phasen- und Amplitudeninformation
umzuwandeln.
Der Ablauf ist in etwa wie folgt:
- 1. zuerst wird ein horz. Sync eingelesen
- 2. nach kurzer Zeit folgt ein Burst. Dieser wird hochfrequent gesampelt und in eine
Phaseninfo (Phase 1) umgewandelt (Amplitude interessiert nicht)
- 3. wiederum nach kurzer Zeit beginnt dann der Pixelstrom. Und hier ist es extrem
wichtig, nur in einem kleinen Fenster innerhalb des Pixels den Burst auszulesen
und dessen Phase+Amplitude (Phase2) auszulesen. Ist die Amplitude gleich Null,
dann liegt S/W/Grau vor, andernfalls Farbe. Aus der Differenz der beiden Phasen
(Phase2-Phase1, evtl. Modulo-Op?) ergibt sich dann mittels Tabelle die Farbe
- 4. danach kommt dann wieder ein Sync etc., d.h. weiter mit 1. oder 5.
- 5. Bildende erkennen
Der Burst ist hier ein hochfrequentes Signal mit fester Frequenz (ca. 4.4MHz fĂĽr PAL).
Aus praktischen GrĂĽnden sample ich jetzt mit einem Vielfachen dieser Frequenz
(Videochips samplen hier z.B. mit 27, 50 oder gar 100 MHz).
Wenn ich mich so auf die Schnelle nicht verrechnet habe, ist das Fenster leider
so klein, dass nur ein Bruchteil einer kompletten Schwingung gesamplelt werden
kann (sonst werden nich Übergänge zum nächsten Pixel bzw. Farbe mitgelesen,
was dann das Ergebnis verfälscht). Aber mithilfe numerischer Verfahren (gleich
mehr dazu) kann man notwendig viel Informationen extrahieren, um Amplitude
und Phase zu bestimmen.
Numerisches Verfahren, um Amplitude und Phase zu bestimmen:
- es sind n Werte fĂĽr Cos- und Sin-Function der Burstfrequenz vorberechnet
- es werden n Werte eingelesen
- mithilfe eines einfachen linearen Approximationsverfahren werden
die Koeffizienten Werte = a*cos + b*sin bestimmt (FT oder FFT gehen hier
nicht, da keine ganze Periode vorhanden ist!), aus a und b dann mittels
einfacher Umwandlung die Amplitude und die Phase (ist vlt. gar nicht
notwendig, da evtl. a und b schon fĂĽr die Farbauswertung ausreichen,
fĂĽr die Amplitude tun sie das ganz sicher) berechnet.
Das Approximationsverfahren verstehe ich gut genug, fĂĽr die konkrete
Aufgabe muss ich aber noch ein kleines Skript schreiben, das mir verrauschte
Burstsignale entsprechender Länge erzeugt und das Verfahren darauf
anwenden. Dann kann ich sehen, wie genau a und b bzw. Aplitude und
Phase bestimmt werden können, und das inkl. Rauschen im Signal. Da sehe
ich ausser einem Zeitaufwand aber keine Probleme, auch die Implementierung
in HDL für FPGAs ist sehr einfach, habe ich schon des öfteren gemacht,
erfordert auch nur wenige Resourcen. (das Ganzer natĂĽrlich unter der Annahme,
dass das Fenster im Pixel gross genug ist, um ein Minimum an Periodenanteil
der Burstfrequenz zu fassen, sonst wird die Extraktion von Phase und Amplitude
unmögliche. genaueres rechne ich Morgen Abend aus.)
So, jetzt aber gute Nacht
Wenn braun in Deiner Darstellung weiter innen (=geringere Farbamplitude) liegt, dann hast Du entweder sRGB-Werte genommen oder meinen Korrekturfaktor nicht auf 100 % gesetzt.
Ups, ich vergesse immer wieder, dass ja die Farbräume irgendwie beschnitten werden müssen,
um ineinander ĂĽberfĂĽhrbar zu sein: hab Brown angepasst, siehe Bild (Phasenbereich: +/-30 Grad).
Im zweiten Bild sieht man die Revision1 des 6569. Ich hoffe mal, man sieht ganz gut, wie sich
zwei Paare in der Phase relativ nahe kommen. Der Phasenbereich umfasst +/-15 Grad. Wie
man das schaltungstechnisch trennen kann ... bis jetzt keine Ahnung.
Für beide Bilder sind im Anhang die passenden Datensätze für den Voxelviewer.
Es wäre evtl. eine Überlegung, weil ja die Farbamplituden halbwegs gleich sein, in "2D" zu analyiseren?
..das werde ich hoffentlich Morgen Abend hinkriegen, ich hatte ja schon weiter Oben eine Idee.
6569R1:
Please login to see this attachment.
PALetteV1:
Please login to see this attachment.
In diesem Anhang findest Du eigentlich erstmal "alles", was Du ĂĽber die C64-Farben wissen solltests:
Neue RGB Palette fĂĽr den C64: PALette
Ja, habe ich schon vor ein paar Tagen gesehen (ich hatte mir auch schon eingebildet, bei dir
eine leichte Abneigung gegen die Pepto-Palette rauszulesen, jetzt ist mir so einiges klar).
Zu meiner Grafik: im Bild von Unten erkennt man ganz gut, dass Braun (mĂĽsste doch Braun
sein) etwas näher zur Mitte gerückt ist, zumindestens ggÜ Pepto und der ersten VIC-Revision,
habe alles mal ausprobiert. Wenn ich keinen Fehler gemacht habe: warum ist das so?
