Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » GDC-Problem beim Vektorzeichnen » Themenansicht

Autor

Thread - Seiten: -1-

000
01.08.2026, 09:25 Uhr
HeikoS

Liebe GDC-Experten,

bei der Programmierung des BIC ist mir ein Fehler aufgefallen, dessen Ursache ich immer in einer fehlerhaften Programmierung gesucht habe. Eigentlich wollte ich ja schon viel weiter mit der ELITE-Demo sein, aber das hat mich sehr gewurmt, vermutlich aber umsonst.

Nach dem Zeichnen einer Linie mit dem Vektor-Befehl (FIGS, FIGD) stellt der GDC immer noch einen „Geister-Punkt“ auf der Y-Koordinate+1 des letzten Punktes des Vektors dar. Der Punkt liegt scheinbar immer in Bit0 des 16-Bit-Wortes dieser VRAM-Adresse, er liegt also nicht immer direkt am Ende der Linie, dann wäre sie ja nur immer 1 Pixel zu lang. Der Punkt liegt also fast immer daneben und stört.

Man kann ihn mit einem anschließenden CURS-Befehl löschen und auf eine unsichtbare Position lenken. Das ist ein Workaround. Ich dachte immer, das müsste doch auch anders gehen. Meine Recherchen haben nun ergeben, dass das wohl ein echter und bekannter Hardware-Bug des GDC ist und auch in allen Nachbauten vorhanden ist, sogar in der A-Version des Chips. Bei der Entwicklung des MAME-Emulators ist das wohl auch besprochen worden.

Die Ursache soll sein, dass der Digital Differential Analyzer (DDA, Recheneinheit im Chip), die nächste VRAM-Adresse schon berechnet hat, wenn der Algorithmus abbricht, weil die Vektorlänge erreicht ist. Im Zusammenspiel mit dem Read-Modify-Write-Modus während FIGD, entsteht wohl noch ein ungewollter Schreibbefehl auf diese VRAM-Adresse und erzeugt ein „Artefakt“.

Bei schnellen Animationen, ist der Workaround mit dem anschließenden CURS-Befehl sogar zu langsam. Man kann das flackernde Geister-Pixel immer noch ein wenig sehen.

Bei der schnellen Würfel-Animation von Cornelius passiert das auch, nur dass durch das Double-Buffering die Punkte nicht sichtbar sind. Jede Linie benötigt ja am Anfang wieder einen CURS-Befehl, löscht damit das „Geister-Pixel“ so dass nur das letzte „Geister-Pixel“ noch mit einem zusätzlichen CURS beseitigt wird und erst dann wird die Ebene sichtbar gemacht. Schöne Lösung ! Aber ich habe eine Routine, die ohne Double-Buffer arbeitet, aber mit einem speziellen „flicker-free“-Algorithmus. Da krieselt es dann immer noch ein wenig auf dem Bildschirm durch die „Geister-Pixel“.

Hat jemand Informationen dazu, evtl. aus den VIS3 Projekten? Oder könnte es jemand auf der VIS3 Hardware testen. Wichtig wäre, dass nach dem FIGD-Befehl KEINE Ausgaben mehr an den GDC sendet werden. Also mit dem Treiber der AdW z.B.:

Quellcode:


;------------------------------------------------------------------------------         
;Programm LG
;04.07.86 hb
;------------------------------------------------------------------------------
;Funktion:
; LINIENPARAMETER FUER FIFO BEREITSTELLEN
;EINGABE: 
; GPX1,GPY1 - Koordinaten Punkt 1
; GPX2,GPY2 - Koordinaten Punkt 2
;AUSGABE: PARAMETER ab HFIGS:
;         KOMMANDO,ANZAHL DER PARAMETER,...
;Benutzte UP:
; DFIFO  - Kommando und Parameter an FIFO
; DSTART - Startkommando an FIFO

                …
                LD      HL,hfigs
                CALL    DFIFO          
                LD      HL,FIGD
                CALL    DSTART
                Hier stoppen !

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
01.08.2026, 11:08 Uhr
kaiOr

