NKC Forum
Registrieren | FAQ | Suche | Wer ist online? | Mitgliederliste | Heutige Beiträge | Einloggen



Autor Thema: GDP64HS-FPGA Bug?
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 17. April 2009 09:26 (#1)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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 :eek:

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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 23. April 2009 10:32 (#2)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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 ???

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 23. April 2009 11:52 (#3)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 23. April 2009 13:03 (#4)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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.

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 23. April 2009 13:09 (#5)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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.

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 23. April 2009 13:09 (#6)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 23. April 2009 13:32 (#7)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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.

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 23. April 2009 13:44 (#8)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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 :rolleyes:

Ü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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 23. April 2009 19:09 (#9)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Moin,

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

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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 23. April 2009 20:45 (#10)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 24. April 2009 12:14 (#11)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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.

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 24. April 2009 18:04 (#12)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 24. April 2009 18:48 (#13)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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 :(

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
tasscaff
Kennt sich schon aus
**
ID # 54


  Erstellt am 16. August 2009 02:44 (#14)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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.

Beiträge: 110 | Mitglied seit: April 2006 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 20. August 2009 08:22 (#15)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 25. September 2009 17:59 (#16)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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 :P

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

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

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
hschuetz
Administrator
Seitenadmins
******
ID # 3


  Erstellt am 26. September 2009 20:32 (#17)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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!

Beiträge: 788 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
tasscaff
Kennt sich schon aus
**
ID # 54


  Erstellt am 01. Oktober 2009 12:14 (#18)  |  Zitat Zitat   PN PN   E-Mail E-Mail
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

Beiträge: 110 | Mitglied seit: April 2006 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 01. Oktober 2009 12:34 (#19)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert
andi
Kennt sich schon aus
**
ID # 63


  Erstellt am 01. Oktober 2009 13:02 (#20)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
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

Beiträge: 61 | Mitglied seit: November 2006 | IP-Adresse: gespeichert



| NDR Computer | Boardregeln


Tritanium Bulletin Board 1.6
© 2010–2016 Tritanium Scripts


Seite in 0,577447 Sekunden erstellt
19 Dateien verarbeitet
gzip Komprimierung ausgeschaltet
1624,11 KiB Speichernutzung