Moin Moin,

ich bin (scheinbar) über einen kleine Bug in der GDP-FPGA gestolpert. Dieser Zeigt sich, wenn man bei eingeschalteten XOR-Modus eine horizontale Linie mit einer Länge > 256 Punkte zeichnet.
Die Frage ist nun, ob es diesen Bug auch bei der orginalen GDP64-HS gibt.
Ich könnte zwar durch Anpassen des Grundprogramms (68xxx) den Bug umgehen, das würde aber nur Sinn machen wenn es ihn auch in der GDP64-HS gibt. Ansonsten muss ich mal Versuchen ihn in der VHDL-Source der FPGA-Karte zu finden

Ich währe Euch dankbar wenn jemand mit der orginal GDP64-HS Karte das unten stehende Programm testen könnte. Bei der GDP-FPGA hat der Kreis in der Mitte einen senkrechten (schwarzen) Strich.

start:
move #!clr, d7
trap #1 * Bildschirm löschen
moveq #1, d0
move #!setxor, d7
trap #1 * XOR einschalten
move #255, d1 * X-Koordinate
move #255, d2 * Y-Koordinate
move #180, d3 * Radius
moveq #8, d0 * gefüllter Kreis
move #!grafik, d7
trap #1
rts


-----------------------
Gruß
-=jens=-

Hallo,

tritt der Bug nur auf wenn der XOR mode eingeschaltet ist und was ist die Auswirkung des Bugs ?
Ich bin auch über das Testprogramm etwas verwirrt.
Du schreibst dass der Bug bei einer horiz. Linie >256 Punkte auftritt, aber Dein Testprogramm zeichnet einen Kreis ???

Hallo Andreas,

das mit dem Kreis war nur als Testprogramm gedacht, weil man dort den (unerwüschten) Effekt schnell sieht.
Und zwar sieht man in der Mitte des Kreises eine senkrechte schwarze Linien, wenn man mit weiß im XOR-Modus arbeitet.

Gefüllte Kreise werden vom Grundprogramm durch horizontale Linien gezeichnet. Wenn nun der Durchmesser des Kreises 255 Punkte überschreitet, werden die Linien durch 2 (oder mehr) Teillinien erzeugt.

So wie ich es sehe, ist die X-Koordinate des letzten Punktes der 1. Teillinie identisch mit der X-Koordinate des 1. Punktes der 2. Teillinie. Dadurch wird dieses Pixel 2 mal geschrieben, was im XOR-Modus halt zur Ausgangsfarbe (schwarz) führt.
Ich kann leider nicht sagen ob die orginal GDP-HS auch dieses Verhalten zeigt (da ich keine habe), wenn ja, dann würde ich die betroffenen Grundprogrammroutinen anpassen. Ansonsten währe es halt schöner die GDP-FPGA anzupassen.

Ach ja ob der "Bug" nur beim XOR-Modus auftritt, kann ich leider auch nicht sagen, da man ihn sonst ja nicht sehen würde

-----------------------
Gruß
-=jens=-

Hallo,

ja, dieses Phänomen kenne ich.
Ich glaube mich erinnern zu können dass dieses auch schon bei der Original GDP-64HS so war (bin mir aber nicht sicher).
Die Ursache dafür ist ganz klar.
Wenn eine Linie aus zwei Teillinien zusammengesetzt wird dann deckt sich der letzte Punkt der 1. Linie mit dem ersten Punkt der 2. Linie (Punkt wird 2x geschrieben)
=> Durch den Xor Mode verschwindet der Punkt.
Dies wäre im VHDL-Code auch ganz leicht zu beheben.
Man muss nur entweder den ersten oder letzten Punkt einer Linie nicht zeichnen lassen. Aber dann weicht man vom Original GDP ab.

Hallo,

ein Fix der Software-routinen ist für horizontale und vertikale Linien leicht. Aber was machst Du wenn du eine schräge Linie >256 Pixels zeichen musst. Durch den Bug hast Du an der Stoßstelle, wo die beiden Teillinien zusammentreffen einen schwarzen Punkt.
Damit die Software die nachfolgende Linie einen Pixel später starten alssen kann muss dieser erst mal berechnet werden, was bei schrägen Linien nciht so leicht ist (Bresenham).
Also ich würde den Fix auf jeden Fall in der Hardware machen.
Die frage ist nur wie, um die Kompatiblität möglichst nciht zu verlieren.

Moin,

