Beiträge von LastLemming

    Wie löst du das Beschaffungsproblem der 50pol.-RM2-Expansionsport-Verbinder? Wenn das gelöst ist, dann packe ich meine C16-Platine gleich dazu :)

    Geht der hier vielleicht ?

    Bitte melde dich an, um diesen Link zu sehen.

    (mein erster Link hoffe der klappt)

    Die 264er haben, keine Ahnung warum (Breite?), einen ungebräuchlichen metrischen pitch von 2.00mm anstatt des üblichen 2,54mm (1/10 Zoll). Link ist auch 2.54mm

    Hätte ich mal vorher Deine Fussnote wahrgenommen ...

    Im kommentierten ROM-Listing (Commodore Sachbuch) stand glaub ich mal was drin. Allerdings weiss ich nicht auf welche Version sich die Aussage bezieht:

    "In der alten Version ist vor allem die Routine zur Bearbeitung von DS$ fehlerhaft. Beim Anlegen von DS$ wird der Deskriptor-Zeiger nicht korrekt angelegt. Ist nun beim C16, C116 und Plus/4 eine Garbage-Collection notwendig, um die ungültigen Strings zu beseitigen, verirrt sich der Prozessor durch die falsche R-Adresse ... "

    In der Beschreibung steht, dass der C64 etwa 0.2h/s rechnen kann. Eine aktuelle GeForce 3080 schafft 48.5Mh/s (mega!), ist also knapp eine Viertelmillion mal schneller als der C64.

    Ähm ... Ist die GeForce nicht sogar knapp ne Viertelmilliarde mal schneller ? Oder hab ich da ein altersbedingtes Potenzproblem im Kopf ?

    :

    Ich konnte die von mir gewünschten Specs dank des Threads optimieren und konkretisieren. Mehr hatte ich mir ja ursprünglich auch gar nicht erhofft. Falls sich irgendwer durch den Thread "aufgerufen" fühlt, etwas davon praktisch umzusetzen (zumindest in Teilen) – umso besser. Vieles wird einem ja auch erst richtig klar, wenn man vor den technischen Problemen konkret steht.

    :

    Wenn ich nochmal Deine Specs zusammenfasse wäre das ein System mit:

    Grafik: 240x216 16 Farben bzw. 480x216 16(?) Farben, Hardware-Scrolling

    CPU: leistungsstärker als 8bit CPU z.B. 68K

    RAM: 1-2 MByte

    Wenn man noch 8Bit PCM-Sound oben drauf wirft wäre man bei einem Amiga.

    D.h. Hardware als auch Emulator wären vorhanden, zudem ist die Plattform skalierbar: A500 -> A1200, Fast-RAM, Turbokarte. Entwicklungsumgebungen sollten auch verfügbar sein. Nachteilig ist dass die Grafik nicht richtig skaliert/gestreckt ist und das mit den Bitplanes ist auch nicht so dolle.

    Was fehlt wäre:

    - einfacher Kernal / OS

    - Deine Spiele-IDE

    Wenn man das ganze final noch in ein eigenes KickROM kippt (was man nicht machen muss weil es ja nur eine Machbarkeitsstudie ist, aber cool wärs trotzdem) wärst Du doch am Ziel. Oder nicht ?

    :

    Unabhängig davon könnte man natürlich ein eigenes Bit für die Transparenz spendieren. Dann könnte man alle 256 Farben verwenden und die Transparenz unabhängig von der Farbe setzen. Ich hatte mir darüber Gedanken gemacht, daß sowas als 1ibt-Minimalausbau eines Alphakanals durchaus seinen Charme hat. Ich hatte mich dann aber bewußt gegen einen solchen Ansatz entschieden, weil man dann immer mit 9bit hantieren muß. Sprich: man kann nicht einfach ein Byte in den Vordergrundspeicher schreiben und vor allem müssen "Sprite"-Daten noch die Transparenzmaske enthalten. Das Setzen/Löschen des Transparenzbits beim Schreiben könnte so lösen, wie ich mir das für das Dirty-Bit überlegt hatte (Modusumschaltung oder virtuelle Adresse), aber die Notwendigkeit einer Transparenzmaske für die Spritedaten fände ich persönlich deutlich unhandlicher als einen Transparenzindex.

    :

    Der "Blitter" kann doch nach wie vor mit einem Transparenz-Index (z.B. 0) arbeiten. Wenn er eine "0" liesst macht er gar nichts ausser die Ziel-Adresse modifizieren. Bei allen anderen Werten kopiert er diesen in den Vordergrund-Buffer und setzt ein Stencil-Bit (bzw. sammelt erstmal die Bits und odert dann sinnig in den Stencil-Buffer). Was spricht dagegen alle beweglichen Objekte in einer Liste zu verwalten? Nach der Darstellung steht es einem frei den Stencil-Buffer komplett zu löschen der ab einer bestimmten Zeile (um die Score-Anzeige zu erhalten) oder anhand der Daten in der Objekt-Liste.

    Und die Grafik-Reste lassen wir schön im Vordergrund-Buffer. Wieso unterm Teppich putzen wenn man da später sowieso drüberkrümelt.

    das mit der "Dirty"-Maske war ja nur ein auf die Schnelle zusammengeklöppelter Implementierungsvorschlag.

    Verallgemeinere es doch auf einen Stencil-Buffer mit genauso viel Bit pro Pixel wie für die Farbauswahl verwendet wird und ein paar konfigurierbaren logischen Verknüpfungen, dann kann man mit dem System zB in Quelle und/oder Ziel einzelne Farben als transparent deklarieren indem man die Quelle oder das Ziel als Lesequelle des "Dirty"-Buffers verwendet

    Mal angenommen man hätte:

    1) 8Bit/Pixel Hintergrund

    2) 8Bit/Pixel Vordergrund

    3) 1Bit/Pixel Stencil Buffer

    4) 8Bit Speicheranbindung

    Je nach Stencil-Bit wird entweder das Hintergrund oder Vordergrund-Pixel dargestellt. Hier könnte zusätzlich der Speicherzugriff minimiert werden, da ja entweder das Hintergrund oder das Vordergrundbyte gelesen wird. Bei mehr als einem Pixel pro Speicherzugriff müsste man hingegen beide Quellen lesen.

    Der Stencil-Buffer hätte auch den Vorteil dass der Vordergrund-Buffer nicht gelöscht werden müsste, es reicht ja den Stencil-Buffer zu bereinigen, die Vordergrund-Objekte drüberzupinseln und den Stencil-Buffer neu zu setzen.

    :

    Kann aber schon einmal den Hinweis geben das die MIDI Implemetierung im VICE Emulation ein wenig Buggy ist, z.B. Kann im MIDI Standard nach einem Note On einfach die nächste zu spielende Note gesendet werden unter Windows im VICE kommt dann aber nix, währen ein echter C64 mit z.B. Datel-MIDI Schnittstelle so spielt wie es der Standard vorsieht.

    :

    Tritt das nur bei folgenden NoteOns auf dem selben Kanal auf oder ist das immer der Fall? Wenn das nur bei folgenden NoteOns auf dem selben Kanal auftritt wird da ggf. ein running status von VICE falsch interpretiert?

    Wenn man eine Objekt-Liste zum Zeichnen hat macht es dann nicht Sinn diese Liste auch zum Löschen zu verwenden. Sprich:

    1) Grafik-DMA auf zeichnen stellen. Objekte der Objekt-Liste zeichnen.

    2) Grafik-DMA auf löschen stellen. Objekte der Objekt-Liste löschen.

    Oder zeigt der Zeiger auf das nächste Objekt auf die nächste Animationsphase ?

    Ansonsten geht der STM32H750 aus dieser 32blit Konsole schon fast in diese Richtung. Der Display-Kontroller LTDC unterstützt zwei Display Layer mit Transparenz und ein DMA2D ist auch vorhanden.

    Hat hier jemand Erfahrung mit einem separaten HDMI Transceiver IC?

    Die Dinger gibt es oft nur mit NDA und separater Angebotsanfrage, was meist gleichbedeutend mit Abnahme großer Stückzahlen ist. Aber immerhin konnte ich bisher ein IC finden, das auch in Einzelstücken für unter 10 EUR verkauft wird:

    NXP Bitte melde dich an, um diesen Link zu sehen., Low power, 150 MHz pixel rate HDMI 1.4a transmitter with 3x8-bit video inputs, HDCP and CEC support.

    Leider nur im nicht übermäßig bastelfreundlichen fine pitch ball grid array oder very thin quad flat package verfügbar. :tischkante:

    Angenommen, man bekäme das Teil irgendwie funktionsfähig auf eine Platine geschraubt, wäre das eine Lösung unserer Video-Probleme?

    Wir verwenden nen TFP410 von TI. Geht dann auf ne DVI Buchse. HDCP & CEC geht damit aber glaub ich nicht. Wäre aber wohl auch nicht notwendig.

    Mit dem Modus lassen sich voll einfach Copper-Bars realiseren.

    Mir ist später noch ein Grund eingefallen, warum sich solch ein Modus in der Praxis schwer tun könnte. Er ist zwar gut geeignet, um horizontale Linien zu erzeugen, aber wenn es darum geht. z. B. einzelne Punkte, Linien oder Muster darzustellen, dürfte es zu kompliziert werden.

    Beispiele für Punkte wären eine Partikelengine (vgl. "Virus") oder Zahlen- bzw. Texteinblendungen. Beispiele für Muster wären die geditherten Farben aus "Carrier Command" oder "Elite" oder der Pseudo-Alpha-Blending-Effekt aus "Epic" bzw. "Robocop 3", in dem z. B. ein Kreis gemalt wird, in dem nur jedes Xte Pixel in einer Farbe (Schwarz, Rot, Blau...) gesetzt wird

    Früher(tm) war aber auch mehr: "Mal überlegen ... was könnte man damit machen."

    Die Halte-Farbe muss man ja nicht in allen Bild-Bereichen nutzen. Bei Bildelementen wie z.B. einem Cockpit kann das mit den normalen Farben ganz normal dargestellt werden. Da kann dann auch gedankenlos reinkopiert werden. Grundsätzlich könnte man auch im "Vektor-Bereich" Farben zusammenrastern, das wird dann aber vermutlich mindestens so aufwändig wie ohne diesen Modus. Robocop 3: Man kann den Hintergrund der Textzeile ohne Halte-Farbe darstellen und dann den Text drüberkopieren. Das Alpha-Blending (Das ist doch der gerasterte Zaun?) bekommt man ggf. sogar besser realisiert weil die Farbe des Zeilenabschnitts ja noch in der Liste geändert werden kann und noch nicht final auf dem Bildschirm ist. Das ginge dann sogar mehrfach. Bei nem Copper-Hintergrund wirds natürlich kompliziert, wenn man denn einen Copper-Hintergrund hat.

    Vielleicht gibt es ja auch genug Farben dann muss man sich keine zusammenrastern.

    Vielleicht gibt es ja ne Char-Plane als Overlay.

    Vielleicht gibt es ja auch Sprites.

    Los gib dem Modus ne Chance ...

    Wie schauts mit dem Löschen des Buffers aus ? Wenn man eh eine Liste hat, müssten nur die einzelnen Pixel gelöscht werden nicht der ganze Screen.

    Mag sein, aber auch hier gibt es den Punkt, an dem es aufwendiger wird, einzelne Pixel zu löschen (deren Koordinaten aus der Liste geholt werden müssen, die wiederum auch gelöscht werden soll) als rabiat den Hintergrund zu löschen. Die Frage ist nur, wann dieser Punkt erreicht ist. Darüber läßt sich an dieser Stelle nur spekulieren, weil schlecht abzuschätzen ist, wie aufwendig genau das Listenverfahren in der Praxis ist.

    Da es keine Hardware gibt, die auf die von Dir genannte Weise arbeitet, bleibt nur eine Möglichkeit: Emulator schreiben und austesten. Womit wir dann wieder beim Thema wären. Oder so wie es Daybyter formuliert

    Naja im Prinzip gibt es das als Hardware. Im HAM Modus nimmt man als Halte-Farbe "Grün-Komponente = 0" und die normalen 16 Farben zum Malen. Es fehlt dann halt der Grünanteil im Bild. Leider gehen die zwei zusätzlichen Planes Zeit bei der CPU klauen, das müsste man bei einem Vergleich entsprechend berücksichtigen.

    Bevor jetzt aber der Teil kommt wo ich 4 populäre Vektorgrafik-Spiele mit einer alternativen Render-Engine realisieren soll hake ich diesen Bereich erstmal ab und schau nochmal in meiner Argumente-Kiste ganz unten nach.

    Hey! Mit dem Modus lassen sich voll einfach Copper-Bars realiseren. Man muss nur die ersten Pixel der einzelnen Zeilen ändern. Cool oder ?

    Mehr is leider nich drin.

    Beim ST weiß ich es jetzt gar nicht, ob der auch diesen Bitplane Mist hatte.

    Ja, wenn auch anders angeordnet. Beim Amiga lagen die Bitplanes bei einer 320x200x16-Grafik je nach Mod-Einstellung entweder 8000 oder 40 Bytes auseinander. Um einen einzelnen Punkt zu setzen, war das recht aufwendig. Bei einer horizontalen Linie hingegen (sprich: Polygon) fiel dies weniger ins Gewicht, da sich dadurch die Anzahl der Bytes, die man insgesamt setzen mußte, nicht viel änderte.

    Beim AtariST waren die Planes direkt nacheinander angeordnet in der Form 16 Bits 1. Plane, 16 Bits 2. Plane, 16 Bits, 3. Plane, 16 Bits 4. Plane. Auch hier mußte man für einen einzelnen Punkt viermal schreiben. Da die Planes aber direkt aufeinanderfolgten, konnte man anstelle der Adressierungsart "offset(Ax)" = Basisregister + Offset auch die etwas schnellere Adressierung "(Ax)+" = indirekt mit Postinkrement verwenden.

    Um Programme zu beschleunigen, hat man keine Routine geschrieben für alle Farben, sondern jede Farbe bekam ihre eigene Routine:

    Psst! Die "ORs" in der Amiga-Version sehen merkwürdig aus.

    Als Gegenbeispiel werfe ich mal ein Carrier Command in den Ring wo im Worst Case die eine Hälfte des Bildschirms Himmelblau und die andere Hälfte Pazifikblau ist. Beim Fliegen auch gerne mal diagonal.

    Bzw. wenn ich bei Elite ein Polygon das horizontal eher schmal ist durch Rollen des Schiffes um 90° drehe dann wird es in der Regel horizontal eher breit.

    Ja vermutlich müsste man mit sowas wie RLE-Listen rumhantieren. Und der Aufwand steigt mit der Anzahl der Objekte pro Zeile. Die Frage ist wieviele Objekte hab ich denn überhaupt z.B. bei einem Elite ? Sterne, Sonne, Raumschiff, Rakete. Und wie werden Überdeckungen (die durch die Listenbearbeitung wegfallen) sonst gehandhabt ? Overdraw ? An den Rändern unden dann odern ? Wie schauts mit dem Löschen des Buffers aus ? Wenn man eh eine Liste hat, müssten nur die einzelnen Pixel gelöscht werden nicht der ganze Screen.

    Eine andere Frage ist: Was braucht das in Hardware? Und da sehe ich ein zusätzliches Farbregister, das mit der letzten Bitmap-Farbe gefüttert wird und einen Multiplexer der je nach Modus entweder das normale Farb-Register oder das Füll-Register selektiert. Sieht für mich sehr preiswert aus für eine Möglichkeit.