Wow 
Falls du nochmal den Pin nennst wo UD3 jetzt angeschlossen ist kann ich mal schauen ob ich was erkenne.
Wow
Falls du nochmal den Pin nennst wo UD3 jetzt angeschlossen ist kann ich mal schauen ob ich was erkenne.
Na klaro: Erst war es PIN2, jetzt PIN5. 
Kann aber auch mit dem Mainboardtyp zusammenhängen.
Alles anzeigenNächster im Bunde: MMF 9000 Fake plus Data Becker Grafik
Allerdings nach gefühlt 235 Anläufen. CPU Kabel tot/Wackelkontakt, UD3 gibt das benötigte Signal für die Data Becker auf einem anderen Pin aus (?!?), wieder Wackelkontakt, kein Platz, etc…
Ergebnis:
ABER- und da kenn ich mich nicht aus: Anstatt bei 0 müssen x-Koordinaten bei 8 beginnen, da sie ansonsten ganz rechts auf dem Bildschirm gezeichnet werden.
Keine Ahnung. Ich hab das Programm des 8032 so umgeschrieben, dass es eben erst bei 8 beginnt.
Und: Hardcopys auf Datenspeicher haben auch leichte Grafikfehler.
Irgendwas passt der Karte also nicht, wenn sie im MMF steckt. Oder aber, es hängt mit diesem Signal zusammen, welches ich umpinnen musste:
Ist aber prinzipiell egal. Funktion ist gegeben und so auch ausreichend.
Als MMF läuft der Rechner natürlich auch noch.
Für Nachbauer: Geht nur mit dem Zweiplatinen-MMF. Der ältere Dreiplatinenrechner hat vermutlich keinerlei Platz auf den Steckverbindern. Müsste man mal testen.
Ahoi, ihr Grafikzwirbler!
Ich würde einfach mal "ins Blaue hinein" andere Videotimings vermuten. Die Data Becker gibt die Grafik doch als "Overlay" zu den normalen Videosignalen aus, oder nicht?
Das ist korrekt.
UD3, Ausgang A. (Eingangs-16Mhz einmal dividiert)
8032029 -> UD3 (74177), Pin 5
8032087 -> UD3 (LS893), Pin 3
Seh grade dass ich es in meiner Konnetorenübersicht als Pin11 angebe. Uiuiui
Das hat dann also nix mit den Koordinaten zu tun.
Ich würde einfach mal "ins Blaue hinein" andere Videotimings vermuten. Die Data Becker gibt die Grafik doch als "Overlay" zu den normalen Videosignalen aus, oder nicht?
Sie schreibt in den Datenbus des Charroms.
Jetzt würde mich mal interessieren ob das mit dem µMMF auch so ist.
Wo landen eigentlich die Punkte mit X-Koordinate639?
Mooooment mal... da war doch was mit dem Superpet und komisch verschobene Ausgaben:
Ist da in dem Screenshot nicht auch die erste Zeile um 8 Pixel falsch? Und dieses "9our" statt "your" -> sind das evtl auch ein offset von 8 im charrom zwischen 9 und y? Oder so?
Ich rieche da einen Zusammenhang.
Na wir sammeln erst mal Symptome.
Also momentan, Superpet+DBHires = Grafik 8 pixel zu weit links beginnend aber text nicht.
Wo landen eigentlich die Punkte mit X-Koordinate639?
Dann wäre interessant: Superpet ohne DB Highres?
DB Highres in diesem Board ohne Superpet?
PS:
stecken die in den richtigen Pins?
Für mich sieht das wie Pin4&6 aus statt 3&5?
Doch, Text und Grafik beginnen 8 Pixel zu weit rechts- wobei man es auch so sehen kann, dass die Grafik eben erst exakt am Anfang des Textes erscheint, wenn man der X-Koordinate die 8 gibt.
Mit nur Text ist es aber nie aufgefallen.
Und eigentlich ist es ja dann 9, weil die Werte von 0 beginnen, right? Ich bin schon ganz verstört. 
Die Buchsenleiste steckt korrekt auf 3 und 5- ich habe bewusst ein Pin überstehen lassen.
Irgendwie bin ich verwirrt. Der "frühe" morgen tut sein übriges. Der Text beginnt zu weit rechts? Der müsste dann wenn doch auch zu weit links beginnen (und dann nach ganz rechts auftauchen).
Screenshots, plx? 
So wie ich das verstehe, steht die Grafik eigentlich richtig, und nur der Text um 1 Zeichen versetzt?
Ich versuch es mal, zu beschreiben (bin aktuell nicht zuhause):
Schalte ich den Rechner in 6502 Modus ein, erscheint das ganz normale Einschaltbild von Basic 4.0.
Hier nichts auffällig. Auch, wenn ich eine Zeile vollschreibe, beginnt der Text ganz normal wieder links.
ABER: lasse ich eine Linie zeichnen (vertikal von oben links nach unten links) muss diese so programmiert werden:
!LINE 8,y TO 8,y. Dann erscheint diese Linie EXAKT da, wo normaler Text auch auf dem Bildschirm beginnt. LINKS.
Deshalb vermute ich, dass auch der Text des Rechners um acht Pixel zu weit rechts dargestellt wird. Würde der Text bei Pixelreihe 0 beginnen, erschiene die Linie ja weiter rechts als der Text.
ODER ABER: Text ist ganz normal dargestellt, lediglich Grafikkarte braucht die 8, um bei 0 zu beginnen... DOOF ZU BESCHREIBEN.
Jedenfalls erkennt man beim Text keinerlei Abweichungen zu einem normalen 8032. Muss aber nichts heißen, weil man eventuelle Abweichungen des linken Randes ja mit Einstellung der Röhre "wegoptimieren" kann.
Ich würde die Karte verdammt UNGERN erneut ausbauen. Auch das Zusatzboard des MMF... am Ende gibts wieder irgendwo einen Wackelkontakt und nix geht mehr. Das hat mich gestern in Summe gute FÜNF Stunden gekostet. 
Aber ich hätte noch einen 8032 mit eingebauter DB Hires hier, der noch nicht abgeholt worden ist.
Da kann ich zumindest mal vergleichen.
Schiesst gerne los, was ich da vergleichen soll/kann!
Also sollte ja, wenn du mit poke 32768,1 oben links in die ecke ein a setzt dieses auch ganz normal oben links zu stehen kommen, oder?
(32768 = E000 = Beginn des Videospeichers)
vossi hatte doch mal einen blogbeitrag geschrieben, in dem er direkt in den bildschirmspeicher der DBHR schreibt: http://lc64.blogspot.com/2017/…h-data-becker-hi-res.html
kann das testproggy da im Blog jemand in Basic übersetzen? Sollten ja nur pokes sein. Dann könnte das CBM_Ba auch mal testen.
Sooooo, hier der Direktvergleich:
Links 8032, rechts MMF:
8032:
MMF:
Und hier wieder beide, diesmal ab X-Koordinate 0:
Der Poke ist bei beiden gleich- ok.
Ah, jetzt hab ich kapiert, wie der Fehler aussieht.
Interessant wäre zu wissen, ob das mit dem MMF zusammenhängt, oder ob der Fehler auch auftritt, wenn der Rechner zu 8032 zurückgerüstet ist.
Ja, leider. Das wäre wichtig zu wissen. Der SuperPet sollte doch genau NULL Auswirkung haben.
Kann das Char ROM ein Thema sein?
Probiers aus Sollte nicht das normale Char-ROM im 6502 Modus normal funktionieren?
Ich würde sagen "nein". Denn selbst wenn da nur Müll drin steht wird der stur ausgegeben, das Raster ist davon nicht abhängig.
Irgendwie stimmen die Adressen, die der CRTC zum auslesen generiert nicht mit denen überein, die geschrieben werden.
Mal was anderes, diese Flachband to DIP Adapter, wie crimpst du die? Klotz und Schraubstock? Muss die an der HAL PCG machen
Mal was anderes, diese Flachband to DIP Adapter, wie crimpst du die? Klotz und Schraubstock? Muss die an der HAL PCG machen
Zange.
Geht aber super auch mit Schraubstock plus zwei gedruckte Backen.
Da gibt es Zangen für?
Wir haben die früher immer mit Schraubstock und irgendwelchen Holzklötzchen in passender Größe gecrimpt. Die Klötzchen entsprechen dann wohl den neumodischen "gedruckten Backen".
zitruskeks meinte aber diese IC-Sockel-Dinger. Glaube ich zumindest. Vielleicht habe ich ihn aber auch falsch interpretiert.
Das Ding für die Buchsenleisten (heißen die so?) kenne und habe ich in der Tat auch.
Spannende Frage, die ich mir stelle: Gibt es Ähnliches hierfür?
https://www.digikey.de/de/products/detail/assmann-wsw-components/ADIP-24Z-LC/924324
Nachtrag: Ah! Verstehe. Du ersetzt diesen gelben Einsatz durch was Breiteres. Schöne Idee! 
Ich würde sagen "nein". Denn selbst wenn da nur Müll drin steht wird der stur ausgegeben, das Raster ist davon nicht abhängig.
Irgendwie stimmen die Adressen, die der CRTC zum auslesen generiert nicht mit denen überein, die geschrieben werden.
So, du hattest wieder mal recht- der Fehler bleibt auch, wenn das MMF-Board draußen ist.
Da ist doch noch diese eine Leitung mit dem 16Mhz-Signal zum CPU Sockel... hat die Einfluss drauf?
Ich will das Mainboard jetzt nicht rausreißen.
Was könnte es dann sein? Das Editor ROM wohl auch kaum? Echt eine spannende Frage!
8mhz signal soll das sein