genau so habe ich es mir gedacht.
Daher würde mich eben das Verhalten der GDP-64HS interessieren. Denn es ist mir lieber, wenn sich die Karten identisch verhalten, weil ich das GP dann halt nicht noch auf die einzelnen GDP-Karten angepassen muss.

-----------------------
Gruß
-=jens=-

Hallo,

ich hab irgendwo eine GDP64HS herumliegen.
Aber mein NKC ist gerade nicht einsatzbereit.
Aber ich denke es ist klar dass der Bug eigentlich ein konzeptionelles Problem ist.
Wenn Du eine Linie von 0,0 - 5,0 zeichnest dann werden durch die GDP 6 Punkte geschrieben. Zeichnest Du eine zweite Linie von 5,0 - 10,0 dann werden wieder 6 Punkte geschrieben, wobei der Punkt 0,5 ein zweites mal geschrieben wird.
Dieses Verhalten kann man auch mit einer normalen GDP verifizieren (Punkte zählen).
Ich glaube nicht dass die Original GDP einen Punkt (ersten oder letzten) auslässt.

Moin,

ne "normale" GDP64 hab ich noch rumliegen, die könnte ich heute Abend mal reaktivieren

Ich werd mich dann mal an's Pixel-Zählen machen

Übrigens in der Senkrechten (und damit auch bei Diagonalen) tritt dieses Problem i.A. nicht auf, da es in Y-Richtung sowieso nur 256 Pixel gibt
Einzig der Grafik-Befehl "Linienfolge Zeichnen" und die darauf aufbauenden Routinen (Quadrat, Rechteck zeichnen) sind dann eventuell noch betroffen. Bei einem Quadrat z.B. fehlen im XOR-Modus die Eckpunkte (sieht aber auch nicht schlecht aus).

-----------------------
Gruß
-=jens=-

Moin Moin,

so meine alte GDP64 läuft noch und auch das "schöne" alte Keyboard.

Um es erstmal vorwegzunehmen: Es ist kein GDP-FPGA Bug! Die alte GDP64 verhält sich genau so wie die GDP-FPGA (oder besser gesagt umgekehrt)!

Ich hab zum testen das folgende kleine Programm verwendet:

start:
move #100, d1
move #100, d2
move #!moveto, d7
trap #1 *** Position auf 100,100 setzen
move #10, $ffffff75.w *** DELTAX mit 10 belegen
move #$10, d0
move #!cmd, d7
trap #1 *** 10 Pixel lange horizontale Linie zeichnen
add.b #1, $ffffff7b.w *** Y-Position auf 101 erhöhen
move #$10, d0
move #!cmd, d7
trap #1 *** 2. 10 Pixel Linie zeichnen
rts

Mit diesem Programm werden 2 horizontele Linien gezeichnet. Die Erste beginnt an Position 100,100 und ist 10 Pixel lang.
Die Zweite beginnt am Ende der ersten Linie und eine Zeile höher, sie ist auch 10 Pixel lang.

Wie man nach Ausführung des Programmes sieht, sind die X-Positionen vom Ende der ersten und dem Anfang der zweiten Linie gleich! Dies führt wie schon vermutet zur Auslöschung von Pixeln bei Benutzung des XOR-Modus.

Ich werde deshalb versuchen, das Grundprogramm dahingehen zu bereinigen (ansatzweise hab ich es schon gemacht).

-----------------------
Gruß
-=jens=-

Moin nochmal,

@Andi: Falls du Interesse hast die GDP-FPGA zu erweitern...
Man könnte das Register $ffffff74 als DELTAX MSB und $ffffff76 als DELTAY MSB nehmen. Diese sind bei den EF936x als Reserviert gekennzeichnet. Somit währe die FPGA-Variante weiterhin abwärtskompatibel und man könnte "beliebig" lange Linien zeichnen.
Eine Abfrage der GDP-Art wird vom Grundprogramm sowieso schon gemacht, von daher währe es eine echte Verbesserung

Übrigens, ich bin schonwiedermal dabei das GP zu überarbeiten (kleine Probleme mit Trap-Initialisierung, ein paar Probs mit Interrupts, Vereinheitlichung von div. Grafik-Aufrufen, Vereinfachung/Flexibilisierung der Sprites, Erweiterung der Grafik um clipping...), so daß es kein Problem währe solch neue Register/Funktionen mit einzubauen.

-----------------------
Gruß
-=jens=-

Hallo,