Hallo Heiko,

eins vorweg, ich habe nichts zum Testen.
Ich könnte mir vorstellen, dass nach Fertigstellung der Linie der Zeiger im Parameter-RAM von RA-8/RA-9 auf RA-10/RA-11 inkrementiert (Fallback auf Zeichengenerierung). Vielleicht macht es Sinn vorab RA-10 bis RA-15 in "DFIFO" zu leeren?

Gruß,
Kai

Dieser Beitrag wurde am 01.08.2026 um 11:15 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
01.08.2026, 15:56 Uhr
HeikoS

Hallo Kai,

danke für Deine Idee, leider verschwindet das Geister-Pixel durch Löschen von RA-10 bis RA-15 nicht. Das wären ja die Pattern für die Zeichendarstellung (Zeile 1-6). Wenn alle auf 0 sind dürfte nichts erscheinen, wenn ein Fallback auf Zeichengenerierung stattfindet. Schade ... Das ist echt ein komisches Verhalten. Ich kann noch nicht so recht an einen Hardware-Bug glauben, obwohl es viele Hinweise in Google (und KI) dazu gibt.

Wer hat denn eine VIS3 und könnte sie mal aktivieren ?

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
01.08.2026, 16:18 Uhr
HeikoS

Ich hatte hier die google (KI) - Antwort auf diese Frage gepostet:

Frage: "Es gibt also historisch belegte berichte über diesen Bug? Kannst du mir eine genaue Quelle. z.B. eine Zeischrift nennen?"

Nach weiteren Recherchen habe ich keine belastbaren Belege für diese Antwort erhalten. Ich habe sie deshalb wieder entfernt, damit sie hier nicht weiter im Raum stehen bleibt. Das muss noch besser recherchert werden.

Das Problem mit dem Geister-Pixel beim BIC bleibt aber ...

Grüße, Heiko

Dieser Beitrag wurde am 01.08.2026 um 19:05 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
01.08.2026, 19:00 Uhr
BICa5105

Also ganz Ehrlich...... Bei dieser KI Antwort wär ich vorsichtig.

Es beschreibt diesen Punkt auch falsch. Er ist ja keine Fortsetzung einer Linie sondern entsteht nach dem zeichnen - etwas entfernt der Linie oder des Objektes!
Also ist das mit den CAD Programmen schon mal erfunden.
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
01.08.2026, 19:07 Uhr
HeikoS

@BICa5105:

Gedankenübertragung - habe diese Antwort gerade entfernt, damit sie nicht weiter im Raum stehen bleibt. Sehe ich auch so. Das ist nicht valide genug.

Grüße, Heiko

EDIT: Habe aber dafür das in der Antwort erwähnte "uPD72220_GDC_Design_Manual_Version_3.pdf" auf die Nextcloud zu den anderen Dokumenten gelegt.

https://nextcloud-ext.peppermint.de/s/7Wqp44YjLBN6Htd

Dieser Beitrag wurde am 01.08.2026 um 19:12 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
01.08.2026, 23:23 Uhr
HeikoS

Zitat:

BICa5105 schrieb
... Er ist ja keine Fortsetzung einer Linie sondern entsteht nach dem zeichnen - etwas entfernt der Linie oder des Objektes! ...

Ja, genau. Es wird auf die dem letzten Pixel des Vektors in Y-Rechnung folgende VRAM-Adresse (16 Bit breit) etwas geschrieben, aber immer nur 1 Bit. Auch wenn man den Vektor verkürzt in DC, wird wieder auf die dem letzten Punkt folgende VRAM-Adresse geschrieben.

Es deckt sich auch mit dem in allen Dokus beschriebenem Verhalten, dass die folgende Adresse schon berechnet und in das Addressregister geladen wird, während der vorherige RMW-Zyklus noch läuft (Pipeline).

Die folgende VRAM-Adresse ist also schon eingestellt, wenn FIGD beendet wird. Aber warum wird diese beschrieben, wenn man alle Ausgaben an den GDC beendet?