ja, diese Erweiterung kann man machen.
Allerdings reicht das meines Erachtens nach noch nicht aus.
Wenn man Polygone im XOR Mode zeichnet dann hat man an den Eckpunkten immer das besagte Problem. Eine Umgehung in Software dieses Problems ist schwierig (man bräuchte Bresenham).
Meiner Ansicht nach wäre es am besten ein neues Registerbit zu machen mit dem man das zeichnen des ersten oder letzten Pixels (welches muss man sich noch überlegen) unterdrücken kann.
Nur mit dieser Lösung erschlägt man alles.

Moin Moin,

das mit dem Registerbit würde leider auch nur bedingt helfen. Wenn man z.B. eine Linie von 0,0 nach 0,255 und die nächste von 0,255 nach 1,0, dann haben die eine Überdeckung von etwa 128 Pixeln.

Von daher finde ich die Idee mit den Langen Vektoren noch am günstigsten. Man hat dann zwar weiterhin das Problem bei Polygonen, aber die Flächenfüllungen sind einwandfrei.

-----------------------
Gruß
-=jens=-

Hallo,

hast mich überzeugt.
Ich werde mal checken wieviel Aufwand die langen Vektoren wären. Ich glaube nicht dass es viel ist.
Aber ich habe auch schon seit einem Jahr oder so nicht mehr in den GDP64-FPGA VHDL Code reingeschaut

Hallo,

gibt es zur GDP64-FPGA eine Beschreibung zu all den schönen Erweiterungen ?

mfg. Gerald

P.S.: Suche noch eine GDP64-FPGA Platine; Kann auch teilbestückt sein.

Hallo,

leider nein zu beiden Fragen.
Die Doku der Erweiterungen / Unterschiede zur "normalen" GDP64-HS hab ich mir schon lange vorgenommen, hatte aber bisher noch keine Zeit dafür
Und im übrigen ist der VHDL-Source meine Doku
Leider hab ich auch keine FPGA-Platinen mehr.

MfG.
Andreas

Moin Moin,

mit der Doku für die GDP-FPGA hat mir auch schon länger auf den Fingern gebrannt

Deshalb hab ich mich mal hingesetzt und zumindest eine Port-Beschreibung für dieses geniale Teil gemacht.
Hoffentlich habe ich da keine größeren Fehler eingebaut.
Ach ja, die von mir nicht näher beschriebenen Ports sind identisch mit den jeweiligen NKC-Baugruppen.

Ich habe diese Beschreibung sowie die Sourcen mit den letzten Änderungen von Andreas an Hans-Werner gemailt.
Dürfte also recht schnell online sein

@andi: währe es übrigens sehr teuer noch mal ein paar Platinen nachzubestellen?

-----------------------
Gruß
-=jens=-

Hallo alles online unter
http://www.schuetz.thtec.org/NKC/hardware/gdphsneu.html
Gruß
Hans- Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Moin Moin,

bin gerade dabei Graphiktreiber für die GDPs und die ACRTC zu schreiben. Dabei ist mir eine Unschönheit aufgefallen.
Die Vordergrundfarbe darf nicht Schwarz sein, wenn die Hintergrundfarbe auch schwarz ist. Weiss auf weiss geht aber. Ärger macht die Sache dann, wenn mein Mustergenerator eine Fläche nur mit der Hintergrundfarbe füllen soll. Die erscheint dann weiss, nicht schwarz.
Nach Durchsicht der VHDL-Sourcen habe ich auch die entsprechenden Stellen gefunden, die das bewirken. Dabei habe ich auch das Problem entdeckt, warum die Tastaturschnittstelle nicht vollständig abschaltbar ist. Der FPGA bedient die Ports $68/69 immer.

Kann das noch geändert werden ?

mfg. Gerald

Hallo,

ja, kein Problem. Das kann ich beheben.
Kannst Du mir die betreffenden Zeile(n) für das Problem mit der Farbe schicken ?
Was ist nochmal genau das Fehlverhalten wenn vorder- und hintergrundfarbe auf Schwarz gestellt werden ?
Und gehen andere Farbkombinationen (z.B. Rot/Rot) ?

MfG.
Andreas

Hallo,

hab's schon gesehen. Da ist eine sicherheitsabfrage drinnen wenn beide Farben auf Schwarz gestellt werden dann wird weiss als Vordergrundfarbe genommen. Diese kann ich problemlos rauswerfen. Den Grund für diese Sicherheitsabfrage kenn ich jetzt nicht mehr.

MfG.
Andreas