Ich habe das mit einer einfachen senkrechten Linie auf X1/2=100 von Y1=100 zu Y2=110 sehr schön untersuchen können.

Grüße, Heiko

Dieser Beitrag wurde am 01.08.2026 um 23:23 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
01.08.2026, 23:51 Uhr
Enrico
Default Group and Edit

Müsste das Problem dann nicht auch beim A7150 oder EC1834 auftreten?
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
02.08.2026, 08:46 Uhr
BICa5105

Zitat:

Enrico schrieb
Müsste das Problem dann nicht auch beim A7150 oder EC1834 auftreten?

Ja stimmt. Man müsste dort auch mal so ein Programm testen.
Hab leider meine großen "Kisten" gerade nicht aufgebaut :-( .
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
02.08.2026, 10:57 Uhr
HeikoS

Wäre schön, wenn es mal auf einem anderen Rechner als dem BIC getestet würde.

Kurios ist ja auch der Workaround mit CURS:

Linie:

CURS ; VRAM-Adr. einstellen
FIGS ; Vektordaten einstellen
FIGD ; Vektor zeichnen

-> Geister-Pixel erscheint

1-2 Sekunden warten

CURS auf 0,0 ; Geister-Pixel verschwindet und erscheint auf Pos 0,0

Das allein ist schon komisch. CURS sollte ja nur die VRAM-Adresse einstellen und keine Schreibvorgänge auslösen.

Beim Test müsste aber der GDC, wie oben beschrieben, direkt programmiert werden. Ein LINE-Befehl aus einer Bibliothek reicht da nicht, weil man nicht weiss, was da noch so alles gesendet wird.

Grüße, Heiko

Dieser Beitrag wurde am 02.08.2026 um 10:58 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
02.08.2026, 11:15 Uhr
MarioG77

Mein 1834 steht theoretisch Einsatzbereit herum. Hatte ihn schon ein paar Tage nicht mehr an, also keine Ahnung, ob er nicht eine neue Macke hat...

Ideal wäre irgendwie ein kleines Testprogramm. Ich habe im Moment leider noch nicht die Zeit, groß mit Assembler auf dem 1834 zu testen/hantieren.
Immerhin wäre es ein Grund, die Kiste endlich mal wieder einzuschalten...

--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
02.08.2026, 11:25 Uhr
Enrico
Default Group and Edit

Zitat:

BICa5105 schrieb

Zitat:

Enrico schrieb
Müsste das Problem dann nicht auch beim A7150 oder EC1834 auftreten?

Ja stimmt. Man müsste dort auch mal so ein Programm testen.
Hab leider meine großen "Kisten" gerade nicht aufgebaut :-( .

Beim A7150 stelle ich mir das aber viel schwieriger vor.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
02.08.2026, 11:31 Uhr
HeikoS

Ich kenne die A7150 oder EC1834 nicht mehr so genau. Hatte nur mal was mit einem A7100 zu tun.

Am einfachsten wäre der Test aus einem TURBO-Pascal, welches schon eine Bibliothek hat für den GDC und wo man schon mal eine Linie zeichnen kann mit dem TP-Befehl. Dann ist der Grafik-Mode initialisiert. Danach fügt man ein Stück Assembler mit INLINE ein.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
02.08.2026, 11:41 Uhr
Enrico
Default Group and Edit

Beim A7150 hängt das am Grafiksubsystem per Z80 CPU, Haupt-CPU ist ja der 8086,
Der 1834 ist nicht viel anders als ein XT.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
02.08.2026, 12:07 Uhr
HeikoS

Ah, dann wäre ein Test auf dem 1834 mit TP wohl am schnellesten gemacht. Da müsste ja schon TP4.x laufen und eine GDC-Lib gibt es bestimmt auch. Ich nehme an, dass der 8086 direkt in die Register des GDC schreibt?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
02.08.2026, 13:22 Uhr
Enrico
Default Group and Edit

Muss ja, irgendwie, da die Grafikkarte direkt am Bus steckt, ist ja im Prinzip ISA, nur DIN-Stecker, und z.T. in 16Bit. mindestens der RAM, I/O nicht.
Ist die Frage, wie man auf den RAM der Graka kommt.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
02.08.2026, 13:23 Uhr
HeikoS

Habe nochmal genau in die Initialisierung des GDC geschaut, die ich aus GDCCUBE von Cornelius übernommen habe. Es wird in der Mischbetriebsart gearbeitet. Könnte es evtl. sein, dass das "Geister-Pixel" ein Textcursor in Grafikdarstellung ist, der mit CURS nachgeführt wird?

Dieser Beitrag wurde am 02.08.2026 um 13:24 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
02.08.2026, 13:25 Uhr
HeikoS

Zitat:

Enrico schrieb
Muss ja, irgendwie, da die Grafikkarte direkt am Bus steckt, ist ja im Prinzip ISA, nur DIN-Stecker, und z.T. in 16Bit. mindestens der RAM, I/O nicht.
Ist die Frage, wie man auf den RAM der Graka kommt.

Oh, gibt es keine Möglichkeit IO-Befehle zu senden über den ISA Bus? Wie soll denn der GDC sonst angesprochen werden?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
02.08.2026, 13:52 Uhr
Enrico
Default Group and Edit

Ich meinte mit "und z.T. in 16Bit. mindestens der RAM, I/O nicht."
I/O nicht in 16 Bit.

Das BIOS, Treiber muss die ja initialisieren.
Wie auch immer das läuft.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
02.08.2026, 14:46 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Habe nochmal genau in die Initialisierung des GDC geschaut, die ich aus GDCCUBE von Cornelius übernommen habe. Es wird in der Mischbetriebsart gearbeitet. Könnte es evtl. sein, dass das "Geister-Pixel" ein Textcursor in Grafikdarstellung ist, der mit CURS nachgeführt wird?

Hmm, es wird aber für jede Zeile das Image-Bit geschickt. Schau da mal auf das Signalspiel auf A16 und A17. Evtl. schließt dich der Cursor aus.

Ich kam gestern doch nochmal an den BIC und habe bisscgen getestet (ohne Double Buffering). Da konnte ich nichts erkennen. Ich habe auch Pausen beim Linienzeichnen eingebaut u.a. Tests gemacht. Aber jede Linie startet da brav mit CURS usw.

Kannst du bitte mal ein Video von dem Seiteneffekt machen?

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Aktuelle Projekte: GDC-Analysen für Grafikeffekte u. Demo/Game-Framework, universelles BIC-Modul auf Pico-Basis, Packer mit sehr kleinem 6502-Dekompressor
HW: BIC, MSX2+, KC87, KC85/2-4, KCC, LC-80, PC1715, C64, C16, Plus/4, A500, A1200, Mega 65, µCs ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
02.08.2026, 16:02 Uhr
PIC18F2550

Ich weis nicht mit was du Programmierst, aber ein Fehler kann auch in einem Modul von der Programmiersoftware sein.
--
42

ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
02.08.2026, 19:27 Uhr
HeikoS

Zitat:

Dresdenboy schrieb

Zitat:

Hier hatte ich das mal gefilmt: <679>

https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22549&pagenum=2#272339

Dann kann es evtl. auch an der GDC-Initialisierung liegen, wenn das bei dir nicht auftritt. Die habe ich ja, wie gesagt, von Cornelius (GDCCUBE) übernommen. Ansonsten wird mit Assembler nur der Vektorbefehl benutzt:

Quellcode:


                ...
                LD      hl,hfigs        ;FIGS Parameter
                CALL    DFIFO           ;AUSGEBEN
                LD      HL,FIGD
                CALL    DSTART  
                ... 
                STOP -> Linie ist gezeichnet, Geister-Pixel ist zu sehen
                
;------------------------------------------------------------------------------
; aus VIS3, AdW der DDR, leicht modifiziert für BIC / Port INC/DEC 
; https://hc-ddr.hucki.net/wiki/doku.php/z1013/module/vis3 -> vis3amz1013.zip           
;------------------------------------------------------------------------------
;DFIFO - Kommando, Parameter in FIFO-Speicher
; Eingabe: HL - Adresse des Kommandofeldes 
;          (Kommando,Parameterzahl,Parameter,..)
;------------------------------------------------------------------------------
DFIFO:          push    bc
                push    hl
                ld      a,FLAGR 
                ld      c,a
dfifo3:         in      a,(c)
                bit     1,a             ;CMD ready ?
                jr      nz,dfifo3
                inc     c               ;CMD
                ld      a,(hl)
                out     (c),a           ;Kommando in FIFO
                inc     hl
                ld      b,(hl)          ;Anzahl Parameter
                ld      a,b
                and     a
                jr      z,dfifo1        ;keine Parameter
                inc     hl
                dec     c               ;PARA, Param.in FIFO
dfifo2:         in      a,(c)
                bit     2,a             ;FIFO leer?
                jr      z,dfifo2        ;nein
                otir                    ;Param. in FIFO
dfifo1:         pop     hl
                pop     bc
                ret
                
;------------------------------------------------------------------------------
; aus VIS3, AdW der DDR, leicht modifiziert für BIC / Port INC/DEC 
; https://hc-ddr.hucki.net/wiki/doku.php/z1013/module/vis3 -> vis3amz1013.zip           
;------------------------------------------------------------------------------
;dstart - Startkommando an FIFO
; Eingabe: hl - Startkommando
;------------------------------------------------------------------------------
DSTART:         push    bc
                ld      a,FLAGR          
                ld      c,a
dstar1:         in      a,(c)
                bit     1,a             ;CMD ready ?    
                jr      nz,dstar1
                inc     c               ;CMD
                out     (c),l
                pop     bc
                ret

EDIT:

Könntest Du mir Deine VIS/GDC-Initialisierung senden? Hier der Code aus GDCCUBE, ein wenig kommentiert. Gestartet wird aus SCPX, also die Initialisierung aus diesem MODE übernommen und dann mit dem folgenden Code überschrieben:

Quellcode:


;------------------------------------------------------------------------------
; Die folgenden Routinen zur Initialisierung/Bedienung von VIS/GDC wurden aus 
; dem GDCCUBE-Bsp. von Cornelius Krejcik übernommen.
; https://www.youtube.com/watch?v=eHB70pNTopk
;------------------------------------------------------------------------------
VI0:
        xor     a               ; X000 X000
        out     (VISMOD),a      ; Mode  0-7
    
        ld      a,020h          ; Farbregister 0: Rand schwarz
        out     (VISMOD),a
        ld      a,031h          ; Farbregister 1: Hintergrund dunkelblau
        out     (VISMOD),a
        ld      a,04Fh          ; Farbregister 2: Vordergrund weiss
        out     (VISMOD),a
        

        ; PRAM3 (der Code wird nicht benötigt, da in GINI erledigt s.u.)
        ;ld      a,PRAM3        ; 73            
        ;out     (COMNP),a
        
        ;ld      a,04Ch         ; 01 001100
        ;out     (PARAP),a
        ret

;------------------------------------------------------------------------------

GINI:
        call    WE
    
        ld      a,PRAM                  ; 70
        call    OC
        xor     a                       ; 0 Startadresse L (SAD1L)
        call    OP
        xor     a                       ; 0 Startadresse H (SAD1M)
        call    OP
        ld      a,10100000b;0A0h        ; 1010 0000 (LEN1L, 0,0, SAD1H)
        call    OP
        ld      a,01001111b;04Fh        ; 01 001111 (WD=0, IM=1, LEN1H)
        call    OP
                                        ; -> 001111 1010 = FA = 250 Zeilen
              
        ld      a,STARTC
        call    OC
        ret

OC = Ausgabe COMMAND mit FIFO-Prüfung
OP = Ausgabe PARAMETER mit FIFO-Prüfung
WE = Prüfung, ob fertig gezeichnet + FIFO-Prüfung

Dieser Beitrag wurde am 02.08.2026 um 20:38 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
02.08.2026, 19:29 Uhr
HeikoS

Zitat:

PIC18F2550 schrieb
Ich weis nicht mit was du Programmierst, aber ein Fehler kann auch in einem Modul von der Programmiersoftware sein.

Ich benutze ja keine Programmiersoftware, nur Arnold-Assembler und GDC-Doku.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
02.08.2026, 19:37 Uhr
HeikoS

Zitat:

Enrico schrieb
Ich meinte mit "und z.T. in 16Bit. mindestens der RAM, I/O nicht."
I/O nicht in 16 Bit.

Das BIOS, Treiber muss die ja initialisieren.
Wie auch immer das läuft.

Ah - ok, das hatte ich falsch verstanden. Danke für den Hinweis. Der GDC wird ja meines Wissens ausschließlich mit 8-Bit I/O angesprochen. Das müsste ja dann gehen.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
02.08.2026, 20:30 Uhr
MarioG77

Zitat:

HeikoS schrieb
Ah - ok, das hatte ich falsch verstanden. Danke für den Hinweis. Der GDC wird ja meines Wissens ausschließlich mit 8-Bit I/O angesprochen. Das müsste ja dann gehen.

Ja klar, sonst wäre es recht Dunkel und Robotron hätte den sicher nicht nehmen können...

Wobei meine Erweiterung ja evtl. auch 16 Bit IO Zugriff möglich macht. Es wird wirklich Zeit, dass ich das mal teste...

Sorry für Off Topic...

--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
02.08.2026, 20:43 Uhr
HeikoS

Klar, aber es war ja schon die Rede von Z80-Subsystemen im A7150. Das wäre dann schwierig. Ich kenne diese Rechner wenig.

Grüße, Heiko

Dieser Beitrag wurde am 02.08.2026 um 20:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
02.08.2026, 21:25 Uhr
Enrico
Default Group and Edit

Zitat:

HeikoS schrieb
Klar, aber es war ja schon die Rede von Z80-Subsystemen im A7150. Das wäre dann schwierig. Ich kenne diese Rechner wenig.

Grüße, Heiko

Wäre auch eine größere Baustelle bei sowas.....
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
02.08.2026, 22:31 Uhr
HeikoS

Das Problem ist gelöst.

In der RFT-Doku des GDC findet sich unter "Zeichen-Betriebsart" folgender Text:

Das hat mich auf die Lösung gebracht. CURS verändert also den Zeichen-Cursor, d.h. schreibt etwas in den VRAM. Genau das beobachte ich ja, wenn mit CURS 0,0 das Pixel von der "Geister-Position" auf Pos 0,0 springt. Der FIGD-Befehl führt ja CURS intern automatisch aus, so dass der Zeichen-Cursor auch mit bewegt wird und dann angezeigt wird (als "Geister-Pixel").

Durch die Initialisierung des GDC aus der "Zeichen-Betriebsart" (BIC-SCPX), ist der Text-Cursor noch aktiv. Wenn man ihn abschaltet mit:

Quellcode:


        ld    a,CCHAR
        call  OC
        ld    a, 00000000b     ; 0=Cursor aus,  00,  00000=0 Zeilen/Zeichenreihe
        call  OP

ist das "Geister-Pixel" weg. Die GDC-Initialisierung war nicht ganz korrekt.

Tests auf anderen Systemen sind dann nicht mehr nötig.

Eigentlich wollte ich das alles garnicht wissen und nur eine "saubere" Linie für meine Demo mit dem GDC zeichnen. Mal wieder was gelernt. Der GDC ist schon ein interessanter Chip.

Grüße, Heiko

Dieser Beitrag wurde am 02.08.2026 um 22:38 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
02.08.2026, 23:58 Uhr
Enrico
Default Group and Edit

Ob man das wohl mal als "normaler" Mensch versteht und nutzen kann ?!

--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]